Re: Panic _at_r205276 (Fatal trap 12: page fault while in kernel mode)

On 18 Mar 2010, at 13:48, Rui Paulo wrote:

> 
> On 18 Mar 2010, at 13:35, David Wolfskill wrote:
> 
>> On first reboot after building & installing; yesterday (_at_r205249) was OK:
>> 
>> 3  1. Boot FreeBSD [default]              3     |_|   |_|  \___|\___|
>> 3  2. Boot FreeBSD with ACPI disabled     3      ____   _____ _____
>> 3  3. Boot FreeBSD in Safe Mode           3     |  _ \ / ____|  __ \
>> 3  4. Boot FreeBSD in single user mode    3     | |_) | (___ | |  | |
>> 3  5. Boot FreeBSD with verbose logging   3     |  _ < \___ \| |  | |
>> 3  6. Escape to loader prompt             3     | |_) |____) | |__| |
>> 3  7. Reboot                              3     |     |      |      |
>> 3                                         3     |____/|_____/|_____/
>> 3                                         3
>> 3                                         3
>> 3                                         3
>> 3  Select option, [Enter] for default     3
>> 3  or [Space] to pause timer  0           3
>> _at_DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
>> 
>> 
>> GDB: no debug ports present
>> KDB: debugger backends: ddb
>> KDB: current backend: ddb
>> Copyright (c) 1992-2010 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>       The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 9.0-CURRENT #102 r205276: Thu Mar 18 06:06:56 PDT 2010
>>   root_at_freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
>> WARNING: WITNESS option enabled, expect reduced performance.
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0xf000efd2
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x20:0xc093a0c8
>> stack pointer           = 0x28:0xc142071c
>> frame pointer           = 0x28:0xc142071c
>> 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 ()
>> [ thread pid 0 tid 0 ]
>> Stopped at      strlen+0x8:     cmpb    $0,0(%edx)
>> db> bt
>> Tracing pid 0 tid 0 td 0xc0e02df0
>> strlen(f000efd2,c142086c,cccccccc,ccccccc,cccccccc,...) at strlen+0x8
>> kvprintf(c0ca617e,c08c9880,c142086c,a,c14208ac,...) at kvprintf+0x8fe
>> vsnprintf(c0e048e0,100,c0ca617e,c14208ac,0,...) at vsnprintf+0x3b
>> panic(c0ca617e,f000efd2,c0cd1cd6,dcc,c1420a68,...) at panic+0x8d
>> _mtx_lock_flags(5c,0,c0cd1cd6,dcc,c142091c,...) at _mtx_lock_flags+0x9a
>> _vm_map_lock_read(0,c0cd1cd6,dcc,5d,0,...) at _vm_map_lock_read+0x30
>> vm_map_lookup(c1420a50,f000f000,1,c1420a54,c1420a44,...) at vm_map_lookup+0x38
>> vm_fault(0,f000f000,1,0,f000ff63,...) at vm_fault+0xa5
>> trap_pfault(5,0,c0ce1b15,c0d904c0,c0e02b40,...) at trap_pfault+0x17b
>> trap(c1420b70) at trap+0x4a8
>> calltrap() at calltrap+0x6
>> --- trap 0xc, eip = 0xc08853d6, esp = 0xc1420bb0, ebp = 0xc1420bd0 ---
>> _mtx_lock_flags(f000ff53,0,c0cd0df2,9a2,0,...) at _mtx_lock_flags+0x46
>> zone_alloc_item(c0d9b5fc,c0cd12d4,c0cd11fb,c15ba000,c1420c88,...) at zone_alloc_item+0x33
>> hash_alloc(c15ba008,c0cd12d4,c0cd11fb,10,df,...) at hash_alloc+0x54
>> keg_ctor(c15ba000,80,c1420c88,2,c1420c88,...) at keg_ctor+0x234
>> zone_alloc_item(c0f7d380,180,c1420c88,c0d9b5fc,20000000,...) at zone_alloc_item+0x176
>> zone_ctor(c0f7d380,180,c1420cd8,2,c0cd33f3,...) at zone_ctor+0x1d2
>> uma_startup(c158b000,30,7ff60000,3,c158b000,...) at uma_startup+0x1db
>> vm_page_startup(c15bb000,a,c1420d88,c084f0b6,0,...) at vm_page_startup+0x1d0
>> vm_mem_init(0,141ec00,141ec00,141e000,1425000,...) at vm_mem_init+0x18
>> mi_startup() at mi_startup+0x96
>> begin() at begin+0x2c
>> db> 
>> 
> 
> I have the same panic. I'll try to revert 205266.

Yes, 205266 is the culprit.

--
Rui Paulo