From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:14:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAD3216A405; Mon, 16 Jul 2007 15:14:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7C96613C428; Mon, 16 Jul 2007 15:14:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960681 for multiple; Mon, 16 Jul 2007 11:05:52 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML7032514; Mon, 16 Jul 2007 10:57:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 08:50:44 -0400 User-Agent: KMail/1.9.6 References: <20070617024935.GU4602@funkthat.com> <20070617053746.GV4602@funkthat.com> <20070616.235659.-1947354616.imp@bsdimp.com> In-Reply-To: <20070616.235659.-1947354616.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160850.46259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, mobile@freebsd.org, simokawa@freebsd.org, "M. Warner Losh" Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 15:14:24 -0000 On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > In message: <20070617053746.GV4602@funkthat.com> > John-Mark Gurney writes: > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > In message: <20070617024935.GU4602@funkthat.com> > : > John-Mark Gurney writes: > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > FILTER_HANDLED. > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd > : > : with _SCHEDULE_THREAD... > : > > : > Will _HANDLED cause all the other handlers to not get called, or just > : > the stray interrupt code from not happening? > : > : It will cause the remaining (not yet called) handlers not to get called... > > I'm not sure that's right, especially for edge triggered devices.\ They shouldn't share interrupts then. Do we support shared interrupts on edge triggered devices? > : intr_event_handle calls intr_filter_loop which will return on the first > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : It looks like this code is designed for level triggered interrupts and > : not edge triggered... > > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > edge triggered interrupts. Also, it is inefficient for level > triggered interrupts, since two interrupt sources on the same > interrupt may trigger at about the same time... It works fine since the second device will interrupt again and we will fall through to its routine on the second interrupt. The idea is that simultaneous interrupts are rare enough that it is worth optimizing the common case. -- John Baldwin