On 29-Apr-2002 Robert Watson wrote:
If I apply the attached diff to the kern_malloc.c, backing out a portion
of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could
have a box panic within five minutes of getting the crash boxes spinning.
Now I've been going for about 40
On Mon, 29 Apr 2002, John Baldwin wrote:
On 29-Apr-2002 Robert Watson wrote:
If I apply the attached diff to the kern_malloc.c, backing out a portion
of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could
have a box panic within five minutes of getting the crash
John Baldwin [EMAIL PROTECTED] writes:
On 28-Apr-2002 Robert Watson wrote:
db trace
_mtx_lock_flags(79747473,0,c03cb862,e3) at _mtx_lock_flags+0x42
Same here. See the first arg which is supposed to be a mutex pointer.
ytts
stty, actually, since the i386 is little-endian.
DES
--
I also get an almost identical fault on crash1 involving mdconfig as
opposed to sh:
ray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
8.50.10 BroadcasP-Address 192.16
t 192.168.50.255
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
If I apply the attached diff to the kern_malloc.c, backing out a portion
of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could
have a box panic within five minutes of getting the crash boxes spinning.
Now I've been going for about 40 minutes without any perceived failures