[parisc-linux] Dodgy SCSI in L2000

[parisc-linux] Dodgy SCSI in L2000

[James Braid]

Okay, I have got my RAID array working now :-)

BUT...

The box dies if I thrash the array with dbench (using anymore than 10
clients), or sometimes when making a filesystem on the array (I have
been able to make a filesystem about once every ten times).

It does the same thing on both SMP and non-SMP kernels.

The raid array looks okay (its 18Gb * 3 in RAID0):

hypo:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5]
read_ahead 1024 sectors
md0 : active raid0 scsi/host4/bus0/target2/lun0/part1[2]
scsi/host4/bus0/target0/lun0/part1[1]
scsi/host0/bus0/target2/lun0/part1[0]
      53320656 blocks 4k chunks

unused devices: <none>

Now, I try to make a ext2 FS on the array, and it dies like so:

hypo:~# mke2fs /dev/md0
mke2fs 1.27 (8-Mar-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
6668288 inodes, 13330164 blocks
666508 blocks (5.00%) reserved for the super user
First data block=0
407 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
        4096000, 7962624, 11239424

Writing inode tables: done
Writing superblocks and filesystem accounting information:
^^^^ dies here, just hangs the login session

In the window I have open to the GSP (in a console session) on the
L2000, I see this:

sym4:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:0:0: DEVICE RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:0:0: DEVICE RESET operation timed-out.
sym0:2:0: DEVICE RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: DEVICE RESET operation timed-out.
sym0:0:0: BUS RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:0:0: BUS RESET operation timed-out.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:0:0: BUS RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:0:0: BUS RESET operation timed-out.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: BUS RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: BUS RESET operation timed-out.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: BUS RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: BUS RESET operation timed-out.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:2:0: BUS RESET operation started.
sym4:2:0: ABORT operation timed-out.
sym4:0:0: DEVICE RESET operation started.
sym0:2:0: BUS RESET operation timed-out.
sym4:0:0: DEVICE RESET operation timed-out.
sym4:2:0: DEVICE RESET operation started.
sym0:2:0: BUS RESET operation started.
sym4:2:0: DEVICE RESET operation timed-out.
sym4:0:0: BUS RESET operation started.
sym0: SCSI BUS reset detected.
sym0: SCSI BUS has been reset.
sym4: SCSI BUS reset detected.
sym4: SCSI BUS has been reset.
sym4:0:0: BUS RESET operation complete.
sym0:2:0: BUS RESET operation complete.
sym4:0:0: ABORT operation started.
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:0:0: ABORT operation started.
sym4:0:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym0:2:0: ABORT operation timed-out.
sym0:2:0: ABORT operation started.
sym4:2:0: ABORT operation timed-out.
sym4:2:0: ABORT operation started.

Which loops over and over and over and over..

It also does the same thing using the sym5c8xx version 1 driver as well
as the version 2 driver (the above errors are from the version 2
driver).

At this point the box is totally unusable.

I then hit CTRL-\, and got this:

May  7 16:23:16 hypo kernel:
May  7 16:23:16 hypo kernel:      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
May  7 16:23:16 hypo kernel: PSW: 00000000000000000000000000000000 Not
tainted
May  7 16:23:16 hypo kernel: r00-03  0000000000000000 0000000040050d00
000000004003d8bb 00000000000291a0
May  7 16:23:16 hypo kernel: r04-07  0000000000000000 0000000040051500
00000000000290a0 0000000000000004
May  7 16:23:16 hypo kernel: r08-11  0000000040051500 0000000000cb8000
0000000000000197 0000000000036890
May  7 16:23:16 hypo kernel: r12-15  0000000000038ad0 0000000000000197
0000000000000800 0000000000000040
May  7 16:23:16 hypo kernel: r16-19  000000000000ffff 0000000000000001
0000000000000004 00000000401d9ab0
May  7 16:23:16 hypo kernel: r20-23  0000000000000076 00000000401d9ab0
00000000401646a8 00000000bff005c8
May  7 16:23:16 hypo kernel: r24-27  0000000000001000 0000000000035880
0000000000000003 0000000000027b18
May  7 16:23:16 hypo kernel: r28-31  0000000000000000 0000000000000032
00000000bff00440 00000000401646b3
May  7 16:23:16 hypo kernel: sr0-3   0000000000000480 0000000000000480
0000000000000000 0000000000000480
May  7 16:23:16 hypo kernel: sr4-7   0000000000000480 0000000000000480
0000000000000480 0000000000000480
May  7 16:23:16 hypo kernel:
May  7 16:23:16 hypo kernel: IASQ: 0000000000000480 0000000000000480
IAOQ: 0000000040113a2f 0000000040113a33
May  7 16:23:16 hypo kernel:  IIR: 6b540028    ISR: 0000000000000480
IOR: 000000000003d000
May  7 16:23:16 hypo kernel:  CPU:        0   CR30: 000000004c1bc000
CR31: 0000000010460000
May  7 16:23:16 hypo kernel:  ORIG_R28: 0000000000000000


After this has finished dumping, the box is usable again.

One thing I have noticed with mke2fs is that the indode table numbers
tick away pretty fast until it gets to 205, then it slows down big time,
and then it speeds up again until it gets to ~340, at which point the
scsi ABORT errors will sometimes start happening.

I have tested all the disks individually (making filesystems, running
dbench), and the filesystems get made fine, and dbench works okay up to
about 100 odd clients.

I have *no* idea what is causing any of this....anyone else have any
hints/info/fixes for this problem? (Sorry for the long email, but I
figured it would be best to paste the full errors)

I can provide clarification or more details if needed.

Cheers, James

Re: [parisc-linux] Dodgy SCSI in L2000

[Grant Grundler]

"James Braid" wrote:
> Okay, I have got my RAID array working now :-)
> 
> BUT...

