Re: mpt(4) hickups (was: RAIDframe component scrubbing)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

        Hello.  Yes, those are exactly the errors I've been working with.
The fixes will let the machine continue running despite that error and will
let all the other disks continue functioning even if sd3 fails.  I agree
with you, however, that you may hav a cabling issue.  Also, check  your
terminators.
-Brian

On Sep 11,  2:12pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: mpt(4) hickups (was: RAIDframe component scrubbing)
} > I have been working on improving error handling for the mpt(4) driver.
} [...]
} > The fixes address issues when the IOC hickups and help to get the IOC back
} > on-line if it goes out to lunch.
} The problem I faced (second time today, but I don't have logs -- see below) 
was
} 
} Sep  7 03:21:38 donau /netbsd: sd3(mpt0:0:3:0): command timeout
} Sep  7 03:21:38 donau /netbsd: mpt0: timeout on request index = 0x8a, seq = 
0x1655bf37
} Sep  7 03:21:38 donau /netbsd: mpt0: Status 0x00000000, Mask 0x00000001, 
Doorbell 0x24000000
} Sep  7 03:21:38 donau /netbsd: mpt0: request state: On Chip
} 
} Is this the type of problem your fix adresses?
} What worries me is that today, I got the same error again, on the same disc.
} So I'm afraid it might be more of a cabling or disc electronics problem.
} 
} 
} This time however, I was fast enough rushing down to the server room and 
} halting the machine before it could declare sd3 failed. So I only had about 
} one hour of parity re-build (thanks to parity maps!) instead of twenty hours 
} of reconstruction.
>-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=