The SATA disk doesn't power off while shutdown

[GONG-YI LIAO]

I have install the linux-image-2.6.17-10-generic package on my system and I encounter this problem while shuting down my Toshiba Satellite M100 laptop: after clicking the shutdown button in the Gnome logout dialog, the system goes shutdown, and while the laptop being powered off, I heard a sound like in the case of disk failure, which is not heard with linux-image-2.6.15-27-686 kernel (the last dapper kernel, berived as 2.6.15), that is, the disk is not power off before the laptop be completely power off, so the disk is turned off as cutting power supply suddenly, this is very serious, this will cause physical damage to the hard drive, and I found that the message available with 2.6.15 kernel :

ACPI: bus type scsi registered

is not found with 2.6.17 kernel,
the disk type in 2.6.15 is PATA:
ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14
but the disk type in 2.6.17 is SATA
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14
it seems that the power management of the SATA disks (especially the laptop SATA disks) of 2.6.17 kernel does not work.

Toshiba Satellite M100 laptop uses ata_piix module.

any suggestion is appreciated.

step to reproduce:
With any laptop with SATA hard drive controled by Intel ICH7-M chipset, the problem will occured while system power off.

[Burn (burn0ut)]

I've got this problem to, with a Dell laptop.

[Johan Kiviniemi (ion)]

AFAIK all HDDs park the heads to a safe position when the power is cut. That's a hardware feature. There's probably not going to be any physical damage.

[Burn (burn0ut)]

The problem is that it doesn't sound "normal" and "safe". :p

I haven't got this problem with Dapper neither with other distro's.

[Matthew Garrett (mjg59)]

What model of Dell laptop?

[Burn (burn0ut)]

A Dell Inspiron 6400, SATA Seagate Momentus 7200rpm disk.

[Burn (burn0ut)]

Nothing changed yet since my update a few minutes ago.

[GONG-YI LIAO (gongyi-liao-gmail)]

This problem also occurs with vanilla (official) kernel 2.6.17+
it may be a up-stream bug.

[Burn (burn0ut)]

So who is going to take care of this bug?

[ehamberg (hamberg)]

Same error here.
Fujitsu Siemens V3205.

[GONG-YI LIAO (gongyi-liao-gmail)]

Doest anyone tried it with 2.6.16 kernel or last git patches?
I think it'a very important for Edgy, because Edgy will break your laptop SATA hard drive.

[magilus (magilus)]

> This problem also occurs with vanilla (official) kernel 2.6.17+ it may be a up-stream bug.

Yeah, it should be reported at http://bugzilla.kernel.org

[Burn (burn0ut)]

This bug has been reported to bugzilla -> http://bugzilla.kernel.org/show_bug.cgi?id=7396

[GONG-YI LIAO (gongyi-liao-gmail)]

