Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jul 2009 21:52:53 +0100
From:      Peter Harrison <peter.piggybox@virgin.net>
To:        David Naylor <naylor.b.david@gmail.com>
Cc:        freebsd-acpi@freebsd.org, Peter Harrison <peter.piggybox@virgin.net>
Subject:   Re: [PATCH] Lenovo S10(e) ACPI
Message-ID:  <20090723205253.GB1084@ideapad.piggybox>
In-Reply-To: <200907201859.21882.naylor.b.david@gmail.com>
References:  <200906181407.11607.naylor.b.david@gmail.com> <200907131447.24702.naylor.b.david@gmail.com> <20090713195836.GA1093@ideapad.piggybox> <200907201859.21882.naylor.b.david@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Monday, 20 July 2009 at 18:59:18 +0200, David Naylor said:
> 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.  

My symptoms are the same - though I didn't describe them quite so well.

> 
> 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.  

I'd rather wait for 8-RELEASE for that, but I'll think about it.

> 
> > > # 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].  

I've fiddled with both the delay and timeout numbers, and don't seem to be able to make a consistent difference.

> 
> > > 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).  

Looking over the Lenovo site, I don't see a way to run the utility unless I'm running Windows (which I'm not). Reading the notes, it seems there has been a change to the acpi code in the updates too. I need to try and find a way around this.

> 
> > > 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.

Ditto. But thanks for all the help and support so far.


Peter Harrison.


> 
> Regards





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090723205253.GB1084>