https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209203
--- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: jhb Date: Sat Aug 6 23:52:09 UTC 2016 New revision: 303807 URL: https://svnweb.freebsd.org/changeset/base/303807 Log: MFC 303076,303225: Use MTX_SYSINIT for the VESA lock. 303076: vesa: fix panic on suspend Fix the following panic seen when migrating a FreeBSD guest on Xen: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0 __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630 vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680 vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0 isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0 bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame [...] This is caused because vga_sub_configure (which is called if the VGA adapter is attached after VESA tried to initialize), points to vesa_configure, which doesn't initialize the VESA mutex. In order to fix it, make sure vga_sub_configure points to vesa_load, so that all the needed vesa components are properly initialized. 303225: Use MTX_SYSINIT for the VESA lock. vesa_init_done isn't a reliable guard for the mutex init. If vesa_configure() doesn't find valid VESA info it will not set vesa_init_done, but the lock will remain initialized. Revert r303076 and use MTX_SYSINIT to deterministically init the lock. PR: 209203 Approved by: re (gjb) Changes: _U stable/11/ stable/11/sys/dev/fb/vesa.c -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
