Re: [patch 04/11] drivers/net/acenic.c Removal of old code
akpm == akpm [EMAIL PROTECTED] writes:
akpm From: Michal Piotrowski [EMAIL PROTECTED]
akpm Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]
akpm Cc: Jeff Garzik [EMAIL PROTECTED]
akpm Cc: Jes Sorensen [EMAIL PROTECTED]
akpm Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
akpm drivers/net/acenic.c | 4 1 file changed, 4 deletions(-)
akpm diff -puN
akpm drivers/net/acenic.c~drivers-net-acenicc-removal-of-old-code
akpm drivers/net/acenic.c ---
akpm a/drivers/net/acenic.c~drivers-net-acenicc-removal-of-old-code +++
akpm a/drivers/net/acenic.c @@ -163,11 +163,7 @@
akpm MODULE_DEVICE_TABLE(pci, acenic_pci_tbl) #define
akpm SET_NETDEV_DEV(net, pdev) do{} while(0) #endif
akpm -#if LINUX_VERSION_CODE = 0x2051c #define ace_sync_irq(irq)
akpm synchronize_irq(irq) -#else -#define ace_sync_irq(irq)
akpm synchronize_irq() -#endif
akpm #ifndef offset_in_page #define offset_in_page(ptr) ((unsigned
akpm long)(ptr) ~PAGE_MASK) _
-
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] neighbour.c, pneigh_get_next() skips published entry
David Miller wrote: I've been sitting on this patch because afaik the problem which it purports to fix remains unfixed. Should I drop it?? Thanks. Please drop it, the patch submitted didn't give us the feedback and test results we asked for which is necessary to pinpoint the true issue here. It is faster to reproduce with a smaller block size. I haven't looked in detail to find the cause, but I did notice that neigh_seq_start() does a pos_minus_one adjustment, and neigh_seq_next() does not. First, with only one entry, both block sizes work: # dd if=/proc/net/arp bs=1024 IP address HW type Flags HW addressMask Device 10.46.1.10x1 0x2 00:04:23:C8:8D:E9 *eth0 0+1 records in 0+1 records out 156 bytes (156 B) copied, 0.000161 seconds, 969 kB/s # dd if=/proc/net/arp bs=128 IP address HW type Flags HW addressMask Device 10.46.1.10x1 0x2 00:04:23:C8:8D:E9 *eth0 1+1 records in 1+1 records out 156 bytes (156 B) copied, 0.000193 seconds, 808 kB/s But add another entry, and it is lost with bs=128: # arp -Ds 1.1.1.1 eth1 pub # dd if=/proc/net/arp bs=1024 IP address HW type Flags HW addressMask Device 10.46.1.10x1 0x2 00:04:23:C8:8D:E9 *eth0 1.1.1.1 0x1 0xc 00:00:00:00:00:00 *eth1 0+1 records in 0+1 records out 233 bytes (233 B) copied, 2.6e-05 seconds, 9.0 MB/s # dd if=/proc/net/arp bs=128 IP address HW type Flags HW addressMask Device 10.46.1.10x1 0x2 00:04:23:C8:8D:E9 *eth0 1+1 records in 1+1 records out 156 bytes (156 B) copied, 7.9e-05 seconds, 2.0 MB/s Add more entries, but still only one is lost: # arp -Ds 1.1.1.2 eth1 pub # arp -Ds 1.1.1.3 eth1 pub # arp -Ds 1.1.1.4 eth1 pub # arp -Ds 1.1.1.5 eth1 pub # dd if=/proc/net/arp bs=128 IP address HW type Flags HW addressMask Device 10.46.1.10x1 0x2 00:04:23:C8:8D:E9 *eth0 1.1.1.3 0x1 0xc 00:00:00:00:00:00 *eth1 1.1.1.2 0x1 0xc 00:00:00:00:00:00 *eth1 1.1.1.5 0x1 0xc 00:00:00:00:00:00 *eth1 1.1.1.4 0x1 0xc 00:00:00:00:00:00 *eth1 3+1 records in 3+1 records out 464 bytes (464 B) copied, 3.6e-05 seconds, 12.9 MB/s - 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] netdev config: revert part of previous patch
From: Randy.Dunlap [EMAIL PROTECTED] Date: Fri, 22 Sep 2006 12:56:25 -0700 From: Randy Dunlap [EMAIL PROTECTED] Net devices should depend on NETDEVICES, so revert part of Paolo's previous patch. See http://marc.theaimsgroup.com/?l=linux-kernelm=115566326218740w=2 for history. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Applied, thanks Randy. - 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] Advertise PPPoE MTU / avoid memory leak.
Speaking of PPPoE and MTU, does Linux support recently-published RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) On Sat, 23 Sep 2006, [EMAIL PROTECTED] wrote: PPPoE must advertise the underlying device's MTU via the ppp channel descriptor structure, as multilink functionality depends on it. __pppoe_xmit must free any skb it allocates if there is an error submitting the skb downstream. Signed-off-by: Michal Ostrowski [EMAIL PROTECTED] --- drivers/net/pppoe.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c index 475dc93..b4dc516 100644 --- a/drivers/net/pppoe.c +++ b/drivers/net/pppoe.c @@ -600,6 +600,7 @@ static int pppoe_connect(struct socket * po-chan.hdrlen = (sizeof(struct pppoe_hdr) + dev-hard_header_len); + po-chan.mtu = dev-mtu - sizeof(struct pppoe_hdr); po-chan.private = sk; po-chan.ops = pppoe_chan_ops; @@ -831,7 +832,7 @@ static int __pppoe_xmit(struct sock *sk, struct pppoe_hdr *ph; int headroom = skb_headroom(skb); int data_len = skb-len; - struct sk_buff *skb2; + struct sk_buff *skb2 = NULL; if (sock_flag(sk, SOCK_DEAD) || !(sk-sk_state PPPOX_CONNECTED)) goto abort; @@ -887,6 +888,8 @@ static int __pppoe_xmit(struct sock *sk, return 1; abort: + if (skb2) + kfree_skb(skb2); return 0; } -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - 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 cut/paste error in TCPPROBE
From: Grant Grundler [EMAIL PROTECTED] Date: Fri, 22 Sep 2006 08:47:10 -0600 Fix cut/paste error in TCPPROBE help text. Signed-off-by: Grant Grundler [EMAIL PROTECTED] Applied, thanks Grant. - 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] genetlink custom attribute type
This patch adds an NLA_CUSTOM_CHECK type for netlink attributes
in order to be able to centrally define new attribute structures
instead of having to check these special types in each function
that uses such an attribute.
nl80211 will benefit from this because it needs an information
element attribute with a fixed type|length|value structure defined
in IEEE 802.11 which ought to be checked when passing an IE from
userspace.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/include/net/netlink.h 2006-09-13 22:06:09.979647141
+0200
+++ wireless-dev/include/net/netlink.h 2006-09-13 22:06:11.329647141 +0200
@@ -159,6 +159,7 @@ enum {
NLA_MSECS,
NLA_NESTED,
NLA_NUL_STRING,
+ NLA_CUSTOM_CHECK,
__NLA_TYPE_MAX,
};
@@ -176,6 +177,8 @@ enum {
*NLA_STRING Maximum length of string
*NLA_NUL_STRING Maximum length of string (excluding NUL)
*NLA_FLAG Unused
+ *NLA_CUSTOM_CHECK Unused, check function must be assigned,
+ * it must return 0 if the attribute is valid
*All otherExact length of attribute payload
*
* Example:
@@ -183,11 +186,13 @@ enum {
* [ATTR_FOO] = { .type = NLA_U16 },
* [ATTR_BAR] = { .type = NLA_STRING, len = BARSIZ },
* [ATTR_BAZ] = { .len = sizeof(struct mystruct) },
+ * [ATTR_CST] = { .type = NLA_CUSTOM_CHECK, .check = my_check },
* };
*/
struct nla_policy {
u16 type;
u16 len;
+ int (*check)(struct nlattr *nla);
};
extern voidnetlink_run_queue(struct sock *sk, unsigned int *qlen,
--- wireless-dev.orig/net/netlink/attr.c2006-09-13 22:06:05.889647141
+0200
+++ wireless-dev/net/netlink/attr.c 2006-09-13 22:06:11.329647141 +0200
@@ -67,6 +67,9 @@ static int validate_nla(struct nlattr *n
}
break;
+ case NLA_CUSTOM_CHECK:
+ BUG_ON(!pt-check);
+ return pt-check(nla);
default:
if (pt-len)
minlen = pt-len;
-
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] Add netpoll/netconsole support to vlan devices
On 26/09/06, David Miller [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Date: Mon, 25 Sep 2006 16:43:10 -0700 +#ifdef CONFIG_NET_POLL_CONTROLLER + new_dev-poll_controller = real_dev-poll_controller; +#endif + I don't see how this part can be correct. If netpoll actually calls new_dev-poll_controller it will pass new_dev in (ie. the VLAN device) yet this method is for real_dev. If the only side effect of this assignment is that netpoll recognizes the device as being usable with netpoll, that's really a nasty way to accomplish that. It was the only way I could find to accomplish that. If you know of a better way I'd appreciate a hint :) In any event, propagating this method pointer to the wrong device structure is a bug. Ok, then the patch as it stands is dead. I'll try to find another way. Thank you for your comments. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs
On Mon, 2006-09-25 at 10:49 -0500, Larry Finger wrote: When using TKIP and CCMP for wireless encryption with ieee80211, the logs get filled with useless replay messages where the previous and received TSC are identical. This change deletes the log message for this case, but still prints the message when there are major differences in the TSC's. Hey, that seems like a good idea to get rid of the messages no one wants to see (in the retransmit case) but still warn if someone is really messing with it. Acked-by: Johannes Berg [EMAIL PROTECTED] johannes - 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
[RFC][PATCH 0/3] bonding support for operation over IPoIB
This patch series is an RFC for changes to the bonding driver such that it would be able to support non ARPHRD_ETHER netdevices for its High-Availability (active-backup) mode. My motivation was to enable the bonding driver on its HA mode to work with the IP over Infiniband (IPoIB) driver. With these patches I was able to enslave IPoIB netdevices and run TCP, UDP, IP (UDP) Multicast and ICMP traffic with fail-over and fail-back working fine. More over, as IPoIB is also the IB ARP provider for the RDMA CM driver which is used by native IB ULPs whose addressing scheme is based on IP (eg iSER, SDP, Lustre, NFSoRDMA, RDS), bonding support for IPoIB devices **enables** HA for these ULPs. This holds as when the ULP is informed by the IB HW on the failure of the currect IB connection, it just need to reconnect, where the bonding device will now issue the IB ARP over the active IPoIB slave. The first patch changes some of the bond netdevice attributes and functions to be that of the active slave for the case of the enslaved device not being of ARPHRD_ETHER type. Basically it overrides those setting done by ether_setup(), which are netdevice **type** dependent and hence might be not appropriate for devices of other types. IPoIB (see Documentation/infiniband/ipoib.txt) MAC address is made of a 3 bytes IB QP (Queue Pair) number and 16 bytes IB port GID (Global ID) of the port this IPoIB device is bounded to. The QP is a resource created by the IB HW and the GID is an identifier burned into the HCA (i have ommited here some details which are not important for the bonding RFC). Basically the IPoIB spec and impl. do not allow for setting the MAC address of an IPoIB device and my work was made under this assumption. The second patch allows for enslaving netdevices which do not support the set_mac_address() function. In that case the bond mac address is the one of the active slave, where remote peers are notified on the mac address (neighbour) change by Gratuitous ARP sent by the bonding code when fail-over occurs (this was already in the bonding code). The third patch is temporal i hope, and is now required to run IP multicast when bonding IPoIB devices. The problem is that some multicast groups (eg the all-hosts 224.0.0.1) might be set to the bonding device by the net stack **before** any enslavement takes place. Since ether_setup() sets the bonding device type to be ARPHRD_ETHER and address len to be ETHER_ALEN, the net core code computes a wrong multicast link address. Now, the current IPoIB impl. attempts to join on this wrong mcast address and does not process more join requests. As a result IP multicast over other groups whose link address is computed correct would not work. Or Gerlitz. - 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: Bluetooth update for 2.6
Hi Dave, here are the pending patches that didn't make it into the 2.6.18 kernel release. I have some additional fixes, but all of them need some more additional testing from my side. it seems that you haven't pulled in these changes so far. So I didn't rebase the tree and simply pushed some additional ones on top of it. All three of them address the issues we had with non-blocking connects. Regards Marcel Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git This will update the following files: include/net/bluetooth/hci.h |6 ++ include/net/bluetooth/hci_core.h | 12 +--- net/bluetooth/af_bluetooth.c |2 +- net/bluetooth/hci_conn.c | 31 +++ net/bluetooth/hci_core.c |3 +++ net/bluetooth/hci_event.c| 25 - net/bluetooth/hci_sysfs.c| 24 net/bluetooth/rfcomm/core.c |2 +- 8 files changed, 95 insertions(+), 10 deletions(-) through these ChangeSets: Marcel Holtmann [EMAIL PROTECTED] Tue, 26 Sep 2006 09:43:48 +0200 [Bluetooth] Support create connection cancel command In case of non-blocking connects it is possible that the last user of an ACL link quits before the connection has been fully established. This will lead to a race condition where the internal state of a connection is closed, but the actual link has been established and is active. In case of Bluetooth 1.2 and later devices it is possible to call create connection cancel to abort the connect. For older devices the disconnect timer will be used to trigger the needed disconnect. Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Marcel Holtmann [EMAIL PROTECTED] Sat, 23 Sep 2006 09:57:20 +0200 [Bluetooth] Read local version information on device init The local version information are needed to identify certain feature sets of devices. They must be read on device init and stored for later use. It is also possible to access them through the device model. Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Marcel Holtmann [EMAIL PROTECTED] Sat, 23 Sep 2006 09:54:38 +0200 [Bluetooth] Return EINPROGRESS for non-blocking socket calls In case of non-blocking socket calls we should return EINPROGRESS and not EAGAIN. Signed-off-by: Ulisses Furquim [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [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] genetlink custom attribute type
On Tue, 2006-09-26 at 11:44 +0200, Thomas Graf wrote: Thinking it over I'm still not completely happy with this. A small subset of all the validation tasks is simply too complex to be put into the policy. The validation of your type value array is such a case, address fields with variable length based on their family is another. I think it's just not worth to blow up struct nla_policy by 12 bytes per entry just to save some code. Alright, I can instead just add the validation function call wherever that attribute is going to be used. Just thought it might be nice to have this generically, I'm not really too attached to it :) I'll change it in the next nl80211 iteration. johannes - 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
[RFC][PATCH 2/3] enable bonding to enslave netdevices not supporting set_mac_address()
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: net-2.6.19/drivers/net/bonding/bond_main.c
===
--- net-2.6.19.orig/drivers/net/bonding/bond_main.c 2006-09-25
11:43:52.0 +0300
+++ net-2.6.19/drivers/net/bonding/bond_main.c 2006-09-25 11:46:35.0
+0300
@@ -1115,7 +1115,14 @@ void bond_change_active_slave(struct bon
*/
if (new_active new_active-dev-type != ARPHRD_ETHER)
bond_setup_by_slave(bond, new_active);
-
+
+ /* when bonding does not set the slave MAC address, the bond MAC
+* address is the one of the active slave.
+*/
+ if (new_active !bond-do_set_mac_addr)
+ memcpy(bond-dev-dev_addr, new_active-dev-dev_addr,
+ new_active-dev-addr_len);
+
bond_send_gratuitous_arp(bond);
}
}
@@ -1335,14 +1342,23 @@ int bond_enslave(struct net_device *bond
}
if (slave_dev-set_mac_address == NULL) {
- printk(KERN_ERR DRV_NAME
- : %s: Error: The slave device you specified does
- not support setting the MAC address.
- Your kernel likely does not support slave
- devices.\n, bond_dev-name);
- res = -EOPNOTSUPP;
- goto err_undo_flags;
- }
+ if (bond-slave_cnt == 0) {
+ printk(KERN_WARNING DRV_NAME
+ : %s: Warning: The first slave device you
+ specified does not support setting the MAC
+ address. This bond MAC address would be that
+ of the active slave.\n, bond_dev-name);
+ bond-do_set_mac_addr = 0;
+ } else if (bond-do_set_mac_addr) {
+ printk(KERN_ERR DRV_NAME
+ : %s: Error: The slave device you specified
+ does not support setting the MAC addres,.
+ but this bond uses this practice. \n
+ , bond_dev-name);
+ res = -EOPNOTSUPP;
+ goto err_undo_flags;
+ }
+ }
new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL);
if (!new_slave) {
@@ -1364,16 +1380,18 @@ int bond_enslave(struct net_device *bond
*/
memcpy(new_slave-perm_hwaddr, slave_dev-dev_addr, ETH_ALEN);
- /*
-* Set slave to master's mac address. The application already
-* set the master's mac address to that of the first slave
-*/
- memcpy(addr.sa_data, bond_dev-dev_addr, bond_dev-addr_len);
- addr.sa_family = slave_dev-type;
- res = dev_set_mac_address(slave_dev, addr);
- if (res) {
- dprintk(Error %d calling set_mac_address\n, res);
- goto err_free;
+ if (bond-do_set_mac_addr) {
+ /*
+* Set slave to master's mac address. The application already
+* set the master's mac address to that of the first slave
+*/
+ memcpy(addr.sa_data, bond_dev-dev_addr, bond_dev-addr_len);
+ addr.sa_family = slave_dev-type;
+ res = dev_set_mac_address(slave_dev, addr);
+ if (res) {
+ dprintk(Error %d calling set_mac_address\n, res);
+ goto err_free;
+ }
}
/* open the slave since the application closed it */
@@ -1617,9 +1635,11 @@ err_close:
dev_close(slave_dev);
err_restore_mac:
- memcpy(addr.sa_data, new_slave-perm_hwaddr, ETH_ALEN);
- addr.sa_family = slave_dev-type;
- dev_set_mac_address(slave_dev, addr);
+ if (bond-do_set_mac_addr) {
+ memcpy(addr.sa_data, new_slave-perm_hwaddr, ETH_ALEN);
+ addr.sa_family = slave_dev-type;
+ dev_set_mac_address(slave_dev, addr);
+ }
err_free:
kfree(new_slave);
@@ -1797,10 +1817,12 @@ int bond_release(struct net_device *bond
/* close slave before restoring its mac address */
dev_close(slave_dev);
- /* restore original (permanent) mac address */
- memcpy(addr.sa_data, slave-perm_hwaddr, ETH_ALEN);
- addr.sa_family = slave_dev-type;
- dev_set_mac_address(slave_dev, addr);
+ if (bond-do_set_mac_addr) {
+ /* restore original (permanent) mac address */
+ memcpy(addr.sa_data, slave-perm_hwaddr, ETH_ALEN);
+ addr.sa_family = slave_dev-type;
+ dev_set_mac_address(slave_dev, addr);
+ }
slave_dev-priv_flags = ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
IFF_SLAVE_INACTIVE);
@@ -1886,10
[RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
Signed-off-by: Or Gerlitz [EMAIL PROTECTED] Index: net-2.6.19/drivers/net/bonding/bond_main.c === --- net-2.6.19.orig/drivers/net/bonding/bond_main.c 2006-09-25 11:46:35.0 +0300 +++ net-2.6.19/drivers/net/bonding/bond_main.c 2006-09-26 10:54:44.0 +0300 @@ -128,6 +128,12 @@ MODULE_PARM_DESC(arp_interval, arp inte module_param_array(arp_ip_target, charp, NULL, 0); MODULE_PARM_DESC(arp_ip_target, arp targets in n.n.n.n form); +static int bonding_dev_type= ARPHRD_ETHER; +static int bonding_dev_addrlen = ETH_ALEN; + +module_param(bonding_dev_type,int, 0644); +module_param(bonding_dev_addrlen, int, 0644); + /*- Global variables */ static const char * const version = @@ -4606,7 +4612,14 @@ int bond_create(char *name, struct bond_ res = -ENOMEM; goto out_rtnl; } - + + /* XXX set the bond dev type and addr len such that the net core code + * (eg arp_mc_map() in net/ipv4/arp.c) would correctly process multicast + * groups set ***before*** the first enslaveness + */ + bond_dev-type = bonding_dev_type; + bond_dev-addr_len = bonding_dev_addrlen; + /* bond_init() must be called after dev_alloc_name() (for the * /proc files), but before register_netdevice(), because we * need to set function pointers. - 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
[RFC][PATCH 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: net-2.6.19/drivers/net/bonding/bond_main.c
===
--- net-2.6.19.orig/drivers/net/bonding/bond_main.c 2006-09-20
14:40:13.0 +0300
+++ net-2.6.19/drivers/net/bonding/bond_main.c 2006-09-25 11:43:52.0
+0300
@@ -1013,6 +1013,23 @@ static struct slave *bond_find_best_slav
return bestslave;
}
+void bond_setup_by_slave(struct bonding *bond, struct slave *new_active)
+{
+ bond-dev-hard_header = new_active-dev-hard_header;
+ bond-dev-rebuild_header = new_active-dev-rebuild_header;
+ bond-dev-hard_header_cache= new_active-dev-hard_header_cache;
+ bond-dev-header_cache_update = new_active-dev-header_cache_update;
+ bond-dev-hard_header_parse= new_active-dev-hard_header_parse;
+
+ bond-dev-type = new_active-dev-type;
+ bond-dev-hard_header_len = new_active-dev-hard_header_len;
+ bond-dev-mtu = new_active-dev-mtu;
+ bond-dev-addr_len = new_active-dev-addr_len;
+
+ memcpy(bond-dev-broadcast, new_active-dev-broadcast,
+ new_active-dev-addr_len);
+}
+
/**
* change_active_interface - change the active slave into the specified one
* @bond: our bonding struct
@@ -1091,6 +1108,14 @@ void bond_change_active_slave(struct bon
if (new_active) {
bond_set_slave_active_flags(new_active);
}
+
+ /* bonding netdevices are created with ether_setup, so when the
+* slave type is not ARPHRD_ETHER there is a need to override
+* some of the type dependent attributes/functions
+*/
+ if (new_active new_active-dev-type != ARPHRD_ETHER)
+ bond_setup_by_slave(bond, new_active);
+
bond_send_gratuitous_arp(bond);
}
}
-
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] genetlink custom attribute type
* Johannes Berg [EMAIL PROTECTED] 2006-09-26 09:25 This patch adds an NLA_CUSTOM_CHECK type for netlink attributes in order to be able to centrally define new attribute structures instead of having to check these special types in each function that uses such an attribute. Thinking it over I'm still not completely happy with this. A small subset of all the validation tasks is simply too complex to be put into the policy. The validation of your type value array is such a case, address fields with variable length based on their family is another. I think it's just not worth to blow up struct nla_policy by 12 bytes per entry just to save some code. - 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
[PKT_SCHED] cls_basic: Use unsigned int when generating handle
Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund [EMAIL PROTECTED]
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/sched/cls_basic.c
===
--- net-2.6.orig/net/sched/cls_basic.c 2006-09-26 13:35:29.0 +0200
+++ net-2.6/net/sched/cls_basic.c 2006-09-26 13:35:39.0 +0200
@@ -194,7 +194,7 @@
if (handle)
f-handle = handle;
else {
- int i = 0x8000;
+ unsigned int i = 0x8000;
do {
if (++head-hgenerator == 0x7FFF)
head-hgenerator = 1;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
Hi, On Mon, Sep 25, 2006 at 10:15:30PM +1000, Herbert Xu wrote: On Fri, Sep 01, 2006 at 06:22:48PM +0200, cagri coltekin wrote: The second causes the system to give the bug a couple of seconds after bind starts, and loads the zones, without any traffic going on. BTW, patch applied with some offset difference (3 for the first -48 for the other two changes), on a pristine 2.6.17.11 source tree. Well the good news is that I found a bug with MSG_PROBE that can cause exactly what you're seeing. The bad news is that bind doesn't use MSG_PROBE :) So please try this patch to narrow the problem down further. This time I applied patch to 2.6.18. The patch applied with some offset difference. I can stick to a version you suggest if 2.6.18 is not a good. Here is the new bug message: -- [ 1395.890897] [ cut here ] [ 1395.946093] kernel BUG at net/ipv6/ip6_output.c:940! [ 1396.005441] invalid opcode: [#1] [ 1396.049225] SMP [ 1396.071419] Modules linked in: ipmi_si ipmi_msghandler ide_cd cdrom [ 1396.146853] CPU:2 [ 1396.146854] EIP:0060:[c02c6148]Not tainted VLI [ 1396.146855] EFLAGS: 00010246 (2.6.18-ns-pri-debug-p3 #2) [ 1396.304174] EIP is at ip6_append_data+0xaf8/0xbd6 [ 1396.360405] eax: f7534d00 ebx: ecx: f7534e9c edx: f68f4480 [ 1396.441552] esi: f7534ee4 edi: f7534ee4 ebp: f7534ef0 esp: f742bc20 [ 1396.522691] ds: 007b es: 007b ss: 0068 [ 1396.571655] Process named (pid: 1897, ti=f742a000 task=c2b2c030 task.ti=f742) [ 1396.659026] Stack: f68f4480 c03c3cb4 f742bf00 c02ef7e2 c02ce658 c02ce658 c03 [ 1396.759947]0002 c02ef7e2 f7534eb4 f7534d70 f74 [ 1396.860803]f742bce4 c02c55c5 f7534d00 f7534e9c f7534d00 0286 f74 [ 1396.961659] Call Trace: [ 1396.993128] [c02ef7e2] _read_unlock_bh+0x12/0x16 [ 1397.051544] [c02ce658] ip6_route_output+0xeb/0x1e9 [ 1397.112038] [c02ce658] ip6_route_output+0xeb/0x1e9 [ 1397.172535] [c02ef7e2] _read_unlock_bh+0x12/0x16 [ 1397.230952] [c02c55c5] ip6_dst_lookup_tail+0xc6/0xd0 [ 1397.293524] [c02d7e29] udpv6_sendmsg+0x3d4/0x9ac [ 1397.351936] [c028b4a2] ip_generic_getfrag+0x0/0xaf [ 1397.412431] [c02d6e22] udpv6_recvmsg+0x20c/0x303 [ 1397.470846] [c02ae7b3] inet_sendmsg+0x4a/0x56 [ 1397.526148] [c02682f4] sock_sendmsg+0xe8/0x101 [ 1397.582494] [c01306ca] autoremove_wake_function+0x0/0x57 [ 1397.649214] [c01cadc4] copy_from_user+0x46/0x7e [ 1397.706594] [c0269e4b] sys_sendmsg+0x191/0x1f8 [ 1397.762941] [c014fe63] find_extend_vma+0x29/0x7e [ 1397.821357] [c0133bca] get_futex_key+0x4c/0x126 [ 1397.878740] [c0135be8] do_futex+0x6c/0x10a [ 1397.930928] [c01cadc4] copy_from_user+0x46/0x7e [ 1397.988307] [c026a2f1] sys_socketcall+0x236/0x254 [ 1398.047762] [c0102cdf] syscall_call+0x7/0xb [ 1398.100989] Code: 34 c7 44 24 04 5a 00 00 00 89 4c 24 0c e8 89 02 02 00 b8 a [ 1398.333299] EIP: [c02c6148] ip6_append_data+0xaf8/0xbd6 SS:ESP 0068:f742bc0 -- Cheers, -- cagri - 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: [PKT_SCHED] cls_basic: Use unsigned int when generating handle
Thomas Graf wrote:
Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund [EMAIL PROTECTED]
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/sched/cls_basic.c
===
--- net-2.6.orig/net/sched/cls_basic.c2006-09-26 13:35:29.0
+0200
+++ net-2.6/net/sched/cls_basic.c 2006-09-26 13:35:39.0 +0200
@@ -194,7 +194,7 @@
if (handle)
f-handle = handle;
else {
- int i = 0x8000;
+ unsigned int i = 0x8000;
I don't see how this patch changes anything, the loop already
ends when i == 0 (and it can't go negative):
do {
if (++head-hgenerator == 0x7FFF)
head-hgenerator = 1;
} while (--i 0 basic_get(tp, head-hgenerator));
which should also make sure that no handle gets used twice:
if (i = 0) {
printk(KERN_ERR Insufficient number of handles\n);
goto errout;
}
-
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] Documentation update pktgen
And the docs. Cheers. --ro Signed-off-by: Francesco Fondelli [EMAIL PROTECTED] Signed-off-by: Robert Olsson [EMAIL PROTECTED] diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 278771c..6062e35 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -100,6 +100,7 @@ Examples: are: IPSRC_RND #IP Source is random (between min/max), IPDST_RND, UDPSRC_RND, UDPDST_RND, MACSRC_RND, MACDST_RND + MPLS_RND, VID_RND, SVID_RND pgset udp_src_min 9 set UDP source port min, If udp_src_max, then cycle through the port range. @@ -125,6 +126,21 @@ Examples: pgset mpls 0 turn off mpls (or any invalid argument works too!) + pgset vlan_id 77 set VLAN ID 0-4095 + pgset vlan_p 3 set priority bit 0-7 (default 0) + pgset vlan_cfi 0 set canonical format identifier 0-1 (default 0) + + pgset svlan_id 22 set SVLAN ID 0-4095 + pgset svlan_p 3set priority bit 0-7 (default 0) + pgset svlan_cfi 0 set canonical format identifier 0-1 (default 0) + + pgset vlan_id 4095 remove vlan and svlan tags + pgset svlan 4095 remove svlan tag + + + pgset tos XX set former IPv4 TOS field (e.g. tos 28 for AF11 no ECN, default 00) + pgset traffic_class XX set former IPv6 TRAFFIC CLASS (e.g. traffic_class B8 for EF no ECN, default 00) + pgset stop aborts injection. Also, ^C aborts generator. - 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 09/11] b44: fix eeprom endianess issue
On Tuesday 26 September 2006 01:59, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: From: Michael Buesch [EMAIL PROTECTED] This fixes eeprom read on big-endian architectures. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/b44.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/b44.c~b44-fix-eeprom-endianess-issue drivers/net/b44.c --- a/drivers/net/b44.c~b44-fix-eeprom-endianess-issue +++ a/drivers/net/b44.c @@ -2055,7 +2055,7 @@ static int b44_read_eeprom(struct b44 *b u16 *ptr = (u16 *) data; for (i = 0; i 128; i += 2) - ptr[i / 2] = readw(bp-regs + 4096 + i); + ptr[i / 2] = cpu_to_le16(readw(bp-regs + 4096 + i)); Seems highly silly to me: readw() already swaps on big endian, so you're just swapping again. And then... read the call of b44_read_eeprom(): bp-dev-dev_addr[] assignment is such that it swaps YET AGAIN. Seems like a better solution would be to remove the manual swap from the caller of b44_read_eeprom(). I already explained this to you, but I will repeat me. readw returns the data in CPU order. With cpu_to_le16 we convert it to little endian, because ptr is a pointer to a _byte_ arrray. See the cast above. A byte array is little endian. Should I go into deeper detail, or did you get it? ;) The dev_addr assignment _intentionally_ swaps yet again, because the values are stored in bigendian format in the SPROM. Removing the swap for dev_addr would definately the worse and wrong solution. -- 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: [PATCH] skge: fiber support
On Thu, Sep 21, 2006 at 03:39:39PM -0700, Stephen Hemminger wrote: Add support for older fiber versions of the SysKonnect board. These chipsets use an internal PHY so they require special handling. The older sk98lin driver already supported these The patch seems to work with a single port card SX card. I'll test with LX dual port shortly. One thing that I haven't got working is forcing the card up if autonegotiation isn't possible. (It used to be a module parameter like AutoNeg=Off for sk98lin; I've tried (unsuccessfully) to use ethtool to turn off autoneg, but I'll try harder.) Mike Stone - 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] vlan support for pktgen
Francesco Fondelli writes:
The attached patch allows pktgen to produce 802.1Q and Q-in-Q tagged frames.
I have used it for stress test a bridge and seems ok to me.
Unfortunately I have no access to net-2.6.x git tree so the diff is against
2.6.17.13.
Thanks a lot.
Looks fine but haven't been able to test Q-in-Q. Below is a git diff.
We ask Dave to apply.
Cheers.
--ro
Signed-off-by: Francesco Fondelli [EMAIL PROTECTED]
Acked-by: Steven Whitehouse [EMAIL PROTECTED]
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index c23e9c0..e418224 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -109,6 +109,8 @@
*
* MPLS support by Steven Whitehouse [EMAIL PROTECTED]
*
+ * 802.1Q/Q-in-Q support by Francesco Fondelli (FF) [EMAIL PROTECTED]
+ *
*/
#include linux/sys.h
#include linux/types.h
@@ -137,6 +139,7 @@
#include linux/inetdevice.h
#include linux/rtnetlink.h
#include linux/if_arp.h
+#include linux/if_vlan.h
#include linux/in.h
#include linux/ip.h
#include linux/ipv6.h
@@ -178,6 +181,8 @@
#define F_TXSIZE_RND (16) /* Transmit size is random */
#define F_IPV6(17) /* Interface in IPV6 Mode */
#define F_MPLS_RND(18) /* Random MPLS labels */
+#define F_VID_RND (19) /* Random VLAN ID */
+#define F_SVID_RND(110) /* Random SVLAN ID */
/* Thread control flag bits */
#define T_TERMINATE (10)
@@ -198,6 +203,9 @@ static struct proc_dir_entry *pg_proc_di
#define MAX_CFLOWS 65536
+#define VLAN_TAG_SIZE(x) ((x)-vlan_id == 0x ? 0 : 4)
+#define SVLAN_TAG_SIZE(x) ((x)-svlan_id == 0x ? 0 : 4)
+
struct flow_state {
__u32 cur_daddr;
int count;
@@ -287,6 +295,15 @@ struct pktgen_dev {
/* MPLS */
unsigned nr_labels; /* Depth of stack, 0 = no MPLS */
__be32 labels[MAX_MPLS_LABELS];
+
+ /* VLAN/SVLAN (802.1Q/Q-in-Q) */
+ __u8 vlan_p;
+ __u8 vlan_cfi;
+ __u16 vlan_id; /* 0x means no vlan tag */
+
+ __u8 svlan_p;
+ __u8 svlan_cfi;
+ __u16 svlan_id; /* 0x means no svlan tag */
__u32 src_mac_count;/* How many MACs to iterate through */
__u32 dst_mac_count;/* How many MACs to iterate through */
@@ -644,6 +661,16 @@ static int pktgen_if_show(struct seq_fil
i == pkt_dev-nr_labels-1 ? \n : , );
}
+ if (pkt_dev-vlan_id != 0x) {
+ seq_printf(seq, vlan_id: %u vlan_p: %u vlan_cfi: %u\n,
+ pkt_dev-vlan_id, pkt_dev-vlan_p,
pkt_dev-vlan_cfi);
+ }
+
+ if (pkt_dev-svlan_id != 0x) {
+ seq_printf(seq, svlan_id: %u vlan_p: %u vlan_cfi: %u\n,
+ pkt_dev-svlan_id, pkt_dev-svlan_p,
pkt_dev-svlan_cfi);
+ }
+
seq_printf(seq, Flags: );
if (pkt_dev-flags F_IPV6)
@@ -673,6 +700,12 @@ static int pktgen_if_show(struct seq_fil
if (pkt_dev-flags F_MACDST_RND)
seq_printf(seq, MACDST_RND );
+ if (pkt_dev-flags F_VID_RND)
+ seq_printf(seq, VID_RND );
+
+ if (pkt_dev-flags F_SVID_RND)
+ seq_printf(seq, SVID_RND );
+
seq_puts(seq, \n);
sa = pkt_dev-started_at;
@@ -1140,6 +1173,18 @@ static ssize_t pktgen_if_write(struct fi
else if (strcmp(f, !MPLS_RND) == 0)
pkt_dev-flags = ~F_MPLS_RND;
+ else if (strcmp(f, VID_RND) == 0)
+ pkt_dev-flags |= F_VID_RND;
+
+ else if (strcmp(f, !VID_RND) == 0)
+ pkt_dev-flags = ~F_VID_RND;
+
+ else if (strcmp(f, SVID_RND) == 0)
+ pkt_dev-flags |= F_SVID_RND;
+
+ else if (strcmp(f, !SVID_RND) == 0)
+ pkt_dev-flags = ~F_SVID_RND;
+
else {
sprintf(pg_result,
Flag -:%s:- unknown\nAvailable flags, (prepend
! to un-set flag):\n%s,
@@ -1445,6 +1490,128 @@ static ssize_t pktgen_if_write(struct fi
offset += sprintf(pg_result + offset,
%08x%s, ntohl(pkt_dev-labels[n]),
n == pkt_dev-nr_labels-1 ? : ,);
+
+ if (pkt_dev-nr_labels pkt_dev-vlan_id != 0x) {
+ pkt_dev-vlan_id = 0x; /* turn off VLAN/SVLAN */
+ pkt_dev-svlan_id = 0x;
+
+ if (debug)
+ printk(pktgen: VLAN/SVLAN auto turned off\n);
+ }
+ return count;
+ }
+
+ if (!strcmp(name, vlan_id)) {
+ len = num_arg(user_buffer[i], 4, value);
+ if (len 0) {
+ return len;
+ }
+
[PATCH] Fix order in inet_init failure path.
This is just a minor buglet I came across by accident - when inet_init fails to register raw_prot, it jumps to out_unregister_udp_proto which should unregister UDP _and_ TCP. Signed-off-by: Olaf Kirch [EMAIL PROTECTED] net/ipv4/af_inet.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: build/net/ipv4/af_inet.c === --- build.orig/net/ipv4/af_inet.c +++ build/net/ipv4/af_inet.c @@ -1345,10 +1345,10 @@ static int __init inet_init(void) rc = 0; out: return rc; -out_unregister_tcp_proto: - proto_unregister(tcp_prot); out_unregister_udp_proto: proto_unregister(udp_prot); +out_unregister_tcp_proto: + proto_unregister(tcp_prot); goto out; } -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - 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
checksum when switching between source and dest addresses in IP header - newbie
Hello, I am not familiar with the details of checksum algorithm of ip headers; My question is this: When switching between source and dest addresses in an IP header of an IP packet - should the checksum of the ip header be changed ? Or is the checksum algorithm indifferent to which is the IP src address and IP dest address in the ip header ? Regards, John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DSCP support for pktgen
Francesco Fondelli writes:
Anyway, I've been asked to add support for managing DSCP codepoints, so
one can test DiffServ capable routers. It's very simple code and is working
for
me.
Looks fine too. We ask Dave to apply again.
Cheers.
--ro
Signed-off-by: Francesco Fondelli [EMAIL PROTECTED]
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
--- new/net/core/pktgen.c.vlan 2006-09-26 14:53:34.0 +0200
+++ new/net/core/pktgen.c 2006-09-26 14:54:49.0 +0200
@@ -160,7 +160,7 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
-#define VERSION pktgen v2.67: Packet Generator for packet performance
testing.\n
+#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
/* #define PG_DEBUG(a) a */
#define PG_DEBUG(a)
@@ -292,6 +292,10 @@
__u16 udp_dst_min; /* inclusive, dest UDP port */
__u16 udp_dst_max; /* exclusive, dest UDP port */
+ /* DSCP + ECN */
+ __u8 tos;/* six most significant bits of (former) IPv4 TOS
are for dscp codepoint */
+ __u8 traffic_class; /* ditto for the (former) Traffic Class in IPv6
(see RFC 3260, sec. 4) */
+
/* MPLS */
unsigned nr_labels; /* Depth of stack, 0 = no MPLS */
__be32 labels[MAX_MPLS_LABELS];
@@ -671,6 +675,14 @@
pkt_dev-svlan_id, pkt_dev-svlan_p,
pkt_dev-svlan_cfi);
}
+ if (pkt_dev-tos) {
+ seq_printf(seq, tos: 0x%02x\n, pkt_dev-tos);
+ }
+
+ if (pkt_dev-traffic_class) {
+ seq_printf(seq, traffic_class: 0x%02x\n,
pkt_dev-traffic_class);
+ }
+
seq_printf(seq, Flags: );
if (pkt_dev-flags F_IPV6)
@@ -748,12 +760,12 @@
}
-static int hex32_arg(const char __user *user_buffer, __u32 *num)
+static int hex32_arg(const char __user *user_buffer, unsigned long maxlen,
__u32 *num)
{
int i = 0;
*num = 0;
- for(; i 8; i++) {
+ for(; i maxlen; i++) {
char c;
*num = 4;
if (get_user(c, user_buffer[i]))
@@ -848,7 +860,7 @@
pkt_dev-nr_labels = 0;
do {
__u32 tmp;
- len = hex32_arg(buffer[i], tmp);
+ len = hex32_arg(buffer[i], 8, tmp);
if (len = 0)
return len;
pkt_dev-labels[n] = htonl(tmp);
@@ -1185,11 +1197,15 @@
else if (strcmp(f, !SVID_RND) == 0)
pkt_dev-flags = ~F_SVID_RND;
+ else if (strcmp(f, !IPV6) == 0)
+ pkt_dev-flags = ~F_IPV6;
+
else {
sprintf(pg_result,
Flag -:%s:- unknown\nAvailable flags, (prepend
! to un-set flag):\n%s,
f,
- IPSRC_RND, IPDST_RND, TXSIZE_RND, UDPSRC_RND,
UDPDST_RND, MACSRC_RND, MACDST_RND\n);
+ IPSRC_RND, IPDST_RND, UDPSRC_RND, UDPDST_RND,
+ MACSRC_RND, MACDST_RND, TXSIZE_RND, IPV6,
MPLS_RND, VID_RND, SVID_RND\n);
return count;
}
sprintf(pg_result, OK: flags=0x%x, pkt_dev-flags);
@@ -1615,6 +1631,38 @@
return count;
}
+ if (!strcmp(name, tos)) {
+ __u32 tmp_value = 0;
+ len = hex32_arg(user_buffer[i], 2, tmp_value);
+ if (len 0) {
+ return len;
+ }
+ i += len;
+ if (len == 2) {
+ pkt_dev-tos = tmp_value;
+ sprintf(pg_result, OK: tos=0x%02x, pkt_dev-tos);
+ } else {
+ sprintf(pg_result, ERROR: tos must be 00-ff);
+ }
+ return count;
+ }
+
+ if (!strcmp(name, traffic_class)) {
+ __u32 tmp_value = 0;
+ len = hex32_arg(user_buffer[i], 2, tmp_value);
+ if (len 0) {
+ return len;
+ }
+ i += len;
+ if (len == 2) {
+ pkt_dev-traffic_class = tmp_value;
+ sprintf(pg_result, OK: traffic_class=0x%02x,
pkt_dev-traffic_class);
+ } else {
+ sprintf(pg_result, ERROR: traffic_class must be
00-ff);
+ }
+ return count;
+ }
+
sprintf(pkt_dev-result, No such parameter \%s\, name);
return -EINVAL;
}
@@ -2339,7 +2387,7 @@
iph-ihl = 5;
iph-version = 4;
iph-ttl = 32;
- iph-tos = 0;
+ iph-tos = pkt_dev-tos;
iph-protocol = IPPROTO_UDP;/* UDP */
iph-saddr = pkt_dev-cur_saddr;
iph-daddr = pkt_dev-cur_daddr;
@@ -2678,6 +2726,11 @@
*(u32 *) iph = __constant_htonl(0x6000);
Re: [patch 09/11] b44: fix eeprom endianess issue
On Tuesday 26 September 2006 17:59, Jeff Garzik wrote: Michael Buesch wrote: On Tuesday 26 September 2006 01:59, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: From: Michael Buesch [EMAIL PROTECTED] This fixes eeprom read on big-endian architectures. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/b44.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/b44.c~b44-fix-eeprom-endianess-issue drivers/net/b44.c --- a/drivers/net/b44.c~b44-fix-eeprom-endianess-issue +++ a/drivers/net/b44.c @@ -2055,7 +2055,7 @@ static int b44_read_eeprom(struct b44 *b u16 *ptr = (u16 *) data; for (i = 0; i 128; i += 2) - ptr[i / 2] = readw(bp-regs + 4096 + i); + ptr[i / 2] = cpu_to_le16(readw(bp-regs + 4096 + i)); Seems highly silly to me: readw() already swaps on big endian, so you're just swapping again. And then... read the call of b44_read_eeprom(): bp-dev-dev_addr[] assignment is such that it swaps YET AGAIN. Seems like a better solution would be to remove the manual swap from the caller of b44_read_eeprom(). I already explained this to you, but I will repeat me. readw returns the data in CPU order. With cpu_to_le16 we convert it to little endian, because ptr is a pointer to a _byte_ arrray. See the cast above. A byte array is little endian. Should I go into deeper detail, or did you get it? ;) The dev_addr assignment _intentionally_ swaps yet again, because the values are stored in bigendian format in the SPROM. Removing the swap for dev_addr would definately the worse and wrong solution. AFAICS it's an obviously-correct end result, with far fewer swaps to boot. No it isn't. There are lots of other parameters in the ssb SPROM. And most of them are _not_ in bigendian. I think we also read the PHYport or something in b44. See bcm43xx or the ssb module for the rest of the values. Returning a SPROM bytearray as BABABABA is just plain wrong. It must always be ABABABAB, because we expect this. This patch encures ABABAB order on every platform. The interpret function must not know on which platform we are, as it's just interpreting the _byte_ array (byte array, without any endian semantics). This _fixes_ a bug (In the correct way, so that future bugs will not appear) -- 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: [patch 09/11] b44: fix eeprom endianess issue
Michael Buesch wrote: On Tuesday 26 September 2006 01:59, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: From: Michael Buesch [EMAIL PROTECTED] This fixes eeprom read on big-endian architectures. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/b44.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/b44.c~b44-fix-eeprom-endianess-issue drivers/net/b44.c --- a/drivers/net/b44.c~b44-fix-eeprom-endianess-issue +++ a/drivers/net/b44.c @@ -2055,7 +2055,7 @@ static int b44_read_eeprom(struct b44 *b u16 *ptr = (u16 *) data; for (i = 0; i 128; i += 2) - ptr[i / 2] = readw(bp-regs + 4096 + i); + ptr[i / 2] = cpu_to_le16(readw(bp-regs + 4096 + i)); Seems highly silly to me: readw() already swaps on big endian, so you're just swapping again. And then... read the call of b44_read_eeprom(): bp-dev-dev_addr[] assignment is such that it swaps YET AGAIN. Seems like a better solution would be to remove the manual swap from the caller of b44_read_eeprom(). I already explained this to you, but I will repeat me. readw returns the data in CPU order. With cpu_to_le16 we convert it to little endian, because ptr is a pointer to a _byte_ arrray. See the cast above. A byte array is little endian. Should I go into deeper detail, or did you get it? ;) The dev_addr assignment _intentionally_ swaps yet again, because the values are stored in bigendian format in the SPROM. Removing the swap for dev_addr would definately the worse and wrong solution. AFAICS it's an obviously-correct end result, with far fewer swaps to boot. 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 09/11] b44: fix eeprom endianess issue
Michael Buesch wrote: No it isn't. There are lots of other parameters in the ssb SPROM. And most of them are _not_ in bigendian. I think we also read the PHYport or something in b44. See bcm43xx or the ssb module for the rest of the values. Returning a SPROM bytearray as BABABABA is just plain wrong. It must always be ABABABAB, because we expect this. This patch encures ABABAB order on every platform. The interpret function must not know on which platform we are, as it's just interpreting the _byte_ array (byte array, without any endian semantics). This _fixes_ a bug (In the correct way, so that future bugs will not appear) It's amusing to call something incorrect, when my suggested solution will interpret the correct values from b44_get_invariants() simply by changing the b44_get_invariants() code from reading BABABABA to ABABABAB. 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: tc related lockdep warning.
Patrick McHardy wrote:
jamal wrote:
Yes, that looks plausible. Can you try making those changes and see if
the warning is gone?
I think this points to a bigger brokeness caused by the move of
dev-qdisc to RCU. It means destruction of filters and actions doesn't
necessarily happens in user-context and thus not protected by the rtnl
anymore.
I looked into this and we indeed still have lots of problems from that
broken RCU patch. Basically all locking (qdiscs, classifiers, actions,
estimators) assumes that updates are only done in process context and
thus read_lock doesn't need bottem half protection. Quite a few things
also assume that updates only happen under the RTNL and don't need
any further protection if not used during packet processing.
Instead of fixing all this I suggest something like this (untested)
patch instead. Since only the dev-qdisc pointer is protected by RCU,
but enqueue and the qdisc tree are still protected by dev-qdisc_lock,
we can perform destruction of the tree immediately and only do the
final free in the rcu callback, as long as we make sure not to enqueue
anything to a half-way destroyed qdisc.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index b0e9108..278d5e6 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -31,6 +31,7 @@ struct Qdisc
#define TCQ_F_BUILTIN 1
#define TCQ_F_THROTTLED2
#define TCQ_F_INGRESS 4
+#define TCQ_F_DYING8
int padded;
struct Qdisc_ops*ops;
u32 handle;
diff --git a/net/core/dev.c b/net/core/dev.c
index 14de297..c9c65c2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1480,14 +1480,15 @@ #endif
if (q-enqueue) {
/* Grab device queue */
spin_lock(dev-queue_lock);
+ if (likely(!(q-flags TCQ_F_DYING))) {
+ rc = q-enqueue(skb, q);
+ qdisc_run(dev);
+ spin_unlock(dev-queue_lock);
- rc = q-enqueue(skb, q);
-
- qdisc_run(dev);
-
+ rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc;
+ goto out;
+ }
spin_unlock(dev-queue_lock);
- rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc;
- goto out;
}
/* The device has no queue. Common case for software devices:
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 6f91518..93d52e0 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -47,9 +47,8 @@ #include net/pkt_sched.h
spinlock dev-queue_lock.
- tree walking is protected by read_lock_bh(qdisc_tree_lock)
and this lock is used only in process context.
- - updates to tree are made under rtnl semaphore or
- from softirq context (__qdisc_destroy rcu-callback)
- hence this lock needs local bh disabling.
+ - updates to tree are made only under rtnl semaphore,
+ hence this lock may be made without local bh disabling.
qdisc_tree_lock must be grabbed BEFORE dev-queue_lock!
*/
@@ -483,20 +482,6 @@ void qdisc_reset(struct Qdisc *qdisc)
static void __qdisc_destroy(struct rcu_head *head)
{
struct Qdisc *qdisc = container_of(head, struct Qdisc, q_rcu);
- struct Qdisc_ops *ops = qdisc-ops;
-
-#ifdef CONFIG_NET_ESTIMATOR
- gen_kill_estimator(qdisc-bstats, qdisc-rate_est);
-#endif
- write_lock(qdisc_tree_lock);
- if (ops-reset)
- ops-reset(qdisc);
- if (ops-destroy)
- ops-destroy(qdisc);
- write_unlock(qdisc_tree_lock);
- module_put(ops-owner);
-
- dev_put(qdisc-dev);
kfree((char *) qdisc - qdisc-padded);
}
@@ -504,32 +489,24 @@ #endif
void qdisc_destroy(struct Qdisc *qdisc)
{
- struct list_head cql = LIST_HEAD_INIT(cql);
- struct Qdisc *cq, *q, *n;
+ struct Qdisc_ops *ops = qdisc-ops;
if (qdisc-flags TCQ_F_BUILTIN ||
- !atomic_dec_and_test(qdisc-refcnt))
+ !atomic_dec_and_test(qdisc-refcnt))
return;
+ qdisc-flags |= TCQ_F_DYING;
- if (!list_empty(qdisc-list)) {
- if (qdisc-ops-cl_ops == NULL)
- list_del(qdisc-list);
- else
- list_move(qdisc-list, cql);
- }
-
- /* unlink inner qdiscs from dev-qdisc_list immediately */
- list_for_each_entry(cq, cql, list)
- list_for_each_entry_safe(q, n, qdisc-dev-qdisc_list, list)
- if (TC_H_MAJ(q-parent) == TC_H_MAJ(cq-handle)) {
- if (q-ops-cl_ops == NULL)
- list_del_init(q-list);
- else
- list_move_tail(q-list, cql);
- }
- list_for_each_entry_safe(cq, n, cql, list)
-
Re: [patch 09/11] b44: fix eeprom endianess issue
On Tuesday 26 September 2006 18:08, Jeff Garzik wrote: Michael Buesch wrote: No it isn't. There are lots of other parameters in the ssb SPROM. And most of them are _not_ in bigendian. I think we also read the PHYport or something in b44. See bcm43xx or the ssb module for the rest of the values. Returning a SPROM bytearray as BABABABA is just plain wrong. It must always be ABABABAB, because we expect this. This patch encures ABABAB order on every platform. The interpret function must not know on which platform we are, as it's just interpreting the _byte_ array (byte array, without any endian semantics). This _fixes_ a bug (In the correct way, so that future bugs will not appear) It's amusing to call something incorrect, when my suggested solution will interpret the correct values from b44_get_invariants() simply by changing the b44_get_invariants() code from reading BABABABA to ABABABAB. Jeff, I officially do not care about b44 any longer now. I am not going to waste my time now. If you don't want this patch, stay with current buggy code. It's OK to me. Maybe the following line of code from get_invariants explains best why my fix is the correct one: bp-phy_addr = eeprom[90] 0x1f; If you don't swap to LE in b44_read_eeprom this _won't_ lead to the expected result of getting byte 90 of the SPROM (on BE archs). Wanna have code like this? #ifdef BIG_ENDIAN bp-phy_addr = eeprom[91] 0x1f; #else bp-phy_addr = eeprom[90] 0x1f; #endif Or maybe bp-phy_addr = ((u16 *)eeprom)[90/2] 0x1f; I don't really think so. -- 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: [patch 09/11] b44: fix eeprom endianess issue
On Mon, 2006-09-25 at 19:59 -0400, Jeff Garzik wrote: Seems like a better solution would be to remove the manual swap from the caller of b44_read_eeprom(). No. You're not looking at the problem from the right angle. The thing is that Broadcom decided to store the EEPROM data as an array of u16s: u16 eeprom_data_as_stored[64]; In there, you have, for example, the mac address in 3 u16s at offsets 39-41: | offset | ... | 39 | 40 | 41 | ... | data | ... | MAC 01 | MAC 23 | MAC 45 | ... which together forms MAC 012345 (6 bytes) Broadcom further assumes that things are in little endian, so it's actually necessary to byteswap the MAC bytes 01, 23, 45 which I have omitted from above pictures because it's an array of u16 so endianness doesn't matter as long as you store it to the mac in big endian. Now come along the current code which didn't understand this and overlayed the eeprom_data_as_stored with a new array: u8 eeprom[128]; That's fine on little endian machines because each u16 will be represented in exactly the same way, and it all works out. However, because of Broadcom always thinking little endian u16 *and* the current code using u8 there's a mismatch on big endian machines which Michael fixed up by making the u8 overlay the driver is using see little endian u16. Insofar, it is the correct fix because the current code wants to use a u8 overlay over an array that was intended to be a little endian u16 array. Now, arguably the correct fix would be to make the b44_read_eeprom routine read an array of u16 as stored, and then use byte shifting everywhere to fix up for the fact that Broadcom stores things into the high/low byte of a u16 (yes, they always use a u16 layout even if the data they want to store is just a u8 or less, then they stuff it into a u16 and store it, they don't store byte-wise). Now, making that fix would result in quite some ugly code along the lines of: bp-dev-dev_addr[0] = eeprom[39] 8; bp-dev-dev_addr[1] = eeprom[39] 0xFF; bp-dev-dev_addr[2] = eeprom[40] 8; bp-dev-dev_addr[3] = eeprom[40] 0xFF; etc. Similar for the other parameters (which you seem to be forgetting by advocating the byte swap here, but they too are stored into u16s!) The current code obviously didn't want to do that so they overlaid the u16 array with a u8 array to read out the bytes directly. This results in the manual-seeming byte-swapping for some parameters of course. Now, Michaels fix works differently instead, it properly reads out the sprom data so that the overlaid u8 array gets what it expects, a view into a little endian u16 array. You really have to think of it as a view. This is obviously what the original authors intended to do but they were unaware of the endianness complications with that approach. johannes - 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 09/11] b44: fix eeprom endianess issue
Michael Buesch wrote: #ifdef BIG_ENDIAN bp-phy_addr = eeprom[91] 0x1f; #else bp-phy_addr = eeprom[90] 0x1f; #endif False. It's already fixed endian. It's just not the endian you like. 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: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
On Tue, 26 Sep 2006 13:18:09 +0300 (IDT) Or Gerlitz [EMAIL PROTECTED] wrote: Signed-off-by: Or Gerlitz [EMAIL PROTECTED] Index: net-2.6.19/drivers/net/bonding/bond_main.c === --- net-2.6.19.orig/drivers/net/bonding/bond_main.c 2006-09-25 11:46:35.0 +0300 +++ net-2.6.19/drivers/net/bonding/bond_main.c2006-09-26 10:54:44.0 +0300 @@ -128,6 +128,12 @@ MODULE_PARM_DESC(arp_interval, arp inte module_param_array(arp_ip_target, charp, NULL, 0); MODULE_PARM_DESC(arp_ip_target, arp targets in n.n.n.n form); +static int bonding_dev_type= ARPHRD_ETHER; +static int bonding_dev_addrlen = ETH_ALEN; + +module_param(bonding_dev_type,int, 0644); +module_param(bonding_dev_addrlen, int, 0644); Do you really want to allow changing these values after module load? If not replace 0644 with 0 - 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 09/11] b44: fix eeprom endianess issue
On Tuesday 26 September 2006 19:00, Jeff Garzik wrote: Michael Buesch wrote: #ifdef BIG_ENDIAN bp-phy_addr = eeprom[91] 0x1f; #else bp-phy_addr = eeprom[90] 0x1f; #endif False. It's already fixed endian. It's just not the endian you like. Jeff, come on... Read Johannes' mail. readX returns CPU endian data. -- 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: Subject: [PATCH] Advertise PPPoE MTU (resubmit).
[EMAIL PROTECTED] writes: PPPoE must advertise the underlying device's MTU via the ppp channel descriptor structure, as multilink functionality depends on it. Signed-off-by: Michal Ostrowski [EMAIL PROTECTED] Acked-by: Paul Mackerras [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
Subject: [PATCH] Advertise PPPoE MTU (resubmit).
PPPoE must advertise the underlying device's MTU via the ppp channel descriptor structure, as multilink functionality depends on it. Signed-off-by: Michal Ostrowski [EMAIL PROTECTED] --- drivers/net/pppoe.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c index 475dc93..c89e9ee 100644 --- a/drivers/net/pppoe.c +++ b/drivers/net/pppoe.c @@ -600,6 +600,7 @@ static int pppoe_connect(struct socket * po-chan.hdrlen = (sizeof(struct pppoe_hdr) + dev-hard_header_len); + po-chan.mtu = dev-mtu - sizeof(struct pppoe_hdr); po-chan.private = sk; po-chan.ops = pppoe_chan_ops; -- 1.4.1.1 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take19 0/4] kevent: Generic event handling mechanism.
On Fri, Sep 22, 2006 at 12:22:07PM -0700, Andrew Morton wrote: On Wed, 20 Sep 2006 13:35:47 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Generic event handling mechanism. Consider for inclusion. Ulrich's objections sounded substantial, and afaik remain largely unresolved. How do we sort this out? I haven't seen any of Ulrichs points (which mostly is a large subset of my objection) beeing addressed. - 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 09/11] b44: fix eeprom endianess issue
Johannes Berg [EMAIL PROTECTED] :
[...]
Now, arguably the correct fix would be to make the b44_read_eeprom
routine read an array of u16 as stored, and then use byte shifting
everywhere to fix up for the fact that Broadcom stores things into the
Yes.
high/low byte of a u16 (yes, they always use a u16 layout even if the
data they want to store is just a u8 or less, then they stuff it into a
u16 and store it, they don't store byte-wise).
Now, making that fix would result in quite some ugly code along the
lines of:
bp-dev-dev_addr[0] = eeprom[39] 8;
bp-dev-dev_addr[1] = eeprom[39] 0xFF;
bp-dev-dev_addr[2] = eeprom[40] 8;
bp-dev-dev_addr[3] = eeprom[40] 0xFF;
etc.
1 - see drivers/net/tg3.c. The drivers/net code does not swaps register
a lot: one can find some cpu_to_{l/b}e or {l/b}e_to_cpu which go
along read/write but they do not look like the norm.
2 - The code is extracting an u8 from an u16. Nothing shocking (ok, the
capitalized 0xFF _is_ shocking :o) ).
3 - The data in the eeprom contains u16 and it has a known endianness.
It can be annotated as such (__be16 eeprom[]). I do not know how to
do the same with an u8 [].
--
Ueimor
-
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] bonding: update version number
I neglected to properly update the version number in the recent patch series; this sets it to something reasonable. Signed-off-by: Jay Vosburgh [EMAIL PROTECTED] diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h index db16fee..dc434fb 100644 --- a/drivers/net/bonding/bonding.h +++ b/drivers/net/bonding/bonding.h @@ -22,8 +22,8 @@ #include linux/kobject.h #include bond_3ad.h #include bond_alb.h -#define DRV_VERSION3.1.0-test -#define DRV_RELDATESeptember 9, 2006 +#define DRV_VERSION3.1.1 +#define DRV_RELDATESeptember 26, 2006 #define DRV_NAME bonding #define DRV_DESCRIPTIONEthernet Channel Bonding Driver - 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 09/11] b44: fix eeprom endianess issue
On Tuesday 26 September 2006 19:49, Francois Romieu wrote:
Johannes Berg [EMAIL PROTECTED] :
[...]
Now, arguably the correct fix would be to make the b44_read_eeprom
routine read an array of u16 as stored, and then use byte shifting
everywhere to fix up for the fact that Broadcom stores things into the
Yes.
That is damn unnecessary. Why change semantics and not _fix_ _current_
semantics? (Espacially, if fixing current semantics is a _lot_ easier).
high/low byte of a u16 (yes, they always use a u16 layout even if the
data they want to store is just a u8 or less, then they stuff it into a
u16 and store it, they don't store byte-wise).
Now, making that fix would result in quite some ugly code along the
lines of:
bp-dev-dev_addr[0] = eeprom[39] 8;
bp-dev-dev_addr[1] = eeprom[39] 0xFF;
bp-dev-dev_addr[2] = eeprom[40] 8;
bp-dev-dev_addr[3] = eeprom[40] 0xFF;
etc.
1 - see drivers/net/tg3.c. The drivers/net code does not swaps register
a lot: one can find some cpu_to_{l/b}e or {l/b}e_to_cpu which go
along read/write but they do not look like the norm.
Well, so maybe tg3 is broken, too.
But that does not matter now. We are talking about b44.
2 - The code is extracting an u8 from an u16. Nothing shocking (ok, the
capitalized 0xFF _is_ shocking :o) ).
o_O No comment, really.
3 - The data in the eeprom contains u16 and it has a known endianness.
It can be annotated as such (__be16 eeprom[]). I do not know how to
do the same with an u8 [].
No. The eeprom is mostly not be16. The eeprom is mostly little
endian, except the mac address and some wireless specific bits
I forgot.
But more important: This does _NOT_ matter here, as that's not
related to the acutual bug in b44.
The bug is:
Reading u16 values with readw, casting them into an u8 array
and accessing this u8 array as an u8 (byte) array.
The correct fix is to swap the CPU-ordering value returned
by readw into little endian, as the u8 array is little
endian.
This compiles to nothing on little endian hardware (so it
does not change b44 code on LE hardware), but _fixes_
code on BE hardware.
--
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: [PKT_SCHED] cls_basic: Use unsigned int when generating handle
* Patrick McHardy [EMAIL PROTECTED] 2006-09-26 15:32
Thomas Graf wrote:
Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund [EMAIL PROTECTED]
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/sched/cls_basic.c
===
--- net-2.6.orig/net/sched/cls_basic.c 2006-09-26 13:35:29.0
+0200
+++ net-2.6/net/sched/cls_basic.c 2006-09-26 13:35:39.0 +0200
@@ -194,7 +194,7 @@
if (handle)
f-handle = handle;
else {
- int i = 0x8000;
+ unsigned int i = 0x8000;
I don't see how this patch changes anything, the loop already
ends when i == 0 (and it can't go negative):
do {
if (++head-hgenerator == 0x7FFF)
head-hgenerator = 1;
} while (--i 0 basic_get(tp, head-hgenerator));
which should also make sure that no handle gets used twice:
if (i = 0) {
printk(KERN_ERR Insufficient number of handles\n);
goto errout;
}
You're right, 0x8000 - 1 is already positive. Ignore the patch.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.18 backport] RTL8168 ethernet support in r8169
Here's a backport of the 2.6.19 patch which adds support for the 8168
hardware found on some recent motherboards. It will be shipped in future
Gentoo 2.6.18 releases. I hope it's useful to someone, although if there
are any problems you should test the latest -git snapshot before telling
anybody.
From: Francois Romieu [EMAIL PROTECTED]
Date: Wed, 26 Jul 2006 21:14:13 + (+0200)
Subject: r8169: sync with vendor's driver
X-Git-Tag: v2.6.18-rc3
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bcf0bf90cd9e9242b66e0563b6a8c8db2e4c262c
r8169: sync with vendor's driver
- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
Explanation: the in-kernel Linux driver is written to allow MM register
accesses and avoid the IO tax. The relevant BAR register was found at
base address 1 for the plain-old PCI 8169. User reported lspci show that
it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
Typically:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)
Subsystem: Unknown device 1631:e015
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR-
Latency: 0, cache line size 20
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at b800 [size=256]
Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
So far I have not received any lspci report for the 0x8136 and
Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
include a USE_IO_SPACE #define but the bar address is always hardcoded
to 1 in the MM case. :o/
- the 8168 has been reported to require an extra alignment for its receive
buffers. The status of the 8167 and 8136 is not known in this regard.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Rediffed for 2.6.18 by Daniel Drake [EMAIL PROTECTED]
---
Index: linux-2.6.18/drivers/net/r8169.c
===
--- linux-2.6.18.orig/drivers/net/r8169.c
+++ linux-2.6.18/drivers/net/r8169.c
@@ -150,11 +150,16 @@ static const int multicast_filter_limit
#define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg)))
enum mac_version {
- RTL_GIGA_MAC_VER_B = 0x00,
- /* RTL_GIGA_MAC_VER_C = 0x03, */
- RTL_GIGA_MAC_VER_D = 0x01,
- RTL_GIGA_MAC_VER_E = 0x02,
- RTL_GIGA_MAC_VER_X = 0x04 /* Greater than RTL_GIGA_MAC_VER_E */
+ RTL_GIGA_MAC_VER_01 = 0x00,
+ RTL_GIGA_MAC_VER_02 = 0x01,
+ RTL_GIGA_MAC_VER_03 = 0x02,
+ RTL_GIGA_MAC_VER_04 = 0x03,
+ RTL_GIGA_MAC_VER_05 = 0x04,
+ RTL_GIGA_MAC_VER_11 = 0x0b,
+ RTL_GIGA_MAC_VER_12 = 0x0c,
+ RTL_GIGA_MAC_VER_13 = 0x0d,
+ RTL_GIGA_MAC_VER_14 = 0x0e,
+ RTL_GIGA_MAC_VER_15 = 0x0f
};
enum phy_version {
@@ -166,7 +171,6 @@ enum phy_version {
RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */
};
-
#define _R(NAME,MAC,MASK) \
{ .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
@@ -175,19 +179,44 @@ static const struct {
u8 mac_version;
u32 RxConfigMask; /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
- _R(RTL8169, RTL_GIGA_MAC_VER_B, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_D, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_E, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_X, 0xff7e1880),
+ _R(RTL8169, RTL_GIGA_MAC_VER_01, 0xff7e1880),
+ _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_02, 0xff7e1880),
+ _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_03, 0xff7e1880),
+ _R(RTL8169sb/8110sb, RTL_GIGA_MAC_VER_04, 0xff7e1880),
+ _R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_05, 0xff7e1880),
+ _R(RTL8168b/8111b, RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
+ _R(RTL8168b/8111b, RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
+ _R(RTL8101e, RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
+ _R(RTL8100e, RTL_GIGA_MAC_VER_14, 0xff7e1880), // PCI-E 8139
+ _R(RTL8100e, RTL_GIGA_MAC_VER_15, 0xff7e1880) // PCI-E 8139
};
#undef _R
+enum cfg_version {
+ RTL_CFG_0 = 0x00,
+ RTL_CFG_1,
+ RTL_CFG_2
+};
+
+static const struct {
+ unsigned int region;
+ unsigned int align;
+} rtl_cfg_info[] = {
+ [RTL_CFG_0] = { 1, NET_IP_ALIGN },
+ [RTL_CFG_1] = { 2, NET_IP_ALIGN },
+ [RTL_CFG_2] = { 2, 8 }
+};
+
static struct pci_device_id rtl8169_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), },
- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
- { PCI_DEVICE(0x16ec, 0x0116), },
- { PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, 0x0024, },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_1
[PATCH] ethtool: add sky2 register dump
Add support for sky2 register dump, put it in a common file
for both skge and sky2.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
Makefile.am|2
ethtool-util.h |2
ethtool.c |1
marvell.c | 327
skge.c | 189
5 files changed, 331 insertions(+), 190 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index c78eecf..97ad512 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,7 +7,7 @@ sbin_PROGRAMS = ethtool
ethtool_SOURCES = ethtool.c ethtool-copy.h ethtool-util.h \
amd8111e.c de2104x.c e100.c e1000.c \
fec_8xx.c ibm_emac.c ixgb.c natsemi.c \
- pcnet32.c realtek.c tg3.c skge.c
+ pcnet32.c realtek.c tg3.c marvell.c
dist-hook:
cp $(top_srcdir)/ethtool.spec $(distdir)
diff --git a/ethtool-util.h b/ethtool-util.h
index 0e6fce2..dbaa06b 100644
--- a/ethtool-util.h
+++ b/ethtool-util.h
@@ -51,4 +51,6 @@ int tg3_dump_regs(struct ethtool_drvinfo
/* SysKonnect Gigabit (Genesis and Yukon) */
int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+/* Marvell SysKonnect Gigabit (Yukon2) */
+int sky2_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
#endif
diff --git a/ethtool.c b/ethtool.c
index 2363b3b..b783248 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -957,6 +957,7 @@ static struct {
{ ibm_emac, ibm_emac_dump_regs },
{ tg3, tg3_dump_regs },
{ skge, skge_dump_regs },
+ { sky2, sky2_dump_regs },
};
static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
diff --git a/marvell.c b/marvell.c
new file mode 100644
index 000..87d5b72
--- /dev/null
+++ b/marvell.c
@@ -0,0 +1,327 @@
+/*
+ * Code to dump Marvell SysKonnect registers for skge and sky2 drivers.
+ *
+ * Copyright (C) 2004, 2006
+ * Stephen Hemminger [EMAIL PROTECTED]
+ */
+
+#include stdio.h
+
+#include ethtool-util.h
+
+static void dump_addr(int n, const u8 *a)
+{
+ int i;
+
+ printf(Addr %d, n);
+ for (i = 0; i 6; i++)
+ printf(%02X%c, a[i], i == 5 ? '\n' : ' ');
+}
+
+static void dump_timer(const char *name, const void *p)
+{
+ const u8 *a = p;
+ const u32 *r = p;
+
+ printf(%s\n, name);
+ printf(\tInit 0x%08X Value 0x%08X\n, r[0], r[1]);
+ printf(\tTest 0x%02X Control 0x%02X\n, a[8], a[9]);
+}
+
+static void dump_queue(const char *name, const void *a, int rx)
+{
+ struct desc {
+ u_int32_t ctl;
+ u_int32_t next;
+ u_int32_t data_lo;
+ u_int32_t data_hi;
+ u_int32_t status;
+ u_int32_t timestamp;
+ u_int16_t csum2;
+ u_int16_t csum1;
+ u_int16_t csum2_start;
+ u_int16_t csum1_start;
+ u_int32_t addr_lo;
+ u_int32_t addr_hi;
+ u_int32_t count_lo;
+ u_int32_t count_hi;
+ u_int32_t byte_count;
+ u_int32_t csr;
+ u_int32_t flag;
+ };
+ const struct desc *d = a;
+
+ printf(\n%s\n, name);
+ printf(---\n);
+ printf(Descriptor Address 0x%08X%08X\n,
+ d-addr_hi, d-addr_lo);
+ printf(Address Counter 0x%08X%08X\n,
+ d-count_hi, d-count_lo);
+ printf(Current Byte Counter %d\n, d-byte_count);
+ printf(BMU Control/Status 0x%08X\n, d-csr);
+ printf(Flag FIFO Address 0x%08X\n, d-flag);
+ printf(\n);
+ printf(Control 0x%08X\n, d-ctl);
+ printf(Next 0x%08X\n, d-next);
+ printf(Data 0x%08X%08X\n,
+ d-data_hi, d-data_lo);
+ printf(Status 0x%08X\n, d-status);
+ printf(Timestamp0x%08X\n, d-timestamp);
+ if (rx) {
+ printf(Csum1 Offset %4d Position %d\n,
+ d-csum1, d-csum1_start);
+ printf(Csum2 Offset %4d Positron %d\n,
+ d-csum2, d-csum2_start);
+ } else
+ printf(Csum Start 0x%04X Pos %4d Write %d\n,
+ d-csum1, d-csum2_start, d-csum1_start);
+
+}
+
+static void dump_ram(const char *name, const void *p)
+{
+ const u32 *r = p;
+
+ printf(\n%s\n, name);
+ printf(---\n);
+ printf(Start Address0x%08X\n, r[0]);
+ printf(End Address 0x%08X\n, r[1]);
+ printf(Write
Re: [patch 09/11] b44: fix eeprom endianess issue
Michael Buesch [EMAIL PROTECTED] : [...] 3 - The data in the eeprom contains u16 and it has a known endianness. It can be annotated as such (__be16 eeprom[]). I do not know how to do the same with an u8 []. No. The eeprom is mostly not be16. The eeprom is mostly little endian, except the mac address and some wireless specific bits I forgot. Sorry, s/__be16/__le16/ -- Ueimor - 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 backport] RTL8168 ethernet support in r8169
Daniel Drake [EMAIL PROTECTED] :
[...]
static struct pci_device_id rtl8169_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), },
- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
- { PCI_DEVICE(0x16ec,0x0116), },
- { PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_1 },
Should be RTL_CFG_2 (but there are still issues with the link management).
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_1 },
^
Should be RTL_CFG_1.
Is there any chance that you can push a different patch for your releases ?
There are no pending changes outside of the git vanilla tree. As an option,
you can use the patch below too:
http://www.fr.zoreil.com/people/francois/misc/20060920-2.6.18-r8169-test.patch
I should have Cced: you :o/
--
Ueimor
-
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 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices
Or Gerlitz [EMAIL PROTECTED] wrote: [...] + bond-dev-mtu = new_active-dev-mtu; This won't generate a NETDEV_CHANGEMTU notifier event. [...] + /* bonding netdevices are created with ether_setup, so when the + * slave type is not ARPHRD_ETHER there is a need to override + * some of the type dependent attributes/functions + */ + if (new_active new_active-dev-type != ARPHRD_ETHER) + bond_setup_by_slave(bond, new_active); + In this case, if the bond has one slave that's ARPHRD_ETHER and one that's not, when the active changes from the non-ARPHRD_ETHER slave to the ARPHRD_ETHER slave, it won't call bond_setup_by_slave() to switch the hard_header, rebuild_header, et al, back to the ARPHRD_ETHER settings. -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
[Patch] Possible dereference in net/core/rtnetlink.c (fwd)
-- Forwarded message --
Date: Tue, 26 Sep 2006 12:50:51 +0200
From: Eric Sesterhenn [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED]
Subject: [Patch] Possible dereference in net/core/rtnetlink.c
hi,
another possible dereference spotted by coverity (#cid 1390).
if the nlmsg_parse() call fails, we goto errout, where we call
dev_put(), with dev still initialized to NULL.
Signed-off-by: Eric Sesterhenn [EMAIL PROTECTED]
--- linux-2.6.18-git5/net/core/rtnetlink.c.orig 2006-09-26 12:48:03.0
+0200
+++ linux-2.6.18-git5/net/core/rtnetlink.c 2006-09-26 12:48:28.0
+0200
@@ -562,7 +562,7 @@ static int rtnl_getlink(struct sk_buff *
err = nlmsg_parse(nlh, sizeof(*ifm), tb, IFLA_MAX, ifla_policy);
if (err 0)
- goto errout;
+ return err;
ifm = nlmsg_data(nlh);
if (ifm-ifi_index = 0) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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 v1.7 rx error...
The server processor is a Pentium-M 1.7GHz (ondemand governor, from 0.6GHz - 1.7GHz). Gigabit path from server - switch - client. Client runs WinXP, Core2Duo 2.13GHz, Realtek RTL8168/8111 PCI-e NIC. Flow contol enabled in both directions, both for client and server: sky2 lan0: Link is up at 1000 Mbps, full duplex, flow control both Jumbo frames are in use on the tx side of server only - MTU 9000. I reproduced this with sky2 v1.7 with non-jumbo MTU 1500 frames too. Let me know if there is any further information I can grab and/or any other settings/tweaks/patches I can try. Dan On 26/09/06, Stephen Hemminger [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006 18:58:40 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: I got a this message with sky2 on 2.6.18 + the sky2 v1.7 patches - it has different status bits set than before (0x977d977d): kernel: sky2 lan0: rx error, status 0x377d377d length 0 Great work so far though - this race takes a while to hit! Dan What speed processor? Are you using receive flow control? Are you using Jumbo frames? -- Stephen Hemminger [EMAIL PROTECTED] -- Daniel J Blueman - 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] genetlink custom attribute type
From: Johannes Berg [EMAIL PROTECTED] Date: Tue, 26 Sep 2006 12:04:34 +0200 On Tue, 2006-09-26 at 11:44 +0200, Thomas Graf wrote: Thinking it over I'm still not completely happy with this. A small subset of all the validation tasks is simply too complex to be put into the policy. The validation of your type value array is such a case, address fields with variable length based on their family is another. I think it's just not worth to blow up struct nla_policy by 12 bytes per entry just to save some code. Alright, I can instead just add the validation function call wherever that attribute is going to be used. Just thought it might be nice to have this generically, I'm not really too attached to it :) I'll change it in the next nl80211 iteration. Thanks Johannes. - 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.6.17.13 2/2] LARTC: trace control for netem: kernelspace
Hi Stephens
We merged your changes into our patch
http://tcn.hypert.net/tcn_kernel_2_6_18.patch
Please let us know if we should do further adoptions to our
implementation and/or resubmit the adapted patch.
Cheers+thanx,
Rainer
Stephen Hemminger wrote:
Some changes:
1. need to select CONFIGFS into configuration
2. don't add declarations after code.
3. use unsigned not int for counters and mask.
4. don't return a structure (ie pkt_delay)
5. use enum for magic values
6. don't use GFP_ATOMIC unless you have to
7. check error values on configfs_init
8. map initialization is unneeded. static's always init to zero.
--
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index d10f353..a51de64 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -430,6 +430,8 @@ enum
TCA_NETEM_DELAY_DIST,
TCA_NETEM_REORDER,
TCA_NETEM_CORRUPT,
+ TCA_NETEM_TRACE,
+ TCA_NETEM_STATS,
__TCA_NETEM_MAX,
};
@@ -445,6 +447,35 @@ struct tc_netem_qopt
__u32 jitter; /* random jitter in latency (us) */
};
+struct tc_netem_stats
+{
+ int packetcount;
+ int packetok;
+ int normaldelay;
+ int drops;
+ int dupl;
+ int corrupt;
+ int novaliddata;
+ int uninitialized;
+ int bufferunderrun;
+ int bufferinuseempty;
+ int noemptybuffer;
+ int readbehindbuffer;
+ int buffer1_reloads;
+ int buffer2_reloads;
+ int tobuffer1_switch;
+ int tobuffer2_switch;
+ int switch_to_emptybuffer1;
+ int switch_to_emptybuffer2;
+};
+
+struct tc_netem_trace
+{
+ __u32 fid; /*flowid */
+ __u32 def; /* default action 0 = no delay, 1 = drop*/
+ __u32 ticks; /* number of ticks corresponding to 1ms */
+};
+
struct tc_netem_corr
{
__u32 delay_corr; /* delay correlation */
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 8298ea9..aee4bc6 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -232,6 +232,7 @@ config NET_SCH_DSMARK
config NET_SCH_NETEM
tristate Network emulator (NETEM)
+ select CONFIGFS_FS
---help---
Say Y if you want to emulate network delay, loss, and packet
re-ordering. This is often useful to simulate networks when
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 45939ba..521b9e3 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -11,6 +11,9 @@
*
* Authors: Stephen Hemminger [EMAIL PROTECTED]
* Catalin(ux aka Dino) BOIE catab at umbrella dot ro
+ * netem trace enhancement: Ariane Keller [EMAIL PROTECTED]
ETH Zurich
+ * Rainer Baumann [EMAIL PROTECTED]
ETH Zurich
+ * Ulrich Fiedler [EMAIL PROTECTED]
ETH Zurich
*/
#include linux/module.h
@@ -21,10 +24,16 @@ #include linux/errno.h
#include linux/netdevice.h
#include linux/skbuff.h
#include linux/rtnetlink.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/configfs.h
+#include linux/vmalloc.h
#include net/pkt_sched.h
-#define VERSION 1.2
+#include net/flowseed.h
+
+#define VERSION 1.3
/* Network Emulation Queuing algorithm.
@@ -50,6 +59,11 @@ #define VERSION 1.2
The simulator is limited by the Linux timer resolution
and will create packet bursts on the HZ boundary (1ms).
+
+ The trace option allows us to read the values for packet delay,
+ duplication, loss and corruption from a tracefile. This permits
+ the modulation of statistical properties such as long-range
+ dependences. See http://tcn.hypert.net.
*/
struct netem_sched_data {
@@ -65,6 +79,11 @@ struct netem_sched_data {
u32 duplicate;
u32 reorder;
u32 corrupt;
+ u32 tcnstop;
+ u32 trace;
+ u32 ticks;
+ u32 def;
+ u32 newdataneeded;
struct crndstate {
unsigned long last;
@@ -72,9 +91,13 @@ struct netem_sched_data {
} delay_cor, loss_cor, dup_cor, reorder_cor, corrupt_cor;
struct disttable {
- u32 size;
+ u32 size;
s16 table[0];
} *delay_dist;
+
+ struct tcn_statistic *statistic;
+ struct tcn_control *flowbuffer;
+ wait_queue_head_t my_event;
};
/* Time stamp put into socket buffer control block */
@@ -82,6 +105,18 @@ struct netem_skb_cb {
psched_time_t time_to_send;
};
+
+struct confdata {
+ int fid;
+ struct netem_sched_data * sched_data;
+};
+
+static struct confdata map[MAX_FLOWS];
+
+#define MASK_BITS29
+#define MASK_DELAY ((1MASK_BITS)-1)
+#define MASK_HEAD ~MASK_DELAY
+
/* init_crandom - initialize correlated random number generator
* Use
Re: sky2 v1.7 rx error...
On Tue, 26 Sep 2006 21:09:31 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: The server processor is a Pentium-M 1.7GHz (ondemand governor, from 0.6GHz - 1.7GHz). Gigabit path from server - switch - client. Client runs WinXP, Core2Duo 2.13GHz, Realtek RTL8168/8111 PCI-e NIC. Flow contol enabled in both directions, both for client and server: sky2 lan0: Link is up at 1000 Mbps, full duplex, flow control both Jumbo frames are in use on the tx side of server only - MTU 9000. I reproduced this with sky2 v1.7 with non-jumbo MTU 1500 frames too. Let me know if there is any further information I can grab and/or any other settings/tweaks/patches I can try. Dan On 26/09/06, Stephen Hemminger [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006 18:58:40 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: I got a this message with sky2 on 2.6.18 + the sky2 v1.7 patches - it has different status bits set than before (0x977d977d): kernel: sky2 lan0: rx error, status 0x377d377d length 0 Great work so far though - this race takes a while to hit! Dan What speed processor? Are you using receive flow control? Are you using Jumbo frames? -- Stephen Hemminger [EMAIL PROTECTED] Statistics? ethtool -S eth0 Does it hang after this? It looks like a receive fifo overflow, that happens when the receive ring gets full. You could try increasing RX_LE_SIZE from 512 to 1024. That would eat more memory (510 packets) but might avoid the problem. Other possible solutions would be to reduce the coalescing timer values with ethtool. ethtool -c eth1 ethtool -C eth1 rx-usecs 10 rx-usecs-irq 10 rx-iframes-irq 4 -- 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: [PATCH 2.6.17.13 2/2] LARTC: trace control for netem: kernelspace
On Tue, 26 Sep 2006 22:17:57 +0200 Rainer Baumann [EMAIL PROTECTED] wrote: Hi Stephens We merged your changes into our patch http://tcn.hypert.net/tcn_kernel_2_6_18.patch Please let us know if we should do further adoptions to our implementation and/or resubmit the adapted patch. Cheers+thanx, Rainer I'll test it out, and send off to Dave for 2.6.20, 2.6.19 is so in flux right now that adding more seems not like a good idea. - 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.6.17.13 2/2] LARTC: trace control for netem: kernelspace
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 26 Sep 2006 13:45:31 -0700 I'll test it out, and send off to Dave for 2.6.20, 2.6.19 is so in flux right now that adding more seems not like a good idea. I'm willing to accept anything reasonable until approximately this weekend. - 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: tc related lockdep warning.
On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote: Patrick McHardy wrote: jamal wrote: Yes, that looks plausible. Can you try making those changes and see if the warning is gone? I think this points to a bigger brokeness caused by the move of dev-qdisc to RCU. It means destruction of filters and actions doesn't necessarily happens in user-context and thus not protected by the rtnl anymore. I looked into this and we indeed still have lots of problems from that broken RCU patch. Basically all locking (qdiscs, classifiers, actions, estimators) assumes that updates are only done in process context and thus read_lock doesn't need bottem half protection. Quite a few things also assume that updates only happen under the RTNL and don't need any further protection if not used during packet processing. Instead of fixing all this I suggest something like this (untested) patch instead. Since only the dev-qdisc pointer is protected by RCU, but enqueue and the qdisc tree are still protected by dev-qdisc_lock, we can perform destruction of the tree immediately and only do the final free in the rcu callback, as long as we make sure not to enqueue anything to a half-way destroyed qdisc. With this patch, I get no lockdep warnings, but the machine locks up completely. I hooked up a serial console, and found this.. u32 classifier Performance counters on input device check on Actions configured BUG: warning at net/sched/sch_htb.c:395/htb_safe_rb_erase() Call Trace: [8026f79b] show_trace+0xae/0x336 [8026fa38] dump_stack+0x15/0x17 [8860a171] :sch_htb:htb_safe_rb_erase+0x3b/0x55 [8860a4d5] :sch_htb:htb_deactivate_prios+0x173/0x1cd [8860b437] :sch_htb:htb_dequeue+0x4d0/0x856 [8042dc0d] __qdisc_run+0x3f/0x1ca [802329a6] dev_queue_xmit+0x137/0x268 [8025b4a2] neigh_resolve_output+0x249/0x27e [802353fd] ip_output+0x210/0x25a [8043ce28] ip_push_pending_frames+0x37c/0x45b [8044ffd7] icmp_push_reply+0x13b/0x148 [80450900] icmp_send+0x366/0x3d3 [802568a9] udp_rcv+0x53d/0x556 [80237e73] ip_local_deliver+0x1a3/0x26b [80238ec8] ip_rcv+0x4b9/0x501 [802218bb] netif_receive_skb+0x33d/0x3c9 [881f6348] :e1000:e1000_clean_rx_irq+0x450/0x4fe [881f47eb] :e1000:e1000_clean+0x88/0x17d [8020cab3] net_rx_action+0xac/0x1d1 [80212725] __do_softirq+0x68/0xf5 [80262638] call_softirq+0x1c/0x28 DWARF2 unwinder stuck at call_softirq+0x1c/0x28 Leftover inexact backtrace: IRQ [80270aaa] do_softirq+0x39/0x9f [80296102] irq_exit+0x57/0x59 [80270c0d] do_IRQ+0xfd/0x107 [8025b51d] mwait_idle+0x0/0x54 [802618c6] ret_from_intr+0x0/0xf EOI [80265e66] __sched_text_start+0xaa6/0xadd [8025b55c] mwait_idle+0x3f/0x54 [8025b526] mwait_idle+0x9/0x54 [8024c81c] cpu_idle+0xa2/0xc5 [8026e519] rest_init+0x2b/0x2d [80a7f811] start_kernel+0x24a/0x24c [80a7f28b] _sinittext+0x28b/0x292 BUG: warning at net/sched/sch_htb.c:395/htb_safe_rb_erase() Call Trace: [8026f79b] show_trace+0xae/0x336 [8026fa38] dump_stack+0x15/0x17 [8860a171] :sch_htb:htb_safe_rb_erase+0x3b/0x55 [8860a4d5] :sch_htb:htb_deactivate_prios+0x173/0x1cd [8860b437] :sch_htb:htb_dequeue+0x4d0/0x856 [8042dc0d] __qdisc_run+0x3f/0x1ca [802329a6] dev_queue_xmit+0x137/0x268 [8025b4a2] neigh_resolve_output+0x249/0x27e [802353fd] ip_output+0x210/0x25a [8043ce28] ip_push_pending_frames+0x37c/0x45b [8044ffd7] icmp_push_reply+0x13b/0x148 [80450900] icmp_send+0x366/0x3d3 [802568a9] udp_rcv+0x53d/0x556 [80237e73] ip_local_deliver+0x1a3/0x26b [80238ec8] ip_rcv+0x4b9/0x501 [802218bb] netif_receive_skb+0x33d/0x3c9 [881f6348] :e1000:e1000_clean_rx_irq+0x450/0x4fe [881f47eb] :e1000:e1000_clean+0x88/0x17d [8020cab3] net_rx_action+0xac/0x1d1 [80212725] __do_softirq+0x68/0xf5 [80262638] call_softirq+0x1c/0x28 DWARF2 unwinder stuck at call_softirq+0x1c/0x28 Leftover inexact backtrace: IRQ [80270aaa] do_softirq+0x39/0x9f [80296102] irq_exit+0x57/0x59 [80270c0d] do_IRQ+0xfd/0x107 [8025b51d] mwait_idle+0x0/0x54 [802618c6] ret_from_intr+0x0/0xf EOI [80265e66] __sched_text_start+0xaa6/0xadd [8025b55c] mwait_idle+0x3f/0x54 [8025b526] mwait_idle+0x9/0x54 [8024c81c] cpu_idle+0xa2/0xc5 [8026e519] rest_init+0x2b/0x2d [80a7f811] start_kernel+0x24a/0x24c [80a7f28b] _sinittext+0x28b/0x292 BUG: soft lockup detected on CPU#0! Call Trace: [8026f79b] show_trace+0xae/0x336 [8026fa38] dump_stack+0x15/0x17 [802bfea7] softlockup_tick+0xd5/0xea
mii-tool gigabit support.
The mii-tool utility seems to be abandoned and unmaintained? Here is a version that does standard 1000baseT support. http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2 -- 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: mii-tool gigabit support.
Stephen Hemminger wrote: The mii-tool utility seems to be abandoned and unmaintained? Here is a version that does standard 1000baseT support. http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2 Not really. I would rather leave it as-is, and deprecate it in favor of ethtool. I want to keep binary ABI compat, but long term, move away from having userspace directly bitbang hardware registers. 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: mii-tool gigabit support.
On Tue, 26 Sep 2006 17:55:34 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: The mii-tool utility seems to be abandoned and unmaintained? Here is a version that does standard 1000baseT support. http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2 Not really. I would rather leave it as-is, and deprecate it in favor of ethtool. It does make a handy debug tool when driver isn't doing MII correctly. -- 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 v1.7 rx error...
On 26/09/06, Stephen Hemminger [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006 21:09:31 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: The server processor is a Pentium-M 1.7GHz (ondemand governor, from 0.6GHz - 1.7GHz). Gigabit path from server - switch - client. Client runs WinXP, Core2Duo 2.13GHz, Realtek RTL8168/8111 PCI-e NIC. Flow contol enabled in both directions, both for client and server: sky2 lan0: Link is up at 1000 Mbps, full duplex, flow control both Jumbo frames are in use on the tx side of server only - MTU 9000. I reproduced this with sky2 v1.7 with non-jumbo MTU 1500 frames too. Let me know if there is any further information I can grab and/or any other settings/tweaks/patches I can try. Dan On 26/09/06, Stephen Hemminger [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006 18:58:40 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: I got a this message with sky2 on 2.6.18 + the sky2 v1.7 patches - it has different status bits set than before (0x977d977d): kernel: sky2 lan0: rx error, status 0x377d377d length 0 Great work so far though - this race takes a while to hit! Dan What speed processor? Are you using receive flow control? Are you using Jumbo frames? -- Stephen Hemminger [EMAIL PROTECTED] Statistics? ethtool -S eth0 Does it hang after this? It looks like a receive fifo overflow, that happens when the receive ring gets full. You could try increasing RX_LE_SIZE from 512 to 1024. That would eat more memory (510 packets) but might avoid the problem. Other possible solutions would be to reduce the coalescing timer values with ethtool. ethtool -c eth1 ethtool -C eth1 rx-usecs 10 rx-usecs-irq 10 rx-iframes-irq 4 When it happens next time, I'll send you the stats. For now, I've increased the receive list entries to 1024. Ping me if you'd like me to test anything else - it may take a few weeks before I find this again (unless I try). Dan -- Daniel J Blueman - 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 backport] RTL8168 ethernet support in r8169
Francois Romieu wrote:
Daniel Drake [EMAIL PROTECTED] :
[...]
static struct pci_device_id rtl8169_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), },
- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
- { PCI_DEVICE(0x16ec,0x0116), },
- { PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_1 },
Should be RTL_CFG_2 (but there are still issues with the link management).
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_1 },
^
Should be RTL_CFG_1.
Thanks. I only really wanted to include the patch for the 8168 support
rather than the larger patch which has some unrelated changes. I went
ahead and updated the patch with the above changes incase someone comes
along with that hardware anyway :)
From: Francois Romieu [EMAIL PROTECTED]
Date: Wed, 26 Jul 2006 21:14:13 + (+0200)
Subject: r8169: sync with vendor's driver
X-Git-Tag: v2.6.18-rc3
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bcf0bf90cd9e9242b66e0563b6a8c8db2e4c262c
r8169: sync with vendor's driver
- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
Explanation: the in-kernel Linux driver is written to allow MM register
accesses and avoid the IO tax. The relevant BAR register was found at
base address 1 for the plain-old PCI 8169. User reported lspci show that
it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
Typically:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)
Subsystem: Unknown device 1631:e015
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR-
Latency: 0, cache line size 20
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at b800 [size=256]
Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
So far I have not received any lspci report for the 0x8136 and
Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
include a USE_IO_SPACE #define but the bar address is always hardcoded
to 1 in the MM case. :o/
- the 8168 has been reported to require an extra alignment for its receive
buffers. The status of the 8167 and 8136 is not known in this regard.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Rediffed for 2.6.18 by Daniel Drake [EMAIL PROTECTED]
Also includes commits d2eed8cff9a1a5d7e12ec9ddf71432c466b104d0 and
d81bf551103cc3bc9e4f7ddf337511d6da0d088f
---
Index: linux-2.6.18/drivers/net/r8169.c
===
--- linux-2.6.18.orig/drivers/net/r8169.c
+++ linux-2.6.18/drivers/net/r8169.c
@@ -150,11 +150,16 @@ static const int multicast_filter_limit
#define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg)))
enum mac_version {
- RTL_GIGA_MAC_VER_B = 0x00,
- /* RTL_GIGA_MAC_VER_C = 0x03, */
- RTL_GIGA_MAC_VER_D = 0x01,
- RTL_GIGA_MAC_VER_E = 0x02,
- RTL_GIGA_MAC_VER_X = 0x04 /* Greater than RTL_GIGA_MAC_VER_E */
+ RTL_GIGA_MAC_VER_01 = 0x00,
+ RTL_GIGA_MAC_VER_02 = 0x01,
+ RTL_GIGA_MAC_VER_03 = 0x02,
+ RTL_GIGA_MAC_VER_04 = 0x03,
+ RTL_GIGA_MAC_VER_05 = 0x04,
+ RTL_GIGA_MAC_VER_11 = 0x0b,
+ RTL_GIGA_MAC_VER_12 = 0x0c,
+ RTL_GIGA_MAC_VER_13 = 0x0d,
+ RTL_GIGA_MAC_VER_14 = 0x0e,
+ RTL_GIGA_MAC_VER_15 = 0x0f
};
enum phy_version {
@@ -166,7 +171,6 @@ enum phy_version {
RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */
};
-
#define _R(NAME,MAC,MASK) \
{ .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
@@ -175,19 +179,44 @@ static const struct {
u8 mac_version;
u32 RxConfigMask; /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
- _R(RTL8169, RTL_GIGA_MAC_VER_B, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_D, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_E, 0xff7e1880),
- _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_X, 0xff7e1880),
+ _R(RTL8169, RTL_GIGA_MAC_VER_01, 0xff7e1880),
+ _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_02, 0xff7e1880),
+ _R(RTL8169s/8110s, RTL_GIGA_MAC_VER_03, 0xff7e1880),
+ _R(RTL8169sb/8110sb, RTL_GIGA_MAC_VER_04, 0xff7e1880),
+ _R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_05, 0xff7e1880),
+ _R(RTL8168b/8111b, RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
+ _R(RTL8168b/8111b, RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
+
[PATCH 2/8] sky2: use standard pci register capabilties for error register
Use the standard pci capability mechanism to access PCI express error
registers, rather than hard coding the offset. Mask off the PCI express
error from ever occuring on non-PCI express systems.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 32 +++-
drivers/net/sky2.h | 45 ++---
2 files changed, 25 insertions(+), 52 deletions(-)
--- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:00.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:02.0 -0700
@@ -2093,7 +2093,7 @@
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
sky2_pci_write16(hw, PCI_STATUS,
- pci_err | PCI_STATUS_ERROR_BITS);
+pci_err | PCI_STATUS_ERROR_BITS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
@@ -2101,7 +2101,8 @@
/* PCI-Express uncorrectable Error occurred */
u32 pex_err;
- pex_err = sky2_pci_read32(hw, PEX_UNC_ERR_STAT);
+ pex_err = sky2_pci_read32(hw,
+ hw-err_cap + PCI_ERR_UNCOR_STATUS);
if (net_ratelimit())
printk(KERN_ERR PFX %s: pci express error (0x%x)\n,
@@ -2109,15 +2110,20 @@
/* clear the interrupt */
sky2_write32(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- sky2_pci_write32(hw, PEX_UNC_ERR_STAT,
- 0xUL);
+ sky2_pci_write32(hw,
+hw-err_cap + PCI_ERR_UNCOR_STATUS,
+0xUL);
sky2_write32(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
- if (pex_err PEX_FATAL_ERRORS) {
+
+ /* In case of fatal error mask off to keep from getting stuck */
+ if (pex_err (PCI_ERR_UNC_POISON_TLP | PCI_ERR_UNC_FCP
+ | PCI_ERR_UNC_DLP)) {
u32 hwmsk = sky2_read32(hw, B0_HWE_IMSK);
hwmsk = ~Y2_IS_PCI_EXP;
sky2_write32(hw, B0_HWE_IMSK, hwmsk);
}
+
}
if (status Y2_HWE_L1_MASK)
@@ -2298,6 +2304,7 @@
u16 status;
u8 t8;
int i;
+ u32 msk;
sky2_write8(hw, B0_CTST, CS_RST_CLR);
@@ -2338,9 +2345,13 @@
sky2_write8(hw, B0_CTST, CS_MRST_CLR);
/* clear any PEX errors */
- if (pci_find_capability(hw-pdev, PCI_CAP_ID_EXP))
- sky2_pci_write32(hw, PEX_UNC_ERR_STAT, 0xUL);
-
+ if (pci_find_capability(hw-pdev, PCI_CAP_ID_EXP)) {
+ hw-err_cap = pci_find_ext_capability(hw-pdev,
PCI_EXT_CAP_ID_ERR);
+ if (hw-err_cap)
+ sky2_pci_write32(hw,
+hw-err_cap + PCI_ERR_UNCOR_STATUS,
+0xUL);
+ }
hw-pmd_type = sky2_read8(hw, B2_PMD_TYP);
hw-ports = 1;
@@ -2397,7 +2408,10 @@
sky2_write8(hw, RAM_BUFFER(i, B3_RI_RTO_XS2), SK_RI_TO_53);
}
- sky2_write32(hw, B0_HWE_IMSK, Y2_HWE_ALL_MASK);
+ msk = Y2_HWE_ALL_MASK;
+ if (!hw-err_cap)
+ msk = ~Y2_IS_PCI_EXP;
+ sky2_write32(hw, B0_HWE_IMSK, msk);
for (i = 0; i hw-ports; i++)
sky2_gmac_reset(hw, i);
--- netdev-2.6.orig/drivers/net/sky2.h 2006-09-25 10:54:17.0 -0700
+++ netdev-2.6/drivers/net/sky2.h 2006-09-25 15:23:02.0 -0700
@@ -4,24 +4,15 @@
#ifndef _SKY2_H
#define _SKY2_H
-/* PCI config registers */
+/* PCI device specific config registers */
enum {
PCI_DEV_REG1= 0x40,
PCI_DEV_REG2= 0x44,
- PCI_DEV_STATUS = 0x7c,
PCI_DEV_REG3= 0x80,
PCI_DEV_REG4= 0x84,
PCI_DEV_REG5= 0x88,
};
-enum {
- PEX_DEV_CAP = 0xe4,
- PEX_DEV_CTRL= 0xe8,
- PEX_DEV_STA = 0xea,
- PEX_LNK_STAT= 0xf2,
- PEX_UNC_ERR_STAT= 0x104,
-};
-
/* Yukon-2 */
enum pci_dev_reg_1 {
PCI_Y2_PIG_ENA = 131, /* Enable Plug-in-Go (YUKON-2) */
@@ -70,39 +61,6 @@
PCI_STATUS_REC_MASTER_ABORT | \
PCI_STATUS_REC_TARGET_ABORT | \
PCI_STATUS_PARITY)
-
-enum pex_dev_ctrl {
- PEX_DC_MAX_RRS_MSK = 712, /* Bit 14..12: Max. Read Request Size
*/
- PEX_DC_EN_NO_SNOOP = 111,/* Enable No Snoop */
- PEX_DC_EN_AUX_POW = 110,/* Enable AUX Power */
- PEX_DC_EN_PHANTOM = 19, /* Enable Phantom Functions */
- PEX_DC_EN_EXT_TAG = 18, /* Enable Extended Tag Field */
- PEX_DC_MAX_PLS_MSK = 75, /* Bit 7.. 5: Max. Payload Size Mask
*/
- PEX_DC_EN_REL_ORD = 14, /* Enable Relaxed Ordering */
[PATCH 8/8] sky2: fragmented receive for large MTU
Version 1.9 is for 2.6.19. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/sky2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:26.0 -0700 +++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:28.0 -0700 @@ -50,7 +50,7 @@ #include sky2.h #define DRV_NAME sky2 -#define DRV_VERSION1.7 +#define DRV_VERSION1.9 #define PFXDRV_NAME /* - 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/8] sky2: workarounds for some 88e806x chips
Workarounds for 88e806x chips from the vendor driver. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/sky2.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) --- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:02.0 -0700 +++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:13.0 -0700 @@ -1124,7 +1124,8 @@ sky2_qset(hw, txqaddr[port]); /* Set almost empty threshold */ - if (hw-chip_id == CHIP_ID_YUKON_EC_U hw-chip_rev == 1) + if (hw-chip_id == CHIP_ID_YUKON_EC_U +hw-chip_rev == CHIP_REV_YU_EC_U_A0) sky2_write16(hw, Q_ADDR(txqaddr[port], Q_AL), 0x1a0); sky2_prefetch_init(hw, txqaddr[port], sky2-tx_le_map, @@ -1443,6 +1444,13 @@ sky2_write32(hw, RB_ADDR(txqaddr[port], RB_CTRL), RB_RST_SET | RB_DIS_OP_MD); + /* WA for dev. #4.209 */ + if (hw-chip_id == CHIP_ID_YUKON_EC_U +hw-chip_rev == CHIP_REV_YU_EC_U_A1) + sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T), +sky2-speed != SPEED_1000 ? +TX_STFW_ENA : TX_STFW_DIS); + ctrl = gma_read16(hw, port, GM_GP_CTRL); ctrl = ~(GM_GPCR_TX_ENA | GM_GPCR_RX_ENA); gma_write16(hw, port, GM_GP_CTRL, ctrl); - 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 7/8] sky2: fragmented receive for large MTU
Use hardware support for chained receive to break up large frames
into multiple pages. This avoids having to do a mult-page allocation
that can fail on a busy system due to fragmented memory.
For normal size MTU, this code behaves the same.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 290 ++---
drivers/net/sky2.h | 10 +
2 files changed, 219 insertions(+), 81 deletions(-)
--- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:25.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:26.0 -0700
@@ -56,13 +56,12 @@
/*
* The Yukon II chipset takes 64 bit command blocks (called list elements)
* that are organized into three (receive, transmit, status) different rings
- * similar to Tigon3. A transmit can require several elements;
- * a receive requires one (or two if using 64 bit dma).
+ * similar to Tigon3.
*/
-#define RX_LE_SIZE 512
+#define RX_LE_SIZE 1024
#define RX_LE_BYTES(RX_LE_SIZE*sizeof(struct sky2_rx_le))
-#define RX_MAX_PENDING (RX_LE_SIZE/2 - 2)
+#define RX_MAX_PENDING (RX_LE_SIZE/6 - 2)
#define RX_DEF_PENDING RX_MAX_PENDING
#define RX_SKB_ALIGN 8
#define RX_BUF_WRITE 16
@@ -74,7 +73,6 @@
#define STATUS_RING_SIZE 2048/* 2 ports * (TX + 2*RX) */
#define STATUS_LE_BYTES(STATUS_RING_SIZE*sizeof(struct
sky2_status_le))
-#define ETH_JUMBO_MTU 9000
#define TX_WATCHDOG(5 * HZ)
#define NAPI_WEIGHT64
#define PHY_RETRIES1000
@@ -90,7 +88,7 @@
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, Debug level (0=none,...,16=all));
-static int copybreak __read_mostly = 256;
+static int copybreak __read_mostly = 128;
module_param(copybreak, int, 0);
MODULE_PARM_DESC(copybreak, Receive copy threshold);
@@ -803,12 +801,12 @@
return sizeof(a) sizeof(u32) ? (a 16) 16 : 0;
}
-/* Build description to hardware about buffer */
-static void sky2_rx_add(struct sky2_port *sky2, dma_addr_t map)
+/* Build description to hardware for one receive segment */
+static void sky2_rx_add(struct sky2_port *sky2, u8 op,
+ dma_addr_t map, unsigned len)
{
struct sky2_rx_le *le;
u32 hi = high32(map);
- u16 len = sky2-rx_bufsize;
if (sky2-rx_addr64 != hi) {
le = sky2_next_rx(sky2);
@@ -820,10 +818,53 @@
le = sky2_next_rx(sky2);
le-addr = cpu_to_le32((u32) map);
le-length = cpu_to_le16(len);
- le-opcode = OP_PACKET | HW_OWNER;
+ le-opcode = op | HW_OWNER;
+}
+
+/* Build description to hardware for one possibly fragmented skb */
+static void sky2_rx_submit(struct sky2_port *sky2,
+ const struct rx_ring_info *re)
+{
+ int i;
+
+ sky2_rx_add(sky2, OP_PACKET, re-data_addr, sky2-rx_data_size);
+
+ for (i = 0; i skb_shinfo(re-skb)-nr_frags; i++)
+ sky2_rx_add(sky2, OP_BUFFER, re-frag_addr[i], PAGE_SIZE);
}
+static void sky2_rx_map_skb(struct pci_dev *pdev, struct rx_ring_info *re,
+ unsigned size)
+{
+ struct sk_buff *skb = re-skb;
+ int i;
+
+ re-data_addr = pci_map_single(pdev, skb-data, size,
PCI_DMA_FROMDEVICE);
+ pci_unmap_len_set(re, data_size, size);
+
+ for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
+ re-frag_addr[i] = pci_map_page(pdev,
+ skb_shinfo(skb)-frags[i].page,
+
skb_shinfo(skb)-frags[i].page_offset,
+ skb_shinfo(skb)-frags[i].size,
+ PCI_DMA_FROMDEVICE);
+}
+
+static void sky2_rx_unmap_skb(struct pci_dev *pdev, struct rx_ring_info *re)
+{
+ struct sk_buff *skb = re-skb;
+ int i;
+
+ pci_unmap_single(pdev, re-data_addr, pci_unmap_len(re, data_size),
+PCI_DMA_FROMDEVICE);
+
+ for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
+ pci_unmap_page(pdev, re-frag_addr[i],
+ skb_shinfo(skb)-frags[i].size,
+ PCI_DMA_FROMDEVICE);
+}
+
/* Tell chip where to start receive checksum.
* Actually has two checksums, but set both same to avoid possible byte
* order problems.
@@ -886,9 +927,7 @@
struct rx_ring_info *re = sky2-rx_ring + i;
if (re-skb) {
- pci_unmap_single(sky2-hw-pdev,
-re-mapaddr, sky2-rx_bufsize,
-PCI_DMA_FROMDEVICE);
+ sky2_rx_unmap_skb(sky2-hw-pdev, re);
kfree_skb(re-skb);
re-skb = NULL;
}
@@ -969,38 +1008,57 @@
#endif
/*
+ * Allocate an skb for receiving. If the MTU
[PATCH 1/8] sky2: gigabit full duplex autonegotiate
(vger gagged on the quilt version of these patches)
Look at the registers correctly, when doing gigabit full duplex.
Need to look for link partner result.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
--- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 10:54:17.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-09-25 10:58:27.0 -0700
@@ -1624,22 +1624,33 @@
return -1;
}
- if (hw-chip_id != CHIP_ID_YUKON_FE
- gm_phy_read(hw, port, PHY_MARV_1000T_STAT) PHY_B_1000S_MSF) {
- printk(KERN_ERR PFX %s: master/slave fault,
- sky2-netdev-name);
- return -1;
- }
-
if (!(aux PHY_M_PS_SPDUP_RES)) {
printk(KERN_ERR PFX %s: speed/duplex mismatch,
sky2-netdev-name);
return -1;
}
- sky2-duplex = (aux PHY_M_PS_FULL_DUP) ? DUPLEX_FULL : DUPLEX_HALF;
-
sky2-speed = sky2_phy_speed(hw, aux);
+ if (sky2-speed == SPEED_1000) {
+ u16 ctl2 = gm_phy_read(hw, port, PHY_MARV_1000T_CTRL);
+ u16 lpa2 = gm_phy_read(hw, port, PHY_MARV_1000T_STAT);
+ if (lpa2 PHY_B_1000S_MSF) {
+ printk(KERN_ERR PFX %s: master/slave fault,
+ sky2-netdev-name);
+ return -1;
+ }
+
+ if ((ctl2 PHY_M_1000C_AFD) (lpa2 PHY_B_1000S_LP_FD))
+ sky2-duplex = DUPLEX_FULL;
+ else
+ sky2-duplex = DUPLEX_HALF;
+ } else {
+ u16 adv = gm_phy_read(hw, port, PHY_MARV_AUNE_ADV);
+ if ((aux adv) PHY_AN_FULL)
+ sky2-duplex = DUPLEX_FULL;
+ else
+ sky2-duplex = DUPLEX_HALF;
+ }
/* Pause bits are offset (9..8) */
if (hw-chip_id == CHIP_ID_YUKON_XL || hw-chip_id ==
CHIP_ID_YUKON_EC_U)
-
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/8] sky2: name irq after eth for irqbalance
Use the ethernet device name when requesting the irq because the
irqbalance daemon looks for the name when deciding policy.
Better to play along with this dubious heuristic.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
--- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:13.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:16.0 -0700
@@ -3349,6 +3349,14 @@
if (!dev)
goto err_out_free_pci;
+ if (!disable_msi pci_enable_msi(pdev) == 0) {
+ err = sky2_test_msi(hw);
+ if (err == -EOPNOTSUPP)
+ pci_disable_msi(pdev);
+ else if (err)
+ goto err_out_free_netdev;
+ }
+
err = register_netdev(dev);
if (err) {
printk(KERN_ERR PFX %s: cannot register net device\n,
@@ -3356,6 +3364,14 @@
goto err_out_free_netdev;
}
+ err = request_irq(pdev-irq, sky2_intr, IRQF_SHARED, dev-name, hw);
+ if (err) {
+ printk(KERN_ERR PFX %s: cannot assign irq %d\n,
+ pci_name(pdev), pdev-irq);
+ goto err_out_unregister;
+ }
+ sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+
sky2_show_addr(dev);
if (hw-ports 1 (dev1 = sky2_init_netdev(hw, 1, using_dac))) {
@@ -3370,23 +3386,6 @@
}
}
- if (!disable_msi pci_enable_msi(pdev) == 0) {
- err = sky2_test_msi(hw);
- if (err == -EOPNOTSUPP)
- pci_disable_msi(pdev);
- else if (err)
- goto err_out_unregister;
- }
-
- err = request_irq(pdev-irq, sky2_intr, IRQF_SHARED, DRV_NAME, hw);
- if (err) {
- printk(KERN_ERR PFX %s: cannot assign irq %d\n,
- pci_name(pdev), pdev-irq);
- goto err_out_unregister;
- }
-
- sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
-
setup_timer(hw-idle_timer, sky2_idle, (unsigned long) hw);
sky2_idle_start(hw);
@@ -3396,10 +3395,6 @@
err_out_unregister:
pci_disable_msi(pdev);
- if (dev1) {
- unregister_netdev(dev1);
- free_netdev(dev1);
- }
unregister_netdev(dev);
err_out_free_netdev:
free_netdev(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 5/8] sky2: incremental transmit completion
Since a transmit can take several control blocks, the old code waited
until the last control block was marked as done. This code processes
the return values incrementally. This makes slots in the tx ring available
and less chance of getting stuck.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 95 ++---
drivers/net/sky2.h |6 +--
2 files changed, 50 insertions(+), 51 deletions(-)
--- netdev-2.6.orig/drivers/net/sky2.c 2006-09-25 15:23:16.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-09-25 15:23:23.0 -0700
@@ -769,9 +769,16 @@
struct sky2_tx_le *le = sky2-tx_le + sky2-tx_prod;
sky2-tx_prod = RING_NEXT(sky2-tx_prod, TX_RING_SIZE);
+ le-ctrl = 0;
return le;
}
+static inline struct tx_ring_info *tx_le_re(struct sky2_port *sky2,
+ struct sky2_tx_le *le)
+{
+ return sky2-tx_ring + (le - sky2-tx_le);
+}
+
/* Update chip's next pointer */
static inline void sky2_put_idx(struct sky2_hw *hw, unsigned q, u16 idx)
{
@@ -786,6 +793,7 @@
{
struct sky2_rx_le *le = sky2-rx_le + sky2-rx_put;
sky2-rx_put = RING_NEXT(sky2-rx_put, RX_LE_SIZE);
+ le-ctrl = 0;
return le;
}
@@ -805,7 +813,6 @@
if (sky2-rx_addr64 != hi) {
le = sky2_next_rx(sky2);
le-addr = cpu_to_le32(hi);
- le-ctrl = 0;
le-opcode = OP_ADDR64 | HW_OWNER;
sky2-rx_addr64 = high32(map + len);
}
@@ -813,7 +820,6 @@
le = sky2_next_rx(sky2);
le-addr = cpu_to_le32((u32) map);
le-length = cpu_to_le16(len);
- le-ctrl = 0;
le-opcode = OP_PACKET | HW_OWNER;
}
@@ -877,7 +883,7 @@
memset(sky2-rx_le, 0, RX_LE_BYTES);
for (i = 0; i sky2-rx_pending; i++) {
- struct ring_info *re = sky2-rx_ring + i;
+ struct rx_ring_info *re = sky2-rx_ring + i;
if (re-skb) {
pci_unmap_single(sky2-hw-pdev,
@@ -1008,7 +1014,7 @@
rx_set_checksum(sky2);
for (i = 0; i sky2-rx_pending; i++) {
- struct ring_info *re = sky2-rx_ring + i;
+ struct rx_ring_info *re = sky2-rx_ring + i;
re-skb = sky2_alloc_skb(sky2-netdev, sky2-rx_bufsize,
GFP_KERNEL);
@@ -1094,7 +1100,7 @@
goto err_out;
memset(sky2-rx_le, 0, RX_LE_BYTES);
- sky2-rx_ring = kcalloc(sky2-rx_pending, sizeof(struct ring_info),
+ sky2-rx_ring = kcalloc(sky2-rx_pending, sizeof(struct rx_ring_info),
GFP_KERNEL);
if (!sky2-rx_ring)
goto err_out;
@@ -1241,13 +1247,10 @@
mapping = pci_map_single(hw-pdev, skb-data, len, PCI_DMA_TODEVICE);
addr64 = high32(mapping);
- re = sky2-tx_ring + sky2-tx_prod;
-
/* Send high bits if changed or crosses boundary */
if (addr64 != sky2-tx_addr64 || high32(mapping + len) !=
sky2-tx_addr64) {
le = get_tx_le(sky2);
le-addr = cpu_to_le32(addr64);
- le-ctrl = 0;
le-opcode = OP_ADDR64 | HW_OWNER;
sky2-tx_addr64 = high32(mapping + len);
}
@@ -1263,7 +1266,6 @@
le = get_tx_le(sky2);
le-addr = cpu_to_le32(mss);
le-opcode = OP_LRGLEN | HW_OWNER;
- le-ctrl = 0;
sky2-tx_last_mss = mss;
}
}
@@ -1276,7 +1278,6 @@
le = get_tx_le(sky2);
le-addr = 0;
le-opcode = OP_VLAN|HW_OWNER;
- le-ctrl = 0;
} else
le-opcode |= OP_VLAN;
le-length = cpu_to_be16(vlan_tx_tag_get(skb));
@@ -1313,13 +1314,13 @@
le-ctrl = ctrl;
le-opcode = mss ? (OP_LARGESEND | HW_OWNER) : (OP_PACKET | HW_OWNER);
- /* Record the transmit mapping info */
+ re = tx_le_re(sky2, le);
re-skb = skb;
pci_unmap_addr_set(re, mapaddr, mapping);
+ pci_unmap_len_set(re, maplen, len);
for (i = 0; i skb_shinfo(skb)-nr_frags; i++) {
- skb_frag_t *frag = skb_shinfo(skb)-frags[i];
- struct tx_ring_info *fre;
+ const skb_frag_t *frag = skb_shinfo(skb)-frags[i];
mapping = pci_map_page(hw-pdev, frag-page, frag-page_offset,
frag-size, PCI_DMA_TODEVICE);
@@ -1338,12 +1339,12 @@
le-ctrl = ctrl;
le-opcode = OP_BUFFER | HW_OWNER;
- fre = sky2-tx_ring
- + RING_NEXT((re - sky2-tx_ring) + i, TX_RING_SIZE);
- pci_unmap_addr_set(fre, mapaddr, mapping);
+ re = tx_le_re(sky2, le);
+
Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
Or Gerlitz [EMAIL PROTECTED] wrote: + /* XXX set the bond dev type and addr len such that the net core code + * (eg arp_mc_map() in net/ipv4/arp.c) would correctly process multicast + * groups set ***before*** the first enslaveness + */ + bond_dev-type = bonding_dev_type; + bond_dev-addr_len = bonding_dev_addrlen; I've been thinking about this a little bit more. The system is understandably not set up to deal with this situation, since normal devices won't ever change their hardware type. 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. A side effect of this is that bonds would have to be restricted to consisting only of slaves of one hardware type, since slave changes (and thus hardware type changes) aren't necessarily restricted to user context. 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. -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
[PATCH] Add NETPOLL Support to SB1250 driver
Hello!
Attached patch adds NETPOLL support for the Sibyte Network driver.
Thanks,
Manish Lachwani
Source: MontaVista Software, Inc. | Manish Lachwani [EMAIL PROTECTED]
NETPOLL support for Sibyte MAC
drivers/net/sb1250-mac.c | 14 ++
1 files changed, 14 insertions(+)
Index: linux-2.6.18/drivers/net/sb1250-mac.c
===
--- linux-2.6.18.orig/drivers/net/sb1250-mac.c
+++ linux-2.6.18/drivers/net/sb1250-mac.c
@@ -1128,6 +1128,17 @@ static void sbdma_fillring(sbmacdma_t *d
}
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void sbmac_netpoll(struct net_device *netdev)
+{
+ struct sbmac_softc *sc = netdev_priv(netdev);
+ int irq = sc-sbm_dev-irq;
+
+ disable_irq(irq);
+ sbmac_intr(irq, netdev, NULL);
+ enable_irq(irq);
+}
+#endif
/**
* SBDMA_RX_PROCESS(sc,d)
@@ -2402,6 +2413,9 @@ static int sbmac_init(struct net_device
dev-watchdog_timeo = TX_TIMEOUT;
dev-change_mtu = sb1250_change_mtu;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev-poll_controller = sbmac_netpoll;
+#endif
/* This is needed for PASS2 for Rx H/W checksum feature */
sbmac_set_iphdr_offset(sc);
[PATCH] ieee80211: Move IV/ICV stripping into ieee80211_rx
This patch adds a host_strip_iv_icv flag to ieee80211 which indicates that
ieee80211_rx should strip the IV/ICV/other security features from the payload.
This saves on some memmove() calls in the driver and seems like something that
belongs in the stack as it can be used by bcm43xx, ipw2200, and zd1211rw
I will submit the ipw2200 patch separately as it needs testing.
This patch also adds some sensible variable reuse (idx vs keyidx) in
ieee80211_rx
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-by: Johannes Berg [EMAIL PROTECTED]
Index: linux/net/ieee80211/ieee80211_rx.c
===
--- linux.orig/net/ieee80211/ieee80211_rx.c
+++ linux/net/ieee80211/ieee80211_rx.c
@@ -415,17 +415,16 @@ int ieee80211_rx(struct ieee80211_device
ieee-host_mc_decrypt : ieee-host_decrypt;
if (can_be_decrypted) {
- int idx = 0;
if (skb-len = hdrlen + 3) {
/* Top two-bits of byte 3 are the key index */
- idx = skb-data[hdrlen + 3] 6;
+ keyidx = skb-data[hdrlen + 3] 6;
}
- /* ieee-crypt[] is WEP_KEY (4) in length. Given that idx
-* is only allowed 2-bits of storage, no value of idx can
-* be provided via above code that would result in idx
+ /* ieee-crypt[] is WEP_KEY (4) in length. Given that keyidx
+* is only allowed 2-bits of storage, no value of keyidx can
+* be provided via above code that would result in keyidx
* being out of range */
- crypt = ieee-crypt[idx];
+ crypt = ieee-crypt[keyidx];
#ifdef NOT_YET
sta = NULL;
@@ -655,6 +654,51 @@ int ieee80211_rx(struct ieee80211_device
goto rx_dropped;
}
+ /* If the frame was decrypted in hardware, we may need to strip off
+* any security data (IV, ICV, etc) that was left behind */
+ if (!can_be_decrypted (fc IEEE80211_FCTL_PROTECTED)
+ ieee-host_strip_iv_icv) {
+ int trimlen = 0;
+
+ /* Top two-bits of byte 3 are the key index */
+ if (skb-len = hdrlen + 3)
+ keyidx = skb-data[hdrlen + 3] 6;
+
+ /* To strip off any security data which appears before the
+* payload, we simply increase hdrlen (as the header gets
+* chopped off immediately below). For the security data which
+* appears after the payload, we use skb_trim. */
+
+ switch (ieee-sec.encode_alg[keyidx]) {
+ case SEC_ALG_WEP:
+ /* 4 byte IV */
+ hdrlen += 4;
+ /* 4 byte ICV */
+ trimlen = 4;
+ break;
+ case SEC_ALG_TKIP:
+ /* 4 byte IV, 4 byte ExtIV */
+ hdrlen += 8;
+ /* 8 byte MIC, 4 byte ICV */
+ trimlen = 12;
+ break;
+ case SEC_ALG_CCMP:
+ /* 8 byte CCMP header */
+ hdrlen += 8;
+ /* 8 byte MIC */
+ trimlen = 8;
+ break;
+ }
+
+ if (skb-len trimlen)
+ goto rx_dropped;
+
+ __skb_trim(skb, skb-len - trimlen);
+
+ if (skb-len hdrlen)
+ goto rx_dropped;
+ }
+
/* skb: hdr + (possible reassembled) full plaintext payload */
payload = skb-data + hdrlen;
Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ linux/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,25 +543,6 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
- frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
- if ((frame_ctl IEEE80211_FCTL_PROTECTED) !bcm-ieee-host_decrypt)
{
- frame_ctl = ~IEEE80211_FCTL_PROTECTED;
- wlhdr-frame_ctl = cpu_to_le16(frame_ctl);
- /* trim IV and ICV */
- /* FIXME: this must be done only for WEP encrypted packets */
- if (skb-len 32) {
- dprintkl(KERN_ERR PFX RX packet dropped (PROTECTED
flag
- set and length 32)\n);
- return -EINVAL;
- } else {
- memmove(skb-data + 4, skb-data, 24);
- skb_pull(skb, 4);
- skb_trim(skb, skb-len - 4);
- stats.len -= 8;
- }
- wlhdr = (struct ieee80211_hdr_4addr *)(skb-data);
-
Re: [PATCH] ieee80211: Move IV/ICV stripping into ieee80211_rx
Daniel Drake wrote:
This patch adds a host_strip_iv_icv flag to ieee80211 which indicates that
ieee80211_rx should strip the IV/ICV/other security features from the payload.
This saves on some memmove() calls in the driver and seems like something that
belongs in the stack as it can be used by bcm43xx, ipw2200, and zd1211rw
I will submit the ipw2200 patch separately as it needs testing.
This patch also adds some sensible variable reuse (idx vs keyidx) in
ieee80211_rx
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-by: Johannes Berg [EMAIL PROTECTED]
Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ linux/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,25 +543,6 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
- frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
- if ((frame_ctl IEEE80211_FCTL_PROTECTED) !bcm-ieee-host_decrypt)
{
- frame_ctl = ~IEEE80211_FCTL_PROTECTED;
- wlhdr-frame_ctl = cpu_to_le16(frame_ctl);
- /* trim IV and ICV */
- /* FIXME: this must be done only for WEP encrypted packets */
- if (skb-len 32) {
- dprintkl(KERN_ERR PFX RX packet dropped (PROTECTED flag
- set and length 32)\n);
- return -EINVAL;
- } else {
- memmove(skb-data + 4, skb-data, 24);
- skb_pull(skb, 4);
- skb_trim(skb, skb-len - 4);
- stats.len -= 8;
- }
- wlhdr = (struct ieee80211_hdr_4addr *)(skb-data);
- }
-
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
At this point, gcc warns that frame_ctl has been used uninitialized. Did you mean to remove the
extraction of frame_ctl from wlhdr just before the previous 'if'?
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: 2.6.18-mm1 -- ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221.
[added netdev] On Tue, 26 Sep 2006 12:04:40 -0700 Miles Lane [EMAIL PROTECTED] wrote: ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. From dmesg output: ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' I suspect that whatever caused this is now in mainline. Are you able to test Linus's current git tree? Thanks. - 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
Generic HDLC update
Hi, Jeff, in this thread I'm posting two patches: - 1/2: modularizes generic HDLC code - WAN protocols (FR, Cisco HDLC etc.) can now be separate modules. We can now have multiple module versions for a protocol (something like syncppp-based PPP or based on generic PPP). Also we don't have to load things like syncppp or lapb if we don't need it. Core generic HDLC code doesn't now know anything about the WAN protocols - all protocol-related information has been moved from hdlc.h to the protocol drivers. - 2/2: while both user-space and low-level driver interfaces are not changed by the first patch, it has to change data structures internal to the generic HDLC. Unfortunately, there is one particular driver - pc300 - abusing those internal structures. There are few ways to fix this driver but it's not trivial. PC300 maintainer has been notified about the problem and possible solutions, and has been sent a copy of the modularizing patch two+ months ago. This patch removes accesses to the HDLC-internal data structures from pc300 driver, thus enabling it to compile but breaking part of its functionality. Please apply both patches to Linux 2.6. Thanks. -- Krzysztof Halasa - 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/2] Make PC300 WAN driver compile again
This patch removes accesses to the HDLC-internal data structures
from pc300 driver, thus enabling it to compile but breaking part
of its functionality.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/drivers/net/wan/pc300_drv.c b/drivers/net/wan/pc300_drv.c
index 56e6940..8d9b959 100644
--- a/drivers/net/wan/pc300_drv.c
+++ b/drivers/net/wan/pc300_drv.c
@@ -2016,7 +2016,6 @@ static void sca_intr(pc300_t * card)
pc300ch_t *chan = card-chan[ch];
pc300dev_t *d = chan-d;
struct net_device *dev = d-dev;
- hdlc_device *hdlc = dev_to_hdlc(dev);
spin_lock(card-card_lock);
@@ -2049,8 +2048,8 @@ #endif
}
cpc_net_rx(dev);
/* Discard invalid
frames */
- hdlc-stats.rx_errors++;
-
hdlc-stats.rx_over_errors++;
+
hdlc_stats(dev)-rx_errors++;
+
hdlc_stats(dev)-rx_over_errors++;
chan-rx_first_bd = 0;
chan-rx_last_bd =
N_DMA_RX_BUF - 1;
rx_dma_start(card, ch);
@@ -2116,8 +2115,8 @@ #endif
card-hw.cpld_reg2)
~
(CPLD_REG2_FALC_LED1 (2 * ch)));
}
- hdlc-stats.tx_errors++;
- hdlc-stats.tx_fifo_errors++;
+ hdlc_stats(dev)-tx_errors++;
+
hdlc_stats(dev)-tx_fifo_errors++;
sca_tx_intr(d);
}
}
@@ -2534,7 +2533,6 @@ static int cpc_change_mtu(struct net_dev
static int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
- hdlc_device *hdlc = dev_to_hdlc(dev);
pc300dev_t *d = (pc300dev_t *) dev-priv;
pc300ch_t *chan = (pc300ch_t *) d-chan;
pc300_t *card = (pc300_t *) chan-card;
@@ -2552,10 +2550,10 @@ static int cpc_ioctl(struct net_device *
case SIOCGPC300CONF:
#ifdef CONFIG_PC300_MLPPP
if (conf-proto != PC300_PROTO_MLPPP) {
- conf-proto = hdlc-proto.id;
+ conf-proto = /* FIXME hdlc-proto.id */ 0;
}
#else
- conf-proto = hdlc-proto.id;
+ conf-proto = /* FIXME hdlc-proto.id */ 0;
#endif
memcpy(conf_aux.conf, conf, sizeof(pc300chconf_t));
memcpy(conf_aux.hw, card-hw, sizeof(pc300hw_t));
@@ -2588,12 +2586,12 @@ #ifdef CONFIG_PC300_MLPPP
}
} else {
memcpy(conf, conf_aux.conf,
sizeof(pc300chconf_t));
- hdlc-proto.id = conf-proto;
+ /* FIXME hdlc-proto.id = conf-proto;
*/
}
}
#else
memcpy(conf, conf_aux.conf, sizeof(pc300chconf_t));
- hdlc-proto.id = conf-proto;
+ /* FIXME hdlc-proto.id = conf-proto; */
#endif
return 0;
case SIOCGPC300STATUS:
@@ -2606,7 +2604,7 @@ #endif
case SIOCGPC300UTILSTATS:
{
if (!arg) { /* clear statistics */
- memset(hdlc-stats, 0, sizeof(struct
net_device_stats));
+ memset(hdlc_stats(dev), 0,
sizeof(struct net_device_stats));
if (card-hw.type == PC300_TE) {
memset(chan-falc, 0,
sizeof(falc_t));
}
@@ -2617,7 +2615,7 @@ #endif
pc300stats.hw_type = card-hw.type;
pc300stats.line_on =
card-chan[ch].d.line_on;
pc300stats.line_off =
card-chan[ch].d.line_off;
- memcpy(pc300stats.gen_stats,
hdlc-stats,
+ memcpy(pc300stats.gen_stats,
hdlc_stats(dev),
Re: Generic HDLC update
Jeff, The first patch renames drivers/net/wan/hdlc_generic.c file to hdlc.c. It has been generated with git-diff* -M. Please let me know if you need a normal patch. -- Krzysztof Halasa - 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/2] Modularize generic HDLC - now signed-off
applied 1-2 - 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: Generic HDLC update
Krzysztof Halasa wrote: The first patch renames drivers/net/wan/hdlc_generic.c file to hdlc.c. It has been generated with git-diff* -M. Please let me know if you need a normal patch. It depends completely on what git-applymbox will accept, and how git-applymbox interprets your submission. In this case... testing... it looks like it renamed things correctly. 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 1/2] Modularize generic HDLC - now signed-off
Jeff Garzik [EMAIL PROTECTED] writes: applied 1-2 Thanks. -- Krzysztof Halasa - 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-mm1 -- ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221.
On 9/26/06, Andrew Morton [EMAIL PROTECTED] wrote: [added netdev] On Tue, 26 Sep 2006 12:04:40 -0700 Miles Lane [EMAIL PROTECTED] wrote: ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. From dmesg output: ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' I suspect that whatever caused this is now in mainline. Are you able to test Linus's current git tree? Sorry, I don't have oodles of disk space free to hold all the git historical information (iirc, it's huge). I could conceivably put it together, but I'd been some help and time. I am currently travelling, but I do have my kernel test laptop with me. Also, I am currently staying in a building running off of solar power, so I need to be a bit careful with power consumption. I'll be in a place with AC power in five days. Lastly, I don't know how I triggered the problem. I am happy to try to reproduce it for you, though. Miles - 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, Sep 26, 2006 at 04:54:16PM +0100, Christoph Hellwig ([EMAIL PROTECTED]) wrote: Generic event handling mechanism. Consider for inclusion. Ulrich's objections sounded substantial, and afaik remain largely unresolved. How do we sort this out? I haven't seen any of Ulrichs points (which mostly is a large subset of my objection) beeing addressed. Could you please be more specific? As far as I can see I addressed all suggestions made by Christoph and still waiting for comments about my points after reply to Ulrich's. -- 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
[PATCH] bcm43xx: fix race condition in periodic work handler
From: Michael Buesch [EMAIL PROTECTED]
There is a potential race condition in the periodic_work_handler routine
of bcm43xx-softmac. In addition to fixing this condition, the size of code is
reduced by moving the mutex lock outside the if.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3164,12 +3164,12 @@ static void bcm43xx_periodic_work_handle
u32 savedirqs = 0;
int badness;
+ mutex_lock(bcm-mutex);
badness = estimate_periodic_work_badness(bcm-periodic_state);
if (badness BADNESS_LIMIT) {
/* Periodic work will take a long time, so we want it to
* be preemtible.
*/
- mutex_lock(bcm-mutex);
netif_tx_disable(bcm-net_dev);
spin_lock_irqsave(bcm-irq_lock, flags);
bcm43xx_mac_suspend(bcm);
@@ -3182,7 +3182,6 @@ static void bcm43xx_periodic_work_handle
/* Periodic work should take short time, so we want low
* locking overhead.
*/
- mutex_lock(bcm-mutex);
spin_lock_irqsave(bcm-irq_lock, flags);
}
-
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