I guess this problem is caused by the uevent (i.e. the new Udev framework in the kernel space), I have tried to compile a 2.6.16.30 official vanilla kernel which is patched with uevent but without significant changes in the PATA/SATA drivers source, and this problem is reproducedable in this case, which means the new udev in the kernel (uevent) may cause this problem, (maybe the laptop's SATA drive is recognized as a removable device by uevent/udev)
I suggestion is, don't upgrade to edgy if not neccessary.

[GONG-YI LIAO (gongyi-liao-gmail)]

By the way, I forget to remind someone which encounter this problem, the new uevent/udev is introduced in 2.6.16+ kernels, so the 2.6.15-27 kernel in the dapper archive doesn't suffer this problem.
This problem is quite serious, it will make fatal damage to your laptop SATA hard drive.
Any solution for this is greatly appreciated

[Eduard Ereza Martínez (ereza)]

I confirm this too in a Toshiba Satellite A110-180.

[ineti (mk-speedy-net)]

Same Problem here on a Biostar Ideq 210 Barebone System (via sata)with Seagate Sata HDD.
Tested: Suse 10.1, 10.2 Beta, Ubunut 6.06, 610, Fedora Core 6. All these are affected by the Problem. If I do a hard power off it is exactly the same noise like doing a soft power off (squeezing).

Iam currently trying to reproduce the error on my new asus laptop (ICH-7, SATA), which does not seem to be affected.

[magilus (magilus)]

Confirmed by several people.

[ineti (mk-speedy-net)]

In the Kernel 2.6.20 Changelog i found the following:

    [PATCH] libata: return sense data in HDIO_DRIVE_CMD ioctl

    Make the HDIO_DRIVE_CMD ioctl in libata (ATA command pass through) return a
    few ATA registers to userspace, following the same convention as the
    drivers/ide implementation of the same ioctl. This is needed to support ATA
    commands like CHECK POWER MODE, which return information in nsectors.

Does this solve our Problem? Did anybody try 2.6.20?

greetz,
marcus

[ehamberg (hamberg)]

I guess you meant 2.6.19 which was just released?
No, that didn't solve the problem. :/

[ehamberg (hamberg)]

Still the same problem with linux-image-2.6.20-5-generic from Feisty

[Burn (burn0ut)]

I can confirm the last comment. Running on Ubuntu Feisty, the same problem still exists... so the problem 's still in the kernel.

[Bart Samwel (bart-samwel)]

I cannot confirm or deny it on my Dell Inspiron 9400 with a Hitachi HTS541616J9SA00 SATA drive, but it does make a pretty loud noise at shutdown. According to the drive's specs:

http://www.hitachigst.com/tech/techlib.nsf/techdocs/8037F4603FE5B763862571840068043C/$file/5K160_SATA_spv1.2.pdf

QUOTE: "6.3.6: Load/unload

The product supports a minimum of 600,000 normal load/unloads.

Load/unload is a functional mechanism of the hard disk drive. It is controlled by the drive micro code. Specifically, unloading of the heads is invoked by the following commands:

* COMRESET
* Standby
* Standby immediate
* Sleep

Load/unload is also invoked as one of the idle modes of the drive.

The specified start/stop life of the product assumes that load/unload is operated normally, not in emergency mode

6.3.6.1 Emergency unload

[...] The drive supports a minimum of 20,000 emergency unloads.

6.3.6.2 Required Power-Off Sequence

The required host system sequence for removing power from the drive is as follows:

* Step 1: Issue one of the following commands.
   - Standby
   - Standby immediate
   - Sleep
   Note: Do not use the Flush Cache command for the power off sequence because this command does not invoke Unload.

Step 2: Wait until the Command Complete status is returned.
[...]

Step 3: Terminate power to the HDD.

This power-down sequence should be followed for entry into any system power-down state, system suspend state, or system hibernation state. In a robustly designed system, emergency unload is limited to rare scenarios, such as battery removal during operation." (END QUOTE)

This indicates that Johan's comment is not correct at least for this drive, and that this really is required. And that the kernel is probably killing my drive at every shutdown. 20,000 versus 600,000 supported spindowns is a *very* hefty difference. If this is representative for SATA notebook drives, this bug should at least be marked important, at the minimum.

[Burn (burn0ut)]

Yes indeed, it should be marked with a higher priority. Kernel 2.6.20.x still suffers from that problem.

[Martijn de Nerd (martijn-de-nerd)]

There is a patch here
http://bugzilla.kernel.org/show_bug.cgi?id=7838
probably due for 2.6.22.

[Martijn de Nerd (martijn-de-nerd)]

Okay, i read the abovementioned bugreport again, and now more carefully :) apparently, the patch is already (partly*) in 2.6.20 , but it is sort of not activated. However, this can be done manually.

For me the following procedure removed the unhealthy 'click';
sudo -i
echo 1 > /sys/class/scsi_disk/0\:0\:0\:0/stop_on_shutdown
(repeat this for all your disks, replace 0\:0\:0\:0/ )

However, this setting is lost when rebooting, that's why optimally the default setting has to be changed, which is;
/sys/module/sd_mod/parameters/stop_on_shutdown_default, then all the disks should follow this setting.
This is set somewhere at bootup, but I don't know where or when, this can't be to hard, though.

