>Number:         10027
>Category:       kern
>Synopsis:       RAIDframe panic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 01 11:52:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        1.4.2
>Organization:
>Environment:
I believe the userland and kernel on this machine are straight 1.4.2.
System: NetBSD ichi 1.4.2 NetBSD 1.4.2 (ICHI) #0: Tue Apr 18 21:08:34 EDT 2000 nemo@ichi:/usr/src/sys/arch/i386/compile/ICHI i386


>Description:
I have seen ichi crash twice panicing in kmem_map.  The first time I did not
remember to get a stack trace; the second time, I manually transcribed the
stack trace that appears later in this message.  Note that since I haven't
gotten a serial console set up on this machine, I had to type it by hand
(saying `reboot' doesn't get a crash dump because the system is too wedged
to write to disk), so after about the twentieth function I got tired of
transcribing all of the hex numbers and stopped.  Also, because I copied the
data by hand, there is some chance that the numbers may have gotten manged;
I suspect I copied with about 98% accuracy or better, but keep that in mind
if things don't make sense.

There are a couple of things about ichi that are non-standard; first, for
various bizarre reasons it has laptop hard disks which are much slower than
3.5" IDE disks.  Second, it has this line in its config:
options         NMBCLUSTERS=16384
I do not know whether either of these facts are relavent to the problem
with the kernel panicing, but I do not know enough to feel confident that these
are unrelated.


db> trace
_Debugger(c,0,0,c9f3c928,c017251f) at _Debugger+0x4
_panic(c0172270,c0b40600,5,870,1000) at _panic+0x55
_malloc(870,5d,0,0,c0b31c00) at _malloc+0x1d3
_rf_CreateRaidOneWriteDAG(c05e4000,c0b40600,c0b461100,c1007b7c,9,c0b6e800) at _rf_CreateRaidOneWriteDAG+0xee
_rf_SelectAlgorithm(c05ff800,9,0,c05ff800,5) at _rf_SelectAlgorithm+0x134c
_rf_State_CreateDAG(c05ff800,c05e4000,c05ff800,c1007b7c,4) at _rf_State_CreateDAG+0x23
_rf_ContinueRaidAccess(c05ff800,31c3ba,c05e4000,c1007b7c,1) at _rf_ContinueRaidAccess+0x86
_rf_DoAccess(c05e4000,77,1,31c3ba,0,80,0,3178000,c1007b7c,0,0,8,0,0,0) at _rf_DoAccess+0x225
_raidstart(c05e4000) at _raidstart+0x1cd
_raidstrategy(c1007b7c,c9f3cd04,c022928f,c9f3cd1c,ffffffff) at _raidstrategy+0x123
_spec_strategy(c9f3cd1c,ffffffff,c1007b7c,0,c9de6db8) at _spec_strategy+0x27
_ufs_strategy(c9f3cd1dc) at _ufs_strategy+0xcf
_bwrite(c1007b7c,c9f3cd44,c0190184,c9f3cd3c,c02a1480) at _bwrite+0xd0
_vn_bwrite(c9f3cd3c,c02a1480,c1007b7c,c9f3cd6c,c01920f3) at _vn_bwrite+0xe
_bawrite(c1007b7c) at _bawrite+0x30
_cluster_wbuild
_cluster_write
_ffs_write
_vn_write
_dofilewrite
_sys_write
_syscall

>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: