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.
Thanks -
Dana
-----Original Message-----
From: Dana H. Myers<dana.my...@sun.com>
Cc: opensolaris-discuss@opensolaris.org
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
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
