Page MenuHomeFreeBSD

vesa: fix panic on suspend
ClosedPublic

Authored by royger on Jul 12 2016, 2:04 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 11:28 AM
Unknown Object (File)
Feb 20 2024, 5:42 PM
Unknown Object (File)
Jan 20 2024, 1:06 PM
Unknown Object (File)
Jan 16 2024, 5:46 PM
Unknown Object (File)
Jan 2 2024, 1:48 AM
Unknown Object (File)
Dec 27 2023, 10:52 AM
Unknown Object (File)
Dec 23 2023, 3:03 AM
Unknown Object (File)
Nov 19 2023, 2:23 PM
Subscribers

Details

Summary

Fix the following panic seem 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. Instead create a vesa_late_attach that
initializes the mutex and calls vesa_configure.

Sponsored by: Citrix Systems R&D
MFC after: 3 days

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

royger retitled this revision from to vesa: fix panic on suspend.
royger updated this object.
royger edited the test plan for this revision. (Show Details)
royger added reviewers: emaste, dumbbell.

Ping? Sorry for the hurry, but I would like to get this into 11.

I don't know the interaction between vga and vesa here and how all those functions are called and in which order.

I suppose vesa_load() is not called at all in the code path you hit. But can't you use it as vga_sub_configure?

I don't know the interaction between vga and vesa here and how all those functions are called and in which order.

I suppose vesa_load() is not called at all in the code path you hit. But can't you use it as vga_sub_configure?

The problem with using vesa_load directly is that it doesn't take any parameter, while vga_sub_configure takes a flags parameter. What I could probably do is make vesa_load call vesa_late_load with an empty flags parameter, does that sound better?

Or the reverse: vesa_late_load(flags) calls vesa_load()? Just to avoid code duplication.

But my suggestion could be wrong: vesa_load() checks vesa_init_done and nullifies vesa_adp. I don't know the code enough :(

Or the reverse: vesa_late_load(flags) calls vesa_load()? Just to avoid code duplication.

But my suggestion could be wrong: vesa_load() checks vesa_init_done and nullifies vesa_adp. I don't know the code enough :(

vesa_late_load cannot call vesa_load because vesa_load cannot take any parameter, and vesa_late_load needs to pass the flags parameter around.

AFAICT, when vesa_late_load (vga_sub_configure) is called vesa_adp should be null and vesa_init_done should be 0, or else there's something wrong going on.

IMHO, the best solution is to rename vesa_load to vesa_late_load (adding a flags parameter), and turn vesa_load into a wrapper that just calls vesa_late_load.

Ok, thanks for the explanation. Sorry I missed that flags was passed to vesa_configure().

Your idea looks good.

This revision was automatically updated to reflect the committed changes.