Bug 63015

Summary:	fails to wake up IDE drive -> deadlock
Product:	[Retired] Red Hat Linux	Reporter:	Michael Schwendt <bugs.michael>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED WORKSFORME	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	low
Version:	7.3
Target Milestone:	---
Target Release:	---
Hardware:	athlon
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-07-28 15:46:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael Schwendt 2002-04-09 09:48:32 UTC

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)

Comment 1 Michael Schwendt 2002-04-10 21:56:52 UTC

How reproducible:
Always

Comment 2 Michael Schwendt 2002-04-11 11:16:39 UTC

Only with DMA disabled for that drive (hdparm -d0 /dev/hdb), the kernel manages
to wake it up.

Comment 3 Michael Schwendt 2002-11-29 02:55:37 UTC

[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 15:46:52 UTC

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.