[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1251775996.3345.5.camel@obelisk.thedillows.org>
Date: Mon, 31 Aug 2009 23:33:16 -0400
From: David Dillow <dave@...dillows.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Francois Romieu <romieu@...zoreil.com>,
Michael Riepe <michael.riepe@...glemail.com>,
Michael Buesch <mb@...sch.de>,
Rui Santos <rsantos@...popie.com>,
Michael B??ker <m.bueker@...lin.de>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] r8169: Reduce looping in the interrupt handler.
On Sun, 2009-08-30 at 13:53 -0700, Eric W. Biederman wrote:
> Francois Romieu <romieu@...zoreil.com> writes:
>
> > David Dillow <dave@...dillows.org> :
> > [...]
> >> It'll be this weekend, but I can see cases where it can lock my chip up
> >> -- they should be rare, but then I thought your case would be extremely
> >> rare...
> >
> > I don't get it.
> >
> > Can you elaborate the relevant cases or give some sample scenarios for
> > them ?
>
> I think David is referring to the fact that in the NAPI loop there is
> nothing that acks everything.
That was my concern, yes.
I've not been able to reproduce my lockups under medium testing with
Francois's patch applied, so I'm a little more comfortable with it.
At the same time, I'm worried that the timing just changed enough to
make it harder to trigger, as was the case when I did the patch IIRC.
The kernel's interrupt handling changed in a manner that made it much
easier to hit about that time. The testing I did in May pointed strongly
at us failing to ACK an interrupt source, causing the MSI generation to
stop, so I need to think about things some more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists