Date: Sun, 26 Jun 2005 15:32:29 -0700 (PDT) From: Doug White <dwhite@gumbysoft.com> To: sparc64@freebsd.org Subject: bug in trap handler? Message-ID: <20050626152732.X66393@carver.gumbysoft.com>
next in thread | raw e-mail | index | archive | help
Hey folks, I fished a 440MHz USIIi on a Panther board out of a boneyard the other day and it doesn't survive a kernel build, dying with this: RED State Exception TL=0000.0000.0000.0005 TT=0000.0000.0000.0010 TPC=0000.0000.c003.c200 TnPC=0000.0000.c003.c204 TSTATE=0000.0044.5800.1503 TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 TPC=0000.0000.c003.c200 TnPC=0000.0000.c003.c204 TSTATE=0000.0044.5800.1503 TL=0000.0000.0000.0003 TT=0000.0000.0000.0010 TPC=0000.0000.c003.c200 TnPC=0000.0000.c003.c204 TSTATE=0000.0044.5800.1503 TL=0000.0000.0000.0002 TT=0000.0000.0000.0010 TPC=0000.0000.c004.0f80 TnPC=0000.0000.c004.0f84 TSTATE=0000.0044.5800.1403 TL=0000.0000.0000.0001 TT=0000.0000.0000.0063 TPC=0000.0000.0012.6b80 TnPC=0000.0000.0012.6b84 TSTATE=0000.0044.0000.1202 I found the .traps OBP command and trap type 0x63 is an ECC error. PC 0xc0040f80 in the kernel is in trap(). Checking the code, we should be panicking since this is an undefined (implementation-specific) trap number as far as FreeBSD is concerned. But we shouldn't be spiralling into endless invalid-instruction traps, which is 0x10. I booted Solaris 9 on the machine and it properly reports memory ECC errors on the system so this shoudn't be fatal. So it appears there are two bugs: 1. We should define trap type 0x63 like the existing ecc-error trap number (0x41?) and just notify the user. 2. We should fix the trap handler to not blow up on undefined traps. I'll try to dig into this but someone more familiar with SPARC assembly would find it much faster :) Thanks for any input! -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050626152732.X66393>