Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR port-amd64/39283; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-amd64-maintainer%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, fredrik%netbsd.se@localhost
Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
Date: Mon, 14 Dec 2009 21:00:07 +0000

 On Mon, Dec 14, 2009 at 02:55:01PM +0000, Tobias Nygren wrote:
 > The following reply was made to PR port-amd64/39283; it has been noted by 
 > GNATS.
 > 
 > From: Tobias Nygren <tnn%NetBSD.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
 > Date: Mon, 14 Dec 2009 15:50:54 +0100
 > 
 >  With some local patches I've been able to reduce the panics to a
 >  deadlock waiting for kva that never becomes availabe. It looks like
 >  the underlying problem is in fact a resource leak.
 >  
 >  From ddb I've identified the following pool cache whose resource usage
 >  looks highly suspicious to me.
 >  
 >  POOL CACHE ksiginfo: size 72, align 8, ioff 0, roflags 0x00000040
 >          alloc 0xffffffff80d42f20
 >          minitems 0, minpages 0, maxpages 4294967295, npages 264334
 >          itemsperpage 56, nitems 21, nout 14802683, hardlimit 4294967295
 >          nget 14809537, nfail 13, nput 6854
 >          npagealloc 264337, npagefree 3, hiwat 264334, nidle 0
 >          cpu layer hits 5450561 misses 14853292
 >          cache layer hits 43741 misses 14809551
 >          cache layer entry uncontended 14853283 contended 9
 >          cache layer empty groups 0 full groups 0
 >  
 >  Are we aware of any issues related to ksiginfo leakage in 5.0/current?
 
 No one has mentioned any, but I do recall something about signals being
 queued to apps (rather than just being a bitmask). If something is
 looping generating signals maybe there is a path which causes an
 indefinite number to be queued (ksiginfo sounds like the item being queued!)
 
 Perhaps something has ignored SIGSEGV!
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost