> On 1/14/2010 11:37 PM, Juris Krumins wrote: > > Hi Dana. > > > > Looks like you are right. I can boot with > acpi-user-options=2 option. > > I've also done what's Brian suggested and got some > output before "trap > > type 8 ...": > > > > load 'misc/acpidev' id 20 loaded .... > > installing acpidev, module id 20 > > load 'drv/isa' id 21 loaded ..... > > installing isa, modules id 21 > > trap: Unknown trap type 8 in user mode .... > > > > panic[cpu0]/thread .... (previously posted message) > > > It is probable that acpi-enum=off option would also > let your > system boot while retaining use of ACPI for interrupt > routing > (you'll lose some, but not all ACPI-based features). > > Build 131 should correct this, though. >
Ok. Thanks a lot for your help. Lets wait for snv_131. > Thanks - > Dana > > > -----Original Message----- > > From: Dana H. Myers<[email protected]> > > Cc: [email protected] > > Subject: Re: [osol-discuss] OpenSolaris snv_130 > panic. > > Date: Thu, 14 Jan 2010 09:58:14 -0800 > > > > Hello Juris, > > > > You're running on an IBM xSeries machine: IBM > xSeries 3650 64 bit, > > which makes me certain this is reported as CR > 6916573. Investigation > > strongly suggests this is a duplicate of CR > 6905550, regression induced > > in build 129 and fixed in build 131. My apologies > for the inconvenience. > > > > (Your system will probably boot with the addition > of the boot > > option "acpi-user-options=2" but this is not a > functional work- > > around, just a diagnostic tool) > > > > Cheers, > > Dana > > > > > > > > On 1/14/2010 12:34 AM, Juris Krumins wrote: > > > >>>> 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(). > >> > > _______________________________________________ > > opensolaris-discuss mailing list > > [email protected] > > > > > > > > > > > > _______________________________________________ > opensolaris-discuss mailing list > [email protected] -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
