Spinlock deadlock

[Felipo Soranz UX]

Hi

One of our servers (a L2000) had a system panic last week.

Using the crashinfo tool I could generate the crash.txt file. (attached)

The panic string is: Spinlock deadlock!

I have done some research and it seems to relate to some processor problems but could certainly use some help to find out exactly what caused the panic.

Thanks

[Steven E. Protter]

Shalom,

This is usually an application problem.

It can often be prevented with patches.

Latest bi-annual update for example.

Set crashdumps to save in /etc/rc.config.d/savecrash

First variable to 1.

If its already to run you have a crash dump in /var/adm/crash

It is possible to perform q4 analysis on the dump and submit a file for HP support to check. They can often recommend a specific patch for the problem after that.

SEP

[Don Morris_1 · Accepted solution]

I would hope this isn't application caused (if an app causes the kernel to crash, that's a kernel defect).

I can't be absolutely sure since the crashinfo output really doesn't tell us what the lock holder is doing -- but given that cpu 1 is intended to be the next holder, and its doing a sodequeue, I suspect its a socket lock being either held across a function that's taking longer than expected (the NFS server timeouts are likely to be related) or wasn't dropped properly.

There are a few spinlock-related fixes in the current ARPA transport cumulative 11.0 patch, PHNE_35729... are you already at that patch level?

Beyond that -- you'd really need HP Support to look at the dump (you'd have to pull out what the lock is, the stack of the owning context, why it didn't drop the lock or what its waiting on, etc... which is more than a little too involved to try to walk you through using q4 [which I'd have to dredge up in my memory] via a web forum). And 11.0 isn't supported, from what I can recall... so my hope is that you just need the ARPA patch.