tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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):
> 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...


Greg Oster

Home | Main Index | Thread Index | Old Index