Which kernel version?


> In the window I have open to the GSP (in a console session) on the
> L2000, I see this:
> 
> sym4:0:0: ABORT operation started.
> sym4:0:0: ABORT operation timed-out.
> sym4:0:0: ABORT operation started.
> sym4:0:0: ABORT operation timed-out.
...

This suggests something is wrong with that device.
Are all RAID0 disks internal? Or connected to external box?
I see further down they seem to be working fine individually.

...
> It also does the same thing using the sym5c8xx version 1 driver as well
> as the version 2 driver (the above errors are from the version 2
> driver).

Can you post lspci -v output from you L2000?
I just want to verify the built-in SCSI chips are the
same as on my A500: sym53c896.

...
> One thing I have noticed with mke2fs is that the indode table numbers
> tick away pretty fast until it gets to 205, then it slows down big time,
> and then it speeds up again until it gets to ~340, at which point the
> scsi ABORT errors will sometimes start happening.

I noticed the slow down/speed up when I built the RAID0 on the B180 as well.
No idea what causes it though.

> I have tested all the disks individually (making filesystems, running
> dbench), and the filesystems get made fine, and dbench works okay up to
> about 100 odd clients.

Can you try running two different dbench instances at the some time on
two different disks?

I had to steal the serial port from my A500 or I could do more
to at least reproduce this.

> I have *no* idea what is causing any of this....anyone else have any
> hints/info/fixes for this problem? (Sorry for the long email, but I
> figured it would be best to paste the full errors)
> 
> I can provide clarification or more details if needed.
> 
> Cheers, James
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

RE: [parisc-linux] Dodgy SCSI in L2000

[James Braid]

> Which kernel version?
Ooops, forgot to include this, its:

2.4.18-pa24, and
2.4.18-pa23 
 
> This suggests something is wrong with that device.
> Are all RAID0 disks internal? Or connected to external box?
> I see further down they seem to be working fine individually.

All disks are internal disks in the hotswap cage thing, connected to the
core I/O board (? not sure if that's what its called , it's a big board
with 3 SCSI cables on it and the ethernet jack/external SCSI). All the
disks are plugged into this, two disks per cable, and the DVD on its own
cable.

> Can you post lspci -v output from you L2000?
> I just want to verify the built-in SCSI chips are the
> same as on my A500: sym53c896.

Sure:

hypo:~# lspci -v
00:00.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 41)
        Subsystem: Hewlett-Packard Company: Unknown device 104f
        Flags: bus master, medium devsel, latency 128, IRQ 128
        I/O ports at 0080 [size=128]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at fffff800 [size=256K]

