Date: Mon, 20 Apr 2009 09:05:03 -0700 From: Nate Lawson <nate@root.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: run resume code only for S1-S4 states Message-ID: <49EC9D2F.8080701@root.org> In-Reply-To: <49EC60C6.7000702@freebsd.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> <49EC60C6.7000702@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > 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. It's a good question. Better to figure out why the first poweroff failed. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49EC9D2F.8080701>