On 15 Aug 02 at 22:13, Mikael Pettersson wrote:
> Petr Vandrovec writes:
> > On 15 Aug 02 at 17:15, Mikael Pettersson wrote:
> > > Booting 2.5.31 (non-bk) on hde5, a UDMA(66) Quantum Fireball
> > > on a PDC20267 add-on card, resulted in a complete hang as init
> > > came to its "mount -n -o remount,rw /" point. No visible messages
> > > or anything in the log.
> >
> > Known bug. Apply IDE113 (Aug 06, 11:02 CEST, from Martin), or just open
> > drivers/ide/pcidma.c in your favorite text editor, look for (first)
> > #ifdef CONFIG_BLK_DEV_TRM290, and replace whole ifdef block with
> > '*--table |= cpu_to_le32(0x80000000);'
>
> Tested. First time 2.5.31 + the patch booted it seemed to work, but hung
> later on while compiling a 2.4.19 kernel. No messages of any kind. The
> hang _seemed_ to coincide with the console screen blanker kicking in.
> Second boot went ok and I made sure the screen blanker wouldn't kick
> in while doing the compile, and it didn't hang.
>
> This box is the only one so far I've seen this problem on, my other
> Intel chipset boxes actually seem to work fairly well with 2.5.31.
Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
between 0b and 0c revisions definition of EOT bit (highest bit of
length) was removed. It is very unfortunate because of now host
adapters cannot prefetch across segment boundaries, because of host
adapter does not know when transfer will terminate (unless host monitors
all accesses to the disk and maintains its own set of IDE registers
(including HOB, so using > 256sectors transfers with such host adapters
which do not implement HOB is impossible)). It is also very dangerous
because of for reads when drive generates more data than expected, with
EOT flag transfer was terminated with error, but without EOT host will
just fetch random entries after last valid, and will (silently) corrupt
random memory.
And Promise implements old, safe&prefetchable, interface, while Intel
just fetches more and more PRD entries as long as drive has/wants more
data.
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:11 EST