On Sun, 14 Jan 2001, Vojtech Pavlik wrote:
> > > So the drive *did* work on the vt82c686a in the A7V board? You tested it
> > > both on the Promise and on the 686a? But doesn't work on the 686a in
> > > your other board?
> >
> > Yes, on both the Promise and on the 686a. But the device revisions are
> > different. The machine that does NOT work:
> >
> > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
> > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> >
> > The machine that works:
> >
> > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> >
> > The one the works is a 1 GHz Athlon, and the other is an 800 MHz
> > Pentium-III.
Of course is isn't. The vt82c686 that does not work is a 450 MHz K-6, not
a PIII.
> > > > no matter what cable I use. When I get this, the machine does not recover
> > > > most of the time, and I have to reset or power cycle.
> > >
> > > It should be able to recover in a couple (up to 10) minutes ...
> >
> > Who waits 10 minutes for a timeout? Can it be lowered?
>
> It's not a 10 minute timeout, it's a shorter timeout retried many times.
> Not my code, though - this is generic PCI IDE code, and is a huge mess.
What I get is a number of Busy and Drive is not ready for command for
different sectors.
> > Expect another mail with the data you requested within a couple of hours.
>
> Thanks a lot.
Ok, it took a bit longer that that, mostly because me and my whife had
unexpected (but very welcome) guests at home. It is Sunday, after all...
I have attached a tar file with "lspci -vvxxx" and "hdinfo -i" for machine
1 and 2 to this mail, but first some comments.
I will be talking about three machines:
1) 450 MHz K-6 on an AOpen MX59 PRO II motherboard
2) 800 MHz PIII on an unknown cheap/crappy motherboard.
3) 1 GHz Athlon on an ASUS A7V motherboard.
and the following drives:
A) SAMSUNG VG34323A, sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2
B) ST38421A, mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4
Machine 3 is the machine at home, and it does not have problems with any
disks I have tried soo far, and seems very stable, both with ATA100 and
ATA66.
I verified that what is happening when RH7 tries to remount / read-write,
is that I get the infamous CRC errors. It does not seem to recover from
this state. At least I did not wait that long.
I do not think that the RH7 kernel 2.2.16-22 uses udma2 at any time, and
that may be why it works.
Disk B does NOT work with DMA enabled with machine 1 or 2. It works
better than disk A, but it does still fail after some time. The
combination 1B was the most stable, and only failed once.
When using disk B, the computer has managed to recover from the CRC error
condition every time, as opposed to disk A which never recovers. (Busy)
Using hdparm -X65 (udma1) makes disk A work with 2.4 in machine 2. What
is the difference between udma1 and udma2?
Now I'm almost completely lost. Hope this helps. Let me know if you want
me to try something else.
/Tobias
This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 21:00:39 EST