Date: Wed, 17 Nov 2010 01:09:16 +0000 From: Alexander Best <arundel@freebsd.org> To: Alexander Motin <mav@FreeBSD.org> Cc: Bruce Cran <bruce@cran.org.uk>, Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= <des@des.no>, Tijl Coosemans <tijl@coosemans.org>, Oliver Fromme <olli@lurza.secnetix.de>, freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off Message-ID: <20101117010916.GA73392@freebsd.org> In-Reply-To: <4CE319E3.4040705@FreeBSD.org> References: <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <4CC156F5.1050109@FreeBSD.org> <20101022100309.GA16446@freebsd.org> <20101116204000.00005aea@unknown> <20101116221725.GA49789@freebsd.org> <4CE3125E.1000307@FreeBSD.org> <20101116235051.GA62744@freebsd.org> <4CE319E3.4040705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed Nov 17 10, Alexander Motin wrote: > Alexander Best wrote: > > On Wed Nov 17 10, Alexander Motin wrote: > >> Alexander Best wrote: > >>> On Tue Nov 16 10, Bruce Cran wrote: > >>>> On Fri, 22 Oct 2010 10:03:09 +0000 > >>>> Alexander Best <arundel@freebsd.org> wrote: > >>>> > >>>>> so how about olivers patch? it will only apply to ata devices so it's > >>>>> garanteed not to break any other CAM devices (i'm thinking about the > >>>>> aac controller issue). you could revert your previous shutdown work > >>>>> and plug olivers patch into CAM. you might want to replace the > >>>>> combination of flush/standby immediate with sleep. > >>>> One problem with the code that's been committed is that the shutdown > >>>> event handler doesn't get run during a suspend operation so an > >>>> emergency unload still gets done when running "acpiconf -s3". > >>> unfortunately i don't think a can help you on that one. acpi never worked for > >>> me! even 'acpiconf -s1' will hopelessly crash my system. :( > >> It is not necessary to have fully working suspend to work on this. > >> Bounce mode should be enough. If bounce is also not working for you - it > >> definitely should be the first thing to fix. > > > > bounce mode? sorry i'm lost. > > sysctl debug.acpi.suspend_bounce=1 > > It will make system to wake up back immediately after suspending all > devices, instead of transition to requested S-state. thanks. i'll investigate a little bit regarding this issue. under single user mode 'acpiconf -s 1' works with and without bounce mode set. under multi user mode however both modes fail. i've made sure kldstat reports the same modules loaded both under single and multi user mode so it seems no module (i suspected nvidia.ko or rtc.ko) is causing the acpi issue in multi user mode. maybe HAL is causing problems. i'll check that out. cheers. alex > > -- > Alexander Motin -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101117010916.GA73392>