* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-10 6:56 UTC (permalink / raw)
To: abonilla, 'Pavel Machek', 'Jeff Garzik',
'Netdev list', 'kernel list',
'James P. Ketrenos'
In-Reply-To: <002a01c56cff$fb64ba70$600cc60a@amer.sykes.com>
On Thursday 09 June 2005 17:31, Alejandro Bonilla wrote:
>
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> >
> > That will be analogous to me plugging ethernet cable into the
> > switch and
> > wanting it to work, without any IP addr config, even without
> > DHCP client.
> > Just power up the box (or modprobe an eth module) and it
> > works! Cool, eh?
> >
>
> You want things one way, I like them in another way. Whoever makes this
> decision should just know that we would like to have an option to make it
> load with or without the ASSOC on.
But you already _have_ the option to associate. Just issue
appropriate iwconfig command (or embed one in startup script).
> James already said to use the options ipw2100 disable=1 if you don't want it
> to associate everytime on boot.
Do we have to add such option to each and every wireless driver now?
That would be wrong since iwconfig already exists.
> At the end, who decides this?
User. As I said, with no automatic assoc at module load user still
may easily attain that with iwconfig.
Adding kernel level wireless autoconfiguration duplicates the effort.
Since I am not going to give up a requirement to be able to stay radio
silent at boot (me too wants freedom, not only you), you need to add
disable=1 module parameter to each driver, which adds to the mess.
ALSA does the Right Thing. Sound is completely muted out at module load.
It's a user freedom to set desired volume level after that.
--
vda
^ permalink raw reply
* Re: 2.4.30-hf1 do_IRQ stack overflows
From: Manfred Schwarb @ 2005-06-10 8:10 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, davem, netdev, herbert
In-Reply-To: <20050609150026.GA7900@logos.cnet>
> Hi,
>
> On Tue, Jun 07, 2005 at 02:38:01PM +0200, Manfred Schwarb wrote:
> >
> >
> > >
> > > Hi Manfred,
> > >
> > > On Wed, May 11, 2005 at 10:15:02AM +0200, Manfred Schwarb wrote:
> > > > Hi,
> > > > with recent versions of the 2.4 kernel (Vanilla), I get an
> increasing
> > > amount of do_IRQ stack overflows.
> > > > This night, I got 3 of them.
> > > > With 2.4.28 I got an overflow about twice a year, with 2.4.29 nearly
> > > once a month and with
> > > > 2.4.30 nearly every day 8-((
> > >
> > > The system is getting dangerously close to an actual stack overflow,
> which
> > > would
> > > crash the system.
> > >
> > > "do_IRQ: stack overflow: " indicates how many bytes are still
> available.
> > >
> > > The traces show huge networking execution paths.
> > >
> > > It seems you are using some packet scheduler (CONFIG_NET_SCHED)?
> Pretty
> > > much all
> > > traces show functions from sch_generic.c. Can you disable that for a
> test?
> > >
> >
> > Sorry to bother you again, but the problem didn't vanish completely.
> > This morning, I caught another one. I built a new kernel with
> > CONFIG_NET_SCHED=n as suggested, uptime is now 25 days, and the
> following
> > is the first do_IRQ since then (ksymoops -i):
> >
> > Jun 7 03:55:01 tp-meteodat7 kernel: f3238830 00000280 f49e7b80 00000000
<---------snip-------->
> > [<c01594d4>] [<c01598d9>] [<c0159bb4>] [<c0158905>]
> > Warning (Oops_read): Code line not seen, dumping what data is available
>
> Do you have the "do_IRQ stack overflow" output and the amount of bytes
> left it informs?
>
Yes, it was a close one, 640. I append the original output to the end of
this email. Thanks for looking at this.
> > Trace; c010d948 <call_do_IRQ+5/d>
> > Trace; c023a039 <skb_copy_and_csum_dev+49/100>
<---------snip-------->
> > Trace; c010d948 <call_do_IRQ+5/d>
>
> I dont see any huge stack consumers on this callchain.
>
> David, Herbert, any clues what might be going on here?
>
>
Jun 7 03:55:01 tp-meteodat7 kernel: do_IRQ: stack overflow: 640
Jun 7 03:55:01 tp-meteodat7 kernel: f3238830 00000280 f49e7b80 00000000
00000042 cca1388e f4116980 f17aa000
Jun 7 03:55:01 tp-meteodat7 kernel: c010d948 00000042 f4116980
00000000 cca1388e f4116980 f17aa000 00000042
Jun 7 03:55:01 tp-meteodat7 kernel: 00000018 f61d0018 ffffff14
c023a039 00000010 00000246 ee5ea480 00000000
Jun 7 03:55:01 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13]
[skb_copy_and_csum_dev+73/256]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445916/96]
[qdisc_restart+114/432] [dev_queue_xmit+383/880]
Jun 7 03:55:01 tp-meteodat7 kernel: Call Trace: [<c010d948>]
[<c023a039>] [<f90df5dc>] [<c0248402>] [<c023cc7f>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_finish_output2+184/336]
[ip_finish_output2+0/336] [ip_finish_output2+0/336] [nf_hook_slow+478/528]
[ip_finish_output2+0/336] [ip_output+334/480]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02561a8>] [<c02560f0>]
[<c02560f0>] [<c024760e>] [<c02560f0>] [<c025492e>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_finish_output2+0/336]
[ip_queue_xmit2+213/671] [ip_queue_xmit2+0/671] [ip_queue_xmit2+0/671]
[nf_hook_slow+478/528] [ip_queue_xmit2+0/671]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02560f0>] [<c0256315>]
[<c0256240>] [<c0256240>] [<c024760e>] [<c0256240>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_queue_xmit+845/1536]
[ip_queue_xmit2+0/671] [tcp_v4_send_check+160/240]
[tcp_transmit_skb+1001/1792] [tcp_send_ack+132/208] [tcp_rfree+0/32]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0254d0d>] [<c0256240>]
[<c026daf0>] [<c0267c99>] [<c026a6f4>] [<c0259370>]
Jun 7 03:55:01 tp-meteodat7 kernel: [tcp_rfree+0/32]
[tcp_rcv_established+2042/2640] [tcp_v4_do_rcv+314/352]
[tcp_v4_rcv+1726/1952] [ip_local_deliver_finish+351/416]
[ip_local_deliver_finish+0/416]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0259370>] [<c02661ca>]
[<c026edaa>] [<c026f48e>] [<c025174f>] [<c02515f0>]
Jun 7 03:55:01 tp-meteodat7 kernel: [nf_hook_slow+478/528]
[ip_local_deliver_finish+0/416] [ip_rcv_finish+0/616]
[ip_local_deliver+399/576] [ip_local_deliver_finish+0/416]
[ip_rcv_finish+0/616]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c024760e>] [<c02515f0>]
[<c0251790>] [<c02510df>] [<c02515f0>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_rcv_finish+473/616]
[ip_rcv_finish+0/616] [nf_hook_slow+478/528] [ip_rcv_finish+0/616]
[ip_rcv+808/1120] [ip_rcv_finish+0/616]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0251969>] [<c0251790>]
[<c024760e>] [<c0251790>] [<c02514b8>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [netif_receive_skb+485/544]
[process_backlog+147/304] [net_rx_action+250/368] [do_softirq+118/224]
[do_IRQ+244/304] [call_do_IRQ+5/13]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c023d4d5>] [<c023d5a3>]
[<c023d73a>] [<c01254c6>] [<c010b094>] [<c010d948>]
Jun 7 03:55:01 tp-meteodat7 kernel: [set_ldt_desc+5/59]
[schedule+650/1344] [schedule_timeout+84/160] [process_timeout+0/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256523927/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256524281/96]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c010a625>] [<c011ce8a>]
[<c011cb14>] [<c011ca60>] [<f90f2697>] [<f90f27f9>]
Jun 7 03:55:01 tp-meteodat7 kernel:
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256524459/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256530630/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256904584/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256908606/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256911957/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526660/96]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f90f28ab>] [<f90f40c6>]
[<f914f588>] [<f915053e>] [<f9151255>] [<f8b3a3c4>]
Jun 7 03:55:01 tp-meteodat7 kernel:
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250598640/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526660/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250605583/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526660/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526660/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250602612/96]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b4bcf0>] [<f8b3a3c4>]
[<f8b4d80f>] [<f8b3a3c4>] [<f8b3a3c4>] [<f8b4cc74>]
Jun 7 03:55:01 tp-meteodat7 kernel:
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526660/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250525224/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250568899/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250613955/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250576507/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250526472/96]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b3a3c4>] [<f8b39e28>]
[<f8b448c3>] [<f8b4f8c3>] [<f8b4667b>] [<f8b3a308>]
Jun 7 03:55:01 tp-meteodat7 kernel:
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250576301/96]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4250628604/96]
[__kfree_skb+246/336]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445940/96]
[qdisc_restart+31/432] [dev_queue_xmit+383/880]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b465ad>] [<f8b531fc>]
[<c02387b6>] [<f90df5f4>] [<c02483af>] [<c023cc7f>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_finish_output2+184/336]
[__kfree_skb+246/336]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445940/96]
[__kfree_skb+246/336]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445940/96]
[qdisc_restart+31/432]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02561a8>] [<c02387b6>]
[<f90df5f4>] [<c02387b6>] [<f90df5f4>] [<c02483af>]
Jun 7 03:55:01 tp-meteodat7 kernel: [dev_queue_xmit+383/880]
[__kfree_skb+246/336]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445940/96]
[qdisc_restart+31/432] [dev_queue_xmit+383/880] [ip_finish_output2+184/336]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_finish_output2+0/336]
[ip_finish_output2+0/336] [nf_hook_slow+478/528] [ip_finish_output2+0/336]
[ip_output+334/480] [ip_finish_output2+0/336]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02560f0>] [<c02560f0>]
[<c024760e>] [<c02560f0>] [<c025492e>] [<c02560f0>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_queue_xmit2+213/671]
[sock_def_readable+99/128] [tcp_rfree+0/32] [tcp_rfree+0/32]
[tcp_rcv_established+1981/2640] [tcp_v4_do_rcv+314/352]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0256315>] [<c0237f63>]
[<c0259370>] [<c0259370>] [<c026618d>] [<c026edaa>]
Jun 7 03:55:01 tp-meteodat7 kernel: [tcp_v4_rcv+1726/1952]
[ip_local_deliver_finish+351/416] [ip_local_deliver_finish+0/416]
[nf_hook_slow+478/528] [ip_local_deliver_finish+0/416] [ip_rcv_finish+0/616]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c026f48e>] [<c025174f>]
[<c02515f0>] [<c024760e>] [<c02515f0>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_local_deliver+399/576]
[ip_local_deliver_finish+0/416] [ip_rcv_finish+0/616]
[ip_rcv_finish+473/616] [ip_rcv_finish+0/616] [nf_hook_slow+478/528]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02510df>] [<c02515f0>]
[<c0251790>] [<c0251969>] [<c0251790>] [<c024760e>]
Jun 7 03:55:01 tp-meteodat7 kernel: [ip_rcv_finish+0/616]
[__alloc_pages+100/640] [poll_freewait+68/80] [do_select+569/592]
[sys_select+660/1248] [sys_ioctl+677/785]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0251790>] [<c013e624>]
[<c01594d4>] [<c01598d9>] [<c0159bb4>] [<c0158905>]
Jun 7 03:55:01 tp-meteodat7 kernel: [sys_time+21/80] [system_call+51/56]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0124bb5>] [<c0108fa7>]
In my previous posting, I snipped /var/log/messages at the wrong place,
and zapped the last line. This line results in two additional
lines of the ksymoops output:
Trace; c0124bb5 <sys_time+15/50>
Trace; c0108fa7 <system_call+33/38>
--
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
^ permalink raw reply
* (unknown),
From: Zoran Bosic (ZG/ETK) @ 2005-06-10 8:27 UTC (permalink / raw)
To: netdev
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Pavel Machek @ 2005-06-10 9:00 UTC (permalink / raw)
To: Alejandro Bonilla
Cc: Jeff Garzik, James Ketrenos, David S. Miller, vda, netdev,
linux-kernel, ipw2100-admin
In-Reply-To: <42A8FF03.3010508@linuxwireless.org>
Hi!
> OK. I understand the point and I totally agree with this. We really want
> the adapter to just do what the user or profiles ask the adapter to do.
> Yes, in an ideal world.
>
> Let's talk about easyness. These adapters are in laptops. You don't want
> to type a lot of stop everytime you move from access points, reboots
> and
We are not trying to make it hard to the users. Lets do the right
thing in kernel, and let userspace make it easy.
Pavel
^ permalink raw reply
* Your premier source for all ATI powered gear.
From: Tybalt @ 2005-06-10 12:59 UTC (permalink / raw)
To: netdev
The world's best software for research, science and engineering.
No one should drive a hard bargain with an artist.
Tis the advisor who suffers from bad advice.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: John Stoffel @ 2005-06-10 13:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Alejandro Bonilla, Jeff Garzik, James Ketrenos, David S. Miller,
vda, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050610090022.GF4173@elf.ucw.cz>
I'd like to chime in here and say that from my point of view, not
enabling the wireless network adaptor until asked by userspace is the
way to go.
It reduces power requirements, and it pushes the configuration details
out to userspace, where they can be handled according to the policy
setup by the distro/user.
Having my latop bootup and turn on the wireless card and join an AP
without my explicity asking is a bad thing to have happen.
John
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Alejandro Bonilla @ 2005-06-10 13:23 UTC (permalink / raw)
To: 'Denis Vlasenko', abonilla, 'Pavel Machek',
'Jeff Garzik', 'Netdev list',
'kernel list', 'James P. Ketrenos'
In-Reply-To: <200506100956.16031.vda@ilport.com.ua>
>
> Adding kernel level wireless autoconfiguration duplicates the effort.
> Since I am not going to give up a requirement to be able to stay radio
> silent at boot (me too wants freedom, not only you), you need to add
> disable=1 module parameter to each driver, which adds to the mess.
>
> ALSA does the Right Thing. Sound is completely muted out at
> module load.
> It's a user freedom to set desired volume level after that.
Yeah right. I remember I had to google for 10 minutes to find the answer for
this one. Why would you install something, for it to not work?
It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
and enable it. Why would it make you google for more things to do? ALSA mute
on install is WAY way, not OK.
You *will* have to use a How-To with ALSA, nobody knows that your sound
would be off because some people decided it.
But this is out of the Topic. I agree with you all, but as I mentioned in a
more current email, this is a laptop, not a server. Things behave
differently and you want things faster. (Yes, I could have a script)
What I'm saying, is that just as ALSA, you will have to google even more
just to be able to look for the boot param for the driver for it to ASSOC on
boot like the Original drive does. Instead, if you simply don't want to
associate then turn off the Radio.
It's a simple FN+F2 or depends on your laptop.
Let's not make this a bigger thread, just decide and then do it that way.
I'm looking at this on the side of a supporter, seeing the emails from
users... "how do I make it behave as it was before" "it won't assoc on boot
anymore"
.Alejandro
> --
> vda
>
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Alejandro Bonilla @ 2005-06-10 13:33 UTC (permalink / raw)
To: 'Pavel Machek'
Cc: 'Jeff Garzik', 'James Ketrenos',
'David S. Miller', vda, netdev, linux-kernel
In-Reply-To: <20050610090022.GF4173@elf.ucw.cz>
> Hi!
>
> > OK. I understand the point and I totally agree with this.
> We really want
> > the adapter to just do what the user or profiles ask the
> adapter to do.
> > Yes, in an ideal world.
> >
> > Let's talk about easyness. These adapters are in laptops.
> You don't want
> > to type a lot of stop everytime you move from access points, reboots
> > and
>
> We are not trying to make it hard to the users. Lets do the right
> thing in kernel, and let userspace make it easy.
> Pavel
Pavel,
Agreed then.
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Jason Lunz @ 2005-06-10 14:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <1118361376.5838.20.camel@rh4>
mchan@broadcom.com said:
> On Thu, 2005-06-09 at 17:38 -0700, Ben Greear wrote:
>
>>
>> * Is the BCM5704 chipset/driver really that much slower?
>>
>
> Unfortunately, the 5704 requires the "ONE_DMA" workaround which will
> limit throughput in a PCIX 100/133 bus. If you comment out the line that
> sets the DMA_RWCTRL_ONE_DMA flag in tg3.c, you should see improved
> performance. However, you may run into some DMA issues on certain
> systems.
>
>> * Is there some information on tuning the tg3 somewhere?
>> (I didn't see a Documentation/networking/tg3.txt file, for instance)
>>
>> * Is there a way to verify the bus speed that the NIC is running at?
>> (ethtool -d ethX gives lots of meaningless (to me) hex)
>>
>
> tg3 probing string for each device will tell you the bus type, width,
> and speed.
The patch below from http://article.gmane.org/gmane.linux.network/18734
does this too for e1000. Lennert Buytenhek posted it a while back.
Jason
diff -urpN linux-pf/drivers/net/e1000/e1000_main.c linux-bs/drivers/net/e1000/e1000_main.c
--- linux-pf/drivers/net/e1000/e1000_main.c Fri Apr 8 15:06:34 2005
+++ linux-bs/drivers/net/e1000/e1000_main.c Fri Apr 8 15:29:34 2005
@@ -617,6 +617,21 @@ e1000_probe(struct pci_dev *pdev,
if(eeprom_data & eeprom_apme_mask)
adapter->wol |= E1000_WUFC_MAG;
+ /* print bus type/speed/width info */
+ printk(KERN_INFO "%s: e1000 (PCI%s:%s:%s) ", netdev->name,
+ ((adapter->hw.bus_type == e1000_bus_type_pcix) ? "X" : ""),
+ ((adapter->hw.bus_speed == e1000_bus_speed_133) ? "133MHz" :
+ (adapter->hw.bus_speed == e1000_bus_speed_120) ? "120MHz" :
+ (adapter->hw.bus_speed == e1000_bus_speed_100) ? "100MHz" :
+ (adapter->hw.bus_speed == e1000_bus_speed_66) ? "66MHz" :
+ "33MHz"),
+ ((adapter->hw.bus_width == e1000_bus_width_64) ? "64-bit" :
+ "32-bit"));
+
+ for (i = 0; i < 6; i++)
+ printk("%2.2x%c", netdev->dev_addr[i],
+ i == 5 ? '\n' : ':');
+
/* reset the hardware with the new settings */
e1000_reset(adapter);
^ permalink raw reply
* [patch 2.6.12-rc6] 3c59x: remove superfluous vortex_debug test from boomerang_start_xmit
From: John W. Linville @ 2005-06-10 14:27 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: akpm, jgarzik
Remove the superfluous test of "if (vortex_debug > 3)" inside the
"if (vortex_debug > 6)" clause early in boomerang_start_xmit.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
I stumbled across this while looking at something else...
drivers/net/3c59x.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -2202,9 +2202,8 @@ boomerang_start_xmit(struct sk_buff *skb
if (vortex_debug > 6) {
printk(KERN_DEBUG "boomerang_start_xmit()\n");
- if (vortex_debug > 3)
- printk(KERN_DEBUG "%s: Trying to send a packet, Tx index %d.\n",
- dev->name, vp->cur_tx);
+ printk(KERN_DEBUG "%s: Trying to send a packet, Tx index %d.\n",
+ dev->name, vp->cur_tx);
}
if (vp->cur_tx - vp->dirty_tx >= TX_RING_SIZE) {
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Lee Revell @ 2005-06-10 20:26 UTC (permalink / raw)
To: abonilla
Cc: 'Denis Vlasenko', 'Pavel Machek',
'Jeff Garzik', 'Netdev list',
'kernel list', 'James P. Ketrenos'
In-Reply-To: <000f01c56dbf$9b15de90$600cc60a@amer.sykes.com>
On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
> >
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
>
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
>
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.
It took you 10 minutes of googling before you thought to try the mixer?
Sorry dude, this is PEBKAC.
Lee
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Alejandro Bonilla @ 2005-06-10 21:00 UTC (permalink / raw)
To: 'Lee Revell'; +Cc: 'Netdev list', 'kernel list'
In-Reply-To: <1118435188.6423.26.camel@mindpipe>
> > It thing of Mute in ALSA is stupid. If you want Sound, you
> install the Sound
> > and enable it. Why would it make you google for more things
> to do? ALSA mute
> > on install is WAY way, not OK.
>
> It took you 10 minutes of googling before you thought to try
> the mixer?
> Sorry dude, this is PEBKAC.
>
> Lee
Riiiight. It could be. Or it could be that no where in the world I have seen
something where the device would be disabled by default without notifying
the user. Why would you Mute the driver? Is the driver that bad, that the
developers would rather Mute the sound card, just in case if the sound cards
starts making noises and shit when the driver is loaded?
You are moving to another topic. Let's drop it.
.Alejandro
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Lee Revell @ 2005-06-10 21:07 UTC (permalink / raw)
To: abonilla; +Cc: 'Netdev list', 'kernel list'
In-Reply-To: <003001c56dff$662fe4b0$600cc60a@amer.sykes.com>
On Fri, 2005-06-10 at 15:00 -0600, Alejandro Bonilla wrote:
> > > It thing of Mute in ALSA is stupid. If you want Sound, you
> > install the Sound
> > > and enable it. Why would it make you google for more things
> > to do? ALSA mute
> > > on install is WAY way, not OK.
> >
> > It took you 10 minutes of googling before you thought to try
> > the mixer?
> > Sorry dude, this is PEBKAC.
> >
> > Lee
>
> Riiiight. It could be. Or it could be that no where in the world I have seen
> something where the device would be disabled by default without notifying
> the user. Why would you Mute the driver? Is the driver that bad, that the
> developers would rather Mute the sound card, just in case if the sound cards
> starts making noises and shit when the driver is loaded?
>
Userspace should handle it, doing this in the kernel is bloat.
My Debian system initializes the mixer settings to a sane state just
fine when the alsasound init script is run. Maybe you need a better
distro.
Users who compile ALSA from source are expected to know what they are
doing. And, if you watch the "make install" output, it prints a big fat
warning that all mixer controls are muted by default.
> You are moving to another topic. Let's drop it.
Agreed, but it was your OT rant that changed the topic...
Lee
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Ben Greear @ 2005-06-10 21:09 UTC (permalink / raw)
To: Michael Chan; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <1118363861.5838.29.camel@rh4>
Michael Chan wrote:
> On Thu, 2005-06-09 at 18:24 -0700, Ben Greear wrote:
>
>>Michael Chan wrote:
>>
>>>Unfortunately, the 5704 requires the "ONE_DMA" workaround which will
>>>limit throughput in a PCIX 100/133 bus. If you comment out the line that
>>>sets the DMA_RWCTRL_ONE_DMA flag in tg3.c, you should see improved
>>>performance. However, you may run into some DMA issues on certain
>>>systems.
>>
>>Is there any way I can tell which systems are affected? It won't be
>>an option for me to purposefully ship possibly busted drivers/hardware,
>>but if I can be certain that my systems are immune, I will try this
>>modification.
>>
>
> I mentioned this so that you could verify that the slow performance was
> indeed caused by ONE_DMA. Even if your system is affected, it's a very
> subtle problem that won't show up right away and should allow you to get
> some performance numbers.
I commented out the code and ran the pktgen test again. It may be a small
bit better, but not much: 770Mbps in one direction, 750Mbps in the other.
Have you done any tests with 2 tg3 NICs in a single machine to see if they
can run at or near line speed (full duplex)?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Michael Chan @ 2005-06-10 21:16 UTC (permalink / raw)
To: Ben Greear; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <42AA016C.9050801@candelatech.com>
On Fri, 2005-06-10 at 14:09 -0700, Ben Greear wrote:
> I commented out the code and ran the pktgen test again. It may be a small
> bit better, but not much: 770Mbps in one direction, 750Mbps in the other.
>
The latest tg3 driver will print out the dma_rwctrl at probe time. Can
you check the value to make sure ONE_DMA is disabled? Bit 14 sets
ONE_DMA.
> Have you done any tests with 2 tg3 NICs in a single machine to see if they
> can run at or near line speed (full duplex)?
>
Yes, we have years ago but not with the tg3 driver. We set up the 5704
to bridge (or route, I don't remember) one port to the other. It cannot
bridge at line-rate with the ONE_DMA workaround enabled.
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Rick Jones @ 2005-06-10 21:33 UTC (permalink / raw)
To: Ben Greear; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <42AA016C.9050801@candelatech.com>
> Have you done any tests with 2 tg3 NICs in a single machine to see if they
> can run at or near line speed (full duplex)?
It isn't just a question of two tg3 NICs in the same box is it? You are running
two NICs on the same bus right? And unless my dimm memory is mistaken, four
ports on a card with 5704s means two 5704's a bridge chip right? So, it would
be two tg3 NICs going through the same bridge chip, not just the same bus or
same system. I'd be worrying about DMA latencies on the system and the bridge
chip, and perhaps the efficiency of the PCI-X bus usage (not sure - is there
anything in your system's chipset to extract that sort of information?)
What happens when you turn pktgen around/insideout and source packets from the
bridging system to each of the (two other?) systems?
Since you are bridging, does having CKO enabled really matter? Mightn't that
allow the firmware on the 5704(s) to run a triffle faster? Or does bridging
already not request CKO (I suppose it might).
Are your interface interrupts distributed across the CPUs?
rick jones
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Ben Greear @ 2005-06-10 21:56 UTC (permalink / raw)
To: Rick Jones; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <42AA0743.1020101@hp.com>
Rick Jones wrote:
>
>> Have you done any tests with 2 tg3 NICs in a single machine to see if
>> they
>> can run at or near line speed (full duplex)?
>
>
> It isn't just a question of two tg3 NICs in the same box is it? You are
> running two NICs on the same bus right? And unless my dimm memory is
> mistaken, four ports on a card with 5704s means two 5704's a bridge chip
> right? So, it would be two tg3 NICs going through the same bridge chip,
> not just the same bus or same system. I'd be worrying about DMA
> latencies on the system and the bridge chip, and perhaps the efficiency
> of the PCI-X bus usage (not sure - is there anything in your system's
> chipset to extract that sort of information?)
There will be a bridge chip, and indeed I see better performance when I just
use a 2-port Intel NIC as opposed to a 4 port, even if I am only actively
using 2 of the 4 ports on the 4-port NIC. For the tg3 hardware I only
have a 4-port NIC. I do assume that a 2-port tg3 NIC w/out a bridge chip
would be faster..but probably not too much.
> What happens when you turn pktgen around/insideout and source packets
> from the bridging system to each of the (two other?) systems?
I looped two ports on the same NIC together for the pktgen tests, so there
is only a single machine in question. With Intel I can source/sink about
960Mbps on two ports simultaneously in this configuration. With the tg3
NIC I can only do about 750Mbps.
And, the tg3 is in the faster PCI-X slot (133Mhz v/s 100Mhz). So, to me
it appears that the tg3 hardware and/or driver can only handle about 80%
of the performance that the intel e1000 can produce. It's possible I have
a particularly sub-optimal configuration for tg3, or maybe a poorly designed
NIC, which is why I'd like to know what others see...
> Since you are bridging, does having CKO enabled really matter? Mightn't
> that allow the firmware on the 5704(s) to run a triffle faster? Or does
> bridging already not request CKO (I suppose it might).
CKO == IP checksum offload?
Since Dave doesn't want to debug my bridge setup (and I don't blame him),
I am going to try to focus my testing/debug reports on the pktgen tests.
If/when pktgen shows better performance with tg3, I can verify that
I see the same speedups with my proprietary bridging module. I've no idea
if CKO would help or hinder pktgen, nor have I tried to enable or disable it.
> Are your interface interrupts distributed across the CPUs?
I'm using FC2, basically a default install. It does seem to have
an irq balance daemon running. But, I'm not specifically binding IRQs
or anything like that. pktgen tx is running as a single thread, so the rx
code could run mostly on the other CPU if locking allows...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Rick Jones @ 2005-06-10 22:03 UTC (permalink / raw)
To: Ben Greear; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <42AA0C9D.2060006@candelatech.com>
> There will be a bridge chip, and indeed I see better performance when I just
> use a 2-port Intel NIC as opposed to a 4 port, even if I am only actively
> using 2 of the 4 ports on the 4-port NIC. For the tg3 hardware I only have a
> 4-port NIC. I do assume that a 2-port tg3 NIC w/out a bridge chip would be
> faster..but probably not too much.
I have been taught by several wise old engineers that the proper spelling of
assume is ass-u-me :)
Bridge chips can in theory do all sorts of nasty things to performance.
> CKO == IP checksum offload?
Yes.
> Since Dave doesn't want to debug my bridge setup (and I don't blame him), I
> am going to try to focus my testing/debug reports on the pktgen tests.
> If/when pktgen shows better performance with tg3, I can verify that I see the
> same speedups with my proprietary bridging module. I've no idea if CKO would
> help or hinder pktgen, nor have I tried to enable or disable it.
>
>> Are your interface interrupts distributed across the CPUs?
>
>
> I'm using FC2, basically a default install. It does seem to have an irq
> balance daemon running. But, I'm not specifically binding IRQs or anything
> like that. pktgen tx is running as a single thread, so the rx code could run
> mostly on the other CPU if locking allows...
again, never ass-u-me.
rick
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Ben Greear @ 2005-06-10 22:25 UTC (permalink / raw)
To: Rick Jones; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <42AA0E17.8050201@hp.com>
Rick Jones wrote:
>
>> There will be a bridge chip, and indeed I see better performance when
>> I just use a 2-port Intel NIC as opposed to a 4 port, even if I am
>> only actively using 2 of the 4 ports on the 4-port NIC. For the tg3
>> hardware I only have a
>> 4-port NIC. I do assume that a 2-port tg3 NIC w/out a bridge chip
>> would be
>> faster..but probably not too much.
>
>
> I have been taught by several wise old engineers that the proper
> spelling of assume is ass-u-me :)
>
> Bridge chips can in theory do all sorts of nasty things to performance.
Sure...but the end result is that I need 2 port NICs and I need 4 port NICs.
The 4-port ones need a bridge, so I'm stuck with a bridge. The Intel 4-port
with a bridge works OK, the tg3 not so good. If someone else has a 2-port
BCM NIC that handles full line speed, then that would be a good data point,
but I'm unlikely to purchase one just to satisfy my curiousity. If someone
wants to send me one, I'll happily stick it in my system and report the results.
>> I'm using FC2, basically a default install. It does seem to have an irq
>> balance daemon running. But, I'm not specifically binding IRQs or
>> anything
>> like that. pktgen tx is running as a single thread, so the rx code
>> could run
>> mostly on the other CPU if locking allows...
>
> again, never ass-u-me.
I'm not assuming anything here...just reporting the setup.
Truth is, the e1000 works really well for my application in most
configurations. It was interesting for me to learn that
some folks are getting very good tg3 performance for TCP
transfers when the e1000 was dropping frames (see thread
from the last week or so). So, I was a little supprised that
I did not see such good tg3 numbers.
If the answer is that the tg3 just can't do it, no shame there...but
if my testing can help the tg3 driver improve, I will try to do my
part.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM5704 performance questions.
From: Ben Greear @ 2005-06-10 22:35 UTC (permalink / raw)
To: Michael Chan; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <1118438203.5294.7.camel@rh4>
Michael Chan wrote:
> On Fri, 2005-06-10 at 14:09 -0700, Ben Greear wrote:
>>I commented out the code and ran the pktgen test again. It may be a small
>>bit better, but not much: 770Mbps in one direction, 750Mbps in the other.
>>
> The latest tg3 driver will print out the dma_rwctrl at probe time. Can
> you check the value to make sure ONE_DMA is disabled? Bit 14 sets
> ONE_DMA.
I don't see any printout in /var/log/messages that looks like it
relates to the dma_rwctrl. I'm using the driver in 2.6.11..maybe
it is not recent enough to print this information out?
>>Have you done any tests with 2 tg3 NICs in a single machine to see if they
>>can run at or near line speed (full duplex)?
>>
> Yes, we have years ago but not with the tg3 driver. We set up the 5704
> to bridge (or route, I don't remember) one port to the other. It cannot
> bridge at line-rate with the ONE_DMA workaround enabled.
Ok. Do you have other chipsets/NICs that can handle faster GigE speeds?
If you'd like to send me some multi-port NICs to play with I'll be happy
to report my findings :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM5704 performance questions.
From: David S. Miller @ 2005-06-10 22:43 UTC (permalink / raw)
To: greearb; +Cc: mchan, netdev
In-Reply-To: <42AA15B7.8050407@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 10 Jun 2005 15:35:35 -0700
> Michael Chan wrote:
> > On Fri, 2005-06-10 at 14:09 -0700, Ben Greear wrote:
>
> >>I commented out the code and ran the pktgen test again. It may be a small
> >>bit better, but not much: 770Mbps in one direction, 750Mbps in the other.
> >>
>
> > The latest tg3 driver will print out the dma_rwctrl at probe time. Can
> > you check the value to make sure ONE_DMA is disabled? Bit 14 sets
> > ONE_DMA.
>
> I don't see any printout in /var/log/messages that looks like it
> relates to the dma_rwctrl. I'm using the driver in 2.6.11..maybe
> it is not recent enough to print this information out?
Yes, your driver is too old. The one in Linus's current GIT
tree has this, along with many other enhancements.
^ permalink raw reply
* testing techniques to confirm the effectiveness of changes made to sch_gred.c
From: Rahul Hari @ 2005-06-11 0:39 UTC (permalink / raw)
To: netdev, netdev, lartc-request, diffserv-general, linux.kernel
Hi,
I have made some changes to the file sch_gred.c to modify the GRED
queueing discipline to support the following features:
1) The first virtual queue should get absolute priority while
dequeueing (not caring if the others get starved)
2) While in equalise mode and with RIO mode enabled, the packets in
the first virtual queue should not be counted for calculating the
qave.
I want to confirm if the changes made by me are really effective. I
would be grateful if someone could let me know about any testing
techniques that can be followed for confirming that the changes are
really effective.
It would be great if someone could also let me know if the logic that
I have applied to effect these changes is correct.
My logic is as follows:
1) Since the process deals with dequeueing, i have to make changes to
gred_dequeue only. If t->tab[0] != 0 then we dequeue the packet
otherwise do not dequeue it.
2)
if (t->eqp && t->grio) {
for (i=0;i<t->DPs;i++) {
if ((!t->tab[i]) || (i==q->DP) || (i==0))
continue;
if ((t->tab[i] != q) && (PSCHED_IS_PASTPERFECT(t->tab[i]->qidlestart)))
qave +=t->tab[i]->qave;
}
Regards,
Rahul
--
----------------------
"The fear you let build up in your mind is worse than the situation
that actually exists"
from "who moved my cheese"
---------------------------------------------------------------------------------
Rahul Hari
Senior Under Grad. Student,
Department of CSE,
ITBHU,
Varanasi.
Ph: +91-9845347020
rahul.hari@cse06.itbhu.org
------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Sockets hang in FIN_WAIT1 state in linux 2.2.5
From: Martin Pool @ 2005-06-11 2:03 UTC (permalink / raw)
To: Pavan K; +Cc: ak, kuznet, netdev, Alan.Cox
In-Reply-To: <20050610105808.13626.qmail@web30909.mail.mud.yahoo.com>
On 10 Jun 2005, Pavan K <pavankrishnamurthy@yahoo.com> wrote:
> Hi,
> This is Pavan from India, a s/w engineer stuck in a TCP problem. We have a
> legendary linux 2.2.5 kernel (redhat ) system which cant be replaced in my
> company. I have noticed that my server stops ACK ing the SYN packets after some
> time . Also when i netstat i can see lots of sockets hung in FIN_WAIT1 state.
> Upon googling, I found ur mails in the mailing list. Sounds that you too had
> similar problems.
> So please suggest me any solution to this problem if you have. I am in a
> critical stage to fix this bug. I cant upgrade my system to newer kernel since
> it needs lot of code porting.
I've heard similar reports from people running distcc on 2.2 kernels;
after a long time the machine stops accepting new connections. If you
can't upgrade the kernel your options are very limited: either work
out the precise patch, or reboot your machines regularly. The second
is probably easier.
--
Martin
^ permalink raw reply
* [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-11 7:43 UTC (permalink / raw)
To: David S. Miller; +Cc: xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050611062413.GA1324@pcw.home.local>
Hi David,
well, I could easily build a proof of concept demonstrating the security
problem implied by the simultaneous connect support. For this, I have two
machines on the LAN. One (wks, 10.0.3.9, 2.4.29) wants to connect to
www.kernel.org:80 (204.152.191.5). It works as expected :
wks:willy$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
HTTP/1.1 200 OK
Date: Sat, 11 Jun 2005 07:08:27 GMT
Server: Apache/2.0.52 (Fedora)
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
ret=0
The other one (pcw) tries to prevent wks from connecting to www.kernel.org,
by sending to it about 10 SYNs per second spoofing kernel.org's port 80 :
pcw# hping2 -i u100000 -k -a 204.152.191.5 -s 80 -I eth0 10.0.3.9 -p 10000 -S -M 12345678
During this, the client cannot connect to www.kernel.org from this port
anymore :
wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
ret=1
Capture on the victim (wks=victim, pcw=attacker, www=www.kernel.org):
wks 09:06:44.020809 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) win 5840 <mss 1460,nop,wscale 0> (DF)
pcw 09:06:44.065589 204.152.191.5.80 > 10.0.3.9.10000: S 12345678:12345678(0) win 512
wks 09:06:44.065621 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) ack 12345679 win 5840 <mss 1460,nop,wscale 0> (DF)
pcw 09:06:44.166544 204.152.191.5.80 > 10.0.3.9.10000: S 12345678:12345678(0) win 512
www 09:06:44.217896 204.152.191.5.80 > 10.0.3.9.10000: S 2774672577:2774672577(0) ack 4010109824 win 5840 <mss 1420,nop,wscale 2> (DF)
wks 09:06:44.217939 10.0.3.9.10000 > 204.152.191.5.80: . ack 12345679 win 5840 (DF)
wks 09:06:47.020040 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) ack 12345679 win 5840 <mss 1460,nop,wscale 0> (DF)
...
=> cannot establish, because of either my local firewall or www.kernel.org's
blocks wrong ACKs. Without a firewall, wks would have got an RST.
With the attached patch, I can no longer block the communication :
09:31:23.004379 IP (tos 0x0, ttl 64, id 36202, offset 0, flags [DF], length: 60) 10.0.3.1.10000 > 204.152.191.5.80: S [tcp sum ok] 1176290222:1176290222(0) win 13920 <mss 6960,sackOK,timestamp 4294921924 0,nop,wscale 2>
09:31:23.051743 IP (tos 0x0, ttl 64, id 9074, offset 0, flags [none], length: 40) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 12345678:12345678(0) win 512
09:31:23.102683 IP (tos 0x0, ttl 64, id 42364, offset 0, flags [none], length: 40) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 12345678:12345678(0) win 512
09:31:23.203546 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], length: 60) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 3923636405:3923636405(0) ack 1176290223 win 5792 <mss 1420,sackOK,timestamp 2199155996 4294921924,nop,wscale 2>
09:31:23.203625 IP (tos 0x0, ttl 64, id 36204, offset 0, flags [DF], length: 52) 10.0.3.1.10000 > 204.152.191.5.80: . [tcp sum ok] 1176290223:1176290223(0) ack 3923636406 win 3480 <nop,nop,timestamp 4294922124 2199155996>
=> the client ignores fake SYNs and the connection establishes normally.
The proposed patch adds a "tcp_simult_connect "sysctl which is disabled by
default to fix the problem for non-aware people. Those who know they need
the simultaneous connect can enable it manually, but I doubt we can find
many of them.
Does it seem appropriate for mainline ? In this case, I would also backport
it to 2.4 and send it to you for inclusion.
Thanks,
Willy
diff -urN linux-2.6.11.11/include/linux/sysctl.h linux-2.6.11.11-tcp/include/linux/sysctl.h
--- linux-2.6.11.11/include/linux/sysctl.h Mon Mar 28 07:06:45 2005
+++ linux-2.6.11.11-tcp/include/linux/sysctl.h Sat Jun 11 09:00:22 2005
@@ -345,6 +345,7 @@
NET_TCP_MODERATE_RCVBUF=106,
NET_TCP_TSO_WIN_DIVISOR=107,
NET_TCP_BIC_BETA=108,
+ NET_TCP_SIMULT_CONNECT=109,
};
enum {
diff -urN linux-2.6.11.11/include/net/tcp.h linux-2.6.11.11-tcp/include/net/tcp.h
--- linux-2.6.11.11/include/net/tcp.h Mon Mar 28 07:06:45 2005
+++ linux-2.6.11.11-tcp/include/net/tcp.h Sat Jun 11 08:56:16 2005
@@ -608,6 +608,7 @@
extern int sysctl_tcp_bic_beta;
extern int sysctl_tcp_moderate_rcvbuf;
extern int sysctl_tcp_tso_win_divisor;
+extern int sysctl_tcp_simult_connect;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff -urN linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c
--- linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c Mon Mar 28 07:06:48 2005
+++ linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c Sat Jun 11 08:55:27 2005
@@ -690,6 +690,14 @@
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = NET_TCP_SIMULT_CONNECT,
+ .procname = "tcp_simult_connect",
+ .data = &sysctl_tcp_simult_connect,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff -urN linux-2.6.11.11/net/ipv4/tcp_input.c linux-2.6.11.11-tcp/net/ipv4/tcp_input.c
--- linux-2.6.11.11/net/ipv4/tcp_input.c Fri Jun 10 22:49:43 2005
+++ linux-2.6.11.11-tcp/net/ipv4/tcp_input.c Sat Jun 11 08:58:54 2005
@@ -84,6 +84,7 @@
int sysctl_tcp_stdurg;
int sysctl_tcp_rfc1337;
+int sysctl_tcp_simult_connect;
int sysctl_tcp_max_orphans = NR_FILE;
int sysctl_tcp_frto;
int sysctl_tcp_nometrics_save;
@@ -4620,7 +4621,7 @@
if (tp->rx_opt.ts_recent_stamp && tp->rx_opt.saw_tstamp && tcp_paws_check(&tp->rx_opt, 0))
goto discard_and_undo;
- if (th->syn) {
+ if (th->syn && sysctl_tcp_simult_connect) {
/* We see SYN without ACK. It is attempt of
* simultaneous connect with crossed SYNs.
* Particularly, it can be connect to self.
^ permalink raw reply
* Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?
From: Andi Kleen @ 2005-06-11 10:25 UTC (permalink / raw)
To: Skywind; +Cc: davem, casavan, linux-kernel, netdev
In-Reply-To: <75052be705060607106a6c0882@mail.gmail.com>
Skywind <gnuwind@gmail.com> writes:
>
> It seems that kernel don't adjust these value automatic, is this a bug?
>
> I guess the mechanism of tcp.c in 2.6.11 have some changes(between
> 2.6.10), and it conduce to this result,
> Is this guess correctly?
Yes, there were some changes here when it was converted to a common
function for all hash tables (alloc_large_system_hash - the function
with the argument list from hell). Anyways, here's a quick fix.
DaveM for your consideration.
Adjust TCP mem order check to new alloc_large_system_hash
Signed-off-by: Andi Kleen <ak@suse.de>
--- linux-2.6.11-work/net/ipv4/tcp.c~ 2005-03-02 08:37:51.000000000 +0100
+++ linux-2.6.11-work/net/ipv4/tcp.c 2005-06-11 12:16:22.000000000 +0200
@@ -2337,7 +2337,7 @@
(tcp_bhash_size * sizeof(struct tcp_bind_hashbucket));
order++)
;
- if (order > 4) {
+ if (order >= 4) {
sysctl_local_port_range[0] = 32768;
sysctl_local_port_range[1] = 61000;
sysctl_tcp_max_tw_buckets = 180000;
^ 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