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 _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
