Most recent kernel where this bug did *NOT* occur: N/A Distribution: Ubuntu/Kubuntu 6.10, Ubuntu/Kubuntu 7.04 alpha1, OpenSuse 10.2, Fedora Core 6. Hardware Environment: HP Pavillion dv2172ea Software Environment: N/A Problem Description: See here: https://launchpad.net/distros/ubuntu/+source/acpi/+bug/68660 When shutting down the system the harddrive make the same noise that occours when you cut the power (pressing power button for 4 seconds) and the drive is not idle. Different users with different systems have the same problem. Shutting down the system under windowsxp is fine, the drive shuts down silently. Steps to reproduce: Just halt your system.
Some more infos: Notebook drives automatically park the head when they are idle (not seeking for a few seconds). Cutting the power when the head is parked makes no bad sounds. Cutting the power when the drive is idle but the head isn't already auto-parked (because of a very recent drive seek) makes that bad noise; this is what happens when halting with linux. In WindowsXP no matter the drive has recently seek or not, a proper park command is sent before cutting the power (I can hear the head parking just before the power is cut). Hope this helps. Marco
I can confirm this behavior on an Samsung X20 with Intel ICH6M on GNU/Gentoo Linux with kernel 2.6.20-rc5 with an ide harddrive & libata with the old ide-driver completely disabled
just wanted to let you know that I made some more "testing" in the meantime and the cause definitely should be libata, I tried ide-driver and this behavior didn't occur I know that this is no help to the people using S-ATA drives since they can't switch to the ide-drivers but this should help isolate the problem this bug still applies to 2.6.20 !
Created attachment 10426 [details] lspci output in Acer 5684wlmi
Created attachment 10427 [details] dmesg output in Ubuntu kernel 2.6.17-11-generic
Created attachment 10428 [details] hdparm output in Acer 5684wlmi
Confirmed on Acer aspire 5684wlmi. Someone affirm that this noise is caused by an emergency head parking, as if the power were cutted before the head is automatically parked (as in case of severe crash and a consequent forced power-off). Seems that ubuntu Dapper Drake ( Linux ceztko-laptop 2.6.17-11-generic #2 SMP Thu Feb 1 19:52:28 UTC 2007 i686 GNU/Linux ) is not affected, maybe because it doesn't use libata? Can't confirm this, yet. Attached output of dmesg, lspci and hdparm on my system (Ubuntu 6.10). Ask me if you need more infos.
Created attachment 10492 [details] Printk output from the kernel during shutdown
Added printk output from my kernel during shut-down (taken with netconsole). Parameters: echo 8 > /proc/sys/kernel/printk echo 1 > /proc/sys/vm/block_dump
What about this page I've found: http://www.nabble.com/(fwd)--PATCH--sd:-implement-stop_on_shutdown-t3049703.html
Hardware: Toshiba M55-S3314 laptop 1. This bug has affected this unit on every distro attempted from even before kernel 2.6.17, on through 2.6.20 2. Have lately tried Ubuntu 6.06, 6.10, Opensuse 10.1, 10.2, Slack 11, Dreamlinux, Myah, and a handful of others, all seem to be affected by this bug. 3. I stopped using linux for a while because of it. Can't afford hardware failure over it. 4. FOR THE FIRST TIME, tried Sidux 2007-1, which uses 2.6.20 kernel SMP...it does NOT appear to have this issue. I'm not a dev, but I thought it might be useful to say that this one works fine, maybe somebody who knows what they're looking for can find out what's different about Sidux vs. the other distros? Or has 2.6.20 been patched and fixed already, and it just hasn't filtered down yet? Any requests for logs, etc., please just email me.
Printk output on my Acer5684WLMI during shutdown (with libata debug enabled): [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 Alternative printk output from Rolf Offermanns on lkml: 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.
I can confirm this as well on SuSE 10.2 (2.6.18.8-0.1-default) on a Fujitsu-Siemens E8210 equipped with a SATA harddisk.
My mistake...Sidux started doing it as well. For a day or two, it was powering down quietly, then I tried suspending and hibernating. Both worked fine, but after that, the parking got all messed up again and it started making the noise once more. Hopefully there's some lead there. Has anyone discovered anything new?
Fixed in mainstream by Tejun Heo, http://article.gmane.org/gmane.linux.scsi/30489 . Lot of infrastructure here, probably 2.6.22 stuff? Please note that the FULL fix will need shutdown(8) modifies, as described here http://article.gmane.org/gmane.linux.ide/17392 . In the same message is described a meantime workaround, that consist of a temporary setting (already scheduled for removal) in the libata module. Here the extract: > This patch implements module parameter libata.spindown_compat which, > when set to one (default value), prevents libata from spinning down > disks on shutdown thus avoiding double spinning down. Note that > libata spins down disks for suspend to mem and disk, so with > libata.spindown_compat set to one, disks should be properly spun down > in all cases without modifying shutdown(8). > > shutdown(8) should be fixed eventually tho. Some drive do spin up on > SYNCHRONZE_CACHE even when their cache is clean. Those disks > currently spin up briefly when sd tries to shutdown the device and > then the machine powers off immediately, which can't be good for the > head. We can't skip SYNCHRONIZE_CACHE during shudown as it can be > dangerous data integrity-wise. > > So, this spindown_compat parameter is already scheduled for removal by > the end of the next year and here's what shutdown(8) should do. > > 1. Check whether /sys/modules/libata/parameters/spindown_compat > exists. If it does, write 0 to it. > > For each libata harddisk { > > 2. Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop > exists. If so, write 1 to it and continue; otherwise, fall > through to #3. > > 3. Synchronize cache and spin down as before. > > }
Fixed in 2.6.22rc1 [1] [2]. Can be closed. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9666f4009c22f6520ac3fb8a19c9e32ab973e828 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=920a4b1038e442700a1cfac77ea7e20bd615a2c3
When I report this bug, 9 months ago, a maintenner says to me that it is normal, but now I read that is a bug. See more (and attachment audio file) in: <http://bugzilla.kernel.org/show_bug.cgi?id=7001> Kernel 2.6.21.1 don't have this problem in my Toshiba M45-S355. # lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 04) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 10) 05:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) 05:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller 05:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller 05:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller 05:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
More detail about my config file to compile Kernel 2.6.2.1 # cat .config | grep -i ata | sed -e '\/#/D' CONFIG_X86_MCE_NONFATAL=m CONFIG_ATALK=m CONFIG_MTD_DATAFLASH=m CONFIG_ATA_OVER_ETH=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_ATA=y CONFIG_ATA_PIIX=y CONFIG_SATA_ACPI=y CONFIG_USB_STORAGE_DATAFAB=y
*** Bug 7001 has been marked as a duplicate of this bug. ***
Some users reported that they can hear the same noise[1] reported here, but in each 2 minutes (or less), and not only in shutdown, running Debian Lenny (Kernel 2.6.26) in some laptops: [1] http://bugzilla.kernel.org/attachment.cgi?id=8777&action=view HP Laptop ==================== Mon Feb 16 15:44:27 BRT 2009 # smartctl -a /dev/sda | grep Load_Cycle_Count 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 1997 Mon Feb 16 16:46:07 BRT 2009 # smartctl -a /dev/sda | grep Load_Cycle_Count 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 2025 ==================== This mean 600.000 counter in only 892 days. I check in my Thinkpad T61 the same problem: When AC is removed: ==================== Tue Feb 17 11:59:26 BRT 2009 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 10820 Tue Feb 17 12:27:48 BRT 2009 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 10840 ==================== As you can see, Load_Cycle_Count increase 20 in only 28min. When AC is connected: ==================== Tue Feb 17 10:14:22 BRT 2009 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 10820 Tue Feb 17 11:59:26 BRT 2009 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 10820 ==================== As you can see, no spin-up and spin-down when AC is connected. Best regards, Renato S. Yamane