Re: Panic on pxeboot: kernel trap 12 with interrupts disabled

Don Lewis wrote (2004/02/17):
> On 16 Feb, Robert Watson wrote:
> > I'm not sure when this began, but my pxeboot test box at work seems pretty
> > unhappy.  I'll attempt to extract more debugging information, but here's a
> > first pass.  Looks like map->system_map is NULL.
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x91
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x8:0xc07ba4b9
> > stack pointer           = 0x10:0xc0c21b3c
> > frame pointer           = 0x10:0xc0c21b4c
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 0 ()
> > kernel: type 12 trap, code=0
> > Stopped at      0xc07ba4b9:     cmpb    $0,0x91(%edx)
> > ...
> My Thinkpad is crashing the same way at boot with a very recent version
> of -CURRENT. The stack trace looks similar, and the fault address is
> also 0x91. I'm booting of disk, so the problem isn't specific to
> pxeboot.  I didn't have any problems with a kernel from Friday the 13th.

Hello, I have exactly the same problem on my Asus L4000L notebook. It
panics even with kernel without modules with acpi disabled. Currently
I'm trying to find the responsible commit. It panics in vm_map.c in
_vm_map_lock_read on (map->system_map) condition. if (map->system_map):

PS: I have another big problem: It seems that there is some long-time
kernel memory leak in -current, my last tested kernel is from February 5.
I have permanent problems with slowly growing kernel memory on
ftp-master.cz.FreeBSD.org. I have created simple utility, which
periodically reads the size of actual kernel memory usage, and here are
latest results (date time: size (min-vnodes, current-vnodes, max-vnodes):

2004/02/05 00:00: 166522880 (33648, 94751, 134594)
2004/02/06 00:00: 177364992 (33648, 94751, 134594)
2004/02/07 00:00: 190513152 (33648, 94751, 134594)
2004/02/08 00:00: 208490496 (33648, 94751, 134594)
2004/02/09 00:00: 238510080 (33648, 121383, 134594)
2004/02/10 00:00: 253415424 (33648, 121383, 134594)
2004/02/11 00:00: 265097216 (33648, 121383, 134594)
2004/02/12 00:00: 278380544 (33648, 121383, 134594)
2004/02/13 00:00: 290336768 (33648, 121383, 134594)
2004/02/14 00:00: 302579712 (33648, 121383, 134594)
2004/02/15 00:00: 315408384 (33648, 121383, 134594)
2004/02/16 00:00: 329408512 (33648, 121383, 134594)
2004/02/17 00:00: 348073984 (33648, 121383, 134594)

I have set limit to vm.kmem_size="400000000", so if anybody have good
idea, what to track before the next panic, I have some days yet ;o)
The responsibility is on:

# vmstat -m
...
         cred1294208161776K 161778K  5449033  128
...

My today's plan was to dig into kernel memory and try to find/look for
stale cred allocations, but I'm stopped because of this higher-priority
panics on my notebook.

-- 
Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66  Brno, Czech Republic