IDE(?) lockups in 2.5.7pre1, 2.5.6, 2.5.6pre3

IDE(?) lockups in 2.5.7pre1, 2.5.6, 2.5.6pre3

[Adam J. Richter]

	Under 2.5.6-pre3 and 2.5.6, my desktop workstation would
occasionally get into a state where all disk I/O would block.
Process would run until they had to go to the disk, and then they
would stop.  Hitting ctrl-<scroll lock> shows these process in "D"
state.  The IDE controller in this machine is:

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)

	I just built 2.5.7-pre1 and have discovered the other machne
that has a VIA IDE controller developed the same problem just after
printing its first "login: " prompt, although it did not have the problem
on a subsequent reboot.  This other machine did not lock up with
2.5.6-pre3 or 2.5.6, although that is probably just due to random
chance, as the problem was occurring only once a day.  The
IDE controller in this second machine is:

00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)

	I will try to track this down from the process stack traces
when it happens next, but I thought I ought to report it in the meantime.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: IDE(?) lockups in 2.5.7pre1, 2.5.6, 2.5.6pre3

[Martin Dalecki]

Adam J. Richter wrote:
> 	Under 2.5.6-pre3 and 2.5.6, my desktop workstation would
> occasionally get into a state where all disk I/O would block.
> Process would run until they had to go to the disk, and then they
> would stop.  Hitting ctrl-<scroll lock> shows these process in "D"
> state.  The IDE controller in this machine is:
> 
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> 
> 	I just built 2.5.7-pre1 and have discovered the other machne
> that has a VIA IDE controller developed the same problem just after
> printing its first "login: " prompt, although it did not have the problem
> on a subsequent reboot.  This other machine did not lock up with
> 2.5.6-pre3 or 2.5.6, although that is probably just due to random
> chance, as the problem was occurring only once a day.  The
> IDE controller in this second machine is:
> 
> 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> 
> 	I will try to track this down from the process stack traces
> when it happens next, but I thought I ought to report it in the meantime.
> 

You may have noted that I'm gradually trying to replace
all cli() sti() stuff, where it's using for data structure
access by proper spin locks on ide_lock. Maybe this just
uncovered something which was hidden by the brute force used
before? (Could you possible have a look at this direction?)

Re: IDE(?) lockups in 2.5.7pre1, 2.5.6, 2.5.6pre3

[Vojtech Pavlik]

On Wed, Mar 13, 2002 at 04:38:58PM +0100, Martin Dalecki wrote:

> Adam J. Richter wrote:
> > 	Under 2.5.6-pre3 and 2.5.6, my desktop workstation would
> > occasionally get into a state where all disk I/O would block.
> > Process would run until they had to go to the disk, and then they
> > would stop.  Hitting ctrl-<scroll lock> shows these process in "D"
> > state.  The IDE controller in this machine is:
> > 
> > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> > 
> > 	I just built 2.5.7-pre1 and have discovered the other machne
> > that has a VIA IDE controller developed the same problem just after
> > printing its first "login: " prompt, although it did not have the problem
> > on a subsequent reboot.  This other machine did not lock up with
> > 2.5.6-pre3 or 2.5.6, although that is probably just due to random
> > chance, as the problem was occurring only once a day.  The
> > IDE controller in this second machine is:
> > 
> > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> > 
> > 	I will try to track this down from the process stack traces
> > when it happens next, but I thought I ought to report it in the meantime.
> > 
> 
> You may have noted that I'm gradually trying to replace
> all cli() sti() stuff, where it's using for data structure
> access by proper spin locks on ide_lock. Maybe this just
> uncovered something which was hidden by the brute force used
> before? (Could you possible have a look at this direction?)

I have a similar report with 2.5.6 and PIIX from  Helge Hafting
<helgehaf@aitel.hist.no>:

	I saw nothing unusual until I tried a simple benchmark:

	# hdparm -t /dev/hda

	Nothing happened with the disk, the process
	got stuck in D state immediately and just sits there.

	The drives works though, "ls -R" works for partitions
	on either drive.

It looks like you uncovered or created some race ...

-- 
Vojtech Pavlik
SuSE Labs