From owner-freebsd-hackers Mon Jun 19 14:42:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 1867437B686 for ; Mon, 19 Jun 2000 14:42:44 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by home.dragondata.com (8.9.2/8.9.2) with ESMTP id QAA26326 for ; Mon, 19 Jun 2000 16:42:05 -0500 (CDT) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id QAA13755 for hackers@freebsd.org; Mon, 19 Jun 2000 16:40:44 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200006192140.QAA13755@celery.dragondata.com> Subject: Unknown exception/trap confusion To: hackers@freebsd.org Date: Mon, 19 Jun 2000 16:40:44 -0500 (CDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I've got a system that seems to spuriously "panic: unknown/reserved trap". In trying to figure out which exception got triggered, I did a backtrace... (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:303 #1 0xc016a355 in panic (fmt=0xc02c58d9 "unknown/reserved trap") at ../../kern/kern_shutdown.c:553 #2 0xc02821ea in trap_fatal (frame=0xd907ebfc, eva=0) at ../../i386/i386/trap.c:929 #3 0xc0281b37 in trap (frame={tf_fs = 24, tf_es = 65552, tf_ds = -653852656, tf_edi = 4, tf_esi = -866895904, tf_ebp = -653792120, tf_isp = -653792216, tf_ebx = -1066888788, tf_edx = -1070536316, tf_ecx = 16777218, tf_eax = 1862615194, tf_trapno = 29, tf_err = 0, tf_eip = -1071493032, tf_cs = 8, tf_eflags = 518, tf_esp = -1071172139, tf_ss = -1042059264}) at ../../i386/i386/trap.c:589 #4 0xc0225058 in ti_intr (xsc=0xc0000) at ../../pci/if_ti.c:1938 #5 0xc027c11f in smp_invltlb () at machine/mpapic.h:104 #6 0xc027dd42 in pmap_qremove (va=3443085312, count=4) at ../../i386/i386/pmap.c:818 #7 0xc01918fc in vfs_vmio_release (bp=0xcc5437e0) at ../../kern/vfs_bio.c:1270 #8 0xc0191dfe in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384) at ../../kern/vfs_bio.c:1551 #9 0xc0192a01 in getblk (vp=0xd9928000, blkno=2, size=16384, slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:2195 #10 0xc019506e in cluster_rbuild (vp=0xd9928000, filesize=136472, lbn=1, blkno=189541632, size=16384, run=2, fbp=0x0) at ../../kern/vfs_cluster.c:391 #11 0xc0194c72 in cluster_read (vp=0xd9928000, filesize=136472, lblkno=1, size=16384, cred=0x0, totread=2820, seqcount=2, bpp=0xd907ee68) at ../../kern/vfs_cluster.c:229 #12 0xc0238666 in ffs_read (ap=0xd907ee8c) at ../../ufs/ufs/ufs_readwrite.c:252 #13 0xc01a00fc in vn_read (fp=0xc2dacb80, uio=0xd907eed8, cred=0xc32e1d00, flags=0, p=0xd6952440) at vnode_if.h:334 #14 0xc017a889 in dofileread (p=0xd6952440, fp=0xc2dacb80, fd=18, buf=0x816f035, nbyte=2820, offset=-1, flags=0) at ../../sys/file.h:141 #15 0xc017a78f in read (p=0xd6952440, uap=0xd907ef80) at ../../kern/sys_generic.c:111 #16 0xc0282511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 135594031, tf_edi = 0, tf_esi = 0, tf_ebp = 0, tf_isp = -653791276, tf_ebx = 140614144, tf_edx = 140614144, tf_ecx = 140614144, tf_eax = 3, tf_trapno = 7, tf_err = 2, tf_eip = 673047244, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937696, tf_ss = 47}) at ../../i386/i386/trap.c:1126 In frame 3, trap is getting called with tf_trapno equal to 29... Which according to machine/trap.h is: #define T_RESERVED 29 /* reserved (unknown) */ It's getting set that way from the idt vector in exception.s: IDTVEC(rsvd) pushl $0; TRAP(T_RESERVED) because all exceptions that aren't specifically mapped to a idt vector are pointed to IDTVEC(rsvd) in machdep.c: for (x = 0; x < NIDT; x++) setidt(x, &IDTVEC(rsvd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); My question is... How am I going to tell which exception is actually getting called? Is it completely unreasonable to have the rsvd idt vector call trap with the trap value + MAX_TRAP_MSG or some other constant, so that trap() can tell what the real exception was? Without knowing which exception really got called, troubleshooting this is more difficult, but... I can't quite figure out what's going on in ti_intr that could cause an exeception... It appears that ti_intr is just getting things off the stack when it crashes: #4 0xc0225058 in ti_intr (xsc=0xc0000) at ../../pci/if_ti.c:1938 1938 } (kgdb) list 1933 1934 if (cur_tx != NULL) 1935 ifp->if_flags &= ~IFF_OACTIVE; 1936 1937 return; 1938 } 1939 1940 static void ti_intr(xsc) 1941 void *xsc; 1942 { (kgdb) disassemble Dump of assembler code for function ti_intr: 0xc0225058 : push %ebp 0xc0225059 : mov %esp,%ebp 0xc022505b : push %esi 0xc022505c : push %ebx 0xc022505d : mov 0x8(%ebp),%esi 0xc0225060 : mov %esi,%ebx (kgdb) info frame Stack level 4, frame at 0xd907ec88: eip = 0xc0225058 in ti_intr (../../pci/if_ti.c:1938); saved eip 0xc027c11f called by frame at 0xd907ec9c, caller of frame at 0xd907ebf4 source language c. Arglist at 0xd907ec88, args: Locals at 0xd907ec88, Previous frame's sp is 0x0 Saved registers: ebx at 0xd907ec80, ebp at 0xd907ec88, esi at 0xd907ec84, eip at 0xd907ec8c (kgdb) info registers eax 0x0 0 ecx 0x0 0 edx 0x0 0 ebx 0x6f05409a 1862615194 esp 0xd907eb58 0xd907eb58 ebp 0xd907ec88 0xd907ec88 esi 0xcc5437e0 -866895904 edi 0x4 4 eip 0xc02701ab 0xc02701ab eflags 0x0 0 cs 0x0 0 ss 0x0 0 ds 0x0 0 es 0x0 0 fs cannot read u area ptr for proc at 0 I'm a bit over my head here, can anyone offer any pointers on what to do now? -- Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message