Date: Mon, 20 Apr 2009 14:47:18 +0300 From: Andriy Gapon <avg@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: run resume code only for S1-S4 states Message-ID: <49EC60C6.7000702@freebsd.org> In-Reply-To: <49E9FFB0.6090707@root.org> References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org> <49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org> <49E4B2A7.3020302@freebsd.org> <49E61986.7040709@root.org> <49E8AED0.1090008@freebsd.org> <20090418125806.2a48b0a8@fabiankeil.de> <49E9FFB0.6090707@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 18/04/2009 19:28 Nate Lawson said the following: > Fabian Keil wrote: >> Andriy Gapon <avg@freebsd.org> wrote: >> >>> An updated version of the patch, the only difference is: do-while(0) is gone, >>> breaks are replaces with gotos, indentation is reduced. >>> >>> Per Nate's request I am calling for people with SMP systems to test if powering >>> off via power button still works with this change. It's desirable to test power >>> off at least two times to increase a chance of non-BSP CPU being used. >> With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU) >> the first few shutdowns were successful, but on the fourth try pressing the >> power button only lead to: >> >> Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet) >> Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6) >> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet) >> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6) >> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet) >> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6) >> [...] > > Yes, I think the case for S5 should probably come before > acpi_sleep_disable(). Right now the patch tries to preserve the same behavior in this respect as the current code has. I don't have a good understanding of overlapping requests to enter different sleep states and potential bad effects (e.g. S1 request while soft power off is already in progress). But in this case I actually wonder what left ACPI driver is "sleep disabled" state. Did the first soft poweroff attempt fail and caused subsequent attempts to be disabled? Hmm, if so, then I wonder why it could have failed. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49EC60C6.7000702>