From owner-freebsd-alpha@FreeBSD.ORG Thu Jun 19 09:08:44 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0F737B401 for ; Thu, 19 Jun 2003 09:08:44 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3996E43FD7 for ; Thu, 19 Jun 2003 09:08:44 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h5JG8hwV027865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Jun 2003 12:08:43 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h5JG8cV82825; Thu, 19 Jun 2003 12:08:38 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16113.57350.330775.726477@grasshopper.cs.duke.edu> Date: Thu, 19 Jun 2003 12:08:38 -0400 (EDT) To: Josh Tolbert In-Reply-To: <20030619155159.GB41810@just.puresimplicity.net> References: <20030619155159.GB41810@just.puresimplicity.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: [hemi@just.puresimplicity.net: Re: Unusual sound problems] X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 16:08:45 -0000 Josh Tolbert writes: > Hi Andrew, > > Looks like ATA things are interrupting on 5 along with the sound card. Should I try putting the sound card in the other ISA slot? Would that make any difference? > > atapci0: interrupting at CIA irq 5 > ata1: interrupting at ISA irq 15 > sbc0: interrupting at ISA irq 5 > If possible, yes. I think the problem is that the audio interrupt handler is MPSAFE (meaning that it does its own locking), while the ata driver is not MPSAFE (meaning that it shares the "Giant" lock with a lot of the rest of the kernel). Since there is a non-MPSAFE driver sharing an IRQ, the MPSAFE driver needs to wait for the Giant kernel lock. Since a lot of the kernel uses the Giant lock, that could translate to very high interrupt latency. If you're not using any IDE disks, CDROMs, etc, the best move would be to just remove the ata driver from your kernel. Drew PS: Please try to break your lines at 72 cols or so.