Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
On Tue, Oct 03, 2006 at 03:49:35PM +1000, Herbert Xu wrote:
OK, I think I've got the right bug this time.
Here is the patch for the other bug that I found along the way:
[UDP6]: Fix MSG_PROBE crash
UDP tracks corking status through the pending variable. The
IP layer also tracks it through the socket write queue. It
is possible for the two to get out of sync when MSG_PROBE is
used.
This patch changes UDP to check the write queue to ensure
that the two stay in sync.
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/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -675,6 +675,8 @@ do_append_data:
udp_flush_pending_frames(sk);
else if (!corkreq)
err = udp_push_pending_frames(sk, up);
+ else if (unlikely(skb_queue_empty(sk-sk_write_queue)))
+ up-pending = 0;
release_sock(sk);
out:
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -770,6 +770,8 @@ do_append_data:
udp_v6_flush_pending_frames(sk);
else if (!corkreq)
err = udp_v6_push_pending_frames(sk, up);
+ else if (unlikely(skb_queue_empty(sk-sk_write_queue)))
+ up-pending = 0;
if (dst) {
if (connected) {
-
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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Mon, Oct 02, 2006 at 04:49:38PM +0300, Ismail Donmez wrote:
02 Eki 2006 Pts 13:24 tarihinde, Jarek Poplawski şunlar?? yazm??şt??:
On 30-09-2006 21:23, Ismail Donmez wrote:
Hi,
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns false when the node is empty as expected.
...
- if (!RB_EMPTY_NODE(rb)) {
+ if (RB_EMPTY_NODE(rb)) {
Maybe you have some kind of agreement with Jens Axboe but I
can't understand current way of kernel cooperation:
he changes some global behavior to the opposite and fixes
his code in three places but can't fix it in the fourth place
where it's used? Isn't it both trivial and automatic kind
of patch?
I don't know if Jens will going to fix other occurrences but the sch_htb.c
fix
was recent and Jens' commit got my attention hence the patch.
As a matter of fact this kind of cooperation has also many pluses:
developers have to be more vigilant, read about other's work,
more people are engaged and last but not least there is this
infallible akpm reminding subsystem...
Best regards,
Jarek P.
-
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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Mon, Oct 02 2006, Jarek Poplawski wrote:
On Mon, Oct 02, 2006 at 12:24:47PM +0200, Jarek Poplawski wrote:
On 30-09-2006 21:23, Ismail Donmez wrote:
Hi,
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns false when the node is empty as expected.
...
- if (!RB_EMPTY_NODE(rb)) {
+ if (RB_EMPTY_NODE(rb)) {
Maybe you have some kind of agreement with Jens Axboe but I
can't understand current way of kernel cooperation:
he changes some global behavior to the opposite and fixes
his code in three places but can't fix it in the fourth place
...
But I see it's not so bad and net_sched isn't the last!
It looks deadline-iosched.c and one place in as-iosched.c
(~ 466 line) where probably also forgotten.
I don't see any missed changes.
Another question - is there any change planned?
If not why in rbtree.c is:
+ if (rb_parent(node) == node)
instead of:
+ if (RB_EMPTY_NODE(rb))
RB_EMPTY_NODE was (re)-introduced after that change, and it never
propagated. Changing it now would be fine and easier to read.
--
Jens Axboe
-
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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Mon, Oct 02 2006, Ismail Donmez wrote:
02 Eki 2006 Pts 13:24 tarihinde, Jarek Poplawski ??unlar?? yazmt??:
On 30-09-2006 21:23, Ismail Donmez wrote:
Hi,
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns false when the node is empty as expected.
...
- if (!RB_EMPTY_NODE(rb)) {
+ if (RB_EMPTY_NODE(rb)) {
Maybe you have some kind of agreement with Jens Axboe but I
can't understand current way of kernel cooperation:
he changes some global behavior to the opposite and fixes
his code in three places but can't fix it in the fourth place
where it's used? Isn't it both trivial and automatic kind
of patch?
I don't know if Jens will going to fix other occurrences but the
sch_htb.c fix was recent and Jens' commit got my attention hence the
patch.
Send me a patch and I'll review / integrate it. Most of the rbtree
mixups stem from the fact that the first color change was incomplete.
--
Jens Axboe
-
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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Tue, Oct 03, 2006 at 12:28:32PM +0200, Jens Axboe wrote: ... I don't see any missed changes. And you are right! I've checked the link from the first message of this thread and now I see it's not current enough. I'm sorry for this false alarm. Jarek P. - 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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns true when the node is empty as expected.
Hence Patrick McHardy's fix for sched_htb.c should be reverted.
Signed-off-by: Ismail Donmez [EMAIL PROTECTED]
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 6c058e3..1f1360e 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -391,7 +391,7 @@ static inline void htb_add_class_to_row(
/* If this triggers, it is a bug in this code, but it need not be fatal */
static void htb_safe_rb_erase(struct rb_node *rb, struct rb_root *root)
{
- if (!RB_EMPTY_NODE(rb)) {
+ if (RB_EMPTY_NODE(rb)) {
WARN_ON(1);
} else {
rb_erase(rb, root);
Re: [RFC][PATCH 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices
Jay Vosburgh wrote: Or Gerlitz [EMAIL PROTECTED] wrote: On 9/26/06, Jay Vosburgh [EMAIL PROTECTED] wrote: Or Gerlitz [EMAIL PROTECTED] wrote: [...] + bond-dev-mtu = new_active-dev-mtu; This won't generate a NETDEV_CHANGEMTU notifier event. What is actually the trigger for the event with the current impl? is the code that actually calls dev_set_mtu() on the bonding device or dev_set_mtu() itself? My comment wasn't quite totally thought out; pretend you didn't see it. I think what would be better overall is to handle the mtu for this case the way bonding handles the mtu for other slave devices. Normally, the mtu is pushed to the slaves from the bonding master, not the other way around. So, you don't want to assign the master's mtu here; the slave mtu should already be up to date (and set to whatever the master's mtu is via the usual mechanism, bond_change_mtu for changes, or set in the slave at enslavement time). OK, i think i got you. Today the dev_set_mtu() is called on the slave device only when someone attempts to change the bond MTU. So you suggest to do it also during enslavement so the current master MTU would be propagated to the slaves and not vise versa, this makes sense. [...] So at the bottom line, i would go on enhancing my patch not to allow bonding together devices of different types or at least if you don't mind, not to allow putting ARPHRD_INFINIBAND with non-ARPHRD_INFINIBAND devices in the same bond. I think this (disallowing bonding of dissimilar ARPHRD types) is the way to go, at least in the short term. Get it to work for the common case first, then deal with the fringe stuff later. OK, as you are fine with it, i will modify the patch to disallow bonding of dissimilar ARPHRD types. Or. - 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 3/3] enable IP multicast when bonding IPoIB devices
Jay Vosburgh wrote: Or Gerlitz [EMAIL PROTECTED] wrote: On 9/27/06, Jay Vosburgh [EMAIL PROTECTED] wrote: Or Gerlitz [EMAIL PROTECTED] wrote: [...] You almost want to have some kind of call to induce a reload from scratch of the multicast filter settings (along with whatever else might be necessary to alter the hardware type on the fly), to be called by bonding at the time the first slave is added (since slave adds happen in user context, and can therefore hold rtnl as required by most of the multicast address handling code). That seems less hassle than having to specify the hardware type and address length at module load time. I agree that it would be better to avoid doing it this way. Actually, it would be ideal to do it this way in all cases, as the change of hardware type is the biggest hurdle to cross-hardware bonding instances. The current infrastructure simply won't allow it, though, since bonding failover events usually occur in a timer context (if memory serves, timers run in softirq and can't acquire rtnl). Sorry, but I don't follow... by saying would be ideal to do ***it*** this way in all cases what exactly is the it you are referring to? [...] Other random thoughts on how to resolve this include modifying bonding to accept slaves when the master is down (which would also require changes to the initscripts that normally configure bonding), so that the initial setting of the, e.g., 224.0.0.1 multicast hardware address happens to the already-changed hardware type. OK, this is a direction i would like to check. Can be nice if you provide me with a 1-2 liner of directions on what need to be changed to enable bonding to accept slaves when it down. I don't think right offhand this would be a particularly difficult change; the up operation for bonding mostly just starts up various timers. A few minutes poking around doesn't reveal anything obvious that would hinder enslaving with the master down. You'll have to change ifenslave and the sysfs code to allow enslaves with the master down; that might be all that's needed for bonding itself. Changing /sbin/ifup and friends is a separate problem. OK, lets see i follow: 1st, your current recommendation to solve the link layer address computation of multicast groups joined by the stack before any enslavement actually takes place, is to instrument the bonding code such that it would be possible to enslave devices when the bonding device is not up yet. 2nd, the change need to be worked out in the bonding sysfs code, the ifenslave program but ***also*** in packages such as /sbin/ifup and friends. ??? BTW - is the ifenslave program still supported to work with upstream (2.6.18 and above) kernel or it was obsoleted at some point. Or. - 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: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
On Tue, 3 Oct 2006, Herbert Xu wrote: On Thu, Sep 28, 2006 at 10:40:18AM +0200, cagri coltekin wrote: No. Bug is the first after boot: OK, I think I've got the right bug this time. [UDP6]: Fix flowi clobbering The udp6_sendmsg function uses a shared buffer to store the flow without taking any locks. This leads to races with SMP. This patch moves the flowi object onto the stack. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Nice catch. Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - 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: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
On Tue, Oct 03, 2006 at 04:28:20PM +1000, Herbert Xu wrote:
On Tue, Oct 03, 2006 at 03:49:35PM +1000, Herbert Xu wrote:
OK, I think I've got the right bug this time.
Here is the patch for the other bug that I found along the way:
[UDP6]: Fix MSG_PROBE crash
This one fixes. Thanks!
The patch does not cleanly apply to 2.6.18, needed some manual
tweaking (the patch that applies cleanly to vanilla 2.6.18 is
below in case it has any use).
Cheers,
--
cagri
--- linux-2.6.18/net/ipv6/udp.c 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18-p4/net/ipv6/udp.c 2006-10-03 08:57:31.0 +0200
@@ -613,7 +613,7 @@
struct in6_addr *daddr, *final_p = NULL, final;
struct ipv6_txoptions *opt = NULL;
struct ip6_flowlabel *flowlabel = NULL;
- struct flowi *fl = inet-cork.fl;
+ struct flowi fl;
struct dst_entry *dst;
int addr_len = msg-msg_namelen;
int ulen = len;
@@ -693,19 +693,19 @@
}
ulen += sizeof(struct udphdr);
- memset(fl, 0, sizeof(*fl));
+ memset(fl, 0, sizeof(fl));
if (sin6) {
if (sin6-sin6_port == 0)
return -EINVAL;
- fl-fl_ip_dport = sin6-sin6_port;
+ fl.fl_ip_dport = sin6-sin6_port;
daddr = sin6-sin6_addr;
if (np-sndflow) {
- fl-fl6_flowlabel =
sin6-sin6_flowinfoIPV6_FLOWINFO_MASK;
- if (fl-fl6_flowlabelIPV6_FLOWLABEL_MASK) {
- flowlabel = fl6_sock_lookup(sk,
fl-fl6_flowlabel);
+ fl.fl6_flowlabel =
sin6-sin6_flowinfoIPV6_FLOWINFO_MASK;
+ if (fl.fl6_flowlabelIPV6_FLOWLABEL_MASK) {
+ flowlabel = fl6_sock_lookup(sk,
fl.fl6_flowlabel);
if (flowlabel == NULL)
return -EINVAL;
daddr = flowlabel-dst;
@@ -723,32 +723,32 @@
if (addr_len = sizeof(struct sockaddr_in6)
sin6-sin6_scope_id
ipv6_addr_type(daddr)IPV6_ADDR_LINKLOCAL)
- fl-oif = sin6-sin6_scope_id;
+ fl.oif = sin6-sin6_scope_id;
} else {
if (sk-sk_state != TCP_ESTABLISHED)
return -EDESTADDRREQ;
- fl-fl_ip_dport = inet-dport;
+ fl.fl_ip_dport = inet-dport;
daddr = np-daddr;
- fl-fl6_flowlabel = np-flow_label;
+ fl.fl6_flowlabel = np-flow_label;
connected = 1;
}
- if (!fl-oif)
- fl-oif = sk-sk_bound_dev_if;
+ if (!fl.oif)
+ fl.oif = sk-sk_bound_dev_if;
if (msg-msg_controllen) {
opt = opt_space;
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt-tot_len = sizeof(*opt);
- err = datagram_send_ctl(msg, fl, opt, hlimit, tclass);
+ err = datagram_send_ctl(msg, fl, opt, hlimit, tclass);
if (err 0) {
fl6_sock_release(flowlabel);
return err;
}
- if ((fl-fl6_flowlabelIPV6_FLOWLABEL_MASK) !flowlabel) {
- flowlabel = fl6_sock_lookup(sk, fl-fl6_flowlabel);
+ if ((fl.fl6_flowlabelIPV6_FLOWLABEL_MASK) !flowlabel) {
+ flowlabel = fl6_sock_lookup(sk, fl.fl6_flowlabel);
if (flowlabel == NULL)
return -EINVAL;
}
@@ -762,37 +762,37 @@
opt = fl6_merge_options(opt_space, flowlabel, opt);
opt = ipv6_fixup_options(opt_space, opt);
- fl-proto = IPPROTO_UDP;
- ipv6_addr_copy(fl-fl6_dst, daddr);
- if (ipv6_addr_any(fl-fl6_src) !ipv6_addr_any(np-saddr))
- ipv6_addr_copy(fl-fl6_src, np-saddr);
- fl-fl_ip_sport = inet-sport;
+ fl.proto = IPPROTO_UDP;
+ ipv6_addr_copy(fl.fl6_dst, daddr);
+ if (ipv6_addr_any(fl.fl6_src) !ipv6_addr_any(np-saddr))
+ ipv6_addr_copy(fl.fl6_src, np-saddr);
+ fl.fl_ip_sport = inet-sport;
/* merge ip6_build_xmit from ip6_output */
if (opt opt-srcrt) {
struct rt0_hdr *rt0 = (struct rt0_hdr *) opt-srcrt;
- ipv6_addr_copy(final, fl-fl6_dst);
- ipv6_addr_copy(fl-fl6_dst, rt0-addr);
+ ipv6_addr_copy(final, fl.fl6_dst);
+ ipv6_addr_copy(fl.fl6_dst, rt0-addr);
final_p = final;
connected = 0;
}
- if (!fl-oif ipv6_addr_is_multicast(fl-fl6_dst)) {
- fl-oif = np-mcast_oif;
+ if (!fl.oif ipv6_addr_is_multicast(fl.fl6_dst)) {
+ fl.oif = np-mcast_oif;
connected = 0;
}
- err = ip6_sk_dst_lookup(sk,
[patch 2/6] 2.6.18: sb1250-mac: Missing inclusions from linux/phy.h
Hello, The linux/phy.h uses some types and macros defined in linux/ethtool.h, linux/mii.h, linux/timer.h and linux/workqueue.h, but fails to include these headers. Please consider. Maciej Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED] patch-mips-2.6.18-20060920-include-phy-16 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/linux/phy.h linux-mips-2.6.18-20060920/include/linux/phy.h --- linux-mips-2.6.18-20060920.macro/include/linux/phy.h2006-08-29 04:58:59.0 + +++ linux-mips-2.6.18-20060920/include/linux/phy.h 2006-10-03 14:18:05.0 + @@ -20,6 +20,10 @@ #include linux/spinlock.h #include linux/device.h +#include linux/ethtool.h +#include linux/mii.h +#include linux/timer.h +#include linux/workqueue.h #define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ SUPPORTED_10baseT_Full | \ - 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 4/6] 2.6.18: sb1250-mac: The actual driver update
Hello,
This is the actual driver update. It includes the following changes:
1. Some help text for Kconfig.
2. Removal of unused module options.
3. Phylib support and the resulting removal of generic bits for handling
the PHY.
4. Proper reserving of device resources and using ioremap()ped handles
to access MAC registers rather than platform-specific macros.
5. Handling of the device using the driver model.
Please consider.
Maciej
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
patch-mips-2.6.18-20060920-sb1250-mac-15
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig
linux-mips-2.6.18-20060920/drivers/net/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig2006-09-10
04:55:24.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/Kconfig 2006-09-28
02:35:44.0 +
@@ -2030,6 +2030,15 @@ config R8169_NAPI
config NET_SB1250_MAC
tristate SB1250 Ethernet support
depends on SIBYTE_SB1xxx_SOC
+ select PHYLIB
+ ---help---
+ This driver supports gigabit Ethernet interfaces based on the
+ Broadcom SiByte family of System-On-a-Chip parts. They include
+ the BCM1120, BCM1125, BCM1125H, BCM1250, BCM1255, BCM1280, BCM1455
+ and BCM1480 chips.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sb1250-mac.
config R8169_VLAN
bool VLAN support
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c
linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c 2006-09-20
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c 2006-09-28
02:51:29.0 +
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2001,2002,2003,2004 Broadcom Corporation
+ * Copyright (c) 2006 Maciej W. Rozycki
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -18,7 +19,11 @@
*
* This driver is designed for the Broadcom SiByte SOC built-in
* Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp.
+ *
+ * Updated to the driver model and the PHY abstraction layer
+ * by Maciej W. Rozycki.
*/
+
#include linux/module.h
#include linux/kernel.h
#include linux/string.h
@@ -32,9 +37,18 @@
#include linux/skbuff.h
#include linux/init.h
#include linux/bitops.h
-#include asm/processor.h /* Processor type for cache alignment.
*/
-#include asm/io.h
+#include linux/err.h
+#include linux/ethtool.h
+#include linux/mii.h
+#include linux/phy.h
+#include linux/platform_device.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+
+#include asm/bug.h
#include asm/cache.h
+#include asm/io.h
+#include asm/processor.h /* Processor type for cache alignment. */
/* This is only here until the firmware is ready. In that case,
the firmware leaves the ethernet address in the register for us. */
@@ -48,7 +62,7 @@
/* These identify the driver base version and may not be removed. */
#if 0
-static char version1[] __devinitdata =
+static char version1[] __initdata =
sb1250-mac.c:1.00 1/11/2001 Written by Mitch Lichtenberg\n;
#endif
@@ -57,8 +71,6 @@ static char version1[] __devinitdata =
#define CONFIG_SBMAC_COALESCE
-#define MAX_UNITS 4/* More are supported, limit only on options */
-
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (2*HZ)
@@ -74,26 +86,6 @@ static int debug = 1;
module_param(debug, int, S_IRUGO);
MODULE_PARM_DESC(debug, Debug messages);
-/* mii status msgs */
-static int noisy_mii = 1;
-module_param(noisy_mii, int, S_IRUGO);
-MODULE_PARM_DESC(noisy_mii, MII status messages);
-
-/* Used to pass the media type, etc.
- Both 'options[]' and 'full_duplex[]' should exist for driver
- interoperability.
- The media type is usually passed in 'options[]'.
-*/
-#ifdef MODULE
-static int options[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(options, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(options, 1- __MODULE_STRING(MAX_UNITS));
-
-static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(full_duplex, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(full_duplex, 1- __MODULE_STRING(MAX_UNITS));
-#endif
-
#ifdef CONFIG_SBMAC_COALESCE
static int int_pktcnt = 0;
module_param(int_pktcnt, int, S_IRUGO);
@@ -104,6 +96,7 @@ module_param(int_timeout, int, S_IRUGO);
MODULE_PARM_DESC(int_timeout, Timeout value);
#endif
+#include asm/sibyte/board.h
#include asm/sibyte/sb1250.h
#if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
#include asm/sibyte/bcm1480_regs.h
@@ -126,22 +119,43 @@ MODULE_PARM_DESC(int_timeout, Timeout v
#error invalid SiByte MAC configuation
#endif
+#ifdef K_INT_PHY
+#define SBMAC_PHY_INT K_INT_PHY
+#else
+#define SBMAC_PHY_INT PHY_POLL
+#endif
+
[patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
Hello,
This patch fixes a couple of problems discovered with interrupt handling
in the phylib core, namely:
1. The driver uses timer and workqueue calls, but does not include
linux/timer.h nor linux/workqueue.h.
2. The driver uses schedule_work() for handling interrupts, but does not
make sure any pending work scheduled thus has been completed before
driver's structures get freed from memory. This is especially
important as interrupts may keep arriving if the line is shared with
another PHY.
The solution is to ignore phy_interrupt() calls if the reported device
has already been halted and calling flush_scheduled_work() from
phy_stop_interrupts() (but guarded with current_is_keventd() in case
the function has been called through keventd from the MAC device's
close call to avoid a deadlock on the netlink lock).
Please consider.
Maciej
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
patch-mips-2.6.18-20060920-phy-irq-16
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c
linux-mips-2.6.18-20060920/drivers/net/phy/phy.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c 2006-08-05
04:58:46.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy.c2006-10-03
14:19:21.0 +
@@ -7,6 +7,7 @@
* Author: Andy Fleming
*
* Copyright (c) 2004 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006 Maciej W. Rozycki
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -32,6 +33,8 @@
#include linux/mii.h
#include linux/ethtool.h
#include linux/phy.h
+#include linux/timer.h
+#include linux/workqueue.h
#include asm/io.h
#include asm/irq.h
@@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq
{
struct phy_device *phydev = phy_dat;
+ if (PHY_HALTED == phydev-state)
+ return IRQ_NONE;/* It can't be ours. */
+
/* The MDIO bus is not allowed to be written in interrupt
* context, so we need to disable the irq here. A work
* queue will write the PHY to disable and clear the
@@ -577,6 +583,13 @@ int phy_stop_interrupts(struct phy_devic
if (err)
phy_error(phydev);
+ /*
+* Finish any pending work; we might have been scheduled
+* to be called from keventd ourselves, though.
+*/
+ if (!current_is_keventd())
+ flush_scheduled_work();
+
free_irq(phydev-irq, phydev);
return err;
@@ -603,7 +616,8 @@ static void phy_change(void *data)
enable_irq(phydev-irq);
/* Reenable interrupts */
- err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
+ if (PHY_HALTED != phydev-state)
+ err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
if (err)
goto irq_enable_err;
@@ -624,18 +638,24 @@ void phy_stop(struct phy_device *phydev)
if (PHY_HALTED == phydev-state)
goto out_unlock;
- if (phydev-irq != PHY_POLL) {
- /* Clear any pending interrupts */
- phy_clear_interrupt(phydev);
+ phydev-state = PHY_HALTED;
+ if (phydev-irq != PHY_POLL) {
/* Disable PHY Interrupts */
phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
- }
- phydev-state = PHY_HALTED;
+ /* Clear any pending interrupts */
+ phy_clear_interrupt(phydev);
+ }
out_unlock:
spin_unlock(phydev-lock);
+
+ /*
+* Cannot call flush_scheduled_work() here as desired because
+* of rtnl_lock(), but PHY_HALTED shall guarantee phy_change()
+* will not reenable interrupts.
+*/
}
-
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 1/6] 2.6.18: sb1250-mac: Broadcom PHY support
Hello,
This patch adds support for interrupt-driven operation of the Broadcom
Gigabit Ethernet PHYs. I have included device IDs for the parts used on
Broadcom SiByte evaluation boards; more can be added as a need arises.
They are apparently generally software-compatible with one another.
Please consider.
Maciej
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
patch-mips-2.6.18-20060920-broadcom-phy-15
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/phy/Kconfig
linux-mips-2.6.18-20060920/drivers/net/phy/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/Kconfig2006-09-20
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/Kconfig 2006-09-23
14:39:08.0 +
@@ -56,6 +56,12 @@ config SMSC_PHY
---help---
Currently supports the LAN83C185 PHY
+config BROADCOM_PHY
+ tristate Drivers for Broadcom PHYs
+ depends on PHYLIB
+ ---help---
+ Currently supports the BCM5411, BCM5421 and BCM5461 PHYs.
+
config FIXED_PHY
tristate Drivers for PHY emulation on fixed speed/link
depends on PHYLIB
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/phy/Makefile
linux-mips-2.6.18-20060920/drivers/net/phy/Makefile
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/Makefile 2006-09-20
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/Makefile 2006-09-22
22:55:37.0 +
@@ -10,4 +10,5 @@ obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY)+= qsemi.o
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
+obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
obj-$(CONFIG_FIXED_PHY)+= fixed.o
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/drivers/net/phy/broadcom.c
linux-mips-2.6.18-20060920/drivers/net/phy/broadcom.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/broadcom.c 1970-01-01
00:00:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/broadcom.c 2006-09-28
01:47:11.0 +
@@ -0,0 +1,175 @@
+/*
+ * drivers/net/phy/broadcom.c
+ *
+ * Broadcom BCM5411, BCM5421 and BCM5461 Gigabit Ethernet
+ * transceivers.
+ *
+ * Copyright (c) 2006 Maciej W. Rozycki
+ *
+ * Inspired by code written by Amy Fong.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/phy.h
+
+#define MII_BCM54XX_ECR0x10/* BCM54xx extended control
register */
+#define MII_BCM54XX_ECR_IM 0x1000 /* Interrupt mask */
+#define MII_BCM54XX_ECR_IF 0x0800 /* Interrupt force */
+
+#define MII_BCM54XX_ESR0x11/* BCM54xx extended status
register */
+#define MII_BCM54XX_ESR_IS 0x1000 /* Interrupt status */
+
+#define MII_BCM54XX_ISR0x1a/* BCM54xx interrupt status
register */
+#define MII_BCM54XX_IMR0x1b/* BCM54xx interrupt mask
register */
+#define MII_BCM54XX_INT_CRCERR 0x0001 /* CRC error */
+#define MII_BCM54XX_INT_LINK 0x0002 /* Link status changed */
+#define MII_BCM54XX_INT_SPEED 0x0004 /* Link speed change */
+#define MII_BCM54XX_INT_DUPLEX 0x0008 /* Duplex mode changed */
+#define MII_BCM54XX_INT_LRS0x0010 /* Local receiver status changed */
+#define MII_BCM54XX_INT_RRS0x0020 /* Remote receiver status changed */
+#define MII_BCM54XX_INT_SSERR 0x0040 /* Scrambler synchronization error */
+#define MII_BCM54XX_INT_UHCD 0x0080 /* Unsupported HCD negotiated */
+#define MII_BCM54XX_INT_NHCD 0x0100 /* No HCD */
+#define MII_BCM54XX_INT_NHCDL 0x0200 /* No HCD link */
+#define MII_BCM54XX_INT_ANPR 0x0400 /* Auto-negotiation page received */
+#define MII_BCM54XX_INT_LC 0x0800 /* All counters below 128 */
+#define MII_BCM54XX_INT_HC 0x1000 /* Counter above 32768 */
+#define MII_BCM54XX_INT_MDIX 0x2000 /* MDIX status change */
+#define MII_BCM54XX_INT_PSERR 0x4000 /* Pair swap error */
+
+MODULE_DESCRIPTION(Broadcom PHY driver);
+MODULE_AUTHOR(Maciej W. Rozycki);
+MODULE_LICENSE(GPL);
+
+static int bcm54xx_config_init(struct phy_device *phydev)
+{
+ int reg, err;
+
+ reg = phy_read(phydev, MII_BCM54XX_ECR);
+ if (reg 0)
+ return reg;
+
+ /* Mask interrupts globally. */
+ reg |= MII_BCM54XX_ECR_IM;
+ err = phy_write(phydev, MII_BCM54XX_ECR, reg);
+ if (err 0)
+ return err;
+
+ /* Unmask events we are interested in. */
+ reg = ~(MII_BCM54XX_INT_DUPLEX |
+ MII_BCM54XX_INT_SPEED |
+ MII_BCM54XX_INT_LINK);
+ err = phy_write(phydev, MII_BCM54XX_IMR, reg);
+ if (err 0)
+ return err;
+
[patch 5/6] 2.6.18: sb1250-mac: Interrupt wiring for PHYs
Hello, This patch defines the wiring for the PHY interrupt lines for the supported Broadcom SiByte boards for which documentation is available. Please consider. Maciej Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED] patch-mips-2.6.18-20060920-sibyte-phy-irq-15 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/sentosa.h linux-mips-2.6.18-20060920/include/asm-mips/sibyte/sentosa.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/sentosa.h 2006-09-20 20:51:12.0 + +++ linux-mips-2.6.18-20060920/include/asm-mips/sibyte/sentosa.h 2006-09-25 21:08:37.0 + @@ -37,4 +37,8 @@ /* GPIOs */ #define K_GPIO_DBG_LED 0 +#ifdef CONFIG_SIBYTE_SENTOSA +#define K_INT_PHY K_INT_PCI_INTD +#endif + #endif /* __ASM_SIBYTE_SENTOSA_H */ diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/swarm.h linux-mips-2.6.18-20060920/include/asm-mips/sibyte/swarm.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/swarm.h 2006-09-20 20:51:12.0 + +++ linux-mips-2.6.18-20060920/include/asm-mips/sibyte/swarm.h 2006-09-25 21:56:49.0 + @@ -67,4 +67,9 @@ #define K_INT_PC_READY (K_INT_GPIO_0 + K_GPIO_PC_READY) #endif +#ifdef CONFIG_SIBYTE_SWARM +#define K_GPIO_PHY 2 +#define K_INT_PHY (K_INT_GPIO_0 + K_GPIO_PHY) +#endif + #endif /* __ASM_SIBYTE_SWARM_H */ - 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 0/6] 2.6.18: sb1250-mac: Driver model phylib update
Hello, Here is a set of patches that update the sb1250-mac driver used for the onchip Gigabit Ethernet interfaces of the Broadcom SiByte family of SOCs including the BCM1250 and a couple of other members. These are used, among others, on various Broadcom evaluation boards together with Broadcom Gigabit Ethernet PHY chips. Changes include porting the driver to the driver model as a platform device, support for phylib, including the BCM54xx PHYs in the interrupt mode, proper resource managment and a couple of minor clean-ups. Apart from changes to networking code, there are a few required in the architecture-specific areas and therefore I am sending these changes to Ralf and the linux-mips list as well. It might also involve a few more interested parties in the discussion. The changes were tested with a Broadcom SWARM board, which includes a BCM1250 part which has 3 MAC units on chip, of which 2 are usable, with BCM5421 PHY chips attached (both wired to the same interrupt line, which made testing whether IRQ sharing works properly in phylib possible). Link partners included a 1000base and a 100base interface doing autonegotiation as well as a 10base one doing none. Other Broadcom boards that I know of may have these or BCM5411 or BCM5461 chips. The lack of documentation or at least actual pieces of hardware makes the use of interrupts impossible for all but the SWARM, the Sentosa and the Shorty (with the latter unsupported by Linux). Maciej - 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 6/6] 2.6.18: sb1250-mac: PHY interrupt polarity fixup
Hello,
This change makes the PHY interrupt actually work as intended on the
SWARM board, where the CFE firmware leaves the GPIO line at the power-on
polarity, which is suitable for active-high interrupts, but not quite so
for this one (the interrupt force bit in the PHY works much better for
stress-testing interrupt handling; use that one instead if needed).
Please consider.
Maciej
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
patch-mips-2.6.18-20060920-swarm-setup-15
diff -up --recursive --new-file
linux-mips-2.6.18-20060920.macro/arch/mips/sibyte/swarm/setup.c
linux-mips-2.6.18-20060920/arch/mips/sibyte/swarm/setup.c
--- linux-mips-2.6.18-20060920.macro/arch/mips/sibyte/swarm/setup.c
2006-07-12 04:59:56.0 +
+++ linux-mips-2.6.18-20060920/arch/mips/sibyte/swarm/setup.c 2006-09-28
02:37:31.0 +
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2000, 2001, 2002, 2003, 2004 Broadcom Corporation
* Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (c) 2006 Maciej W. Rozycki
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -106,6 +107,8 @@ int swarm_be_handler(struct pt_regs *reg
void __init plat_mem_setup(void)
{
+ u64 invert;
+
#if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
bcm1480_setup();
#elif defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X)
@@ -114,6 +117,16 @@ void __init plat_mem_setup(void)
#error invalid SiByte board configuation
#endif
+ /*
+* The PHY interrupt on the SWARM is active low,
+* but CFE gets it wrong (or not at all, probably).
+*/
+#ifdef K_GPIO_PHY
+ invert = __raw_readq(IOADDR(A_GPIO_INPUT_INVERT));
+ invert |= 1 K_GPIO_PHY;
+ __raw_writeq(invert, IOADDR(A_GPIO_INPUT_INVERT));
+#endif
+
panic_timeout = 5; /* For debug. */
board_time_init = swarm_time_init;
-
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] mv643xx_eth: Fix ethtool stats
Some stats reported by ethtool -S on mv643xx_eth device are cleared between each call. Is it the wanted behaviour ? If not, the attached patch fixes it. Signed-off-by: Maxime Bizon [EMAIL PROTECTED] --- linux-2.6.18/drivers/net/mv643xx_eth.c.orig 2006-10-03 18:29:14.0 +0200 +++ linux-2.6.18/drivers/net/mv643xx_eth.c 2006-10-03 18:29:42.0 +0200 @@ -2156,7 +2156,7 @@ for (offset = ETH_MIB_BAD_OCTETS_RECEIVED; offset = ETH_MIB_FRAMES_1024_TO_MAX_OCTETS; offset += 4) - *(u32 *)((char *)p + offset) = read_mib(mp, offset); + *(u32 *)((char *)p + offset) += read_mib(mp, offset); p-good_octets_sent += read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_LOW); p-good_octets_sent += @@ -2165,7 +2165,7 @@ for (offset = ETH_MIB_GOOD_FRAMES_SENT; offset = ETH_MIB_LATE_COLLISION; offset += 4) - *(u32 *)((char *)p + offset) = read_mib(mp, offset); + *(u32 *)((char *)p + offset) += read_mib(mp, offset); } /* -- Maxime - 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-mm2 - oops in cache_alloc_refill()
Jean == Jean Tourrilhes [EMAIL PROTECTED] writes: Jean @@ -2500,9 +2501,9 @@ static int orinoco_hw_get_essid(struct o Jean len = le16_to_cpu(essidbuf.len); Jean BUG_ON(len IW_ESSID_MAX_SIZE); Jean Jean - memset(buf, 0, IW_ESSID_MAX_SIZE+1); Jean + memset(buf, 0, IW_ESSID_MAX_SIZE); Jean memcpy(buf, p, len); Jean - buf[len] = '\0'; Jean + err = len; Jean, something bugs me here: - either buf is supposed to be a nul-terminated string, in which case if p is IW_ESSID_MAX_SIZE long there may be a bug (no '\0' at the end of buf) - either buf is not-supposed to be nul-terminated and the length value will always be used, in which case the memset() looks useless I suggest that you revert the memset() to IW_ESSID_MAX_SIZE+1 so that the last byte is cleared as well. Or am I missing something? Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ - 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-mm2 - oops in cache_alloc_refill()
On Tue, Oct 03, 2006 at 05:58:31PM +0200, Samuel Tardieu wrote: Jean == Jean Tourrilhes [EMAIL PROTECTED] writes: Jean @@ -2500,9 +2501,9 @@ static int orinoco_hw_get_essid(struct o Jean len = le16_to_cpu(essidbuf.len); Jean BUG_ON(len IW_ESSID_MAX_SIZE); Jean Jean - memset(buf, 0, IW_ESSID_MAX_SIZE+1); Jean + memset(buf, 0, IW_ESSID_MAX_SIZE); Jean memcpy(buf, p, len); Jean - buf[len] = '\0'; Jean + err = len; Jean, something bugs me here: - either buf is supposed to be a nul-terminated string, in which case if p is IW_ESSID_MAX_SIZE long there may be a bug (no '\0' at the end of buf) ESSID is supposed to be up to 32 char, so we need to full buffer size. - either buf is not-supposed to be nul-terminated and the length value will always be used, in which case the memset() looks useless Yes, it is entirely useless, but not incorrect. Note that the code was not very efficient to start with, the last char of the string was set to NUL twice. I don't really want to overstep my authority there, my goal was to minimise the changes. Pavel will have to clean up my mess, so I don't want change things too much. I suggest that you revert the memset() to IW_ESSID_MAX_SIZE+1 so that the last byte is cleared as well. Or am I missing something? No, that would bring back the slab/memory overflow we are trying to get rid of. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ Strange, this name remind me someone. Must be a previous life ;-) A+ Jean - 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-mm2 - oops in cache_alloc_refill()
On 3/10, Jean Tourrilhes wrote: | I suggest that you revert the memset() to IW_ESSID_MAX_SIZE+1 so that | the last byte is cleared as well. Or am I missing something? | | No, that would bring back the slab/memory overflow we are | trying to get rid of. Then I am puzzled by the function declaration: static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active, char buf[IW_ESSID_MAX_SIZE+1]) Do you mean that this function is called with a buf parameter which doesn't have the expected size? (as far as the function declaration is concerned) Shouldn't the declaration be changed to static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active, char buf[IW_ESSID_MAX_SIZE]) then to reflect the reality? (it won't change the code but would be clearer from a documentation point of view) Sam - 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: Please pull bcm43xx-d80211 bugfixes and new features
On Tuesday 03 October 2006 05:44, Larry Finger wrote: Michael Buesch wrote: Hi John, Please pull from my tree git pull http://bu3sch.de/git/wireless-dev.git for-linville This will pull various bugfixes and feature improvements. Most noteably it will pull a bugfix for a crash introduced by an earlier patch to d80211 which changed RX status information handling. The new features include support for the new v4 firmware. I also did my homework to get better support for OpenWRT devices in ssb. The list of pulled changesets is: Michael Buesch: ssb: Abstract bus accesses. bcm43xx-d80211: convert to ssb abstract bus access API bcm43xx-d80211: Don't crash if we use v4 firmware. bcm43xx-d80211: Always make fwpostfix option available. bcm43xx-d80211: Firmware revision/patchlevel detection. bcm43xx-d80211: Add support for v4 firmware. bcm43xx-d80211: add SHM constants bcm43xx-d80211: Don't use low level netif and ieee80211_netif_oper functions. bcm43xx-d80211: DMA-mask fixes. bcm43xx-d80211: Remove some BCM947XX ifdefs, Merge branch 'master' of git://kernel.org/.../linville/wireless-dev bcm43xx-d80211: Assign all fields in the RX status report. bcm43xx-d80211: Set channel cookie to prevent ghost packets. bcm43xx-d80211: Prevent crash by setting active wlcore to NULL on wlcore-select failure. The diffstat is: drivers/misc/ssb.c | 431 ++- drivers/net/wireless/d80211/bcm43xx/bcm43xx.h | 143 +++ .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c | 295 +++- .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.h | 35 - drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c | 149 ++-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h | 18 drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c | 16 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 820 +--- drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c | 76 +- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c | 104 +-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.h | 12 .../net/wireless/d80211/bcm43xx/bcm43xx_power.c| 125 +--- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.c| 143 ++-- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.h|1 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c | 309 +++- drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h | 247 +- include/linux/ssb.h| 71 +- 17 files changed, 1681 insertions(+), 1314 deletions(-) Michael, There is something wrong with wireless-dev after I pulled your changes. The logs are: kernel: ssb: Core 0 found: cc 0800, rev 02, vendor 4243 kernel: ssb: Core 1 found: cc 0812, rev 04, vendor 4243 kernel: ssb: Core 2 found: cc 080D, rev 01, vendor 4243 kernel: ssb: Core 3 found: cc 0807, rev 01, vendor 4243 kernel: ssb: Core 4 found: cc 0804, rev 07, vendor 4243 kernel: ssb: Core 5 found: cc 0812, rev 04, vendor 4243 kernel: bcm43xx_d80211: Ignoring additional 802.11 core. kernel: bcm43xx_d80211: Broadcom 4306 WLAN found kernel: ssb: Switching to core 4 kernel: bcm43xx_d80211: PHY connected kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Detected PHY: Version: 1, Type 2, Revision 1 kernel: bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) kernel: bcm43xx_d80211: Radio turned off kernel: bcm43xx_d80211: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00 :06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: PHY disconnected kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? kernel: ssb: Switching to core 0 kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Radio turned on kernel: bcm43xx_d80211: Chip initialized kernel: bcm43xx_d80211: 30-bit DMA initialized kernel: bcm43xx_d80211: TODO: Incomplete code in keymac_write() at drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:871 . kernel: bcm43xx_d80211: Keys cleared kernel: bcm43xx_d80211: Selected 802.11 core (phytype 2) kernel: wmaster0: Does not support passive scan, disabled kernel: wlan1: starting scan kernel: HW CONFIG: channel=1 freq=2412 phymode=3 kernel: HW CONFIG: channel=2 freq=2417 phymode=3 kernel: bcm43xx_d80211: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR kernel: bcm43xx_d80211: ASSERTION FAILED (0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c:1020:parse_cookie() kernel: bcm43xx_d80211: ASSERTION FAILED (ring *slot = 0 *slot ring-nr_slots) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c:1023:parse_cookie() kernel: bcm43xx_d80211: FATAL
Re: Please pull bcm43xx-d80211 bugfixes and new features
On Tue, Oct 03, 2006 at 01:58:33PM +0200, Michael Buesch wrote: On Tuesday 03 October 2006 05:44, Larry Finger wrote: kernel: ssb: Core 0 found: cc 0800, rev 02, vendor 4243 kernel: ssb: Core 1 found: cc 0812, rev 04, vendor 4243 kernel: ssb: Core 2 found: cc 080D, rev 01, vendor 4243 kernel: ssb: Core 3 found: cc 0807, rev 01, vendor 4243 kernel: ssb: Core 4 found: cc 0804, rev 07, vendor 4243 kernel: ssb: Core 5 found: cc 0812, rev 04, vendor 4243 kernel: bcm43xx_d80211: Ignoring additional 802.11 core. kernel: bcm43xx_d80211: Broadcom 4306 WLAN found kernel: ssb: Switching to core 4 kernel: bcm43xx_d80211: PHY connected kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Detected PHY: Version: 1, Type 2, Revision 1 kernel: bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) kernel: bcm43xx_d80211: Radio turned off kernel: bcm43xx_d80211: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00 :06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: PHY disconnected kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? v4 testers should use the SVN version of fwcutter. There was a v4 windriver bug in fwcutter some time ago. Martin - 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: Please pull bcm43xx-d80211 bugfixes and new features
On Tuesday 03 October 2006 14:36, Martin Langer wrote: On Tue, Oct 03, 2006 at 01:58:33PM +0200, Michael Buesch wrote: On Tuesday 03 October 2006 05:44, Larry Finger wrote: kernel: ssb: Core 0 found: cc 0800, rev 02, vendor 4243 kernel: ssb: Core 1 found: cc 0812, rev 04, vendor 4243 kernel: ssb: Core 2 found: cc 080D, rev 01, vendor 4243 kernel: ssb: Core 3 found: cc 0807, rev 01, vendor 4243 kernel: ssb: Core 4 found: cc 0804, rev 07, vendor 4243 kernel: ssb: Core 5 found: cc 0812, rev 04, vendor 4243 kernel: bcm43xx_d80211: Ignoring additional 802.11 core. kernel: bcm43xx_d80211: Broadcom 4306 WLAN found kernel: ssb: Switching to core 4 kernel: bcm43xx_d80211: PHY connected kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Detected PHY: Version: 1, Type 2, Revision 1 kernel: bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) kernel: bcm43xx_d80211: Radio turned off kernel: bcm43xx_d80211: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00 :06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: PHY disconnected kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? v4 testers should use the SVN version of fwcutter. There was a v4 windriver bug in fwcutter some time ago. For convenience I modified current fwcutter to not reject v4 firmware files (but print a big fat warning) and tagged the 005 release here: http://prdownload.berlios.de/bcm43xx/bcm43xx-fwcutter-005.tar.bz2 -- Greetings Michael. - 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: Please pull bcm43xx-d80211 bugfixes and new features
Michael Buesch wrote: kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? The softmac version reports the following (The loaded messages are something I'm trying.): kernel: bcm43xx: Firmware: Microcode bcm43xx_microcode4.fw loaded. kernel: bcm43xx: Firmware: PCM bcm43xx_pcm4.fw loaded. kernel: bcm43xx: Firmware: InitVals0 bcm43xx_initval01.fw loaded. kernel: bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22 19:48:06) Larry - 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: Please pull bcm43xx-d80211 bugfixes and new features
On Tuesday 03 October 2006 16:36, Larry Finger wrote: Michael Buesch wrote: kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? The softmac version reports the following (The loaded messages are something I'm trying.): kernel: bcm43xx: Firmware: Microcode bcm43xx_microcode4.fw loaded. kernel: bcm43xx: Firmware: PCM bcm43xx_pcm4.fw loaded. kernel: bcm43xx: Firmware: InitVals0 bcm43xx_initval01.fw loaded. kernel: bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22 19:48:06) Well, so now you know where the problem is. I can't debug this for you ;) -- Greetings Michael. - 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: Please pull bcm43xx-d80211 bugfixes and new features
Michael Buesch wrote: On Tuesday 03 October 2006 16:36, Larry Finger wrote: Michael Buesch wrote: kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? The softmac version reports the following (The loaded messages are something I'm trying.): kernel: bcm43xx: Firmware: Microcode bcm43xx_microcode4.fw loaded. kernel: bcm43xx: Firmware: PCM bcm43xx_pcm4.fw loaded. kernel: bcm43xx: Firmware: InitVals0 bcm43xx_initval01.fw loaded. kernel: bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22 19:48:06) Well, so now you know where the problem is. I can't debug this for you ;) I repulled wireless-dev and rebuilt it to find the same problem, which probably is not in your recent patches. When I get a chance, I'll see if I can where it goes wrong. Larry - 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: Please pull bcm43xx-d80211 bugfixes and new features
On Tue, Oct 03, 2006 at 04:48:04PM +0200, Michael Buesch wrote: On Tuesday 03 October 2006 16:36, Larry Finger wrote: Michael Buesch wrote: kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? The softmac version reports the following (The loaded messages are something I'm trying.): kernel: bcm43xx: Firmware: Microcode bcm43xx_microcode4.fw loaded. kernel: bcm43xx: Firmware: PCM bcm43xx_pcm4.fw loaded. kernel: bcm43xx: Firmware: InitVals0 bcm43xx_initval01.fw loaded. kernel: bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22 19:48:06) Well, so now you know where the problem is. I can't debug this for you ;) You have to wait some time to get correct values. That was the reason why I placed version reading originally after bcm43xx_initialize_irq(), because I got strange values if I read the version directly after the upload. Martin - 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: Please pull bcm43xx-d80211 bugfixes and new features
On Tuesday 03 October 2006 17:12, Martin Langer wrote: On Tue, Oct 03, 2006 at 04:48:04PM +0200, Michael Buesch wrote: On Tuesday 03 October 2006 16:36, Larry Finger wrote: Michael Buesch wrote: kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 Uhm, which firmware are you running? The softmac version reports the following (The loaded messages are something I'm trying.): kernel: bcm43xx: Firmware: Microcode bcm43xx_microcode4.fw loaded. kernel: bcm43xx: Firmware: PCM bcm43xx_pcm4.fw loaded. kernel: bcm43xx: Firmware: InitVals0 bcm43xx_initval01.fw loaded. kernel: bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22 19:48:06) Well, so now you know where the problem is. I can't debug this for you ;) You have to wait some time to get correct values. That was the reason why I placed version reading originally after bcm43xx_initialize_irq(), because I got strange values if I read the version directly after the upload. Ok, that seems to be the problem. It's v3 firmware, but the driver is tuned to v4, because of the uncorrect rev value. I'll fix this. -- Greetings Michael. - 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-mm2 - oops in cache_alloc_refill()
On Tue, Oct 03, 2006 at 06:45:35PM +0200, Samuel Tardieu wrote: On 3/10, Jean Tourrilhes wrote: | I suggest that you revert the memset() to IW_ESSID_MAX_SIZE+1 so that | the last byte is cleared as well. Or am I missing something? | | No, that would bring back the slab/memory overflow we are | trying to get rid of. Then I am puzzled by the function declaration: static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active, char buf[IW_ESSID_MAX_SIZE+1]) Do you mean that this function is called with a buf parameter which doesn't have the expected size? (as far as the function declaration is concerned) Shouldn't the declaration be changed to static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active, char buf[IW_ESSID_MAX_SIZE]) then to reflect the reality? (it won't change the code but would be clearer from a documentation point of view) Yep, that one is a bug. Thanks ! Sam Jean - 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] mv643xx_eth: Fix ethtool stats
From: Maxime Bizon [EMAIL PROTECTED] Some stats reported by ethtool -S on mv643xx_eth device are cleared between each call. This patch fixes it. Signed-off-by: Maxime Bizon [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] --- Thanks Maxime. --- linux-2.6.18/drivers/net/mv643xx_eth.c.orig 2006-10-03 18:29:14.0 +0200 +++ linux-2.6.18/drivers/net/mv643xx_eth.c 2006-10-03 18:29:42.0 +0200 @@ -2156,7 +2156,7 @@ for (offset = ETH_MIB_BAD_OCTETS_RECEIVED; offset = ETH_MIB_FRAMES_1024_TO_MAX_OCTETS; offset += 4) - *(u32 *)((char *)p + offset) = read_mib(mp, offset); + *(u32 *)((char *)p + offset) += read_mib(mp, offset); p-good_octets_sent += read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_LOW); p-good_octets_sent += @@ -2165,7 +2165,7 @@ for (offset = ETH_MIB_GOOD_FRAMES_SENT; offset = ETH_MIB_LATE_COLLISION; offset += 4) - *(u32 *)((char *)p + offset) = read_mib(mp, offset); + *(u32 *)((char *)p + offset) += read_mib(mp, offset); } /* - 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 4/5] d80211: retain PS frames for at least STA listen interval
From: Jouni Malinen [EMAIL PROTECTED]
Start using 2 * listen_int * beacon_int as a timeout for PS buffered
unicast frames if that is longer than 10 seconds. Previously, we used
fixed 10 second limit regardless of the listen interval.
This fixes power saving for STAs that request very long listen
interval (over 10 seconds).
This was reported by UNH IOL 802.11 AP Base MAC Test Suite v2.4
Test #1.3.2 Part e.
While we are at it, remove the station from the TIM when the PS buffer is
empty.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/hostapd_ioctl.h
===
--- wireless-dev.orig/net/d80211/hostapd_ioctl.h
+++ wireless-dev/net/d80211/hostapd_ioctl.h
@@ -189,6 +189,7 @@ struct prism2_hostapd_param {
u8 wds_flags;
#define IEEE80211_STA_DYNAMIC_ENC BIT(0)
u8 enc_flags;
+ u16 listen_interval;
} add_sta;
struct {
u32 inactive_msec;
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -296,6 +296,7 @@ static int ieee80211_ioctl_add_sta(struc
sta-aid = param-u.add_sta.aid;
if (sta-aid IEEE80211_MAX_AID)
sta-aid = 0;
+ sta-listen_interval = param-u.add_sta.listen_interval;
rates = 0;
for (i = 0; i sizeof(param-u.add_sta.supp_rates); i++) {
Index: wireless-dev/net/d80211/sta_info.c
===
--- wireless-dev.orig/net/d80211/sta_info.c
+++ wireless-dev/net/d80211/sta_info.c
@@ -269,18 +269,24 @@ void sta_info_free(struct sta_info *sta,
}
-static inline int sta_info_buffer_expired(struct sk_buff *skb)
+static inline int sta_info_buffer_expired(struct ieee80211_local *local,
+ struct sta_info *sta,
+ struct sk_buff *skb)
{
struct ieee80211_tx_packet_data *pkt_data;
+ int timeout;
+
if (!skb)
return 0;
- /* TODO: this could be improved by passing STA listen interval into
-* the kernel driver and expiring frames after 2 x listen_interval x
- * beacon interval */
-
pkt_data = (struct ieee80211_tx_packet_data *) skb-cb;
- return time_after(jiffies, pkt_data-jiffies + STA_TX_BUFFER_EXPIRE);
+
+ /* Timeout: (2 * listen_interval * beacon_int * 1024 / 100) sec */
+ timeout = (sta-listen_interval * local-conf.beacon_int * 32 /
+ 15625) * HZ;
+ if (timeout STA_TX_BUFFER_EXPIRE)
+ timeout = STA_TX_BUFFER_EXPIRE;
+ return time_after(jiffies, pkt_data-jiffies + timeout);
}
@@ -296,9 +302,11 @@ static void sta_info_cleanup_expire_buff
for (;;) {
spin_lock_irqsave(sta-ps_tx_buf.lock, flags);
skb = skb_peek(sta-ps_tx_buf);
- if (sta_info_buffer_expired(skb))
+ if (sta_info_buffer_expired(local, sta, skb)) {
skb = __skb_dequeue(sta-ps_tx_buf);
- else
+ if (skb_queue_empty(sta-ps_tx_buf))
+ sta-flags = ~WLAN_STA_TIM;
+ } else
skb = NULL;
spin_unlock_irqrestore(sta-ps_tx_buf.lock, flags);
Index: wireless-dev/net/d80211/sta_info.h
===
--- wireless-dev.orig/net/d80211/sta_info.h
+++ wireless-dev/net/d80211/sta_info.h
@@ -107,6 +107,8 @@ struct sta_info {
#endif /* CONFIG_D80211_DEBUG_COUNTERS */
int vlan_id;
+
+ u16 listen_interval;
};
@@ -120,7 +122,8 @@ struct sta_info {
/* Maximum number of frames to buffer per power saving station */
#define STA_MAX_TX_BUFFER 128
-/* Buffered frame expiry time */
+/* Minimum buffered frame expiry time. If STA uses listen interval that is
+ * smaller than this value, the minimum value here is used instead. */
#define STA_TX_BUFFER_EXPIRE (10 * HZ)
/* How often station data is cleaned up (e.g., expiration of buffered frames)
--
-
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 5/5] d80211: allow wireless vlan interface to have same MAC an AP interface
Wireless vlan interfaces need to have the same mac address as AP interfaces. The STA must not see the change when it is bound to a specific vlan, so the address of the vlan interface must be the same as the address of the AP interface the station associated with. Signed-off-by: David Kimdon [EMAIL PROTECTED] Index: wireless-dev/net/d80211/ieee80211.c === --- wireless-dev.orig/net/d80211/ieee80211.c +++ wireless-dev/net/d80211/ieee80211.c @@ -2092,7 +2092,12 @@ static inline int identical_mac_addr_all type2 == IEEE80211_IF_TYPE_WDS) || (type1 == IEEE80211_IF_TYPE_WDS (type2 == IEEE80211_IF_TYPE_WDS || - type2 == IEEE80211_IF_TYPE_AP))); + type2 == IEEE80211_IF_TYPE_AP)) || + (type1 == IEEE80211_IF_TYPE_AP +type2 == IEEE80211_IF_TYPE_VLAN) || + (type1 == IEEE80211_IF_TYPE_VLAN +(type2 == IEEE80211_IF_TYPE_AP || + type2 == IEEE80211_IF_TYPE_VLAN))); } static int ieee80211_master_open(struct net_device *dev) -- - 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 3/5] d80211: remove rate limit code
From: Elliot Schwartz [EMAIL PROTECTED]
Remove unused and more or less pointless rate limiting code. This
would have just dropped multicast frames arbitrarily when the limit is
reached which is quite useless and does not really belong to 802.11
code.
Signed-off-by: Elliot Schwartz [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/hostapd_ioctl.h
===
--- wireless-dev.orig/net/d80211/hostapd_ioctl.h
+++ wireless-dev/net/d80211/hostapd_ioctl.h
@@ -58,8 +58,8 @@ enum {
PRISM2_PARAM_CTS_PROTECT_ERP_FRAMES = 1001,
PRISM2_PARAM_DROP_UNENCRYPTED = 1002,
PRISM2_PARAM_PREAMBLE = 1003,
- PRISM2_PARAM_RATE_LIMIT = 1004,
- PRISM2_PARAM_RATE_LIMIT_BURST = 1005,
+ PRISM2_PARAM_RATE_LIMIT = 1004, /* no longer used */
+ PRISM2_PARAM_RATE_LIMIT_BURST = 1005, /* no longer used */
PRISM2_PARAM_SHORT_SLOT_TIME = 1006,
PRISM2_PARAM_TEST_MODE = 1007,
PRISM2_PARAM_NEXT_MODE = 1008,
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -843,38 +843,6 @@ ieee80211_tx_h_misc(struct ieee80211_txr
}
-static void ieee80211_rate_limit(unsigned long data)
-{
- struct ieee80211_local *local = (struct ieee80211_local *) data;
-
- if (local-rate_limit) {
-local-rate_limit_bucket += local-rate_limit;
-if (local-rate_limit_bucket local-rate_limit_burst)
-local-rate_limit_bucket = local-rate_limit_burst;
- local-rate_limit_timer.expires = jiffies + HZ;
- add_timer(local-rate_limit_timer);
- }
-}
-
-
-static ieee80211_txrx_result
-ieee80211_tx_h_rate_limit(struct ieee80211_txrx_data *tx)
-{
-
- if (likely(!tx-local-rate_limit || tx-u.tx.unicast))
-return TXRX_CONTINUE;
-
- /* rate limit */
-if (tx-local-rate_limit_bucket) {
-tx-local-rate_limit_bucket--;
-return TXRX_CONTINUE;
-}
-
- I802_DEBUG_INC(tx-local-tx_handlers_drop_rate_limit);
- return TXRX_DROP;
-}
-
-
static ieee80211_txrx_result
ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
{
@@ -4206,7 +4174,6 @@ static ieee80211_rx_handler ieee80211_rx
static ieee80211_tx_handler ieee80211_tx_handlers[] =
{
- ieee80211_tx_h_rate_limit,
ieee80211_tx_h_check_assoc,
ieee80211_tx_h_ps_buf,
ieee80211_tx_h_select_key,
@@ -4369,9 +4336,6 @@ struct net_device *ieee80211_alloc_hw(si
init_timer(local-scan.timer); /* clear it out */
spin_lock_init(local-generic_lock);
- init_timer(local-rate_limit_timer);
- local-rate_limit_timer.function = ieee80211_rate_limit;
- local-rate_limit_timer.data = (unsigned long) local;
init_timer(local-stat_timer);
local-stat_timer.function = ieee80211_stat_refresh;
local-stat_timer.data = (unsigned long) local;
@@ -4582,8 +4546,6 @@ void ieee80211_unregister_hw(struct net_
}
rtnl_unlock();
- if (local-rate_limit)
- del_timer_sync(local-rate_limit_timer);
if (local-stat_time)
del_timer_sync(local-stat_timer);
if (local-scan_work.data) {
Index: wireless-dev/net/d80211/ieee80211_i.h
===
--- wireless-dev.orig/net/d80211/ieee80211_i.h
+++ wireless-dev/net/d80211/ieee80211_i.h
@@ -470,10 +470,6 @@ struct ieee80211_local {
u32 stat_time;
struct timer_list stat_timer;
-struct timer_list rate_limit_timer;
-u32 rate_limit;
-u32 rate_limit_burst;
-u32 rate_limit_bucket;
struct proc_dir_entry *proc, *proc_sta, *proc_iface;
struct work_struct sta_proc_add;
@@ -493,7 +489,6 @@ struct ieee80211_local {
unsigned int tx_handlers_drop_unencrypted;
unsigned int tx_handlers_drop_fragment;
unsigned int tx_handlers_drop_wep;
- unsigned int tx_handlers_drop_rate_limit;
unsigned int tx_handlers_drop_not_assoc;
unsigned int tx_handlers_drop_unauth_port;
unsigned int rx_handlers_drop;
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -2405,25 +2405,6 @@ static int ieee80211_ioctl_prism2_param(
local-short_preamble = value;
break;
- case PRISM2_PARAM_RATE_LIMIT_BURST:
- local-rate_limit_burst = value;
-local-rate_limit_bucket = value;
- break;
-
- case PRISM2_PARAM_RATE_LIMIT:
- /* number of packets (tokens) allowed per second */
- if (!local-rate_limit value) {
-
[patch 1/5] d80211: Fix overflow when creating AVS header
Fix overflow when converting timespec to microseconds. Without this patch you
can get an overflow during the multiplication which can result in a negative
number.
hostime is define here:
4.4 hosttime
The hosttime field is set to the current value of the host maintained
clock variable when the frame is received.
(from
http://www.locustworld.com/tracker/getfile/prism2drivers/doc/capturefrm.txt)
it is a u64.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -2573,7 +2573,7 @@ ieee80211_rx_mgmt(struct net_device *dev
struct ieee80211_rate *rate;
jiffies_to_timespec(status-hosttime, ts);
- fi-hosttime = cpu_to_be64(ts.tv_sec * 100 +
+ fi-hosttime = cpu_to_be64((u64) ts.tv_sec * 100 +
ts.tv_nsec / 1000);
fi-mactime = cpu_to_be64(status-mactime);
switch (status-phymode) {
--
-
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 2/5] d80211: remove unused xr structure members, interface, etc.
From: Elliot Schwartz [EMAIL PROTECTED]
This is all unused.
Signed-off-by: Elliot Schwartz [EMAIL PROTECTED]
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -82,7 +82,6 @@ struct ieee80211_hw_modes {
struct ieee80211_channel *channels;
int num_rates;
struct ieee80211_rate *rates;
- int xr_end; /* only used with Atheros XR */
};
struct ieee80211_tx_queue_params {
@@ -166,8 +165,6 @@ struct ieee80211_tx_control {
* transmission */
unsigned int fast_frame:1;
- unsigned int atheros_xr:1; /* only used with Atheros XR */
-
unsigned int power_level:8; /* per-packet transmit power level, in dBm
*/
unsigned int antenna_sel:4; /* 0 = default/diversity,
@@ -193,7 +190,6 @@ struct ieee80211_tx_control {
#define RX_FLAG_MMIC_ERROR 0x1
#define RX_FLAG_DECRYPTED0x2
-#define RX_FLAG_XR_DOUBLE_CHIRP 0x4
/* Receive status. The low-level driver should provide this information
* (the subset supported by hardware) to the 802.11 code with each received
@@ -276,8 +272,6 @@ struct ieee80211_conf {
int atheros_super_ag_turbo_g;
int atheros_super_ag_turbo_prime;
- int atheros_xr;
-
/* Following five fields are used for IEEE 802.11H */
unsigned int radar_detect;
unsigned int spect_mgmt;
@@ -679,9 +673,6 @@ struct ieee80211_hw {
* needed only for IBSS mode and the result of this function is used to
* determine whether to reply to Probe Requests. */
int (*tx_last_beacon)(struct net_device *dev);
-
- /* Optional handler for XR-in-use notification. */
- int (*atheros_xr_in_use)(struct net_device *dev, int in_use);
};
/* Allocate a new hardware device. This must be called once for each
Index: wireless-dev/include/net/d80211_mgmt.h
===
--- wireless-dev.orig/include/net/d80211_mgmt.h
+++ wireless-dev/include/net/d80211_mgmt.h
@@ -220,8 +220,4 @@ enum ieee80211_eid {
WLAN_EID_QOS_PARAMETER = 222
};
-
-
-#define ATHEROS_INFO_USEXR BIT(3)
-
#endif /* D802_11_MGMT_H */
Index: wireless-dev/include/net/d80211_shared.h
===
--- wireless-dev.orig/include/net/d80211_shared.h
+++ wireless-dev/include/net/d80211_shared.h
@@ -21,8 +21,7 @@ enum {
MODE_ATHEROS_TURBOG = 4 /* Atheros Turbo mode (2x.11g at 2.4 GHz) */,
MODE_ATHEROS_PRIME = 5 /* Atheros Dynamic Turbo mode */,
MODE_ATHEROS_PRIMEG = 6 /* Atheros Dynamic Turbo mode G */,
- MODE_ATHEROS_XR = 7 /* Atheros XR mode */,
- NUM_IEEE80211_MODES = 8
+ NUM_IEEE80211_MODES = 7
};
#define IEEE80211_CHAN_W_SCAN 0x0001
@@ -40,7 +39,6 @@ enum {
#define IEEE80211_RATE_CCK 0x0040
#define IEEE80211_RATE_TURBO 0x0080
#define IEEE80211_RATE_MANDATORY 0x0100
-#define IEEE80211_RATE_XR 0x0200
#define IEEE80211_RATE_CCK_2 (IEEE80211_RATE_CCK | IEEE80211_RATE_PREAMBLE2)
#define IEEE80211_RATE_MODULATION(f) \
Index: wireless-dev/net/d80211/hostapd_ioctl.h
===
--- wireless-dev.orig/net/d80211/hostapd_ioctl.h
+++ wireless-dev/net/d80211/hostapd_ioctl.h
@@ -186,7 +186,6 @@ struct prism2_hostapd_param {
* IEEE80211_ATHEROS_SUPER_AG
*/
u8 atheros_super_ag;
- u8 atheros_xr_mode;
u8 wds_flags;
#define IEEE80211_STA_DYNAMIC_ENC BIT(0)
u8 enc_flags;
Index: wireless-dev/net/d80211/ieee80211_sysfs_sta.c
===
--- wireless-dev.orig/net/d80211/ieee80211_sysfs_sta.c
+++ wireless-dev/net/d80211/ieee80211_sysfs_sta.c
@@ -77,7 +77,7 @@ STA_ATTR(wep_weak_iv_count, wep_weak_iv_
static ssize_t show_sta_flags(const struct sta_info *sta, char *buf)
{
- return sprintf(buf, %s%s%s%s%s%s%s%s%s%s,
+ return sprintf(buf, %s%s%s%s%s%s%s%s%s,
sta-flags WLAN_STA_AUTH ? AUTH\n : ,
sta-flags WLAN_STA_ASSOC ? ASSOC\n : ,
sta-flags WLAN_STA_PS ? PS\n : ,
@@ -87,8 +87,7 @@ static ssize_t show_sta_flags(const stru
sta-flags WLAN_STA_SHORT_PREAMBLE ?
SHORT PREAMBLE\n : ,
sta-flags WLAN_STA_WME ? WME\n : ,
- sta-flags WLAN_STA_WDS ? WDS\n : ,
- sta-flags WLAN_STA_XR ? XR\n : );
+ sta-flags WLAN_STA_WDS ? WDS\n : );
}
__STA_ATTR(flags);
Index: wireless-dev/net/d80211/sta_info.h
===
---
Re: [PATCH] Customizable TCP backoff patch
David Miller wrote:
From: Ben Woodard [EMAIL PROTECTED]
Date: Wed, 27 Sep 2006 11:52:57 -0700
Because these are general utility clusters we run many different
programs and so trying to fix this problem in the application is not
possible since there are literally hundreds if not thousands of them.
Then why add a socket option setting as your patch does? :-)
I also object to the socket option setting being allowed for
any user because this can have awful effects if allowed by
arbitrary users on arbitrary networks.
We're more than willing to consider other approaches to handling this
particular workload better. We've even considered that TCP isn't at all
the right protocol but this affects several protocols including NFS and
the benefits of running NFS over TCP are too great.
The original patch was prepared by Brian Behlendorf. He asked me to
adapt it for current kernels keep it up to date and send upstream.
This may also help people like Andrew Athan which reported a similar
problem a couple of days ago on the linux-net mailing list:
http://www.uwsg.iu.edu/hypermail/linux/net/0609.3/0005.html I suspect
that it is more common a case than is widely recognized.
Signed-off-by: Ben Woodard [EMAIL PROTECTED]
Signed-off-by: Brian Behlendorf [EMAIL PROTECTED]
Other issues:
1) 2 u32 in the tcp_sock is a lot of space to devote to this
new state. If it can fit in 2 u16's or even less space,
please use that.
2) the expression (tp-foo ? : sysctl_foo) is repeated many times
in the patch, please encapsulate it into an inline function
or similar
How does this look to you for answering your two complaints above.
I'm still torn on the fundamental issues of this patch. I think
random backoff is a better generic solution to this kind of problem.
If it works for ethernet, it might just work for TCP too :-)
I haven't taken this on in this patch. I'd have to think more about how
to do that and I'm not sure that introducing randomness here will allow
us to settle into a steady state faster than configuring a shorter
timeout in the environments that need it.
Thanks.
diff -ru linux-2.6.18/include/linux/sysctl.h linux-2.6.18.new/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18.new/include/linux/sysctl.h 2006-09-26 17:10:36.0 -0700
@@ -411,6 +411,8 @@
NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS=115,
NET_TCP_DMA_COPYBREAK=116,
NET_TCP_SLOW_START_AFTER_IDLE=117,
+ NET_TCP_RTO_MAX=118,
+ NET_TCP_RTO_INIT=119,
};
enum {
Only in linux-2.6.18.new/include/linux: sysctl.h.orig
Only in linux-2.6.18.new/include/linux: sysctl.h.rej
diff -ru linux-2.6.18/include/linux/tcp.h linux-2.6.18.new/include/linux/tcp.h
--- linux-2.6.18/include/linux/tcp.h 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18.new/include/linux/tcp.h 2006-09-28 13:18:12.0 -0700
@@ -94,6 +94,8 @@
#define TCP_INFO 11 /* Information about this connection. */
#define TCP_QUICKACK 12 /* Block/reenable quick acks */
#define TCP_CONGESTION 13 /* Congestion control algorithm */
+#define TCP_BACKOFF_MAX 14 /* Maximum backoff value */
+#define TCP_BACKOFF_INIT15 /* Initial backoff value */
#define TCPI_OPT_TIMESTAMPS 1
#define TCPI_OPT_SACK 2
@@ -257,6 +259,8 @@
__u8 frto_counter; /* Number of new acks after RTO */
__u8 nonagle; /* Disable Nagle algorithm? */
__u8 keepalive_probes; /* num of allowed keep alive probes */
+__u16 rto_max;/* Maximum backoff value*/
+__u16 rto_init; /* Initial backoff value*/
/* RTT measurement */
__u32 srtt; /* smoothed round trip time 3 */
Only in linux-2.6.18.new/include/linux: tcp.h.orig
diff -ru linux-2.6.18/include/net/tcp.h linux-2.6.18.new/include/net/tcp.h
--- linux-2.6.18/include/net/tcp.h 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18.new/include/net/tcp.h 2006-09-26 17:12:04.0 -0700
@@ -227,6 +227,8 @@
extern int sysctl_tcp_base_mss;
extern int sysctl_tcp_workaround_signed_windows;
extern int sysctl_tcp_slow_start_after_idle;
+extern int sysctl_tcp_rto_max;
+extern int sysctl_tcp_rto_init;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
Only in linux-2.6.18.new/include/net: tcp.h.orig
Only in linux-2.6.18.new/include/net: tcp.h.rej
diff -ru linux-2.6.18/net/ipv4/sysctl_net_ipv4.c linux-2.6.18.new/net/ipv4/sysctl_net_ipv4.c
--- linux-2.6.18/net/ipv4/sysctl_net_ipv4.c 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18.new/net/ipv4/sysctl_net_ipv4.c 2006-09-26 17:08:33.0 -0700
@@ -697,6 +697,22 @@
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .ctl_name = NET_TCP_RTO_MAX,
+ .procname = tcp_rto_max,
+ .data = sysctl_tcp_rto_max,
+ .maxlen = sizeof(unsigned),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
+ .ctl_name =
Re: sky2 hangs, hw csum errors with 2.6.18
Hi Stephen, I'm still getting tx timeouts even after applying the patch you sent me and forcing tx flow control off: Sep 28 20:35:53 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 20:35:53 dezo kernel: sky2 eth1: tx timeout Sep 28 20:35:53 dezo kernel: sky2 eth1: transmit ring 420 .. 379 report=420 done=420 Sep 28 20:35:53 dezo kernel: sky2 hardware hung? flushing Sep 28 20:50:28 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 20:50:28 dezo kernel: sky2 eth1: tx timeout Sep 28 20:50:28 dezo kernel: sky2 eth1: transmit ring 379 .. 338 report=420 done=420 Sep 28 20:50:28 dezo kernel: sky2 status report lost? Sep 28 20:51:53 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 20:51:53 dezo kernel: sky2 eth1: tx timeout Sep 28 20:51:53 dezo kernel: sky2 eth1: transmit ring 420 .. 379 report=420 done=420 Sep 28 20:51:53 dezo kernel: sky2 hardware hung? flushing Sep 28 21:08:03 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:08:03 dezo kernel: sky2 eth1: tx timeout Sep 28 21:08:03 dezo kernel: sky2 eth1: transmit ring 379 .. 338 report=420 done=420 Sep 28 21:08:03 dezo kernel: sky2 status report lost? Sep 28 21:09:28 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:09:28 dezo kernel: sky2 eth1: tx timeout Sep 28 21:09:28 dezo kernel: sky2 eth1: transmit ring 420 .. 379 report=420 done=420 Sep 28 21:09:28 dezo kernel: sky2 hardware hung? flushing Sep 28 21:25:18 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:25:18 dezo kernel: sky2 eth1: tx timeout Sep 28 21:25:18 dezo kernel: sky2 eth1: transmit ring 379 .. 338 report=420 done=420 Sep 28 21:25:18 dezo kernel: sky2 status report lost? Sep 28 21:26:38 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:26:38 dezo kernel: sky2 eth1: tx timeout Sep 28 21:26:38 dezo kernel: sky2 eth1: transmit ring 420 .. 379 report=420 done=420 Sep 28 21:26:38 dezo kernel: sky2 hardware hung? flushing Sep 28 21:41:42 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:41:42 dezo kernel: sky2 eth1: tx timeout Sep 28 21:41:42 dezo kernel: sky2 eth1: transmit ring 379 .. 338 report=420 done=420 Sep 28 21:41:42 dezo kernel: sky2 status report lost? Sep 28 21:42:57 dezo kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 28 21:42:57 dezo kernel: sky2 eth1: tx timeout Sep 28 21:42:57 dezo kernel: sky2 eth1: transmit ring 420 .. 379 report=420 done=420 Sep 28 21:42:57 dezo kernel: sky2 hardware hung? flushing Sep 28 21:49:19 dezo kernel: sky2 eth1: disabling interface Sep 28 21:49:19 dezo kernel: sky2 eth1: enabling interface Sep 28 21:49:22 dezo kernel: sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control rx Sep 28 21:49:30 dezo kernel: eth1: no IPv6 routers present This appears to have resulted in a system hang some time later, since the machine stopped responding and the last message I see in the syslog is: Sep 28 22:09:22 dezo -- MARK -- The box was dead when I arrived at the office the next morning. Also, I'm seeing a bunch of messages like this (in addition to the hw csum failures I mentioned in my original email): Oct 2 16:42:17 dezo kernel: SKB BUG: Invalid truesize (3944) len=12745, sizeof(sk_buff)=2 32 Oct 2 16:42:29 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 2 16:42:29 dezo last message repeated 11 times Oct 3 17:20:54 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 3 17:21:56 dezo last message repeated 4 times Oct 3 17:21:56 dezo last message repeated 3 times Oct 3 17:23:46 dezo last message repeated 2 times Oct 3 20:03:28 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 3 20:03:28 dezo last message repeated 16 times After which some open TCP sockets between dezo and another box (also with sky2) start running really slowly. Not sure how to proceed with this - is there a newer version of sky2 than that in 2.6.18 which I can test? -mato - 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 2/5] ibmveth: Add netpoll function
From: Santiago Leon [EMAIL PROTECTED]
This patch adds the net poll controller function to ibmveth to support
netconsole and netdump.
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
---
drivers/net/ibmveth.c | 11 +++
1 file changed, 11 insertions(+)
diff -urNp a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2006-07-12 11:07:41.940202928 -0500
+++ b/drivers/net/ibmveth.c 2006-07-12 11:09:45.344207680 -0500
@@ -925,6 +925,14 @@ static int ibmveth_change_mtu(struct net
return -EINVAL;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void ibmveth_poll_controller(struct net_device *dev)
+{
+ ibmveth_replenish_task(dev-priv);
+ ibmveth_interrupt(dev-irq, dev, NULL);
+}
+#endif
+
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct
vio_device_id *id)
{
int rc, i;
@@ -997,6 +1005,9 @@ static int __devinit ibmveth_probe(struc
netdev-ethtool_ops = netdev_ethtool_ops;
netdev-change_mtu = ibmveth_change_mtu;
SET_NETDEV_DEV(netdev, dev-dev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev-poll_controller = ibmveth_poll_controller;
+#endif
netdev-features |= NETIF_F_LLTX;
spin_lock_init(adapter-stats_lock);
-
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 0/5] ibmveth: various fixes
Hi Jeff, Can you apply the following patches (hopefully for 2.6.19)? They are the hardening of the initialization for kexec, adding netpoll, and some small fixes for bugs that people have been running into. Thanks, -- Santiago A. Leon Power Linux Development IBM Linux Technology Center - 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 3/5] ibmveth: kdump interrupt fix
From: Santiago Leon [EMAIL PROTECTED]
This patch fixes a race that panics the kernel when opening the device after a
kdump. Without this patch there is a window where the hypervisor can send an
interrupt before all the structures for the kdump ibmveth module are ready
(because the hypervisor is not aware that the partition crashed and that the
virtual driver is reloading). We close this window by disabling the interrupts
before registering the adapter to the hypervisor.
This patch depends on the ibmveth: Harden driver initilisation patch.
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
---
drivers/net/ibmveth.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -527,6 +527,8 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk(filter list @ 0x%p\n, adapter-filter_list_addr);
ibmveth_debug_printk(receive q @ 0x%p\n,
adapter-rx_queue.queue_addr);
+ h_vio_signal(adapter-vdev-unit_address, VIO_IRQ_DISABLE);
+
lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
-
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 5/5] ibmveth: fix int rollover panic
From: Santiago Leon [EMAIL PROTECTED]
This patch fixes a nasty bug that has been sitting there since the very first
versions of the driver, but is generating a panic because we changed the number
of 2K buffers for 2.6.16.
The consumer_index and producer_index are u32's that get incremented on every
buffer emptied and replenished respectively. We use the
{producer,consumer}_index mod'ed with the size of the pool to pick out an entry
in the free_map. The problem happens when the u32 rolls over and the number of
the buffers in the pool is not a perfect divisor of 2^32. i.e. if the number
of 2K buffers is 0x300, before the consumer_index rolls over, our index to the
free map = 0x mod 0x300 = 0xff. The next time a buffer is emptied, we
want the index to the free map to be 0x100, but 0x0 mod 0x300 is 0x0.
This patch assigns the mod'ed result back to the consumer and producer indexes
so that they never roll over. The second chunk of the patch covers the
unlikely case where the consumer_index has just been reset to 0x0 and the
hypervisor is not able to accept that buffer.
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
---
drivers/net/ibmveth.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -213,6 +213,7 @@ static void ibmveth_replenish_buffer_poo
}
free_index = pool-consumer_index++ % pool-size;
+ pool-consumer_index = free_index;
index = pool-free_map[free_index];
ibmveth_assert(index != IBM_VETH_INVALID_MAP);
@@ -238,7 +239,10 @@ static void ibmveth_replenish_buffer_poo
if(lpar_rc != H_SUCCESS) {
pool-free_map[free_index] = index;
pool-skbuff[index] = NULL;
- pool-consumer_index--;
+ if (pool-consumer_index == 0)
+ pool-consumer_index = pool-size - 1;
+ else
+ pool-consumer_index--;
dma_unmap_single(adapter-vdev-dev,
pool-dma_addr[index], pool-buff_size,
DMA_FROM_DEVICE);
@@ -326,6 +330,7 @@ static void ibmveth_remove_buffer_from_p
DMA_FROM_DEVICE);
free_index = adapter-rx_buff_pool[pool].producer_index++ %
adapter-rx_buff_pool[pool].size;
+ adapter-rx_buff_pool[pool].producer_index = free_index;
adapter-rx_buff_pool[pool].free_map[free_index] = index;
mb();
-
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 1/5] ibmveth: Harden driver initilisation
From: Michael Ellerman [EMAIL PROTECTED]
Hi Jeff,
This patch has been floating around for a while now, Santi originally sent it
in March: http://www.spinics.net/lists/netdev/msg00471.html
You replied saying you thought it was bonkers, I think I explained why it
wasn't, perhaps you disagree.
I'm resending it now in the hope you can either give us more info on your
objections, or merge it.
After a kexec the ibmveth driver will fail when trying to register with the
Hypervisor because the previous kernel has not unregistered.
So if the registration fails, we unregister and then try again.
We don't unconditionally unregister, because we don't want to disturb the
regular code path for 99% of users.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Anton Blanchard [EMAIL PROTECTED]
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
---
drivers/net/ibmveth.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff -urNp a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2006-07-12 10:45:09.787235496 -0500
+++ b/drivers/net/ibmveth.c 2006-07-12 10:43:20.655186616 -0500
@@ -437,6 +437,31 @@ static void ibmveth_cleanup(struct ibmve
adapter-rx_buff_pool[i]);
}
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+ int rc, try_again = 1;
+
+ /* After a kexec the adapter will still be open, so our attempt to
+ * open it will fail. So if we get a failure we free the adapter and
+ * try again, but only once. */
+retry:
+ rc = h_register_logical_lan(adapter-vdev-unit_address,
+ adapter-buffer_list_dma, rxq_desc.desc,
+ adapter-filter_list_dma, mac_address);
+
+ if (rc != H_SUCCESS try_again) {
+ do {
+ rc = h_free_logical_lan(adapter-vdev-unit_address);
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+ try_again = 0;
+ goto retry;
+ }
+
+ return rc;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev-priv;
@@ -502,12 +527,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk(filter list @ 0x%p\n, adapter-filter_list_addr);
ibmveth_debug_printk(receive q @ 0x%p\n,
adapter-rx_queue.queue_addr);
-
- lpar_rc = h_register_logical_lan(adapter-vdev-unit_address,
-adapter-buffer_list_dma,
-rxq_desc.desc,
-adapter-filter_list_dma,
-mac_address);
+ lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk(h_register_logical_lan failed with
%ld\n, lpar_rc);
-
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 4/5] ibmveth: rename proc entry name
From: Santiago Leon [EMAIL PROTECTED]
This patch changes the name of the proc file for each ibmveth adapter from the
network device name to the slot number in the virtual bus.
The proc file is created when the device is probed, so a change in the name of
the device will not be reflected in the name of the proc file giving problems
when identifying and removing the adapter. The slot number is a property that
does not change through the life of the adapter so we use that instead.
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
---
drivers/net/ibmveth.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1165,7 +1165,9 @@ static void ibmveth_proc_register_adapte
{
struct proc_dir_entry *entry;
if (ibmveth_proc_dir) {
- entry = create_proc_entry(adapter-netdev-name, S_IFREG,
ibmveth_proc_dir);
+ char u_addr[10];
+ sprintf(u_addr, %x, adapter-vdev-unit_address);
+ entry = create_proc_entry(u_addr, S_IFREG, ibmveth_proc_dir);
if (!entry) {
ibmveth_error_printk(Cannot create adapter proc
entry);
} else {
@@ -1180,7 +1182,9 @@ static void ibmveth_proc_register_adapte
static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter *adapter)
{
if (ibmveth_proc_dir) {
- remove_proc_entry(adapter-netdev-name, ibmveth_proc_dir);
+ char u_addr[10];
+ sprintf(u_addr, %x, adapter-vdev-unit_address);
+ remove_proc_entry(u_addr, ibmveth_proc_dir);
}
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7254] New: leaving IP multicast group with incorrect imr_address unexpectedly succeeded
If the index is set, it doesn't look up the address (which may be expensive). If you want to look up by address, the index must be 0. I wouldn't call that a bug. +-DLS - 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: sky2 hangs, hw csum errors with 2.6.18
On Tue, 3 Oct 2006 20:21:20 +0200 Martin Lucina [EMAIL PROTECTED] wrote: Hi Stephen, I'm still getting tx timeouts even after applying the patch you sent me and forcing tx flow control off: What speed and duplex are you using? Also, I'm seeing a bunch of messages like this (in addition to the hw csum failures I mentioned in my original email): Oct 2 16:42:17 dezo kernel: SKB BUG: Invalid truesize (3944) len=12745, sizeof(sk_buff)=2 32 Oct 2 16:42:29 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 2 16:42:29 dezo last message repeated 11 times Oct 3 17:20:54 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 3 17:21:56 dezo last message repeated 4 times Oct 3 17:21:56 dezo last message repeated 3 times Oct 3 17:23:46 dezo last message repeated 2 times Oct 3 20:03:28 dezo kernel: SKB BUG: Invalid truesize (3944) len=16384, sizeof(sk_buff)=2 32 Oct 3 20:03:28 dezo last message repeated 16 times After which some open TCP sockets between dezo and another box (also with sky2) start running really slowly. What MTU are you using. Not sure how to proceed with this - is there a newer version of sky2 than that in 2.6.18 which I can test? -mato -- Stephen Hemminger [EMAIL PROTECTED] - 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: sky2 hangs, hw csum errors with 2.6.18
[EMAIL PROTECTED] said: On Tue, 3 Oct 2006 20:21:20 +0200 Martin Lucina [EMAIL PROTECTED] wrote: Hi Stephen, I'm still getting tx timeouts even after applying the patch you sent me and forcing tx flow control off: What speed and duplex are you using? 1000 Mbps, full duplex What MTU are you using. 1500 -mato - 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: sky2 hangs, hw csum errors with 2.6.18
On Tue, 3 Oct 2006 21:13:51 +0200 Martin Lucina [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] said: What speed and duplex are you using? 1000 Mbps, full duplex What MTU are you using. 1500 Are you sure? I assume you are using the latest driver from Linus's git repository. That version adds support for fragmented receive, but that code shouldn't be doing anything unless MTU page size (4K). Absolutely positive on the MTU and speed/duplex. !!! As for the driver version, I'm using the one in the stock 2.6.18 kernel, NOT the one in Linus' git. !!! If I should be using a newer version, please send me a patch, or tell me a way to obtain one from the git repository that doesn't involve syncing the whole repository (not enough intl bandwith for that sort of thing here). -mato If you are seeing truesize errors with the stock 2.6.18 kernel then some other protocol is messing with the skb's? Are you using IPV6? Or PPPoE or something like that. -- Stephen Hemminger [EMAIL PROTECTED] - 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: sky2 hangs, hw csum errors with 2.6.18
Possibly related, could the TX hangs be due to extreme load / no free memory on the machine? I just realised that my application appears to be loading the machine to the max... (i.e. all 2GB RAM used + another couple GB in swap) -mato - 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: sky2 hangs, hw csum errors with 2.6.18
[EMAIL PROTECTED] said: What speed and duplex are you using? 1000 Mbps, full duplex What MTU are you using. 1500 Are you sure? I assume you are using the latest driver from Linus's git repository. That version adds support for fragmented receive, but that code shouldn't be doing anything unless MTU page size (4K). Absolutely positive on the MTU and speed/duplex. !!! As for the driver version, I'm using the one in the stock 2.6.18 kernel, NOT the one in Linus' git. !!! If I should be using a newer version, please send me a patch, or tell me a way to obtain one from the git repository that doesn't involve syncing the whole repository (not enough intl bandwith for that sort of thing here). -mato - 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: sky2 hangs, hw csum errors with 2.6.18
[EMAIL PROTECTED] said: If you are seeing truesize errors with the stock 2.6.18 kernel then some other protocol is messing with the skb's? Are you using IPV6? Or PPPoE or something like that. Only thing like that that is running here is OpenVPN which is using a tun interface. There's hardly any traffic running over that though. Could that explain the truesize errors? Doesn't explain the sky2 tx timeouts though... -mato - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7254] New: leaving IP multicast group with incorrect imr_address unexpectedly succeeded
From: David Stevens [EMAIL PROTECTED] Date: Tue, 3 Oct 2006 11:33:07 -0700 If the index is set, it doesn't look up the address (which may be expensive). If you want to look up by address, the index must be 0. I wouldn't call that a bug. Me neither, Andrew please close this. :) - 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] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 03 Oct 2006 20:05:33 +0200 Ismail Donmez wrote: With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE changed behaviour so it returns true when the node is empty as expected. Hence Patrick McHardy's fix for sched_htb.c should be reverted. Signed-off-by: Ismail Donmez [EMAIL PROTECTED] ACKed-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks everyone. - 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] neigh: always use hash_mask under tbl lock
From: Julian Anastasov [EMAIL PROTECTED] Date: Tue, 3 Oct 2006 03:05:51 +0300 (EEST) Make sure hash_mask is protected with tbl-lock in all cases just like the hash_buckets. Signed-off-by: Julian Anastasov [EMAIL PROTECTED] Applied, thanks Julian. I'll push this to -stable too. - 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][XFRM] Fixes for net-2.6
From: Masahide NAKAMURA [EMAIL PROTECTED] Date: Tue, 03 Oct 2006 12:29:54 +0900 [XFRM] POLICY: Fix per-direction policy counter after flushing. Currently when xfrm_policy_flush() is called per-direction policy counter is cleared. However flusing policy is performed for each type (i.e. main or sub) then it is not always true to make the counter zero. Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] The idea of this code is to avoid updating global state many many times during such a flush. This can be expensive and cause much SMP cacheline activity as other cpus read the counter in the routing lookup path. I think what I'll do is reimplement this patch so that a local variable is used to maintain how many entries were removed, and then simply subtract that counter from xfrm_policy_count[dir] at the very end where the assignment to zero occurs. [XFRM] STATE: Use destination address for src hash. Src hash is introduced for Mobile IPv6 route optimization usage. On current kenrel code it is calculated with source address only. It results we uses the same hash value for outbound state (when the node has only one address for Mobile IPv6). This patch use also destination address as peer information for src hash to be dispersed. Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] This patch is fine, I will apply this, thank you. - 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 3/3] enable IP multicast when bonding IPoIB devices
Or Gerlitz [EMAIL PROTECTED] wrote: Sorry, but I don't follow... by saying would be ideal to do ***it*** this way in all cases what exactly is the it you are referring to? It refers to: You almost want to have some kind of call to induce a reload from scratch of the multicast filter settings (along with whatever else might be necessary to alter the hardware type on the fly), to be called by bonding at the time the first slave is added (since slave adds happen in user context, and can therefore hold rtnl as required by most of the multicast address handling code). That seems less hassle than having to specify the hardware type and address length at module load time. Having this would eliminate the need to specify the hardware type at load time, and would allow changing of the hardware type at enslave time, rather than at device up time. This requires fewer changes to other things, like the initscripts or ifenslave. The ideal would be to allow changing of hardware type at literally any time, allowing failover across dissimilar hardware types. That's a lot more complicated, and has a smaller pool of potential uses. 1st, your current recommendation to solve the link layer address computation of multicast groups joined by the stack before any enslavement actually takes place, is to instrument the bonding code such that it would be possible to enslave devices when the bonding device is not up yet. 2nd, the change need to be worked out in the bonding sysfs code, the ifenslave program but ***also*** in packages such as /sbin/ifup and friends. Correct. The necessary changes to initscript and sysconfig are probably the most complex piece to organize (not necessarily the hardest to implement, but rather the most troublesome to deploy, as it introduces an API change). BTW - is the ifenslave program still supported to work with upstream (2.6.18 and above) kernel or it was obsoleted at some point. Yes, ifenslave is still supported. It probably will be obsoleted some day (or replaced with a script that uses sysfs), but not anytime soon. As far as I know, all current distros use ifenslave to configure bonding. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - 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] Fix for IPsec leakage with SELinux enabled - V.02
From: James Morris [EMAIL PROTECTED] Date: Mon, 2 Oct 2006 10:27:13 -0400 (EDT) Updated version of the patch, which return directly after a flow cache lookup error in xfrm_lookup rather than returing via the cleanup path (which was causing a spurious dst_release). This works for me, although I never saw the oops with the old patch. Evgeniy, let me know if this fixes the oops you're seeing. Signed-off-by: James Morris [EMAIL PROTECTED] As I review this patch I realize there is a question of semantics and prioritization here. For example, socket policies are handled such that if the security layer gives an error we behave as if the socket policy did not match. Whereas we handle sub vs. primary global policies differently. If we hit a sub-policy match, and we get a security layer error, we signal a full lookup failure instead of trying to see if there is a primary policy that the security layer likes. I'm not saying either is wrong, I'm just pointing it out to make sure this is intentional. The socket policy behavior deserves some scrutiny. I say this because if a matching socket policy is avoided due to security layer error, this could potentially make key manager problems very hard to diagnose. - 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: rewriting skb-truesize... good or bad idea
From: Vlad Yasevich [EMAIL PROTECTED] Date: Mon, 02 Oct 2006 10:46:42 -0400 David Miller wrote: If, on the other hand, you know you have exclusive access to the skb and there are no other references, setting skb-truesize can be OK. However setting it to sizeof(struct sk_buff) doesn't make sense since there is at least: sizeof(struct sk_buff) + sizeof(struct skb_shared_info) memory assosciated with any SKB whatsoever in the kernel. That is, even for a zero length skb-data buffer, we still always allocate the skb_shared_info area which must be accounted for. Well, since we are dealing with clones of the original skb, I didn't think that we need to include skb_shared_info. I thought that was accounted for in the original skb? We use the original packet's truesize, as-is, when making SKB clones. This is our global policy. The reason for that behavior is the usual case is that the clone is being attached to a different socket than the original SKB will. And we very much should charge the memory fully to every socket that references it. In your case it seems that the memory is already charged to the socket, and we would just be charging that memory again to the same socket. So in this very specific case, it should be OK not to include skb_shared_info in the truesize calculation. - 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 1/3][ATM]: kmalloc to kzalloc patches for drivers/atm
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Sun, 01 Oct 2006 11:17:05 -0400 [ATM]: kmalloc to kzalloc patches for drivers/atm Signed-off-by: Om Narasimhan [EMAIL PROTECTED] Signed-off-by: Chas Williams [EMAIL PROTECTED] Applied, thanks Chas. - 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 0/4]: Spidernet transmit patches
The following set of four patches provide some more spidernet fixes. Most important are a pair of patches to stop the transmit queue when it is full, and to actually turn off transmit interrupts during NAPI(!) Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] - 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 1/4]: Spidernet stop queue when queue is full
Subject: [PATCH 1/4]: Spidernet stop queue when queue is full.
This patch adds a call to netif_stop_queue() when there is
no more room for more packets on the transmit queue.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-10-02
12:12:56.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-10-02 18:59:43.0
-0500
@@ -686,6 +686,7 @@ spider_net_prepare_tx_descr(struct spide
/* Chain the bus address, so that the DMA engine finds this descr. */
descr-prev-next_descr_addr = descr-bus_addr;
+ card-netdev-trans_start = jiffies;
return 0;
}
@@ -857,29 +858,23 @@ spider_net_xmit(struct sk_buff *skb, str
spider_net_release_tx_chain(card, 0);
- if (chain-head-next == chain-tail-prev) {
- card-netdev_stats.tx_dropped++;
- result = NETDEV_TX_LOCKED;
- goto out;
- }
-
- if (spider_net_get_descr_status(descr) != SPIDER_NET_DESCR_NOT_IN_USE) {
- card-netdev_stats.tx_dropped++;
+ if ((chain-head-next == chain-tail-prev) ||
+ (spider_net_get_descr_status(descr) != SPIDER_NET_DESCR_NOT_IN_USE))
{
result = NETDEV_TX_LOCKED;
goto out;
}
if (spider_net_prepare_tx_descr(card, skb) != 0) {
- card-netdev_stats.tx_dropped++;
result = NETDEV_TX_BUSY;
goto out;
}
- result = NETDEV_TX_OK;
spider_net_kick_tx_dma(card);
+ return NETDEV_TX_OK;
out:
- netif_wake_queue(netdev);
+ card-netdev_stats.tx_dropped++;
+ netif_stop_queue(netdev);
return result;
}
@@ -898,6 +893,8 @@ spider_net_cleanup_tx_ring(struct spider
if ((spider_net_release_tx_chain(card, 0) != 0)
(card-netdev-flags IFF_UP))
spider_net_kick_tx_dma(card);
+
+ netif_wake_queue(card-netdev);
}
/**
-
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 3/4]: Spidernet transmit interupt mitigation
For small packets, the transmit interrupt settings were
accidentally generating too many interrupts. This patch
turns off all transmit-related interrupts when the tx
queue is mostly empty.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c |8 +---
drivers/net/spider_net.h |7 +++
2 files changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-10-02
19:06:55.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-10-02 19:09:38.0
-0500
@@ -707,7 +707,9 @@ spider_net_set_low_watermark(struct spid
descr = descr-next;
cnt++;
}
- if (cnt == 0)
+
+ /* If TX queue is short, don't even bother with interrupts */
+ if (cnt tx_descriptors/4)
return;
/* Set low-watermark 3/4th's of the way into the queue. */
@@ -716,7 +718,7 @@ spider_net_set_low_watermark(struct spid
for (i=0;icnt; i++)
descr = descr-next;
- /* Set the new watermark, clear the old wtermark */
+ /* Set the new watermark, clear the old watermark */
spin_lock_irqsave(card-tx_chain.lock, flags);
descr-dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
if (card-low_watermark card-low_watermark != descr)
@@ -1639,7 +1641,7 @@ spider_net_enable_card(struct spider_net
SPIDER_NET_INT2_MASK_VALUE);
spider_net_write_reg(card, SPIDER_NET_GDTDMACCNTR,
-SPIDER_NET_GDTBSTA);
+SPIDER_NET_GDTBSTA | SPIDER_NET_GDTDCEIDIS);
}
/**
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-10-02
19:06:55.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-10-02 19:09:38.0
-0500
@@ -217,7 +217,8 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_GDTBSTA 0x0300
#define SPIDER_NET_GDTDCEIDIS 0x0002
#define SPIDER_NET_DMA_TX_VALUESPIDER_NET_TX_DMA_EN | \
- SPIDER_NET_GDTBSTA
+ SPIDER_NET_GDTBSTA | \
+ SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
/* SPIDER_NET_UA_DESCR_VALUE is OR'ed with the unicast address */
@@ -326,9 +327,7 @@ enum spider_net_int2_status {
SPIDER_NET_GRISPDNGINT
};
-#define SPIDER_NET_TXINT ( (1 SPIDER_NET_GTTEDINT) | \
- (1 SPIDER_NET_GDTDCEINT) | \
- (1 SPIDER_NET_GDTFDCINT) )
+#define SPIDER_NET_TXINT ( (1 SPIDER_NET_GDTFDCINT) )
/* we rely on flagged descriptor interrupts*/
#define SPIDER_NET_RXINT ( (1 SPIDER_NET_GDAFDCINT) | \
-
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 2/4]: Spidernet fix register field definitions
This patch fixes the names of a few fields in the DMA control register. There is no functional change. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] drivers/net/spider_net.c |2 +- drivers/net/spider_net.h | 14 +- 2 files changed, 10 insertions(+), 6 deletions(-) Index: linux-2.6.18-mm2/drivers/net/spider_net.c === --- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-10-02 18:59:43.0 -0500 +++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-10-02 19:06:55.0 -0500 @@ -1639,7 +1639,7 @@ spider_net_enable_card(struct spider_net SPIDER_NET_INT2_MASK_VALUE); spider_net_write_reg(card, SPIDER_NET_GDTDMACCNTR, -SPIDER_NET_GDTDCEIDIS); +SPIDER_NET_GDTBSTA); } /** Index: linux-2.6.18-mm2/drivers/net/spider_net.h === --- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-10-02 18:58:11.0 -0500 +++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-10-02 19:06:55.0 -0500 @@ -191,7 +191,9 @@ extern char spider_net_driver_name[]; #define SPIDER_NET_MACMODE_VALUE 0x0001 #define SPIDER_NET_BURSTLMT_VALUE 0x0200 /* about 16 us */ -/* 1(0)enable r/tx dma +/* DMAC control register GDMACCNTR + * + * 1(0)enable r/tx dma * 000fixed to 0 * * 00 fixed to 0 @@ -200,6 +202,7 @@ extern char spider_net_driver_name[]; * * 00 fixed to 0 * 00burst alignment: 128 bytes + * 11burst alignment: 1024 bytes * * 0 fixed to 0 * 0 descr writeback size 32 bytes @@ -210,10 +213,11 @@ extern char spider_net_driver_name[]; #define SPIDER_NET_DMA_RX_VALUE0x8000 #define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003 /* to set TX_DMA_EN */ -#define SPIDER_NET_TX_DMA_EN 0x8000 -#define SPIDER_NET_GDTDCEIDIS 0x0300 -#define SPIDER_NET_DMA_TX_VALUESPIDER_NET_TX_DMA_EN | \ - SPIDER_NET_GDTDCEIDIS +#define SPIDER_NET_TX_DMA_EN 0x8000 +#define SPIDER_NET_GDTBSTA 0x0300 +#define SPIDER_NET_GDTDCEIDIS 0x0002 +#define SPIDER_NET_DMA_TX_VALUESPIDER_NET_TX_DMA_EN | \ + SPIDER_NET_GDTBSTA #define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003 /* SPIDER_NET_UA_DESCR_VALUE is OR'ed with the unicast address */ - 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 4/4]: Spidernet module parm permissions
The module param permsissions should bw read-only, not writable. Signed-off-by: James K Lewis [EMAIL PROTECTED] Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] drivers/net/spider_net.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.18-mm2/drivers/net/spider_net.c === --- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-10-02 19:09:38.0 -0500 +++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-10-02 19:14:48.0 -0500 @@ -60,8 +60,8 @@ MODULE_VERSION(VERSION); static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT; static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT; -module_param(rx_descriptors, int, 0644); -module_param(tx_descriptors, int, 0644); +module_param(rx_descriptors, int, 0444); +module_param(tx_descriptors, int, 0444); MODULE_PARM_DESC(rx_descriptors, number of descriptors used \ in rx chains); - 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 1/4]: Spidernet stop queue when queue is full
On Tuesday 03 October 2006 22:57, Linas Vepstas wrote:
+ if ((chain-head-next == chain-tail-prev) ||
+ (spider_net_get_descr_status(descr) !=
SPIDER_NET_DESCR_NOT_IN_USE)) {
result = NETDEV_TX_LOCKED;
goto out;
}
...
out:
- netif_wake_queue(netdev);
+ card-netdev_stats.tx_dropped++;
+ netif_stop_queue(netdev);
return result;
}
Hmm, this looks a little strange to me. I would assume that we should not
stop the queue when the device is locked, but only when it is busy.
I would assume though that the fix is to return NETDEV_TX_BUSY instead
of NETDEV_TX_LOCKED in the case above, while the netif_stop_queue()
is correct here.
Arnd
-
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] TIPC: fix printk warning
From: Jeff Garzik [EMAIL PROTECTED] Date: Sun, 1 Oct 2006 12:24:13 -0400 gcc spits out this warning: net/tipc/link.c: In function $,1rx(Blink_retransmit_failure$,1ry(B: net/tipc/link.c:1669: warning: cast from pointer to integer of different size More than a little bit ugly, storing integers in void*, but at least the code is correct, unlike some of the more crufty Linux kernel code found elsewhere. Rather than having two casts to massage the value into u32, it's easier just to have a single cast and use %lu, since it's just a printk. Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Applied, thanks Jeff. - 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/3][ATM]: [zatm] always *pcr in alloc_shaper()
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Sun, 01 Oct 2006 11:18:00 -0400 please consider for 2.6.18 -- thanks! [ATM]: [zatm] always *pcr in alloc_shaper() Signed-off-by: Chas Williams [EMAIL PROTECTED] Also applied, thanks a lot. - 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: [NET_SCHED]: Remove old estimator implementation
Good spotting Patrick, applied. - 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 2/3][ATM]: [ambassador] Change the return type to reflect reality
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Sun, 01 Oct 2006 11:17:43 -0400 please consider for 2.6.19 -- thanks! [ATM]: [ambassador] Change the return type to reflect reality Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Chas Williams [EMAIL PROTECTED] Applied. - 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] sky2: incorrect length on receive packets
The previous change to do fragmented receive (post 2.6.18) introduced a bug where packets are passed up with size set to the size of the receive buffer not the actual received data. IP silently trims this so it didn't show up right away. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/sky2.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- sky2.orig/drivers/net/sky2.c2006-10-03 16:35:09.0 -0700 +++ sky2/drivers/net/sky2.c 2006-10-03 16:35:23.0 -0700 @@ -1907,7 +1907,7 @@ pci_dma_sync_single_for_device(sky2-hw-pdev, re-data_addr, length, PCI_DMA_FROMDEVICE); re-skb-ip_summed = CHECKSUM_NONE; - __skb_put(skb, length); + skb_put(skb, length); } return skb; } @@ -1970,7 +1970,7 @@ if (skb_shinfo(skb)-nr_frags) skb_put_frags(skb, hdr_space, length); else - skb_put(skb, hdr_space); + skb_put(skb, length); return skb; } - 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 4/6] 2.6.18: sb1250-mac: The actual driver update
On Tue, 3 Oct 2006 16:18:44 +0100 (BST) Maciej W. Rozycki [EMAIL PROTECTED] wrote: + sbmac_state_t sbm_state; /* current state */ argh. The reader looks at this and doesn't know if it's an integer, a void*, a struct usb_ac_header_descriptor** or what. enum sbmac_statesmb_state; is nicer. It has information. - 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 4/6] 2.6.18: sb1250-mac: The actual driver update
On Tue, Oct 03, 2006 at 04:42:53PM -0700, Andrew Morton wrote: On Tue, 3 Oct 2006 16:18:44 +0100 (BST) Maciej W. Rozycki [EMAIL PROTECTED] wrote: + sbmac_state_t sbm_state; /* current state */ argh. The reader looks at this and doesn't know if it's an integer, a void*, a struct usb_ac_header_descriptor** or what. enum sbmac_statesmb_state; is nicer. It has information. De-typedef-ing would be a separate project for this driver which makes quite generous use of typedefs. Ralf - 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] Fix for IPsec leakage with SELinux enabled - V.02
On Tue, 3 Oct 2006, David Miller wrote: I'm not saying either is wrong, I'm just pointing it out to make sure this is intentional. The socket policy behavior deserves some scrutiny. I say this because if a matching socket policy is avoided due to security layer error, this could potentially make key manager problems very hard to diagnose. Yep, the code needs to be reworked in general (Venkat is doing this). - James -- James Morris [EMAIL PROTECTED] - 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] Add spinlocks to serialize ib_post_send/ib_post_recv
From: Tom Tucker [EMAIL PROTECTED]
The AMSO driver was not thread-safe in the post WR code and had
code that would sleep if the WR post FIFO was full. Since these
functions can be called on interrupt level I changed the sleep to a
udelay.
Signed-off-by: Tom Tucker [EMAIL PROTECTED]
---
drivers/infiniband/hw/amso1100/c2_qp.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_qp.c
b/drivers/infiniband/hw/amso1100/c2_qp.c
index 1226113..681c130 100644
--- a/drivers/infiniband/hw/amso1100/c2_qp.c
+++ b/drivers/infiniband/hw/amso1100/c2_qp.c
@@ -35,6 +35,7 @@
*
*/
+#include linux/delay.h
#include c2.h
#include c2_vq.h
#include c2_status.h
@@ -705,10 +706,8 @@ static inline void c2_activity(struct c2
* cannot get on the bus and the card and system hang in a
* deadlock -- thus the need for this code. [TOT]
*/
- while (readl(c2dev-regs + PCI_BAR0_ADAPTER_HINT) 0x8000) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(0);
- }
+ while (readl(c2dev-regs + PCI_BAR0_ADAPTER_HINT) 0x8000)
+ udelay(10);
__raw_writel(C2_HINT_MAKE(mq_index, shared),
c2dev-regs + PCI_BAR0_ADAPTER_HINT);
@@ -766,6 +765,7 @@ int c2_post_send(struct ib_qp *ibqp, str
struct c2_dev *c2dev = to_c2dev(ibqp-device);
struct c2_qp *qp = to_c2qp(ibqp);
union c2wr wr;
+ unsigned long lock_flags;
int err = 0;
u32 flags;
@@ -881,8 +881,10 @@ int c2_post_send(struct ib_qp *ibqp, str
/*
* Post the puppy!
*/
+ spin_lock_irqsave(qp-lock, lock_flags);
err = qp_wr_post(qp-sq_mq, wr, qp, msg_size);
if (err) {
+ spin_unlock_irqrestore(qp-lock, lock_flags);
break;
}
@@ -890,6 +892,7 @@ int c2_post_send(struct ib_qp *ibqp, str
* Enqueue mq index to activity FIFO.
*/
c2_activity(c2dev, qp-sq_mq.index, qp-sq_mq.hint_count);
+ spin_unlock_irqrestore(qp-lock, lock_flags);
ib_wr = ib_wr-next;
}
@@ -905,6 +908,7 @@ int c2_post_receive(struct ib_qp *ibqp,
struct c2_dev *c2dev = to_c2dev(ibqp-device);
struct c2_qp *qp = to_c2qp(ibqp);
union c2wr wr;
+ unsigned long lock_flags;
int err = 0;
if (qp-state IB_QPS_RTS)
@@ -945,8 +949,10 @@ int c2_post_receive(struct ib_qp *ibqp,
break;
}
+ spin_lock_irqsave(qp-lock, lock_flags);
err = qp_wr_post(qp-rq_mq, wr, qp, qp-rq_mq.msg_size);
if (err) {
+ spin_unlock_irqrestore(qp-lock, lock_flags);
break;
}
@@ -954,6 +960,7 @@ int c2_post_receive(struct ib_qp *ibqp,
* Enqueue mq index to activity FIFO
*/
c2_activity(c2dev, qp-rq_mq.index, qp-rq_mq.hint_count);
+ spin_unlock_irqrestore(qp-lock, lock_flags);
ib_wr = ib_wr-next;
}
-
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] Add spinlocks to serialize ib_post_send/ib_post_recv
Thanks, queued for 2.6.19 - 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][XFRM] Fixes for net-2.6
David Miller wrote: From: Masahide NAKAMURA [EMAIL PROTECTED] Date: Tue, 03 Oct 2006 12:29:54 +0900 [XFRM] POLICY: Fix per-direction policy counter after flushing. Currently when xfrm_policy_flush() is called per-direction policy counter is cleared. However flusing policy is performed for each type (i.e. main or sub) then it is not always true to make the counter zero. Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] The idea of this code is to avoid updating global state many many times during such a flush. This can be expensive and cause much SMP cacheline activity as other cpus read the counter in the routing lookup path. Thanks for the clarify. My patch should have included such cacheline consideration. I think what I'll do is reimplement this patch so that a local variable is used to maintain how many entries were removed, and then simply subtract that counter from xfrm_policy_count[dir] at the very end where the assignment to zero occurs. I feel it's better idea now. I agree to apply it instead of my patch. Regards, -- Masahide NAKAMURA - 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 1/1] secid reconcialiation: Replace unlabeled_t with the network_t
The following replaces unlabeled_t with network_t for better characterization of the flow out/in checks in SELinux, as well as to allow for mls packets to flow out/in from the network since network_t would allow the full range of MLS labels, as opposed to the unlabeled init sid that only allows system-hi. Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED] --- This is an incremental patch the secid-reconcilation v4 patchset. --- net-2.6.sid3/security/selinux/hooks.c 2006-10-01 15:43:12.0 -0500 +++ net-2.6/security/selinux/hooks.c2006-10-03 16:43:21.0 -0500 @@ -3703,7 +3703,8 @@ static int selinux_skb_flow_in(struct sk err = selinux_xfrm_decode_session(skb, xfrm_sid, 0); BUG_ON(err); - err = avc_has_perm(xfrm_sid, skb-secmark, SECCLASS_PACKET, + err = avc_has_perm(xfrm_sid, skb-secmark? : SECINITSID_NETMSG, + SECCLASS_PACKET, PACKET__FLOW_IN, NULL); if (err) goto out; @@ -3900,7 +3901,7 @@ static unsigned int selinux_ip_postroute skb-secmark = sksec-sid; } } - err = avc_has_perm(skb-secmark, SECINITSID_UNLABELED, + err = avc_has_perm(skb-secmark, SECINITSID_NETMSG, SECCLASS_PACKET, PACKET__FLOW_OUT, ad); } out: - 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: sky2 (was Re: 2.6.18-mm2)
Hello Stephen,
Am Donnerstag, den 28.09.2006, 16:19 -0700 schrieb Stephen Hemminger:
Here is the debug patch I sent to the first reporter of the problem.
I know what the offset is supposed to be, so if the PCI subsystem is
wrong, this will show.
--- sky2.orig/drivers/net/sky2.c 2006-09-28 08:45:27.0 -0700
+++ sky2/drivers/net/sky2.c 2006-09-28 08:51:24.0 -0700
@@ -2463,6 +2463,7 @@
sky2_write8(hw, B0_CTST, CS_MRST_CLR);
+#define PEX_UNC_ERR_STAT 0x104 /* PCI extended error capablity
*/
/* clear any PEX errors */
if (pci_find_capability(hw-pdev, PCI_CAP_ID_EXP)) {
hw-err_cap = pci_find_ext_capability(hw-pdev,
PCI_EXT_CAP_ID_ERR);
@@ -2470,6 +2471,15 @@
sky2_pci_write32(hw,
hw-err_cap + PCI_ERR_UNCOR_STATUS,
0xUL);
+ else
+ printk(KERN_ERR PFX pci express found but not extended
error support?\n);
+
+ if (hw-err_cap + PCI_ERR_UNCOR_STATUS != PEX_UNC_ERR_STAT) {
+
+ printk(KERN_ERR PFX pci express error status register
fixed from %#x to %#x\n,
+hw-err_cap, PEX_UNC_ERR_STAT -
PCI_ERR_UNCOR_STATUS);
+ hw-err_cap = PEX_UNC_ERR_STAT - PCI_ERR_UNCOR_STATUS;
+ }
}
hw-pmd_type = sky2_read8(hw, B2_PMD_TYP);
while the above patch indeed removes the error messages from my previous
mail, I have since seen random but reproduceable freezes of the box in
question. I believe they are sky2 related since the freeze can be
triggered by continuous network traffic (like playing a movie over NFS
etc.).
The freezes only happen with 2.6.18-mm2 and 2.6.18-mm3. 2.6.18-mm1 works
perfectly fine.
I've hooked up the box to my laptop via a serial cable and captured all
kernel messages from booting up the machine to the freeze. You'll note
that the last messages are from the sky2 driver ;)
Once frozen the network is dead, the screen won't wake up from suspend
and CAPSLOCK can not be toggled. SYSRQ (sp?) still works tho.
Any help in debugging this problem would be appreciated =)
--
Matthias 'CoreDump' Hentges
My OS: Debian SID. Geek by Nature, Linux by Choice
p5w-freeze_2.6.18-mm3.cap.gz
Description: GNU Zip compressed data
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[PATCH] ieee80211: Drop and count duplicate data frames to remove 'replay detected' log messages
In the SoftMAC version of the IEEE 802.11 stack, not all duplicate messages are
detected. For the most part, there is no difficulty; however ifor TKIP and CCMP
encryption, the duplicates result in a replay detected log message where the
received and previous values of the TSC are identical. This change adds a new
variable to the ieee80211_device structure that holds the 'seq_ctl' value for
the previous frame. When a new frame repeats the value, the frame is dropped and
the appropriate counter is incremented.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch replaces the one that I originally sent on 9/25. This version logs
the
dropped packets, which addresses the objections to the previous one.
Larry
Index: wireless-2.6/net/ieee80211/ieee80211_rx.c
===
--- wireless-2.6.orig/net/ieee80211/ieee80211_rx.c
+++ wireless-2.6/net/ieee80211/ieee80211_rx.c
@@ -479,6 +479,11 @@ int ieee80211_rx(struct ieee80211_device
goto rx_exit;
}
#endif
+ /* drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.29) */
+ if (sc == ieee-prev_seq_ctl)
+ goto rx_dropped;
+ else
+ ieee-prev_seq_ctl = sc;
/* Data frame - extract src/dst addresses */
if (skb-len IEEE80211_3ADDR_LEN)
Index: wireless-2.6/include/net/ieee80211.h
===
--- wireless-2.6.orig/include/net/ieee80211.h
+++ wireless-2.6/include/net/ieee80211.h
@@ -1076,6 +1076,8 @@ struct ieee80211_device {
int perfect_rssi;
int worst_rssi;
+ u16 prev_seq_ctl; /* used to drop duplicate frames */
+
/* Callback functions */
void (*set_security) (struct net_device * dev,
struct ieee80211_security * sec);
-
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: sky2 (was Re: 2.6.18-mm2)
On Wed, 04 Oct 2006 04:57:08 +0200
Matthias Hentges [EMAIL PROTECTED] wrote:
Hello Stephen,
Am Donnerstag, den 28.09.2006, 16:19 -0700 schrieb Stephen Hemminger:
Here is the debug patch I sent to the first reporter of the problem.
I know what the offset is supposed to be, so if the PCI subsystem is
wrong, this will show.
--- sky2.orig/drivers/net/sky2.c2006-09-28 08:45:27.0 -0700
+++ sky2/drivers/net/sky2.c 2006-09-28 08:51:24.0 -0700
@@ -2463,6 +2463,7 @@
sky2_write8(hw, B0_CTST, CS_MRST_CLR);
+#define PEX_UNC_ERR_STAT 0x104 /* PCI extended error capablity
*/
/* clear any PEX errors */
if (pci_find_capability(hw-pdev, PCI_CAP_ID_EXP)) {
hw-err_cap = pci_find_ext_capability(hw-pdev,
PCI_EXT_CAP_ID_ERR);
@@ -2470,6 +2471,15 @@
sky2_pci_write32(hw,
hw-err_cap + PCI_ERR_UNCOR_STATUS,
0xUL);
+ else
+ printk(KERN_ERR PFX pci express found but not extended
error support?\n);
+
+ if (hw-err_cap + PCI_ERR_UNCOR_STATUS != PEX_UNC_ERR_STAT) {
+
+ printk(KERN_ERR PFX pci express error status register
fixed from %#x to %#x\n,
+ hw-err_cap, PEX_UNC_ERR_STAT -
PCI_ERR_UNCOR_STATUS);
+ hw-err_cap = PEX_UNC_ERR_STAT - PCI_ERR_UNCOR_STATUS;
+ }
}
hw-pmd_type = sky2_read8(hw, B2_PMD_TYP);
while the above patch indeed removes the error messages from my previous
mail, I have since seen random but reproduceable freezes of the box in
question. I believe they are sky2 related since the freeze can be
triggered by continuous network traffic (like playing a movie over NFS
etc.).
When it fixes what does the log say. I'm probably going to back out
the PCI express extended error using the pci_XXX functions.
The freezes only happen with 2.6.18-mm2 and 2.6.18-mm3. 2.6.18-mm1 works
perfectly fine.
I've hooked up the box to my laptop via a serial cable and captured all
kernel messages from booting up the machine to the freeze. You'll note
that the last messages are from the sky2 driver ;)
Does it still happen with linus git tree. If so, a git bisect might
help. It might not be sky2 related at all, there has been lots of changes.
Once frozen the network is dead, the screen won't wake up from suspend
and CAPSLOCK can not be toggled. SYSRQ (sp?) still works tho.
Any help in debugging this problem would be appreciated =)
The TX timeout is a symptom of a common bug still not fixed where
the transmitter stops. I'm working on reproducing it on my hardware and
switches,
because without a reproducible test, its just shooting in the dark and
that isn't working.
-
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: [take19 0/4] kevent: Generic event handling mechanism.
On 9/27/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: \ I have been told in private what is signal masks about - just to wait until either signal or given condition is ready, but in that case just add additional kevent user like AIO complete or netwrok notification and wait until either requested events are ready or signal is triggered. No, this won't work. Yes, I want signal notification as part of the event handling. But there are situations when this is not suitable. Only if the signal is expected in the same code using the event handling can you do this. But this is not always possible. Especially when the signal handling code is used in other parts of the code than the event handling. E.g., signal handling in a library, event handling in the main code. You cannot assume that all the code is completely integrated. - 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: [take19 0/4] kevent: Generic event handling mechanism.
On Tue, Oct 03, 2006 at 09:50:09PM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: On 9/27/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: \ I have been told in private what is signal masks about - just to wait until either signal or given condition is ready, but in that case just add additional kevent user like AIO complete or netwrok notification and wait until either requested events are ready or signal is triggered. No, this won't work. Yes, I want signal notification as part of the event handling. But there are situations when this is not suitable. Only if the signal is expected in the same code using the event handling can you do this. But this is not always possible. Especially when the signal handling code is used in other parts of the code than the event handling. E.g., signal handling in a library, event handling in the main code. You cannot assume that all the code is completely integrated. Signals still can be delivered in usual way too. When we enter sys_ppoll() we specify needed signals as syscall parameter, with kevents we will add them into the queue. -- Evgeniy Polyakov - 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] Fix for IPsec leakage with SELinux enabled - V.02
On Mon, Oct 02, 2006 at 12:41:57PM -0400, James Morris ([EMAIL PROTECTED])
wrote:
You can get recent policy packages via the devel repo, which I'd suggest
if you're using development (or DIY) kernels.
[EMAIL PROTECTED] ~]# uname -a
Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.3.17-2
I get only this messages in audit.log when remote racoon tries to
connect to system with selinux enabled in enforcing mode:
type=AVC msg=audit(1159938297.845:625): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
type=AVC msg=audit(1159938297.845:626): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938307.837:627): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938317.838:628): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
type=AVC msg=audit(1159938327.839:629): avc: denied { polmatch } for
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=association
It is with your patch applied.
Should I try Venkat's or it is unrelated problem?
--
James Morris
[EMAIL PROTECTED]
--
Evgeniy Polyakov
-
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
