From nobody@FreeBSD.org  Mon Sep 10 01:55:39 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 0097937B401
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 10 Sep 2001 01:55:39 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f8A8tc352141;
	Mon, 10 Sep 2001 01:55:38 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200109100855.f8A8tc352141@freefall.freebsd.org>
Date: Mon, 10 Sep 2001 01:55:38 -0700 (PDT)
From: Ville-Pertti Keinonen <will@iki.fi>
To: freebsd-gnats-submit@FreeBSD.org
Subject: calcru calls printf while holding a spin lock
X-Send-Pr-Version: www-1.0

>Number:         30482
>Category:       kern
>Synopsis:       calcru calls printf while holding a spin lock
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    remko
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 10 02:00:01 PDT 2001
>Closed-Date:    Sat Jan 27 19:01:31 GMT 2007
>Last-Modified:  Sat Jan 27 19:01:31 GMT 2007
>Originator:     Ville-Pertti Keinonen
>Release:        5.0-current
>Organization:
>Environment:
>Description:
A machine that previously frequently reported problems with
microuptime() going backwards in calcru started crashing after a
recent update.

I'm just guessing based on the stack trace and the panic message
(and this is the first time I look at anything related to SMPng
locking), but it seems that calcru calls printf which eventually
tries to wake up another process and grab allproc_lock while
sched_lock is held...

This seems like an obvious enough bug that it should not require
further details.
>How-To-Repeat:

>Fix:
Remove or defer the printf-calls.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Ville-Pertti Keinonen <will@iki.fi>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: kern/30482: calcru calls printf while holding a spin lock
Date: Wed, 12 Sep 2001 00:13:38 +1000 (EST)

 On Mon, 10 Sep 2001, Ville-Pertti Keinonen wrote:
 
 > >Description:
 > A machine that previously frequently reported problems with
 > microuptime() going backwards in calcru started crashing after a
 > recent update.
 >
 > I'm just guessing based on the stack trace and the panic message
 > (and this is the first time I look at anything related to SMPng
 > locking), but it seems that calcru calls printf which eventually
 > tries to wake up another process and grab allproc_lock while
 > sched_lock is held...
 >
 > This seems like an obvious enough bug that it should not require
 > further details.
 
 This is a bug in printf().  printf() must work when ordinary spinlocks
 like sched_lock are held (for debugging).  Known bugs in printf():
 - the syscons console driver is not reentrant.  The corresponding
   "microtime() goes backwards" printf() in mi_switch() was ifdefed out
   a long time ago to avoid panicing for this bug.
 - the TIOCCONS ioctl causes ordinary printf()s to go to a tty (usually
   a pty).  This can never have worked for printf()s from interrupt
   handlers and now causes a panic instead of random misbehaviour when
   printf() is called with a spinlock held.
 
 Workaround: always use a serial console and don't permit it to be stolen
 by TIOCCONS.
 
 Bruce
 
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Sat Dec 30 16:46:18 UTC 2006 
State-Changed-Why:  
Is this still relevant for recent 6.x versions of FreeBSD? 


Responsible-Changed-From-To: freebsd-bugs->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sat Dec 30 16:46:18 UTC 2006 
Responsible-Changed-Why:  
grab the pr 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30482 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Sat Jan 27 19:01:30 UTC 2007 
State-Changed-Why:  
feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30482 
>Unformatted:
