[PATCH] Accept -1 for IPV6_TCLASS
Hello, This patch should add support for -1 as default IPv6 traffic class, as specified in IETF RFC3542 §6.5. Within the kernel, it seems tclass 0 is already handled, but setsockopt, getsockopt and recvmsg calls won't accept it from userland. Signed-off-by: Remi Denis-Courmont [EMAIL PROTECTED] diff -Nru linux-2.6.18-rc5-git6.orig/net/ipv6/datagram.c linux-2.6.18-rc5-git6/net/ipv6/datagram.c --- linux-2.6.18-rc5-git6.orig/net/ipv6/datagram.c 2006-03-20 07:53:29.0 +0200 +++ linux-2.6.18-rc5-git6/net/ipv6/datagram.c 2006-09-03 09:42:03.0 +0300 @@ -696,7 +696,7 @@ } tc = *(int *)CMSG_DATA(cmsg); - if (tc 0 || tc 0xff) + if (tc -1 || tc 0xff) goto exit_f; err = 0; diff -Nru linux-2.6.18-rc5-git6.orig/net/ipv6/ipv6_sockglue.c linux-2.6.18-rc5-git6/net/ipv6/ipv6_sockglue.c --- linux-2.6.18-rc5-git6.orig/net/ipv6/ipv6_sockglue.c 2006-09-03 09:47:10.0 +0300 +++ linux-2.6.18-rc5-git6/net/ipv6/ipv6_sockglue.c 2006-09-03 09:41:31.0 +0300 @@ -362,7 +362,7 @@ break; case IPV6_TCLASS: - if (val 0 || val 0xff) + if (val -1 || val 0xff) goto e_inval; np-tclass = val; retv = 0; @@ -947,6 +947,8 @@ case IPV6_TCLASS: val = np-tclass; + if (val 0) + val = 0; break; case IPV6_RECVTCLASS: -- Rémi Denis-Courmont http://www.remlab.net/ -- VGER BF report: U 0.93636 - 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.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Francois Romieu [EMAIL PROTECTED] writes: dev_activate takes BH disabling locks only. How could a softirq happen on the same cpu and trigger a deadlock ? That's BTW possible circular locking dependency and there is only one CPU (no HT, single core - an old mobile Celeron P3). I have to admit this machine has a history of mysterious hangs (black screen of death), though I think they are related to LAN and maybe disk activity, not GRE/PPP/ATM/ADSL (RAM tests ok, the hardware is rather common - i440BX etc. but who knows). -- Krzysztof Halasa -- VGER BF report: S 0.999877 - 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: Loop detected - calling function from different modules
hi Stephen, you can check these: http://bcm43xx.berlios.de/ http://madwifi.org/ R /frank From: Stephen Hemminger [EMAIL PROTECTED] To: Frank Schneider [EMAIL PROTECTED] CC: netdev@vger.kernel.org Subject: Re: Loop detected - calling function from different modules Date: Wed, 30 Aug 2006 14:26:07 -0700 On Wed, 30 Aug 2006 22:58:17 +0200 Frank Schneider [EMAIL PROTECTED] wrote: hi all, I am writing/customizing a network(wlan pc card) device driver for Linux kernel 2.6.12 Think about I have two modules e.g. ath_pci and wlan module. I can call a function from a .c file which is implemented in a .c file in wlan module by using EXPORT_SYMBOL macro.. and i need to do same in reverse way, i.e. call a function from wlan module that is implemented in ath_pci module. I did the same way and its making but when I do make install its showing following error: WARNING: Loop detected: /lib/modules/2.6.12/net/ath_pci.ko needs wlan.ko which needs ath_pci.ko again! Please anybody tell how can I do this, any clue , please ? thanx in advance n.b. this question may consider as very naive since I am not good yet in kernel hacking.. regards, /Frank Where are these open source drivers so the wireless developers can help? -- Stephen Hemminger [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- VGER BF report: U 0.864812 - 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.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
[NET]: Drop tx lock in dev_watchdog_up
On Sat, Sep 02, 2006 at 08:39:28PM +, Krzysztof Halasa wrote:
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(dev-queue_lock){-+..}, at: [c02c8c46] dev_queue_xmit+0x56/0x290
but task is already holding lock:
(dev-_xmit_lock){-+..}, at: [c02c8e14] dev_queue_xmit+0x224/0x290
which lock already depends on the new lock.
This turns out to be a genuine bug. The queue lock and xmit lock are
intentionally taken out of order. Two things are supposed to prevent
dead-locks from occuring:
1) When we hold the queue_lock we're supposed to only do try_lock on the
tx_lock.
2) We always drop the queue_lock after taking the tx_lock and before doing
anything else.
the existing dependency chain (in reverse order) is:
- #1 (dev-_xmit_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c0336241] _spin_lock_bh+0x31/0x40
[c02d25a9] dev_activate+0x69/0x120
This path obviously breaks assumption 1) and therefore can lead to ABBA
dead-locks.
I've looked at the history and there seems to be no reason for the lock
to be held at all in dev_watchdog_up. The lock appeared in day one and
even there it was unnecessary. In fact, people added __dev_watchdog_up
precisely in order to get around the tx lock there.
The function dev_watchdog_up is already serialised by rtnl_lock since
its only caller dev_activate is always called under it.
So here is a simple patch to remove the tx lock from dev_watchdog_up.
In 2.6.19 we can eliminate the unnecessary __dev_watchdog_up and
replace it with dev_watchdog_up.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 0834c2e..6f91518 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -238,9 +238,7 @@ void __netdev_watchdog_up(struct net_dev
static void dev_watchdog_up(struct net_device *dev)
{
- netif_tx_lock_bh(dev);
__netdev_watchdog_up(dev);
- netif_tx_unlock_bh(dev);
}
static void dev_watchdog_down(struct net_device *dev)
--
VGER BF report: U 0.5
-
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: neigh_lookup lockdep warning
On Sun, Sep 03, 2006 at 01:26:59AM +, Dave Jones wrote:
Seen during boot of a 2.6.18rc5-git1 based kernel.
===
[ INFO: possible circular locking dependency detected ]
2.6.17-1.2608.fc6 #1
---
swapper/0 is trying to acquire lock:
(tbl-lock){-+-+}, at: [c05bdf97] neigh_lookup+0x50/0xaf
but task is already holding lock:
(list-lock#3){-+..}, at: [c05bf677] neigh_proxy_process+0x20/0xc2
Looks like a validator bug. Arjan, it seems that the removal of the
lockdep_set_class from skb_queue_head_init doesn't completely cure
the problem.
the existing dependency chain (in reverse order) is:
- #2 (list-lock#3){-+..}:
[c043c09a] lock_acquire+0x4b/0x6d
[c061411f] _spin_lock_irqsave+0x22/0x32
[c05b451f] skb_dequeue+0x12/0x43
[c05b523a] skb_queue_purge+0x14/0x1b
[c05be990] neigh_update+0x34a/0x3a6
This list-lock is n-arp_queue.
[c05f0f6e] arp_process+0x4ad/0x4e7
[c05f107c] arp_rcv+0xd4/0xf1
[c05b942c] netif_receive_skb+0x205/0x274
[c7bb0566] rhine_napipoll+0x28d/0x449 [via_rhine]
[c05baf73] net_rx_action+0x9d/0x196
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
...
- #0 (tbl-lock){-+-+}:
[c043c09a] lock_acquire+0x4b/0x6d
[c0613f02] _read_lock_bh+0x1e/0x2d
[c05bdf97] neigh_lookup+0x50/0xaf
[c05bf0b9] neigh_event_ns+0x2c/0x77
[c05f0e2a] arp_process+0x369/0x4e7
[c05f10a1] parp_redo+0x8/0xa
[c05bf6bd] neigh_proxy_process+0x66/0xc2
This list-lock is tbl-proxy_queue.
[c042dc58] run_timer_softirq+0x108/0x167
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
BTW, out of the last four validator reports I've read three have turned
out to be genuine bugs. So you guys have done a fantastic job!
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
VGER BF report: U 0.5
-
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: [GENL]: Provide more information to userspace about registered genl families
jamal wrote: Could you point me to it? I can look at it over the weekend. I posted it here on netdev, look for nl80211. It may be we need to add another feature to genl to accomodate this. Example by setting a flag to indicate supportability. However, it does sound like this is something your code needs to own in a capability set structure somewhere. I cant tell without looking at the code. Yes, I'm currently exporting it myself. johannes -- VGER BF report: U 0.534475 - 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.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Herbert Xu [EMAIL PROTECTED] writes:
[NET]: Drop tx lock in dev_watchdog_up
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -238,9 +238,7 @@ void __netdev_watchdog_up(struct net_dev
static void dev_watchdog_up(struct net_device *dev)
{
- netif_tx_lock_bh(dev);
__netdev_watchdog_up(dev);
- netif_tx_unlock_bh(dev);
}
static void dev_watchdog_down(struct net_device *dev)
Many thanks for looking into this. The lockdep warning is gone now.
--
Krzysztof Halasa
--
VGER BF report: H 3.43998e-11
-
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: [PATCH] Accept -1 for IPV6_TCLASS
In article [EMAIL PROTECTED] (at Sun, 3 Sep 2006 10:28:30 +0300), Rémi Denis-Courmont [EMAIL PROTECTED] says: This patch should add support for -1 as default IPv6 traffic class, as specified in IETF RFC3542 §6.5. Within the kernel, it seems tclass 0 is already handled, but setsockopt, getsockopt and recvmsg calls won't accept it from userland. Signed-off-by: Remi Denis-Courmont [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji -- VGER BF report: S 1 - 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: BUG in bcm32xx-d80211: sleeping function called with irq's disabled
Michael Buesch wrote: John, please apply the following patch to wireless-dev. (And please apply all the other patches, too, as I'm still waiting to pull ;) ) -- Don't disable IRQs in PHY init. Signed-off-by: Michael Buesch [EMAIL PROTECTED] The patch fixes the problem on my machine. Should I add my name to the signed-off-by list? Larry -- VGER BF report: U 0.499941 - 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: e1000 Detected Tx Unit Hang
On 9/2/06, Paul Aviles [EMAIL PROTECTED] wrote: I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a large ftp transfer to the server. It does not happen if the server is connected to a dummy 100 Mb switch, only when is connected to the Gig switch. I have also tried the options line below disabling tso, tx and rx in the modprobe.conf without any luck. Hi Paul, sorry to hear about your problem. You're getting hangs on the 82547 right? can you send the output of cat /proc/interrupts. I'm curious if you are sharing interrupts while running NAPI. Also, please try the driver without CONFIG_E1000_NAPI enabled in your kernel .config, and let us know the results. Someone has posted (what they think is) a theoretical problem with irq_sem on the 82547 at e1000.sf.net and I haven't had a chance to figure it out yet. Jesse -- VGER BF report: U 0.495355 - 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: [RFC PATCH] EtherIP tunnel driver (RFC 3387)
On Fri, Sep 01, 2006 at 06:24:56PM +0200, Patrick McHardy wrote:
Hello Patrick,
Thank you very much for reviewing my driver. I will fix the issues you
mentioned. But I have some explanations and questions left.
Joerg Roedel wrote:
+ fl.oif = 0;
+ fl.nl_u.ip4_u.daddr = tunnel-parms.iph.daddr;
+ fl.nl_u.ip4_u.saddr = tunnel-parms.iph.saddr;
+ fl.nl_u.ip4_u.saddr = 0;
+ fl.proto = IPPROTO_ETHERIP;
This leaves fields like nfmark or iif uninitialized.
I changed the code to initialize iif to 0, but I am not sure how to
initialize the fwmark field. Neigther the ipip driver nor the sit driver
initialize this field. Is it right to initialize it to 0?
+ goto accept;
+
+ if ((skb-pkt_type == PACKET_OTHERHOST) (dev-flags IFF_PROMISC))
+ goto accept;
Why would you want to receive packets for other hosts picked up in
promiscous mode?
This is because the device should be usable in a bridge to build a
distributed layer 2 network. Furthermore, this could be usefull when I
extend the driver to support multicast destinations.
+static void etherip_err(struct sk_buff *skb, u32 info)
+{
You could propagte errors from destination unreachable messages
similar to what the IPIP driver does.
I am not sure that this makes sense here. The IPIP driver handles
ICMP_FRAG_NEEDED messages. But I think those messages will never be
received by the EtherIP driver because it never sets the DF flag in the
outgoing packets (to ensure the Ethernet MTU for protocols besides IP
and IPv6). I added a comment about this issue to the etherip_tunnel_xmit
function.
This were my questions and explanations. Thanks again for reviewing, I
will submit a new patch as soon as the questions have been discussed and
the changes are tested.
Greets,
Joerg Roedel
--
VGER BF report: U 0.5001
-
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: Possible circular locking in current wireless-dev.git
Larry Finger [EMAIL PROTECTED] :
When booting the latest version of Linville's wireless-dev
and starting my BCM4306 with WPA-PSK TKIP, the I get the
following INFO printout that indicates a possible circular locking dependency
involving 80211 and wpa_supplicant.
Please try the patch below that Xerbert Xu sent a few hours
ago on l-k and netdev:
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 0834c2e..6f91518 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -238,9 +238,7 @@ void __netdev_watchdog_up(struct net_dev
static void dev_watchdog_up(struct net_device *dev)
{
- netif_tx_lock_bh(dev);
__netdev_watchdog_up(dev);
- netif_tx_unlock_bh(dev);
}
static void dev_watchdog_down(struct net_device *dev)
--
--
VGER BF report: U 0.50127
-
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.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Herbert Xu wrote:
[NET]: Drop tx lock in dev_watchdog_up
On Sat, Sep 02, 2006 at 08:39:28PM +, Krzysztof Halasa wrote:
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(dev-queue_lock){-+..}, at: [c02c8c46] dev_queue_xmit+0x56/0x290
but task is already holding lock:
(dev-_xmit_lock){-+..}, at: [c02c8e14] dev_queue_xmit+0x224/0x290
which lock already depends on the new lock.
This turns out to be a genuine bug. The queue lock and xmit lock are
intentionally taken out of order. Two things are supposed to prevent
dead-locks from occuring:
1) When we hold the queue_lock we're supposed to only do try_lock on the
tx_lock.
2) We always drop the queue_lock after taking the tx_lock and before doing
anything else.
the existing dependency chain (in reverse order) is:
- #1 (dev-_xmit_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c0336241] _spin_lock_bh+0x31/0x40
[c02d25a9] dev_activate+0x69/0x120
This path obviously breaks assumption 1) and therefore can lead to ABBA
dead-locks.
I've looked at the history and there seems to be no reason for the lock
to be held at all in dev_watchdog_up. The lock appeared in day one and
even there it was unnecessary. In fact, people added __dev_watchdog_up
precisely in order to get around the tx lock there.
The function dev_watchdog_up is already serialised by rtnl_lock since
its only caller dev_activate is always called under it.
So here is a simple patch to remove the tx lock from dev_watchdog_up.
In 2.6.19 we can eliminate the unnecessary __dev_watchdog_up and
replace it with dev_watchdog_up.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
This patch also fixes a circular locking problem that I found on Linville's
wireless-dev tree
involving ieee80211 and wpa_supplicant.
Larry Finger
--
VGER BF report: H 1.06514e-06
-
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: Possible circular locking in current wireless-dev.git
Francois Romieu wrote: Larry Finger [EMAIL PROTECTED] : When booting the latest version of Linville's wireless-dev and starting my BCM4306 with WPA-PSK TKIP, the I get the following INFO printout that indicates a possible circular locking dependency involving 80211 and wpa_supplicant. Please try the patch below that Xerbert Xu sent a few hours ago on l-k and netdev: Jamal [EMAIL PROTECTED] also suggested that patch, which does the trick. Thanks, Larry -- VGER BF report: U 0.530972 - 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
Re: [RFC PATCH] EtherIP tunnel driver (RFC 3387)
Joerg Roedel wrote:
On Fri, Sep 01, 2006 at 06:24:56PM +0200, Patrick McHardy wrote:
+fl.oif = 0;
+fl.nl_u.ip4_u.daddr = tunnel-parms.iph.daddr;
+fl.nl_u.ip4_u.saddr = tunnel-parms.iph.saddr;
+fl.nl_u.ip4_u.saddr = 0;
+fl.proto = IPPROTO_ETHERIP;
This leaves fields like nfmark or iif uninitialized.
I changed the code to initialize iif to 0, but I am not sure how to
initialize the fwmark field. Neigther the ipip driver nor the sit driver
initialize this field. Is it right to initialize it to 0?
They both initialize the entire structure at once, which sets members
not explicitly initialized to zero.
+goto accept;
+
+if ((skb-pkt_type == PACKET_OTHERHOST) (dev-flags IFF_PROMISC))
+goto accept;
Why would you want to receive packets for other hosts picked up in
promiscous mode?
This is because the device should be usable in a bridge to build a
distributed layer 2 network. Furthermore, this could be usefull when I
extend the driver to support multicast destinations.
Yes, I totally misunderstood the intention.
+static void etherip_err(struct sk_buff *skb, u32 info)
+{
You could propagte errors from destination unreachable messages
similar to what the IPIP driver does.
I am not sure that this makes sense here. The IPIP driver handles
ICMP_FRAG_NEEDED messages. But I think those messages will never be
received by the EtherIP driver because it never sets the DF flag in the
outgoing packets (to ensure the Ethernet MTU for protocols besides IP
and IPv6). I added a comment about this issue to the etherip_tunnel_xmit
function.
Thanks for the explanation, I didn't notice that it doesn't set DF.
--
VGER BF report: U 0.505164
-
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: tg3: tg3_stop_block timed out
Philip Molter wrote: Michael Chan wrote: On Tue, 2006-08-08 at 01:24 +0200, Bernd Schubert wrote: tg3.c:v3.49 (Feb 2, 2006) acpi_bus-0201 [01] bus_set_power : Device is not power manageable eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:28 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] eth1: dma_rwctrl[769f4000] dma_mask[64-bit] eth2: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:29 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth2: dma_rwctrl[769f4000] dma_mask[64-bit] You have ASF enabled on eth1 but not on eth2 so I wonder if ASF is causing the problem. Can you run the same traffic on eth2 and see if you get the same timeout problem? Thanks. I'm also having this same problem: Is there any additional information that I can give to help get some more work targeted at this bug? I've been getting this lockup three or four times a week per server (I have four of them exhibiting this behavior). The network setup is fairly complicated, but unfortunately, these are production machines pushing multi-gigabit traffic loads. We're using vlans on top of bonding on top of anywhere from 2-to-6 broadcomm NICs, but it appears that the problem is unrelated to the bonding and vlans, as others are reporting similar problems without those enabled. Any assistance would be appreciated. I've left the original information below for reference. If anyone could even explain what this error means, that would be helpful. Maybe we can change something to work around it. Philip divert: allocating divert_blk for bond0 tg3.c:v3.14 (November 15, 2004) divert: allocating divert_blk for eth0 eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2e:82:1a eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] divert: allocating divert_blk for eth1 eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2e:82:1b eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] divert: freeing divert_blk for bond0 divert: freeing divert_blk for eth0 divert: freeing divert_blk for eth1 02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03) Subsystem: Broadcom Corporation: Unknown device 1644 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 161 Memory at fc8c (64-bit, non-prefetchable) [size=fc8a] Memory at fc8b (64-bit, non-prefetchable) [size=64K] Expansion ROM at 0001 [disabled] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03) Subsystem: Broadcom Corporation: Unknown device 1644 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 169 Memory at fc8f (64-bit, non-prefetchable) [size=fc8d] Memory at fc8e (64-bit, non-prefetchable) [size=64K] Expansion ROM at 0001 [disabled] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- I run these things with jumbo frames and bonding. In the case last night, our machine completely locked up because both interfaces stopped working and the channel bond between them went down. These guys are pushing a little over 1Gb/s total traffic between them (500Mb/s each) and one of them will take in about 300Mb/s. Outgoing packets average 20kpkts/s and incoming packets on the one interface average about 45kpkts/s (most incoming traffic is not jumbo). This was on console: tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth0: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth0: transmit timed
Re: [patch 3/4] Make sure ip_vs_ftp ports are valid
Horms wrote:
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:06:42.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0
+0900
@@ -373,6 +373,12 @@
for (i=0; iIP_VS_APP_MAX_PORTS; i++) {
if (!ports[i])
continue;
+ if (ports[i] 0 || ports[i] 0x) {
+ IP_VS_WARNING(ip_vs_ftp: Ignoring invalid
+ configuration port[%d] = %d\n,
+ i, ports[i]);
+ continue;
+ }
How about just changing the module parameter type to ushort, similar to
what ip_conntrack_ftp does?
# modprobe ip_conntrack_ftp ports=999392
ip_conntrack_ftp: `999392' invalid for parameter `ports'
--
VGER BF report: H 0.41558
-
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: e1000 Detected Tx Unit Hang
Hey Jesse, thanks for your reply. Here is the stuff on /procs. The weird part is that I have several other identical systems and only one is affected. Today I moved the hard drive to another similar system and I am not seeing the problem so I am wondering if is something maybe wrong with the card eeprom? Is there a way to check that? Regards, Paul cat /proc/interrupts CPU0 CPU1 0:7716253 0IO-APIC-edge timer 3: 11538 0IO-APIC-edge serial 8: 1 0IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 14: 93406 0IO-APIC-edge ide0 16: 70540 0 IO-APIC-level uhci_hcd:usb4, eth0 17: 2 0 IO-APIC-level ehci_hcd:usb1 18: 0 0 IO-APIC-level uhci_hcd:usb2, uhci_hcd:usb5 19: 90 0 IO-APIC-level uhci_hcd:usb3 NMI: 0 0 LOC:77158397715838 ERR: 0 MIS: 0 - Original Message - From: Jesse Brandeburg [EMAIL PROTECTED] To: Paul Aviles [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Sent: Sunday, September 03, 2006 1:45 PM Subject: Re: e1000 Detected Tx Unit Hang On 9/2/06, Paul Aviles [EMAIL PROTECTED] wrote: I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a large ftp transfer to the server. It does not happen if the server is connected to a dummy 100 Mb switch, only when is connected to the Gig switch. I have also tried the options line below disabling tso, tx and rx in the modprobe.conf without any luck. Hi Paul, sorry to hear about your problem. You're getting hangs on the 82547 right? can you send the output of cat /proc/interrupts. I'm curious if you are sharing interrupts while running NAPI. Also, please try the driver without CONFIG_E1000_NAPI enabled in your kernel .config, and let us know the results. Someone has posted (what they think is) a theoretical problem with irq_sem on the 82547 at e1000.sf.net and I haven't had a chance to figure it out yet. Jesse -- VGER BF report: U 0.495355 - 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 -- VGER BF report: U 0.516297 - 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: [patch 3/4] Make sure ip_vs_ftp ports are valid
On Mon, Sep 04, 2006 at 01:09:59AM +0200, Patrick McHardy wrote:
Horms wrote:
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01
19:06:42.0 +0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0
+0900
@@ -373,6 +373,12 @@
for (i=0; iIP_VS_APP_MAX_PORTS; i++) {
if (!ports[i])
continue;
+ if (ports[i] 0 || ports[i] 0x) {
+ IP_VS_WARNING(ip_vs_ftp: Ignoring invalid
+ configuration port[%d] = %d\n,
+ i, ports[i]);
+ continue;
+ }
How about just changing the module parameter type to ushort, similar to
what ip_conntrack_ftp does?
Sure. I wasn't sure if that was possible or not.
But as it is, I will make it so.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
--
VGER BF report: U 0.575956
-
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: [patch 3/4] Make sure ip_vs_ftp ports are valid
On Mon, Sep 04, 2006 at 09:44:02AM +0900, Horms wrote:
On Mon, Sep 04, 2006 at 01:09:59AM +0200, Patrick McHardy wrote:
Horms wrote:
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01
19:06:42.0 +0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0
+0900
@@ -373,6 +373,12 @@
for (i=0; iIP_VS_APP_MAX_PORTS; i++) {
if (!ports[i])
continue;
+ if (ports[i] 0 || ports[i] 0x) {
+ IP_VS_WARNING(ip_vs_ftp: Ignoring invalid
+ configuration port[%d] = %d\n,
+ i, ports[i]);
+ continue;
+ }
How about just changing the module parameter type to ushort, similar to
what ip_conntrack_ftp does?
Sure. I wasn't sure if that was possible or not.
But as it is, I will make it so.
Here is the revised patch.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[IPVS] Make sure ip_vs_ftp ports are valid
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ensures that
the port values are unsigned short values, and thus always valid.
Cc: Patrick McHardy [EMAIL PROTECTED]
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-04 10:47:09.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-04 10:59:30.0 +0900
@@ -44,8 +44,8 @@
* List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper
* First port is set to the default port.
*/
-static int ports[IP_VS_APP_MAX_PORTS] = {21, 0};
-module_param_array(ports, int, NULL, 0);
+static unsigned short ports[IP_VS_APP_MAX_PORTS] = {21, 0};
+module_param_array(ports, ushort, NULL, 0);
MODULE_PARM_DESC(ports, Ports to monitor for FTP control commands);
/*
--
VGER BF report: U 0.832414
-
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
[PATCH] remove dead code from bcm43xx-softmac
John, Please queue the following patch for wireless-2.6. It removes some code that was made obsolete by the wireless statistics changes of several weeks ago, but was not noticed them. Thanks, Larry = This patch removes code that was make obsolete when the wireless statistics in bcm43xx-softmac were changed, but was overlooked at that time. The value of bcm-stats.link_quality computed here is never used. Signed-off-by: Larry Finger [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c === --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -1549,17 +1549,7 @@ static void handle_irq_noise(struct bcm4 else average -= 48; -/* FIXME: This is wrong, but people want fancy stats. well... */ -bcm-stats.noise = average; - if (average -65) - bcm-stats.link_quality = 0; - else if (average -75) - bcm-stats.link_quality = 1; - else if (average -85) - bcm-stats.link_quality = 2; - else - bcm-stats.link_quality = 3; -// dprintk(KERN_INFO PFX Link Quality: %u (avg was %d)\n, bcm-stats.link_quality, average); + bcm-stats.noise = average; drop_calculation: bcm-noisecalc.calculation_running = 0; return; -- VGER BF report: U 0.500141 - 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
sky2 problem on powerpc
Hi Stephen !
To try to validate some PCIe code we have around, I got myself a
SysKonnect SK-9Exx card (one x1 lane one port and one x4 lanes 2 ports
actually, though I've only tested the first one at this point, based on
a 88E8061 Marvell chip).
I've used the sky2 driver as of a random last week's git snapshot. I'll
double check tomorrow if there have been any update.
So far, I had no success on a couple of different machines, and I was
wondering if you had an idea of what's wrong. Here's what I've seen far:
- Card is probed fine
sky2 v1.5 addr 0xa000 irq 63 Yukon-XL (0xb3) rev 1
sky2 eth2: addr 00:00:5a:72:4c:2a
- As soon as I ifconfig it up, I get a steady stream of
sky2 eth2: receive descriptor error (hardware problem)
sky2 eth2: Link is down.
mesages in my kernel log, which makes me think that it's unhappy about
the format of the descriptors or something like that (endian issue ? see
below my notes about that). I'm also wondering why it seems to be
flooding me which makes me think the error condition is never cleared on
the chip.
Some of the things I've noticed and tweaked in the driver, without luck
so far:
- There is that bit when initializing the chip:
#ifdef __BIG_ENDIAN
/* byte swap descriptors in hardware */
{
u32 reg;
.../...
However, if you look at some of the routines filling up descriptors,
they still do swap the values put into some of the fields like lenght,
address. (Except an incosistency with rx_set_checksum which doesn't swap
whatever it writes to le-addr, though I've tried fixing that without
much success).
Thus I don't quite understand what the above is supposed to do. I've
tried disabling it but it didn't fix the problem. However, that leads me
to wondering wether there might be a deeper problem with descriptor
swapping. What kind of access size and what kind of swapping the chip is
supposedly doing ? 32 bits accesses ? 64 bits accesses ?
Because if you look at the definition for:
struct sky2_rx_le {
__le32 addr;
__le16 length;
u8 ctrl;
u8 opcode;
} __attribute((packed));
(As an example)
If the chips does LE accesses, then marking lenght as being an LE
value isn't enough. It also needs to be swapped with ctrl and opcode.
The layout then becomes:
struct sky2_rx_le {
__le32 addr;
u8 opcode;
u8 ctrl;
__le16 length;
} __attribute((packed));
Unless the chip does 2x16 bits accesses here but I very much doubt it.
Now, it's possible that this bit about byteswapping descriptor is
about doing that address munging, but would it do it without also
byteswapping the content of the individual fields ? That looks
unlikely... Thus I wonder wether we should either keep this HW byteswap
option _and_ remove all the byteswapping of fields when accessing addr
and lenght, or leave the byteswapping in, remove the HW byteswap option
_and_ fixup the structure definitions of the descriptor in the big
endian case
I haven't had time to try all those options yet, and I don't have access
to any documentation for that chip, but I wondered if, in the meantime,
you had any other idea about what may be going wrong or see any flaw in
my reasoning above.
Cheers,
Ben.
--
VGER BF report: U 0.505334
-
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
