Let's jump into adb and find out what instruction caused the bad trap type 2. We will do this on a SPARCstation 20, a sun4m system as is the customer's SPARCstation 10. The SS20 is running Solaris 2.3. Underlined bits show you the information we used in some of the adb commands. Again, some of the adb output has been modified in accordance with the customer's wishes. Hiya... adb -k unix.0 vmcore.0 physmem 3e15 $<utsname utsname: utsname: sys SunOS utsname+0x101: node anonymous utsname+0x202: release 5.3 utsname+0x303: version Generic_101318-41 utsname+0x404: machine sun4m time/Y time: time: 1994 Jan 18 17:00:00 *time-(*lbolt%0t100)=Y 1994 Jan 16 19:50:45 $c complete_panic(0xf0049460,0xf0ac94a4,0xf0ac9330,0x0,0x0,0x1) + 10c do_panic(?) + 1c vcmn_err(0xf015f608,0xf0ac94a4,0xf0ac94a4,0x80,0xffee2000,0x3) cmn_err(0x3,0xf015f608,0x0,0x18,0x18,0xf0152400) + 1c die(0x2,0xf0ac95bc,0x0,0x0,0x0,0xf015f608) + 78 trap(0x2, 0xf0ac95bc ,0xf0181d80,0x0,0x0,0x0) + ca0 sys_trap(?) + 1e4 mutex_exit(0x0,0x0,0xe26310ff,0x1,0x0,0x0) mod_hold_stub(0xfc61607c,0x80,0xfc6ca580,0x1,0x19f8309,0xfc61607c) + 26c 0xf0ac95bc$<regs 0xf0ac95bc: psr pc npc 404000c4 fc69d458 fc69d4bc 0xf0ac95c8: y g1 g2 g3 0 fc69d440 8000000 ffffff00 0xf0ac95d8: g4 g5 g6 g7 0 f0ac99e0 1 fc4c6200 0xf0ac95e8: o0 o1 o2 o3 0 0 e26310ff 1 0xf0ac95f8: o4 o5 o6 o7 0 0 f0ac9608 f00e7570 fc69d458/i ipcaccess+0x18: unimp 0x0 ipcaccess/10i ipcaccess: ipcaccess: save %sp, -0x60, %sp ld [%i2 + 0x4], %o0 orcc %g0, %o0, %g0 bne,a ipcaccess + 0x1c ld [%i0], %o2 ba ipcaccess + 0x7c unimp 0x0 cmp %o0, %o2 be,a ipcaccess + 0x6c ld [%i0 + 0x10], %i0 ipcaccess/10X ipcaccess: ipcaccess: 9de3bfa0 d006a004 80900008 32800004 d4060000 1080001a 80a2000a 22800013 f0062010 That was easy! The system trapped due to an illegal instruction in the ipcaccess() routine. |