2.5.31 boot failure on pdc20267
Quoted 12 lines · Mikael Pettersson
Quoted 10 lines · Petr Vandrovec
Quoted 4 lines · Mikael Pettersson
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.cin your favorite text editor, look for (first) #ifdefCONFIG_BLK_DEV_TRM290, and replace whole ifdef block with '*--table |=cpu_to_le32(0x80000000);'
Quoted 8 lines
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 [email protected]
Quoted 1 line · Petr Vandrovec
Yes. If you'll look at d1510r0c.pdf from ATA guys, you'll find that
BUZZIT!
That is an totally new transport protocol and if you research the pci device class you would know that it has nothing to do with the problem. If you guys are playing with ADMA on DMA Hosts, oh my!
The context of what is the EOT between the two HOST protocols has no meaning.
Regards,
Andre Hedrick
LAD Storage Consulting Group