So, as far as I can see there is a simple solution for the 2.6.20 case, the edgy people aren't helped by this however...

Cheers,

Martijn
BTW
why does the upstream 7838 status say 'rejected' , while it actually is; resolved / code_fix ??

*partly; "SCSI part is committed into mainline. libata part is still pending. This can
appear in mainline 2.6.22 at the earliest."

[Bart Samwel (bart-samwel)]

Martijn,

Does the 2.6.20 SCSI-only change imply that I can't use this for my SATA disk?

[Martijn de Nerd (martijn-de-nerd)]

Yes you can, i have SATA disk myself. SATA disks are treated as scsi disks by the kernel (hence the /dev/sd* names)

[hetvliegend... (karel-vdm)]

Itried the workaround of Martijn (which I found on another page). It didn't work for me.
I made a file hdd-shutdown-workaround in /etc/init.d with the following two lines:

#!/bin/sh
echo 1 > /sys/class/scsi_device/0\:0\:0\:0/stop_on_shutdown

(only had to change "scsi_disk" for "scsi_device")
then

sudo chmod +x filename
sudo ln -s /etc/rc0.d/S99hdd-shutdown-workaround /etc/init.d/hdd-shutdown-workaround

I guessed this didn't work because "S99" meant it was called after S90halt so the computer was shutdown before. so I changed it to "S00hdd-shutdown-workaround" (like Martin wrote) but still nothing changed. I had no noise in Dapper, then noise in Edgy with kernel 2.6.17 but not with kernel 2.6.15, and still the noise in Feisty with kernel 2.6.20.

I don't have this file (or directory?) /sys/module/sd_mod/parameters/stop_on_shutdown_default
nor /sys/class/scsi_disk/0\:0\:0\:0/stop_on_shutdown . only /sys/class/scsi_device/0\:0\:0\:0/
am I missing something?

[Martijn de Nerd (martijn-de-nerd)]

hmm strange, if you have sata disks controlled by sd_mod (check whether that's loaded by "lsmod |grep sd_mod" ), i'd say there should be a file with a N/Y or 0/1 in /sys/class/scsi_disk/***/stop_on_shutdown (something for *** obviously)

i'm actually using a similar script as yours, activated it with update-rc.d script defaults , works fine for me

[Bart Samwel (bart-samwel)]

Adding my EUR 0.02, my SATA disk does have a stop_on_shutdown, and it fixes the problem.

[hetvliegend... (karel-vdm)]

~$ lsmod |grep sd_mod
sd_mod 19984 8
scsi_mod 139496 5 sbp2,sr_mod,sg,sd_mod,libata

I guess this means sd_mod is loaded?

[Bart Samwel (bart-samwel)]

I'm running 2.6.22-5 now, and there has been a development on this issue. Links to the LKML thread on the patch:

http://thread.gmane.org/gmane.linux.ide/18485

Basically, what it says is that it should now work as expected out of the box, if you write 0 to /sys/module/libata/parameters/spindown_compat before shutdown. This was done to support distros that were "fixed" in the mean time by doing the spindown in shutdown(8) or halt(8). Ubuntu is supposed to fix up halt(8) and shutdown(8), like it says on the accompanying web page:

http://linux-ata.org/shutdown.html

As for feisty, at this link there is a patch that toggles the default for stop_on_shutdown:

http://permalink.gmane.org/gmane.linux.hardware.thinkpad/29772

Unfortunately it apparently tries to spin down flash devices too, which leads to nasty but innocent error messages in the kernel output.

[Mehul Dixit (mehul-dixit)]

Martijn's workaround works for me but I'm unable to make the setting permanent. Can someone help me out with how it's to be done.

Thanks.

[xtknight (xt-knight)]

Is this still an issue in Gutsy?

[Brian Murray (brian-murray)]

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

[Sergio Zanchetta (primes2h)]

The 18 month support period for Edgy Eft 6.10 has reached it's end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task. However, please note that this report will remain open against the actively developed kernel. Thank you for your continued support and help as we debug this issue.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Ralph Janke (txwikinger)]

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.