On Sat, 30 Oct 2004 13:47:45 +1000, CaT [off-list ref] wrote:

On Wed, Oct 27, 2004 at 03:51:14PM +0200, Bartlomiej Zolnierkiewicz wrote:

quoted

http://bugme.osdl.org/show_bug.cgi?id=2494

Tried it via bk7, wasn't it.

Looks like I have found a bug relating to the pdc driver though.

The situation is such: I have 2 HDs connected to a PDC20267 PCI card,
one on each channel, with a master on the primary channel and a slave on
the secondry channel. Accessing each drive individually causes no
problems at all but accessing them simultaneously (like copying data off
one drive onto the other) causes the IDE layer to go to hell in a hand
basket. I can duplicate this each and every time by doing the following:

1. copying a few gig from hde to hdh
2. dd if=/dev/hde of=/dev/null
   dd if=/dev/zero of=/dev/hdh

With method #1 I get the following:

Oct 27 00:37:39 nessie kernel: attempt to access beyond end of device
Oct 27 00:37:39 nessie kernel: hdh1: rw=1, want=3034756264, limit=390716802
Oct 27 00:37:40 nessie kernel: Aborting journal on device hdh1.
Oct 27 00:37:40 nessie kernel: ext3_abort called.
Oct 27 00:37:40 nessie kernel: EXT3-fs error (device hdh1): ext3_journal_start: Detected aborted journal
Oct 27 00:37:40 nessie kernel: Remounting filesystem read-only
Oct 27 00:37:40 nessie kernel: EXT3-fs error (device hdh1) in start_transaction: Journal has aborted

This comes from the block layer, generic_make_request(),
request is screwed up before it hits IDE layer.

With method #2, a whole lot more fun occurs. The logfile I have is big
(almost 400k) so I've compressed it and included it as an attachment.
This is with kernel 2.6.10-rc1-bk7 (no logs survived from me testing
this with rc1-mm2).

Indeed, this is a lot more fun. ;)

Is this bug new/old?

Is it pdc202xx_old specific?  Does the same havoc happen
if you connect drives to the on-board Intel IDE controller?

Please post /proc identify data for both drives and PCI config
space dump for PDC20267 so someone can verify them.