NetBSD Problem Report #38330

From chris@dokein.co.uk  Sat Mar 29 15:34:50 2008
Return-Path: <chris@dokein.co.uk>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 2607563B8BD
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 29 Mar 2008 15:34:50 +0000 (UTC)
Message-Id: <47EE61EF.5060200@dokein.co.uk>
Date: Sat, 29 Mar 2008 15:36:15 +0000
From: Chris Gilbert <chris@dokein.co.uk>
Reply-To:
To: gnats-bugs@gnats.NetBSD.org
Subject: lockdebug_barrier spin lock held panic

>Number:         38330
>Category:       kern
>Synopsis:       running a -current kernel with lockdebug causes a panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 29 15:35:01 +0000 2008
>Closed-Date:    Tue Jun 06 01:34:25 +0000 2017
>Last-Modified:  Tue Jun 06 01:34:25 +0000 2017
>Originator:     Chris Gilbert <chris@dokein.co.uk>
>Release:        NetBSD 4.99.58
>Organization:

>Environment:
 cats machine running latest -current source.
 Architecture: arm
 Machine: cats

>Description:
 While trying to diagnose an issue where processes are hanging in biolock
 I enabled LOCKDEBUG.

 After booting the system this triggered a lockdebug_barrier message of
 spinlock held (note db typed in, rather than copied from a serial console):
 db> show lock 0xf05a2b5c
 lock address : 0x00000000f05a2b5c type     :               spin
 shared holds :                  0 exclusive:                  1
 shares wanted:                  0 exclusive:                  0
 current cpu  :                  0 last held:                  0
 current lwp  : 0x00000000f33a66e0 last held: 0x00000000f33a66e0
 last locked  : 0x00000000f020f428 unlocked : 0x00000000f020f180
 initialized  : 0x00000000f021c030
 owner field  : 0x0000000000010500 wait/spin:                0/1

 a bt (abbreviated to just the call lines):
 netbsd:cpu_Debugger
 netbsd:panic
 netbsd:lockdebug_abort1
 netbsd:lockdebug_barrier
 netbsd:mutex_vector_enter
 netbsd:pool_cache_invalidator
 netbsd:pool_reclaim
 netbsd:pool_reclaim_callback
 netbsd:callback_run_roundrobin
 netbsd:uvm_map_prepare
 netbsd:uvm_map
 netbsd:pool_grow
 netbsd:pool_get
 netbsd:uvm_km_alloc_poolpage_cache
 netbsd:pool_grow
 netbsd:pool_get
 netbsd:ksiginfo_alloc
 netbsd:kpsignal2
 netbsd:kpsignal
 netbsd:exit1
 netbsd:sys_exit
 netbsd:syscall_plain
 netbsd:swi_handler

 Poking around the memory and instructions I think the cause is that
 proclist_mutex is held at the call point to kpsignal but the pool code
 also needs to use a spinlock, this triggers the lockdebug panic.

 See line 533 of sys/kern/kern_exit.c

 Note the actual process is pickup, which is a child of postfix master.

>How-To-Repeat:
 	Boot a -current LOCKDEBUG kernel on cats.

>Fix:

Unknown

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->kern-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sat, 29 Mar 2008 15:42:28 +0000
Responsible-Changed-Why:
rectify mangled PR


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 31 Jul 2016 21:48:45 +0000
State-Changed-Why:
Have you seen this problem lately?


State-Changed-From-To: feedback->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 06 Jun 2017 01:34:25 +0000
State-Changed-Why:
feedback timeout. it's been a while, assuming fixed. feel free to mention issues you have.


>Unformatted:

Home	PR Database Search