* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-02 23:00 UTC (permalink / raw)
To: Just Marc; +Cc: netdev
In-Reply-To: <44578691.4020402@corky.net>
Just Marc <marc@corky.net> 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 never found it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: Stephen Hemminger @ 2006-05-02 23:00 UTC (permalink / raw)
To: Alex Aizman; +Cc: netdev
In-Reply-To: <4457E2FE.50505@neterion.com>
On Tue, 02 May 2006 15:53:50 -0700
Alex Aizman <alex@neterion.com> wrote:
> Signed-off-by: Alex Aizman <alex@xxxxxxxxxx>
>
> Hacked netdevice.h to support multiple channels.
>
> --- netdevice-orig.h 2006-03-04 10:01:38.000000000 -0800
> +++ netdevice-channel.h 2006-03-09 10:17:11.419955200 -0800
> @@ -246,6 +246,147 @@
>
> extern int __init netdev_boot_setup(char *str);
>
> +#ifdef CONFIG_NET_CHANNELS
> +/*************** NETDEVICE HW CHANNELS data structures *****************/
> +/**
> + * enum netdev_hwchannel_rx_flow_e - Hardware receive channel "flow" types.
> + * @HWCH_RX_FLOW_NONE: does not filter rx packets.
> + * @HWCH_RX_FLOW_MACADDR: filters based upon the rx mac address
> + * @HWCH_RX_FLOW_VLAN_ID: filters based upon the rx vlan id tag
> + * @HWCH_RX_FLOW_VLAN_QOS: fikters based upon the vlan qos field
> + * @HWCH_RX_FLOW_PORT: filters based upon the tcp or udp receive port number
> + * @HWCH_RX_FLOW_L4_HASH: filters based upon a hash of the tcp session id
> + * @HWCH_RX_FLOW_L4_SPDM: filters based upon a hash of the four-tuple of the
> + * following: source ip, source port, destination ip, destinaton port
> + *
> + * A rx is bound to a specific device. When one of thsese enums is used,
> + * traffic is filtered onto the queue of only the requested type. By default
> + * we use HWCH_RX_FLOW_NONE as we usually want all traffic from this device.
> + **/
> +typedef enum netdev_hwchannel_rx_flow_e {
> + HWCH_RX_FLOW_NONE,
> + HWCH_RX_FLOW_MACADDR,
> + HWCH_RX_FLOW_VLAN_ID,
> + HWCH_RX_FLOW_VLAN_QOS,
> + HWCH_RX_FLOW_PORT,
> + HWCH_RX_FLOW_L4_HASH,
> + HWCH_RX_FLOW_L4_SPDM,
> +} netdev_hwchan_rx_flow_e;
> +
No, not a typedef. also pls use shorter names.
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 4:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <200605021802.43301.ak@suse.de>
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 displaying hundreds (if not more) times a day,
>>
>
> You're talking to a lot of broken TCP clients then.
>
>
I don't think that's a surprise, with hundreds of thousands of visitors,
thousands are probably broken.
>> completely clogging the kernel log and making it harder to see if there
>> are more interesting messages being printed. TCP_DEBUG is being used
>> in one more place that may also not require it anymore and or have it
>> always enabled.
>>
>
> It's better to use run time switches for these kind of things.
>
>
Agreed.
>> So, is it time to disable this print altogether? Is it time to allow an
>> admin to toggle printing of this thing off?
>>
>
> If it's disabled there should be probably a netstat counter for the condition instead.
>
>
Yes, that would be better.
> It might be a reasonable simple beginner project for someone:
>
> - Convert all NETDEBUGs/TCP_DEBUG to a single netdebug sysctl
> - Then perhaps make a CONFIG to change its default: 0 or 1
> - Add statistics counters for all of these conditions
>
It's indeed pretty simple, unfortunately I don't have the time to do
it. For myself, I'll just comment it out for now. But clearly
something needs to be done about this one.
Thanks
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 4:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1Fb3qv-0005Vp-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Just Marc <marc@corky.net> 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 never found it.
>
Agreed, though this would be true for many other cases in the kernel
should it be much more verbose in many other places.
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?
Marc
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Auke Kok @ 2006-05-03 4:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: Just Marc, netdev
In-Reply-To: <E1Fb3qv-0005Vp-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Just Marc <marc@corky.net> 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 never found it.
I am surprised that this never made it as a sysctl option that defaulted "on"
in the first place really.
Auke
^ permalink raw reply
* Re: [PATCH 2/2] ipg: redundancy with mii.h
From: Pekka J Enberg @ 2006-05-03 6:16 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Vrabel, linux-kernel, netdev, david
In-Reply-To: <20060502215559.GA1119@electric-eye.fr.zoreil.com>
Hi Francois,
On Tue, 2 May 2006, Francois Romieu wrote:
> Btw the whole serie is available in branch 'netdev-ipg' at:
> git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
>
> The interim steps may be useful if testing reveals something wrong
> (especially if it happens in a few weeks/months).
I have all the interim steps in a private git tree also. I asked for a
kernel.org account so I could publish the tree. However, if you wish to
maintain the tree, I can send you my patches so you can recreate the full
history. The first steps were produced by quilt on the original
out-of-tree driver, though, so they're probably not helpful.
Pekka
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: David S. Miller @ 2006-05-03 6:32 UTC (permalink / raw)
To: ak; +Cc: marc, netdev
In-Reply-To: <200605021802.43301.ak@suse.de>
From: Andi Kleen <ak@suse.de>
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 servers running usually latest versions of
> > 2.6 I have this message displaying hundreds (if not more) times a day,
>
> You're talking to a lot of broken TCP clients then.
Herbert Xu also fixed a bug that would cause that message
to be emitted erroneously, 9 times out of 10 that is why
people are seeing these messages.
I think disabling that message is a non-starter, we want to
see the message because as we've seen it can point to bugs
on our end too.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: David S. Miller @ 2006-05-03 6:47 UTC (permalink / raw)
To: shemminger; +Cc: alex, netdev
In-Reply-To: <20060502160058.7af02254@localhost.localdomain>
I don't think we should be defining driver APIs when we haven't even
figured out how the core of it would even work yet.
A key part of this is the netfilter bits, that will require
non-trivial flow identification, a hash will simply not be enough, and
it will not be allowed to not support the netfilter bits properly
since everyone will have netfilter enabled in one way or another.
^ permalink raw reply
* Re: VJ Channel API - driver level (README)
From: David S. Miller @ 2006-05-03 6:49 UTC (permalink / raw)
To: alex; +Cc: netdev
In-Reply-To: <4457E2E1.3030809@neterion.com>
BTW another thing to keep in mind, besides the fact that we should be
designing driver APIs at this point at all, is that no implementation
should do MMIOs to the card to insert or delete netchannel lookup
entries.
Rather, it should be communicated to the card in a lazy fashion using
DMA.
Otherwise, net channels will have the same connection rate performance
problems that TOE has.
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Andi Kleen @ 2006-05-03 6:52 UTC (permalink / raw)
To: David S. Miller; +Cc: marc, netdev
In-Reply-To: <20060502.233246.92272407.davem@davemloft.net>
On Wednesday 03 May 2006 08:32, David S. Miller wrote:
> From: Andi Kleen <ak@suse.de>
> 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 servers running usually latest versions of
> > > 2.6 I have this message displaying hundreds (if not more) times a day,
> >
> > You're talking to a lot of broken TCP clients then.
>
> Herbert Xu also fixed a bug that would cause that message
> to be emitted erroneously, 9 times out of 10 that is why
> people are seeing these messages.
Still if Marc has hundreds per day that would be still tens
per day - and someone with even more traffic than Marc
would have hundreds per day again.
> I think disabling that message is a non-starter, we want to
> see the message because as we've seen it can point to bugs
> on our end too.
Just having the counter would help with that already, no?
Also the default for the sysctl could be maybe switched in -rc* and final?
-Andi
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 7:05 UTC (permalink / raw)
To: Just Marc; +Cc: herbert, netdev
In-Reply-To: <445835BB.4050000@corky.net>
Just Marc <marc@corky.net> 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 do not see this message
at all.
So either your web server is somehow attracting a lot of buggy TCP stacks,
or there could be a dodgy gateway in your path that is mucking with the
TCP windows.
I suggest that you do a tcpdump to see what it looks like. It might turn
out that we do still have a bug on our RX side.
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 8:06 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, netdev
In-Reply-To: <20060502.233246.92272407.davem@davemloft.net>
> From: Andi Kleen <ak@suse.de>
> 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 servers running usually latest versions of
>>> 2.6 I have this message displaying hundreds (if not more) times a day,
>>>
>> You're talking to a lot of broken TCP clients then.
>>
>
> Herbert Xu also fixed a bug that would cause that message
> to be emitted erroneously, 9 times out of 10 that is why
> people are seeing these messages.
>
> I think disabling that message is a non-starter, we want to
> see the message because as we've seen it can point to bugs
> on our end too.
>
>
Correct, I noticed this was applied to 2.6.14, however, I am running
2.6.16 (and now 2.6.16.12) on all of the machines in question, I am
seeing hundreds of these messages a day...
Thanks
^ permalink raw reply
* Re: [PATCH] au1000_eth.c Power Management, driver registration and module support
From: Rodolfo Giometti @ 2006-05-03 7:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: jgarzik, netdev, Linux-MIPS
In-Reply-To: <20060502150914.GE20543@gundam.enneenne.com>
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Hello,
yesterday I did a little mess with GIT... now the patch is
complete. Sorry. :)
I forgot also to say that it has been done against
«linux-2.6.16-stable» branch.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 3/9] natsemi: Add support for using MII port with no PHY
From: Jeff Garzik @ 2006-05-03 11:07 UTC (permalink / raw)
To: Jeff Garzik, akpm, netdev, jgarzik, thockin
In-Reply-To: <20060428130139.GA20068@sirena.org.uk>
Mark Brown wrote:
> On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote:
>
>>> Provide a module option which configures the natsemi driver to use the
>>> external MII port on the chip but ignore any PHYs that may be attached to
>>> it. The link state will be left as it was when the driver started and can
>
>> The proper way to do this is via the force_media boolean flag found in
>> several net drivers.
>
> I've had a look at several of the net drivers that implement this option
> (e100, smc91x, starfire and the shared code in mii.c). Unless I'm
> misreading the code it looks like the effect of this option in those
> drivers is to disable autonegotiation but still configure the PHY when
> the NIC is configured.
>
> That is a subset of what the patch does and isn't sufficient for the
> hardware this patch targets: sometimes there may be a PHY visible on the
> MII bus but with a different configuration to the natsemi or there may
> be no PHY present at all. In this case the code in the natsemi driver
> that configures the PHY to match the configuration of the natsemi also
> needs to be disabled.
>
> It looks like I should implement a force_media option and redo this
> patch to use that.
That's the sort of patch I'm looking for...
Jeff
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Ingo Oeser @ 2006-05-03 11:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: Just Marc, netdev
In-Reply-To: <E1FbBPy-0007Iu-00@gondolin.me.apana.org.au>
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: /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?
Regards
Ingo Oeser
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 12:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1FbBPy-0007Iu-00@gondolin.me.apana.org.au>
Hi,
> Just Marc <marc@corky.net> 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 do not see this message
> at all.
>
> So either your web server is somehow attracting a lot of buggy TCP stacks,
> or there could be a dodgy gateway in your path that is mucking with the
> TCP windows.
>
>
You're right, actually this box serves http/ftp file transfers only,
it's a mirror with a large amount of downloads a day.
On a pure html/image web server that is just as busy, there are only a
few of these messages, one or two a day.
> I suggest that you do a tcpdump to see what it looks like. It might turn
> out that we do still have a bug on our RX side.
>
I gave it another look, many of the prints are repeat prints for the
same remote IPs,
> 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.
>
I agree, however, I think it's pretty good to allow an admin to toggle
it off completely. Maybe that's all we need, really.
Thanks
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 11:56 UTC (permalink / raw)
To: Just Marc; +Cc: netdev
In-Reply-To: <4458A6C1.90103@corky.net>
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 conditions. Alas you're running
a fixed kernel.
> I gave it another look, many of the prints are repeat prints for the
> same remote IPs,
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 agree, however, I think it's pretty good to allow an admin to toggle
> it off completely. Maybe that's all we need, really.
The question is always what you want to be off and what to leave on.
After all, you can turn off all printk's to the console through /proc.
If you also tell klogd to ignore them then you won't see anything at
all (unless you run dmesg).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: net/d80211 and management interface (wmaster0ap)
From: Jiri Benc @ 2006-05-03 12:08 UTC (permalink / raw)
To: Jouni Malinen; +Cc: netdev
In-Reply-To: <20060502183930.GA28777@instant802.com>
On Tue, 2 May 2006 11:39:30 -0700, Jouni Malinen wrote:
> It looks like one of your patches in wireless-dev.git broke management
> interface. I'm not completely sure about how this was supposed to work,
> but are the low-level drivers now expected to accept
> IEEE80211_IF_TYPE_MGMT in add_interface handler or should ieee80211.c be
> modified to accept wmaster0ap to be set UP without asking the low-level
> driver?
It shouldn't ask the driver. This was a part of the dropped patch for
removing default management device. I will send a patch to address this
particular issue later today.
> In addition to this, it looked like sending packets from wmaster0ap did
> not work. The packets were being dropped since originating device
> (wmaster0ap) did not match in is_ieee80211_device(). This function
> seemed to use wireless_handlers pointer for recognizing interfaces which
> (like to comment says) is not that nice. wireless_handlers were not set
> for apdev, so the patch below adds it to make TX work through
> wmaster0ap.
Oh, thanks for finding this. But we probably don't want wmaster0ap to
have wireless_handlers set. I will try to rewrite is_ieee80211_device in
some another way.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:08 UTC (permalink / raw)
To: Ingo Oeser; +Cc: netdev
In-Reply-To: <200605031347.31281.netdev@axxeo.de>
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 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?
>
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
Marc
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 12:11 UTC (permalink / raw)
To: Just Marc; +Cc: netdev, netdev
In-Reply-To: <4458AB57.6060706@corky.net>
Just Marc <marc@corky.net> 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 is to do the filtering yourself in userspace through
klogd/syslogd.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:11 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20060503115653.GA1353@gondor.apana.org.au>
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 these conditions. Alas you're running
> a fixed kernel.
>
>
>> I gave it another look, many of the prints are repeat prints for the
>> same remote IPs,
>>
>
> 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?
>
>
OK, I'll try that.
>> I agree, however, I think it's pretty good to allow an admin to toggle
>> it off completely. Maybe that's all we need, really.
>>
>
> The question is always what you want to be off and what to leave on.
> After all, you can turn off all printk's to the console through /proc.
> If you also tell klogd to ignore them then you won't see anything at
> all (unless you run dmesg).
>
The problem is that it's really BAD to suppress all messages, there may
be critical ones. In my opinion while the treason uncloaked message can
help uncover bugs it is mostly redundant on a day to day usage for
probably 99% of the scenarios.
Marc
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Alexey Toptygin @ 2006-05-03 12:15 UTC (permalink / raw)
To: Herbert Xu; +Cc: Just Marc, netdev
In-Reply-To: <20060503115653.GA1353@gondor.apana.org.au>
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 background, waits for the offending
log entry to appear and then kills tcpdump?
Alexey
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 12:21 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Just Marc, netdev
In-Reply-To: <200605031347.31281.netdev@axxeo.de>
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.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netdev
In-Reply-To: <E1FbGCo-0000OS-00@gondolin.me.apana.org.au>
Hi
> Just Marc <marc@corky.net> 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 is to do the filtering yourself in userspace through
> klogd/syslogd.
>
It is the crux of the matter. This print is a purely informational one,
absolutely harmless (unless I'm mistaken) and clogs kernel logs
throughout the universe :)
Seriously, other kernel prints are usually not so harmless and are
generally more important to see. Let me put it another way, except
this print, I have no other prints whatsoever on any of my machines and
if there are prints, I usually do want to know about them, I learned to
ignore this print over the years. I believe many people are in the
same boat.
That's my opinion, anyway.
Thanks
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Andrew Morton @ 2006-05-03 12:43 UTC (permalink / raw)
To: Pekka Enberg; +Cc: dvrabel, romieu, linux-kernel, netdev, david
In-Reply-To: <1146475901.11271.3.camel@localhost>
On Mon, 01 May 2006 12:31:40 +0300
Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> [PATCH] IP1000 Gigabit Ethernet device driver
>
> This is a cleaned up fork of the IP1000A device driver:
>
> http://www.icplus.com.tw/driver-pp-IP1000A.html
Please remember that to merge this we'll need a signed-off-by from the
original developers. (That's not very gplish, but such is life).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox