[possibly OT] for_each_netdev() in 2.6.23-gitX / 2.6.24-rc1-gitY breaks Cisco VPN client
It's been a while I noticed, but I thought someone would as usual cook up some fix, while I don't even see the issue been reported... if this isn't a Linux kernel/net issue just drop my email, thanks. Error message during cisco_vpn.ko build: /download/linux/net/vpnclient/interceptor.c:345:23: error: macro for_each_netdev requires 2 arguments, but only 1 given seems like for_each_netdev() now also uses init_net. If there is an alternative and somebody could point me to that, it'd be great, as understanding the issue is well out of my grasp. Patching up the vpnclient source to use init_net gets me to depmod complaining it's not allowed to use a GPL-only symbol (init_net) in a proprietary module. If this is meant to be - fine, and apologies for the waste of bandwidth; but if this is simply an unwanted side effect of the recent changes, perhaps it's a good idea to have it at least reported. --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - 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
Fwd: Problems with ipv4 part of Kernels post-2.6.16
Sorry - reply-all got a bounce, didn't check the bad netdev address... -- Forwarded message -- From: Alessandro Suardi [EMAIL PROTECTED] Date: Sep 4, 2006 12:07 AM Subject: Re: Problems with ipv4 part of Kernels post-2.6.16 To: Willy Tarreau [EMAIL PROTECTED] Cc: Rogério Brito [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], John Heffner [EMAIL PROTECTED], David S. Miller [EMAIL PROTECTED] On 9/3/06, Willy Tarreau [EMAIL PROTECTED] wrote: Hi Rogério, On Sun, Sep 03, 2006 at 05:13:35PM -0300, Rogério Brito wrote: Hi, John, David and others developers. I have been trying to keep up with the kernel releases (not only the -rc ones, but also some -mm's) and I noticed something quite strange: with some post 2.6.16 kernels (say, 2.6.17), I can't access (from where I am) the site www.everymac.com, while I can access other sites. I believe I read on LKML last month that there's a problem on this site with window scaling. There's a patch floating around to allow per destination window clamping. I believe that you can workaround the problem by disabling TCP window scaling : echo 0 /proc/sys/net/ipv4/tcp_window_scaling Hoping this helps, Willy The above does help while hitting certain websites from behind my corporate proxy (while others are okay); same websites can be accessed without any issue from my home ISP connection. I logged an internal ticket for this, will check whether there's been any update as of recently; both happens with recent 2.6.18-rc and with FC5-latest kernel. This has made me quite curious, because just booting back with a 2.6.16.x kernel, I could access it, which, of course, led me to think this was a problem with the networking part of the kernel. Well, to cut a long story short, yesterday I decided to learn how to use git, grabbed Linus's tree and started a bisection session. After 12 recompilations, I found the following patch being the first suspect (sorry for the line wrapping, but I copied this one from one console to another, since I don't know how to generate it again with git): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [EMAIL PROTECTED]:/usr/local/media/progs/linux/kernel/linux-git$ git bisect good 7b4f4b5ebceab67ce440a61081a69f0265e17c2a is first bad commit commit 7b4f4b5ebceab67ce440a61081a69f0265e17c2a Author: John Heffner [EMAIL PROTECTED] Date: Sat Mar 25 01:34:07 2006 -0800 [TCP]: Set default max buffers from memory pool size This patch sets the maximum TCP buffer sizes (available to automatic buffer tuning, not to setsockopt) based on the TCP memory pool size. The maximum sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/128 of the memory pressure threshold. Signed-off-by: John Heffner [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] :04 04 514849b6a38c5fb671f3aeae1c0108a0e8e897dc 3b912fd10db444b22262f995fac99f2851363531 M net [EMAIL PROTECTED]:/usr/local/media/progs/linux/kernel/linux-git$ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I'm currently connected to my provider via cable modem and I'm assigned an IP address via DHCP (actually, I'm using a D-Link DI-524 router in between, but I already tested *without* the router in the middle and the problem remains). The contents of my /etc/sysctl.conf file are attached. My userspace is Debian's testing/etch, regularly upgraded every day. My system is a Duron 1.1GHz, with 512MB of RAM and a KT133 (VIA) chipset, with the network card being a Realtek RTL8139. I would like to point out that this has prevented me from using/testing other newer kernels. :-( If anything else is required, please, don't hesitate to ask. I will try my best to use any patches that may seem relevant, until we can point out what may be happening. Thanks, Rogério Brito. P.S.: Please, I'm not (currently) subscribed to any mailing list. I'd appreciate if the CCs weren't trimmed. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ # # /etc/sysctl.conf - Configuration file for setting system variables # See sysctl.conf (5) for information. # # Uncomment the following to stop low-level messages on console #kernel.printk = 4 4 1 7 ##3 # Functions previously found in netbase # #net.ipv4.conf.default.forwarding=1 #net.ipv6.conf.default.forwarding=1 dev.rtc.max-user-freq=1024 net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.all.accept_source_route=0 net.ipv4.conf.all.log_martians=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.accept_redirects=0 net.ipv4.conf.default.accept_source_route=0 net.ipv4.conf.default.log_martians=1 net.ipv4.conf.default.rp_filter=1 net.ipv4
[2.6.17-git22] lock debugging output
Hoping gmail doesn't mess it too badly...
eth0: tg3 (BCM5751 Gbit Ethernet)
eth1: ipw2200 (Intel PRO/Wireless 2200BG)
Sequence:
1. boot with eth0 disconnected (eth1 doesn't come up on boot)
2. ifup eth1, bring wpa-supplicant up
3. run 'dig' --- lock debug info gets printed on console
Note that due to my very variable network setup, I had no /etc/resolv.conf
in place at the moment I ran 'dig'. Second execution of 'dig' did not print
any lock debug output but just (properly) stalled; then I realized I didn't
put my home resolv.conf in place, did that and 'dig' just worked.
System appears to work and I'm actually typing this report from the
same kernel that reported the following upon invoking 'dig' :
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-W} - {in-softirq-R} usage.
dig/2373 [HC0[0]:SC1[2]:HE1:SE0] takes:
(sk-sk_dst_lock){---?}, at: [c028cf72] sk_dst_check+0x1b/0xe6
{softirq-on-W} state was registered at:
[c0127a6a] lock_acquire+0x60/0x80
[c02e151d] _write_lock+0x19/0x28
[c028c0af] sock_setsockopt+0x351/0x49c
[c0289d0d] sys_setsockopt+0x5b/0x8d
[c028ac22] sys_socketcall+0x148/0x186
[c0102699] sysenter_past_esp+0x56/0x8d
irq event stamp: 1130
hardirqs last enabled at (1130): [c01161ed] local_bh_enable_ip+0xb2/0xbb
hardirqs last disabled at (1129): [c011618e] local_bh_enable_ip+0x53/0xbb
softirqs last enabled at (1120): [c029423c] dev_queue_xmit+0x205/0x211
softirqs last disabled at (1121): [c01040e6] do_softirq+0x4d/0xac
other info that might help us debug this:
2 locks held by dig/2373:
#0: (sk_lock-AF_INET6){--..}, at: [f8cf1168]
udpv6_sendmsg+0x546/0x818 [ipv6]
#1: (slock-AF_INET6){-...}, at: [f8cf3228] icmpv6_send+0x222/0x549 [ipv6]
stack backtrace:
[c0102e44] show_trace+0xd/0x10
[c010335e] dump_stack+0x19/0x1b
[c01260e1] print_usage_bug+0x1cc/0x1d9
[c01265e2] mark_lock+0x193/0x360
[c01271ee] __lock_acquire+0x3b7/0x969
[c0127a6a] lock_acquire+0x60/0x80
[c02e15ff] _read_lock+0x19/0x28
[c028cf72] sk_dst_check+0x1b/0xe6
[f8ce1305] ip6_dst_lookup+0x31/0x16d [ipv6]
[f8cf3338] icmpv6_send+0x332/0x549 [ipv6]
[f8cf09a1] udpv6_rcv+0x4ab/0x4d6 [ipv6]
[f8ce2900] ip6_input+0x19c/0x228 [ipv6]
[f8ce2d61] ipv6_rcv+0x188/0x1b7 [ipv6]
[c02925b7] netif_receive_skb+0x18d/0x1d8
[c0293d6a] process_backlog+0x80/0xf9
[c0293f43] net_rx_action+0x80/0x174
[c01162fd] __do_softirq+0x46/0x9c
[c01040e6] do_softirq+0x4d/0xac
===
[c0116117] local_bh_enable+0xc8/0xec
[c029423c] dev_queue_xmit+0x205/0x211
[c0298a8b] neigh_resolve_output+0x1db/0x207
[f8ce0bee] ip6_output2+0x1e4/0x202 [ipv6]
[f8ce12aa] ip6_output+0x69e/0x6c8 [ipv6]
[f8ce1706] ip6_push_pending_frames+0x2c5/0x377 [ipv6]
[f8cefd8e] udp_v6_push_pending_frames+0x154/0x176 [ipv6]
[f8cf122a] udpv6_sendmsg+0x608/0x818 [ipv6]
[c02c6b1d] inet_sendmsg+0x3b/0x48
[c02894f9] sock_sendmsg+0xe8/0x103
[c0289b18] sys_sendmsg+0x14f/0x1aa
[c028ac45] sys_socketcall+0x16b/0x186
[c0102699] sysenter_past_esp+0x56/0x8d
Hope this may be useful to lock debug devs / netdev folks...
Ciao,
--alessandro
I can't change what makes me high and I can't change what I believe in
(Heather Nova, My Fidelity)
-
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: [2.6.16-gitX] heavy performance regression in ipw2200 wireless driver
On 3/24/06, Zhu Yi [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:02 +0100, Alessandro Suardi wrote: That scp test shows 50%ish - but that was a quickie. The VNC client even reported a 719Kbps throughput down from the more usual 11500Kbps it starts off with. The first scp I tried when the sluggishness was intolerable was going at 200KB/s - which shows the problem can easily get in the neighborhood of an order of magnitude. What kind of wireless encryption do you use? We turned off hardware encryption by default recently as a workaround for a firmware restart bug. You might want to load module with modprobe ipw2200 hwcrypto=1 and retest. The issue seems to have vanished in more recent kernel snapshots (namely, 2.6.16-git3 and -git5 exhibited the problem; -git8 and -git9 did not). I will holler if the problem pops up again... thanks, --alessandro Dreamer ? Each one of us is a dreamer. We just push it down deep because we are repeatedly told that we are not allowed to dream in real life (Reinhold Ziegler) - 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: [2.6.16-gitX] heavy performance regression in ipw2200 wireless driver
On 3/24/06, Zhu Yi [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:02 +0100, Alessandro Suardi wrote: That scp test shows 50%ish - but that was a quickie. The VNC client even reported a 719Kbps throughput down from the more usual 11500Kbps it starts off with. The first scp I tried when the sluggishness was intolerable was going at 200KB/s - which shows the problem can easily get in the neighborhood of an order of magnitude. What kind of wireless encryption do you use? We turned off hardware encryption by default recently as a workaround for a firmware restart bug. You might want to load module with modprobe ipw2200 hwcrypto=1 and retest. I actually use no encryption yet, as I still have to find out time to call D-Link about the fact that my router hangs when I try to set up a whitelist of MAC addresses for the wireless AP; WPA would be up next... Would loading the module with h/w encryption turned on make any difference in my case ? Thanks, PS don't tell my neighbors ;) --alessandro Dreamer ? Each one of us is a dreamer. We just push it down deep because we are repeatedly told that we are not allowed to dream in real life (Reinhold Ziegler) - 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: [2.6.16-gitX] heavy performance regression in ipw2200 wireless driver
On 3/23/06, Andrew Morton [EMAIL PROTECTED] wrote: Alessandro Suardi [EMAIL PROTECTED] wrote: Plze try to cc the right people. Sorry about that - should probably defer bug reporting to times when I'm actually supposed to be awake (2:20am doesn't fit the bill obviously :| ) Driver - or firmware ? Don't know - since the new git snapshots run 1.1.1 which requires newer firmware from http://ipw2200.sourceforge.net. Symptom - my new FC5 partition with 2.6.16-git kernels connects via VNC viewer to my bittorrent box over wireless (ipw2200 to a D-Link G604T router/AP); Dell D610 runs FC5, BT box is a K7-800 running FC3 with a 2.6.16-rc5-git8 kernel (15+ days uptime...). I also run Firefox on the bittorrent box; noticed today (2.6.16-git5) that the screen refresh of pages with images was from time to time very slow (close to unusable). Rebooted into my FC4 partition with a 2.6.16 kernel, everything much snappier. So I ran a scp test from my BT server to the laptop, three times in a row the same file - a 38MB .flac with the laptop in the same physical position (ie, no signal variation). Results... FC5 - 2.6.16-git3: [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 971.3KB/s 00:40 [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 1.3MB/s 00:29 [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 626.7KB/s 01:02 FC4 - 2.6.16: [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 1.5MB/s 00:25 [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 1.7MB/s 00:23 [EMAIL PROTECTED] melua_2004-09-23_Berlin]$ scp KM_9-23-04_17_The\ Closest\ Thing\ to\ Crazy.flac 192.168.1.8:/tmp [EMAIL PROTECTED]'s password: KM_9-23-04_17_The Closest Thing to Crazy.flac 100% 38MB 1.7MB/s 00:22 Bottom line - old driver has better performance than the new one, but most noticeably delivers consistent performance. I will be available for testing starting Thursday 30th as I'll be on the road since then. Of course if the problem is identified and fixed earlier, I won't cry ;) Well. It's not a huge regression. It's a 50%ish regression. We've done worse ;) That scp test shows 50%ish - but that was a quickie. The VNC client even reported a 719Kbps throughput down from the more usual 11500Kbps it starts off with. The first scp I tried when the sluggishness was intolerable was going at 200KB/s - which shows the problem can easily get in the neighborhood of an order of magnitude. Thanks, --alessandro Dreamer ? Each one of us is a dreamer. We just push it down deep because we are repeatedly told that we are not allowed to dream in real life (Reinhold Ziegler) - 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
