I have a box with a three-disk RAIDframe RAID5 set. Two of the disks
are exactly the same make/model, run off separate busses on the same
Silicon Image controller. I have recently noticed that after a
reported error:

Apr 15 18:24:48 stix-pc /netbsd: cmdide0:1:0: lost interrupt
Apr 15 18:24:48 stix-pc /netbsd:        type: ata tc_bcount: 16384 
tc_skip: 0
Apr 15 18:24:48 stix-pc /netbsd: cmdide0:1:0: bus-master DMA error: 
missing interrupt, status=0x21
Apr 15 18:24:48 stix-pc /netbsd: cmdide0:1:0: device timeout, 
c_bcount=16384, c_skip0
Apr 15 18:24:48 stix-pc /netbsd: wd4a: device timeout writing fsbn 
18427840 of 18427840-18427871 (wd4 bn 18427840; cn 18
281 tn 9 sn 25), retrying
Apr 15 18:24:51 stix-pc /netbsd: wd4: soft error (corrected)

the drive seems to be in go-slow mode:

ksh$ dd if=/dev/rwd3d of=/dev/null bs=64k count=16k
16384+0 records in
16384+0 records out
1073741824 bytes transferred in 30.988 secs (34650246 bytes/sec)
ksh$ dd if=/dev/rwd4d of=/dev/null bs=64k count=16k
16384+0 records in
16384+0 records out
1073741824 bytes transferred in 129.220 secs (8309408 bytes/sec)

This seems to affect random I/O even more.

There are no recent changes in the relevant source files between
the running kernel (1.6ZI) and 2.0_BETA. Just wondering if anyone
has seen this or something similar - and what to do about it. As
yet, I have only rebooted the box. Shortly after reboot, it
generated a similar error again, with the same consequences.
I'll shortly be pulling the top off, and checking the cabling.
Might even switch wd3/4 (joys of RAIDframe :) ) and see what happens.
BTW: is there a way to interrogate the current drive transfer mode?
ie. UDMA mode 5, PIO, etc. I was expecting to see messages dumped
by wd/cmdide - just if someone knows off the top of their head,
otherwise I'll UTSL.

dmesg: <http://stix.homeunix.net:8080/about/dmesg-stix-pc.txt>

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams