netdev
[Top] [All Lists]

Re: [PATCH 1/7] netpoll: shorten carrier detect timeout

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout
From: Matt Mackall <mpm@xxxxxxxxxxx>
Date: Thu, 10 Mar 2005 15:01:17 -0800
Cc: Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx, Jeff Moyer <jmoyer@xxxxxxxxxx>
In-reply-to: <422A564D.4080809@trash.net>
References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Sun, Mar 06, 2005 at 02:01:01AM +0100, Patrick McHardy wrote:
> Matt Mackall wrote:
> >On Sun, Mar 06, 2005 at 01:09:28AM +0100, Patrick McHardy wrote:
> >>
> >>The carrier detection looks partially broken to me. The current logic
> >>detects an instantly available carrier as flaky because
> >>netif_carrier_ok() takes less than 1/10s. This patch does what
> >>I assume is intended, make sure the carrier is stable for 1/10s.

Ok, on closer inspection, the current logic is: the NIC reports
carrier detect nearly instaneously and thus its carrier detect
reporting is considered unreliable. Rather than immediately sending
packets, we wait for some interval for it to really be up so that the
backlog of console messages doesn't get pumped into the bit bucket.

So I'm going to change it from "flaky" to "untrustworthy" and add a
comment.

> How about this one ? I also removed oflags, reading it outside of
> the locked section was racy.

I'll do this as a separate patch.

> >Did you try this with a card that otherwise goes into the wait?
> 
> Yes, I tried with sk98lin. I don't have a card here that actually
> supports netpoll.

Huh? sk98lin appears to support it?

-- 
Mathematics is the supreme nostalgia of our time.

<Prev in Thread] Current Thread [Next in Thread>