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