Re: TCP connection stops after high load.
On 4/13/07, David Miller [EMAIL PROTECTED] wrote: From: Robert Iakobashvili [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 23:11:14 +0200 It works good with 2.6.11.8 and debian 2.6.18.3-i686 image. At the same Intel Pentium-4 PC with the same about kernel configuration (make oldconfig using Debian config-2.6.18.3-i686) the setup fails with the tcp-connections stalled after 1000 established connections when the kernel is 2.6.20.6 or 2.6.19.5. It stalls even earlier, when lighttpd used with the default (poll ()) demultiplexing after 500 connections or when apache2 web server used (memory?) - after 100 connections. I am currently going to try vanilla 2.6.18.3 and, if with it also fails, to look through Debian patches, trying to figure out, what is the delta. Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Is not it done deliberately by the below patch: commit 9e950efa20dc8037c27509666cba6999da9368e8 Author: John Heffner [EMAIL PROTECTED] Date: Mon Nov 6 23:10:51 2006 -0800 [TCP]: Don't use highmem in tcp hash size calculation. This patch removes consideration of high memory when determining TCP hash table sizes. Taking into account high memory results in tcp_mem values that are too large. Is it a feature? My machine has: MemTotal: 484368 kB and for all kernel configurations are actually the same with CONFIG_HIGHMEM4G=y Thanks, -- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... Navigare necesse est, vivere non est necesse ... http://curl-loader.sourceforge.net An open-source HTTP/S, FTP/S traffic generating, and web testing tool. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
{Spam?} Re: {Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
On Sun, 15 Apr 2007, Ian McDonald wrote: On 4/15/07, Robert P. J. Day [EMAIL PROTECTED] wrote: in fact, according to this: http://lkml.org/lkml/2006/1/13/139 that notice was put in the feature removal file well over a year ago, during 2.6.15. so that would seem to be more than adequate time for everyone to prepare for it. but it must have been deleted from that file since then as well. Yes and that was never merged and so was resent on January 19th, 2006: http://www.nabble.com/-2.6-patch--schedule-SHAPER-for-removal-t949871.html At that point people debated about it being too short notice and the patch never went in. I therefore think we can't just remove with NO notice. i have no dog in this fight one way or the other. i was just in a housecleaning mood and the shaper stuff looked old and relatively dead, that's all. if there's a good reason to keep it, fine. but it seems fairly clear that this *is* a dead feature: === $ git show 3b6a792f6ace33584897d1af08630c9acc0ce221 commit 3b6a792f6ace33584897d1af08630c9acc0ce221 Author: Jiri Slaby [EMAIL PROTECTED] Date: Mon Nov 6 14:34:48 2006 -0800 [NET]: kconfig, correct traffic shaper As Patrick McHardy [EMAIL PROTECTED] suggested, Traffic Shaper is now obsolete and alternative to it is no longer CBQ, since its problems with virtual devices, alter Kconfig text to reflect this -- put a link to the traffic schedulers as a whole. Signed-off-by: Jiri Slaby [EMAIL PROTECTED] Acked-by: Patrick McHardy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] == so given that the discussion of getting rid of this feature started well over a year ago, coupled with the fact that its own Kconfig entry has listed it as OBSOLETE for over five months now, plus that it has very few references left in the tree, well, maybe it's not outrageous to think that it really can be tossed. but, like i said, i have no vested interest in this one way or the other, except for a fondness for getting rid of dead stuff. rday p.s. if it shouldn't be removed, maybe someone would like to add an entry to the feature removal file for it. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
On 4/13/07, David Miller [EMAIL PROTECTED] wrote: From: Robert Iakobashvili [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 23:11:14 +0200 It works good with 2.6.11.8 and debian 2.6.18.3-i686 image. At the same Intel Pentium-4 PC with the same about kernel configuration (make oldconfig using Debian config-2.6.18.3-i686) the setup fails with the tcp-connections stalled after 1000 established connections when the kernel is 2.6.20.6 or 2.6.19.5. It stalls even earlier, when lighttpd used with the default (poll ()) demultiplexing after 500 connections or when apache2 web server used (memory?) - after 100 connections. I am currently going to try vanilla 2.6.18.3 and, if with it also fails, to look through Debian patches, trying to figure out, what is the delta. Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Is not it done deliberately by the below patch: commit 9e950efa20dc8037c27509666cba6999da9368e8 Author: John Heffner [EMAIL PROTECTED] Date: Mon Nov 6 23:10:51 2006 -0800 Sorry, the commit is innocent. Something else has been broken in tcp_mem initialization logic. My machine has: MemTotal: 484368 kB and for all kernel configurations are actually the same with CONFIG_HIGHMEM4G=y Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... Navigare necesse est, vivere non est necesse ... http://curl-loader.sourceforge.net An open-source HTTP/S, FTP/S traffic generating, and web testing tool. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
Robert Iakobashvili wrote: Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Is not it done deliberately by the below patch: commit 9e950efa20dc8037c27509666cba6999da9368e8 Author: John Heffner [EMAIL PROTECTED] Date: Mon Nov 6 23:10:51 2006 -0800 [TCP]: Don't use highmem in tcp hash size calculation. This patch removes consideration of high memory when determining TCP hash table sizes. Taking into account high memory results in tcp_mem values that are too large. Is it a feature? My machine has: MemTotal: 484368 kB and for all kernel configurations are actually the same with CONFIG_HIGHMEM4G=y Thanks, Another patch that went in right around that time: commit 52bf376c63eebe72e862a1a6e713976b038c3f50 Author: John Heffner [EMAIL PROTECTED] Date: Tue Nov 14 20:25:17 2006 -0800 [TCP]: Fix up sysctl_tcp_mem initialization. Fix up tcp_mem initial settings to take into account the size of the hash entries (different on SMP and non-SMP systems). Signed-off-by: John Heffner [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] (This has been changed again for 2.6.21.) In the dmesg, there should be some messages like this: IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) What do yours say? Thanks, -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
Hi John, On 4/15/07, John Heffner [EMAIL PROTECTED] wrote: Robert Iakobashvili wrote: Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Another patch that went in right around that time: commit 52bf376c63eebe72e862a1a6e713976b038c3f50 Author: John Heffner [EMAIL PROTECTED] Date: Tue Nov 14 20:25:17 2006 -0800 [TCP]: Fix up sysctl_tcp_mem initialization. (This has been changed again for 2.6.21.) In the dmesg, there should be some messages like this: IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) What do yours say? For the 2.6.19.5, where we have this problem: From dmsg: IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) #cat /proc/sys/net/ipv4/tcp_mem 307240966144 MemTotal: 484368 kB CONFIG_HIGHMEM4G=y Thanks, Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... Navigare necesse est, vivere non est necesse ... http://curl-loader.sourceforge.net An open-source HTTP/S, FTP/S traffic generating, and web testing tool. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work
On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote: I hadn't considered an always-blocking (or unbuffered) networking API. It's very counter to current APIs, but does make sense with things like syslets. Without syslets, I don't think it's very useful as you need some artificial threads to keep things humming along. (How would userspace specify it? O_DIRECT when opening the tap?) TBH, I hadn't thought that far. Tap already has those IFF_NO_PI etc flags, but it might make sense to just be the default. From userspace's POV it's not a semantic change. OK, just tested: I can get 230,000 packets (28 byte UDP) through the tun device in a second (130,000 actually out the 100-base-T NIC, 100,000 dropped). If the tun driver's write() blocks until the skb is destroyed, it's 4,000 packets. So your intuition was right: skb_free latency on xmit (at least for this e1000) is far too large for anything but an async solution. Will ponder further. Thanks! Rusty. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[1/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist [EMAIL PROTECTED] Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski [EMAIL PROTECTED] Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann [EMAIL PROTECTED] Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged Subject: forcedeth: interface hangs under load References : http://lkml.org/lkml/2007/4/3/39 http://www.spinics.net/lists/netdev/msg28981.html Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Ayaz Abdulla [EMAIL PROTECTED] David Miller [EMAIL PROTECTED] Status : problem is being debugged Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6369800.html Submitter : Andi Kleen [EMAIL PROTECTED] Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : problem is being debugged Subject: Oops when changing USB DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 http://lkml.org/lkml/2007/4/5/154 Submitter : CIJOML [EMAIL PROTECTED] Handled-By : Markus Rechberger [EMAIL PROTECTED] Status : patches available - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.21rc7 e1000 media-detect oddness.
I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe e1000, and got this.. e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:d3:3a:62:d3 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and it works fine.. Why would no cable make it think the EEPROM is invalid ? I repeated this a few times, just to be sure it wasn't a fluke, and it seems to happen 100% reproducably. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message
Milan Kocián wrote: On Wed, 2007-04-11 at 20:19 +0200, Patrick McHardy wrote: I think having notifications for this case makes sense (IIRC I used to use a similar patch some time ago, but can't find it right now). But we need to indicate somehow that it is a replacement and not a completely new route, either by sending a RTM_DELROUTE for the old route first (which would match what devinet does for addresses) or by echoing the NLM_F_REPLACE flag. The former would probably be easier for userspace to understand since it wouldn't need to replicate the replacement logic just to find out which rule got replaced. Hard to tell what is better. I slightly tried to test my patch with quagga routing daemon. And then I tested second case: send RTM_DELROUTE before RTM_NEWROUTE. Quagga updates internal rib in both cases (as I saw in debug logs). I was in fear that quagga will try to install sefl route but it doesn't catch. So from my point of view is all the same :). Looking at some old code of mine, it would treat a simple RTM_NEWROUTE without deletion in advance incorrectly, but it also would ignore NLM_F_REPLACE. Quagga doing the right thing seems to be a result of the fact that it doesn't care about some of the routes attributes and treats NEWROUTE messages as replacements as long as the attributes it cares about match. RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct that it might cause userspace to perform some action upon receiving the DELROUTE message since the update is non-atomic. So I really don't know, I'm in favour of having notifications for replacements, but I fear we might break something. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work
Rusty Russell wrote: On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote: I hadn't considered an always-blocking (or unbuffered) networking API. It's very counter to current APIs, but does make sense with things like syslets. Without syslets, I don't think it's very useful as you need some artificial threads to keep things humming along. (How would userspace specify it? O_DIRECT when opening the tap?) TBH, I hadn't thought that far. Tap already has those IFF_NO_PI etc flags, but it might make sense to just be the default. From userspace's POV it's not a semantic change. OK, just tested: I can get 230,000 packets (28 byte UDP) through the tun device in a second (130,000 actually out the 100-base-T NIC, 100,000 dropped). If the tun driver's write() blocks until the skb is destroyed, it's 4,000 packets. So your intuition was right: skb_free latency on xmit (at least for this e1000) is far too large for anything but an async solution. Will ponder further. I think aio_write (but done copyless-lessly) is the way to go. Not only is the infrastructure there, but the API already allows for multiple packet submission and for batching completions. Fitting into that framework ought to be easier than starting yet another one. It still misses scatter/gather and integration with fd-based notification, but there are patches around for that. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen
Andrew Morton wrote: On Fri, 13 Apr 2007 13:53:12 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8325 Summary: -j REDIRECT --to-ports 1000-1009, always first choosen Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: Distribution: FC6, gentoo Hardware Environment: Software Environment: Problem Description: Steps to reproduce: Try redirecting to range of ports with iptables, kernel(?) will always redirect to first port from given range. It will use a different port if there is a clash (a connection with the same identity already exists). I'm guessing you're expecting that it will use the ports in order. We might be able to change that, but I don't really see a case where it would make sense. Please describe what you're trying to do. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen
Sorry, i will put my IMHO, since i am using it too. I guess it can be useful for load-balancing scenario. Is there way to provide both ways? Thinking... 60% done, But maybe this can be done over -m statistic already On Mon, 16 Apr 2007 07:12:33 +0200, Patrick McHardy wrote Andrew Morton wrote: On Fri, 13 Apr 2007 13:53:12 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8325 Summary: -j REDIRECT --to-ports 1000-1009, always first choosen Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: Distribution: FC6, gentoo Hardware Environment: Software Environment: Problem Description: Steps to reproduce: Try redirecting to range of ports with iptables, kernel(?) will always redirect to first port from given range. It will use a different port if there is a clash (a connection with the same identity already exists). I'm guessing you're expecting that it will use the ports in order. We might be able to change that, but I don't really see a case where it would make sense. Please describe what you're trying to do. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen
Denys wrote: Sorry, i will put my IMHO, since i am using it too. I guess it can be useful for load-balancing scenario. That makes sense with using multiple IPs (and we support doing that), but whats the point of load-balancing to differenet *ports*? Is there way to provide both ways? Thinking... 60% done, But maybe this can be done over -m statistic already 2.6.21-rc supports randomized port selection (with iptables userspace from SVN). Using the statistic match would work as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen
On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote Denys wrote: Sorry, i will put my IMHO, since i am using it too. I guess it can be useful for load-balancing scenario. That makes sense with using multiple IPs (and we support doing that), but whats the point of load-balancing to differenet *ports*? Easy - for example i have my own TCP acceleration solution, which is using REDIRECT, then getsockopt/SO_ORIGINAL_DST to get original IP, then forwarding to compressed tunnel, stripping unneeded bytes (oh, my expensive satellite bandwidth). This way for example i can do some kind load-balancing for satellite bandwidth. But i have done it over -m statistic. Is there way to provide both ways? Thinking... 60% done, But maybe this can be done over -m statistic already 2.6.21-rc supports randomized port selection (with iptables userspace from SVN). Using the statistic match would work as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen
Denys wrote: On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote That makes sense with using multiple IPs (and we support doing that), but whats the point of load-balancing to differenet *ports*? Easy - for example i have my own TCP acceleration solution, which is using REDIRECT, then getsockopt/SO_ORIGINAL_DST to get original IP, then forwarding to compressed tunnel, stripping unneeded bytes (oh, my expensive satellite bandwidth). This way for example i can do some kind load-balancing for satellite bandwidth. That sounds rather hackish, you might as well do it in your application. I just noticed we don't accept the random option for DNAT/REDIRECT yet, but that is easily fixed (I'll queue a patch for 2.6.22). Then this will work and select ports from the range randomly: iptables -t nat -A INPUT .. -j REDIRECT --to-ports 1000:1010 --random - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
