>Number:         10182
>Category:       kern
>Synopsis:       raidctl -u while partity rewrites panics
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 23 08:41:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Manuel Bouyer
>Release:        -current as of a few days ago
>Organization:
	LIP6
>Environment:

System: NetBSD disco 1.4Y NetBSD 1.4Y (DS20-siop) #8: Tue May 23 12:23:10 MEST 2000 bouyer@disco:/home/src/sys/arch/alpha/compile/DS20-siop alpha


>Description:
	I have a raid 1 volume, composed of 20 disks:
START array
# numRow numCol numSpare
1 20 0
START disks
/dev/sd10a
/dev/sd30a
/dev/sd40a
/dev/sd20a
/dev/sd31a
/dev/sd11a
/dev/sd21a
/dev/sd41a
/dev/sd12a
/dev/sd32a
/dev/sd42a
/dev/sd22a
/dev/sd33a
/dev/sd13a
/dev/sd23a
/dev/sd43a
/dev/sd14a
/dev/sd34a
/dev/sd44a
/dev/sd24a
START layout
# sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level
64 1 1 1
START queue
fifo 100

	Parity rewrite is initiated at boot and can take a long time.
	When trying to unconfigure the raid device while the parity
	is being rewritten (raidctl -u) the machine panics with a trap.
	stack trace is:
db> tr
cpu_Debugger() at cpu_Debugger+0x4
panic() at panic+0xec
trap() at trap+0x6b4
XentMM() at XentMM+0x20
--- memory management fault (from ipl 6) ---
rf_DispatchKernelIO() at rf_DispatchKernelIO+0x278
rf_DiskIOEnqueue() at rf_DiskIOEnqueue+0x2d4
rf_DiskReadFuncForThreads() at rf_DiskReadFuncForThreads+0x178
FireNodeList() at FireNodeList+0x2b4
PropagateResults() at PropagateResults+0x6b0
rf_FinishNode() at rf_FinishNode+0x120
rf_NullNodeFunc() at rf_NullNodeFunc+0x24
FireNodeArray() at FireNodeArray+0x2d4
rf_DispatchDAG() at rf_DispatchDAG+0x158
rf_VerifyParityRAID1() at rf_VerifyParityRAID1+0x6a8
rf_VerifyParity() at rf_VerifyParity+0x8c
rf_RewriteParity() at rf_RewriteParity+0xdc
rf_RewriteParityThread() at rf_RewriteParityThread+0x54
esigcode() at esigcode
--- root of call graph ---

	This is annoying as it can happen at reboot time.
	I didn't try with a recontruction instead of parity rewrite,
	maybe the same problem can happen.

>How-To-Repeat:
	raidctl -i raid2
	raidctl -u raid2
>Fix:
	I guess abort the parity rewrite before unconfiguring ?
>Release-Note:
>Audit-Trail:
>Unformatted: