Okay, we've spent the day looking at hardware signals on the PCI bus, to =
see if we could clarify the problem further (now you know we're getting =
desperate: trying to analyze PCI signals!) So, we put a Promise PCI IDE =
Controller into a slot, with a disk that it recognises as PIO 4, DMA 2, =
UDMA 2.

We boot up, and during bootup, DMA transfers (reading from the disk I =
supppose) work perfectly - the REQuest and GraNT lines show the Promise =
requesting the bus, and being granted it, and doing the transfers. We =
are given a login prompt and log in. Now things go wrong. I wrote two =
programs - one to read 512 dwords from the disk into memory, and one to =
write 512 dwords from memory to the disk (/dev/rwd0g). When  I try and =
run either of these, the operating system stop functioning immediately: =
that is, even before the Promise asserts its REQuest line! I also tried =
to run "dd if=3D/dev/zero of=3D/dev/rwd0g count=3D2048", but the same =
results.

At the point where it hangs, I get a message:
  pciide0:0:0: lost interrupts
    type: ata
    c_bcount: 512
    c_skip: 0

  The 21285 status register shows a MAster Abort in the status register, =
although I don't know if this is relevant. Then I get:
  pciide0:0:0: Bus-Master DMA error: status =3D0x22 ("Error" and "DMA =
Capable" bits set)
  wd0g: DMA error writing fsbn 0 (wd0 bn 4152800; cn 4394; tn 7; sn 29), =
retrying
  pciide0:0:0 not ready, st=3D0x00 err=3D0x00

Followed by "device timeout" messages continuously. The O/S does recover =
after about 3 minutes of these messages, but reports a -1 for the number =
of bytes written (error).=20

I think a big clue in the whole thing is the fact that DMA disk =
transfers work before login, and not after (it also crashes if an fsck =
is done by the system before login, though!). Another clue is that the =
Promise doesn't even make a REQuest for the PCI bus???

We have other devices, (a FrameGrabber card we designed) using DMA =
transfers perfectly, so at least we know the hardware is capable of DMA =
transfers!

Two questions:
  Philip: you seem to put your RAM in the secondary slot, judging by the =
21285 ram registers -  is this for a reason?
  I have attached my disklabel below: perhaps there is something wrong =
with that???

Otherwise, please let me know if any of this means anyything to you, and =
you could possibly give me a clearer idea of where the problem lies!

Oh yes, we are currently using a Western Digital drive, and I 've heard =
some of them are dody with DMA, so I'll try a Seagate drive so long, to =
see if it works any better.

Thanks
 Bruce

Disklabel:
# /dev/rwd0c
type: unknown
disk: WDC AC11200L
label: 1234567890
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 15
sectors/cylinder: 945
cylinders: 13328
total sectors: 12594960
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0
track-to-track seek: 0
drivedata: 0

8 partitions:
#	size		offset		fstype	[fsize	bsize	cpg]
a:	143360		0		4.2BSD	1024	8192	16
b:	61440		143360		4.2BSD	1024	8192	16
c:	12594960	0		unused	0	0
e:	2048000	204800		4.2BSD	1024	8192	16
f:	1900000	2252800	4.2BSD	1024	8192	16
g:	8350000	4158200	4.2BSD	1024	8192	16

What disks do you guys have working???

Thanks
 Bruce