Customer's Starcat system panic-ed in hat_add_callback. Here are the details of the panic:
release: 5.10 (64-bit)
version: Generic_118822-19
machine: sun4u
system type: SUNW,Sun-Fire-15000 (UltraSPARC-IV)
time of crash: Mon Oct 24 02:05:11 PDT 2005
age of system: 1 days 10 hours 46 minutes 35.90 seconds
panic CPU: 230 (72 CPUs, 144G memory, 9 nodes)
panic string: BAD TRAP: type=31 rp=2a106172be0 addr=49 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference
sanity checks: settings...vmem...CPU...
WARNING: TS thread 0x300636ce320 on CPU198 using 97%CPU
sysent...clock...misc...
NOTE: kcage_freemem < kcage_lotsfree
NOTE: system has 4 non-global zones
done
This happened after customer upgraded to 118822-19 and started running his oracle application.
Work Around
Workaround is to disable hat_kpr_enabled to 0 in /etc/system and rebooting the system.
not going to any highler KU patch level then 118822-10 is also
a workaround, 118822-11 obviously introduced the probelm with 6235003.
The first workaround listed involving hat_kpr_enabled is actually incomplete if you want Dynamic Reconfiguration to still work; if the previous workaround has been applied and cfgadm operations are not completing, setting hat_kpr_enabled back to 1 via mdb on the live system would allow the DR operation to complete successfully :
echo "hat_kpr_enabled/W 1" | mdb -kw
(run the above as root). Apologies for the inconvenience this caused.