From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:05:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0029916A420 for ; Fri, 3 Feb 2006 01:05:09 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4E543D45 for ; Fri, 3 Feb 2006 01:05:09 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k13153It044033; Thu, 2 Feb 2006 18:05:03 -0700 (MST) (envelope-from scottl@pooker.samsco.org) Date: Thu, 2 Feb 2006 18:05:03 -0700 (MST) From: Scott Long To: Jack Vogel In-Reply-To: <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> Message-ID: <20060202180247.M10747@pooker.samsco.org> References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <1138890130.9192.3.camel@genius.i.cz> <43E2184B.3040606@samsco.org> <43E256DD.1030504@elischer.org> <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org X-Mailman-Approved-At: Fri, 03 Feb 2006 05:26:17 +0000 Cc: Michal Mertl , Julian Elischer , freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding 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: Fri, 03 Feb 2006 01:05:10 -0000 On Thu, 2 Feb 2006, Jack Vogel wrote: > On 2/2/06, Julian Elischer wrote: >> >> the big "workaround" that may save lives would be to have a "storm >> detection" that detects that >> an interrupt is not being reset, say, by noticing that the same >> interrupt has fired 32 times without >> ever giving the system a chance to even get out of the interrupt >> handling layer, >> and then on detection call the interrupt routine sof EVERY DRIVER that >> is registerred >> for interrupts. >> >> I have done similar to this on one of our machines where the redirected >> interrupt is being sent >> to the interrupt used by em4, when em0 gets delayed. >> >> My solution for this embedded hardware is to add a hack so that when em4 >> gets an interrupt and there >> isn't one, it goes and services all the other em devices as well. >> (remember this is for a particular hardware config so I can use >> non-general solutions).. >> >> Another way to achieve this would be to have a special driver that you >> register on the 'target' >> interrupt, that when run, calls the correct interrupt handlers :-) >> you could have a kernel module that you compile up with the correct two >> interrupts in it >> and on loading it would do the trick.. > > I have a feeling that the real fix is something down in the bottom half of > the kernel where interrupt routing is set up. I think something is wonky > down there on some new chip sets, but I'm not sure without more > research. Anyone else looking at that perhaps? > > Jack > It's quite common for laptop motherboard makers to route lots of interrupts onto the same physical line. It saves a small fraction of a penny in costs. My last Dell notebook was that way, regardless of Windows, Linux, or FreeBSD. Scott