Suspend/resume on Macbooks: partial diagnosis

[Jung-uk Kim]

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
> would).
>
> 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 
happen. ;-)

Jung-uk Kim