Panic strings
in [Solaris]
|
Prev: ZFS pool
Next: snv_134 Zpool Failure (again)
From: Chris Ridd on 29 Mar 2010 02:21 On 2010-03-29 01:27:27 +0100, Richard B. Gilbert said: > Wolfgang Ley wrote: >> Hi, >> >> Nelly Boy wrote: >>> Hi >>> >>> We have a 480R server running Solaris 8 (108528-20) and over the last >>> few months the server has been crashing. >>> >> >> Apart from that: consider to move to a more recent Solaris release. >> Solaris 8 is really old. >> > > The age of the software is probably not the issue here. Solaris 8 is > quite old but many of us here are older still! ;-) > > The real issue with running S8 is that you can't get support from Sun. S8 is in what Sun calls "retirement phase 2", but contract customers can still get (some) help. I *think* you can still open new support contracts, but I suspect it'll cost large amounts. <http://www.sun.com/service/eosl/eosl_solaris.html> <http://www.sun.com/software/solaris/lifecycle.xml> > If the OP upgrades to S10 and has the same problem, he will at least be > able to get support. You can also run Solaris 8 programs in a Solaris 8 container in Solaris 10. There's a cost involved for the Solaris 8 container license. -- Chris
From: Sami Ketola on 29 Mar 2010 04:56 Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > The real issue with running S8 is that you can't get support from Sun. Sure you can. They might not make patches for S8 but they will provide some help. All you need is a contract. Sami
From: Wolfgang Ley on 29 Mar 2010 08:33 Hi, Nelly Boy wrote: > Heres the stack trace from the mutex_destroy panic trace. > Ensure that you've patch 116965-22 or newer on the system. This is at least the best match on the panic stack trace (but the real problem may still be elsewhere in which case a dump with kmem_flags and more detailed analysis of the dump itself would be required). Bye, Wolfgang.
From: Nelly Boy on 31 Mar 2010 10:09 On Mar 29, 1:33 pm, Wolfgang Ley <newsp...(a)drusus.de> wrote: > Hi, > > Nelly Boy wrote: > > Heres the stack trace from the mutex_destroy panic trace. > > Ensure that you've patch 116965-22 or newer on the system. > > This is at least the best match on the panic stack trace (but > the real problem may still be elsewhere in which case a dump > with kmem_flags and more detailed analysis of the dump itself > would be required). > > Bye, > Wolfgang. Hi Patch 116965 is not on the system. Should kmem_flags be enabled on a production box? Thanks Nelly Boy
From: Casper H.S. Dik on 31 Mar 2010 10:44
Nelly Boy <jimmythejones(a)googlemail.com> writes: >On Mar 29, 1:33=A0pm, Wolfgang Ley <newsp...(a)drusus.de> wrote: >> Hi, >> >> Nelly Boy wrote: >> > Heres the stack trace from the mutex_destroy panic trace. >> >> Ensure that you've patch 116965-22 or newer on the system. >> >> This is at least the best match on the panic stack trace (but >> the real problem may still be elsewhere in which case a dump >> with kmem_flags and more detailed analysis of the dump itself >> would be required). >> >> Bye, >> =A0 Wolfgang. >Hi >Patch 116965 is not on the system. >Should kmem_flags be enabled on a production box? No. It requires a lot of additional memory and CPU cycles. Update your system. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. |