00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c896 (rev 05)
        Flags: bus master, medium devsel, latency 0, IRQ 129
        I/O ports at 0100 [size=256]
        Memory at fffffff0 (64-bit, non-prefetchable) [size=1K]
        Memory at fffffff0 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2

00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c896 (rev 05)
        Flags: bus master, medium devsel, latency 0, IRQ 130
        I/O ports at 0200 [size=256]
        Memory at fffffff0 (64-bit, non-prefetchable) [size=1K]
        Memory at fffffff0 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2

00:02.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
        Flags: bus master, medium devsel, latency 0, IRQ 130
        I/O ports at 0300 [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=4K]

00:02.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
        Flags: bus master, medium devsel, latency 0, IRQ 131
        I/O ports at 0400 [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=4K]

00:04.0 Serial controller: Hewlett-Packard Company: Unknown device 1048
(rev 02) (prog-if 02 [16550])
        Subsystem: Hewlett-Packard Company: Unknown device 1049
        Flags: bus master, medium devsel, latency 0, IRQ 132
        BIST result: 00
        Memory at fffffff0 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 0040 [size=64]

00:05.0 Serial controller: Hewlett-Packard Company: Unknown device 1048
(rev 02) (prog-if 02 [16550])
        Subsystem: Hewlett-Packard Company: Unknown device 104a
        Flags: medium devsel, IRQ 133
        BIST result: 00
        Memory at fffffff0 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 0500 [size=64]

08:02.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI
(rev 05)
        Subsystem: QLogic Corp.: Unknown device 0000
        Flags: medium devsel, IRQ 194
        I/O ports at 10000 [disabled] [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [disabled]
[size=4K]
        Expansion ROM at fffff800 [size=64K]

08:03.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI
(rev 05)
        Subsystem: QLogic Corp.: Unknown device 0000
        Flags: medium devsel, IRQ 195
        I/O ports at 10100 [disabled] [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [disabled]
[size=4K]
        Expansion ROM at fffff800 [size=64K]

20:00.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 04)
        Flags: bus master, medium devsel, latency 0, IRQ 384
        I/O ports at 40000 [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=256]
        Memory at fffffff0 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at fffff800 [size=64K]

The Qlogic cards I put in as I was going to move the scsi drives onto
them, but then I found out that the Qlogic ISP driver doesn't compile
for PA-RISC (doh!). The problem happens with or without the Qlogic
boards in there.

> Can you try running two different dbench instances at the some time on
> two different disks?

On three disks (sdb/sdc/sdd):

hypo:/sdb# dbench 10
10 clients started
..........

hypo:/sdc# dbench 10
10 clients started
..............

hypo:/sdd# dbench 10
10 clients started
........................................................................
................................................

None of them finish, and I get a ton of both bus and device
RESETS/ABORTS on the GSP terminal.

On two disks (sdc/sdc):

hypo:/sdb# dbench 10
10 clients started
......................................

hypo:/sdc# dbench 10
10 clients started
...............

Pretty much the same thing, lots of RESETS/ABORTS. I can post these if
needed, but its pretty much just more of what was in my first message.
It all goes pear shaped after this with lots of I/O errors and EXT2
errors, e.g.

EXT2-fs error (device sd(8,17)): ext2_write_inode: unable to read inode
block - inode=1357217, block=2719749
 I/O error: dev 08:11, sector 9961512
 I/O error: dev 08:11, sector 0

I will try again with dbench on just one disk at a time as well.

Thanks, James.

Re: [parisc-linux] Dodgy SCSI in L2000

[Grant Grundler]

"James Braid" wrote:
> 2.4.18-pa24, and
> 2.4.18-pa23 

ok - those are running mostly ok on the A500.
Still have stability problems.

Our best 2.4.18 kernel so far is the non-SMP kernel I built for -pa7.
See ftp.parisc-linux.org/kernels/a500.

> > This suggests something is wrong with that device.
> > Are all RAID0 disks internal? Or connected to external box?
> > I see further down they seem to be working fine individually.
> 
> All disks are internal disks in the hotswap cage thing, connected to the
> core I/O board (? not sure if that's what its called , it's a big board
> with 3 SCSI cables on it and the ethernet jack/external SCSI). All the
> disks are plugged into this, two disks per cable, and the DVD on its own
> cable.

This still sounds like a problem with the cable or termination.

> 00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
> NCR) 53c896 (rev 05)
...
> 00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
> NCR) 53c896 (rev 05)

