Suspend/resume on Macbooks: partial diagnosis
jkim at FreeBSD.org
Mon Feb 27 18:04:22 UTC 2012
On Sunday 26 February 2012 04:33 pm, Eric McCorkle wrote:
> A while ago, I tried to diagnose the reason why suspend/resume
> doesn't work on my macbook (9.0-STABLE, 13' unibody macbook pro,
> 5,5, I think). I got a partial answer, but then got busy and never
> finished. The recent KDE update apparently triggers a suspend, so
> I had incentive to look at it again, and also to report my previous
> findings, in case someone else has information or can fix it.
Can you please show us more detail, e.g., "devinfo -rv", "pciconf
-lv", verbose dmesg, etc?
> Here's what I have:
> The USB system sometimes fails to come back up, but this seems to
> be a more general issue not specific to the hardware. The firewire
> system would also sometimes trigger a kernel panic, but that was
> almost a year ago on 9-CURRENT, and firewire was causing other
> issues, so I disabled it and haven't used it since.
These are very common issues, unfortunately. :-(
> The VGA system fails to come back up, reporting "vga0: failed to
> reload state". I traced this error using extra logging messages to
> the BIOS POST call, at which point the x86emu system emulates the
> bios. From looking at the error message, disassembly of the BIOS
> code, and the memory map I am almost certain I know why. I'd meant
> to confirm it 100%, but I got busy.
Actually, the error message has nothing to do with BIOS POST call. Do
you have NVIDIA GPU on it?
> The root problem seems to be bad BIOS code that accesses the stack
> one word above the region allocated by the BIOS memory map (the map
> allocates 0x1000-0x1fff, the code dereferences 0x2000, or something
> similar). This is *technically* an error, but it does not cause a
> problem during boot, because there is always good memory at that
> address. The BIOS emulation system, however, seems to only
> allocate the regions described by the memory map, and thus treats
> it as an error (as a strictly-conforming BIOS implementation
> A quick-and-dirty fix might be to add an extra page above the stack
> region. I'm not sure what a more "legitimate" fix might be, since
> it's the BIOS code and not FreeBSD that's causing the problem.
> I'll probably take a closer look in the near future.
x86bios virtualizes real-mode memory and invalid memory access
immedidately halts the emulator. In other words, it shouldn't
More information about the freebsd-acpi