Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 63015 - fails to wake up IDE drive -> deadlock
fails to wake up IDE drive -> deadlock
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
athlon Linux
low Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-04-09 05:48 EDT by Michael Schwendt
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-28 11:46:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2002-04-09 05:48:32 EDT
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):

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)
Comment 1 Michael Schwendt 2002-04-10 17:56:52 EDT
How reproducible:
Comment 2 Michael Schwendt 2002-04-11 07:16:39 EDT
Only with DMA disabled for that drive (hdparm -d0 /dev/hdb), the kernel manages
to wake it up.
Comment 3 Michael Schwendt 2002-11-28 21:55:37 EST
[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.
Comment 4 Michael Schwendt 2004-07-28 11:46:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.