I've just got what seems an unlikely panic. How could I get a privileged
instruction fault while in kernel mode?
This is from a week old 4.0-current kernel on a 16Mb 486. It has an AHA1542CF
a slow SCSI-1 disk, and a rebadged TDC4200 (2GB QIC). I run soft updates
but nothing else fancy. I was doing a make buildworld, and rewinding a
tape at the time. It seemed like the panic occurred when the tape stopped,
but I wasn't actually watching at the time.
The fatal instruction is:
0xc016abc9 <vclean+269>: movl $0xc023355c,0xffffffdc(%ebp)
which looks pretty ordinary.
Can this be a software bug? Or has my hardware gone funny? It has done a
good number of make worlds in the last few months with only the normal
(software) troubles you expect from -current.
Stephen.
Here are the gory bits, in case anyone can offer any hints:
IdlePTD 2834432
initial pcb at 248774
panicstr: from debugger
panic messages:
---
Fatal trap 1: privileged instruction fault while in kernel mode
instruction pointer = 0x8:0xc016abc9
stack pointer = 0x10:0xc30a6c20
frame pointer = 0x10:0xc30a6c54
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 = 12245 (sh)
interrupt mask = bio
panic: from debugger
panic: from debugger
dumping to dev 30401, offset 163840
dump 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:287
#1 0xc0148095 in panic (fmt=0xc021bda8 "from debugger")
at ../../kern/kern_shutdown.c:448
#2 0xc0129575 in db_panic (addr=-1072256055, have_addr=0, count=-1,
modif=0xc30a6acc "") at ../../ddb/db_command.c:432
#3 0xc0129515 in db_command (last_cmdp=0xc023558c, cmd_table=0xc02353ec,
aux_cmd_tablep=0xc0245f8c) at ../../ddb/db_command.c:332
#4 0xc01295da in db_command_loop () at ../../ddb/db_command.c:454
#5 0xc012b95b in db_trap (type=1, code=0) at ../../ddb/db_trap.c:71
#6 0xc01f9bea in kdb_trap (type=1, code=0, regs=0xc30a6be4)
at ../../i386/i386/db_interface.c:157
#7 0xc0203a00 in trap_fatal (frame=0xc30a6be4, eva=0)
at ../../i386/i386/trap.c:938
#8 0xc02034b0 in trap (frame={tf_es = 16, tf_ds = -1023541232,
tf_edi = -1023478144, tf_esi = 0, tf_ebp = -1022727084,
tf_isp = -1022727156, tf_ebx = -1024550784, tf_edx = 12245,
tf_ecx = -1023478144, tf_eax = 0, tf_trapno = 1, tf_err = 0,
tf_eip = -1072256055, tf_cs = -1072300024, tf_eflags = 66194,
tf_esp = -1024550784, tf_ss = -1024177152}) at ../../i386/i386/trap.c:586
#9 0xc016abc9 in vclean (vp=0xc2ee9880, flags=8, p=0xc2fef680)
at vnode_if.h:835
#10 0xc016adb7 in vgonel (vp=0xc2ee9880, p=0xc2fef680)
at ../../kern/vfs_subr.c:1830
#11 0xc01698b1 in getnewvnode (tag=VT_UFS, mp=0xc05c5e00, vops=0xc05aa000,
vpp=0xc30a6d04) at ../../kern/vfs_subr.c:467
#12 0xc01d4e69 in ffs_vget (mp=0xc05c5e00, ino=20442, vpp=0xc30a6d84)
at ../../ufs/ffs/ffs_vfsops.c:1082
#13 0xc01d8b1a in ufs_lookup (ap=0xc30a6ddc) at ../../ufs/ufs/ufs_lookup.c:538
#14 0xc01dd38d in ufs_vnoperate (ap=0xc30a6ddc)
at ../../ufs/ufs/ufs_vnops.c:2309
#15 0xc0166978 in vfs_cache_lookup (ap=0xc30a6e38) at vnode_if.h:55
#16 0xc01dd38d in ufs_vnoperate (ap=0xc30a6e38)
at ../../ufs/ufs/ufs_vnops.c:2309
#17 0xc0168dc1 in lookup (ndp=0xc30a6eb8) at vnode_if.h:31
#18 0xc0168894 in namei (ndp=0xc30a6eb8) at ../../kern/vfs_lookup.c:152
#19 0xc016e124 in stat (p=0xc2fef680, uap=0xc30a6f94)
at ../../kern/vfs_syscalls.c:1651
#20 0xc0203c83 in syscall (frame={tf_es = 134873135, tf_ds = -1078001617,
tf_edi = 0, tf_esi = 134890328, tf_ebp = -1077946844,
tf_isp = -1022726172, tf_ebx = 134890372, tf_edx = -1077946944,
tf_ecx = 134890388, tf_eax = 188, tf_trapno = 22, tf_err = 2,
tf_eip = 134656096, tf_cs = 31, tf_eflags = 518, tf_esp = -1077946968,
tf_ss = 47}) at ../../i386/i386/trap.c:1101
#21 0xc01fa53c in Xint0x80_syscall ()
#22 0x804b5f1 in ?? ()
#23 0x804a879 in ?? ()
#24 0x804a7f3 in ?? ()
#25 0x804a7f3 in ?? ()
#26 0x804a6fe in ?? ()
#27 0x804a7f3 in ?? ()
#28 0x804ab8a in ?? ()
#29 0x804a7ab in ?? ()
#30 0x804aa23 in ?? ()
#31 0x804a812 in ?? ()
#32 0x8051257 in ?? ()
#33 0x8051183 in ?? ()
#34 0x80480e9 in ?? ()
(kgdb)
The End.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
