lkml.org 
[lkml]   [2008]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT]: Networking

* David Miller <davem@davemloft.net> wrote:

> > just to clarify the bug pattern: the box was still accessible after
> > the warning. So this is a far less serious problem and i'd suggest
> > we open up a separate regression entry for it and consider the
> > hung-TCP problem closed. (i havent seen the hang in the last week,
> > with either version of the tcp-accept reverts)
>
> It is a warning that just means the transmitted on the network device
> stalled for an unusually long period of time. Is your subnet flooded
> when these warnings occur? Is the remove side system wedged or at a
> very high load when the message triggers?

yes, both the network and the testbox is at relatively high load, it's a
distcc kernel build over the network. Thousands of such iterations were
done successfully without this warning ever triggering - it triggered
for the first time in about 10,000 bootups the moment i applied your
version of the reverts. When i applied the small diff the warning did
not come back.

> All of these would be useful points of information to determine if
> this might be normal or not.
>
> In theory, if the remove port the device is connected to gets
> extremely congested, emits a pause frame to your machine, but never
> releases that pause, this (new) warning could trigger.
>
> This warning was added by Arjan in 2.6.25 FYI in order to diagnose the
> not-normal cases better.

ok, should we then remove that warning, if it's spurious? kerneloops.org
has picked up a few other instances of this warning as well:

http://www.kerneloops.org/searchfile.php?search=net%2Fsched%2Fsch_generic.c&btnG=Filename+Search

Ingo


\
 
 \ /
  Last update: 2008-06-14 10:21    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site