Re: Disk spin down issue on shut down/suspend to disk
On Sunday, 9 September 2007 11:20, Maciek Rutecki wrote: > Rafael J. Wysocki pisze: > >> Shutdown is completely broken on HP NX6??? laptops. > > > > It's not completely broken, it just handles disks incorrectly and we are not > > sure whether or not there are any serious consequences of that. Moreover, > > it has happened for a long time now, AFAICT, so that's not a regression. > > Maybe it isn't regression, we can call it no matter how, but this issue > can shorten disk live. Well, I'll try to carry out some experiments with it later today ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Rafael J. Wysocki pisze: >> Shutdown is completely broken on HP NX6??? laptops. > > It's not completely broken, it just handles disks incorrectly and we are not > sure whether or not there are any serious consequences of that. Moreover, > it has happened for a long time now, AFAICT, so that's not a regression. Maybe it isn't regression, we can call it no matter how, but this issue can shorten disk live. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Rafael J. Wysocki pisze: Shutdown is completely broken on HP NX6??? laptops. It's not completely broken, it just handles disks incorrectly and we are not sure whether or not there are any serious consequences of that. Moreover, it has happened for a long time now, AFAICT, so that's not a regression. Maybe it isn't regression, we can call it no matter how, but this issue can shorten disk live. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Sunday, 9 September 2007 11:20, Maciek Rutecki wrote: Rafael J. Wysocki pisze: Shutdown is completely broken on HP NX6??? laptops. It's not completely broken, it just handles disks incorrectly and we are not sure whether or not there are any serious consequences of that. Moreover, it has happened for a long time now, AFAICT, so that's not a regression. Maybe it isn't regression, we can call it no matter how, but this issue can shorten disk live. Well, I'll try to carry out some experiments with it later today ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Saturday, 8 September 2007 17:32, Michal Piotrowski wrote: > Hi, > > On 05/08/2007, Michał sed <[EMAIL PROTECTED]> wrote: > > Greetings > > > > I'm experiencing double disk spin down issue on my HP nx6310 laptop > > during shut down and suspend to disk. The drive is power down on "Will > > now halt message" then turned back on and off again with the laptop > > itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel > > along with Debian Unstable plus fixes from Sidux repository so I have > > the updated shut down script. I have also verified on two other > > systems [AMD/Nforce based] that the spin down issue has been resolved > > by the Sidux update and I'm certain that this is a hp bios bug or a > > piix kernel module problem. > > > > What is the _actual_ state of this bug? Does anyone work on this? > > I see the report > http://lkml.org/lkml/2007/8/5/214 > > and a very long thread > http://lkml.org/lkml/2007/8/6/4 > > dmidecode stuff > http://bugzilla.kernel.org/show_bug.cgi?id=8855 > > and _only_one_fix_ - for Suspend To Disc (thanks Rafael) > http://lkml.org/lkml/2007/8/7/316 There's an updated version of that patch at http://lkml.org/lkml/2007/8/27/392 > Shutdown is completely broken on HP NX6??? laptops. It's not completely broken, it just handles disks incorrectly and we are not sure whether or not there are any serious consequences of that. Moreover, it has happened for a long time now, AFAICT, so that's not a regression. BTW, in my opinion, we don't really understand why the patch at http://lkml.org/lkml/2007/8/27/392 actually helps and understanding that might allow us to fix the problem in general. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Saturday, 8 September 2007 17:32, Michal Piotrowski wrote: Hi, On 05/08/2007, Michał sed [EMAIL PROTECTED] wrote: Greetings I'm experiencing double disk spin down issue on my HP nx6310 laptop during shut down and suspend to disk. The drive is power down on Will now halt message then turned back on and off again with the laptop itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel along with Debian Unstable plus fixes from Sidux repository so I have the updated shut down script. I have also verified on two other systems [AMD/Nforce based] that the spin down issue has been resolved by the Sidux update and I'm certain that this is a hp bios bug or a piix kernel module problem. What is the _actual_ state of this bug? Does anyone work on this? I see the report http://lkml.org/lkml/2007/8/5/214 and a very long thread http://lkml.org/lkml/2007/8/6/4 dmidecode stuff http://bugzilla.kernel.org/show_bug.cgi?id=8855 and _only_one_fix_ - for Suspend To Disc (thanks Rafael) http://lkml.org/lkml/2007/8/7/316 There's an updated version of that patch at http://lkml.org/lkml/2007/8/27/392 Shutdown is completely broken on HP NX6??? laptops. It's not completely broken, it just handles disks incorrectly and we are not sure whether or not there are any serious consequences of that. Moreover, it has happened for a long time now, AFAICT, so that's not a regression. BTW, in my opinion, we don't really understand why the patch at http://lkml.org/lkml/2007/8/27/392 actually helps and understanding that might allow us to fix the problem in general. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote:
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote:
Hi!
firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system ("iasl ...") and syntactical
errors/warnings are printed out.
I also thought about a test, interpreting the DSDT and read out values
of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
not designed for that atm. You need to compile in most parts of the
acpica code and parse and interpret DSDT/SSDT code yourself in the
firmwarekit core or inside a plugin, then do a walk_namespace call or
whatever to find the functions/parts you like to examine. This is a lot
work and needs a proper design (providing an interface to plugins to let
them easily check specific AML/ASL code).
Furthermore, we don't really know what we're looking for. How can you
tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
trying to power the machine off? Adding to the fun, many modern ATA
controller have more than one way to issue a command. Maybe we can
match accesses inside regions specified by PCI BARs :-(
Hmmm... perhaps we should do it the other way. ACPI is allowed to
touch the embedded controller, what else? Maybe we should warn as soon
as API touches non-EC I/O port?
This is not working...
ACPI can and does access all kind of other I/O ports and other
resources.
Hmm, are the disk accesses done by ACPI via OperationRegion/Field
declared variables?
I try to get a check for those clashing with native drivers (hopefully
this approach is successful for 2.6.24, can't say for sure yet), I
wonder whether this one would give a warning like "Libata driver is
using the same SystemIO/SystemMem resources than ACPI OperationRegion
declaration XY".
This would not solve the problem, but at least show the need of such a
test. Such ACPI vs native driver interference problems are very hard
nuts (in identifying and solving).
Can someone post an ASL code snippet how ACPI actually access the disk
and in which parts/functions, pls.
Again, it's not believed that this is being done via AML, but via a BIOS
SMM trap on the ACPI sleep state hardware IO port. We have no real
ability to find out what the BIOS is doing or prevent it in this case.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote: Hi! firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Furthermore, we don't really know what we're looking for. How can you tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or trying to power the machine off? Adding to the fun, many modern ATA controller have more than one way to issue a command. Maybe we can match accesses inside regions specified by PCI BARs :-( Hmmm... perhaps we should do it the other way. ACPI is allowed to touch the embedded controller, what else? Maybe we should warn as soon as API touches non-EC I/O port? This is not working... ACPI can and does access all kind of other I/O ports and other resources. Hmm, are the disk accesses done by ACPI via OperationRegion/Field declared variables? I try to get a check for those clashing with native drivers (hopefully this approach is successful for 2.6.24, can't say for sure yet), I wonder whether this one would give a warning like Libata driver is using the same SystemIO/SystemMem resources than ACPI OperationRegion declaration XY. This would not solve the problem, but at least show the need of such a test. Such ACPI vs native driver interference problems are very hard nuts (in identifying and solving). Can someone post an ASL code snippet how ACPI actually access the disk and in which parts/functions, pls. Again, it's not believed that this is being done via AML, but via a BIOS SMM trap on the ACPI sleep state hardware IO port. We have no real ability to find out what the BIOS is doing or prevent it in this case. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote: > On Wednesday, 8 August 2007 04:56, Tejun Heo wrote: > > Rafael J. Wysocki wrote: > > > Well, on my box (nx6325) with the appended (experimental) patch applied > > > on top of 2.6.23-rc1 with the patchset from > > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , > > > the > > > double spin down doesn't occur during hibernation and the system is shut > > > down > > > notceably faster. > > > > Can you please explain what the patch does? > > It replaces the shutting down of devices done by kernel_shutdown_prepare() > with the suspending of the (just like before entering S3, but the target state > is now S4) and the shutting down of sysdevs with suspending them. > > It also disables the nonboot CPUs before entering the sleep state (S4), which > generally always is a good idea. > > In short, it makes hibernation_platform_enter() execute the > enter-a-sleep-state > sequence instead of the mixed shutdown-with-entering-S4 thing. > > > So, I take it that entering S4 also spins down the disk. > > Yes. > > > Does the patch remove the ACPI spin down or libata one? > > I _think_ that it removes the ACPI one, although I'll need to do some more > testing to confirm that. OK I can confirm that the patch removes the ACPI spin down (ie. the one that happens in the power down phase without the patch). Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Thursday, 9 August 2007 17:06, Pavel Machek wrote: > Hi! > > > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > > >> it spins down the disk correctly. Does emergency unload count increase > > >> after each power down? Also, please post the result of 'dmidecode'. > > > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > > games with the disk on ACPI power off (I assume it is putting the disk > > > in standby before power-off at least). It also does this if you boot > > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > > is dumb enough to spin up for sync cache and standby when there is > > > nothing to flush, and the kernel does its own standby, this could cause > > > an extra spinup/down.. > > > > Yeah, that seems to be what's going on. I don't think we have any other > > choice than blacklisting those notebooks. This is a mess. How does the > > other OS cope with this? > > > > I'm thinking about using DMI vendor/product match to detect the affected > > systems but I think it would be better to match the ACPI implementation > > directly. Is there a way to match specific ACPI implementation? > > Well.. unless they use some SMM trick, it is ACPI AML code telling > kernel to spin the disk down. I guess we could detect that, and simply > ignore the request. Please see: http://lkml.org/lkml/2007/8/8/187 Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote:
> Hi!
>
> > > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
> > > see: http://linuxfirmwarekit.org/
> > >
> > > But if I understand this problem right, this won't be easy.
> > > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > > errors/warnings are printed out.
> > > I also thought about a test, interpreting the DSDT and read out values
> > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > > not designed for that atm. You need to compile in most parts of the
> > > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > > whatever to find the functions/parts you like to examine. This is a lot
> > > work and needs a proper design (providing an interface to plugins to let
> > > them easily check specific AML/ASL code).
> >
> > Furthermore, we don't really know what we're looking for. How can you
> > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> > trying to power the machine off? Adding to the fun, many modern ATA
> > controller have more than one way to issue a command. Maybe we can
> > match accesses inside regions specified by PCI BARs :-(
>
> Hmmm... perhaps we should do it the other way. ACPI is allowed to
> touch the embedded controller, what else? Maybe we should warn as soon
> as API touches non-EC I/O port?
This is not working...
ACPI can and does access all kind of other I/O ports and other
resources.
Hmm, are the disk accesses done by ACPI via OperationRegion/Field
declared variables?
I try to get a check for those clashing with native drivers (hopefully
this approach is successful for 2.6.24, can't say for sure yet), I
wonder whether this one would give a warning like "Libata driver is
using the same SystemIO/SystemMem resources than ACPI OperationRegion
declaration XY".
This would not solve the problem, but at least show the need of such a
test. Such ACPI vs native driver interference problems are very hard
nuts (in identifying and solving).
Can someone post an ASL code snippet how ACPI actually access the disk
and in which parts/functions, pls.
Thanks,
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hi!
> > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
> > see: http://linuxfirmwarekit.org/
> >
> > But if I understand this problem right, this won't be easy.
> > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > errors/warnings are printed out.
> > I also thought about a test, interpreting the DSDT and read out values
> > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > not designed for that atm. You need to compile in most parts of the
> > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > whatever to find the functions/parts you like to examine. This is a lot
> > work and needs a proper design (providing an interface to plugins to let
> > them easily check specific AML/ASL code).
>
> Furthermore, we don't really know what we're looking for. How can you
> tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> trying to power the machine off? Adding to the fun, many modern ATA
> controller have more than one way to issue a command. Maybe we can
> match accesses inside regions specified by PCI BARs :-(
Hmmm... perhaps we should do it the other way. ACPI is allowed to
touch the embedded controller, what else? Maybe we should warn as soon
as API touches non-EC I/O port?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hi! > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > >> it spins down the disk correctly. Does emergency unload count increase > >> after each power down? Also, please post the result of 'dmidecode'. > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > games with the disk on ACPI power off (I assume it is putting the disk > > in standby before power-off at least). It also does this if you boot > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > is dumb enough to spin up for sync cache and standby when there is > > nothing to flush, and the kernel does its own standby, this could cause > > an extra spinup/down.. > > Yeah, that seems to be what's going on. I don't think we have any other > choice than blacklisting those notebooks. This is a mess. How does the > other OS cope with this? > > I'm thinking about using DMI vendor/product match to detect the affected > systems but I think it would be better to match the ACPI implementation > directly. Is there a way to match specific ACPI implementation? Well.. unless they use some SMM trick, it is ACPI AML code telling kernel to spin the disk down. I guess we could detect that, and simply ignore the request. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hi! Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Well.. unless they use some SMM trick, it is ACPI AML code telling kernel to spin the disk down. I guess we could detect that, and simply ignore the request. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hi! firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Furthermore, we don't really know what we're looking for. How can you tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or trying to power the machine off? Adding to the fun, many modern ATA controller have more than one way to issue a command. Maybe we can match accesses inside regions specified by PCI BARs :-( Hmmm... perhaps we should do it the other way. ACPI is allowed to touch the embedded controller, what else? Maybe we should warn as soon as API touches non-EC I/O port? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote: Hi! firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Furthermore, we don't really know what we're looking for. How can you tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or trying to power the machine off? Adding to the fun, many modern ATA controller have more than one way to issue a command. Maybe we can match accesses inside regions specified by PCI BARs :-( Hmmm... perhaps we should do it the other way. ACPI is allowed to touch the embedded controller, what else? Maybe we should warn as soon as API touches non-EC I/O port? This is not working... ACPI can and does access all kind of other I/O ports and other resources. Hmm, are the disk accesses done by ACPI via OperationRegion/Field declared variables? I try to get a check for those clashing with native drivers (hopefully this approach is successful for 2.6.24, can't say for sure yet), I wonder whether this one would give a warning like Libata driver is using the same SystemIO/SystemMem resources than ACPI OperationRegion declaration XY. This would not solve the problem, but at least show the need of such a test. Such ACPI vs native driver interference problems are very hard nuts (in identifying and solving). Can someone post an ASL code snippet how ACPI actually access the disk and in which parts/functions, pls. Thanks, Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Thursday, 9 August 2007 17:06, Pavel Machek wrote: Hi! Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Well.. unless they use some SMM trick, it is ACPI AML code telling kernel to spin the disk down. I guess we could detect that, and simply ignore the request. Please see: http://lkml.org/lkml/2007/8/8/187 Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote: On Wednesday, 8 August 2007 04:56, Tejun Heo wrote: Rafael J. Wysocki wrote: Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the double spin down doesn't occur during hibernation and the system is shut down notceably faster. Can you please explain what the patch does? It replaces the shutting down of devices done by kernel_shutdown_prepare() with the suspending of the (just like before entering S3, but the target state is now S4) and the shutting down of sysdevs with suspending them. It also disables the nonboot CPUs before entering the sleep state (S4), which generally always is a good idea. In short, it makes hibernation_platform_enter() execute the enter-a-sleep-state sequence instead of the mixed shutdown-with-entering-S4 thing. So, I take it that entering S4 also spins down the disk. Yes. Does the patch remove the ACPI spin down or libata one? I _think_ that it removes the ACPI one, although I'll need to do some more testing to confirm that. OK I can confirm that the patch removes the ACPI spin down (ie. the one that happens in the power down phase without the patch). Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: > Mark Lord wrote: > > Heh.. I haven't instrumented it yet, but I did discover a bit more about > > it: > > > > The Power-Off_Retract_Count incrmenents *only* when there's data in the > > on-drive write-cache. So if I haven't written anything significantly > > large before suspending, then it often does NOT increment the retract > > counter. > > > > But if I copy a couple of multi-MB files around and then suspend (to > > RAM), the retract count gets incremented. > > > > So I've now just stuck "hdparm -F /dev/sda" into my suspend script, > > and that cures the problem completely for me. "-F" does a FLUSH_CACHE, > > and requires a recent copy of hdparm. > > > > Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW > > command, prior to entering STR, which is what my script is currently now > > doing.. > > > > I'll instrument libata and see what the current sequence is. > > H.. libata should issue FLUSH CACHE on STR too. sd_suspend() and > sd_shutdown() are pretty similar after all. IMHO, this is a mess because we are essentially trying to work around firmware bugs, which may only be solved by having the kernel load a user-supplied shutdown sequence, instead of hardcoding it into the kernel. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Mark Lord wrote: Further to this, if I have an active-writer running at the time of suspend, then even my scripted "sleep 1" is not good enough, as additional writes are still happening before/after the flush. Now I'll reboot and try it with the "sleep 1" hardcoded inside sd_suspend(). Hmmm... queue quiescing might be broken. Can you verify there's no command issued between STANDBYNOW1 and suspending? Yeah, I verified that already. Nothing happens other than the FLUSH_CACHE_EXT and STANDBY commands. I've now tried adding various sleeps into the sd_suspend() routine. The sleeps actually do sleep, but they don't seem to solve the problem there. The "hdparm -F /dev/sda ; sleep 1" inside my script actually works better, though even it fails if there's a ton of writes happening. I put a 4-second sleep in front of the sd_start_stop_device() call, and here is what I observed: the disk light flickers briefly, then the system does absolutely nothing for the 4-seconds, and then it flickers again, and then the light comes on solid for a second or two, and then it suspends. I am confused now. :) We need Eric (from Seagate) to enlighten us. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: > Further to this, if I have an active-writer running at the time of suspend, > then even my scripted "sleep 1" is not good enough, as additional writes > are still happening before/after the flush. > > Now I'll reboot and try it with the "sleep 1" hardcoded inside > sd_suspend(). Hmmm... queue quiescing might be broken. Can you verify there's no command issued between STANDBYNOW1 and suspending? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: My suspend script now has this little chunk of code at the point where it actually does the suspend-to-RAM: sync; sync hdparm -F /dev/sda ## flush drive write cache sleep 1 ## allow time for the flush to complete echo mem > /sys/power/state ## suspend-to-RAM Without the "sleep 1", it doesn't always eliminate the extra Retract, so I hypothesize that the FLUSH_CACHE_EXT command is implemented in an asynchronous fashion by the drive: it returns immediately before it has actually completed writing cached data to disk. The "sleep 1" seems to give it enough time to finish up, at least for me. Further to this, if I have an active-writer running at the time of suspend, then even my scripted "sleep 1" is not good enough, as additional writes are still happening before/after the flush. Now I'll reboot and try it with the "sleep 1" hardcoded inside sd_suspend(). Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck "hdparm -F /dev/sda" into my suspend script, and that cures the problem completely for me. "-F" does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. Okay, instrumented it and all of that now. Yes, sd + libata-scsi send the proper FLUSH_CACHE_EXT and STANDBY1 commands immediately prior to the suspend-to-RAM, and there are no other commands sneaking through at the same time. Good. But the retract count still increments if I've recently written a signficant amount of data. My suspend script now has this little chunk of code at the point where it actually does the suspend-to-RAM: sync; sync hdparm -F /dev/sda ## flush drive write cache sleep 1 ## allow time for the flush to complete echo mem > /sys/power/state ## suspend-to-RAM Without the "sleep 1", it doesn't always eliminate the extra Retract, so I hypothesize that the FLUSH_CACHE_EXT command is implemented in an asynchronous fashion by the drive: it returns immediately before it has actually completed writing cached data to disk. The "sleep 1" seems to give it enough time to finish up, at least for me. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: > Heh.. I haven't instrumented it yet, but I did discover a bit more about > it: > > The Power-Off_Retract_Count incrmenents *only* when there's data in the > on-drive write-cache. So if I haven't written anything significantly large > before suspending, then it often does NOT increment the retract counter. > > But if I copy a couple of multi-MB files around and then suspend (to RAM), > the retract count gets incremented. > > So I've now just stuck "hdparm -F /dev/sda" into my suspend script, > and that cures the problem completely for me. "-F" does a FLUSH_CACHE, > and requires a recent copy of hdparm. > > Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, > prior to entering STR, which is what my script is currently now doing.. > > I'll instrument libata and see what the current sequence is. H.. libata should issue FLUSH CACHE on STR too. sd_suspend() and sd_shutdown() are pretty similar after all. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Mark Lord wrote: > Tejun Heo wrote: >> Michael Sedkowski wrote: >>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? >>> I think I got it. >>> Using smartctl I've done a test and shut down, then repeted the test. >>> The only values that where diffrent are temperatures and >>> Hardware_ECC_Recovered which rised by 6 points. >>> However I have no idea which of those is the "emergency count"... >>> Full results in attachment. >>> >>> 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age >>> Always - 388 >> >> I think this is the one. You can test it by forcefully powering off the >> machine (press power button for several secs or disconnect AC and >> battery) and see whether the count increases. > > FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) > increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation. > It does not do any double spin-up/spin-down things though. > > What a mess. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck "hdparm -F /dev/sda" into my suspend script, and that cures the problem completely for me. "-F" does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: > Tejun Heo wrote: >> Michael Sedkowski wrote: >>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? >>> I think I got it. >>> Using smartctl I've done a test and shut down, then repeted the test. >>> The only values that where diffrent are temperatures and >>> Hardware_ECC_Recovered which rised by 6 points. >>> However I have no idea which of those is the "emergency count"... >>> Full results in attachment. >>> >>> 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age >>> Always - 388 >> >> I think this is the one. You can test it by forcefully powering off the >> machine (press power button for several secs or disconnect AC and >> battery) and see whether the count increases. > > FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) > increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation. > It does not do any double spin-up/spin-down things though. > > What a mess. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the "emergency count"... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. What a mess. -ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 02:23, Robert Hancock wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> >>> On Tue, 07 Aug 2007, Tejun Heo wrote:
> Michael Sedkowski wrote:
> >> Hmmm... If the problem only shows up on nx6325, it might be that ACPI
> >> is
> >> pulling unnecessary stunt. Please apply the attached patch and report
> >> when the disk spins down and up.
> > Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> > "Power down".
> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> it spins down the disk correctly. Does emergency unload count increase
> after each power down? Also, please post the result of 'dmidecode'.
> >>> You know, this actually make a lot of sense, and one can't even complain
> >>> about firmware that pulls that off.
> >> Well, I'm complaining. I think the problem here is that it isn't clear
> >> which one is who's responsibility. There's a Korean saying which
> >
> > The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
> > about it. Doing it through ACPI ATA objects is at least non-broken as far
> > as these things go, as one knows when to do it directly ("non-ACPI mode"),
> > and one doesn't talk to the disk directly.
> >
> >> approximately translates into "if you have too many boatmen on a ship,
> >> it goes to mountain". We also have a bunch of Toshiba laptops which
> >
> > Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> > is asking us to deliver to the disks, which IMO is an extremely good idea
> > anyway.
>
> Problem is I don't think we can do this. As far as I can tell, on my
> Compaq at least, it's not being done through ACPI AML in the DSDT, like
> in the _PTS function (which the kernel executes and can snoop), but when
> we actually do the power-off we write a value to a magic ACPI register.
> That likely triggers the BIOS to take control in SMM mode and access the
> controller directly before triggering the power off, which we have no
> control or knowledge of.
Yes, this also is my observation.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 04:56, Tejun Heo wrote: > Rafael J. Wysocki wrote: > > Well, on my box (nx6325) with the appended (experimental) patch applied > > on top of 2.6.23-rc1 with the patchset from > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the > > double spin down doesn't occur during hibernation and the system is shut > > down > > notceably faster. > > Can you please explain what the patch does? It replaces the shutting down of devices done by kernel_shutdown_prepare() with the suspending of the (just like before entering S3, but the target state is now S4) and the shutting down of sysdevs with suspending them. It also disables the nonboot CPUs before entering the sleep state (S4), which generally always is a good idea. In short, it makes hibernation_platform_enter() execute the enter-a-sleep-state sequence instead of the mixed shutdown-with-entering-S4 thing. > So, I take it that entering S4 also spins down the disk. Yes. > Does the patch remove the ACPI spin down or libata one? I _think_ that it removes the ACPI one, although I'll need to do some more testing to confirm that. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 23:28 +0200, Maciej Rutecki napisał(a): > > > Well, on my box (nx6325) with the appended (experimental) patch applied > > > on top of 2.6.23-rc1 with the patchset from > > > > s/2.6.23-rc1/2.6.23-rc2/ > > > > HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: > > 1. Before: > rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep > Power-Off_Retract_Count > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 61 > > 2. Try suspend to disk, double spin down doesn't exist > > 3. Normal shutdown, double spin down exists, BUT NOTE: I have still > old shutdown utility from Debian package. > > 4. After: > rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep > Power-Off_Retract_Count > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 61 > > (it doesn't change=61). > > I wait for Michael, He has new shutdown from Sidux, and the same notebook. > Same here. On suspend to disk the problem disappeared, on shut down remained unchanged, although it is a bit faster. The emergency unload count remain unchanged. I have the updated shut down... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 23:28 +0200, Maciej Rutecki napisał(a): Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: 1. Before: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 2. Try suspend to disk, double spin down doesn't exist 3. Normal shutdown, double spin down exists, BUT NOTE: I have still old shutdown utility from Debian package. 4. After: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 (it doesn't change=61). I wait for Michael, He has new shutdown from Sidux, and the same notebook. Same here. On suspend to disk the problem disappeared, on shut down remained unchanged, although it is a bit faster. The emergency unload count remain unchanged. I have the updated shut down... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 04:56, Tejun Heo wrote: Rafael J. Wysocki wrote: Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the double spin down doesn't occur during hibernation and the system is shut down notceably faster. Can you please explain what the patch does? It replaces the shutting down of devices done by kernel_shutdown_prepare() with the suspending of the (just like before entering S3, but the target state is now S4) and the shutting down of sysdevs with suspending them. It also disables the nonboot CPUs before entering the sleep state (S4), which generally always is a good idea. In short, it makes hibernation_platform_enter() execute the enter-a-sleep-state sequence instead of the mixed shutdown-with-entering-S4 thing. So, I take it that entering S4 also spins down the disk. Yes. Does the patch remove the ACPI spin down or libata one? I _think_ that it removes the ACPI one, although I'll need to do some more testing to confirm that. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Wednesday, 8 August 2007 02:23, Robert Hancock wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. Problem is I don't think we can do this. As far as I can tell, on my Compaq at least, it's not being done through ACPI AML in the DSDT, like in the _PTS function (which the kernel executes and can snoop), but when we actually do the power-off we write a value to a magic ACPI register. That likely triggers the BIOS to take control in SMM mode and access the controller directly before triggering the power off, which we have no control or knowledge of. Yes, this also is my observation. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the emergency count... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the Power-Off_Retract_Count on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. What a mess. -ml - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: Tejun Heo wrote: Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the emergency count... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the Power-Off_Retract_Count on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. What a mess. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Mark Lord wrote: Tejun Heo wrote: Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the emergency count... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the Power-Off_Retract_Count on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. What a mess. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck hdparm -F /dev/sda into my suspend script, and that cures the problem completely for me. -F does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck hdparm -F /dev/sda into my suspend script, and that cures the problem completely for me. -F does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. H.. libata should issue FLUSH CACHE on STR too. sd_suspend() and sd_shutdown() are pretty similar after all. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook) increments the Power-Off_Retract_Count on each suspend-to-RAM operation. It does not do any double spin-up/spin-down things though. Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering STR. Can you instrument code a bit and see whether it actually gets issued? Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck hdparm -F /dev/sda into my suspend script, and that cures the problem completely for me. -F does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. Okay, instrumented it and all of that now. Yes, sd + libata-scsi send the proper FLUSH_CACHE_EXT and STANDBY1 commands immediately prior to the suspend-to-RAM, and there are no other commands sneaking through at the same time. Good. But the retract count still increments if I've recently written a signficant amount of data. My suspend script now has this little chunk of code at the point where it actually does the suspend-to-RAM: sync; sync hdparm -F /dev/sda ## flush drive write cache sleep 1 ## allow time for the flush to complete echo mem /sys/power/state ## suspend-to-RAM Without the sleep 1, it doesn't always eliminate the extra Retract, so I hypothesize that the FLUSH_CACHE_EXT command is implemented in an asynchronous fashion by the drive: it returns immediately before it has actually completed writing cached data to disk. The sleep 1 seems to give it enough time to finish up, at least for me. Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: My suspend script now has this little chunk of code at the point where it actually does the suspend-to-RAM: sync; sync hdparm -F /dev/sda ## flush drive write cache sleep 1 ## allow time for the flush to complete echo mem /sys/power/state ## suspend-to-RAM Without the sleep 1, it doesn't always eliminate the extra Retract, so I hypothesize that the FLUSH_CACHE_EXT command is implemented in an asynchronous fashion by the drive: it returns immediately before it has actually completed writing cached data to disk. The sleep 1 seems to give it enough time to finish up, at least for me. Further to this, if I have an active-writer running at the time of suspend, then even my scripted sleep 1 is not good enough, as additional writes are still happening before/after the flush. Now I'll reboot and try it with the sleep 1 hardcoded inside sd_suspend(). Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Mark Lord wrote: Further to this, if I have an active-writer running at the time of suspend, then even my scripted sleep 1 is not good enough, as additional writes are still happening before/after the flush. Now I'll reboot and try it with the sleep 1 hardcoded inside sd_suspend(). Hmmm... queue quiescing might be broken. Can you verify there's no command issued between STANDBYNOW1 and suspending? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Mark Lord wrote: Further to this, if I have an active-writer running at the time of suspend, then even my scripted sleep 1 is not good enough, as additional writes are still happening before/after the flush. Now I'll reboot and try it with the sleep 1 hardcoded inside sd_suspend(). Hmmm... queue quiescing might be broken. Can you verify there's no command issued between STANDBYNOW1 and suspending? Yeah, I verified that already. Nothing happens other than the FLUSH_CACHE_EXT and STANDBY commands. I've now tried adding various sleeps into the sd_suspend() routine. The sleeps actually do sleep, but they don't seem to solve the problem there. The hdparm -F /dev/sda ; sleep 1 inside my script actually works better, though even it fails if there's a ton of writes happening. I put a 4-second sleep in front of the sd_start_stop_device() call, and here is what I observed: the disk light flickers briefly, then the system does absolutely nothing for the 4-seconds, and then it flickers again, and then the light comes on solid for a second or two, and then it suspends. I am confused now. :) We need Eric (from Seagate) to enlighten us. Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Mark Lord wrote: Heh.. I haven't instrumented it yet, but I did discover a bit more about it: The Power-Off_Retract_Count incrmenents *only* when there's data in the on-drive write-cache. So if I haven't written anything significantly large before suspending, then it often does NOT increment the retract counter. But if I copy a couple of multi-MB files around and then suspend (to RAM), the retract count gets incremented. So I've now just stuck hdparm -F /dev/sda into my suspend script, and that cures the problem completely for me. -F does a FLUSH_CACHE, and requires a recent copy of hdparm. Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command, prior to entering STR, which is what my script is currently now doing.. I'll instrument libata and see what the current sequence is. H.. libata should issue FLUSH CACHE on STR too. sd_suspend() and sd_shutdown() are pretty similar after all. IMHO, this is a mess because we are essentially trying to work around firmware bugs, which may only be solved by having the kernel load a user-supplied shutdown sequence, instead of hardcoding it into the kernel. Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Robert Hancock wrote: You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on I am not so sure about that. Please correct me if I am wrong, but contact stop in an emergency retract shakes the head assembly badly as well. It subjects the head assembly to higher acceleration than a normal seek, and a nasty impulse at impact with the stopper. And I very much doubt it is nice to the heads to slide into the parking zone at high speed and hit the bumper while over it. Unless I missed something, I don't why an emergency retract would not be as big a problem as an emergency unload. Maybe we should hunt down some proper datasheets for drives lacking head load/unload technology, and check what they say about emergency unloads... I did a bit of a look and didn't find any mention of the subject for drives using contact start/stop. I did find mention that the unload torque needed is quite a bit higher on load/unload systems, so I would imagine that having to extract or store that energy for emergency unloads would be more of a demanding task and might be a rougher process. Just judging from the sound, though, hard power-offs on a desktop Seagate Barracuda 7200.10, for example, which is contact start/stop, don't really sound any different from a commanded standby. On the laptop drives I've seen you can really tell the difference. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Robert Hancock wrote: >> You *do* have to worry about it in any box you turn off daily. Desktop >> HDs will croak fast in that scenario, laptop HDs less so, but still too >> fast. A very good laptop HD can last about 20k emergency unloads (this >> is a unit that can do about 600k normal unloads in its lifetime). >> Desktop and server HDs don't even come close to those numbers, last time >> I checked. > > It only matters on hard drives which actually use load-unload heads. Lots > of desktop/server drives (perhaps some laptop ones as well) still use > contact start/stop, which doesn't remove the heads from the platters on I am not so sure about that. Please correct me if I am wrong, but contact stop in an emergency retract shakes the head assembly badly as well. It subjects the head assembly to higher acceleration than a normal seek, and a nasty impulse at impact with the stopper. And I very much doubt it is nice to the heads to slide into the parking zone at high speed and hit the bumper while over it. Unless I missed something, I don't why an emergency retract would not be as big a problem as an emergency unload. Maybe we should hunt down some proper datasheets for drives lacking head load/unload technology, and check what they say about emergency unloads... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Rafael J. Wysocki wrote: > Well, on my box (nx6325) with the appended (experimental) patch applied > on top of 2.6.23-rc1 with the patchset from > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the > double spin down doesn't occur during hibernation and the system is shut down > notceably faster. Can you please explain what the patch does? So, I take it that entering S4 also spins down the disk. Does the patch remove the ACPI spin down or libata one? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: > I did some additional checking today... > On kernels prior to 2.6.22 line, the bug exists and manifests itself > exactly the same way. However, when I removed the "-h" flag > from /etc/init.d/halt, the drive spins down only once on "Power down" > message and there is no sign of the bug and the emergency unload count > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; > 2.6.18-4-686-Etch. > The obvious conclusion is that something must have changed it the 2.6.22 > kernels, so that removing the "-h" has no effect. > I dunno if my observations are of any value, but I thought You should > know... Yeah, till 2.6.22, libata didn't spindown disks on suspend or power off which incremented emergency unload count on all normal systems, so only the ACPI S5 routine is spinning down the disk on you system. The problem here is that now that libata is fixed there are two entities trying to spin down the disk and the disk is dumb enough to spin back up when FLUSH CACHE or STANDBYNOW is received while spun down. :-( Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
Disk spins down on "Pre-shutdown prepare" and then goes up and down on
"Power down".
Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
You know, this actually make a lot of sense, and one can't even complain
about firmware that pulls that off.
Well, I'm complaining. I think the problem here is that it isn't clear
which one is who's responsibility. There's a Korean saying which
The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
about it. Doing it through ACPI ATA objects is at least non-broken as far
as these things go, as one knows when to do it directly ("non-ACPI mode"),
and one doesn't talk to the disk directly.
approximately translates into "if you have too many boatmen on a ship,
it goes to mountain". We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
is asking us to deliver to the disks, which IMO is an extremely good idea
anyway.
Problem is I don't think we can do this. As far as I can tell, on my
Compaq at least, it's not being done through ACPI AML in the DSDT, like
in the _PTS function (which the kernel executes and can snoop), but when
we actually do the power-off we write a value to a magic ACPI register.
That likely triggers the BIOS to take control in SMM mode and access the
controller directly before triggering the power off, which we have no
control or knowledge of.
want the ATA controller to be in enabled state when ACPI suspend is
invoked because the suspend method apparently wants to execute some
commands before going to sleep.
That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
method to do it.
I wish ACPI spec carries a big fat sign saying "stay f*** away from
anything which isn't essential to the requested operation".
Shutting down disks *is* essential to the power off operation. ACPI would
have to mandate who is to do it, instead (ACPI table or OSI by itself).
Any chances of changing things
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?
No, we can't unless we snoop ACPI method execution and detect accesses
to IO ports or iomem regions. It's not going through any driver. This
is a gross mess.
I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
that is to blacklist the hell out of that crap and patch their DSDT into
something remotely sane.
I do mean snooping the ACPI methods that *return* a taskset to send to the
driver, and we send that taskset ourselves in libata and libpata(?).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on shutdown but just parks the heads over the landing zone. I don't think arbitrary power-offs make too much difference on those drives. (However, these generally aren't rated to handle as many start/stop cycles, which is why laptop drives generally use load/unload instead.) -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 23:28, Maciej Rutecki wrote: > > > Well, on my box (nx6325) with the appended (experimental) patch applied > > > on top of 2.6.23-rc1 with the patchset from > > > > s/2.6.23-rc1/2.6.23-rc2/ > > > > HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: > > 1. Before: > rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep > Power-Off_Retract_Count > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 61 > > 2. Try suspend to disk, double spin down doesn't exist > > 3. Normal shutdown, double spin down exists, BUT NOTE: I have still > old shutdown utility from Debian package. I should have said explicitly that my patch only affects hibernation (it doesn't touch the normal shutdown code path). Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
> > Well, on my box (nx6325) with the appended (experimental) patch applied > > on top of 2.6.23-rc1 with the patchset from > > s/2.6.23-rc1/2.6.23-rc2/ > HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: 1. Before: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 2. Try suspend to disk, double spin down doesn't exist 3. Normal shutdown, double spin down exists, BUT NOTE: I have still old shutdown utility from Debian package. 4. After: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 (it doesn't change=61). I wait for Michael, He has new shutdown from Sidux, and the same notebook. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 22:33, Rafael J. Wysocki wrote: > On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote: > > 2007/8/7, Michael Sedkowski <[EMAIL PROTECTED]>: > > > I did some additional checking today... > > > On kernels prior to 2.6.22 line, the bug exists and manifests itself > > > exactly the same way. However, when I removed the "-h" flag > > > from /etc/init.d/halt, the drive spins down only once on "Power down" > > > message and there is no sign of the bug and the emergency unload count > > > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; > > > 2.6.18-4-686-Etch. > > > The obvious conclusion is that something must have changed it the 2.6.22 > > > kernels, so that removing the "-h" has no effect. > > > I dunno if my observations are of any value, but I thought You should > > > know... > > > > I confirm this. First 2.6.21-rcx works OK (if I remember). In > > 2.6.22(.1) remove -h option doesn't help - only warning message > > dissapear, and double spin down also exists in suspend to disk. > > Well, on my box (nx6325) with the appended (experimental) patch applied > on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
> 2007/8/7, Michael Sedkowski <[EMAIL PROTECTED]>:
> > I did some additional checking today...
> > On kernels prior to 2.6.22 line, the bug exists and manifests itself
> > exactly the same way. However, when I removed the "-h" flag
> > from /etc/init.d/halt, the drive spins down only once on "Power down"
> > message and there is no sign of the bug and the emergency unload count
> > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> > 2.6.18-4-686-Etch.
> > The obvious conclusion is that something must have changed it the 2.6.22
> > kernels, so that removing the "-h" has no effect.
> > I dunno if my observations are of any value, but I thought You should
> > know...
>
> I confirm this. First 2.6.21-rcx works OK (if I remember). In
> 2.6.22(.1) remove -h option doesn't help - only warning message
> dissapear, and double spin down also exists in suspend to disk.
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
double spin down doesn't occur during hibernation and the system is shut down
notceably faster.
Greetings,
Rafael
---
kernel/power/disk.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc2/kernel/power/disk.c
===
--- linux-2.6.23-rc2.orig/kernel/power/disk.c 2007-08-06 14:04:07.0
+0200
+++ linux-2.6.23-rc2/kernel/power/disk.c2007-08-07 21:10:59.0
+0200
@@ -223,15 +223,23 @@ int hibernation_platform_enter(void)
int error;
if (hibernation_ops) {
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
/*
* We have cancelled the power transition by running
* hibernation_ops->finish() before saving the image, so we
* should let the firmware know that we're going to enter the
* sleep state after all
*/
- error = hibernation_ops->prepare();
- sysdev_shutdown();
+ error = hibernation_ops->start();
+ if (!error) {
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ }
+ if (!error)
+ error = hibernation_ops->prepare();
+ if (!error)
+ error = disable_nonboot_cpus();
+ if (!error)
+ error = device_power_down(PMSG_SUSPEND);
if (!error)
error = hibernation_ops->enter();
} else {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
2007/8/7, Michael Sedkowski <[EMAIL PROTECTED]>: > I did some additional checking today... > On kernels prior to 2.6.22 line, the bug exists and manifests itself > exactly the same way. However, when I removed the "-h" flag > from /etc/init.d/halt, the drive spins down only once on "Power down" > message and there is no sign of the bug and the emergency unload count > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; > 2.6.18-4-686-Etch. > The obvious conclusion is that something must have changed it the 2.6.22 > kernels, so that removing the "-h" has no effect. > I dunno if my observations are of any value, but I thought You should > know... I confirm this. First 2.6.21-rcx works OK (if I remember). In 2.6.22(.1) remove -h option doesn't help - only warning message dissapear, and double spin down also exists in suspend to disk. The same laptop, bios, Debian etc. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the "-h" flag from /etc/init.d/halt, the drive spins down only once on "Power down" message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the "-h" has no effect. I dunno if my observations are of any value, but I thought You should know... Regards, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote: > Robert Hancock wrote: > > Tejun Heo wrote: > >> Michael Sedkowski wrote: > Hmmm... If the problem only shows up on nx6325, it might be that > ACPI is > pulling unnecessary stunt. Please apply the attached patch and report > when the disk spins down and up. > >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on > >>> "Power down". > >> > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > >> it spins down the disk correctly. Does emergency unload count increase > >> after each power down? Also, please post the result of 'dmidecode'. > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > games with the disk on ACPI power off (I assume it is putting the disk > > in standby before power-off at least). It also does this if you boot > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > is dumb enough to spin up for sync cache and standby when there is > > nothing to flush, and the kernel does its own standby, this could cause > > an extra spinup/down.. > > Yeah, that seems to be what's going on. I don't think we have any other > choice than blacklisting those notebooks. This is a mess. How does the > other OS cope with this? > > I'm thinking about using DMI vendor/product match to detect the affected > systems but I think it would be better to match the ACPI implementation > directly. Is there a way to match specific ACPI implementation? I opened a new bug to collect dmi and acpidump outputs: http://bugzilla.kernel.org/show_bug.cgi?id=8855 Thought this is the easiest way to get this all a bit together. Would be great if you tell all affected people and let them attach dmidecode and acpidump output there... Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Robert Hancock wrote: > Tejun Heo wrote: >> Yeah, that seems to be what's going on. I don't think we have any other >> choice than blacklisting those notebooks. This is a mess. How does the >> other OS cope with this? > > Quite possible that it gets a double spindown with these laptop/drive > combinations as well. I don't think it's particularly harmful as long as > there's no emergency unload.. I heard that spinning a harddrive back up while the platter is still spinning from the previous spindown can have pretty bad affect on the harddisk. This is from a Samsung HDD service guy and I'm not sure how credible it is at all. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on "Pre-shutdown prepare" and then goes up and down on "Power down". Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? Quite possible that it gets a double spindown with these laptop/drive combinations as well. I don't think it's particularly harmful as long as there's no emergency unload.. I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Don't think it would be very easy, it's presumably being done off some SMI code triggered from the ACPI power off register or something, so I'm assuming it's nothing the kernel sees in its ACPI tables.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote:
>>> I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
>>> doing this. Who should we prod to add that check?
>> Dunno how the firmware toolkit works but this one can be pretty
>> difficult to test (if it were easy, we could test it in libata) as it
>> involves entering S5. If it's possible, I'm all for it. Also, it would
>> be nice if we can test the same thing for S3 and S4.
>>
>> Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
>
> firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
> see: http://linuxfirmwarekit.org/
>
> But if I understand this problem right, this won't be easy.
> The ACPI tables are just parsed with system ("iasl ...") and syntactical
> errors/warnings are printed out.
> I also thought about a test, interpreting the DSDT and read out values
> of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> not designed for that atm. You need to compile in most parts of the
> acpica code and parse and interpret DSDT/SSDT code yourself in the
> firmwarekit core or inside a plugin, then do a walk_namespace call or
> whatever to find the functions/parts you like to examine. This is a lot
> work and needs a proper design (providing an interface to plugins to let
> them easily check specific AML/ASL code).
Furthermore, we don't really know what we're looking for. How can you
tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
trying to power the machine off? Adding to the fun, many modern ATA
controller have more than one way to issue a command. Maybe we can
match accesses inside regions specified by PCI BARs :-(
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> approximately translates into "if you have too many boatmen on a ship,
> it goes to mountain". We also have a bunch of Toshiba laptops which
> >>> Yeah, that's a problem. But we can avoid it if we start snooping what
> >>> ACPI
> >>> is asking us to deliver to the disks, which IMO is an extremely good idea
> >>> anyway.
> >> If it were done that way (by asking OS driver to deliver commands TFs),
> >> I wouldn't have any problem at all. The spin down command is issued
> >> from deep down in the acpi power off method - entering S5 directly
> >> issues ATA commands bypassing the whole OS except for the ACPI
> >> interpreter. It's just like the toshiba suspend crap and there's no
> >> standard way to tell whether the acpi power off method is gonna do it or
> >> not. We'll just have to blacklist it.
> >
> > Urk. I see.
> >
> > I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
> > doing this. Who should we prod to add that check?
>
> Dunno how the firmware toolkit works but this one can be pretty
> difficult to test (if it were easy, we could test it in libata) as it
> involves entering S5. If it's possible, I'm all for it. Also, it would
> be nice if we can test the same thing for S3 and S4.
>
> Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system ("iasl ...") and syntactical
errors/warnings are printed out.
I also thought about a test, interpreting the DSDT and read out values
of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
not designed for that atm. You need to compile in most parts of the
acpica code and parse and interpret DSDT/SSDT code yourself in the
firmwarekit core or inside a plugin, then do a walk_namespace call or
whatever to find the functions/parts you like to examine. This is a lot
work and needs a proper design (providing an interface to plugins to let
them easily check specific AML/ASL code).
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? >>> No, we can't unless we snoop ACPI method execution and detect accesses >>> to IO ports or iomem regions. It's not going through any driver. This >>> is a gross mess. >> I don't mean fixing the stuff clowns like Toshiba did. The correct fix for >> that is to blacklist the hell out of that crap and patch their DSDT into >> something remotely sane. >> >> I do mean snooping the ACPI methods that *return* a taskset to send to the >> driver, and we send that taskset ourselves in libata and libpata(?). > > I haven't read the whole thread in every detail, but this sounds like a > very intrusive, overdosed workaround. > > Are the DSDT/SSDTs already lying around somewhere (collecting them in a > bug assigned to ACPI component should be a good idea)? > Could someone give me a pointer where this happens (best in code and > DSDT). The toshiba problem is already taken care of. It's the issue that we talked over beer. Let me look up the bug number... It's 7780. http://bugzilla.kernel.org/show_bug.cgi?id=7780 This was worked around by blacklisting the systems using dmi. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: > On Tue, 07 Aug 2007, Tejun Heo wrote: >> Henrique de Moraes Holschuh wrote: approximately translates into "if you have too many boatmen on a ship, it goes to mountain". We also have a bunch of Toshiba laptops which >>> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI >>> is asking us to deliver to the disks, which IMO is an extremely good idea >>> anyway. >> If it were done that way (by asking OS driver to deliver commands TFs), >> I wouldn't have any problem at all. The spin down command is issued >> from deep down in the acpi power off method - entering S5 directly >> issues ATA commands bypassing the whole OS except for the ACPI >> interpreter. It's just like the toshiba suspend crap and there's no >> standard way to tell whether the acpi power off method is gonna do it or >> not. We'll just have to blacklist it. > > Urk. I see. > > I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT > doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: > Henrique de Moraes Holschuh wrote: > >> approximately translates into "if you have too many boatmen on a ship, > >> it goes to mountain". We also have a bunch of Toshiba laptops which > > > > Yeah, that's a problem. But we can avoid it if we start snooping what ACPI > > is asking us to deliver to the disks, which IMO is an extremely good idea > > anyway. > > If it were done that way (by asking OS driver to deliver commands TFs), > I wouldn't have any problem at all. The spin down command is issued > from deep down in the acpi power off method - entering S5 directly > issues ATA commands bypassing the whole OS except for the ACPI > interpreter. It's just like the toshiba suspend crap and there's no > standard way to tell whether the acpi power off method is gonna do it or > not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hello, Henrique. Henrique de Moraes Holschuh wrote: >> approximately translates into "if you have too many boatmen on a ship, >> it goes to mountain". We also have a bunch of Toshiba laptops which > > Yeah, that's a problem. But we can avoid it if we start snooping what ACPI > is asking us to deliver to the disks, which IMO is an extremely good idea > anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote: > On Tue, 07 Aug 2007, Tejun Heo wrote: > > Henrique de Moraes Holschuh wrote: > > > On Tue, 07 Aug 2007, Tejun Heo wrote: > > >> Michael Sedkowski wrote: ---snip--- > > > Any chances of changing things > > > so that we inspect/snoop all tasks sent to the device, and filter them > > > out, or react to them accordingly? > > > > No, we can't unless we snoop ACPI method execution and detect accesses > > to IO ports or iomem regions. It's not going through any driver. This > > is a gross mess. > > I don't mean fixing the stuff clowns like Toshiba did. The correct fix for > that is to blacklist the hell out of that crap and patch their DSDT into > something remotely sane. > > I do mean snooping the ACPI methods that *return* a taskset to send to the > driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: > emergency unload. Emergency unload does shorten the lifespan of the > disk but you don't have to worry too much about it. Disks are designed > to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Michael Sedkowski wrote:
> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> pulling unnecessary stunt. Please apply the attached patch and report
> when the disk spins down and up.
> >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> >>> "Power down".
> >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> >> it spins down the disk correctly. Does emergency unload count increase
> >> after each power down? Also, please post the result of 'dmidecode'.
> >
> > You know, this actually make a lot of sense, and one can't even complain
> > about firmware that pulls that off.
>
> Well, I'm complaining. I think the problem here is that it isn't clear
> which one is who's responsibility. There's a Korean saying which
The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
about it. Doing it through ACPI ATA objects is at least non-broken as far
as these things go, as one knows when to do it directly ("non-ACPI mode"),
and one doesn't talk to the disk directly.
> approximately translates into "if you have too many boatmen on a ship,
> it goes to mountain". We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
is asking us to deliver to the disks, which IMO is an extremely good idea
anyway.
> want the ATA controller to be in enabled state when ACPI suspend is
> invoked because the suspend method apparently wants to execute some
> commands before going to sleep.
That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
method to do it.
> I wish ACPI spec carries a big fat sign saying "stay f*** away from
> anything which isn't essential to the requested operation".
Shutting down disks *is* essential to the power off operation. ACPI would
have to mandate who is to do it, instead (ACPI table or OSI by itself).
> > Any chances of changing things
> > so that we inspect/snoop all tasks sent to the device, and filter them
> > out, or react to them accordingly?
>
> No, we can't unless we snoop ACPI method execution and detect accesses
> to IO ports or iomem regions. It's not going through any driver. This
> is a gross mess.
I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
that is to blacklist the hell out of that crap and patch their DSDT into
something remotely sane.
I do mean snooping the ACPI methods that *return* a taskset to send to the
driver, and we send that taskset ourselves in libata and libpata(?).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: > Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): >> 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age >> Always - 388 >> >> I think this is the one. You can test it by forcefully powering off >> the >> machine (press power button for several secs or disconnect AC and >> battery) and see whether the count increases. >> > When I forcefully power off using the power button the raw value [last > one] rise by 1 point from 389 to 390. When I power off normally with > linux it remains constant. > Now could some one please explain to me what does that mean and am I in > danger of data loss? So, the ACPI routine puts the disk into the standby mode before powering off. That's good. On power off, the r/w heads in a disk should be unloaded (parked). This is usually achieved by either putting the disk into standby/sleep mode during shutdown. However, all modern disks can automatically unload their heads when the power is removed abruptly. This is called emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): > You can test it by forcefully powering off the > machine (press power button for several secs or disconnect AC and > battery) and see whether the count increases. Forgot to mention that double spin down does not happen when the laptop is powered down forcefully and as my friend described who has te same model it "sounds right"... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 388 > > I think this is the one. You can test it by forcefully powering off > the > machine (press power button for several secs or disconnect AC and > battery) and see whether the count increases. > When I forcefully power off using the power button the raw value [last one] rise by 1 point from 389 to 390. When I power off normally with linux it remains constant. Now could some one please explain to me what does that mean and am I in danger of data loss? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: > Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): >> Does emergency unload count increase >> after each power down? > > I think I got it. > Using smartctl I've done a test and shut down, then repeted the test. > The only values that where diffrent are temperatures and > Hardware_ECC_Recovered which rised by 6 points. > However I have no idea which of those is the "emergency count"... > Full results in attachment. > > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always > - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: > On Tue, 07 Aug 2007, Tejun Heo wrote: >> Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on >>> "Power down". >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether >> it spins down the disk correctly. Does emergency unload count increase >> after each power down? Also, please post the result of 'dmidecode'. > > You know, this actually make a lot of sense, and one can't even complain > about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which approximately translates into "if you have too many boatmen on a ship, it goes to mountain". We also have a bunch of Toshiba laptops which want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. I wish ACPI spec carries a big fat sign saying "stay f*** away from anything which isn't essential to the requested operation". > Any chances of changing things > so that we inspect/snoop all tasks sent to the device, and filter them > out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Robert Hancock wrote: > Tejun Heo wrote: >> Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on >>> "Power down". >> >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether >> it spins down the disk correctly. Does emergency unload count increase >> after each power down? Also, please post the result of 'dmidecode'. > > I know that my Compaq X1000-series laptop does do some kind of ACPI > games with the disk on ACPI power off (I assume it is putting the disk > in standby before power-off at least). It also does this if you boot > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > is dumb enough to spin up for sync cache and standby when there is > nothing to flush, and the kernel does its own standby, this could cause > an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the emergency count... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. When I forcefully power off using the power button the raw value [last one] rise by 1 point from 389 to 390. When I power off normally with linux it remains constant. Now could some one please explain to me what does that mean and am I in danger of data loss? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. Forgot to mention that double spin down does not happen when the laptop is powered down forcefully and as my friend described who has te same model it sounds right... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. When I forcefully power off using the power button the raw value [last one] rise by 1 point from 389 to 390. When I power off normally with linux it remains constant. Now could some one please explain to me what does that mean and am I in danger of data loss? So, the ACPI routine puts the disk into the standby mode before powering off. That's good. On power off, the r/w heads in a disk should be unloaded (parked). This is usually achieved by either putting the disk into standby/sleep mode during shutdown. However, all modern disks can automatically unload their heads when the power is removed abruptly. This is called emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. That's just broken, since it is not even using a OS-backed SATA/ATA ACPI method to do it. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Shutting down disks *is* essential to the power off operation. ACPI would have to mandate who is to do it, instead (ACPI table or OSI by itself). Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: ---snip--- Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). Thanks, Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Hello, Henrique. Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). The toshiba problem is already taken care of. It's the issue that we talked over beer. Let me look up the bug number... It's 7780. http://bugzilla.kernel.org/show_bug.cgi?id=7780 This was worked around by blacklisting the systems using dmi. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Furthermore, we don't really know what we're looking for. How can you tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or trying to power the machine off? Adding to the fun, many modern ATA controller have more than one way to issue a command. Maybe we can match accesses inside regions specified by PCI BARs :-( -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? Quite possible that it gets a double spindown with these laptop/drive combinations as well. I don't think it's particularly harmful as long as there's no emergency unload.. I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Don't think it would be very easy, it's presumably being done off some SMI code triggered from the ACPI power off register or something, so I'm assuming it's nothing the kernel sees in its ACPI tables.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Robert Hancock wrote: Tejun Heo wrote: Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? Quite possible that it gets a double spindown with these laptop/drive combinations as well. I don't think it's particularly harmful as long as there's no emergency unload.. I heard that spinning a harddrive back up while the platter is still spinning from the previous spindown can have pretty bad affect on the harddisk. This is from a Samsung HDD service guy and I'm not sure how credible it is at all. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote: Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? I opened a new bug to collect dmi and acpidump outputs: http://bugzilla.kernel.org/show_bug.cgi?id=8855 Thought this is the easiest way to get this all a bit together. Would be great if you tell all affected people and let them attach dmidecode and acpidump output there... Thanks, Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... Regards, Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]: I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... I confirm this. First 2.6.21-rcx works OK (if I remember). In 2.6.22(.1) remove -h option doesn't help - only warning message dissapear, and double spin down also exists in suspend to disk. The same laptop, bios, Debian etc. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]:
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from /etc/init.d/halt, the drive spins down only once on Power down
message and there is no sign of the bug and the emergency unload count
remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
2.6.18-4-686-Etch.
The obvious conclusion is that something must have changed it the 2.6.22
kernels, so that removing the -h has no effect.
I dunno if my observations are of any value, but I thought You should
know...
I confirm this. First 2.6.21-rcx works OK (if I remember). In
2.6.22(.1) remove -h option doesn't help - only warning message
dissapear, and double spin down also exists in suspend to disk.
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
double spin down doesn't occur during hibernation and the system is shut down
notceably faster.
Greetings,
Rafael
---
kernel/power/disk.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc2/kernel/power/disk.c
===
--- linux-2.6.23-rc2.orig/kernel/power/disk.c 2007-08-06 14:04:07.0
+0200
+++ linux-2.6.23-rc2/kernel/power/disk.c2007-08-07 21:10:59.0
+0200
@@ -223,15 +223,23 @@ int hibernation_platform_enter(void)
int error;
if (hibernation_ops) {
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
/*
* We have cancelled the power transition by running
* hibernation_ops-finish() before saving the image, so we
* should let the firmware know that we're going to enter the
* sleep state after all
*/
- error = hibernation_ops-prepare();
- sysdev_shutdown();
+ error = hibernation_ops-start();
+ if (!error) {
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ }
+ if (!error)
+ error = hibernation_ops-prepare();
+ if (!error)
+ error = disable_nonboot_cpus();
+ if (!error)
+ error = device_power_down(PMSG_SUSPEND);
if (!error)
error = hibernation_ops-enter();
} else {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 22:33, Rafael J. Wysocki wrote: On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote: 2007/8/7, Michael Sedkowski [EMAIL PROTECTED]: I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... I confirm this. First 2.6.21-rcx works OK (if I remember). In 2.6.22(.1) remove -h option doesn't help - only warning message dissapear, and double spin down also exists in suspend to disk. Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: 1. Before: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 2. Try suspend to disk, double spin down doesn't exist 3. Normal shutdown, double spin down exists, BUT NOTE: I have still old shutdown utility from Debian package. 4. After: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 (it doesn't change=61). I wait for Michael, He has new shutdown from Sidux, and the same notebook. -- Maciej Rutecki http://www.maciek.unixy.pl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 23:28, Maciej Rutecki wrote: Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: 1. Before: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 2. Try suspend to disk, double spin down doesn't exist 3. Normal shutdown, double spin down exists, BUT NOTE: I have still old shutdown utility from Debian package. I should have said explicitly that my patch only affects hibernation (it doesn't touch the normal shutdown code path). Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on shutdown but just parks the heads over the landing zone. I don't think arbitrary power-offs make too much difference on those drives. (However, these generally aren't rated to handle as many start/stop cycles, which is why laptop drives generally use load/unload instead.) -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. Problem is I don't think we can do this. As far as I can tell, on my Compaq at least, it's not being done through ACPI AML in the DSDT, like in the _PTS function (which the kernel executes and can snoop), but when we actually do the power-off we write a value to a magic ACPI register. That likely triggers the BIOS to take control in SMM mode and access the controller directly before triggering the power off, which we have no control or knowledge of. want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. That's just broken, since it is not even using a OS-backed SATA/ATA ACPI method to do it. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Shutting down disks *is* essential to the power off operation. ACPI would have to mandate who is to do it, instead (ACPI table or OSI by itself). Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... Yeah, till 2.6.22, libata didn't spindown disks on suspend or power off which incremented emergency unload count on all normal systems, so only the ACPI S5 routine is spinning down the disk on you system. The problem here is that now that libata is fixed there are two entities trying to spin down the disk and the disk is dumb enough to spin back up when FLUSH CACHE or STANDBYNOW is received while spun down. :-( Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk spin down issue on shut down/suspend to disk
Rafael J. Wysocki wrote: Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the double spin down doesn't occur during hibernation and the system is shut down notceably faster. Can you please explain what the patch does? So, I take it that entering S4 also spins down the disk. Does the patch remove the ACPI spin down or libata one? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
