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): 2.4.18-0.13 How reproducible: Didn't try 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 the drive. Expected Results: Kernel should not crash, but wake up the drive. Additional info: 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)
How reproducible: Always
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.