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.
Description: OpenPGP digital signature