Date: Fri, 10 Jul 2015 00:34:56 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-mobile@freebsd.org" <freebsd-mobile@freebsd.org>, freebsd-acpi@freebsd.org Subject: Attempting to diagnose suspend/resume issue Message-ID: <559F4B70.8060402@metricspace.net>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A69Jo0KNjClhIe0LL8wJF1M6fD2Iscg2E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A long while ago, I reported my screen not coming back on after resume, shortly after r274386 went in. Unfortunately, the follow-on patch didn't seem to work for me. (r274386 changed the way devices get powered down/up, and r274397 fixed a typo in r274386 that tried to power down/up the wrong devices.) I finally found the time to try and track this thing down, and I got some information that might prove useful in tracking it down. * The screen comes back up only for syscons in pixel mode up to r274835. As far as I can tell, it doesn't work for vt in any revision (not as sure about text-mode syscons, but there is at least one revision where it works for pixel mode, but not text mode) * Comparing logs from r274385 and r274397, it seems the likely cause is that the changes in r274386 reordered things so that the VGA driver attempts to restore the state of the card before its power has been turned back on (you can clearly see this happening, and you can see the attempt to restore the state failing). * Suspend/resume works fine in Linux (I'm not sure how to get linux to printout a debug trace similar to debug.bootverbose), so the hardware can't be /that/ broken. * The order in which things happen during resume seems to be different between vt and syscons resumes, though I can't tell where vt restores the state of the card (or the efifb device) My guess as to the likely cause is that vt also tries to restore the state of the card before its power has been turned back on similar to what syscons does after r274386, or else the dual happens during suspend (it tries to save the state after the device is powered down). It does seem a little wierd that syscons would behave differently in that respect for pixel mode vs text mode, though. I'm open to suggestions as to what to look at next, or theories as to what might be the culprit. I also have dmesg logs for the various revisions and drivers. Best, Eric --A69Jo0KNjClhIe0LL8wJF1M6fD2Iscg2E 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 iQIcBAEBAgAGBQJVn0t0AAoJECuREQPg1IcE7rAP/jteSXpB5FjTIT3IYfbzSWUH p6rZX4phzFAoViunN1joDjU6nAKSZV07hNrw50dJvZdjRvD87NJMrJGMUWxxFnI2 kwx1SM8ONKSmO95aeoKDxgQvDvdvl4T7ZLibCe5Exvx3Sv+4+HR3rM6zv61yIL9O e1OJvUwrczVbeGwthOxxGR2ayXFvg7zjkokfAmEX1tEyCBjaTyHhwlFP0hVhAVO9 usWrzpVmdfAdkxhM9D+CKsPWk68OcnwL75bDXMv1se2/AyOKBG4caZf4C2YrMFUb norsIcRCrG2oRgf6F1sOpSTHMJ4ge33fKNG25Aq2QZXgX1V8499UdsIYpU4GZBFJ +veribe6l+Y42z3ZUT1kiNRfZm+RmhxeQCcxMIrlitkq0k78N4584FBEkfbWtOqd Xh33rmgqHja/EWo1LubyOgAgBjrgFRzaKuZ64FRPiXH4z281sNUwGFsM4k50RiYb A5j0xZJYzWjMJ8sG3/YITKTNvTmXCkgcFHeo6Fmfmxk8YsEOdohKlE24ZXxrbavI zDhBvjrZSnF8g+Z3FPDPmYgmoY3plpFWmk/7SS2uOe8aCO7SF6lyePeXlsO927/k 7aTXS1e2DSGCpV5mgOIFhy3hEVBSmkkxe4SNE7Yu3MCRvMhidRV6J33I5igrMn+P X6cmM5bKoHFVq05K1MqE =Dds2 -----END PGP SIGNATURE----- --A69Jo0KNjClhIe0LL8wJF1M6fD2Iscg2E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?559F4B70.8060402>