Re: raidframe oddity, take three (kernel panic!)

[Greg Oster <oster%cs.usask.ca@localhost>]

der Mouse writes:
> >>> raidctl -u on [a reconstructing RAID 5], boom, instant panic in
> >>> VOP_STRATEGY inside the reconstruction code.
> >> Hmmm.... It's supposed to stop gracefully.. (it didn't used to, and
> >> I though I'd fixed that...)  If you happen to have the panic message
> >> and trace handy I'd be interested in seeing it..
> 
> uvm_fault(0xc0a0cbc0, 0, 1) -> 0xe
> kernel: supervisor trap page fault, code=0
> 
> ddb's trace says (scribbled-down copy, ie, minor errors moderately
> likely):
> 
> VOP_STRATEGY+0x1c
> rf_DispatchKernelIO+0x170
> TryToRead+0x612
> ProcessReconEvent+0x468
> rf_ContinueReconstructFailedDisk+0x282
> rf_ReconstructInPlace+0x3e7
> rf_ReconstructInPlaceThread+0x44
> 
> I have a kernel coredump from a sample crash, in case there's anything
> useful to be extracted from it.  It appears to be repeatable (and, I
> would guess, probably not a Heisenbug), so if it would be useful to
> trigger it with, say, debugging printfs added, I can do that.

Ahh.. it seems I did parity checking, but not reconstruction... 
It seems that fixing this for the reconstruction case is fairly 
straightforward... let me see what I can come up with...

Later...

Greg Oster