Re: Ultrasparc III+ kernel panic

Eduardo Horvath <[email protected]>
Newsgroups gmane.os.netbsd.ports.sparc64
Message-ID <[email protected]>
On Mon, 23 Feb 2015, BERTRAND Joël wrote:

> > I'd turn on ddb and traptrace in the kernel and
> > examine the contents of the traptrace buffer after the panic.  That should
> > tell us the sequence of traps that caused the panic.
> 
> 	I'm trying, but it is not very easy. I have several Blade2000 and this
> bug seems to be triggered by something on PCI/UPA bus. At home, I have
> installed the same configuration (without external U320 disks, but with mpt
> adapter) and this server seems to be stable. I'm working on cpufreq and I
> haven't seen panic or deadlock for a long time.
> 
> 	Faulty servers are far away and I don't have any serial console, only
> SSH access.

In that case you could try turning on traptrace and wiring db_traptrace() 
to dump the buffer into the panic path.  Maybe also reduce the size of the 
traptrace buffer to hold only a couple of dozen entries so you don't 
overflow the syslog buffer.

Eduardo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.