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 20:42:46 -0800
Cc: Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx, Jeff Moyer <jmoyer@xxxxxxxxxx>
In-reply-to: <42311FF9.5010007@trash.net>
References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net> <20050310230117.GP3120@waste.org> <42311FF9.5010007@trash.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Fri, Mar 11, 2005 at 05:35:05AM +0100, Patrick McHardy wrote:
> Matt Mackall wrote:
> >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.
> 
> Why don't you trust an instaneously available carrier? Any
> reason to assume there will be false positives?

Because I had reports of people losing all their boot messages until
this logic was added (about a year ago now?). I don't remember which
NICs were implicated, but some apparently report carrier is always
available.

-- 
Mathematics is the supreme nostalgia of our time.

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