Date: Fri, 25 Feb 2000 23:04:17 -0500
From: Doug Ledford <[EMAIL PROTECTED]>
OK, this has gone beyond a usefull debate. If you want to take the
high road that anything other than a perfectly sculpted SCSI bus that
does everything perfectly is a misconfiguration, and that no external
factors are allowed to influence the SCSI bus, and that everyone must
buy matched hardware all at one time instead of upgrading piecemeal,
etc., then feel free. I, on the other hand, have to worry about all
the times that users email me with problems that *I* know are SCSI
bus related problems (termination, cable length, cable type, cable
proximity to other emf producing devices such as active IDE cables,
backplanes that don't grok the latest signals but do at least know
LVD and could therefore be a cause of problems with DT transfers,
etc) but that take their system down.
Heh. You left out "expensive hot-pluggable chasis that worked fine
before it was shipped from California, but didn't after UPS dribbled it
across the country to Boston". (One or two of the plastic rails in the
chasis were cracked, so I know it must have gotton some monster
G-forces.)
The SCSI disks in the abused case mostly worked fine, except that under
heavy load, I'd see SCSI timeouts and the bus would lock up until it got
reset by the SCSI driver. I solved that one by forcing the SCSI bus
speed down from the negotiated 40 MB/s down to 32 MB/s:
## HACK: We need to slow down the SCSI bus, or things don't work right.
echo "setsync all 15" > /proc/scsi/ncr53c8xx/0
Kludgy as all hell, but it fixed the problem. I'm still curious exactly
what was the damage UPS inflicted on the case, though. Hairline crack
in one of the bus lines? Who knows.... But Doug is right; this is sort
of things you do in the real world.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
