On Mon, Dec 18, 2000 at 07:48:18PM +0100, Zdenek Kabelac wrote:
So hpt366 linux could coexists peacefully they just can't use UDMA4
mode.
I've come to the same conclusion on my bp6 with a seagate ST320430A.
--
Jonas Munsin [EMAIL PROTECTED] KeyID: 1024/98A0C47D
In message [EMAIL PROTECTED], Zdenek Kabelac writes:
ยด
Ok after this - I've also found some partial solution for this problem
which is
relatively easy - degrading hpt366 from UDMA 4 to UDMA 2 with 'hdparm
-X66
/dev/hdf' - after issuing this command all my test had never failed (8
copies
In message [EMAIL PROTECTED], Zdenek Kabelac writes:
How about UDMA 3 (UATA 44) ?
hdparm -X67 /dev/hdf
For me UDMA 3 works (but not anything higher).
I've forget to mention that while checking my computer with
SiSandra MSWindows software - it has shown some warning for
hpt366
On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
BP6 hpt366 is completely bad piece of hardware (I hope it's not that
bad)
Unfortunately this is your answer. It will even lockup using PIO mode.
It also locks up under Windoze, so it's not a "linux driver problem".
Although Andre has said it's a
On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
BP6 hpt366 is completely bad piece of hardware (I hope it's not that
bad)
Unfortunately this is your answer. It will even lockup using PIO mode.
It also locks up under Windoze, so it's not a "linux driver problem".
Why its not locking with
On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
BP6 hpt366 is completely bad piece of hardware (I hope it's not that
bad)
Unfortunately this is your answer. It will even lockup using PIO mode.
It also locks up under Windoze, so it's not a
Ahmon Dancy wrote:
I suspect that going to UDMA2 just makes the problem harder
to reproduce due to the reduced load.
Or it could be something intrinsic about PCI busmastering
timings. I would try different PCI latencies in the BIOS.
Higher numbers mean a device can hog the bus for
