Weird hard disk noise on shutdown (bug #7674)
Francesco Pretto
hard disk noise emitted when shutting down, immediately after the main
power is cut from the pc/notebook. We believe that the noise is a
symptom of an emergency head parking, usually performed on the drives
when the the power is forced cut off (for example consequently a
severe system crash). We are Ubuntu users, but other users tried various
distros observing similar behavior when comparable settings are used
(e.g. using libata drivers). Ubuntu bug managers have decided that is
kernel drivers issue [1] and a bugzilla entry was opened [2]. The bug was
issued on 2006-12-20 but since that there hasn't been much interested on
it, except from other users worried about their notebooks' health. It has
been conjectured that this is a libata specific problem, because using
legacy ide drivers for the same disk (when possible), this "fix" the
problem.
Now, what we'd like to know is a clear word if this a distro specific
bug or a kernel one (it should be enough to establish if the
responsibility of safely parking the disk head is of the shutdown
script or of the controller driver). In the latter case, we'd like to
enter in contact with the related subsystem maintainer so we can help
to track down the bug (some details are already present in the related
bug entries on bugzilla and launchpad). After all, this seems a bug that
could injure the disks in the long time. Even if this is not the case, it's not
good that people (especially newbies) believe that using linux is not
safe for their hardware :-D .
Thanks for your interest,
Francesco Pretto, ceztko at gmail dot com
Giorgio Mennea, swengml at gmail dot com
NB: Please CC the sender's email. I'm not subscribed.
[1] https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/67810
[2] http://bugzilla.kernel.org/show_bug.cgi?id=7674
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan
turn on all the ATA debug and shutdown, the code should issue a cache
flush followed by a standbynow1 command for each disk.
Alan
Francesco Pretto
2007/2/21, Alan <al...@lxorguk.ukuu.org.uk>:
> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
> turn on all the ATA debug and shutdown, the code should issue a cache
> flush followed by a standbynow1 command for each disk.
>
> Alan
>
Hi! Using netconsole, i was able to capture some printk output.
Following some advices in the net (forum threads about similar
problems), i did this to enable more verbose printk printing:
echo 8 > /proc/sys/kernel/printk
echo 1 > /proc/sys/vm/block_dump
This was the result:
http://bugzilla.kernel.org/attachment.cgi?id=10492&action=view
However, i'm not still sure i enabled as much debugging info as i
could in the kernel configuration. If you need more, please point me
to precise configuration options.
Thanks for your response.
Francesco Pretto
Robert Hancock
> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
> turn on all the ATA debug and shutdown, the code should issue a cache
> flush followed by a standbynow1 command for each disk.
>
> Alan
I believe it runs on suspend, but we don't run that code on normal
shutdown, do we?
Tejun Heo had a patch for sd that could (optionally) trigger a START
STOP UNIT command to spin the disk down after synchronizing the cache
before shutdown, but I haven't heard anything of it lately..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hanc...@nospamshaw.ca
Home Page: http://www.roberthancock.com/
Robert Hancock
> Alan wrote:
>> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
>> turn on all the ATA debug and shutdown, the code should issue a cache
>> flush followed by a standbynow1 command for each disk.
>>
>> Alan
>
> I believe it runs on suspend, but we don't run that code on normal
> shutdown, do we?
>
> Tejun Heo had a patch for sd that could (optionally) trigger a START
> STOP UNIT command to spin the disk down after synchronizing the cache
> before shutdown, but I haven't heard anything of it lately..
And yes, this is something we need to deal with. I don't think that
disks that use contact start-stop heads care so much, but disks that use
load-unload heads (like most laptop drives, it seems) generally quote a
much lower cycle lifetime for "emergency unloads" caused by power loss
than by normal unloads done while power is still applied. It's important
enough that in some cases, like the Compaq X1000-series laptop I have,
the BIOS appears to have a power button handler that spins down the
drive before power-down when the power button is pressed and an ACPI OS
isn't running. (Holding the button down when an ACPI OS is running just
forces the power off, then you get the clunk from the drive..)
Windows XP (and even as far back as Windows 98) get this right, surely
we can do as well :-)
Tejun Heo
> Robert Hancock wrote:
>> Alan wrote:
>>> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
>>> turn on all the ATA debug and shutdown, the code should issue a cache
>>> flush followed by a standbynow1 command for each disk.
>>>
>>> Alan
>>
>> I believe it runs on suspend, but we don't run that code on normal
>> shutdown, do we?
>>
>> Tejun Heo had a patch for sd that could (optionally) trigger a START
>> STOP UNIT command to spin the disk down after synchronizing the cache
>> before shutdown, but I haven't heard anything of it lately..
I just came back from LSF and lunar new year's holidays and need a bit
more time to get to it. I'll get to it in one or two weeks.
--
tejun
Francesco Pretto
>
> And yes, this is something we need to deal with. I don't think that
> disks that use contact start-stop heads care so much, but disks that use
> load-unload heads (like most laptop drives, it seems) generally quote a
> much lower cycle lifetime for "emergency unloads" caused by power loss
> than by normal unloads done while power is still applied. It's important
> enough that in some cases, like the Compaq X1000-series laptop I have,
> the BIOS appears to have a power button handler that spins down the
> drive before power-down when the power button is pressed and an ACPI OS
> isn't running. (Holding the button down when an ACPI OS is running just
> forces the power off, then you get the clunk from the drive..)
>
> Windows XP (and even as far back as Windows 98) get this right, surely
> we can do as well :-)
>
>
Yes, windows XP could handle better the power button pressed event
(causing the hd not to go to emergency parking, even when forced
shut-down, most of the times). But regarding a normal shut-down cycle,
isn't this a regression? You don't solve a regression adding a feature
(IMHO).
Alan
> could in the kernel configuration. If you need more, please point me
> to precise configuration options.
You grabbed a lot of junk but you did grab this line
[17179682.560000] Synchronizing SCSI cache for disk sda:
Which means sd_sync_cache got called and flushed the data to disk.
I don't think you can do the other needed debugging without a recompile.
The following will generate a vast amount of debug of which only the end
matters. You may well want to build a kernel this way, boot it with
init=/bin/sh and then at the shell prompt do "halt -f" so you don't get
too much debug
In include/linux/libata.h change
#undef ATA_DEBUG /* debugging output */
#undef ATA_VERBOSE_DEBUG /* yet more debugging output */
so both of the undef-s read define
#define ATA_DEBUG
#define ATA_VERBOSE_DEBUG
and recompile
Robert Hancock
> Yes, windows XP could handle better the power button pressed event
> (causing the hd not to go to emergency parking, even when forced
> shut-down, most of the times). But regarding a normal shut-down cycle,
> isn't this a regression? You don't solve a regression adding a feature
> (IMHO).
It's a feature that's in drivers/ide (I believe) but isn't in libata or
the SCSI layer.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hanc...@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
Rolf Offermanns
>> However, i'm not still sure i enabled as much debugging info as i
>> could in the kernel configuration. If you need more, please point me
>> to precise configuration options.
>
> You grabbed a lot of junk but you did grab this line
>
> [17179682.560000] Synchronizing SCSI cache for disk sda:
>
> Which means sd_sync_cache got called and flushed the data to disk.
>
> I don't think you can do the other needed debugging without a recompile.
>
> The following will generate a vast amount of debug of which only the end
> matters. You may well want to build a kernel this way, boot it with
> init=/bin/sh and then at the shell prompt do "halt -f" so you don't get
> too much debug
>
> In include/linux/libata.h change
>
> #undef ATA_DEBUG /* debugging output */
> #undef ATA_VERBOSE_DEBUG /* yet more debugging output */
>
> so both of the undef-s read define
>
> #define ATA_DEBUG
> #define ATA_VERBOSE_DEBUG
>
> and recompile
I hear the same strange noise on poweroff (2.6.20 vanilla). This is what I
get on my system with ATA_DEBUG and ATA_VERBOSE_DEBUG both defined. The
system will *not* poweroff with "halt -f" so there was no noise!
md: stopping all md devices.
Synchronizing SCSI cache for disk sda:
ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
ata_scsi_translate: ENTER
ata1: ata_dev_select: ENTER, ata1: device 0, wait 1
ata_tf_load_pio: device 0xA0
ata_exec_command_pio: ata1: cmd 0xE7
ata_scsi_translate: EXIT
ata_host_intr: ata1: protocol 1 task_state 2
ata_hsm_move: ata1: protocol 1 task_state 2 (dev_stat 0x50)
ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
System halted.
If I do a sysrq-o right after this, the above message repeate once more and
the system turns off w/o the disturbing noise.
For the next messages, I booted the system completely (no init=/bin/sh) and
did a "poweroff" at the console prompt after the boot was completed. This
time the noise was there.
ata_host_intr: ata1: protocol 3 task_state 2
ata_host_intr: ata1: host_stat 0x24
ata_hsm_move: ata1: protocol 3 task_state 2 (dev_stat 0x50)
ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
ata_sg_clean: unmapping 1 sg elements
ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 04 b5 d4 c8 00 00 08
ata_scsi_translate: ENTER
scsi_10_lba_len: ten-byte command
ata_sg_setup: ENTER, ata1
ata_sg_setup: 1 sg elements mapped
ata_fill_sg: PRD[0] = (0x39A63000, 0x1000)
ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0xC8 0xD4 0xB5
ata_tf_load_pio: device 0xE4
ata_exec_command_pio: ata1: cmd 0xC8
ata_scsi_translate: EXIT
ata_host_intr: ata1: protocol 3 task_state 2
ata_host_intr: ata1: host_stat 0x24
ata_hsm_move: ata1: protocol 3 task_state 2 (dev_stat 0x50)
ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
ata_sg_clean: unmapping 1 sg elements
ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
ata_scsi_translate: ENTER
ata_tf_load_pio: device 0xA0
ata_exec_command_pio: ata1: cmd 0xE7
ata_scsi_translate: EXIT
ata_host_intr: ata1: protocol 1 task_state 2
ata_hsm_move: ata1: protocol 1 task_state 2 (dev_stat 0x50)
ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
Power down.
HTH,
Rolf
Francesco Pretto
>
> The following will generate a vast amount of debug of which only the end
> matters.
>
For some reason, related to my current distro, i didn't used init=/bin/sh .
The full, bloated, log is here http://www.webalice.it/ceztko/log1
(taken from launch of "poweroff"). I can confirm, as Rolf Offermanns
noted, that "halt -f" doesn't cut the power.
An extract is here. However i'm worried that the log is trunkated. Is
netconsole good enough to use in this case?
[17179886.052000] ata_scsi_dump_cdb: CDB (1:0,0,0) 2a 00 07 5b dd 90 00 00 08
[17179886.052000] ata_scsi_translate: ENTER
[17179886.052000] scsi_10_lba_len: ten-byte command
[17179886.052000] ata_sg_setup: ENTER, ata1
[17179886.052000] ata_sg_setup: 1 sg elements mapped
[17179886.052000] ata_fill_sg: PRD[0] = (0x2317000, 0x1000)
[17179886.052000] ata_dev_select: ENTER, ata1: device 0, wait 1
[17179886.052000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x90 0xDD 0x5B
[17179886.052000] ata_tf_load_pio: device 0xE7
[17179886.052000] ata_exec_command_pio: ata1: cmd 0xCA
[17179886.052000] ata_scsi_translate: EXIT
[17179886.052000] ata_host_intr: ata1: host_stat 0x24
[17179886.052000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50)
[17179886.052000] ata_sg_clean: unmapping 1 sg elements
[17179886.056000] rc(4351): READ block 309568 on sda6
[17179886.056000] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 07 5f 96 40 00 00 08
[17179886.056000] ata_scsi_translate: ENTER
[17179886.056000] scsi_10_lba_len: ten-byte command
[17179886.056000] ata_sg_setup: ENTER, ata1
[17179886.056000] ata_sg_setup: 1 sg elements mapped
[17179886.056000] ata_fill_sg: PRD[0] = (0x7E992000, 0x1000)
[17179886.056000] ata_dev_select: ENTER, ata1: device 0, wait 1
[17179886.056000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x40 0x96 0x5F
[17179886.056000] ata_tf_load_pio: device 0xE7
[17179886.056000] ata_exec_command_pio: ata1: cmd 0xC8
[17179886.056000] ata_scsi_translate: EXIT
[17179886.064000] ata_host_intr: ata1: host_stat 0x24
[17179886.064000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50)
[17179886.064000] ata_sg_clean: unmapping 1 sg elements
[17179886.064000] S90halt(4351): READ block 307632 on sda6
[17179886.064000] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 07 5f 8e b0 00 00 08
[17179886.064000] ata_scsi_translate: ENTER
[17179886.064000] scsi_10_lba_len: ten-byte command
[17179886.064000] ata_sg_setup: ENTER, ata1
[17179886.064000] ata_sg_setup: 1 sg elements mapped
[17179886.064000] ata_fill_sg: PRD[0] = (0x7CC47000, 0x1000)
[17179886.064000] ata_dev_select: ENTER, ata1: device 0, wait 1
[17179886.064000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0xB0 0x8E 0x5F
[17179886.064000] ata_tf_load_pio: device 0xE7
[17179886.064000] ata_exec_command_pio: ata1: cmd 0xC8
[17179886.064000] ata_scsi_translate: EXIT
[17179886.076000] ata_host_intr: ata1: host_stat 0x24
[17179886.076000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50)
[17179886.076000] ata_sg_clean: unmapping 1 sg elements
Robert Hancock
> I hear the same strange noise on poweroff (2.6.20 vanilla). This is what I
> get on my system with ATA_DEBUG and ATA_VERBOSE_DEBUG both defined. The
> system will *not* poweroff with "halt -f" so there was no noise!
>
> md: stopping all md devices.
> Synchronizing SCSI cache for disk sda:
> ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
> ata_scsi_translate: ENTER
> ata1: ata_dev_select: ENTER, ata1: device 0, wait 1
> ata_tf_load_pio: device 0xA0
> ata_exec_command_pio: ata1: cmd 0xE7
> ata_scsi_translate: EXIT
> ata_host_intr: ata1: protocol 1 task_state 2
> ata_hsm_move: ata1: protocol 1 task_state 2 (dev_stat 0x50)
> ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
> System halted.
>
> If I do a sysrq-o right after this, the above message repeate once more and
> the system turns off w/o the disturbing noise.
>
> For the next messages, I booted the system completely (no init=/bin/sh) and
> did a "poweroff" at the console prompt after the boot was completed. This
> time the noise was there.
From these traces you can clearly see that no STANDBY IMMEDIATE
(command code 0xE0) was issued before the power-off, which is what would
prevent this problem.
If you wait long enough after halting before you power down, you may not
get the noise, since many laptop drives unload the heads after a fairly
short period of inactivity, and so the heads are already unloaded when
the power is shut off.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hanc...@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
Francesco Pretto
>
> I believe it runs on suspend, but we don't run that code on normal
> shutdown, do we?
>
> Tejun Heo had a patch for sd that could (optionally) trigger a START
> STOP UNIT command to spin the disk down after synchronizing the cache
> before shutdown, but I haven't heard anything of it lately..
>
>
Was this?
http://www.nabble.com/(fwd)--PATCH--sd:-implement-stop_on_shutdown-t3049703.html
Not ready for inclusion yet? Tomorrow i'll give it a try, hoping it
will apply to my conf. My actually shutdown procedure is to reboot on
windows Xp and shutdown from there: i'm starting to become
frustrated...
Dan Gilliam
> 2007/2/22, Robert Hancock <hanc...@shaw.ca>:
>>
>> I believe it runs on suspend, but we don't run that code on normal
>> shutdown, do we?
>>
>> Tejun Heo had a patch for sd that could (optionally) trigger a START
>> STOP UNIT command to spin the disk down after synchronizing the cache
>> before shutdown, but I haven't heard anything of it lately..
>>
>>
>
> Was this?
> http://www.nabble.com/(fwd)--PATCH--sd:-implement-stop_on_shutdown-t3049703.html
>
>
> Not ready for inclusion yet? Tomorrow i'll give it a try, hoping it
> will apply to my conf. My actually shutdown procedure is to reboot on
>
Hi, I just wanted to say that I'm another user having this issue. I
have a Toshiba M55-S3314 which is also making the same noise on
shutdown. I have heard it from Ubuntu 5.04 on to Feisty Fawn Herd 4
(which is using the 2.6.20-9 kernel). I had installed the newest
version of Sidux the other night, with the 2.6.20 kernel, and it didn't
seem to do it. But then I tried it with Feisty, and at first, it didn't
do it. Then I suspended the unit, and it came back fine; then I
hibernated the unit; it came up ok, but after that, it's making the
noise again every time. So I have no idea what's causing this.
I hope that somebody can figure this one out...for the first time since
1998, I can't use linux on my machine! :-( I can't afford to sacrifice
my hard drive... I'm not a programmer, but I'll be more than happy to
try out stuff if anybody wants me to, or give logs or whatever. Just
tell me what you want and how to get it!
Thanks,
Dan
Phillip Susi
this. Does this patch resolve the issue? I can't seem to load it up
right now; the site says it is down for maintenance.
Tejun Heo
> Did anything ever come of this? We still have users complaining about
> this. Does this patch resolve the issue? I can't seem to load it up
> right now; the site says it is down for maintenance.
Yeap, the third iteration of the patch just got submitted.
http://thread.gmane.org/gmane.linux.ide/18485
Unfortunately, there doesn't seem to be an easy way out. We'll need
userland shutdown(8) update.
--
tejun
Francesco Pretto
> Yeap, the third iteration of the patch just got submitted.
>
> http://thread.gmane.org/gmane.linux.ide/18485
>
> Unfortunately, there doesn't seem to be an easy way out. We'll need
> userland shutdown(8) update.
>
> --
> tejun
>
Ok, i can't understand if the patch will be included in 2.6.22 (i
didn't see it in the Andrew Morton merge plan). However, if you can
confirm the inclusion, i can send bug reports for ubuntu and gentoo. I
can even send an email to Miquel van Smoorenburg, who should be the
mainstream sysvinit developer (and probably the last maintainer).
Francesco
Tejun Heo
> Ok, i can't understand if the patch will be included in 2.6.22 (i
> didn't see it in the Andrew Morton merge plan). However, if you can
> confirm the inclusion, i can send bug reports for ubuntu and gentoo. I
> can even send an email to Miquel van Smoorenburg, who should be the
> mainstream sysvinit developer (and probably the last maintainer).
It hasn't generated too much response yet. Anyways, yeap, merging it
for 2.6.22 is definitely the plan. This thing can shorten lifespan of
harddisks. :-( I'll let you know if something changes.
Thanks.
--
tejun
Tejun Heo
> 2007/5/4, Tejun Heo <hte...@gmail.com>:
>> Yeap, the third iteration of the patch just got submitted.
>>
>> http://thread.gmane.org/gmane.linux.ide/18485
>>
>> Unfortunately, there doesn't seem to be an easy way out. We'll need
>> userland shutdown(8) update.
>>
>> --
>> tejun
>>
>
> Ok, i can't understand if the patch will be included in 2.6.22 (i
> didn't see it in the Andrew Morton merge plan). However, if you can
> confirm the inclusion, i can send bug reports for ubuntu and gentoo. I
> can even send an email to Miquel van Smoorenburg, who should be the
> mainstream sysvinit developer (and probably the last maintainer).
Okay, the patch made upstream and webpage posted.
http://linux-ata.org/shutdown.html
--
tejun
Francesco Pretto
>
> Okay, the patch made upstream and webpage posted.
>
> http://linux-ata.org/shutdown.html
>
> --
> tejun
>
Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
Smoorenburg, dev of sysvinit.
[1] https://bugs.launchpad.net/upstart/+bug/114683
[2] http://bugs.gentoo.org/show_bug.cgi?id=178559
Tejun Heo
> 2007/5/14, Tejun Heo <hte...@gmail.com>
>>
>> Okay, the patch made upstream and webpage posted.
>>
>> http://linux-ata.org/shutdown.html
>>
>> --
>> tejun
>>
>
> Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
> Smoorenburg, dev of sysvinit.
>
> [1] https://bugs.launchpad.net/upstart/+bug/114683
> [2] http://bugs.gentoo.org/show_bug.cgi?id=178559
Thanks a lot. I've notified suse. I'll ask Jeff whether rh is notified.
--
tejun
Henrique de Moraes Holschuh
> Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
> Smoorenburg, dev of sysvinit.
For all Debian sysvinit issues, please send email to
pkg-sysvi...@lists.alioth.debian.org (added to CC).
For the Debian sysvinit crew: Guys, have a look at
http://linux-ata.org/shutdown.html. We need to act on it, and also file a
bug on all of our current kernels (poweroff causes minor but accumulating-
over-time damage to all hardware under control of libata). This is really
something we should be trying to fix on our 2.6.18 kernels and stable
sysvinit.
> [1] https://bugs.launchpad.net/upstart/+bug/114683
> [2] http://bugs.gentoo.org/show_bug.cgi?id=178559
Tejun, am I right to assume that any servers with self-contained SCSI disks
(i.e. that are not plugged into externally powered drive enclosures, etc)
also get the emergency head unloads when they are powered off?
--
"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
Tejun Heo
Henrique de Moraes Holschuh wrote:
> On Mon, 14 May 2007, Francesco Pretto wrote:
>> Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
>> Smoorenburg, dev of sysvinit.
>
> For all Debian sysvinit issues, please send email to
> pkg-sysvi...@lists.alioth.debian.org (added to CC).
>
> For the Debian sysvinit crew: Guys, have a look at
> http://linux-ata.org/shutdown.html. We need to act on it, and also file a
> bug on all of our current kernels (poweroff causes minor but accumulating-
> over-time damage to all hardware under control of libata). This is really
> something we should be trying to fix on our 2.6.18 kernels and stable
> sysvinit.
>
>> [1] https://bugs.launchpad.net/upstart/+bug/114683
>> [2] http://bugs.gentoo.org/show_bug.cgi?id=178559
There have been further developments,
http://article.gmane.org/gmane.linux.ide/18823 (bugfix)
http://article.gmane.org/gmane.linux.ide/18846 (in discussion)
The second patch makes libata turn off the warning message and just
issue STANDBYNOW without userland modification, iff userland
halt/shutdown doesn't issue STANDBYNOW during shutdown. I'm not sure
whether this will be accepted or not. It makes the change much less
intrusive for distros which don't issue STANDBYNOW from userland but
disks will always do emergency-unload on all kernels with this problem.
> Tejun, am I right to assume that any servers with self-contained SCSI disks
> (i.e. that are not plugged into externally powered drive enclosures, etc)
> also get the emergency head unloads when they are powered off?
AFAIK, yes, all SCSI disks attached to a single host and shares power
on/off status will do emergency unload on poweroff. In the updated
kernel, this is controlled by the following sysfs node.
/sys/class/scsi_disk/h:c:i:l/manage_start_stop.
It defaults to 1 for libata devices and 0 for all others. Echoing 1 to
it makes the sd driver spindown the device on suspend to ram/disk and
poweroff.
--
tejun
Dave Jones
> Francesco Pretto wrote:
> > 2007/5/4, Tejun Heo <hte...@gmail.com>:
> >> Yeap, the third iteration of the patch just got submitted.
> >>
> >> http://thread.gmane.org/gmane.linux.ide/18485
> >>
> >> Unfortunately, there doesn't seem to be an easy way out. We'll need
> >> userland shutdown(8) update.
> >>
> >> --
> >> tejun
> >>
> >
> > Ok, i can't understand if the patch will be included in 2.6.22 (i
> > didn't see it in the Andrew Morton merge plan). However, if you can
> > confirm the inclusion, i can send bug reports for ubuntu and gentoo. I
> > can even send an email to Miquel van Smoorenburg, who should be the
> > mainstream sysvinit developer (and probably the last maintainer).
>
> Okay, the patch made upstream and webpage posted.
>
> http://linux-ata.org/shutdown.html
There's a typo..
"Check whether /sys/modules/libata/parameters/spindown_compat exists. If it does, write 0 to it."
should be /sys/module/libata/parameters/spindown_compat
(no 's' after module)
Dave
--
http://www.codemonkey.org.uk
Rob Landley
> On Mon, May 14, 2007 at 07:32:43PM +0200, Tejun Heo wrote:
> > Francesco Pretto wrote:
> > > 2007/5/4, Tejun Heo <hte...@gmail.com>:
> > >> Yeap, the third iteration of the patch just got submitted.
> > >>
> > >> http://thread.gmane.org/gmane.linux.ide/18485
> > >>
> > >> Unfortunately, there doesn't seem to be an easy way out. We'll need
> > >> userland shutdown(8) update.
> > >>
> > >> --
> > >> tejun
> > >>
> > >
> > > Ok, i can't understand if the patch will be included in 2.6.22 (i
> > > didn't see it in the Andrew Morton merge plan). However, if you can
> > > confirm the inclusion, i can send bug reports for ubuntu and gentoo. I
> > > can even send an email to Miquel van Smoorenburg, who should be the
> > > mainstream sysvinit developer (and probably the last maintainer).
> >
> > Okay, the patch made upstream and webpage posted.
> >
> > http://linux-ata.org/shutdown.html
>
> There's a typo..
>
> "Check whether /sys/modules/libata/parameters/spindown_compat exists. If it
does, write 0 to it."
>
> should be /sys/module/libata/parameters/spindown_compat
>
> (no 's' after module)
Um, hang on. So libata can't reliably turn the system off without data loss
and potential damage to hardware unless userspace goes through a special song
and dance? And this is _not_ considered a defect in the kernel?
Why?
(Is there any other piece of hardware that needs userspace to quiesce it just
so the _off_switch_ can take effect? Yes, I read both the gmane thread and
the linux-ata.org link. I used to maintain the busybox halt/reboot/poweroff
commands, although I don't anymore. That just called reboot(), and this
worked.)
Why on _earth_ does complicating software suspend add extra requirements to
actual shutdown? Since when does the shutdown command have to enumerate
attached block devices? If anything this would belong in umount -a, but that
doesn't care about the hardware of the underlying block devices and
SHOULDN'T...
I'm confused. Could someone please explain?
Rob
Francesco Pretto
> (Is there any other piece of hardware that needs userspace to quiesce it just
> so the _off_switch_ can take effect? Yes, I read both the gmane thread and
> the linux-ata.org link. I used to maintain the busybox halt/reboot/poweroff
> commands, although I don't anymore. That just called reboot(), and this
> worked.)
>
For what i understood, there were a misunderstanding caused by the
wrong assumption that shutdown(8) implementations were issuing
STANDBYNOW on all hard disk devices on the system (indistinctly from
the interface, old-ide/libata/scsi). The fact is that sysvinit and
others actually do something with the old interface /proc/ide, trying
to spindown the hard disks. This worked only on systems using the old
ide/ata drivers because kernel prior to 2.6.22rc1 didn't even have the
necessary feature to spindown hard disks using the libata or the scsi
interface.
Hopefully, with the patch in discussion, there will be an happy ending with:
- sysvinit and derived implementations:
if ( old ide/ata drivers are used )
{continue to do the old userland spindown mechanism with /proc/ide; }
// else
// { do nothing; }
reboot();
- everyone else:
// continue to do nothing :-)
reboot();
If exists some, at this point, exotic shutdown(8) implementation that
is trying to issue STANDBYBOW on libata/scsi devices, it will get a
fat warning. The warning could also state that the only supported way
is to leave complete responsibility of spinning down the hard disks to
kernel, so eventually it could be cleaned of checks and compatibility
options.
[1] http://article.gmane.org/gmane.linux.ide/18846
Tejun Heo
> For what i understood, there were a misunderstanding caused by the
> wrong assumption that shutdown(8) implementations were issuing
> STANDBYNOW on all hard disk devices on the system (indistinctly from
> the interface, old-ide/libata/scsi). The fact is that sysvinit and
> others actually do something with the old interface /proc/ide, trying
> to spindown the hard disks. This worked only on systems using the old
> ide/ata drivers because kernel prior to 2.6.22rc1 didn't even have the
> necessary feature to spindown hard disks using the libata or the scsi
> interface.
>
> Hopefully, with the patch in discussion, there will be an happy ending
> with:
>
> - sysvinit and derived implementations:
> if ( old ide/ata drivers are used )
> {continue to do the old userland spindown mechanism with /proc/ide; }
> // else
> // { do nothing; }
> reboot();
>
> - everyone else:
> // continue to do nothing :-)
> reboot();
Yeap, exactly. The patch has been accepted, I'll update the web page soon.
> If exists some, at this point, exotic shutdown(8) implementation that
> is trying to issue STANDBYBOW on libata/scsi devices, it will get a
> fat warning. The warning could also state that the only supported way
> is to leave complete responsibility of spinning down the hard disks to
> kernel, so eventually it could be cleaned of checks and compatibility
> options.
It does exist. It's my primary testing machine - a debian installation
which doesn't get updated too often. The only problem is that I'm half
globe away from that machine until the end of the month.
So, anyways, things are looking much brighter now.
--
tejun
Tejun Heo
> There's a typo..
>
> "Check whether /sys/modules/libata/parameters/spindown_compat exists. If it does, write 0 to it."
>
> should be /sys/module/libata/parameters/spindown_compat
Right, thanks.
--
tejun
Tejun Heo
Rob Landley wrote:
> Um, hang on. So libata can't reliably turn the system off without data loss
> and potential damage to hardware unless userspace goes through a special song
> and dance? And this is _not_ considered a defect in the kernel?
Yeap, definitely a bug in the kernel and we're trying to fix it. Just
for the record, we have _always_ issued FLUSH CACHE, so there hasn't
been and won't be any data loss problem. The data loss problem was
mentioned as why we can't do things completely inside kernel without
updating userland shutdown(8) which issues STANDBYNOW.
--
tejun
Stephen Clark
I agree. This didn't happen when I was just using the ide driver, why
can't libata work as well
as the old ide driver.
My $.02
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
Francesco Pretto
> >On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote:
> >
> >I'm confused. Could someone please explain?
> >
> can't libata work as well
> as the old ide driver.
>
Read my reply to that post. To summarize: libata, prior to 2.6.22rc1,
lacked the feature to spindown the hard disk. The last discussion was
about who's responsable to issue the STANDBYNOW command to the hard
disk. Response from the discussion is: the kernel. Trying to issue it
form userspace (iff your shutdown(8) implementation do so) will now
result in a big fat warning, until these compatibility measures will
be dropped from the kernel (soon or later).
Rob Landley
> - everyone else:
> // continue to do nothing :-)
> reboot();
That would be cool, but the impression I got from
http://linux-ata.org/shutdown.html was that shutdown commands were supposed
to _add_ quiescing of drives in order to avoid emergency head parking on
poweroff.
That article says:
> Distros should update their shutdown(8) to do the followings.
> Check whether /sys/modules/libata/parameters/spindown_compat exists. If it
> does, write 0 to it. For each libata harddisk
> Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop exists. If it
> doesn't, synchronize cache and spin the disk down as before. If it does, do
> nothing and continue to the next disk. The file is also accessible as
> /sys/block/sdX/device/scsi_disk:*/manage_start_stop.
You're saying all this is to work around kernels _before_ 2.6.22, and instead
of updating your shutdown you could just either update the kernel instead?
> If exists some, at this point, exotic shutdown(8) implementation that
> is trying to issue STANDBYBOW on libata/scsi devices, it will get a
> fat warning. The warning could also state that the only supported way
> is to leave complete responsibility of spinning down the hard disks to
> kernel, so eventually it could be cleaned of checks and compatibility
> options.
I'm all for leaving this to the kernel. I play in the embedded space a lot,
so the less I can get away with doing, the better. :)
Rob
-
Rob Landley
> Hello,
>
> Rob Landley wrote:
> > Um, hang on. So libata can't reliably turn the system off without data
loss
> > and potential damage to hardware unless userspace goes through a special
song
> > and dance? And this is _not_ considered a defect in the kernel?
>
> Yeap, definitely a bug in the kernel and we're trying to fix it. Just
> for the record, we have _always_ issued FLUSH CACHE, so there hasn't
> been and won't be any data loss problem. The data loss problem was
> mentioned as why we can't do things completely inside kernel without
> updating userland shutdown(8) which issues STANDBYNOW.
Ok, so the change is to get shutdown to _stop_ doing something stupid
(spinning down the disk without first flushing the cache), and the correct
thing for shutdown to do is keep its' mitts off the thing and let the kernel
power down the darn hardware?
Woot,
Rob
Rob Landley
> 2007/5/16, Stephen Clark <Stephe...@seclark.us>:
> > >On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote:
> > >
> > >I'm confused. Could someone please explain?
> > >
> > I agree. This didn't happen when I was just using the ide driver, why
> > can't libata work as well
> > as the old ide driver.
> >
>
> Read my reply to that post. To summarize: libata, prior to 2.6.22rc1,
> lacked the feature to spindown the hard disk. The last discussion was
> about who's responsable to issue the STANDBYNOW command to the hard
> disk. Response from the discussion is: the kernel. Trying to issue it
> form userspace (iff your shutdown(8) implementation do so) will now
> result in a big fat warning, until these compatibility measures will
> be dropped from the kernel (soon or later).
The last bit was what threw me. It seemed that the kernel was changed to do
the right thing, but only as a compatability measure that would be dropped
because userspace should be changed to start doing it (which seemed crazy).
It seems that the _warning_ is the compatability measure that will be dropped
(or perhaps the ability for userspace to do the wrong thing at all?), and the
kernel will continue to DTRT.
It's a bit confusing for those of us coming in late in the discussion. :)
Rob
Henrique de Moraes Holschuh
> Ok, so the change is to get shutdown to _stop_ doing something stupid
> (spinning down the disk without first flushing the cache), and the correct
> thing for shutdown to do is keep its' mitts off the thing and let the kernel
> power down the darn hardware?
Yes, for *all* SCSI disk devices, libata or not.
But you need to detect if the kernel has proper SCSI device shutdown
support, because if it does not, you have to do a cache flush and spindown
on shutdown(8) if you can...
--
"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
Rob Landley
> On Wed, 16 May 2007, Rob Landley wrote:
> > Ok, so the change is to get shutdown to _stop_ doing something stupid
> > (spinning down the disk without first flushing the cache), and the correct
> > thing for shutdown to do is keep its' mitts off the thing and let the
kernel
> > power down the darn hardware?
>
> Yes, for *all* SCSI disk devices, libata or not.
I realize that this time next year it won't be possible to use a ramdisk or a
network block device without going through the SCSI layer, but while it
remains an option I'm relishing _not_ using it, thanks.
> But you need to detect if the kernel has proper SCSI device shutdown
> support, because if it does not, you have to do a cache flush and spindown
> on shutdown(8) if you can...
Or (and this is just a thought), you could upgrade your kernel so it correctly
handles your hardware, treating this just like any other driver bug or other
lack of proper hardware support in the history of Linux. (Back when APM
couldn't power off the machine at the end of the shutdown sequence, did we
modify shutdown to try to work around this, or did we fix it in the kernel so
it worked?)
Why does everybody want to shoehorn everything through the SCSI layer, anyway?
Last I checked you didn't have to spin down a USB flash key. If SATA is
SCSI, what the heck is SAS? (Answer: a cynical marketing hack to bleed SCSI
bigots for the huge margins they've always been bled for. But oh well.) It
would be hilarious if I didn't have to put up with it renumbering my devices
and imposing requirements for hardware I haven't got on hardware I have
got...
Rob
Henrique de Moraes Holschuh
> > But you need to detect if the kernel has proper SCSI device shutdown
> > support, because if it does not, you have to do a cache flush and spindown
> > on shutdown(8) if you can...
>
> Or (and this is just a thought), you could upgrade your kernel so it correctly
> handles your hardware, treating this just like any other driver bug or other
The distros can't update kernels that easily on their stable branches.
And in the userland side, we are not breaking things any further for users
of kernels before 2.6.22 anyway. Don't expect shutdown(8) to remove support
for <2.6.22 any time soon, at least in Debian. That will happen only when
we are forced by some other reason to completely break compatibility with
such kernels.
> Last I checked you didn't have to spin down a USB flash key. If SATA is
But you have to spin down an USB HD... el-cheapo USB enclosures will NOT do
it for you. It is not an easy problem.
> SCSI, what the heck is SAS? (Answer: a cynical marketing hack to bleed SCSI
> bigots for the huge margins they've always been bled for. But oh well.) It
Actually, in my limited experience, SAS is marginally less crappy than SATA,
and has a higher MTBF, probably because the manufacturers try to cut less
corners. But if one can get high-quality SATA drives (where?!), I don't
know why SAS would be superior to SATA.
--
"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
Tejun Heo
>> Distros should update their shutdown(8) to do the followings.
>> Check whether /sys/modules/libata/parameters/spindown_compat exists. If it
>> does, write 0 to it. For each libata harddisk
>> Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop exists. If it
>> doesn't, synchronize cache and spin the disk down as before. If it does, do
>> nothing and continue to the next disk. The file is also accessible as
>> /sys/block/sdX/device/scsi_disk:*/manage_start_stop.
>
> You're saying all this is to work around kernels _before_ 2.6.22, and instead
> of updating your shutdown you could just either update the kernel instead?
Yeap, I was assuming most shutdown(8)s were spinning down disks, which
apparently is wrong. If shutdown(8) doesn't do that, you can just
upgrade the kernel and be done with it. I'll submit update for the page
in a few hours.
>> If exists some, at this point, exotic shutdown(8) implementation that
>> is trying to issue STANDBYBOW on libata/scsi devices, it will get a
>> fat warning. The warning could also state that the only supported way
>> is to leave complete responsibility of spinning down the hard disks to
>> kernel, so eventually it could be cleaned of checks and compatibility
>> options.
>
> I'm all for leaving this to the kernel. I play in the embedded space a lot,
> so the less I can get away with doing, the better. :)
Yeap, that's what's being done here. For all SCSI disks (real SCSI,
SATA, USB, whatnot), it's now controlled by sysfs node
manage_start_stop. Low level drivers can turn them on by default and
userland can change them by echoing to it.
--
tejun
Tejun Heo
>> Yeap, definitely a bug in the kernel and we're trying to fix it. Just
>> for the record, we have _always_ issued FLUSH CACHE, so there hasn't
>> been and won't be any data loss problem. The data loss problem was
>> mentioned as why we can't do things completely inside kernel without
>> updating userland shutdown(8) which issues STANDBYNOW.
>
> Ok, so the change is to get shutdown to _stop_ doing something stupid
> (spinning down the disk without first flushing the cache), and the correct
> thing for shutdown to do is keep its' mitts off the thing and let the kernel
> power down the darn hardware?
Yeah, about right. Because kernel can't skip FLUSH CACHE and FLUSH
CACHE can spin up the disk back again. Oh well, some disks even spin
back up on STANDBYNOW to spin down again. The big fat warning and all
compat mess are to avoid introducing regression and urge shutdown(8)
update such that it does nothing.
--
tejun
Lennart Sorensen
> Actually, in my limited experience, SAS is marginally less crappy than SATA,
> and has a higher MTBF, probably because the manufacturers try to cut less
> corners. But if one can get high-quality SATA drives (where?!), I don't
> know why SAS would be superior to SATA.
SAS is dual ported so you can have redundant cables and controllers.
--
Len Sorensen
Rob Landley
> On Thu, May 17, 2007 at 12:39:47AM -0300, Henrique de Moraes Holschuh wrote:
> > Actually, in my limited experience, SAS is marginally less crappy than
SATA,
> > and has a higher MTBF, probably because the manufacturers try to cut less
> > corners. But if one can get high-quality SATA drives (where?!), I don't
> > know why SAS would be superior to SATA.
>
> SAS is dual ported so you can have redundant cables and controllers.
Because the controller's far more likely to go than the moving parts...
On the models I saw they also literally gold plated the connectors, spun the
disks faster, and basically did everything they could think of to make the
same basic bundle of components more expensive. (Of course the fundamental
thing you do to make it more expensive is have smaller production runs in the
first place...)
Rob
Alan Cox
Rob Landley <r...@landley.net> wrote:
> On Thursday 17 May 2007 11:04 am, Lennart Sorensen wrote:
> > On Thu, May 17, 2007 at 12:39:47AM -0300, Henrique de Moraes Holschuh wrote:
> > > Actually, in my limited experience, SAS is marginally less crappy than
> SATA,
> > > and has a higher MTBF, probably because the manufacturers try to cut less
> > > corners. But if one can get high-quality SATA drives (where?!), I don't
> > > know why SAS would be superior to SATA.
> >
> > SAS is dual ported so you can have redundant cables and controllers.
>
> Because the controller's far more likely to go than the moving parts...
That only matters if you don't lay the data out with mirrors on different
controllers in the first place - which is cheaper to do with SATA than
buy any SAS kit IMHO
Lennart Sorensen
> Because the controller's far more likely to go than the moving parts...
Having redundant everything would be preferable. But cables do
sometimes fail. Not sure about the controllers, but if the controller
went you might loose the whole raid.
> On the models I saw they also literally gold plated the connectors, spun the
> disks faster, and basically did everything they could think of to make the
> same basic bundle of components more expensive. (Of course the fundamental
> thing you do to make it more expensive is have smaller production runs in the
> first place...)
Well I guess the theory is that a gold plated connector won't corrode as
much so the connection is less likely to fail. Not sure if there is any
proof to backup that theory.
--
Len Sorensen