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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Some additional info: As I stated before I'm using a patched sysvinit package with patch from Debian bug 426224 with provide a patched hddown.c. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 Michael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. -- 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh napisał(a): On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. Well there is an -h variable: # Don't shut down drives if we're using RAID. hddown=-h if grep -qs '^md.*active' /proc/mdstat then hddown= fi log_action_msg Will now halt halt -d -f $netdown $poweroff $hddown However removing it has no effect, the drive still spins down two times. Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 Michael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Mon, 06 Aug 2007, Michael Sedkowski wrote: Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh napisa??(a): On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. Well there is an -h variable: # Don't shut down drives if we're using RAID. hddown=-h if grep -qs '^md.*active' /proc/mdstat then hddown= fi log_action_msg Will now halt halt -d -f $netdown $poweroff $hddown However removing it has no effect, the drive still spins down two times. Nothing in Debian userspace will spin down the drive if you kill that -h, at least as far as I know. Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. -- 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Monday, 6 August 2007 17:01, Henrique de Moraes Holschuh wrote: On Mon, 06 Aug 2007, Michael Sedkowski wrote: Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh napisa??(a): On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. Well there is an -h variable: # Don't shut down drives if we're using RAID. hddown=-h if grep -qs '^md.*active' /proc/mdstat then hddown= fi log_action_msg Will now halt halt -d -f $netdown $poweroff $hddown However removing it has no effect, the drive still spins down two times. Nothing in Debian userspace will spin down the drive if you kill that -h, at least as far as I know. Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. Well, I've been observing the same behavior on nx6325 for some time and I use openSUSE 10.2. I think this is kernel-related. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Dnia 06-08-2007, Pn o godzinie 12:01 -0300, Henrique de Moraes Holschuh napisał(a): On Mon, 06 Aug 2007, Michael Sedkowski wrote: Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh napisa??(a): On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. Well there is an -h variable: # Don't shut down drives if we're using RAID. hddown=-h if grep -qs '^md.*active' /proc/mdstat then hddown= fi log_action_msg Will now halt halt -d -f $netdown $poweroff $hddown However removing it has no effect, the drive still spins down two times. Nothing in Debian userspace will spin down the drive if you kill that -h, at least as far as I know. Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. The double spin down problem occurs not only on Sidux, but on all distros that I isued like Fedora 7, Mandriva, Debian or Ubuntu with kernels ranging from 2.6.18 to 2.6.22. I only use the Sidux because they released the shut down patch required to shut down properly on the 2.6.22 kernel line and on two other systems the drives are turned off nicely [standard Debian still runs on the old shut down scripts. On that basis I believe that this is a HP (Intel?) issue not related to any particular distro. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Rafael J. Wysocki wrote:
Sidux is a Debian Unstable based distro with it's own set of patches
including the shut down patch provided here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
You'll probably have to ask Sidux what changes they made that could cause
the double spin down, even if halt(8) is never passed the -h flag.
Well, I've been observing the same behavior on nx6325 for some time and I
use openSUSE 10.2. I think this is kernel-related.
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.
Thanks.
--
tejun
diff --git a/kernel/sys.c b/kernel/sys.c
index 449b81b..9578e3f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -875,10 +875,20 @@ EXPORT_SYMBOL_GPL(kernel_halt);
*/
void kernel_power_off(void)
{
+ printk(KERN_EMERG XXX: pre-shutdown prepare\n);
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
- if (pm_power_off_prepare)
+ printk(KERN_EMERG XXX: post-shutdown prepare, sleeping 5\n);
+ ssleep(5);
+ if (pm_power_off_prepare) {
+ printk(KERN_EMERG XXX: pre-power_off_prepare\n);
pm_power_off_prepare();
+ printk(KERN_EMERG XXX: post-power_off_prepare, sleeping 5\n);
+ ssleep(5);
+ }
+ printk(KERN_EMERG XXX: pre-sysdev_shutdown\n);
sysdev_shutdown();
+ printk(KERN_EMERG XXX: post-sysdev_shutdown, sleeping 5\n);
+ ssleep(5);
printk(KERN_EMERG Power down.\n);
machine_power_off();
}
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 02:03 +0900, Tejun Heo napisał(a): Rafael J. Wysocki wrote: Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. Well, I've been observing the same behavior on nx6325 for some time and I use openSUSE 10.2. I think this is kernel-related. 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. Thanks. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
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'. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Monday, 6 August 2007 20:21, Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 02:03 +0900, Tejun Heo napisał(a): Rafael J. Wysocki wrote: Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. Well, I've been observing the same behavior on nx6325 for some time and I use openSUSE 10.2. I think this is kernel-related. 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. Thanks. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Same thing on my box. In kernel_shutdown_prepare(SYSTEM_POWER_OFF) we call device_shutdown(), so it looks like the drive is powered off by one driver's .shutdown() routine. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Monday, 6 August 2007 20:43, 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? How to check that? Also, please post the result of 'dmidecode'. Here's mine, from nx6325 (Michael's is a different model): # dmidecode 2.8 SMBIOS 2.4 present. 23 structures occupying 1029 bytes. Table at 0x000F3FA3. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Hewlett-Packard Version: 68TT2 Ver. F.02 Release Date: 07/06/2006 Address: 0xE Runtime Size: 128 kB ROM Size: 1024 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported 3.5/720 KB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported LS-120 boot is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 15.2 Firmware Revision: 64.21 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Hewlett-Packard Product Name: HP Compaq nx6325 (EY351EA#AKD) Version: F.02 Serial Number: CNU63201YR UUID: CDF6EA3B-A5D7-DD11-0188-6D990C3F6129 Wake-up Type: Power Switch SKU Number: EY351EA#AKD Family: 103C_5336AN Handle 0x0040, DMI type 126, 33 bytes Inactive Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Hewlett-Packard Product Name: 30B0 Version: KBC Version 40.15 Serial Number: Not Specified Handle 0x0003, DMI type 3, 13 bytes Chassis Information Manufacturer: Hewlett-Packard Type: Notebook Lock: Not Present Version: Not Specified Serial Number: CNU63201YR Asset Tag: CNU63201YR Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: External Interface Enabled Handle 0x0041, DMI type 126, 32 bytes Inactive Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: U10 Type: Central Processor Family: Athlon 64 Manufacturer: AMD(R) ID: 82 0F 04 00 FF FB 8B 17 Signature: Extended Family 0, Model 8, Stepping 2 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) HTT (Hyper-threading technology) Version: AMD Turion(tm) 64 X2 Mobile TL-60 Voltage: 1.1 V External Clock: 200 MHz Max Speed: 2000 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: Internal L1 Cache Configuration:
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): 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'. Thanks. I do not know how to check this emergency unload count, so please explain what do I need to do. dmidecode: dmidecode 2.9 SMBIOS 2.4 present. 23 structures occupying 1029 bytes. Table at 0x000F38EB. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Hewlett-Packard Version: 68YDU Ver. F.0D Release Date: 04/17/2007 Address: 0xE Runtime Size: 128 kB ROM Size: 1024 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported 3.5/720 KB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported LS-120 boot is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 15.13 Firmware Revision: 88.18 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Hewlett-Packard Product Name: Version: F.0D Serial Number: UUID: Not Settable Wake-up Type: Power Switch SKU Number: Family: 103C_5336AN Handle 0x0040, DMI type 126, 4 bytes Inactive Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Hewlett-Packard Product Name: 30AA Version: KBC Version 58.12 Serial Number: Not Specified Handle 0x0003, DMI type 3, 13 bytes Chassis Information Manufacturer: Hewlett-Packard Type: Notebook Lock: Not Present Version: Not Specified Serial Number: Asset Tag: CNU63515Y3 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: External Interface Enabled Handle 0x0041, DMI type 126, 10 bytes Inactive Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: U10 Type: Central Processor Family: Pentium M Manufacturer: Intel(R) ID: E8 06 00 00 FF FB E9 BF Signature: Type 0, Family 6, Model 14, Stepping 8 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Hyper-threading technology) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Genuine Intel(R) CPU T2050 @ 1.60GHz Voltage: 1.1 V External Clock: 133 MHz Max Speed: 1600 MHz Current Speed: 1600 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: Internal L1 Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back
Re: Disk spin down issue on shut down/suspend to disk
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.. -- 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
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. 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? -- 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Cc'ing Henrique. Any ideas? Michał sed 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. Michael -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
