Re: page fault in _mtx_lock_flags

2002-04-29 Thread John Baldwin
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

Re: page fault in _mtx_lock_flags

2002-04-29 Thread Robert Watson
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

Re: page fault in _mtx_lock_flags

2002-04-29 Thread Dag-Erling Smorgrav
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 --

Re: page fault in _mtx_lock_flags

2002-04-28 Thread Robert Watson
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

Re: page fault in _mtx_lock_flags

2002-04-28 Thread Robert Watson
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