Date: Mon, 20 Jul 2009 18:59:18 +0200 From: David Naylor <naylor.b.david@gmail.com> To: Peter Harrison <peter.piggybox@virgin.net> Cc: freebsd-acpi@freebsd.org Subject: Re: [PATCH] Lenovo S10(e) ACPI Message-ID: <200907201859.21882.naylor.b.david@gmail.com> In-Reply-To: <20090713195836.GA1093@ideapad.piggybox> References: <200906181407.11607.naylor.b.david@gmail.com> <200907131447.24702.naylor.b.david@gmail.com> <20090713195836.GA1093@ideapad.piggybox>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Hi, How is the testing going? I've actually had the symptom you described (twice I think). In my case the screen goes blank (but still on) and no power off. The first time the battery was dead when it shouldn't have (didn't wait for it to power down), the second I was there to 'witness' it. These are, for me, very sporadic events. Since some timeouts still occur I suspect one is happening for the shutdown command. See at the bottom for a quick discussion. On Monday 13 July 2009 21:58:36 Peter Harrison wrote: > > First some diagnostics, please do the following: > > 1) On a console: > > # uname -a > > FreeBSD ideapad.piggybox 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Sat Jun > 20 11:03:21 BST 2009 > peter@ideapad.piggybox:/usr/obj/usr/src/sys/GENERIC i386 Upgrading to 8 might improve things. > > # sysctl debug.acpi > > debug.acpi.suspend_bounce: 0 > debug.acpi.do_powerstate: 1 > debug.acpi.acpi_ca_version: 20070320 > debug.acpi.ec.timeout: 100 > debug.acpi.ec.polled: 0 > debug.acpi.ec.gpe: 1 > debug.acpi.ec.delay: 200 > debug.acpi.ec.burst: 0 > debug.acpi.batt.batt_sleep_ms: 0 > debug.acpi.semaphore_debug: 0 > debug.acpi.resume_beep: 0 Everything looks good, although your acpi_ca_version is outdated (newer in -current). Increasing timeout might help (say 750), also increasing delay won't hurt [don't forget delay is in microseconds whereas timeout is in milliseconds]. > > 2) What version are you using (I've got the S10e)? > > S10e - BIOS reports model number 40684AG Same (except XG suffix) > > 3) What version of the BIOS are you running? > > BIOS version is 14CN51WW Difference, I've got 14CN67WW. I'll be interested to know how you flash your system (if you don't have Windows installed). > > 4) Is there any predictors as to when the system will not shutdown? > > Not that I've been able to determine. I thought at one point that it had to > do with the amount of charge in the battery, or whether it was mains > connected. But I can't detect a pattern. Same > > 5) What are the last messages printed on the console (when shutdown > > fails)? > > Sometimes normal 'Syncing disks, vnodes remaining...' sometimes the correct > message but garbled. > > Whether the message is garbled or not seems to have no bearing on whether > the system powers off or not. My suspected solution: If I understand the situation correctly, in spite of my hackery there is still a timeout happening. This sometimes happens at the most unfortunate time of a powerdown preventing the BIOS from receiving the command to switch of power. I suspect that FreeBSD doesn't try to reissue the power down command if it fails and just abandons things. If I understand the Linux code correctly in the heart of the acpi_ec code: if there is a command timeout it will reset the EC and reissue the command, so in effect Linux reissues. One place to look is the ACPI shutdown code and make it retry a power-down if it fails, or make the acpi_ec more robust to EC timeouts. I think this will be a good time to consult someone who actually has an understanding of ACPI (especially the EC). Any ideas welcome. Regards [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkpkomkACgkQUaaFgP9pFrK/QgCfVUQi2H94MM+jANaWrhw6hU7p v4UAn2A+BaRPCWLs8j4Vs3+QwXUJPuow =/YNS -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907201859.21882.naylor.b.david>