> > Experiencing very strange behaviour with upgraded > > OpenSolaris machine ( from snv_124 to snv_130 ) > > > > Machine gets panic, with the following error: > > Just a wild guess... > > An opensolaris upgrade currently has a nasty bug > that > results in old kernel modules ending in the > boot_archive: > > Bug ID: 6914346 > Synopsis: upgrade from OpenSolaris 2009.06 (111b2) to > 130 fails with stale archive_cache > > ttp://bugs.opensolaris.org/bugdatabase/view_bug.do?bug > _id=6914346 > > Could that bug be an explanation for the panic you're > getting? > > Could you try to workaround from CR 6914346 and > force > building a fresh boot_archive ? Would that avoid the > panic ?
I've tried suggested solution with fresh build archive. Still no luck. During reboot I once again turned on kernel debugging and find out a little bit more info about previously called functions: startup.c: 2001 Attaching segkp startup.c: 2009 Doing segkp_create() startup.c: 2014 'segkp' is 0xfffffffffbc30480 startup.c: 852 about to create segkpm startup.c: 2034 'segmap' is 0xffffffffbc32fc0 startup.c: 2052 startup_vm () done startup.c: 1455 startup_modules () starting ... trap: Unknown trap type 8 in user mode panic[cpu0]/thread = fffffffffbc2e3a0: mutex_enter: bad mutex, lp=20 owner=f000e987f000fea0 thread=fffffffffbc2e3a0 unix: mutex_panic + 73 () unix: mutex_vector_enter +446() genunix: zone_getspecific+2b () genunix: core+5f () unix: kern_gpfault+18e () unix: trap+41e () unix: cmntrap + e6 () I've dig a little bit through src.opensolaris.org and I seems to me that mutex_panic comes from startup.c:1517: dispinit(); function call So dispinit() call disp.c:221: mutex_enter(&cpu_lock); which is the case of mutex_panic(). -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
