From owner-freebsd-smp  Sat Apr  5 08:33:09 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id IAA15518
          for smp-outgoing; Sat, 5 Apr 1997 08:33:09 -0800 (PST)
Received: from corona.jcmax.com (corona.jcmax.com [204.69.248.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA15513
          for <smp@freebsd.org>; Sat, 5 Apr 1997 08:33:06 -0800 (PST)
Received: by corona.jcmax.com (5.65/2.49G/4.1.3_U1)
	id AA05399; Sat, 5 Apr 97 11:33:04 -0500
Date: Sat, 5 Apr 97 11:33:04 -0500
From: cr@jcmax.com (Cyrus Rahman)
Message-Id: <9704051633.AA05399@corona.jcmax.com>
To: smp@freebsd.org
Subject: Deadlocking in SMP kernel
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

There appears to be a situation in which the SMP kernel deadlocks on
mp_lock.  With much help from Steve Passe, I've come up with the following
(still tentative) scenario:

 A process, running on cpu1, enters the kernel and obtains a lock.  While it
 has the lock, but before interrupts are redirected to cpu1 (or any time, if
 TEST_LOPRIO isn't defined), an interrupt goes to cpu0, blocking (until it
 obtains the lock) all lower priority interrupts.

 If for some reason the kernel now waits for an interrupt, there will be a
 deadlock.

Are there any places where the kernel waits for an interrupt to occur?
There are three places I found where software interrupts are generated by
the kernel - but I don't think any of them are relevant (two in icu.s, one
in locore.s).

I suspect that understanding my previous question about why mp_lock needs
to be stored during cpu_switch() might be helpful - for there's clearly some
reason why mp_lock isn't always 1 in that routine, but I can't figure it out.

For some reason the deadlock only seems to occur with APIC_IO defined, if
that provides any additional clues.

Cyrus