On Wed, May 03, 2006 at 12:15:30PM +, Alexey Toptygin wrote:
>
> I'm curious, how would you do this without filling the disk? With a script
> that starts tcpdump to a ring in the background, waits for the offending
> log entry to appear and then kills tcpdump?
Well if you know the set of IP
Hi
Just Marc <[EMAIL PROTECTED]> wrote:
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only s
On Wed, May 03, 2006 at 01:47:31PM +0200, Ingo Oeser wrote:
>
> Already there: /proc/sys/net/core/{message_cost,message_burst}
>
> Just set burst to 0 and cost to a very big value to basically supppress
> all net_ratelimit()ed messages.
>
> Or did you think of sth. else?
No that'll do just fine
On Wed, 3 May 2006, Herbert Xu wrote:
Can you take a tcpdump of the TCP sessions involving those IPs and
then show me the sections that occur when those messages are triggered?
I'm curious, how would you do this without filling the disk? With a script
that starts tcpdump to a ring in the back
Hi
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
You're right, actually this box serves http/ftp file transfers only,
it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly thes
Just Marc <[EMAIL PROTECTED]> wrote:
>
> That's good, but it may (and probably will) suppress many other messages
> which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only solution
Hi
Herbert Xu wrote:
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Already
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
>
> You're right, actually this box serves http/ftp file transfers only,
> it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly these condit
Hi,
Just Marc <[EMAIL PROTECTED]> wrote:
We're now at 2.6.16.12 and it is still showing thousands of times a day
on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have acc
Herbert Xu wrote:
> BTW, this message is already under net_ratelimit so I don't see any
> urgency in getting rid of it completely. If we're going down the
> path of disabling it, we probably should go for something more global
> rather than a sysctl that controls this one message.
Already there:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 2 May 2006 18:02:43 +0200
On Tuesday 02 May 2006 18:19, Just Marc wrote:
I thought that maybe it's time to either set TCP_DEBUG to 0 or
alternatively allow an admin to toggle the printing of this message
off/on? On a few busy web serv
Just Marc <[EMAIL PROTECTED]> wrote:
>
> We're now at 2.6.16.12 and it is still showing thousands of times a day
> on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have access to d
On Wednesday 03 May 2006 08:32, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 2 May 2006 18:02:43 +0200
>
> > On Tuesday 02 May 2006 18:19, Just Marc wrote:
> >
> > > I thought that maybe it's time to either set TCP_DEBUG to 0 or
> > > alternatively allow an admin to
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 2 May 2006 18:02:43 +0200
> On Tuesday 02 May 2006 18:19, Just Marc wrote:
>
> > I thought that maybe it's time to either set TCP_DEBUG to 0 or
> > alternatively allow an admin to toggle the printing of this message
> > off/on? On a few busy web
Herbert Xu wrote:
Just Marc <[EMAIL PROTECTED]> wrote:
Looking at mailing list archives there has been much talk of this print
in the past, given the fact that this check/print is surrounded by an
A good number of these turned out to be a bug in the Linux TCP stack.
If this message wasn't the
Herbert Xu wrote:
Just Marc <[EMAIL PROTECTED]> wrote:
Looking at mailing list archives there has been much talk of this print
in the past, given the fact that this check/print is surrounded by an
A good number of these turned out to be a bug in the Linux TCP stack.
If this message wa
Andi Kleen wrote:
On Tuesday 02 May 2006 18:19, Just Marc wrote:
I thought that maybe it's time to either set TCP_DEBUG to 0 or
alternatively allow an admin to toggle the printing of this message
off/on? On a few busy web servers running usually latest versions of
2.6 I have this message
Just Marc <[EMAIL PROTECTED]> wrote:
>
> Looking at mailing list archives there has been much talk of this print
> in the past, given the fact that this check/print is surrounded by an
A good number of these turned out to be a bug in the Linux TCP stack.
If this message wasn't there we would've
On Tuesday 02 May 2006 18:19, Just Marc wrote:
> I thought that maybe it's time to either set TCP_DEBUG to 0 or
> alternatively allow an admin to toggle the printing of this message
> off/on? On a few busy web servers running usually latest versions of
> 2.6 I have this message displaying hund
Hi everyone,
Looking at mailing list archives there has been much talk of this print
in the past, given the fact that this check/print is surrounded by an
#ifdef TCP_DEBUG
#ifdef TCP_DEBUG
if (net_ratelimit()) {
struct inet_sock *inet = inet_sk(sk);
printk(KERN_DEBUG
20 matches
Mail list logo
