From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:01:14 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 2D9BC16A420 for ; Fri, 3 Feb 2006 01:01:14 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78B843D48 for ; Fri, 3 Feb 2006 01:01:13 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by pproxy.gmail.com with SMTP id i49so111909pye for ; Thu, 02 Feb 2006 17:01:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qhWcMBYopgrKPnaeQ4fH6NxFydMbDPdxQR/M/ZAsE5hsNr9B4HUMdiI9c5LDmJrSmBH/GGBCUFgcyyBFLsE3fSQyjYX1MNS0K4uc7ia0aX1mM37wynib8qQKJvvxadmypWrf+vrL1CgriUqSSuQuD/DhDChMvfNZcJC2IDU/j2s= Received: by 10.35.127.7 with SMTP id e7mr36968pyn; Thu, 02 Feb 2006 17:01:12 -0800 (PST) Received: by 10.35.28.4 with HTTP; Thu, 2 Feb 2006 17:01:12 -0800 (PST) Message-ID: <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> Date: Thu, 2 Feb 2006 17:01:12 -0800 From: Jack Vogel To: Julian Elischer In-Reply-To: <43E256DD.1030504@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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> Cc: Michal Mertl , 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:01:14 -0000 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