Re: [PATCH 2.6.18] WE-21 support (core API)
On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote: And I strongly disagree with your disagrement ;-) You're of course free to do that :) But let me explain. I'm sorry to say it like this, but I hope my work will not be impacted by vaporware. How many drivers are currently converted to nl80211 ? None, I have to admit, of course. But I hope you realise that I can impossibly convert all drivers at once and all by myself. I merely set out a framework in which it is easy to add new features, new calls and make things behave. The reason why those new features are good for you : o They give you a template on how you could implement those features in nl80211, saving you design time. Gack. I'm inclined to not even respond to this, but I am convinced that having all the unions and ill-defined semantics with one field having multiple meanings is in no way saving me design time because it's part of the problem I intend to completely avoid. o The goal is to replace private ioctls (driver specific) with standard ioctls. So, in other words, they actually *reduce* the historic baggage and make it easier to wrap around those functions if you want (I won't expect you to wrap around *every* WE). Actually, trust me, you will. Once drivers can no longer handle WEs by themselves because it's done centrally and over a shim layer in cfg80211, you will. Personally, I still have not seen the point of nl80211, as the full Wireless Extension is already available over NetLink (have you tried it ?). Actually, no. But that's beside the point anyway. Actually, I think that publishing WE over netlink was a mistake. See, my gripes with WE aren't how the interface works. I could live with an ioctl based interface forever, we have many of those and that's not really a problem. The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. There are too many special cases. Setting an ESSID to all-zeroes to disable something (or was it all-ones to disable??) might have seemed like a good idea 10 years ago, but I certainly think that putting this implicit behaviour into a modern interface is just asking for the kind of trouble that WE has. But, I shut up my big mouth, and let you work freely on it, as a mark of respect for your work and intentions, and also because something good may come out of it. :) Personally, I though that the plan that was more or less the consensus that the new API would be targeted mostly at the DeviceScape stack, as it seems difficult to offer the full feature set of that stack through WE. So, I would have expected the development of the new API to be somewhat in sync with the integration of the DeviceScape stack. Not at all. I plan to support all drivers over nl80211, even those that make no use of d80211. In fact, my current plan is to convert all drivers to nl80211 and put WE as a shim layer. Yes, that'll rip out a good part of your code, sorry about that. And if you look closely, you will realise the other features are also good for you ;-) Not really. More ioctls aren't good. Even if they replace private ones. Private ones were never really guaranteed anyway, so all the private ones that generically make sense (and shouldn't just be in debugfs instead...) shall be in nl80211 as well. 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.18] WE-21 support (core API)
On Thu, 2006-08-31 at 19:57 +0200, Michael Buesch wrote: It is. Nobody says different. I think with mainline Johannes meant the wireless-dev tree. Merging nl80211 with softmac would indeed not make sense to me, too. Actually, I do say different. I want softmac to be a consumer of nl80211 too, as well as all the fullmac drivers. I want to put all the ioctl handling and all the mess with implicit semantics and special cases into some common shim layer that simply calls the same methods you gave to nl80211, so that drivers never ever need to bother with WE again. 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/2]d80211: add hardware scan callback
On Fri, 2006-09-01 at 14:41, Johannes Berg wrote:
On Fri, 2006-09-01 at 11:37 +0800, Hong Liu wrote:
+ local-sta_scanning = 1;
+ if (local-hw-hw_scan)
+ return local-hw-hw_scan(dev, ssid, ssid_len);
+
My question still stands, is it proper to assign sta_scanning to 1 even
if the function returns an error?
johannes
Thanks for point this out!
Change to only set sta_scanning to 1 if hw_scan successes.
Signed-off-by: Hong Liu [EMAIL PROTECTED]
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 42fdbf7..1caa8a9 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -600,6 +600,10 @@ struct ieee80211_hw {
int (*passive_scan)(struct net_device *dev, int state,
struct ieee80211_scan_conf *conf);
+ /* Ask the hardware to service the scan request, no need to start
+* the scan state machine in stack. */
+ int (*hw_scan)(struct net_device *dev, u8 *ssid, size_t len);
+
/* return low-level statistics */
int (*get_stats)(struct net_device *dev,
struct ieee80211_low_level_stats *stats);
@@ -906,6 +910,8 @@ void ieee80211_tx_led(int state, struct
*/
void ieee80211_rx_led(int state, struct net_device *dev);
+/* called by driver to notify scan status completed */
+void ieee80211_scan_completed(struct net_device *dev);
/* IEEE 802.11 defines */
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 557ba17..1f60a22 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2410,6 +2410,29 @@ static int ieee80211_active_scan(struct
}
+void ieee80211_scan_completed(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev-ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ union iwreq_data wrqu;
+
+ printk(KERN_DEBUG %s: scan completed\n, dev-name);
+ local-sta_scanning = 0;
+ local-last_scan_completed = jiffies;
+
+ memset(wrqu, 0, sizeof(wrqu));
+ wireless_send_event(dev, SIOCGIWSCAN, wrqu, NULL);
+
+ if (sdata-type == IEEE80211_IF_TYPE_IBSS) {
+ struct ieee80211_if_sta *ifsta = sdata-u.sta;
+ if (!ifsta-bssid_set ||
+ (!ifsta-state == IEEE80211_IBSS_JOINED
+ !ieee80211_sta_active_ibss(dev)))
+ ieee80211_sta_find_ibss(dev, ifsta);
+ }
+}
+EXPORT_SYMBOL(ieee80211_scan_completed);
+
static void ieee80211_sta_scan_work(void *ptr)
{
struct net_device *dev = ptr;
@@ -2418,7 +2441,6 @@ static void ieee80211_sta_scan_work(void
struct ieee80211_hw_modes *mode;
struct ieee80211_channel *chan;
int skip;
- union iwreq_data wrqu;
unsigned long next_delay = 0;
if (!local-sta_scanning)
@@ -2435,20 +2457,8 @@ static void ieee80211_sta_scan_work(void
operational channel after scan\n,
dev-name);
}
- printk(KERN_DEBUG %s: scan completed\n, dev-name);
- local-sta_scanning = 0;
- local-last_scan_completed = jiffies;
- memset(wrqu, 0, sizeof(wrqu));
- wireless_send_event(dev, SIOCGIWSCAN, wrqu, NULL);
- if (sdata-type == IEEE80211_IF_TYPE_IBSS) {
- struct ieee80211_sub_if_data *sdata =
- IEEE80211_DEV_TO_SUB_IF(dev);
- struct ieee80211_if_sta *ifsta = sdata-u.sta;
- if (!ifsta-bssid_set ||
- (ifsta-state == IEEE80211_IBSS_JOINED
-!ieee80211_sta_active_ibss(dev)))
- ieee80211_sta_find_ibss(dev, ifsta);
- }
+
+ ieee80211_scan_completed(dev);
return;
}
skip = !(local-enabled_modes (1 mode-mode));
@@ -2549,6 +2559,13 @@ int ieee80211_sta_req_scan(struct net_de
printk(KERN_DEBUG %s: starting scan\n, dev-name);
+ if (local-hw-hw_scan) {
+ int rc = local-hw-hw_scan(dev, ssid, ssid_len);
+ if (!rc)
+ local-sta_scanning = 1;
+ return rc;
+ }
+
ieee80211_sta_save_oper_chan(dev);
local-sta_scanning = 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
[PATCH] neigh_table_clear() doesn't free stats
neigh_table_clear() doesn't free tbl-stats. Found by Alexey Kuznetsov. Though Alexey considers this leak minor for mainstream, I still believe that cleanup code should not forget to free some of the resources :) At least, this is critical for OpenVZ with virtualized neighbour tables. Signed-Off-By: Kirill Korotaev [EMAIL PROTECTED] diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 89b7904..a45bd21 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1429,6 +1429,9 @@ int neigh_table_clear(struct neigh_table kfree(tbl-phash_buckets); tbl-phash_buckets = NULL; + free_percpu(tbl-stats); + tbl-stats = NULL; + return 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] neigh_table_clear() doesn't free stats
From: Kirill Korotaev [EMAIL PROTECTED] Date: Fri, 01 Sep 2006 12:28:56 +0400 neigh_table_clear() doesn't free tbl-stats. Found by Alexey Kuznetsov. Though Alexey considers this leak minor for mainstream, I still believe that cleanup code should not forget to free some of the resources :) At least, this is critical for OpenVZ with virtualized neighbour tables. Signed-Off-By: Kirill Korotaev [EMAIL PROTECTED] Applied, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high latency with TCP connections
From: Pekka Savola [EMAIL PROTECTED] Date: Fri, 1 Sep 2006 12:44:48 +0300 (EEST) On Thu, 31 Aug 2006, David Miller wrote: ... Probably, aspect 1 of ABC just should be disabled. And the first my suggestion looks working too. I'm ready to rip out ABC entirely, to be honest. Or at least turn it off by default. Just as a curious observer: do you think these issues are due to ABC implementation, or due to ABC specification? It simply doesn't apply to us, as Alexey explained, because we prevent ACK divison already when we apply the ACK to the retransmit queue purging loop. If we didn't free any whole packets, we don't advance the congestion window. The other bit, dealing with delayed ACKs, we could handle another way. ABC is a very BSD specific algorithm, as Alexey also mentioned. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/4] ip_vs_ftp cleanups
Hi, This series of four patches has several minor cleanups for the options to the ip_vs_ftp modules. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/4] Make sure ip_vs_ftp ports are valid
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:06:42.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0 +0900
@@ -373,6 +373,12 @@
for (i=0; iIP_VS_APP_MAX_PORTS; i++) {
if (!ports[i])
continue;
+ if (ports[i] 0 || ports[i] 0x) {
+ IP_VS_WARNING(ip_vs_ftp: Ignoring invalid
+ configuration port[%d] = %d\n,
+ i, ports[i]);
+ continue;
+ }
ret = register_ip_vs_app_inc(app, app-protocol, ports[i]);
if (ret)
break;
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/4] Document the ports option to ip_vs_ftp in kernel-parameters.txt
I'm not sure if documenting this here is appropriate, but if it is, here is some text to put there. Signed-Off-By: Simon Horman [EMAIL PROTECTED] Index: linux-2.6/Documentation/kernel-parameters.txt === --- linux-2.6.orig/Documentation/kernel-parameters.txt 2006-09-01 17:02:10.0 +0900 +++ linux-2.6/Documentation/kernel-parameters.txt 2006-09-01 17:02:49.0 +0900 @@ -697,6 +697,12 @@ ips=[HW,SCSI] Adaptec / IBM ServeRAID controller See header of drivers/scsi/ips.c. + ports= [IP_VS_FTP] IPVS ftp helper module + Default is 21. + Up to 8 (IP_VS_APP_MAX_PORTS) ports + may be specified. + Format: port,port + irqfixup[HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken -- -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/4] remove the debug option go ip_vs_ftp
This patch makes the debuging behaviour of this code more consistent
with the rest of IPVS.
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:06:49.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:06:50.0 +0900
@@ -48,14 +48,6 @@
module_param_array(ports, int, NULL, 0);
MODULE_PARM_DESC(ports, Ports to monitor for FTP control commands);
-/*
- * Debug level
- */
-#ifdef CONFIG_IP_VS_DEBUG
-static int debug=0;
-module_param(debug, int, 0);
-#endif
-
/* Dummy variable */
static int ip_vs_ftp_pasv;
@@ -178,7 +170,7 @@
start, end) != 1)
return 1;
- IP_VS_DBG(1-debug, PASV response (%u.%u.%u.%u:%d) -
+ IP_VS_DBG(7, PASV response (%u.%u.%u.%u:%d) -
%u.%u.%u.%u:%d detected\n,
NIPQUAD(from), ntohs(port), NIPQUAD(cp-caddr), 0);
@@ -281,7 +273,7 @@
while (data = data_limit - 6) {
if (strnicmp(data, PASV\r\n, 6) == 0) {
/* Passive mode on */
- IP_VS_DBG(1-debug, got PASV at %zd of %zd\n,
+ IP_VS_DBG(7, got PASV at %zd of %zd\n,
data - data_start,
data_limit - data_start);
cp-app_data = ip_vs_ftp_pasv;
@@ -303,7 +295,7 @@
start, end) != 1)
return 1;
- IP_VS_DBG(1-debug, PORT %u.%u.%u.%u:%d detected\n,
+ IP_VS_DBG(7, PORT %u.%u.%u.%u:%d detected\n,
NIPQUAD(to), ntohs(port));
/* Passive mode off */
@@ -312,7 +304,7 @@
/*
* Now update or create a connection entry for it
*/
- IP_VS_DBG(1-debug, protocol %s %u.%u.%u.%u:%d %u.%u.%u.%u:%d\n,
+ IP_VS_DBG(7, protocol %s %u.%u.%u.%u:%d %u.%u.%u.%u:%d\n,
ip_vs_proto_name(iph-protocol),
NIPQUAD(to), ntohs(port), NIPQUAD(cp-vaddr), 0);
@@ -382,8 +374,8 @@
ret = register_ip_vs_app_inc(app, app-protocol, ports[i]);
if (ret)
break;
- IP_VS_DBG(1-debug, %s: loaded support on port[%d] = %d\n,
- app-name, i, ports[i]);
+ IP_VS_INFO(%s: loaded support on port[%d] = %d\n,
+ app-name, i, ports[i]);
}
if (ret)
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/4] auto-help for ip_vs_ftp
Fill in a help message for the ports option to ip_vs_ftp
Signed-Off-By: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:02:38.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:06:42.0 +0900
@@ -46,6 +46,7 @@
*/
static int ports[IP_VS_APP_MAX_PORTS] = {21, 0};
module_param_array(ports, int, NULL, 0);
+MODULE_PARM_DESC(ports, Ports to monitor for FTP control commands);
/*
* Debug level
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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: Unable to halt or reboot due to - unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1
On 31/08/06, Jesper Juhl [EMAIL PROTECTED] wrote: On 31/08/06, Ben Greear [EMAIL PROTECTED] wrote: Jesper Juhl wrote: Hi, I've got a small problem with 2.6.18-rc5-git2. I've got a vlan setup on eth0.20, eth0 does not have an IP. When I attempt to reboot or halt the machine I get the following message from the loop in net/core/dev.c::netdev_wait_allrefs() where it waits for the ref-count to drop to zero. Unfortunately the ref-count stays at 1 forever and the server never gets any further. unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1 I googled a bit and found that people have had similar problems in the past and could work around them by shutting down the vlan interface before the 'lo' interface. I tried that and indeed, it works. Any idea how we can get this fixed? This is usually a ref-count leak somewhere. Used to be IPv6 had issues..then there were some neighbor leaks...but these were fixed as far as I know. Using IPv4 here. Can you reproduce this on older kernels? I've not actively tried, but I do have several servers running various older kernel releases with similar vlan setups and I'm not aware of any problems with those. Only this new box that I'm using for testing new kernels (currently) shows the problem, and I've only tried 2.6.8 and 2.6.18-rc5-git2 on the box so far (2.6.8 doesn't have the problem). I've just encountered the problem on a different server with an identical vlan setup. That server is running 2.6.13.4 -- 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: Unable to halt or reboot due to - unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1
Jesper Juhl [EMAIL PROTECTED] wrote:
I've just encountered the problem on a different server with an
identical vlan setup. That server is running 2.6.13.4
Do you have a simple recipe to reproduce this? Ideally it'd be a
script that anyone can execute in a freshly booted system that
exhibits the problem.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Unable to halt or reboot due to - unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1
On 01/09/06, Herbert Xu [EMAIL PROTECTED] wrote: Jesper Juhl [EMAIL PROTECTED] wrote: I've just encountered the problem on a different server with an identical vlan setup. That server is running 2.6.13.4 Do you have a simple recipe to reproduce this? Ideally it'd be a script that anyone can execute in a freshly booted system that exhibits the problem. Well, the first server I saw this on only had a base install of debian stable on it, then I replaced the kernel, configured the vlan interface in /etc/network/interfaces typed 'reboot' and it failed - and it seems to fail reliably on reboot every time. -- 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: high latency with TCP connections
On Fri, Sep 01, 2006 at 01:47:15PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED]) wrote: Hello! problem. The problem is really at the receiver because we only ACK every other full sized frame. I had the idea to ACK every 2 frames, regardless of size, This would solve lots of problems. At least for slow start it is safe, but experiments with atcp for netchannels showed that it is better not to send excessive number of acks when slow start is over, instead we can introduce some tricky ack avoidance scheme and ack at least 2-3-4 packets or full MSS instead of two mss-sized frames. Alexey -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] 8139cp: misc minor changes
Pierre Ossman [EMAIL PROTECTED] : Ehm... why am I included in this? :) To preserve an happy 8139cp user :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: [PATCH 0/7] 8139cp: misc minor changes
Francois Romieu wrote: Pierre Ossman [EMAIL PROTECTED] : Ehm... why am I included in this? :) To preserve an happy 8139cp user :o) A noble endeavor. Carry on. ;) - 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: Unable to halt or reboot due to - unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1
On 01/09/06, Jesper Juhl [EMAIL PROTECTED] wrote: On 01/09/06, Herbert Xu [EMAIL PROTECTED] wrote: Jesper Juhl [EMAIL PROTECTED] wrote: I've just encountered the problem on a different server with an identical vlan setup. That server is running 2.6.13.4 Do you have a simple recipe to reproduce this? Ideally it'd be a script that anyone can execute in a freshly booted system that exhibits the problem. Well, the first server I saw this on only had a base install of debian stable on it, then I replaced the kernel, configured the vlan interface in /etc/network/interfaces typed 'reboot' and it failed - and it seems to fail reliably on reboot every time. Ok, I've done some more testing and it seems, unfortunately, that I can't trigger the problem reliably. I guess I was just lucky with my first few reboots. It now seems that uptime and/or amount of data that has flowed over the vlan interface impacts the probability of hitting the problem. -- 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: [RFC][IPSEC]: tunnel mode processing
On Fri, 2006-01-09 at 14:07 +1000, Herbert Xu wrote: On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote: Would it be reasonable to do a check so that incase a skb-dst doesnt exist, the inner headers values can be used i.e something along xfrm4_tunnel_output():: If you didn't care what values they were, couldn't you just stuff some bogus dst into the skb? That bogus dst is NULL ;- If this packet is going somewhere you're going to have a dst one way or another :) If i was going to use routing/layer 3, then true. At the pktgen level somewhere is just shove down the ether. Actually (i havent thought clearly about this) wouldnt a bump in the wire implementation aka bridging level also not care about route details? Note: This does not absolve the need for a secure ipid or a proper ttl. Also, the IPID is only generated if DF is not set on the packet. Otherwise this path is already as fast as it can be. In the case of traffic generation, if i could shave even more cycles the better since i want to generate high speed. In this case the cycles would be in creating a fake dst and attaching it some fake values. I do agree that it is an awkward way of achieving my goals - but i dont know of a clever way to do it ;- cheers, jamal - 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][IPSEC]: tunnel mode processing
On Fri, Sep 01, 2006 at 08:17:14AM -0400, jamal wrote:
In the case of traffic generation, if i could shave even more cycles the
better since i want to generate high speed. In this case the cycles
would be in creating a fake dst and attaching it some fake values.
Right, you're testing the receiver side. In that case I suggest that
you replicate the IPsec transport mode logic in the generator. Just
as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't
really need to use xfrm4_output.c to generate IPsec traffic.
You can still call down to esp4.c through the type pointer of course.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GENL]: Provide more information to userspace about registered genl families
On Fri, 2006-09-01 at 08:22 -0400, jamal wrote: Seems you may be talking about capabilities more than filtering? yes, I had sort of thought filtering would be that, but now that you say it I get the point :) Sorry, I havent had time to look at that code (is it in Daves tree?); No, it's not in any tree yet. if i understand you correctly - you have a superset of commands, and some users of those commands can only implement a subset? precisely. 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: [RFC][IPSEC]: tunnel mode processing
On Fri, 2006-01-09 at 22:22 +1000, Herbert Xu wrote: Right, you're testing the receiver side. both in/out sides (on the receiver); i just count and drop all packets coming back to the sender (the pktgenerator) In that case I suggest that you replicate the IPsec transport mode logic in the generator. Tunnel mode you mean, i think. Just as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't really need to use xfrm4_output.c to generate IPsec traffic. IPsec is slightly different since i need to use state in the core. i.e it is stateful. Nothing that pktgen does today has such requirements. You can still call down to esp4.c through the type pointer of course. Thats one idea i havent thought of. i.e the code would look like: - if (mode == tunnel) err = mytunneloutput (x, skb); else err = x-mode-output(x, skb); if (err) goto error; err = x-type-output(x, skb); -- This is what you are suggesting? I am probably better off going back to creating a dummy dst with just those two fields when in tunnel mode;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GENL]: Provide more information to userspace about registered genl families
On Fri, 2006-01-09 at 14:25 +0200, Johannes Berg wrote: On Fri, 2006-09-01 at 08:22 -0400, jamal wrote: Sorry, I havent had time to look at that code (is it in Daves tree?); No, it's not in any tree yet. Could you point me to it? I can look at it over the weekend. if i understand you correctly - you have a superset of commands, and some users of those commands can only implement a subset? precisely. It may be we need to add another feature to genl to accomodate this. Example by setting a flag to indicate supportability. However, it does sound like this is something your code needs to own in a capability set structure somewhere. I cant tell without looking at the code. cheers, jamal - 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][IPSEC]: tunnel mode processing
On Fri, Sep 01, 2006 at 08:56:18AM -0400, jamal wrote:
Thats one idea i havent thought of.
i.e the code would look like:
-
if (mode == tunnel)
err = mytunneloutput (x, skb);
else
err = x-mode-output(x, skb);
if (err)
goto error;
err = x-type-output(x, skb);
--
This is what you are suggesting?
Yes, I suppose you could even replace x-mode directly.
I am probably better off going back to creating a dummy dst with just
those two fields when in tunnel mode;-
Probably. Although if you write your own output function you could
make it go faster by adapting it to the specifics of pktgen.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] change netfilter tunables to __read_mostly
Brian Haley wrote:
Change some netfilter tunables to __read_mostly. Also fixed some
incorrect file reference comments while I was in there.
Please send these kind of patches for netfilter to me so I can
make sure they don't clash with other pending patches.
(this will be my last __read_mostly patch unless someone points out
something else that needs it)
This seems to be a bit random, there are quite a few more candidates for
__read_mostly right next to the ones you marked.
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 8f22619..3b64dbe 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -77,12 +77,12 @@ LIST_HEAD(nf_conntrack_expect_list);
struct nf_conntrack_protocol **nf_ct_protos[PF_MAX];
Like this one
struct nf_conntrack_l3proto *nf_ct_l3protos[PF_MAX];
and this one
static LIST_HEAD(helpers);
and this one
-unsigned int nf_conntrack_htable_size = 0;
-int nf_conntrack_max;
+unsigned int nf_conntrack_htable_size __read_mostly = 0;
+int nf_conntrack_max __read_mostly;
struct list_head *nf_conntrack_hash;
and this one
static kmem_cache_t *nf_conntrack_expect_cachep;
and this one
struct nf_conn nf_conntrack_untracked;
-unsigned int nf_ct_log_invalid;
+unsigned int nf_ct_log_invalid __read_mostly;
static LIST_HEAD(unconfirmed);
static int nf_conntrack_vmalloc;
and this one
Same ones in ip_conntrack.
/* Log invalid packets of a given protocol */
diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c
index 276a964..80060cb 100644
--- a/net/ipv4/netfilter/ip_queue.c
+++ b/net/ipv4/netfilter/ip_queue.c
@@ -53,7 +53,7 @@ struct ipq_queue_entry {
typedef int (*ipq_cmpfn)(struct ipq_queue_entry *, unsigned long);
static unsigned char copy_mode = IPQ_COPY_NONE;
-static unsigned int queue_maxlen = IPQ_QMAX_DEFAULT;
+static unsigned int queue_maxlen __read_mostly = IPQ_QMAX_DEFAULT;
static DEFINE_RWLOCK(queue_lock);
static int peer_pid;
static unsigned int copy_range;
Basically all these variables besides the lock are candidates.
-
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.18] WE-21 support (core API)
On Fri, Sep 01, 2006 at 08:54:00AM +0200, Johannes Berg wrote: On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote: And I strongly disagree with your disagrement ;-) You're of course free to do that :) But let me explain. And my explanation is even more simple : let's not throw the baby with the bathwater. If things are broken in WE, let's just fix it. I've always worked with people working with me. Note that one thing that worry me with your approach is footprint. I've used various embedded devices over the years, such as the Gumstix (4MB Flash), and this is why WE was optimised for footprint. I'm sorry to say it like this, but I hope my work will not be impacted by vaporware. How many drivers are currently converted to nl80211 ? None, I have to admit, of course. But I hope you realise that I can impossibly convert all drivers at once and all by myself. I merely set out a framework in which it is easy to add new features, new calls and make things behave. I hope you realised that you can't expect driver authors to convert their driver, it won't happen. I've implemented WE in half the driver in the kernel myself, and I convert WE in those drivers myself. The reason why those new features are good for you : o They give you a template on how you could implement those features in nl80211, saving you design time. Gack. I'm inclined to not even respond to this, but I am convinced that having all the unions and ill-defined semantics with one field having multiple meanings is in no way saving me design time because it's part of the problem I intend to completely avoid. Can we have specifics, instead of generalities ? Every time somebody pointed out a specific thing that was broken in WE, I've fixed it (with a few exceptions). Case in point : the ESSID change (which was a pain to coordinate in user space). Actually, no. But that's beside the point anyway. Actually, I think that publishing WE over netlink was a mistake. I don't understand, in the last few years everybody was clamoring for a Netlink interface, and now that it is done, people say it is a stupid thing. Any specifics ? The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. I don't understand why you say it's ill defined, it 100% documented in the iwconfig man page. Setting an ESSID to all-zeroes to disable something (or was it all-ones to disable??) This has *never* existed, there has always been a separate flag to indicate that since the beggining. I don't know where you got that. Any other misconception I need to straighten ? johannes Regards, Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] change netfilter tunables to __read_mostly
Patrick McHardy wrote: Brian Haley wrote: Change some netfilter tunables to __read_mostly. Also fixed some incorrect file reference comments while I was in there. Please send these kind of patches for netfilter to me so I can make sure they don't clash with other pending patches. (this will be my last __read_mostly patch unless someone points out something else that needs it) This seems to be a bit random, there are quite a few more candidates for __read_mostly right next to the ones you marked. Ah sorry, I didn't really get why you chose these :) The patch doesn't clash with anything in my queue, so ACK from me. - 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] change netfilter tunables to __read_mostly
Patrick McHardy wrote: Patrick McHardy wrote: Brian Haley wrote: Change some netfilter tunables to __read_mostly. Also fixed some incorrect file reference comments while I was in there. Please send these kind of patches for netfilter to me so I can make sure they don't clash with other pending patches. (this will be my last __read_mostly patch unless someone points out something else that needs it) This seems to be a bit random, there are quite a few more candidates for __read_mostly right next to the ones you marked. Ah sorry, I didn't really get why you chose these :) The patch doesn't clash with anything in my queue, so ACK from me. Sorry, next time I'll send them to you, or [EMAIL PROTECTED] I'll cook-up another patch for the others you mentioned and send it out. -Brian - 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 to add board revision to the WLAN chip_id printout
Michael, This patch includes the board revision in the chip_id printk for the ssb version of bcm43xx-d80211 and is meant to be applied to wireless-dev. As we have seen, behavior of the chips can be dependent on the rev level, thus a need to have it in the log. Signed-off-by: Larry Finger [EMAIL PROTECTED] Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c @@ -3346,7 +3346,8 @@ static int bcm43xx_attach_board(struct b if (err) goto err_chipset_detach; - printk(KERN_INFO PFX Broadcom %04X WLAN found\n, bcm-ssb.chip_id); + printk(KERN_INFO PFX Broadcom %04X WLAN, Revision %d found\n, + bcm-ssb.chip_id, bcm-board_revision); /* Attach all IO cores to the backplane. */ coremask = 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 2.6.17 0/9] NetXen: 1G/10G Ethernet Driver
Hi, This entire patch is available at, http://www.netxen.com/products/downloads/netxen-2.6.17.patch.zip Thanks, pradeep On Thu, 31 Aug 2006, Amit S. Kale wrote: Hi All, Thank you Stephen, Don and Wendy. We have incorporated feedbacks which have received since after last post. I'll be resending updated patchset in subsequent emails. We are working on finding out good way of using tables to manage compatibility between firmware version number and driver version number. Kindly review it and feel free to send feedback. Thanks, -Amit Signed-off-by: Amit S. Kale [EMAIL PROTECTED] MAINTAINERS |7 drivers/net/Kconfig |5 drivers/net/Makefile |1 drivers/net/netxen/Makefile | 35 drivers/net/netxen/netxen_nic.h | 901 + drivers/net/netxen/netxen_nic_ethtool.c | 696 +++ drivers/net/netxen/netxen_nic_hdr.h | 611 + drivers/net/netxen/netxen_nic_hw.c | 1102 ++ drivers/net/netxen/netxen_nic_hw.h | 499 + drivers/net/netxen/netxen_nic_init.c | 1089 ++ drivers/net/netxen/netxen_nic_ioctl.h| 75 ++ drivers/net/netxen/netxen_nic_isr.c | 301 drivers/net/netxen/netxen_nic_main.c | 1107 +++ drivers/net/netxen/netxen_nic_niu.c | 779 + drivers/net/netxen/netxen_nic_phan_reg.h | 195 + 15 files changed, 7403 insertions(+) - 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
[IPV6]: Fix tclass setting for raw sockets.
Hello.
Following patch is for linux-2.6.
I think it is appropriate to push this to -stable.
---
[IPV6]: Fix tclass setting for raw sockets.
np-cork.tclass is used only in cork'ed context.
Otherwise, np-tclass should be used.
Bug#7096 reported by Remi Denis-Courmont [EMAIL PROTECTED].
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 3d6e9a3..356a8a7 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -401,7 +401,7 @@ void icmpv6_send(struct sk_buff *skb, in
if (hlimit 0)
hlimit = ipv6_get_hoplimit(dst-dev);
- tclass = np-cork.tclass;
+ tclass = np-tclass;
if (tclass 0)
tclass = 0;
@@ -497,7 +497,7 @@ static void icmpv6_echo_reply(struct sk_
if (hlimit 0)
hlimit = ipv6_get_hoplimit(dst-dev);
- tclass = np-cork.tclass;
+ tclass = np-tclass;
if (tclass 0)
tclass = 0;
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index d57e61c..15b862d 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -781,7 +781,7 @@ static int rawv6_sendmsg(struct kiocb *i
}
if (tclass 0) {
- tclass = np-cork.tclass;
+ tclass = np-tclass;
if (tclass 0)
tclass = 0;
}
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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/8] address: Convert address deletion to new netlink api
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:14.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:18.0 +0200
@@ -2894,22 +2894,17 @@
static int
inet6_rtm_deladdr(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
{
- struct rtattr **rta = arg;
- struct ifaddrmsg *ifm = NLMSG_DATA(nlh);
+ struct ifaddrmsg *ifm;
+ struct nlattr *tb[IFA_MAX+1];
struct in6_addr *pfx;
+ int err;
- pfx = NULL;
- if (rta[IFA_ADDRESS-1]) {
- if (RTA_PAYLOAD(rta[IFA_ADDRESS-1]) sizeof(*pfx))
- return -EINVAL;
- pfx = RTA_DATA(rta[IFA_ADDRESS-1]);
- }
- if (rta[IFA_LOCAL-1]) {
- if (RTA_PAYLOAD(rta[IFA_LOCAL-1]) sizeof(*pfx) ||
- (pfx memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]),
sizeof(*pfx
- return -EINVAL;
- pfx = RTA_DATA(rta[IFA_LOCAL-1]);
- }
+ err = nlmsg_parse(nlh, sizeof(*ifm), tb, IFA_MAX, ifa_ipv6_policy);
+ if (err 0)
+ return err;
+
+ ifm = nlmsg_data(nlh);
+ pfx = extract_addr(tb[IFA_ADDRESS], tb[IFA_LOCAL]);
if (pfx == NULL)
return -EINVAL;
--
VGER BF report: H 0.0599509
-
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] address: Add put_ifaddrmsg() and rt_scope()
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:21.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:22.0 +0200
@@ -3000,6 +3000,19 @@
preferred_lft, valid_lft);
}
+static void put_ifaddrmsg(struct nlmsghdr *nlh, u8 prefixlen, u8 flags,
+ u8 scope, int ifindex)
+{
+ struct ifaddrmsg *ifm;
+
+ ifm = nlmsg_data(nlh);
+ ifm-ifa_family = AF_INET6;
+ ifm-ifa_prefixlen = prefixlen;
+ ifm-ifa_flags = flags;
+ ifm-ifa_scope = scope;
+ ifm-ifa_index = ifindex;
+}
+
static int put_cacheinfo(struct sk_buff *skb, unsigned long cstamp,
unsigned long tstamp, u32 preferred, u32 valid)
{
@@ -3015,6 +3028,18 @@
return nla_put(skb, IFA_CACHEINFO, sizeof(ci), ci);
}
+static inline int rt_scope(int ifa_scope)
+{
+ if (ifa_scope IFA_HOST)
+ return RT_SCOPE_HOST;
+ else if (ifa_scope IFA_LINK)
+ return RT_SCOPE_LINK;
+ else if (ifa_scope IFA_SITE)
+ return RT_SCOPE_SITE;
+ else
+ return RT_SCOPE_UNIVERSE;
+}
+
/* Maximum length of ifa_cacheinfo attributes */
#define INET6_IFADDR_RTA_SPACE \
RTA_SPACE(16) /* IFA_ADDRESS */ + \
@@ -3023,24 +3048,14 @@
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
u32 pid, u32 seq, int event, unsigned int flags)
{
- struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
unsigned char*b = skb-tail;
u32 preferred, valid;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
- ifm = NLMSG_DATA(nlh);
- ifm-ifa_family = AF_INET6;
- ifm-ifa_prefixlen = ifa-prefix_len;
- ifm-ifa_flags = ifa-flags;
- ifm-ifa_scope = RT_SCOPE_UNIVERSE;
- if (ifa-scopeIFA_HOST)
- ifm-ifa_scope = RT_SCOPE_HOST;
- else if (ifa-scopeIFA_LINK)
- ifm-ifa_scope = RT_SCOPE_LINK;
- else if (ifa-scopeIFA_SITE)
- ifm-ifa_scope = RT_SCOPE_SITE;
- ifm-ifa_index = ifa-idev-dev-ifindex;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ put_ifaddrmsg(nlh, ifa-prefix_len, ifa-flags, rt_scope(ifa-scope),
+ ifa-idev-dev-ifindex);
+
RTA_PUT(skb, IFA_ADDRESS, 16, ifa-addr);
if (!(ifa-flagsIFA_F_PERMANENT)) {
preferred = ifa-prefered_lft;
@@ -3071,19 +3086,16 @@
static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
u32 pid, u32 seq, int event, u16 flags)
{
- struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
unsigned char*b = skb-tail;
+ u8 scope = RT_SCOPE_UNIVERSE;
+ int ifindex = ifmca-idev-dev-ifindex;
+
+ if (ipv6_addr_scope(ifmca-mca_addr) IFA_SITE)
+ scope = RT_SCOPE_SITE;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
- ifm = NLMSG_DATA(nlh);
- ifm-ifa_family = AF_INET6;
- ifm-ifa_prefixlen = 128;
- ifm-ifa_flags = IFA_F_PERMANENT;
- ifm-ifa_scope = RT_SCOPE_UNIVERSE;
- if (ipv6_addr_scope(ifmca-mca_addr)IFA_SITE)
- ifm-ifa_scope = RT_SCOPE_SITE;
- ifm-ifa_index = ifmca-idev-dev-ifindex;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
RTA_PUT(skb, IFA_MULTICAST, 16, ifmca-mca_addr);
if (put_cacheinfo(skb, ifmca-mca_cstamp, ifmca-mca_tstamp,
@@ -3102,19 +3114,16 @@
static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca,
u32 pid, u32 seq, int event, unsigned int flags)
{
- struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
unsigned char*b = skb-tail;
+ u8 scope = RT_SCOPE_UNIVERSE;
+ int ifindex = ifaca-aca_idev-dev-ifindex;
+
+ if (ipv6_addr_scope(ifaca-aca_addr) IFA_SITE)
+ scope = RT_SCOPE_SITE;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
- ifm = NLMSG_DATA(nlh);
- ifm-ifa_family = AF_INET6;
- ifm-ifa_prefixlen = 128;
- ifm-ifa_flags = IFA_F_PERMANENT;
- ifm-ifa_scope = RT_SCOPE_UNIVERSE;
- if (ipv6_addr_scope(ifaca-aca_addr)IFA_SITE)
- ifm-ifa_scope = RT_SCOPE_SITE;
- ifm-ifa_index = ifaca-aca_idev-dev-ifindex;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
RTA_PUT(skb, IFA_ANYCAST, 16, ifaca-aca_addr);
if (put_cacheinfo(skb, ifaca-aca_cstamp, ifaca-aca_tstamp,
--
VGER BF report: H 7.82266e-05
-
To unsubscribe from
[PATCH 8/8] address: Support NLM_F_EXCL when adding addresses
iproute2 doesn't provide the NLM_F_CREATE flag when adding addresses,
it is assumed to be implied. The existing code issues a check on
said flag when the modify operation fails (likely due to ENOENT)
before continueing to create it, this leads to a hard to predict
result, therefore the NLM_F_CREATE check is removed.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:25.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:26.0 +0200
@@ -2908,24 +2908,14 @@
return inet6_addr_del(ifm-ifa_index, pfx, ifm-ifa_prefixlen);
}
-static int
-inet6_addr_modify(int ifindex, struct in6_addr *pfx,
- __u32 prefered_lft, __u32 valid_lft)
+static int inet6_addr_modify(struct inet6_ifaddr *ifp, u32 prefered_lft,
+u32 valid_lft)
{
- struct inet6_ifaddr *ifp = NULL;
- struct net_device *dev;
int ifa_flags = 0;
- if ((dev = __dev_get_by_index(ifindex)) == NULL)
- return -ENODEV;
-
if (!valid_lft || (prefered_lft valid_lft))
return -EINVAL;
- ifp = ipv6_get_ifaddr(pfx, dev, 1);
- if (ifp == NULL)
- return -ENOENT;
-
if (valid_lft == INFINITY_LIFE_TIME)
ifa_flags = IFA_F_PERMANENT;
else if (valid_lft = 0x7FFF/HZ)
@@ -2947,7 +2937,6 @@
spin_unlock_bh(ifp-lock);
if (!(ifp-flagsIFA_F_TENTATIVE))
ipv6_ifa_notify(0, ifp);
- in6_ifa_put(ifp);
addrconf_verify(0);
@@ -2960,6 +2949,8 @@
struct ifaddrmsg *ifm;
struct nlattr *tb[IFA_MAX+1];
struct in6_addr *pfx;
+ struct inet6_ifaddr *ifa;
+ struct net_device *dev;
u32 valid_lft, preferred_lft;
int err;
@@ -2983,15 +2974,29 @@
valid_lft = INFINITY_LIFE_TIME;
}
- if (nlh-nlmsg_flags NLM_F_REPLACE) {
- err = inet6_addr_modify(ifm-ifa_index, pfx,
- preferred_lft, valid_lft);
- if (err == 0 || !(nlh-nlmsg_flags NLM_F_CREATE))
- return err;
+ dev = __dev_get_by_index(ifm-ifa_index);
+ if (dev == NULL)
+ return -ENODEV;
+
+ ifa = ipv6_get_ifaddr(pfx, dev, 1);
+ if (ifa == NULL) {
+ /*
+* It would be best to check for !NLM_F_CREATE here but
+* userspace alreay relies on not having to provide this.
+*/
+ return inet6_addr_add(ifm-ifa_index, pfx, ifm-ifa_prefixlen,
+ preferred_lft, valid_lft);
}
- return inet6_addr_add(ifm-ifa_index, pfx, ifm-ifa_prefixlen,
- preferred_lft, valid_lft);
+ if (nlh-nlmsg_flags NLM_F_EXCL ||
+ !(nlh-nlmsg_flags NLM_F_REPLACE))
+ err = -EEXIST;
+ else
+ err = inet6_addr_modify(ifa, preferred_lft, valid_lft);
+
+ in6_ifa_put(ifa);
+
+ return err;
}
static void put_ifaddrmsg(struct nlmsghdr *nlh, u8 prefixlen, u8 flags,
--
VGER BF report: H 0.192484
-
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] address: Allow address changes while device is administrative down
Same behaviour as IPv4, using IFF_UP is a no-no anyway. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6.19/net/ipv6/addrconf.c === --- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:24.0 +0200 +++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:25.0 +0200 @@ -1886,9 +1886,6 @@ if ((dev = __dev_get_by_index(ifindex)) == NULL) return -ENODEV; - if (!(dev-flagsIFF_UP)) - return -ENETDOWN; - if ((idev = addrconf_add_dev(dev)) == NULL) return -ENOBUFS; @@ -2922,9 +2919,6 @@ if ((dev = __dev_get_by_index(ifindex)) == NULL) return -ENODEV; - if (!(dev-flagsIFF_UP)) - return -ENETDOWN; - if (!valid_lft || (prefered_lft valid_lft)) return -EINVAL; -- VGER BF report: H 1.17609e-05 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] address: Convert address dumping to new netlink api
Replaces INET6_IFADDR_RTA_SPACE with a new function calculating
the total required message size for all address messages.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.19/net/ipv6/addrconf.c
===
--- net-2.6.19.orig/net/ipv6/addrconf.c 2006-09-01 23:15:22.0 +0200
+++ net-2.6.19/net/ipv6/addrconf.c 2006-09-01 23:15:24.0 +0200
@@ -3040,23 +3040,27 @@
return RT_SCOPE_UNIVERSE;
}
-/* Maximum length of ifa_cacheinfo attributes */
-#define INET6_IFADDR_RTA_SPACE \
- RTA_SPACE(16) /* IFA_ADDRESS */ + \
- RTA_SPACE(sizeof(struct ifa_cacheinfo)) /* CACHEINFO */
+static inline int inet6_ifaddr_msgsize(void)
+{
+ return nlmsg_total_size(sizeof(struct ifaddrmsg) +
+ nla_total_size(16) +
+ nla_total_size(sizeof(struct ifa_cacheinfo)) +
+ 128);
+}
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
u32 pid, u32 seq, int event, unsigned int flags)
{
struct nlmsghdr *nlh;
- unsigned char*b = skb-tail;
u32 preferred, valid;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ nlh = nlmsg_put(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ if (nlh == NULL)
+ return -ENOBUFS;
+
put_ifaddrmsg(nlh, ifa-prefix_len, ifa-flags, rt_scope(ifa-scope),
ifa-idev-dev-ifindex);
- RTA_PUT(skb, IFA_ADDRESS, 16, ifa-addr);
if (!(ifa-flagsIFA_F_PERMANENT)) {
preferred = ifa-prefered_lft;
valid = ifa-valid_lft;
@@ -3071,72 +3075,57 @@
valid = INFINITY_LIFE_TIME;
}
- if (put_cacheinfo(skb, ifa-cstamp, ifa-tstamp, preferred, valid) 0)
- goto rtattr_failure;
-
- nlh-nlmsg_len = skb-tail - b;
- return skb-len;
+ if (nla_put(skb, IFA_ADDRESS, 16, ifa-addr) 0 ||
+ put_cacheinfo(skb, ifa-cstamp, ifa-tstamp, preferred, valid) 0)
+ return nlmsg_cancel(skb, nlh);
-nlmsg_failure:
-rtattr_failure:
- skb_trim(skb, b - skb-data);
- return -1;
+ return nlmsg_end(skb, nlh);
}
static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
u32 pid, u32 seq, int event, u16 flags)
{
struct nlmsghdr *nlh;
- unsigned char*b = skb-tail;
u8 scope = RT_SCOPE_UNIVERSE;
int ifindex = ifmca-idev-dev-ifindex;
if (ipv6_addr_scope(ifmca-mca_addr) IFA_SITE)
scope = RT_SCOPE_SITE;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
- put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
- RTA_PUT(skb, IFA_MULTICAST, 16, ifmca-mca_addr);
+ nlh = nlmsg_put(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ if (nlh == NULL)
+ return -ENOBUFS;
- if (put_cacheinfo(skb, ifmca-mca_cstamp, ifmca-mca_tstamp,
+ put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
+ if (nla_put(skb, IFA_MULTICAST, 16, ifmca-mca_addr) 0 ||
+ put_cacheinfo(skb, ifmca-mca_cstamp, ifmca-mca_tstamp,
INFINITY_LIFE_TIME, INFINITY_LIFE_TIME) 0)
- goto rtattr_failure;
-
- nlh-nlmsg_len = skb-tail - b;
- return skb-len;
+ return nlmsg_cancel(skb, nlh);
-nlmsg_failure:
-rtattr_failure:
- skb_trim(skb, b - skb-data);
- return -1;
+ return nlmsg_end(skb, nlh);
}
static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca,
u32 pid, u32 seq, int event, unsigned int flags)
{
struct nlmsghdr *nlh;
- unsigned char*b = skb-tail;
u8 scope = RT_SCOPE_UNIVERSE;
int ifindex = ifaca-aca_idev-dev-ifindex;
if (ipv6_addr_scope(ifaca-aca_addr) IFA_SITE)
scope = RT_SCOPE_SITE;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
- put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
- RTA_PUT(skb, IFA_ANYCAST, 16, ifaca-aca_addr);
+ nlh = nlmsg_put(skb, pid, seq, event, sizeof(struct ifaddrmsg), flags);
+ if (nlh == NULL)
+ return -ENOBUFS;
- if (put_cacheinfo(skb, ifaca-aca_cstamp, ifaca-aca_tstamp,
+ put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
+ if (nla_put(skb, IFA_ANYCAST, 16, ifaca-aca_addr) 0 ||
+ put_cacheinfo(skb, ifaca-aca_cstamp, ifaca-aca_tstamp,
INFINITY_LIFE_TIME, INFINITY_LIFE_TIME) 0)
- goto rtattr_failure;
+ return nlmsg_cancel(skb, nlh);
- nlh-nlmsg_len = skb-tail - b;
- return skb-len;
-
-nlmsg_failure:
-rtattr_failure:
-
[PATCH] sky2: more pci device id's
Some more Marvell device id's, these are from the latest SysKonnect
vendor driver version of sk98lin (8.36).
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c |3 +++
1 file changed, 3 insertions(+)
--- sky2.orig/drivers/net/sky2.c2006-09-01 14:49:49.0 -0700
+++ sky2/drivers/net/sky2.c 2006-09-01 14:49:56.0 -0700
@@ -106,6 +106,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9000) },
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9E00) },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4b00) },/* DGE-560T */
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4001) },/* DGE-550SX */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4340) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4341) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4342) },
@@ -117,6 +118,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4350) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4351) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4352) },
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4353) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4360) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4362) },
@@ -126,6 +128,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4366) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4367) },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4368) },
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) },
{ 0 }
};
--
VGER BF report: H 0.0313791
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] bonding: Miscellaneous small fixes
Patch 1: Add 10 Gig support Patch 2: Convert delay value from s16 to int Patch 3: Format fix in seq_printf call Patch 4: Remove unneeded NULL test Patch 5: Handle large hard_header_len Patch 6: Add priv_flag to avoid event mishandling Patch 7: Don't release slaves when master is admin down -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] -- VGER BF report: U 0.49 - 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/7] bonding: Convert delay value from s16 to int
From: Kenzo Iwami [EMAIL PROTECTED]
The value of downdelay/miimon and updelay/miimon are stored in
slave-delay. The type of downdelay, updelay, and miimon are all int.
However, slave-delay is type short, and it is not possible to store the
value of downdelay/miimon or updelay/miimon in some cases. (For example,
miimon=1 downdelay=32768)
Signed-off-by: Kenzo Iwami [EMAIL PROTECTED]
Acked-by: Jay Vosburgh [EMAIL PROTECTED]
diff -urpN linux-2.6.17/drivers/net/bonding/bonding.h
linux-2.6.17_fix/drivers/net/bonding/bonding.h
--- linux-2.6.17/drivers/net/bonding/bonding.h 2006-06-18 10:49:35.0
+0900
+++ linux-2.6.17_fix/drivers/net/bonding/bonding.h 2006-06-19
16:52:43.0
+0900
@@ -149,7 +149,7 @@ struct slave {
struct net_device *dev; /* first - useful for panic debug */
struct slave *next;
struct slave *prev;
- s16delay;
+ intdelay;
u32jiffies;
s8 link;/* one of BOND_LINK_ */
s8 state; /* one of BOND_STATE_ */
--
VGER BF report: H 0.391544
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] bonding: Add 10 Gig support
Allow channel bonding to enslave a 10 Gig adapter without errors.
Signed-off-by: Mitch Williams [EMAIL PROTECTED]
Acked-by: Jay Vosburgh [EMAIL PROTECTED]
diff -urpN -X linux-2.6.18-rc4-clean/Documentation/dontdiff
linux-2.6.18-rc4-clean/drivers/net/bonding/bond_3ad.c
linux-2.6.18-rc4/drivers/net/bonding/bond_3ad.c
--- linux-2.6.18-rc4-clean/drivers/net/bonding/bond_3ad.c 2006-06-17
18:49:35.0 -0700
+++ linux-2.6.18-rc4/drivers/net/bonding/bond_3ad.c 2006-08-30
11:31:45.0 -0700
@@ -85,6 +85,7 @@
#define AD_LINK_SPEED_BITMASK_10MBPS 0x2
#define AD_LINK_SPEED_BITMASK_100MBPS 0x4
#define AD_LINK_SPEED_BITMASK_1000MBPS0x8
+#define AD_LINK_SPEED_BITMASK_1MBPS 0x10
//endalloun
// compare MAC addresses
@@ -330,7 +331,8 @@ static inline void __release_rx_machine_
* 0,
* %AD_LINK_SPEED_BITMASK_10MBPS,
* %AD_LINK_SPEED_BITMASK_100MBPS,
- * %AD_LINK_SPEED_BITMASK_1000MBPS
+ * %AD_LINK_SPEED_BITMASK_1000MBPS,
+ * %AD_LINK_SPEED_BITMASK_1MBPS
*/
static u16 __get_link_speed(struct port *port)
{
@@ -357,6 +359,10 @@ static u16 __get_link_speed(struct port
speed = AD_LINK_SPEED_BITMASK_1000MBPS;
break;
+ case SPEED_1:
+ speed = AD_LINK_SPEED_BITMASK_1MBPS;
+ break;
+
default:
speed = 0; // unknown speed value from ethtool.
shouldn't happen
break;
@@ -775,6 +781,9 @@ static u32 __get_agg_bandwidth(struct ag
case AD_LINK_SPEED_BITMASK_1000MBPS:
bandwidth = aggregator-num_of_ports * 1000;
break;
+ case AD_LINK_SPEED_BITMASK_1MBPS:
+ bandwidth = aggregator-num_of_ports * 1;
+ break;
default:
bandwidth=0; // to silent the compilor
}
diff -urpN -X linux-2.6.18-rc4-clean/Documentation/dontdiff
linux-2.6.18-rc4-clean/drivers/net/bonding/bond_main.c
linux-2.6.18-rc4/drivers/net/bonding/bond_main.c
--- linux-2.6.18-rc4-clean/drivers/net/bonding/bond_main.c 2006-08-21
13:28:43.0 -0700
+++ linux-2.6.18-rc4/drivers/net/bonding/bond_main.c2006-08-30
10:49:37.0 -0700
@@ -638,6 +638,7 @@ verify:
case SPEED_10:
case SPEED_100:
case SPEED_1000:
+ case SPEED_1:
break;
default:
return -1;
--
VGER BF report: H 0.0801872
-
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/7] bonding: Format fix in seq_printf call
From: Kenzo Iwami [EMAIL PROTECTED] Though link_failure_count is type unsigned int, this value is outputted to /proc/net/bonding/bondX file using %d instead of %u. The attached patch fixes this problem. Signed-off-by: Kenzo Iwami [EMAIL PROTECTED] Acked-by: Jay Vosburgh [EMAIL PROTECTED] --- netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/19 10:39:34 1.2 +++ netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/19 14:46:07 1.3 @@ -2951,7 +2951,7 @@ seq_printf(seq, \nSlave Interface: %s\n, slave-dev-name); seq_printf(seq, MII Status: %s\n, (slave-link == BOND_LINK_UP) ? up : down); - seq_printf(seq, Link Failure Count: %d\n, + seq_printf(seq, Link Failure Count: %u\n, slave-link_failure_count); seq_printf(seq, -- VGER BF report: U 0.498925 - 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/7] bonding: Remove unneeded NULL test
Remove unneeded test for NULL. Reported by Thomas Dillig
[EMAIL PROTECTED] and Isil Dillig [EMAIL PROTECTED] via Stephen
Hemminger [EMAIL PROTECTED].
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
--- netdev-2.6.git-upstream/drivers/net/bonding/bond_sysfs.c2006/08/19
10:22:17 1.1
+++ netdev-2.6.git-upstream/drivers/net/bonding/bond_sysfs.c2006/08/19
15:01:09 1.2
@@ -1093,7 +1093,7 @@
strlen(slave-dev-name)) == 0) {
old_active = bond-curr_active_slave;
new_active = slave;
- if (new_active (new_active == old_active)) {
+ if (new_active == old_active) {
/* do nothing */
printk(KERN_INFO DRV_NAME
: %s: %s is already the current
active slave.\n,
--
VGER BF report: H 0.139804
-
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.18] WE-21 support (core API)
On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote: Note that one thing that worry me with your approach is footprint. I've used various embedded devices over the years, such as the Gumstix (4MB Flash), and this is why WE was optimised for footprint. Can you please explain in more detail, how WE + the WE-netlink wrapper has lower footprint than this netlink-only layer? WE-netlink is optional. And WE-ioctl could be made optional (still on the todo list). You can also disable WE-event and WE-iwspy for further footprint reduction. The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. I don't understand why you say it's ill defined, it 100% documented in the iwconfig man page. It is horribly documented. There is one big union and one magic extra parameter. You have to guess (or look at other implementations) to find out which element of the union or even if and how to use the extra parameter. That's a real pain. And after you found out which element to use, you have to figure out somehow how to actually use that element. That's nontrivial, escpecially because some flags (that are not documented) may magically change the whole semantics of the contents. If you are trying to write WE without reading any other code, that's true. But that's not the way sane people work. Sane people cut'n'paste from other drivers, and then check the source code of iwconfig (which is fully commented) in case of doubt. It's strange, many driver authors are not afraid of asking me questions, but some can't manage to do that. In my opinion this One function signature fits all design used in WE is simply broken by design. So, are you saying that the 'syscal' design is broken by nature ? I've never seen the kernel and glibc people complaining about it. It was designed this way on purpose, because you get low footprint and very good scalability. And I've yet to see anyone tripped by it. Greetings Michael. Jean -- VGER BF report: U 0.5 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] bonding: Handle large hard_header_len
The bonding driver fails to adjust its hard_header_len when enslaving
interfaces. Whenever an interface with a hard_header_len greater than the
ETH_HLEN default is enslaved, the potential for an oops exists, and if the
oops happens while responding to an arp request, for example, the system
panics. GIANFAR devices may use an extended hard_header for VLAN or
hardware checksumming. Enslaving such a device and then transmitting over
it causes a kernel panic.
Patch modified from submitter's original, but submitter agreed with this
patch in private email.
Signed-off-by: Mark Huth [EMAIL PROTECTED]
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
--- netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/19
14:46:07 1.3
+++ netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/19
15:47:27 1.4
@@ -1211,10 +1211,14 @@ static int bond_compute_features(struct
unsigned long features = BOND_INTERSECT_FEATURES;
struct slave *slave;
struct net_device *bond_dev = bond-dev;
+ unsigned short max_hard_header_len = ETH_HLEN;
int i;
- bond_for_each_slave(bond, slave, i)
+ bond_for_each_slave(bond, slave, i) {
features = (slave-dev-features BOND_INTERSECT_FEATURES);
+ if (slave-dev-hard_header_len max_hard_header_len)
+ max_hard_header_len = slave-dev-hard_header_len;
+ }
if ((features NETIF_F_SG)
!(features NETIF_F_ALL_CSUM))
@@ -1232,6 +1236,7 @@ static int bond_compute_features(struct
features |= (bond_dev-features ~BOND_INTERSECT_FEATURES);
bond_dev-features = features;
+ bond_dev-hard_header_len = max_hard_header_len;
return 0;
}
--
VGER BF report: U 0.498513
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] bonding: Add priv_flag to avoid event mishandling
Add priv_flag to specifically identify bonding-involved devices. Needed
because IFF_MASTER is an unreliable identifier (vlan interfaces above bonding
will inherit IFF_MASTER). Misidentification of devices would cause
notifier events for other devices to be erroneously processed by bonding,
causing various havoc.
Bug discovered by Martin Papik [EMAIL PROTECTED]; this patch is
modified from his original.
Signed-off-by: Martin Papik [EMAIL PROTECTED]
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
--- netdev-2.6.git-upstream/include/linux/if.h 2006/08/26 17:23:42 1.1
+++ netdev-2.6.git-upstream/include/linux/if.h 2006/08/26 17:24:23 1.2
@@ -59,6 +59,7 @@
#define IFF_SLAVE_INACTIVE 0x4 /* bonding slave not the curr. active */
#define IFF_MASTER_8023AD 0x8 /* bonding master, 802.3ad. */
#define IFF_MASTER_ALB 0x10/* bonding master, balance-alb. */
+#define IFF_BONDING0x20/* bonding master or slave */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
--- netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/19
15:47:27 1.4
+++ netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/26
17:24:41 1.5
@@ -1371,6 +1371,7 @@ int bond_enslave(struct net_device *bond
}
new_slave-dev = slave_dev;
+ slave_dev-priv_flags |= IFF_BONDING;
if ((bond-params.mode == BOND_MODE_TLB) ||
(bond-params.mode == BOND_MODE_ALB)) {
@@ -1784,7 +1785,7 @@ int bond_release(struct net_device *bond
dev_set_mac_address(slave_dev, addr);
slave_dev-priv_flags = ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
- IFF_SLAVE_INACTIVE);
+ IFF_SLAVE_INACTIVE | IFF_BONDING);
kfree(slave);
@@ -3216,6 +3217,9 @@ static int bond_netdev_event(struct noti
(event_dev ? event_dev-name : None),
event);
+ if (!(event_dev-priv_flags IFF_BONDING))
+ return NOTIFY_DONE;
+
if (event_dev-flags IFF_MASTER) {
dprintk(IFF_MASTER\n);
return bond_master_netdev_event(event, event_dev);
@@ -4185,6 +4189,7 @@ static int bond_init(struct net_device *
/* Initialize the device options */
bond_dev-tx_queue_len = 0;
bond_dev-flags |= IFF_MASTER|IFF_MULTICAST;
+ bond_dev-priv_flags |= IFF_BONDING;
/* At first, we block adding VLANs. That's the only way to
* prevent problems that occur when adding VLANs over an
--
VGER BF report: U 0.49
-
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/7] bonding: Don't release slaves when master is admin down
From: jamal [EMAIL PROTECTED]
When a bonding netdevice is admin-ed down it loses the slaves
attributes (set via ifenslave). This is not consistent with other
behavior of netdevices (example a qdisc attached to a netdevice doesnt
disappear or an attached IP address etc).
The included patch fixes this. Ive tested by ifenslaving, downing the
bond, checking /proc and making sure it still has the slaves, up-ing the
bond and making sure things continue to work.
Jay/Bonding folks if you are ok with it, just ACK it or include it in
your tree etc. Otherwise we can discuss.
Acked-by: Jay Vosburgh [EMAIL PROTECTED]
--- netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/26
17:24:41 1.5
+++ netdev-2.6.git-upstream/drivers/net/bonding/bond_main.c 2006/08/26
18:21:39 1.6
@@ -3430,7 +3430,6 @@ static int bond_close(struct net_device
write_lock_bh(bond-lock);
- bond_mc_list_destroy(bond);
/* signal timers not to re-arm */
bond-kill_timers = 1;
@@ -3461,8 +3460,6 @@ static int bond_close(struct net_device
break;
}
- /* Release the bonded slaves */
- bond_release_all(bond_dev);
if ((bond-params.mode == BOND_MODE_TLB) ||
(bond-params.mode == BOND_MODE_ALB)) {
@@ -4248,6 +4245,9 @@ static void bond_free_all(void)
list_for_each_entry_safe(bond, nxt, bond_dev_list, bond_list) {
struct net_device *bond_dev = bond-dev;
+ bond_mc_list_destroy(bond);
+ /* Release the bonded slaves */
+ bond_release_all(bond_dev);
unregister_netdevice(bond_dev);
bond_deinit(bond_dev);
}
--
VGER BF report: U 0.499787
-
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
TCP send/ack lockstep problem
Hello, I have a problem with a TCP connection here which just doesn't want to have multiple packets on the wire. I have verified that the sender has enough buffered data (netstat -t shows 8..10k send buffer). There's no packet loss. The tcpdump (attached) shows that the receiver increases its window correctly -- the sender just seems to ignore that. Any ideas? Is the sending program doing something stupid? If so, what? tcpdump (on the sender's interface; Ubuntu kernel 2.6.15-23): 11:00:02.101523 IP (tos 0x34, ttl 53, id 19121, offset 0, flags [DF], proto: TCP (6), length: 60) 62.193.238.120.33126 192.109.102.42.3306: S, cksum 0x130b (correct), 3222543538:3222543538(0) win 5840 mss 1460,sackOK,timestamp 1550801950,nop,wscale 2 11:00:02.101566 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.109.102.42.3306 62.193.238.120.33126: S, cksum 0xcff6 (correct), 1482874191:1482874191(0) ack 3222543539 win 5696 mss 1100,sackOK,timestamp 150079063 155080195,nop,wscale 2 11:00:02.149295 IP (tos 0x34, ttl 53, id 50966, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33115 192.109.102.42.3306: ., cksum 0x2703 (correct), 86:86(0) ack 99 win 1460 nop,nop,timestamp 155080241 150079062 11:00:02.153222 IP (tos 0x34, ttl 53, id 19122, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33126 192.109.102.42.3306: ., cksum 0x0daf (correct), 1:1(0) ack 1 win 1460 nop,nop,timestamp 155080246 150079063 11:00:02.153504 IP (tos 0x38, ttl 64, id 56076, offset 0, flags [DF], proto: TCP (6), length: 127) 192.109.102.42.3306 62.193.238.120.33126: P 1:76(75) ack 1 win 1424 nop,nop,timestamp 150079068 155080246 11:00:02.166282 IP (tos 0x38, ttl 64, id 27087, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.33821: P 1015273:1016689(1416) ack 0 win 1424 nop,nop,timestamp 150079070 155079804 11:00:02.190953 IP (tos 0x34, ttl 53, id 19123, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33126 192.109.102.42.3306: ., cksum 0x0d39 (correct), 1:1(0) ack 76 win 1460 nop,nop,timestamp 155080284 150079068 11:00:02.194676 IP (tos 0x0, ttl 53, id 19124, offset 0, flags [DF], proto: TCP (6), length: 116) 62.193.238.120.33126 192.109.102.42.3306: P 1:65(64) ack 76 win 1460 nop,nop,timestamp 155080288 150079068 11:00:02.194727 IP (tos 0x34, ttl 64, id 56077, offset 0, flags [DF], proto: TCP (6), length: 52) 192.109.102.42.3306 62.193.238.120.33126: ., cksum 0x0d15 (correct), 76:76(0) ack 65 win 1424 nop,nop,timestamp 150079072 155080288 11:00:02.194835 IP (tos 0x34, ttl 64, id 56078, offset 0, flags [DF], proto: TCP (6), length: 63) 192.109.102.42.3306 62.193.238.120.33126: P, cksum 0x05fe (correct), 76:87(11) ack 65 win 1424 nop,nop,timestamp 150079072 155080288 11:00:02.223927 IP (tos 0x34, ttl 53, id 64017, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33821 192.109.102.42.3306: ., cksum 0xd02b (correct), 0:0(0) ack 1016689 win 16022 nop,nop,timestamp 155080317 150079070 11:00:02.223961 IP (tos 0x38, ttl 64, id 27088, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.33821: P 1016689:1018105(1416) ack 0 win 1424 nop,nop,timestamp 150079075 155080317 11:00:02.236030 IP (tos 0x0, ttl 53, id 19125, offset 0, flags [DF], proto: TCP (6), length: 73) 62.193.238.120.33126 192.109.102.42.3306: P, cksum 0xcf80 (correct), 65:86(21) ack 87 win 1460 nop,nop,timestamp 155080329 150079072 11:00:02.240355 IP (tos 0x38, ttl 64, id 56079, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.33126: . 87:1503(1416) ack 86 win 1424 nop,nop,timestamp 150079077 155080329 11:00:02.281126 IP (tos 0x34, ttl 53, id 64018, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33821 192.109.102.42.3306: ., cksum 0xca65 (correct), 0:0(0) ack 1018105 win 16022 nop,nop,timestamp 155080374 150079075 11:00:02.375243 IP (tos 0x34, ttl 53, id 19126, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33126 192.109.102.42.3306: ., cksum 0x03bb (correct), 86:86(0) ack 1503 win 2184 nop,nop,timestamp 155080469 150079077 11:00:02.385427 IP (tos 0x38, ttl 64, id 56080, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.33126: . 1503:2919(1416) ack 86 win 1424 nop,nop,timestamp 150079077 155080329 11:00:02.444747 IP (tos 0x34, ttl 53, id 19127, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.33126 192.109.102.42.3306: ., cksum 0xfb19 (correct), 86:86(0) ack 2919 win 2908 nop,nop,timestamp 155080538 150079077 11:00:02.444787 IP (tos 0x38, ttl 64, id 56082, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.33126: P 2919:4335(1416) ack 86 win 1424 nop,nop,timestamp 150079097 155080538 11:00:02.530953 IP (tos 0x34, ttl 53, id 19128, offset 0, flags [DF], proto: TCP (6), length: 52)
Re: [PATCH 2.6.18] WE-21 support (core API)
On 06-09-01 20:55 Michael Buesch wrote: The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. I don't understand why you say it's ill defined, it 100% documented in the iwconfig man page. It is horribly documented. Jean, you have certainly done more for wireless support in Linux than most of us and definitely for a much longer time. However I have to admit that Michael has a point here. The iwconfig manual page doesn't reference a single IO control macro, the big union or a single flag. Reading source code doesn't make things a lot easier, because the drivers do things quite differently or not at all. I had to check by trial and error, what the right semantics of controls might be. For example I spent hours for the controls SIOCGIWFREQ and SIOCSIWFREQ, because I had no idea what the exact semantics of IW_FREQ_FIXED and IW_FREQ_AUTO are and whether it's only a SIOCGIWFREQ issue or not. I fear that user space programmers are facing the same issues. This might be the reason, why we don't have a larger number of graphical widgets that show signal strength and support AP selection. Jean, you could do us all a favour, if you could start to write down, what you know about the wireless extensions. This would help us folks, who do not have your long experience, a lot. In my opinion this One function signature fits all design used in WE is simply broken by design. It leads to exactly this big union, the magic extra field and all the other magic flags here and there. I second this. Simple special structs for the control pairs would have made the task of understanding the interface much more easier and even simpler to document. From my point of view it's a fundamental issue, which could be mitigated by documentation a little bit. But in my opinion it might be about time to put the wireless extension API to rest and replace it by something better. Johannes actually tries to do this. I have also trouble to understand, how adding new controls to the old API should help here. It actually increases the footprint for the compatibility layer and there has not exactly been a lot of pressure to introduce these controls right now. Ciao, Uli -- VGER BF report: U 0.5 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] bonding: Miscellaneous small fixes
Jay Vosburgh wrote: Patch 1: Add 10 Gig support Patch 2: Convert delay value from s16 to int Patch 3: Format fix in seq_printf call Patch 4: Remove unneeded NULL test Patch 5: Handle large hard_header_len Patch 6: Add priv_flag to avoid event mishandling Patch 7: Don't release slaves when master is admin down Will queue these up for 2.6.19. Jeff -- VGER BF report: U 0.499948 - 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 to add board revision to the WLAN chip_id printout
On Friday 01 September 2006 17:28, Larry Finger wrote: Michael, This patch includes the board revision in the chip_id printk for the ssb version of bcm43xx-d80211 and is meant to be applied to wireless-dev. As we have seen, behavior of the chips can be dependent on the rev level, thus a need to have it in the log. Any specific example on this? I mean, every revision in the chip (and bcm43xx has a _lot_) can (and does) change behaviour. But I still think we shouldn't print them all on initialization. ;) Signed-off-by: Larry Finger [EMAIL PROTECTED] Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c @@ -3346,7 +3346,8 @@ static int bcm43xx_attach_board(struct b if (err) goto err_chipset_detach; - printk(KERN_INFO PFX Broadcom %04X WLAN found\n, bcm-ssb.chip_id); + printk(KERN_INFO PFX Broadcom %04X WLAN, Revision %d found\n, + bcm-ssb.chip_id, bcm-board_revision); /* Attach all IO cores to the backplane. */ coremask = 0; -- 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
[RFC] sky2: fragmented DMA
I modified the sky2 driver to do fragmented receive for large MTU.
The hardware supports breaking receive into chunks, so this version allocates
some header space in the skb data up to two pages (assuming 4K page size) for
the extra data.
It doesn't go into fragmented mode until it thinks the alloc_skb will cause
a order 1 allocation. For 1500 byte MTU the effective result is the same.
For systems with 64k pages there is no point in fragmenting.
The patch is part of a bigger set of changes, so it is really for comment
only at this point.
---
drivers/net/sky2.c | 293 ++---
drivers/net/sky2.h | 10 +
2 files changed, 221 insertions(+), 82 deletions(-)
--- sky2.orig/drivers/net/sky2.c2006-09-01 14:16:23.0 -0700
+++ sky2/drivers/net/sky2.c 2006-09-01 14:16:24.0 -0700
@@ -50,19 +50,21 @@
#include sky2.h
#define DRV_NAME sky2
-#define DRV_VERSION1.7
+#define DRV_VERSION1.10
#define PFXDRV_NAME
/*
* 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.
+ * A transmit can require up to 40 ring elements (4 + 18 * 2)
+ * a jumbo receive requires 6 elements (3 * 2)
+ * Ring sizes must be a power of 2.
*/
-#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 +76,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 +91,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);
@@ -814,12 +815,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);
@@ -831,9 +832,52 @@
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
[PATCH]: ethtool: typo fix for e1000
e1000: Typo fix. Signed-off-by: Auke Kok [EMAIL PROTECTED] diff --git a/e1000.c b/e1000.c index 6de27ca..6741323 100644 --- a/e1000.c +++ b/e1000.c @@ -372,7 +372,7 @@ e1000_dump_regs(struct ethtool_drvinfo * Descriptor minimum threshold size: %s\n Broadcast accept mode: %s\n VLAN filter: %s\n - Cononical form indicator: %s\n + Canonical form indicator: %s\n Discard pause frames: %s\n Pass MAC control frames: %s\n, reg,
[PATCH 0/5] skge update
This set fixes several races and performance problems related to bug reports. -- VGER BF report: H 0.437515 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] skge: irq lock race
The driver needs to access the IRQ status inside of lock to avoid
races with other places changing IRQ mask etc. This may be related
to some of the SMP bugs reported against skge in kernel bugzilla.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netdev-2.6.orig/drivers/net/skge.c
+++ netdev-2.6/drivers/net/skge.c
@@ -2891,13 +2891,15 @@ static irqreturn_t skge_intr(int irq, vo
{
struct skge_hw *hw = dev_id;
u32 status;
+ int handled = 0;
+ spin_lock(hw-hw_lock);
/* Reading this register masks IRQ */
status = skge_read32(hw, B0_SP_ISRC);
if (status == 0)
- return IRQ_NONE;
+ goto out;
- spin_lock(hw-hw_lock);
+ handled = 1;
status = hw-intr_mask;
if (status IS_EXT_REG) {
hw-intr_mask = ~IS_EXT_REG;
@@ -2959,9 +2961,10 @@ static irqreturn_t skge_intr(int irq, vo
skge_write32(hw, B0_IMSK, hw-intr_mask);
skge_read32(hw, B0_IMSK);
+out:
spin_unlock(hw-hw_lock);
- return IRQ_HANDLED;
+ return IRQ_RETVAL(handled);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
--
VGER BF report: H 0.00723675
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] skge: use NAPI for transmit complete
The skge driver has much better performance if transmit done is handled in
NAPI softirq. Change from doing transmit locking in driver (LLTX) and
use device lock.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netdev-2.6.orig/drivers/net/skge.c
+++ netdev-2.6/drivers/net/skge.c
@@ -91,7 +91,7 @@ MODULE_DEVICE_TABLE(pci, skge_id_table);
static int skge_up(struct net_device *dev);
static int skge_down(struct net_device *dev);
static void skge_phy_reset(struct skge_port *skge);
-static void skge_tx_clean(struct skge_port *skge);
+static void skge_tx_clean(struct net_device *dev);
static int xm_phy_write(struct skge_hw *hw, int port, u16 reg, u16 val);
static int gm_phy_write(struct skge_hw *hw, int port, u16 reg, u16 val);
static void genesis_get_stats(struct skge_port *skge, u64 *data);
@@ -105,6 +105,7 @@ static const int txqaddr[] = { Q_XA1, Q_
static const int rxqaddr[] = { Q_R1, Q_R2 };
static const u32 rxirqmask[] = { IS_R1_F, IS_R2_F };
static const u32 txirqmask[] = { IS_XA1_F, IS_XA2_F };
+static const u32 irqmask[] = { IS_R1_F|IS_XA1_F, IS_R2_F|IS_XA2_F };
static int skge_get_regs_len(struct net_device *dev)
{
@@ -2283,7 +2284,7 @@ static int skge_down(struct net_device *
skge_led(skge, LED_MODE_OFF);
netif_poll_disable(dev);
- skge_tx_clean(skge);
+ skge_tx_clean(dev);
skge_rx_clean(skge);
kfree(skge-rx_ring.start);
@@ -2308,25 +2309,12 @@ static int skge_xmit_frame(struct sk_buf
int i;
u32 control, len;
u64 map;
- unsigned long flags;
if (skb_padto(skb, ETH_ZLEN))
return NETDEV_TX_OK;
- if (!spin_trylock_irqsave(skge-tx_lock, flags))
- /* Collision - tell upper layer to requeue */
- return NETDEV_TX_LOCKED;
-
- if (unlikely(skge_avail(skge-tx_ring) skb_shinfo(skb)-nr_frags +
1)) {
- if (!netif_queue_stopped(dev)) {
- netif_stop_queue(dev);
-
- printk(KERN_WARNING PFX %s: ring full when queue
awake!\n,
- dev-name);
- }
- spin_unlock_irqrestore(skge-tx_lock, flags);
+ if (unlikely(skge_avail(skge-tx_ring) skb_shinfo(skb)-nr_frags +
1))
return NETDEV_TX_BUSY;
- }
e = skge-tx_ring.to_use;
td = e-desc;
@@ -2401,8 +2389,6 @@ static int skge_xmit_frame(struct sk_buf
netif_stop_queue(dev);
}
- spin_unlock_irqrestore(skge-tx_lock, flags);
-
dev-trans_start = jiffies;
return NETDEV_TX_OK;
@@ -2432,18 +2418,18 @@ static void skge_tx_free(struct skge_por
printk(KERN_DEBUG PFX %s: tx done slot %td\n,
skge-netdev-name, e - skge-tx_ring.start);
- dev_kfree_skb_any(e-skb);
+ dev_kfree_skb(e-skb);
}
e-skb = NULL;
}
/* Free all buffers in transmit ring */
-static void skge_tx_clean(struct skge_port *skge)
+static void skge_tx_clean(struct net_device *dev)
{
+ struct skge_port *skge = netdev_priv(dev);
struct skge_element *e;
- unsigned long flags;
- spin_lock_irqsave(skge-tx_lock, flags);
+ netif_tx_lock_bh(dev);
for (e = skge-tx_ring.to_clean; e != skge-tx_ring.to_use; e =
e-next) {
struct skge_tx_desc *td = e-desc;
skge_tx_free(skge, e, td-control);
@@ -2451,8 +2437,8 @@ static void skge_tx_clean(struct skge_po
}
skge-tx_ring.to_clean = e;
- netif_wake_queue(skge-netdev);
- spin_unlock_irqrestore(skge-tx_lock, flags);
+ netif_wake_queue(dev);
+ netif_tx_unlock_bh(dev);
}
static void skge_tx_timeout(struct net_device *dev)
@@ -2463,7 +2449,7 @@ static void skge_tx_timeout(struct net_d
printk(KERN_DEBUG PFX %s: tx timeout\n, dev-name);
skge_write8(skge-hw, Q_ADDR(txqaddr[skge-port], Q_CSR), CSR_STOP);
- skge_tx_clean(skge);
+ skge_tx_clean(dev);
}
static int skge_change_mtu(struct net_device *dev, int new_mtu)
@@ -2679,15 +2665,15 @@ resubmit:
}
/* Free all buffers in Tx ring which are no longer owned by device */
-static void skge_txirq(struct net_device *dev)
+static void skge_tx_done(struct net_device *dev)
{
struct skge_port *skge = netdev_priv(dev);
struct skge_ring *ring = skge-tx_ring;
struct skge_element *e;
- rmb();
+ skge_write8(skge-hw, Q_ADDR(txqaddr[skge-port], Q_CSR), CSR_IRQ_CL_F);
- spin_lock(skge-tx_lock);
+ netif_tx_lock(dev);
for (e = ring-to_clean; e != ring-to_use; e = e-next) {
struct skge_tx_desc *td = e-desc;
@@ -2698,11 +2684,10 @@ static void skge_txirq(struct net_device
}
skge-tx_ring.to_clean = e;
- if (netif_queue_stopped(skge-netdev)
-skge_avail(skge-tx_ring) TX_LOW_WATER)
- netif_wake_queue(skge-netdev);
+
[PATCH 4/5] skge: version 1.8
Because of the NAPI and other SMP fixes, let's call this a version. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- skge-2.6.orig/drivers/net/skge.c +++ skge-2.6/drivers/net/skge.c @@ -43,7 +43,7 @@ #include skge.h #define DRV_NAME skge -#define DRV_VERSION1.7 +#define DRV_VERSION1.8 #define PFXDRV_NAME #define DEFAULT_TX_RING_SIZE 128 -- -- VGER BF report: H 0.0441835 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] skge: pci_post bugs
There are several places where this driver needs to ensure that PCI accesses have completed before releasing locks. These maybe related to the problem (not verified): http://bugzilla.kernel.org/show_bug.cgi?id=6142 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- netdev-2.6.orig/drivers/net/skge.c +++ netdev-2.6/drivers/net/skge.c @@ -2747,7 +2747,7 @@ static int skge_poll(struct net_device * spin_lock_irq(hw-hw_lock); hw-intr_mask |= rxirqmask[skge-port]; skge_write32(hw, B0_IMSK, hw-intr_mask); - mmiowb(); + skge_read32(hw, B0_IMSK); spin_unlock_irq(hw-hw_lock); return 0; @@ -2881,6 +2881,7 @@ static void skge_extirq(void *arg) spin_lock_irq(hw-hw_lock); hw-intr_mask |= IS_EXT_REG; skge_write32(hw, B0_IMSK, hw-intr_mask); + skge_read32(hw, B0_IMSK); spin_unlock_irq(hw-hw_lock); } @@ -2955,6 +2956,7 @@ static irqreturn_t skge_intr(int irq, vo skge_error_irq(hw); skge_write32(hw, B0_IMSK, hw-intr_mask); + skge_read32(hw, B0_IMSK); spin_unlock(hw-hw_lock); return IRQ_HANDLED; @@ -3424,6 +3426,7 @@ static void __devexit skge_remove(struct spin_lock_irq(hw-hw_lock); hw-intr_mask = 0; skge_write32(hw, B0_IMSK, 0); + skge_read32(hw, B0_IMSK); spin_unlock_irq(hw-hw_lock); skge_write16(hw, B0_LED, LED_STAT_OFF); -- -- VGER BF report: H 0.178292 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] skge: use netdev_alloc_skb
Change to use new netdev_alloc_skb interface for 2.6.18.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -818,8 +818,9 @@ static void skge_rx_clean(struct skge_po
/* Allocate buffers for receive ring
* For receive: to_clean is next received frame.
*/
-static int skge_rx_fill(struct skge_port *skge)
+static int skge_rx_fill(struct net_device *dev)
{
+ struct skge_port *skge = netdev_priv(dev);
struct skge_ring *ring = skge-rx_ring;
struct skge_element *e;
@@ -827,8 +828,8 @@ static int skge_rx_fill(struct skge_port
do {
struct sk_buff *skb;
- skb = __dev_alloc_skb(skge-rx_buf_size + NET_IP_ALIGN,
- GFP_KERNEL);
+ skb = __netdev_alloc_skb(dev, skge-rx_buf_size + NET_IP_ALIGN,
+GFP_KERNEL);
if (!skb)
return -ENOMEM;
@@ -2179,7 +2180,7 @@ static int skge_up(struct net_device *de
if (err)
goto free_pci_mem;
- err = skge_rx_fill(skge);
+ err = skge_rx_fill(dev);
if (err)
goto free_rx_ring;
@@ -2585,16 +2586,17 @@ static inline int bad_phy_status(const s
/* Get receive buffer from descriptor.
* Handles copy of small buffers and reallocation failures
*/
-static inline struct sk_buff *skge_rx_get(struct skge_port *skge,
- struct skge_element *e,
- u32 control, u32 status, u16 csum)
+static struct sk_buff *skge_rx_get(struct net_device *dev,
+ struct skge_element *e,
+ u32 control, u32 status, u16 csum)
{
+ struct skge_port *skge = netdev_priv(dev);
struct sk_buff *skb;
u16 len = control BMU_BBC;
if (unlikely(netif_msg_rx_status(skge)))
printk(KERN_DEBUG PFX %s: rx slot %td status 0x%x len %d\n,
- skge-netdev-name, e - skge-rx_ring.start,
+ dev-name, e - skge-rx_ring.start,
status, len);
if (len skge-rx_buf_size)
@@ -2610,7 +2612,7 @@ static inline struct sk_buff *skge_rx_ge
goto error;
if (len RX_COPY_THRESHOLD) {
- skb = dev_alloc_skb(len + 2);
+ skb = netdev_alloc_skb(dev, len + 2);
if (!skb)
goto resubmit;
@@ -2625,7 +2627,7 @@ static inline struct sk_buff *skge_rx_ge
skge_rx_reuse(e, skge-rx_buf_size);
} else {
struct sk_buff *nskb;
- nskb = dev_alloc_skb(skge-rx_buf_size + NET_IP_ALIGN);
+ nskb = netdev_alloc_skb(dev, skge-rx_buf_size + NET_IP_ALIGN);
if (!nskb)
goto resubmit;
@@ -2640,20 +2642,19 @@ static inline struct sk_buff *skge_rx_ge
}
skb_put(skb, len);
- skb-dev = skge-netdev;
if (skge-rx_csum) {
skb-csum = csum;
skb-ip_summed = CHECKSUM_HW;
}
- skb-protocol = eth_type_trans(skb, skge-netdev);
+ skb-protocol = eth_type_trans(skb, dev);
return skb;
error:
if (netif_msg_rx_err(skge))
printk(KERN_DEBUG PFX %s: rx err, slot %td control 0x%x status
0x%x\n,
- skge-netdev-name, e - skge-rx_ring.start,
+ dev-name, e - skge-rx_ring.start,
control, status);
if (skge-hw-chip_id == CHIP_ID_GENESIS) {
@@ -2723,7 +2724,7 @@ static int skge_poll(struct net_device *
if (control BMU_OWN)
break;
- skb = skge_rx_get(skge, e, control, rd-status, rd-csum2);
+ skb = skge_rx_get(dev, e, control, rd-status, rd-csum2);
if (likely(skb)) {
dev-last_rx = jiffies;
netif_receive_skb(skb);
--
--
VGER BF report: H 0.0016278
-
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: i not find in the kernel code the code of this command
On 9/2/06, Franco [EMAIL PROTECTED] wrote: I thought that this code was police.c but seem that it isn't i must implement a proc file in the code and recompiling the kernel. I'm not sure I understand your question. Please tell me if I answer wrong! The code is under net/sched in the source tree. The main file is act_police.c but it is in use elsewhere as well. grep for POLICE. To build the code you need to alter your kernel options under 'make menuconfig' Networking, Networking Options, Qos and/or fair queueing, Actions must be selected and then Traffic Police. I hope this helps. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand -- VGER BF report: U 0.5 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18] WE-21 support (core API)
On Saturday 02 September 2006 00:10, Jean Tourrilhes wrote: On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote: Note that one thing that worry me with your approach is footprint. I've used various embedded devices over the years, such as the Gumstix (4MB Flash), and this is why WE was optimised for footprint. Can you please explain in more detail, how WE + the WE-netlink wrapper has lower footprint than this netlink-only layer? WE-netlink is optional. And WE-ioctl could be made optional (still on the todo list). You can also disable WE-event and WE-iwspy for further footprint reduction. And we don't need all this stuff on these devices? OK, nl80211 can easily be made optional, too. The real problem with WE is, as I previously said, the ill-defined semantics of both the user-space API and the in-kernel API. I don't understand why you say it's ill defined, it 100% documented in the iwconfig man page. It is horribly documented. There is one big union and one magic extra parameter. You have to guess (or look at other implementations) to find out which element of the union or even if and how to use the extra parameter. That's a real pain. And after you found out which element to use, you have to figure out somehow how to actually use that element. That's nontrivial, escpecially because some flags (that are not documented) may magically change the whole semantics of the contents. If you are trying to write WE without reading any other code, that's true. But that's not the way sane people work. Sane people cut'n'paste from other drivers, and then check the source code of iwconfig (which is fully commented) in case of doubt. It's strange, many driver authors are not afraid of asking me questions, but some can't manage to do that. Heh, well. I would say sane code should not raise the questions in the first place. In my opinion this One function signature fits all design used in WE is simply broken by design. So, are you saying that the 'syscal' design is broken by nature ? I've never seen the kernel and glibc people complaining about it. ?? All syscalls have the same function signature? I doubt that. It was designed this way on purpose, because you get low footprint and very good scalability. And I've yet to see anyone tripped by it. I don't see how this is lower footprint. A function pointer is always the same size. Regardless of how the function looks like. -- Greetings Michael. -- VGER BF report: U 0.5 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i not find in the kernel code the code of this command
thanks for your response! Yes, The code is under net/sched in the source tree. The file act_police.c in the directoy net/sched don't exist. there is police.c that have a very similar code act_police.c (that i have found on internet) however i have doon 'make menuconfig', i have gone to traffic policing and it is selectionated but there is only the *. there isn't M that means modularized featured and i can't insert M in traffic policing you have help me very much with this last information. But, at this point, if i want create a proc file in police.c, therefore modificate the kernel, i must install on my pc another version on linux. It is exact? Thanks bye Franco - Original Message - From: Ian McDonald [EMAIL PROTECTED] To: Franco [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Sent: Saturday, September 02, 2006 2:04 AM Subject: Re: i not find in the kernel code the code of this command On 9/2/06, Franco [EMAIL PROTECTED] wrote: I thought that this code was police.c but seem that it isn't i must implement a proc file in the code and recompiling the kernel. I'm not sure I understand your question. Please tell me if I answer wrong! The code is under net/sched in the source tree. The main file is act_police.c but it is in use elsewhere as well. grep for POLICE. To build the code you need to alter your kernel options under 'make menuconfig' Networking, Networking Options, Qos and/or fair queueing, Actions must be selected and then Traffic Police. I hope this helps. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand __ Informazione NOD32 1.1607 (20060619) __ Questo messaggio è stato controllato dal Sistema Antivirus NOD32 http://www.nod32.it -- VGER BF report: U 0.502266 - 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: icmp echo reply and DF
Marco Berizzi [EMAIL PROTECTED] wrote:
I kindly would like to know why linux reply to ICMP
echo request packets with the DF bit set always to 0.
We do that because that's the only sensible thing to do if you
actually want ICMP messages to reach the destination host. PMTU
on ICMP does not make sense.
Furthermore, ICMP echo means echoing at the ICMP level, it does
not mean that we have to echo things inside the IP header.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
VGER BF report: U 0.5
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP send/ack lockstep problem
Matthias Urlichs [EMAIL PROTECTED] wrote:
Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and tell us?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
VGER BF report: U 0.52
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 Detected Tx Unit Hang
Paul Aviles wrote: I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS10 and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a large ftp transfer to the server. It does not happen if the server is connected to a dummy 100 Mb switch, only when is connected to the Gig switch. I have also tried the options line below disabling tso, tx and rx in the modprobe.conf without any luck. options e1000 XsumRX=0 Speed=1000 Duplex=2 InterruptThrottleRate=0 FlowControl=3 RxDescriptors=4096 TxDescriptors=4096 RxIntDelay=0 TxIntDelay=0 in /var/log/kernel I get the following... Sep 1 23:53:01 www kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Sep 1 23:53:01 www kernel: Tx Queue 0 Sep 1 23:53:01 www kernel: TDH 4c4 Sep 1 23:53:01 www kernel: TDT 4c9 Sep 1 23:53:01 www kernel: next_to_use 4c9 Sep 1 23:53:01 www kernel: next_to_clean4c4 Sep 1 23:53:01 www kernel: buffer_info[next_to_clean] Sep 1 23:53:01 www kernel: time_stamp 9c60 Sep 1 23:53:01 www kernel: next_to_watch4c4 Sep 1 23:53:01 www kernel: jiffies 9d96 Sep 1 23:53:01 www kernel: next_to_watch.status 0 . repeats the same as above a few times . Sep 1 23:53:10 www kernel: NETDEV WATCHDOG: eth0: transmit timed out Sep 1 23:53:13 www kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex then the server locks up, no response from the keyboard at all and must be forced down with a power kill. Here is my driver info, driver: e1000 version: 7.0.33-k2-NAPI firmware-version: N/A bus-info: :02:01.0 What else could I check? [adding netdev to cc, this is a NET issue] This is a known issue and there are several discussions and bugs filed on this. Please read this one where most is documented, and also the netdev http://sourceforge.net/tracker/index.php?func=detailaid=1463045group_id=42302atid=447449 more links and information available on http://e1000.sf.net/ Your debugging information might be needed and helpful, so please take the trouble of digging in the previous bugreports and reporting anything that might be relevant there. The full lockup is certainly not good, but should not necessarily be related to the tx hang (or the cause of that). It is likely that interrupt sharing might be a problem here; what kind of e1000 nic is this? lspci -vv? Cheers, Auke -- VGER BF report: H 0.00334085 - 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: TCP send/ack lockstep problem
Hi,
Herbert Xu:
Matthias Urlichs [EMAIL PROTECTED] wrote:
Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and tell us?
The stuff I see in there doesn't look stupid to me.
accept(...) = 216
setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0
setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
followed by a bunch of interactive read() and write() calls, and then
a rather long sequence of 16384-byte writes (all of which end up being
partial because the send buffer size is 12k).
so if one of these is the cause for the observed lockstep behavior when
the send buffer is *full*, I'd consider that to be a bug.
Interestingly, the *sender* advertizes window that's (a bit more than) one MTU:
07:47:03.204939 IP (tos 0x38, ttl 64, id 41217, offset 0, flags [DF], proto:
TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.53138: .
167089:168505 (1416) ack 0 win 1424 nop,nop,timestamp 218027038 834794727
but that's the other direction -- is something in the kernel confused about
which window variable to use ??
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
VGER BF report: U 0.499405
-
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