yeah - this is the same thing.

...
> The Qlogic cards I put in as I was going to move the scsi drives onto
...

I don't expect the extra cards to cause any problems.

...
> I will try again with dbench on just one disk at a time as well.

That sounds like a good idea.

Another general warning: we haven't tested L2000 as much as other boxes.

I've taken a quick look at sym53c8xx driver and the first routine
I look at has a sequence I don't like to see:
static void ncr_chip_reset (ncb_p np)
{
	OUTB (nc_istat, SRST);
	UDELAY (10);
	OUTB (nc_istat, 0);
}

This sequence is fine when using IO port space but not OK
for MMIO space. (posted write preceding a udelay and nothing
to force the clearing of SRST down).

Can you try a kernel with SCSI_NCR_IOMAPPED=y?

grant

RE: [parisc-linux] Dodgy SCSI in L2000

[James Braid]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Our best 2.4.18 kernel so far is the non-SMP kernel I built for
> -pa7. See ftp.parisc-linux.org/kernels/a500.
> 

Okay, I will take a look at that, thanks.

> Can you try a kernel with SCSI_NCR_IOMAPPED=y?

Yep. The kernels I am currently running already have that option set.
I read something about SCSI not working without it, so I tried
enabling it. Didn't really seem to have any affect on the problems I
have been having.

I will try mucking with the termination and cables, but they should
be okay right? I mean, this box hasn't been opened or touched since
(hardware wise) since we got it from HP.

Thanks, James.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPNiGGVW+bhIOiSqWEQIzGgCgz7SCN7qCJT6UNIfe9gO3lIsYbJIAn2KB
lDBYV2Sjd1GQMrHd9HnVM1iS
=azxw
-----END PGP SIGNATURE-----

RE: [parisc-linux] Dodgy SCSI in L2000

[James Braid]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, I have just been thrashing my L2000, one disk at a time with
dbench (up to 100 clients, havent tried any more), one disk at a
time, and it has held up fine (i.e. no ABORTS/RESETS or anything).
Yet as soon as I run dbench concurrently over more than one disk
(whether in a RAID array or just fire up 2 dbench's on different
disks, the SCSI driver goes mental with ABORTS and RESETS in the
error log. 

The SCSI termination and cabling *should* be fine, as nobody here has
touched the box since we got it from HP. I cant be sure on the cables
though as we have no replacement cables for it.

This is really weird, anybody have further ideas about this one?

Cheers, James

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPNizVVW+bhIOiSqWEQLb8gCgi6S7nm8amd9gIFMYpvkyCYFXRV4AoOQG
5Zg346MvhtAALRg218WsjV17
=R9aP
-----END PGP SIGNATURE-----

Re: [parisc-linux] Dodgy SCSI in L2000

[Grant Grundler]

"James Braid" wrote:
> > Can you try a kernel with SCSI_NCR_IOMAPPED=y?
> 
> Yep. The kernels I am currently running already have that option set.
> I read something about SCSI not working without it, so I tried
> enabling it. Didn't really seem to have any affect on the problems I
> have been having.

The -pa7 I built has:
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set

Of those, the _SYNC param is probably the one you want to twiddle.
That sets the SDTR ceiling for all scsi busses in the system.
While the 896 chip can do faster, termination, cable length, device
bugs, misalignment of jupiter and pluto, failure to sacrifice enough
710s, etc can cause the symptoms you described.

On the last two generations of parisc machines one can cripple individual
SCSI busses via PDC. Look at the SCSI cmd in the "configuration" menu at
boot up.  A few months back I added the PDC calls to sym53c8xx driver to
get SCSI initiator ID, width, and SDTR settings. This PDC support was
intended for Multi-initiator SCSI clusters. But is useful to cripple a
bus when the topology doesn't support the capabilities of the
interfaces or devices.


> I will try mucking with the termination and cables, but they should
> be okay right? I mean, this box hasn't been opened or touched since
> (hardware wise) since we got it from HP.

I normally expect the internal cables to be OK from HP.
But given the current issues, it's worth double checking.

The need for termination varies depending on drive types and bus speeds.
I'm talking practical here since SCSI spec *requires* the termination.

grant