On Tue, 4 Apr 2000, Ricky Beam wrote:
> Are the drives jumpered for parity? If they aren't jumpered, they may not
> even calculate parity.
No parity jumpers.
> >with a device plugged in. No combinations of just cables and terminators
> >will cause this to happen.
>
> Pardon my "attitude", but _duh_. If there's nothing to talk to, where's
> it supposed to get a parity error? The terminator is just a bunch of
> resistors. Here's how this works... the initiator (scsi card) sends a
> command and data to the target (drive). The target calculates parity
> for what it received and checks it against what it should see. If it
> detects a parity error, it signals an error to the initiator (check condition
> with sense data indicating a parity error.) The initiator does the same
> check in receiving data back from the target. The parity information is
> "out of band". It's in parallel to the data on the bus -- 8bit data, 1bit
> parity -- and thus can be processed "on the fly".
Good. This means that I'm not crazy.
The thing that got me is thi: the test that the controller performs is
independent of devices. In fact, it's under a heading marked "cable
tests", and there is a separate section for "device tests". I didn't
think parity was in-band data...
So it looks like this controller is isolating me too much. I think it's
time to invest a bit more money into this problem and get a new controller
to test with
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
E: You run this ship with Windows?! YOU IDIOT!
L: Give me a break, it came bundled with the computer!
-- ESR and Lan Solaris
User Friendly, 12/8/1998
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
