Date: Sun, 26 Feb 2012 16:33:36 -0500 From: Eric McCorkle <eric@shadowsun.net> To: freebsd-acpi@FreeBSD.org Subject: Suspend/resume on Macbooks: partial diagnosis Message-ID: <4F4AA530.4030606@shadowsun.net>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC7CDEC818CD110CE184C3295 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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).=20 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. --------------enigC7CDEC818CD110CE184C3295 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJPSqUwAAoJENSCzbQ+koZ7PzAP/37fw/HoP/1YSFd5qovUqGNc WKJOPPk8JLxoKUn210PEk4BMHTakzv/39SSp7qWc88lifHmEJ0J/2b0GdefGaHHh qXkkFcdIk8imnmKjhCFRKX7HUojHO2ZmqEJYg1y5Qvr6CWsfyaKq0iis6Cd81Fd1 8j+aZXJvbiVg3Gkl/Vy1XMcdgogOC0nri234xQ/Vi54T87PRkocCcNh8p7ZipUP5 5kt9MKTWJX2xm93GqQ951FMDnUJo0E7Liq4IQXULK0t/F2YPfhu4ww7PPPzbCWDw 9bZgegH4kgpFMWcOQh89p1XhU+OksFwYBd1Ec+isnLO+QUwR5QUwo6cZ53jcq5Uv tTaZ7K7XCwtlABaKMcBLLHbu9YyJ8NRH/l+PJjZCmAinQvwyoYh3vt0gdPVfUh1h UuqV1JNJzOdtN6uAyiYRySRr0kPMxB/o1RaUvD2v5BFx/2oCz4f9zS0qs2FMfubo L6PbCByojFWO8eDS6TPP4L5D9mbrpmj7PDCwwpzUNywVysbF/xmErQP5PyQo19Gc 5eC1tvhPqRZMgKcrhdmQZvwKp4W4PslIUwvoUpYTpxZGSxLeD/EHMT+zk3vHNvnE zZOKuDsI8s4zoV2ynbCJxm8EICD8ZA4kAIiO9hOEQPkoUpAWFqYzhWGJyK0eBrPk I64p/cFq15hKNHVqOO/s =BxYH -----END PGP SIGNATURE----- --------------enigC7CDEC818CD110CE184C3295--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F4AA530.4030606>