Red Hat Bugzilla – Bug 63015
fails to wake up IDE drive -> deadlock
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311
Description of problem:
I use to let one of my Seagate harddisc drives (a ST310240A) spin down using
hdparm -Y /dev/hdb, to reduce noise and heat production. Normally (e.g. with
Enigma and earlier), when I access /dev/hdb* again, the kernel would wake up the
drive. This can take several seconds (probably involving a timeout and drive
reset), but so far it has worked flawlessly and reliable. With
kernel-2.4.18-0.13 it doesn't work and effectively puts the kernel into a
deadlock which requires a hard reset. Additionally, because of using partition
volume labels in /etc/fstab, the shutdown procedure also tries to access the
sleeping drive during unmount stage, but fails, too.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. hdparm -Y /dev/hdb
2. sleep 2
3. fdisk -l /dev/hdb
Actual Results: Kernel crashes, entering a deadlock while failing to wake up
Expected Results: Kernel should not crash, but wake up the drive.
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdb: ST310240A, ATA DISK drive
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
Only with DMA disabled for that drive (hdparm -d0 /dev/hdb), the kernel manages
to wake it up.
[Updated product from skipjack-beta2 to Valhalla.]
Running LVCool for Linux (a small program that keeps AMD Athlon/Duron CPUs idle)
in the background increases the likelihood that the kernel manages to wake up
the sleeping drive.
And hdparm -y /dev/hdb (small 'y' = standby mode instead of large 'Y' = sleep
mode) doesn't create any problems. So, currently that is my workaround.
Since this report is so old and I cannot reproduce it anymore with
changed h/w and s/w configuration, there's no point in keeping it
open. Closing as WORKSFORME.