Lars Eggert wrote:

I'm tracking down a lock order reversal for hsu@, and just came across this other locking panic twice in the last few hours.
Found a way to reproduce this at will (shell tab-completion on a filename on an NFS-mounted file system), and managed to get a core dump. Note that the panic message makes a lot more sense this time around:

panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 02000000
fault virtual address = 0x2887ff38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0259253
stack pointer = 0x10:0xeb505c94
frame pointer = 0x10:0xeb505cc0
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 = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 02000000


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 1; lapic.id = 02000000
instruction pointer = 0x8:0xc03d44ca
stack pointer = 0x10:0xeb505a0c
frame pointer = 0x10:0xeb505a18
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 2720 (tcsh)
panic: from debugger
cpuid = 1; lapic.id = 02000000
boot() called on cpu#1
Uptime: 8m43s
pfs_vncache_unload(): 3 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
224 dumpsys(&dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
#1 0xc027768e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0277c87 in panic (fmt=0xc0413084 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc01507a2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01505dc in db_command (last_cmdp=0xc047b5e0, cmd_table=0x0,
aux_cmd_tablep=0xc0472bfc, aux_cmd_tablep_end=0xc0472c00)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc015081a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01534c5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc03d4187 in kdb_trap (type=12, code=0, regs=0xeb505c54)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc03ec41c in trap_fatal (frame=0xeb505c54, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc03ec16a in trap_pfault (frame=0xeb505c54, usermode=0, eva=680001336)
at /usr/src/sys/i386/i386/trap.c:760
#10 0xc03ebcce in trap (frame=
{tf_fs = -1068498920, tf_es = 16, tf_ds = -953876464, tf_edi = -953858560, tf_esi = -965994304, tf_ebp = -347054912, tf_isp = -347054976, tf_ebx = 680001280, tf_edx = -953876480, tf_ecx = 4, tf_eax = -1, tf_trapno = 12, tf_err = 0, tf_eip = -1071279533, tf_cs = 8, tf_eflags = 66178, tf_esp = -953858508, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:446
#11 0xc03d5938 in calltrap () at {standard input}:99
#12 0xc02584c3 in dup2 (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:174
#13 0xc03ec9f6 in syscall (frame=
{tf_fs = 47, tf_es = -65489, tf_ds = -1078001617, tf_edi = 4, tf_esi = 135637504, tf_ebp = -1078036088, tf_isp = -347054732, tf_ebx = -1, tf_edx = -1078037360, tf_ecx = 136105984, tf_eax = 90, tf_trapno = 12, tf_err = 2, tf_eip = 134842063, tf_cs = 31, tf_eflags = 646, tf_esp = -1078037316, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1071
#14 0xc03d598d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---


--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to