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.

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.

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.

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.

Hope this helps someone.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to