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.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: [GENL]: Provide more information to userspace about registered genl families
On Thu, 2006-08-31 at 17:46 -0400, jamal wrote: > I think it would be valuable to specify a set of flags for filtering > what gets sent to user space instead of unconditionally. > > Example, > filter level 0: > - what we have before your patch > filter level 1: > - protocol version > - header size > - maximum number of attributes > filter level 2: > - the rest of the stuff you have > > What netlink does today to filter at user space is something that can be > avoided with the above (an improvement in my opinion if you have a lot > of genl items in the kernel). What I'd personally like to see for nl80211 if we go there is an actual filter callback, then I could completely avoid the command I have in there for getting a command list for a given interface, and just filter out those commands that some interface doesn't support. 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 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 - 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: "Ian McDonald" <[EMAIL PROTECTED]> Date: Fri, 1 Sep 2006 15:39:37 +1200 > > > I'm ready to rip out ABC entirely, to be honest. Or at least > > > turn it off by default. > > > > Turn it off for 2.6.18, by default then evaluate more for 2.6.19 > > > If it goes out in 2.6.18 there could probably be a good argument for > going into the stable tree as well... to stop the likes of the JVM > type issues that users keep hitting (which is fixed or going to be > fixed by Sun). I completely agree. - 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] xfrm: remove xerr_idxp from __xfrm_policy_check()
It seems that during the MIPv6 respin, some code which was originally
conditionally compiled around CONFIG_XFRM_ADVANCED was accidently left in
after the config option was removed.
This patch removes an extraneous pointer (xerr_idxp) which is no longer
needed.
Please review & apply.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
net/xfrm/xfrm_policy.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff -purN -X dontdiff net-2.6.19.o/net/xfrm/xfrm_policy.c
net-2.6.19.x/net/xfrm/xfrm_policy.c
--- net-2.6.19.o/net/xfrm/xfrm_policy.c 2006-08-30 00:31:38.0 -0400
+++ net-2.6.19.x/net/xfrm/xfrm_policy.c 2006-09-01 00:40:25.0 -0400
@@ -1514,8 +1514,7 @@ static inline int secpath_has_nontranspo
{
for (; k < sp->len; k++) {
if (sp->xvec[k]->props.mode != XFRM_MODE_TRANSPORT) {
- if (idxp)
- *idxp = k;
+ *idxp = k;
return 1;
}
}
@@ -1534,7 +1533,6 @@ int __xfrm_policy_check(struct sock *sk,
struct flowi fl;
u8 fl_dir = policy_to_flow_dir(dir);
int xerr_idx = -1;
- int *xerr_idxp = &xerr_idx;
if (xfrm_decode_session(skb, &fl, family) < 0)
return 0;
@@ -1560,7 +1558,7 @@ int __xfrm_policy_check(struct sock *sk,
xfrm_policy_lookup);
if (!pol) {
- if (skb->sp && secpath_has_nontransport(skb->sp, 0, xerr_idxp))
{
+ if (skb->sp && secpath_has_nontransport(skb->sp, 0, &xerr_idx))
{
xfrm_secpath_reject(xerr_idx, skb, &fl);
return 0;
}
@@ -1619,13 +1617,14 @@ int __xfrm_policy_check(struct sock *sk,
for (i = xfrm_nr-1, k = 0; i >= 0; i--) {
k = xfrm_policy_ok(tpp[i], sp, k, family);
if (k < 0) {
- if (k < -1 && xerr_idxp)
- *xerr_idxp = -(2+k);
+ if (k < -1)
+ /* "-2 - errored_index" returned */
+ xerr_idx = -(2+k);
goto reject;
}
}
- if (secpath_has_nontransport(sp, k, xerr_idxp))
+ if (secpath_has_nontransport(sp, k, &xerr_idx))
goto reject;
xfrm_pols_put(pols, npols);
-
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: LRO fix needed
On Fri, Sep 01, 2006 at 09:43:47AM +1000, herbert wrote:
>
> It might be better to set it to the biggest frag you see rather
> than the first.
I've coded it up.
BTW Ananda, what hardware assistance do your chips currently provide
for LRO? What are the timeouts used before it gives up on aggregating
a session?
[NETDRV] s2io: Set gso_size for LRO to TCP stack
Now that the TCP stack uses gso_size to estimate the receive MSS,
it helps to actually set it :)
Unlike the sending side, there is no single MSS that naturally
pops up for LRO. However, for our purposes the maximal TCP payload
size is the most appropriate for estimating MSS.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index e72e0e0..3ebc789 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -6522,6 +6522,8 @@ static int rx_osm_handler(ring_info_t *r
&tcp_len, &lro, rxdp, sp);
switch (ret) {
case 3: /* Begin anew */
+ skb_shinfo(skb)->gso_size =
+ tcp_len;
lro->parent = skb;
goto aggregate;
case 1: /* Aggregate */
@@ -7556,6 +7558,8 @@ static void lro_append_pkt(nic_t *sp, lr
{
struct sk_buff *first = lro->parent;
+ if (tcp_len > skb_shinfo(first)->gso_size)
+ skb_shinfo(first)->gso_size = tcp_len;
first->len += tcp_len;
first->data_len = lro->frags_len;
skb_pull(skb, (skb->len - tcp_len));
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][IPSEC]: tunnel mode processing
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? If this packet is going somewhere you're going
to have a dst one way or another :)
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[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]d80211: fix "iwconfig key [x]" behavior
On Thu, 2006-08-31 at 01:24, Jiri Benc wrote:
> On Mon, 28 Aug 2006 16:36:39 +0800, Hong Liu wrote:
> > "iwconfig key [x]" behavior is not correctly handled in the stack, also
> > modify the giwencode method to show the key info.
>
> Thanks for spotting and fixing these bugs!
>
> > @@ -2869,7 +2877,8 @@ static int ieee80211_ioctl_giwencode(str
> > return 0;
> > }
> >
> > - erq->length = 0;
> > + erq->length = sdata->keys[idx]->keylen;
> > + memcpy(key, sdata->keys[idx]->key, erq->length);
>
> Shouldn't there be a check for buffer size here?
>
> Thanks,
>
> Jiri
>
> --
> Jiri Benc
> SUSE Labs
>
>
Signed-off-by: Hong Liu <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..c9a3524 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -2867,9 +2867,10 @@ static int ieee80211_ioctl_siwencode(str
if (!sdata->default_key)
idx = 0;
else for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- if (sdata->default_key == sdata->keys[i])
+ if (sdata->default_key == sdata->keys[i]) {
idx = i;
- break;
+ break;
+ }
}
if (idx < 0)
return -EINVAL;
@@ -2880,16 +2881,21 @@ static int ieee80211_ioctl_siwencode(str
alg = ALG_NONE;
else if (erq->length == 0) {
/* No key data - just set the default TX key index */
- sdata->default_key = sdata->keys[idx];
+ if (sdata->default_key != sdata->keys[idx]) {
+ if (sdata->default_key)
+ ieee80211_key_sysfs_remove_default(sdata);
+ sdata->default_key = sdata->keys[idx];
+ if (sdata->default_key)
+ ieee80211_key_sysfs_add_default(sdata);
+ }
+ return 0;
}
return ieee80211_set_encryption(
dev, bcaddr,
- idx, erq->length == 0 ? ALG_NONE : ALG_WEP,
+ idx, alg,
!sdata->default_key,
NULL, keybuf, erq->length);
-
- return 0;
}
@@ -2908,9 +2914,10 @@ static int ieee80211_ioctl_giwencode(str
if (!sdata->default_key)
idx = 0;
else for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- if (sdata->default_key == sdata->keys[i])
+ if (sdata->default_key == sdata->keys[i]) {
idx = i;
- break;
+ break;
+ }
}
if (idx < 0)
return -EINVAL;
@@ -2925,7 +2932,8 @@ static int ieee80211_ioctl_giwencode(str
return 0;
}
- erq->length = 0;
+ erq->length = min((int)erq->length, sdata->keys[idx]->keylen);
+ memcpy(key, sdata->keys[idx]->key, erq->length);
erq->flags |= IW_ENCODE_ENABLED;
return 0;
@@ -3054,9 +3062,10 @@ static int ieee80211_ioctl_siwencodeext(
if (!sdata->default_key)
idx = 0;
else for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
- if (sdata->default_key == sdata->keys[i])
+ if (sdata->default_key == sdata->keys[i]) {
idx = i;
- break;
+ break;
+ }
}
if (idx < 0)
return -EINVAL;
-
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 Thu, 2006-08-31 at 01:10, Jiri Benc wrote:
> On Fri, 25 Aug 2006 16:32:13 +0800, Hong Liu wrote:
> > Add hardware scan callback to support cards like ipw3945 which
> > implements the scan command in firmware.
>
> How ipw3945 performs scan? From the patch, it looks like it switches
> channels (and sends probe requests) in the firmware and delivers all
> received beacons and probe responses through the normal rx path to be
> handled in a software MAC layer. This is really weird behaviour and
> doesn't make sense to me. Why isn't channel switching left to the
> software MAC as well?
>
> > +/* set station scan completed */
> > +void ieee80211_set_scan_completed(struct net_device *dev);
>
> Why "set"? "ieee80211_scan_completed" sounds better.
>
> Thanks,
>
> Jiri
>
> --
> Jiri Benc
> SUSE Labs
>
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.c b/net/d80211/ieee80211.c
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 557ba17..8541a52 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,9 +2559,12 @@ int ieee80211_sta_req_scan(struct net_de
printk(KERN_DEBUG "%s: starting scan\n", dev->name);
+ local->sta_scanning = 1;
+ if (local->hw->hw_scan)
+ return local->hw->hw_scan(dev, ssid, ssid_len);
+
ieee80211_sta_save_oper_chan(dev);
- local->sta_scanning = 1;
/* TODO: stop TX queue? */
Re: [PATCH 1/2]d80211: fix wpa_supplicant reassoc problem
On Thu, 2006-08-31 at 00:57, Jiri Benc wrote:
> On Fri, 25 Aug 2006 16:32:08 +0800, Hong Liu wrote:
> > After key negotiation completed using wpa_supplicant, wpa_supplicant
> > can't reassoc with the AP if we reboot the AP. It always fails at the
> > 4-way handshake.
> > The problem is the key info is not cleared correctly. Thus when
> > wpa_supplicant send the EAPOL-KEY packet, the d80211 stack finds the old
> > key and uses it to encrypt the packet.
> >
> > The patch removes the sta_info when we disassociate with AP.
>
> Please:
> - add proper Signed-off-by line
> - do not send patches as an attachment
> - Cc: John Linville <[EMAIL PROTECTED]> as well as me on d80211
> patches
>
> > diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
> > index 8caf352..2144b34 100644
> > --- a/net/d80211/ieee80211_sta.c
> > +++ b/net/d80211/ieee80211_sta.c
> > @@ -739,6 +739,14 @@ static void ieee80211_associated(struct
> > wireless_send_event(dev, SIOCGIWAP, &wrqu, NULL);
> > mod_timer(&ifsta->timer,
> > jiffies + IEEE80211_MONITORING_INTERVAL + 30 * HZ);
> > +
> > + sta = sta_info_get(local, ifsta->bssid);
> > + if (sta) {
> > + sta_info_free(sta, 0);
> > + sta_info_put(sta);
> > + }
> > +
> > + ifsta->probereq_poll = 0;
>
> Wouldn't it be better to move this into the 'else' branch of previous
> 'if' statement (i.e. just before sta_info_put call in the
> ieee80211_associated function)?
>
Rework the patch according to Jiri's comments.
Signed-off-by: Hong Liu <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..557ba17 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -710,6 +710,8 @@ static void ieee80211_associated(struct
"range\n",
dev->name, MAC_ARG(ifsta->bssid));
disassoc = 1;
+ sta_info_free(sta, 0);
+ ifsta->probereq_poll = 0;
} else {
ieee80211_send_probe_req(dev, ifsta->bssid,
local->scan_ssid,
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 622b234..5edbd0c 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -197,6 +197,12 @@ #ifdef CONFIG_D80211_VERBOSE_DEBUG
local->mdev->name, MAC_ARG(sta->addr));
#endif /* CONFIG_D80211_VERBOSE_DEBUG */
+ if (sta->key) {
+ ieee80211_key_sysfs_remove(sta->key);
+ ieee80211_key_free(sta->key);
+ sta->key = NULL;
+ }
+
rate_control_remove_sta_attrs(local, sta->rate_ctrl_priv, &sta->kobj);
ieee80211_sta_sysfs_remove(sta);
@@ -244,8 +250,6 @@ void sta_info_free(struct sta_info *sta,
kfree(key);
}
}
- ieee80211_key_free(sta->key);
- sta->key = NULL;
} else if (sta->key_idx_compression != HW_KEY_IDX_INVALID) {
struct ieee80211_key_conf conf;
memset(&conf, 0, sizeof(conf));
-
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
> I'm ready to rip out ABC entirely, to be honest. Or at least > turn it off by default. Turn it off for 2.6.18, by default then evaluate more for 2.6.19 If it goes out in 2.6.18 there could probably be a good argument for going into the stable tree as well... to stop the likes of the JVM type issues that users keep hitting (which is fixed or going to be fixed by Sun). -- 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 - 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 Thu, 31 Aug 2006 16:57:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Alexey Kuznetsov <[EMAIL PROTECTED]> > Date: Fri, 1 Sep 2006 03:29:23 +0400 > > > > 2) a way to take delayed ACKs into account for cwnd growth > > > > This part is OK now, right? > > This part of ABC is not on by default, and was broken until last week > :-) > > Test in tcp_slow_start() used to be: > > tp->bytes_acked > 2*tp->mss_cache > > but now it is the correct: > > tp->bytes_acked >= 2*tp->mss_cache > > It allows to make two congestion window increases from one ACK, when > noticing delayed ACK. > > Non-ABC code did not do this, but could figure this kind of thing > out while scanning retransmit queue. > > > > 1) protection against ACK division > > > > But Linux never had this problem... Congestion window was increased > > only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could > > break this, but should not). Otherwise, this ACK just advanced snd_una > > and nothing more. > > Ugh, I missed this. :-/ > > The TSO code is carefuly to only trim TSO skbs on proper boundaries, > and this ensures proper setting of FLAG_DATA_ACKED too. So no > problems here. > > > The only problem of kind "too-aggressive" with Linux was that we could > > develop large cwnd sending small segments, and then switch to sending > > mss-sized segments. It does not look scary, to be honest. :-) > > Agreed. > > > Linux had troubles with slow start even before ABC. Actually, > > some of applications can suffer of the same syndrome even if ABC disabled. > > With ABC it becomes TROUBLE, cwnd has no chances to develop at all. > > I've discussed that very issue here before, some time ago, with > John Heffner. It was in response to a user reporting a similar > 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, but that might have other problems. > > There is an assymetry between how we do congestion control on > sending (packet counting) and our ACK policy on receive (packet > sized based). > > > 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. Turn it off for 2.6.18, by default then evaluate more for 2.6.19 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM] STATE: Fix flusing with hash mask.
David Miller wrote: Masahide-san, please provide a Signed-off-by: line in the future, even for simple changes like this one. OK, I'll :-) Regards, -- Masahide NAKAMURA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][IPSEC]: tunnel mode processing
At the moment transport mode processing is not dependent on skb->dst
being passed. Tunnel mode derives the ip->id and ttl from it. More like
computes ip->id.
I am trying to generate traffic via pktgen and it would be nice if i
could get the same behavior on tunnel mode as in transport mode. I dont
think it matters what the values of those two fields are.
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()::
top_iph->frag_off = (flags & XFRM_STATE_NOPMTUDISC) ?
0 : (iph->frag_off & htons(IP_DF));
if (dst) {
if (!top_iph->frag_off)
__ip_select_ident(top_iph, dst->child, 0);
top_iph->ttl = dst_metric(dst->child, RTAX_HOPLIMIT);
} else {
top_iph->id = iph->id;
top_iph->ttl = iph->ttl;
}
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: [IPSEC]: output mode to take an xfrm state as input param
From: jamal <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 20:29:36 -0400 > On Thu, 2006-31-08 at 17:24 -0700, David Miller wrote: > > Are you too cool to give "Signed-off-by:" lines? > > :-) > > > > Dang. Just too brain congested to give you one ;-> > > signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]> Applied thanks :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPSEC]: output mode to take an xfrm state as input param
On Thu, 2006-31-08 at 17:24 -0700, David Miller wrote: > Are you too cool to give "Signed-off-by:" lines? > :-) > Dang. Just too brain congested to give you one ;-> signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]> 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: [IPSEC]: output mode to take an xfrm state as input param
Are you too cool to give "Signed-off-by:" lines? :-) Please give me one for this patch so I can add it to net-2.6.19 Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPSEC]: output mode to take an xfrm state as input param
Against net-2.6.19
cheers,
jamal
Expose IPSEC modes output path to take an xfrm state as input param.
This makes it consistent with the input mode processing (which already
takes the xfrm state as a param).
---
commit 0169ac1c2a64f04deeff3dae704f34e22ae59cb7
tree 8ae315bf21444eec3f845538ac06a080a184a534
parent 28df617d024ac4eaeb51123eea9eda2932466684
author Jamal Hadi Salim <[EMAIL PROTECTED]> Thu, 31 Aug 2006 19:55:17 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED](none)> Thu, 31 Aug 2006 19:55:17
-0400
include/net/xfrm.h |2 +-
net/ipv4/xfrm4_mode_transport.c |4 +---
net/ipv4/xfrm4_mode_tunnel.c|3 +--
net/ipv4/xfrm4_output.c |2 +-
net/ipv6/xfrm6_mode_ro.c|3 +--
net/ipv6/xfrm6_mode_transport.c |3 +--
net/ipv6/xfrm6_mode_tunnel.c|3 +--
net/ipv6/xfrm6_output.c |2 +-
8 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9d366a2..bf8e2df 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -286,7 +286,7 @@ extern void xfrm_put_type(struct xfrm_ty
struct xfrm_mode {
int (*input)(struct xfrm_state *x, struct sk_buff *skb);
- int (*output)(struct sk_buff *skb);
+ int (*output)(struct xfrm_state *x,struct sk_buff *skb);
struct module *owner;
unsigned int encap;
diff --git a/net/ipv4/xfrm4_mode_transport.c b/net/ipv4/xfrm4_mode_transport.c
index a9e6b3d..92676b7 100644
--- a/net/ipv4/xfrm4_mode_transport.c
+++ b/net/ipv4/xfrm4_mode_transport.c
@@ -21,9 +21,8 @@ #include
* On exit, skb->h will be set to the start of the payload to be processed
* by x->type->output and skb->nh will be set to the top IP header.
*/
-static int xfrm4_transport_output(struct sk_buff *skb)
+static int xfrm4_transport_output(struct xfrm_state *x, struct sk_buff *skb)
{
- struct xfrm_state *x;
struct iphdr *iph;
int ihl;
@@ -33,7 +32,6 @@ static int xfrm4_transport_output(struct
ihl = iph->ihl * 4;
skb->h.raw += ihl;
- x = skb->dst->xfrm;
skb->nh.raw = memmove(skb_push(skb, x->props.header_len), iph, ihl);
return 0;
}
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index 13cafbe..e23c21d 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -33,10 +33,9 @@ static inline void ipip_ecn_decapsulate(
* On exit, skb->h will be set to the start of the payload to be processed
* by x->type->output and skb->nh will be set to the top IP header.
*/
-static int xfrm4_tunnel_output(struct sk_buff *skb)
+static int xfrm4_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
- struct xfrm_state *x = dst->xfrm;
struct iphdr *iph, *top_iph;
int flags;
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 5fd115f..04403fb 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -66,7 +66,7 @@ static int xfrm4_output_one(struct sk_bu
if (err)
goto error;
- err = x->mode->output(skb);
+ err = x->mode->output(x, skb);
if (err)
goto error;
diff --git a/net/ipv6/xfrm6_mode_ro.c b/net/ipv6/xfrm6_mode_ro.c
index c11c335..6031c16 100644
--- a/net/ipv6/xfrm6_mode_ro.c
+++ b/net/ipv6/xfrm6_mode_ro.c
@@ -43,9 +43,8 @@ #include
* its absence, that of the top IP header. The value of skb->data will always
* point to the top IP header.
*/
-static int xfrm6_ro_output(struct sk_buff *skb)
+static int xfrm6_ro_output(struct xfrm_state *x, struct sk_buff *skb)
{
- struct xfrm_state *x = skb->dst->xfrm;
struct ipv6hdr *iph;
u8 *prevhdr;
int hdr_len;
diff --git a/net/ipv6/xfrm6_mode_transport.c b/net/ipv6/xfrm6_mode_transport.c
index a5dce21..3a4b39b 100644
--- a/net/ipv6/xfrm6_mode_transport.c
+++ b/net/ipv6/xfrm6_mode_transport.c
@@ -25,9 +25,8 @@ #include
* its absence, that of the top IP header. The value of skb->data will always
* point to the top IP header.
*/
-static int xfrm6_transport_output(struct sk_buff *skb)
+static int xfrm6_transport_output(struct xfrm_state *x, struct sk_buff *skb)
{
- struct xfrm_state *x = skb->dst->xfrm;
struct ipv6hdr *iph;
u8 *prevhdr;
int hdr_len;
diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c
index 8af79be..5e7d8a7 100644
--- a/net/ipv6/xfrm6_mode_tunnel.c
+++ b/net/ipv6/xfrm6_mode_tunnel.c
@@ -37,10 +37,9 @@ static inline void ipip6_ecn_decapsulate
* its absence, that of the top IP header. The value of skb->data will always
* point to the top IP header.
*/
-static int xfrm6_tunnel_output(struct sk_buff *skb)
+static int xfrm6_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
- struct xfrm_state *x = dst->xfrm;
struct ipv6hdr *iph
Re: high latency with TCP connections
From: Alexey Kuznetsov <[EMAIL PROTECTED]> Date: Fri, 1 Sep 2006 03:29:23 +0400 > > 2) a way to take delayed ACKs into account for cwnd growth > > This part is OK now, right? This part of ABC is not on by default, and was broken until last week :-) Test in tcp_slow_start() used to be: tp->bytes_acked > 2*tp->mss_cache but now it is the correct: tp->bytes_acked >= 2*tp->mss_cache It allows to make two congestion window increases from one ACK, when noticing delayed ACK. Non-ABC code did not do this, but could figure this kind of thing out while scanning retransmit queue. > > 1) protection against ACK division > > But Linux never had this problem... Congestion window was increased > only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could > break this, but should not). Otherwise, this ACK just advanced snd_una > and nothing more. Ugh, I missed this. :-/ The TSO code is carefuly to only trim TSO skbs on proper boundaries, and this ensures proper setting of FLAG_DATA_ACKED too. So no problems here. > The only problem of kind "too-aggressive" with Linux was that we could > develop large cwnd sending small segments, and then switch to sending > mss-sized segments. It does not look scary, to be honest. :-) Agreed. > Linux had troubles with slow start even before ABC. Actually, > some of applications can suffer of the same syndrome even if ABC disabled. > With ABC it becomes TROUBLE, cwnd has no chances to develop at all. I've discussed that very issue here before, some time ago, with John Heffner. It was in response to a user reporting a similar 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, but that might have other problems. There is an assymetry between how we do congestion control on sending (packet counting) and our ACK policy on receive (packet sized based). > 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. - 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: NAPI: netif_rx_reschedule() ??
Hello!
> However I'm confused about a couple of things, and there are only two
> uses of netif_rx_reschedule() in the kernel, so I'm a little stuck.
First, do not believe to even single bit of code or docs about
netif_rx_reschedule(). It was used once in the first version of NAPI
for 3com driver (which did not go to mainstream) and was left to rot. :-)
> 1. What is the intent of the second, 'undo' parameter? For example,
>ibmveth.c does
>
> if(ibmveth_rxq_pending_buffer(adapter) && netif_rx_reschedule(netdev,
> frames_processed))
> {
> lpar_rc = h_vio_signal(adapter->vdev->unit_address,
> VIO_IRQ_DISABLE);
> ibmveth_assert(lpar_rc == H_SUCCESS);
> more_work = 1;
> goto restart_poll;
> }
>
>but it only does
>
> netdev->quota -= frames_processed;
>
>_after_ that block (and the jump back to restart_poll). So the
>whole things seems fishy: netdev->quota goes up by the number of
>frames processed??
It is broken. netdev->quota MUST not be touched after netif_rx_complete().
Authors improved coding style, moving it closer to update of *budget
and it is wrong. First, because it is changed in an absolutely unserialized
context, second... you noticed.
>It's not clear to me why the driver would want to do something
>different depending on whether the NAPI poll was already scheduled
>or not.
netif_rx_complete() released control. ->poll can be reentered on another
CPU after this.
If netif_rx_reschedule() fails, it means that ->poll must exit, because
poll was already rescheduled.
If it succeds, it means current thread got control back. Changes made
before netif_rx_complete(), becuase we were going to exit, (netdev->quota etc)
are undone and loop can be restarted.
To be honest, I do not recollect everything. F.e. scheduling softirq
in netif_rx_reschedule() looks like a cut-n-paste bug.
Alexey
-
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: LRO fix needed
On Thu, Aug 31, 2006 at 04:42:27PM -0700, David Miller wrote:
>
> So could you please make the S2io driver LRO path
> set skb_shared_info(skb)->gso_size appropriately?
> Probably the easiest is to use the length of the
> first frag of a multiple frag LRO sequence.
It might be better to set it to the biggest frag you see rather
than the first.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[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
LRO fix needed
Ananda, Herbert Xu recently found a problem in the TCP stack input path for LRO capable receive paths. The issue is that the receive MSS estimator in tcp_measure_rcv_mss() uses skb->len for the MSS estimation. This is wrong for LRO frames. Herbert noticed this using Xen which pused TSO frames on output back into the destination TCP stack on input so it looks exactly like LRO. His fix to tcp_measure_rcv_mss() is to use skb_shared_info(skb)->gso_size if it is non-zero, else skb->len, in the assignment to "len". So could you please make the S2io driver LRO path set skb_shared_info(skb)->gso_size appropriately? Probably the easiest is to use the length of the first frag of a multiple frag LRO sequence. Also, could we have a linux/MAINTAINERS entry added for the S2io driver? Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Enable/Disable VLAN HW filters
Mitch Williams wrote:
We've had a few internal requests for a way to enable and disable the
hardware VLAN filter at runtime. I'm posting it here for discussion and
to see if anybody else is interested in this feature.
Originally I had planned to do this as an Ethtool ioctl, but decided
instead to handle it through the VLAN module. Ethtool doesn't know
anything about VLANs at all.
There are no userspace changes required to support this functionality.
To disable HW VLAN filtering:
# vconfig set_flag 2 1
To enable HW VLAN filtering:
# vconfig set_flag 2 0
At this point (somewhat obviously), it's only implemented on e1000, but
this ioctl could be easily implemented by other drivers.
Sounds like a good idea to me.
+ switch (flag) {
+ case VLAN_FLAG_REORDER:
+ if (flag_val)
+ VLAN_DEV_INFO(dev)->flags |= 1;
+ else
+ VLAN_DEV_INFO(dev)->flags &= ~1;
+ break;
If we're defining constants for the flags, might as well use them here
instead of using the bare '1'.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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
Hello! > 2) a way to take delayed ACKs into account for cwnd growth This part is OK now, right? > 1) protection against ACK division But Linux never had this problem... Congestion window was increased only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could break this, but should not). Otherwise, this ACK just advanced snd_una and nothing more. This aspect of ABC is crucial for BSD. TCP_NODELAY sockets did not obey congestion control there. From the very beginning, before slow start it can send thousands of 1 byte segments. The only problem of kind "too-aggressive" with Linux was that we could develop large cwnd sending small segments, and then switch to sending mss-sized segments. It does not look scary, to be honest. :-) Linux had troubles with slow start even before ABC. Actually, some of applications can suffer of the same syndrome even if ABC disabled. With ABC it becomes TROUBLE, cwnd has no chances to develop at all. Probably, aspect 1 of ABC just should be disabled. And the first my suggestion looks working too. Alexey - 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] Wake-on-LAN flex filters
Most modern Ethernet hardware supports flexible filters for wake-on-LAN,
probably because it's a requirement for certification with Another
Operating System.
This patch implements this feature on e1000 via Ethtool. The kernel
portion of this code is fairly well polished, but the changes to the
tool are extremely hacky and ugly. Don't bother to comment on that
portion; if people want this feature either Jeff or I will redo it
correctly.
To create a filter:
# ethtool -F
where can be from 0 - 3 (at least for e1000), and where
filter is a string of hex digits describing what the filtered frame
should look like. Each byte MUST be represented by two hex digits, and
no whitespace is allowed. If a particular byte should be ignored by the
filter, represent it with "xx".
For example:
# ethtool -F eth0 1 0011223344567890xx
To show a filter:
# ethtool -f
To enable WOL filters (after setting one):
# ethtool -s wol f
Please review and comment, and thanks.
Kernel patch is inline, ethtool patch is attached.
-Mitch
diff -urpN -X linux-2.6.18-rc4/Documentation/dontdiff
linux-2.6.18-rc4-clean/include/linux/ethtool.h
linux-2.6.18-rc4/include/linux/ethtool.h
--- linux-2.6.18-rc4-clean/include/linux/ethtool.h 2006-08-21
13:28:47.0 -0700
+++ linux-2.6.18-rc4/include/linux/ethtool.h2006-08-21 13:48:59.0
-0700
@@ -53,6 +53,17 @@ struct ethtool_wolinfo {
__u32 supported;
__u32 wolopts;
__u8sopass[SOPASS_MAX]; /* SecureOn(tm) password */
+ __u32 n_filters;
+};
+
+#define WOL_FILTER_MAX 256
+#define WOL_FILTER_IGNORE 0x100
+/* wake-on-lan flexible filters */
+struct ethtool_wol_filter {
+ __u32 cmd;
+ __u32 index;
+ __u32 len;
+ __u16 mask_val[0];
};
/* for passing single values */
@@ -372,6 +383,8 @@ struct ethtool_ops {
void(*complete)(struct net_device *);
u32 (*get_ufo)(struct net_device *);
int (*set_ufo)(struct net_device *, u32);
+ int (*get_wol_filter)(struct net_device *, struct
ethtool_wol_filter *, u16 *);
+ int (*set_wol_filter)(struct net_device *, struct
ethtool_wol_filter *, u16 *);
};
#endif /* __KERNEL__ */
@@ -413,6 +426,8 @@ struct ethtool_ops {
#define ETHTOOL_SUFO 0x0022 /* Set UFO enable (ethtool_value) */
#define ETHTOOL_GGSO 0x0023 /* Get GSO enable (ethtool_value) */
#define ETHTOOL_SGSO 0x0024 /* Set GSO enable (ethtool_value) */
+#define ETHTOOL_GWOLFILTER 0x0025 /* Get WOL flex filter */
+#define ETHTOOL_SWOLFILTER 0x0026 /* Set WOL flex filter */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
@@ -497,5 +512,6 @@ struct ethtool_ops {
#define WAKE_ARP (1 << 4)
#define WAKE_MAGIC (1 << 5)
#define WAKE_MAGICSECURE (1 << 6) /* only meaningful if WAKE_MAGIC */
+#define WAKE_FILTER(1 << 7)
#endif /* _LINUX_ETHTOOL_H */
diff -urpN -X linux-2.6.18-rc4/Documentation/dontdiff
linux-2.6.18-rc4-clean/net/core/ethtool.c linux-2.6.18-rc4/net/core/ethtool.c
--- linux-2.6.18-rc4-clean/net/core/ethtool.c 2006-08-21 13:28:48.0
-0700
+++ linux-2.6.18-rc4/net/core/ethtool.c 2006-08-21 13:59:14.0 -0700
@@ -229,6 +229,63 @@ static int ethtool_set_wol(struct net_de
return dev->ethtool_ops->set_wol(dev, &wol);
}
+static int ethtool_get_wol_filter(struct net_device *dev, char __user
*useraddr)
+{
+ struct ethtool_wol_filter wolfilt = { ETHTOOL_GWOLFILTER };
+ u16 *data;
+
+ if (!dev->ethtool_ops->get_wol_filter)
+ return -EOPNOTSUPP;
+
+ data = kmalloc(WOL_FILTER_MAX*2, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ if (copy_from_user(&wolfilt, useraddr, sizeof(wolfilt)))
+ return -EFAULT;
+
+ dev->ethtool_ops->get_wol_filter(dev, &wolfilt, data);
+
+ if (copy_to_user(useraddr, &wolfilt, sizeof(wolfilt)))
+ return -EFAULT;
+ if (copy_to_user(useraddr + sizeof(wolfilt), data, wolfilt.len*2))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int ethtool_set_wol_filter(struct net_device *dev, char __user
*useraddr)
+{
+ struct ethtool_wol_filter wolfilt;
+ u16 *data;
+ int ret;
+
+ if (!dev->ethtool_ops->get_wol_filter)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&wolfilt, useraddr, sizeof(wolfilt)))
+ return -EFAULT;
+
+ if (wolfilt.len > WOL_FILTER_MAX)
+ return -EOPNOTSUPP;
+
+ if (wolfilt.len) {
+ data = kmalloc(wolfilt.len*2, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+ }
+
+ ret = -EFAULT;
+ if (copy_from_user(data, useraddr + sizeof(wolfilt), wolfilt.len*2))
+ goto out;
+
+ ret = dev->ethtool_ops->set_wol_filter(dev, &wolfilt, data);
+ out:
Re: RTL8136
I demand that Francois Romieu may or may not have written...
> Darren Salt <[EMAIL PROTECTED]> :
> [...]
>> The former. Without that, the connection is persistently re-negotiated
>> (though, according to the switch's LEDs, it's fine before the module is
>> loaded).
> The state of the LEDs at startup is not necessarily significant (it can
> come from the eeprom).
I'm inclined to believe the switch...
> I have regenerated a serie which includes a fix with the correct RTL_CFG_2
> at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/r8169 (the git
> branch has been updated as well).
Got it.
> Could you use it with mii-tool to collect the state of the mii registers in
> the broken state and in the working state ?
Broken:
eth0: no link
registers for MII PHY 32:
1000 7849 8201 0de1
05c0 000f
0080
product info: vendor 00:00:20, model 32 rev 1
basic mode: autonegotiation enabled
basic status: no link
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
eth0: no link
registers for MII PHY 32:
3100 7849 8201 0de1 45e0 0001
000c 05c0 007a 000f
00f8
product info: vendor 00:00:20, model 32 rev 1
basic mode: autonegotiation enabled
basic status: no link
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Working (after "mii-tool -A 10baseT eth0"):
eth0: negotiated 10baseT-FD, link ok
registers for MII PHY 32:
1100 786d 8201 0061 45e1 0001
000c 05c0 000f
0086
product info: vendor 00:00:20, model 32 rev 1
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Working (after "mii-tool -R eth0", needed to allow 100baseTx):
eth0: negotiated 100baseTx-FD, link ok
registers for MII PHY 32:
3100 786d 8201 01e1 45e1 0001
000c 05c0 0002
00f9
product info: vendor 00:00:20, model 32 rev 1
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
--
| Darren Salt| linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| Say NO to UK ID cards. http://www.no2id.net/
Windows 2000. Known to some as Windows 1900.
-
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] Enable/Disable VLAN HW filters
We've had a few internal requests for a way to enable and disable the
hardware VLAN filter at runtime. I'm posting it here for discussion and
to see if anybody else is interested in this feature.
Originally I had planned to do this as an Ethtool ioctl, but decided
instead to handle it through the VLAN module. Ethtool doesn't know
anything about VLANs at all.
There are no userspace changes required to support this functionality.
To disable HW VLAN filtering:
# vconfig set_flag 2 1
To enable HW VLAN filtering:
# vconfig set_flag 2 0
At this point (somewhat obviously), it's only implemented on e1000, but
this ioctl could be easily implemented by other drivers.
Originally based on 2.6.17 but applies OK to 2.6.18-rc4 with a little
fuzz.
diff -urpN -X linux-2.6.17/Documentation/dontdiff
linux-2.6.17-clean/include/linux/if_vlan.h linux-2.6.17/include/linux/if_vlan.h
--- linux-2.6.17-clean/include/linux/if_vlan.h 2006-06-17 18:49:35.0
-0700
+++ linux-2.6.17/include/linux/if_vlan.h2006-07-13 15:37:41.0
-0700
@@ -87,7 +87,20 @@ struct vlan_priority_tci_mapping {
*/
struct vlan_priority_tci_mapping *next;
};
-
+#define VLAN_FLAG_REORDER 1/* (1 << 0) re_order_header This
option will cause the
+* VLAN code to move around the
ethernet header on
+* ingress to make the skb look
**exactly** like it
+* came in from an ethernet port.
This destroys some of
+* the VLAN information in the skb,
but it fixes programs
+* like DHCP that use
packet-filtering and don't understand
+* 802.1Q
+*/
+
+#define VLAN_FLAG_DISABLE_FILTER 2 /* (1 << 1) disable HW filtering. This
flag allows
+* devices that perform hardware
filtering to
+* turn off filtering. This may be
useful for
+* debugging or for sniffer
applications.
+*/
/* Holds information that makes sense if this device is a VLAN device. */
struct vlan_dev_info {
/** This will be the mapping that correlates skb->priority to
@@ -97,14 +110,7 @@ struct vlan_dev_info {
struct vlan_priority_tci_mapping *egress_priority_map[16]; /* hash
table */
unsigned short vlan_id;/* The VLAN Identifier for this
interface. */
- unsigned short flags; /* (1 << 0) re_order_header This
option will cause the
-* VLAN code to move around the
ethernet header on
-* ingress to make the skb look
**exactly** like it
-* came in from an ethernet port.
This destroys some of
-* the VLAN information in the skb,
but it fixes programs
-* like DHCP that use
packet-filtering and don't understand
-* 802.1Q
-*/
+ unsigned short flags;
struct dev_mc_list *old_mc_list; /* old multi-cast list for the VLAN
interface..
* we save this so we can tell what
changes were
* made, in order to feed the right
changes down
diff -urpN -X linux-2.6.17/Documentation/dontdiff
linux-2.6.17-clean/include/linux/netdevice.h
linux-2.6.17/include/linux/netdevice.h
--- linux-2.6.17-clean/include/linux/netdevice.h2006-06-17
18:49:35.0 -0700
+++ linux-2.6.17/include/linux/netdevice.h 2006-07-17 16:53:26.0
-0700
@@ -484,7 +484,9 @@ struct net_device
unsigned short vid);
void(*vlan_rx_kill_vid)(struct net_device *dev,
unsigned short vid);
-
+#define HAVE_VLAN_FLAGS
+ int (*vlan_set_flag)(struct net_device *dev,
+ unsigned int flag, int value);
int (*hard_header_parse)(struct sk_buff *skb,
unsigned char *haddr);
int (*neigh_setup)(struct net_device *dev, struct
neigh_parms *);
diff -urpN -X linux-2.6.17/Documentation/dontdiff
linux-2.6.17-clean/net/8021q/vlan_dev.c linux-2.6.17/net/8021q/vlan_dev.c
--- linux-2.6.17-clean/net/8021q/vlan_dev.c 2006-06-17 18:49:35.0
-0700
+++ linux-2.6.17/net/8021q/vlan_dev.c 2006-07-19 10:53:36.0 -0700
@@ -590,37 +590,58 @@ int vlan_dev_set_egress_priori
Re: high latency with TCP connections
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 15:14:56 -0700 > On Fri, 1 Sep 2006 01:46:35 +0400 > Alexey Kuznetsov <[EMAIL PROTECTED]> wrote: > > > > Expecting any performance with one byte write's is silly. > > > > I am not sure why you are so confident about status of ABC. > > I missed the discussions, when it was implemented. Apparently, > > it was noticed that ABC in its pure form does not make sense > > with snd_cwnd counted in packets and there were some reasons, > > why it still was not adapted. > > I implemented it but don't think ABC is the correct thing to be doing > in all cases. > > If you read the RFC3465, the problem it is trying to address is that of > small packets causing growth of congestion window beyond the capacity > of the link. > > It makes a number of assumptions that may not be true for Linux: > * ABC doesn't take into account congestion window validation RFC2861 > already prevents most of the problem of inflated growth. > * ABC assumes that the "true" capacity of the link is limited by > byte count not packet count. It seems to me that the thing gained by ABC are twofold: 1) protection against ACK division 2) a way to take delayed ACKs into account for cwnd growth Both of which can be obtained by simply validating the ACK against the retransmit queue, returning number of true packets ACK'd. I would even go so far as to suggest that we should drop ACKs which do not fall on packetization boundaries. Perhaps only when not in LOSS state, but I doubt that this matters in practice. Cases where mid-packet ACK is valid are truly marginal ones involving repacketization wrt. MSS/MTU changes, and these would self-correct eventually. I agree that ABC has some problems. Solution is good, implementation is just horrible :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix sk->sk_filter field access
From: Dmitry Mishin <[EMAIL PROTECTED]>
Date: Wed, 30 Aug 2006 17:07:14 +0400
> Function sk_filter() is called from tcp_v{4,6}_rcv() functions with argue
> needlock = 0, while socket is not locked at that moment. In order to avoid
> this and similar issues in the future, use rcu for sk->sk_filter field read
> protection.
>
> Patch is for net-2.6.19
>
> Signed-off-by: Dmitry Mishin <[EMAIL PROTECTED]>
> Signed-off-by: Alexey Kuznetsov <[EMAIL PROTECTED]>
> Signed-off-by: Kirill Korotaev <[EMAIL PROTECTED]>
Dmitry, your email client chopped up the longer lines in the patch
such as:
> -static inline int sk_filter(struct sock *sk, struct sk_buff *skb, int
> needlock)
> +static inline int sk_filter(struct sock *sk, struct sk_buff *skb)
Here.
> -static inline unsigned run_filter(struct sk_buff *skb, struct sock *sk,
> unsigned res)
> +static inline int run_filter(struct sk_buff *skb, struct sock *sk,
And there.
But I fixed these up and applied the patch to net-2.6.19
I think we seriously need to think about fixing this bug,
in so me form, for 2.6.18
-
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: SNMPv2 "ipFragFails" counter error
From: weidong <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 10:39:35 -0400
> Hi, All
> When I tested Linux kernel 2.6.17.7 about statistics
> "ipFragFails",found that this counter couldn't increase correctly. The
> criteria is RFC2011:
> RFC2011
> ipFragFails OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of IP datagrams that have been discarded because
> they needed to be fragmented at this entity but could not
> be, e.g., because their Don't Fragment flag was set."
> ::= { ip 18 }
>
> When I send big IP packet to a router with DF bit set to 1 which need to
> be fragmented, and router just sends an ICMP error message
> ICMP_FRAG_NEEDED but no increments for this counter(in the function
> ip_fragment).
>
> signed-off-by:Wei Dong <[EMAIL PROTECTED]>
Patch applied, thank you very much.
-
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] rate limiting for socket allocation failure messages
From: Akinobu Mita <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 18:59:21 +0900 > (Resending due to local mail server trouble) > > This patch limits the warning messages when socket allocation > failures happen. It happens under memory pressure. > > Cc: David Miller <[EMAIL PROTECTED]> > Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]> Patch 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: [IPV6] MIP6: Fix to update IP6CB when cloned skbuff is received at HAO.
From: Masahide NAKAMURA <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 21:05:41 +0900 > > From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > > Date: Thu, 24 Aug 2006 00:02:24 +0900 > > > > > In receiving Mobile IPv6 home address option which is a TLV carried > > > by destination options header, kernel will try to mangle source adderss > > > of packet. Think of cloned skbuff it is required to replace it by > > > the parser just like routing header case. > > > This is a framework to achieve that to allow TLV parser to replace > > > inbound skbuff pointer. > > > > > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> > > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > > > > Applied to net-2.6.19, thanks a lot. > > > > I've found issue about the patch above. > This is a fix for it, to update IP6CB when cloned skbuff is received at HAO. > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> Patch applied, thank you very much. - 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, 1 Sep 2006 01:46:35 +0400
Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Expecting any performance with one byte write's is silly.
>
> I am not sure why you are so confident about status of ABC.
> I missed the discussions, when it was implemented. Apparently,
> it was noticed that ABC in its pure form does not make sense
> with snd_cwnd counted in packets and there were some reasons,
> why it still was not adapted.
I implemented it but don't think ABC is the correct thing to be doing
in all cases.
If you read the RFC3465, the problem it is trying to address is that of
small packets causing growth of congestion window beyond the capacity
of the link.
It makes a number of assumptions that may not be true for Linux:
* ABC doesn't take into account congestion window validation RFC2861
already prevents most of the problem of inflated growth.
* ABC assumes that the "true" capacity of the link is limited by
byte count not packet count.
> That's what I am sure: if congestion control causes delack syndrome,
> it is difficult to advocate this congestion control scheme.
> It must be repaired, if there is even the smallest possibility
> to do this.
>
>
> The first idea:
>
> Behaviour is broken, when we have < 2*MSS in flight. In that
> case receiver falls to delack timeout and breaks ACK clock.
>
> thresh = tp->mss_cache;
>
> if (tp->snd_nxt - tp->snd_una <= tp->mss_cache) {
> thresh = 1;
> if (tp->send_head)
> thresh = tp->send_head->len;
> /* If send_head is empty, it disables ABC.
>* If send_head is good mss sized segment, ABC is in work.
>* If send_head is a small segment, it is half-way.
>*/
> }
>
> if (tp->bytes_acked < thresh)
> return;
>
> Probably, do this only when TCP_NODELAY is set, but actually it does not
> matter. If it is nagled/corked, cwnd will not be used/increased in any case.
Maybe it makes better sense to add a bonus to bytes_acked on each ack to
try and make small packets get an increase sooner, and try and make the
cwnd * mss_cache estimate be more accurate. In the ideal case, during
slow start with small packets cwnd should increase at the same rate
that it would with larger packets.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM] STATE: Fix flusing with hash mask.
From: Masahide NAKAMURA <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 21:00:17 +0900 > This is a minor fix about transformation state flushing > for net-2.6.19. Please apply it. Thank you for finding this bug. Patch applied. Masahide-san, please provide a Signed-off-by: line in the future, even for simple changes like this one. Arigato. - 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]: Fix rcv mss estimate for LRO
From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 23:18:33 +1000 > The Xen performance problem turned out to be something else altogether. > It was an incorrect rcv mss estimate which leads to delayed acks. So > it's not a bug in Linux yet :) However, since we need this for LRO as > well, here's a patch for net-2.6.19. Good spotting. > [TCP]: Fix rcv mss estimate for LRO > > By passing a Linux-generated TSO packet straight back into Linux, Xen > becomes our first LRO user :) Unfortunately, there is at least one spot > in our stack that needs to be changed to cope with this. > > The receive MSS estimate is computed from the raw packet size. This is > broken if the packet is GSO/LRO. Fortunately the real MSS can be found > in gso_size so we simply need to use that if it is non-zero. > > Real LRO NICs should of course set the gso_size field in future. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ok, I'll put this into net-2.6.19, but I think it deserves serious consideration for 2.6.18 because the S2IO driver does implement HW LRO and it is almost certainly getting bitten by this issue since I do not see that driver setting gso_size, and perhaps the current S2io firmware implementing this cannot provide the MSS value needed. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Fix typo causing wrong skb to be freed
From: Thomas Graf <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 23:26:51 +0200 > A typo introduced by myself which leads to freeing the skb > containing the netlink message when it should free the newly > allocated skb for the reply. > > Signed-off-by: Thomas Graf <[EMAIL PROTECTED]> Applied, thanks Thomas. - 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 somaxconn sysctl to __read_mostly
From: Brian Haley <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 16:35:33 -0400 > Change sysctl_somaxconn to __read_mostly. > > Signed-off-by: Brian Haley <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] change max_dgram_qlen sysctl to __read_mostly
From: Brian Haley <[EMAIL PROTECTED]> Date: Thu, 31 Aug 2006 16:35:37 -0400 > Change AF_UNIX sysctl_unix_max_dgram_qlen to __read_mostly. > > Signed-off-by: Brian Haley <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAPI: netif_rx_reschedule() ??
On Thu, 2006-31-08 at 14:29 -0700, Stephen Hemminger wrote: > On Wed, 30 Aug 2006 16:39:14 -0700 > Roland Dreier <[EMAIL PROTECTED]> wrote: > > > Roland> makes sense -- especially since the caller probably also > > Roland> deducted N from *budget, and netif_rx_reschedule() doesn't > > Roland> touch that. > > > > Actually, why does undoing the change to quota make sense? Presumably > > I passed N packets to netif_receive_skb() -- why shouldn't I deduct N > > from quota and *budget? > > > > - R. > > This was probably a preventive thing to avoid scheduling when quota remaining > was zero? I am reading backwards, so i may be incoherent ;-> I suppose if you dont trust the driver to tell you the truth it could be done in the core code such as netif_receive_skb(). Should be noted however, your quota does get refilled by the NAPI core governed by DRR scheduling rules. 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: [PATCH 00/26] e100, e1000, ixgb updates
pulled into #upstream, thanks - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high latency with TCP connections
Hello!
> Expecting any performance with one byte write's is silly.
I am not sure why you are so confident about status of ABC.
I missed the discussions, when it was implemented. Apparently,
it was noticed that ABC in its pure form does not make sense
with snd_cwnd counted in packets and there were some reasons,
why it still was not adapted.
That's what I am sure: if congestion control causes delack syndrome,
it is difficult to advocate this congestion control scheme.
It must be repaired, if there is even the smallest possibility
to do this.
The first idea:
Behaviour is broken, when we have < 2*MSS in flight. In that
case receiver falls to delack timeout and breaks ACK clock.
thresh = tp->mss_cache;
if (tp->snd_nxt - tp->snd_una <= tp->mss_cache) {
thresh = 1;
if (tp->send_head)
thresh = tp->send_head->len;
/* If send_head is empty, it disables ABC.
* If send_head is good mss sized segment, ABC is in work.
* If send_head is a small segment, it is half-way.
*/
}
if (tp->bytes_acked < thresh)
return;
Probably, do this only when TCP_NODELAY is set, but actually it does not
matter. If it is nagled/corked, cwnd will not be used/increased in any case.
-
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
Useful stuff. There are things along these lines that i have been contemplating myself. I think it would be valuable to specify a set of flags for filtering what gets sent to user space instead of unconditionally. Example, filter level 0: - what we have before your patch filter level 1: - protocol version - header size - maximum number of attributes filter level 2: - the rest of the stuff you have What netlink does today to filter at user space is something that can be avoided with the above (an improvement in my opinion if you have a lot of genl items in the kernel). cheers, jamal On Thu, 2006-31-08 at 23:21 +0200, Thomas Graf wrote: > Additionaly exports the following information when providing > the list of registered generic netlink families: > - protocol version > - header size > - maximum number of attributes > > - list of available operations including > - id > - flags > - avaiability of policy and doit/dumpit function > > libnl HEAD provides a utility to read this new information: > > 0x0010 nlctrl version 1 > hdrsize 0 maxattr 6 > op GETFAMILY (0x03) [POLICY,DOIT,DUMPIT] > 0x0011 NLBL_MGMT version 1 > hdrsize 0 maxattr 0 > op unknown (0x02) [DOIT] > op unknown (0x03) [DOIT] > > - 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: NAPI: netif_rx_reschedule() ??
On Wed, 30 Aug 2006 16:39:14 -0700 Roland Dreier <[EMAIL PROTECTED]> wrote: > Roland> makes sense -- especially since the caller probably also > Roland> deducted N from *budget, and netif_rx_reschedule() doesn't > Roland> touch that. > > Actually, why does undoing the change to quota make sense? Presumably > I passed N packets to netif_receive_skb() -- why shouldn't I deduct N > from quota and *budget? > > - R. This was probably a preventive thing to avoid scheduling when quota remaining was zero? -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] 8139cp: misc minor changes
Ehm... why am I included in this? :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] e100, e1000, ixgb updates
Jeff, I have adjusted several things in our queue after comments. Here is a summary of those changes against the original summary. These changes are available through git. Please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream (against netdev-2.6#upstream 699a71238856b19091503c671bac8abb1e3f9a3a) Cheers, Auke Kok, Auke wrote: Vasily Averin <[EMAIL PROTECTED]> e1000: IRQ resources cleanup e1000: e1000_probe resources cleanup e1000: ring buffers resources cleanup Jesse Brandeburg <[EMAIL PROTECTED]> e1000: unify WoL capability detection code all unchanged e1000: Add PCI ID 0x10a4 for our new 4-port PCI-Express device This patch was not Acked but I assume no objections exist. ixgb: Set a constant blink rate for ixgb adapter identify (1sec on, 1sec off) unchanged ixgb: Cache-align all TX components of the adapter struct. modified per comments to include "_in_smp" ixgb: Add buffer_info and test like e1000 has. unchanged Christoph Hellwig <[EMAIL PROTECTED]> e1000: clean up skb allocation code, patch submitted by Christoph Changed topic as attribution is already in the patch correctly Jeff Kirsher <[EMAIL PROTECTED]> e1000: Deprecate mii-tool SIOCMIIREG ioctl Dropped patch. Auke Kok <[EMAIL PROTECTED]> e1000: Whitespace cleanup, cosmetic changes e1000: error out if we cannot enable PCI device on resume e1000: remove unused part_num reading code e1000: Use module param array code e1000: Increment driver version to 7.2.7-k2 e100: Convert e100 to use netdev_alloc_skb(). all unchanged e100: reduce time under spinlock Dropped patch. e100: remove skb->dev assignment e100: increment version to 3.5.16-k2 ixgb: Convert dev_alloc_skb to netdev_alloc_skb. ixgb: convert dev->priv to netdev_priv(dev). ixgb: recalculate after how many descriptors to wake the queue ixgb: remove skb->dev assignment ixgb: Increment version to 1.0.112-k2 Linas Vepstas <[EMAIL PROTECTED]> e100: fix error recovery ixgb: Add PCI Error recovery callbacks all unchanged Cheers, Auke --- drivers/net/e100.c|8 drivers/net/e1000/e1000.h |6 drivers/net/e1000/e1000_ethtool.c | 219 --- drivers/net/e1000/e1000_hw.c | 1059 ++--- drivers/net/e1000/e1000_hw.h | 26 drivers/net/e1000/e1000_main.c| 145 +++-- drivers/net/e1000/e1000_param.c | 161 +++-- drivers/net/ixgb/ixgb.h |5 drivers/net/ixgb/ixgb_ethtool.c |6 drivers/net/ixgb/ixgb_main.c | 140 - 10 files changed, 979 insertions(+), 796 deletions(-) - 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
[NET]: Fix typo causing wrong skb to be freed
A typo introduced by myself which leads to freeing the skb
containing the netlink message when it should free the newly
allocated skb for the reply.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/core/rtnetlink.c
===
--- net-2.6.19.orig/net/core/rtnetlink.c2006-08-30 13:14:48.0
+0200
+++ net-2.6.19/net/core/rtnetlink.c 2006-08-31 23:21:28.0 +0200
@@ -596,7 +596,7 @@
err = rtnl_fill_ifinfo(nskb, dev, iw, iw_buf_len, RTM_NEWLINK,
NETLINK_CB(skb).pid, nlh->nlmsg_seq, 0, 0);
if (err <= 0) {
- kfree_skb(skb);
+ kfree_skb(nskb);
goto errout;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/26] e1000: Deprecate mii-tool SIOCMIIREG ioctl
Brandeburg, Jesse wrote: Jeff Garzik wrote: Kok, Auke wrote: Deprecate mii-tool SIOCMIIREG ioctl. This ioctl is broken in e1000 and ethtool has this functionality in working order. Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> This doesn't "deprecated" anything, it changes the ABI on a user's machine by _removing_ ioctl handling code that used to be there. What's broken, and what is needed to fix? Perhaps e1000 should instead be limited to 10/100 networks/speeds? mii-tool is broken because it doesn't understand GMII phys. We ended up having a mess of code trying to implement the shim layer to support the PHY write ioctls, among others. mii-tool always reports 100 Mbps link when you actually have 1Gbps link. Using mii-tool to set options didn't work very well to begin with, so rather than continue to dump time into a dead end, just remove the incomplete/non-working code and force the user to use ethtool if they want to do set operations. Mii-tool is already marked in its man page to be obsolete NOTE This program is obsolete. Valid media are only 100baseT4, 100baseTx-FD,100baseTx-HD, 10baseT-FD and 10baseT-HD ethernet cards. For replacement check eth-tool. We intentionally left the read code in to not break any user space programs that are using that IOCTL to read link status etc. With some recent improvements to ethtool, it has the exact same functionality as mii-tool. While I appreciate the "don't break user space" position, in this case it never really worked right, and when it did work the user was just lucky because they probably weren't getting what they wanted. I'm dropping this patch from our stack, it seems (irony) that we might have some use for this ioctl after all and we need to re-evaluate what to do with it. It doesn't hurt (much) to leave it in there for now. Jeff, I'll repost a summary of the changes I made to the queue on our gitserver in a second. Cheers, Auke - 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
[GENL]: Provide more information to userspace about registered genl families
Additionaly exports the following information when providing
the list of registered generic netlink families:
- protocol version
- header size
- maximum number of attributes
- list of available operations including
- id
- flags
- avaiability of policy and doit/dumpit function
libnl HEAD provides a utility to read this new information:
0x0010 nlctrl version 1
hdrsize 0 maxattr 6
op GETFAMILY (0x03) [POLICY,DOIT,DUMPIT]
0x0011 NLBL_MGMT version 1
hdrsize 0 maxattr 0
op unknown (0x02) [DOIT]
op unknown (0x03) [DOIT]
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/linux/genetlink.h
===
--- net-2.6.19.orig/include/linux/genetlink.h 2006-08-31 16:01:16.0
+0200
+++ net-2.6.19/include/linux/genetlink.h2006-08-31 19:24:43.0
+0200
@@ -16,6 +16,8 @@
#define GENL_HDRLENNLMSG_ALIGN(sizeof(struct genlmsghdr))
+#define GENL_ADMIN_PERM0x01
+
/*
* List of reserved static generic netlink identifiers:
*/
@@ -43,9 +45,25 @@
CTRL_ATTR_UNSPEC,
CTRL_ATTR_FAMILY_ID,
CTRL_ATTR_FAMILY_NAME,
+ CTRL_ATTR_VERSION,
+ CTRL_ATTR_HDRSIZE,
+ CTRL_ATTR_MAXATTR,
+ CTRL_ATTR_OPS,
__CTRL_ATTR_MAX,
};
#define CTRL_ATTR_MAX (__CTRL_ATTR_MAX - 1)
+enum {
+ CTRL_ATTR_OP_UNSPEC,
+ CTRL_ATTR_OP_ID,
+ CTRL_ATTR_OP_FLAGS,
+ CTRL_ATTR_OP_POLICY,
+ CTRL_ATTR_OP_DOIT,
+ CTRL_ATTR_OP_DUMPIT,
+ __CTRL_ATTR_OP_MAX,
+};
+
+#define CTRL_ATTR_OP_MAX (__CTRL_ATTR_OP_MAX - 1)
+
#endif /* __LINUX_GENERIC_NETLINK_H */
Index: net-2.6.19/net/netlink/genetlink.c
===
--- net-2.6.19.orig/net/netlink/genetlink.c 2006-08-31 16:21:39.0
+0200
+++ net-2.6.19/net/netlink/genetlink.c 2006-08-31 19:10:38.0 +0200
@@ -387,7 +387,10 @@
static int ctrl_fill_info(struct genl_family *family, u32 pid, u32 seq,
u32 flags, struct sk_buff *skb, u8 cmd)
{
+ struct nlattr *nla_ops;
+ struct genl_ops *ops;
void *hdr;
+ int idx = 1;
hdr = genlmsg_put(skb, pid, seq, GENL_ID_CTRL, 0, flags, cmd,
family->version);
@@ -396,6 +399,37 @@
NLA_PUT_STRING(skb, CTRL_ATTR_FAMILY_NAME, family->name);
NLA_PUT_U16(skb, CTRL_ATTR_FAMILY_ID, family->id);
+ NLA_PUT_U32(skb, CTRL_ATTR_VERSION, family->version);
+ NLA_PUT_U32(skb, CTRL_ATTR_HDRSIZE, family->hdrsize);
+ NLA_PUT_U32(skb, CTRL_ATTR_MAXATTR, family->maxattr);
+
+ nla_ops = nla_nest_start(skb, CTRL_ATTR_OPS);
+ if (nla_ops == NULL)
+ goto nla_put_failure;
+
+ list_for_each_entry(ops, &family->ops_list, ops_list) {
+ struct nlattr *nest;
+
+ nest = nla_nest_start(skb, idx++);
+ if (nest == NULL)
+ goto nla_put_failure;
+
+ NLA_PUT_U32(skb, CTRL_ATTR_OP_ID, ops->cmd);
+ NLA_PUT_U32(skb, CTRL_ATTR_OP_FLAGS, ops->flags);
+
+ if (ops->policy)
+ NLA_PUT_FLAG(skb, CTRL_ATTR_OP_POLICY);
+
+ if (ops->doit)
+ NLA_PUT_FLAG(skb, CTRL_ATTR_OP_DOIT);
+
+ if (ops->dumpit)
+ NLA_PUT_FLAG(skb, CTRL_ATTR_OP_DUMPIT);
+
+ nla_nest_end(skb, nest);
+ }
+
+ nla_nest_end(skb, nla_ops);
return genlmsg_end(skb, hdr);
@@ -411,6 +445,9 @@
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
+ if (chains_to_skip != 0)
+ genl_lock();
+
for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
if (i < chains_to_skip)
continue;
@@ -428,6 +465,9 @@
}
errout:
+ if (chains_to_skip != 0)
+ genl_unlock();
+
cb->args[0] = i;
cb->args[1] = n;
Index: net-2.6.19/include/net/genetlink.h
===
--- net-2.6.19.orig/include/net/genetlink.h 2006-08-31 19:24:15.0
+0200
+++ net-2.6.19/include/net/genetlink.h 2006-08-31 19:24:20.0 +0200
@@ -27,8 +27,6 @@
struct list_headfamily_list;/* private */
};
-#define GENL_ADMIN_PERM0x01
-
/**
* struct genl_info - receiving information
* @snd_seq: sending sequence number
-
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
The word performance in this list seems to always mean 'throughput'. It seems though that there could be some knob to tweak for those of us who don't care so much about throughput but care a great deal about latency. SCTP has been mentioned. There is also DCCP - http://www.read.cs.ucla.edu/dccp/ -- 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 - 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: RTL8136
Darren Salt <[EMAIL PROTECTED]> : [...] > The former. Without that, the connection is persistently re-negotiated > (though, according to the switch's LEDs, it's fine before the module is > loaded). The state of the LEDs at startup is not necessarily significant (it can come from the eeprom). I have regenerated a serie which includes a fix with the correct RTL_CFG_2 at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/r8169 (the git branch has been updated as well). Could you use it with mii-tool to collect the state of the mii registers in the broken state and in the working state ? -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] 8139cp: use PCI_DEVICE() to shorten the PCI device table
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
cccb20d3a9b7c6d4b6e1b52ee02814e6094aaa12
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index a123d28..bbdaa18 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -406,10 +406,8 @@ static int cp_set_eeprom(struct net_devi
struct ethtool_eeprom *eeprom, u8 *data);
static struct pci_device_id cp_pci_tbl[] = {
- { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, },
- { PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139), },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322), },
{ },
};
MODULE_DEVICE_TABLE(pci, cp_pci_tbl);
--
1.3.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 6/7] 8139cp: pci_get_drvdata(pdev) can not be NULL in suspend handler
1) pci_set_drvdata() is used in cp_{init/remove}_one to initialize/reset
driver_data to the relevant value (resp. net_device * and NULL).
2) each of the 3 relevant functions is issued under (device *)->sem:
2.1) pci_unregister_driver
-> driver_unregister
-> bus_remove_driver
-> driver_detach (takes (device *)->sem)
-> __device_release_driver(dev)
-> dev->bus-remove(dev) (== pci_device_remove)
-> drv->remove(pdev) (== cp_remove_one)
[...]
pci_dev->driver = NULL;
2.2) pci_register_driver
-> __pci_register_driver
-> driver_register
-> bus_add_driver
-> driver_attach
-> __driver_attach (takes (device *)->sem)
-> driver_probe_device(drv, dev)
-> dev->bus->probe(dev) (== pci_device_probe)
-> _pci_device_probe(drv, pci_dev)
-> pci_call_probe(drv, pci_dev, id)
-> drv->probe(dev, id) (== cp_init_one)
[...]
pci_dev->driver = drv;
2.3) suspend_device (takes (device *)->sem)
-> dev->bus->suspend(dev) (== pci_device_suspend)
checking for drv = pci_dev->driver != NULL
[...]
-> drv->suspend(pci_dev, state) (== cp_suspend)
dev->sem and the state of pci_dev->driver provide the expected result.
St Mary's day was a bit rainy here.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
7668a4945ba0e17a61e535a6c67aa64a319a03b4
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 94ab3c3..a123d28 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -2023,14 +2023,12 @@ static void cp_remove_one (struct pci_de
#ifdef CONFIG_PM
static int cp_suspend (struct pci_dev *pdev, pm_message_t state)
{
- struct net_device *dev;
- struct cp_private *cp;
+ struct net_device *dev = pci_get_drvdata(pdev);
+ struct cp_private *cp = netdev_priv(dev);
unsigned long flags;
- dev = pci_get_drvdata (pdev);
- cp = netdev_priv(dev);
-
- if (!dev || !netif_running (dev)) return 0;
+ if (!netif_running(dev))
+ return 0;
netif_device_detach (dev);
netif_stop_queue (dev);
--
1.3.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 3/7] 8139cp: ring_info removal for the receive path
The ring_info.len field is not used at all. cp_private.rx_skb is
turned into an array of sk_buff *.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
0ba894d420b845667e2981c2147af974a755fba2
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index ae9bb75..0725681 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -354,7 +354,7 @@ struct cp_private {
unsignedrx_tail cacheline_aligned;
struct cp_desc *rx_ring;
- struct ring_inforx_skb[CP_RX_RING_SIZE];
+ struct sk_buff *rx_skb[CP_RX_RING_SIZE];
unsignedrx_buf_sz;
unsignedtx_head cacheline_aligned;
@@ -541,7 +541,7 @@ rx_status_loop:
struct cp_desc *desc;
unsigned buflen;
- skb = cp->rx_skb[rx_tail].skb;
+ skb = cp->rx_skb[rx_tail];
BUG_ON(!skb);
desc = &cp->rx_ring[rx_tail];
@@ -596,7 +596,7 @@ rx_status_loop:
mapping = pci_map_single(cp->pdev, new_skb->data, buflen,
PCI_DMA_FROMDEVICE);
- cp->rx_skb[rx_tail].skb = new_skb;
+ cp->rx_skb[rx_tail] = new_skb;
cp_rx_skb(cp, skb, desc);
rx++;
@@ -1097,7 +1097,7 @@ static int cp_refill_rx (struct cp_priva
mapping = pci_map_single(cp->pdev, skb->data, cp->rx_buf_sz,
PCI_DMA_FROMDEVICE);
- cp->rx_skb[i].skb = skb;
+ cp->rx_skb[i] = skb;
cp->rx_ring[i].opts2 = 0;
cp->rx_ring[i].addr = cpu_to_le64(mapping);
@@ -1152,11 +1152,11 @@ static void cp_clean_rings (struct cp_pr
unsigned i;
for (i = 0; i < CP_RX_RING_SIZE; i++) {
- if (cp->rx_skb[i].skb) {
+ if (cp->rx_skb[i]) {
desc = cp->rx_ring + i;
pci_unmap_single(cp->pdev, le64_to_cpu(desc->addr),
cp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb(cp->rx_skb[i].skb);
+ dev_kfree_skb(cp->rx_skb[i]);
}
}
@@ -1176,7 +1176,7 @@ static void cp_clean_rings (struct cp_pr
memset(cp->rx_ring, 0, sizeof(struct cp_desc) * CP_RX_RING_SIZE);
memset(cp->tx_ring, 0, sizeof(struct cp_desc) * CP_TX_RING_SIZE);
- memset(&cp->rx_skb, 0, sizeof(struct ring_info) * CP_RX_RING_SIZE);
+ memset(cp->rx_skb, 0, sizeof(struct sk_buff *) * CP_RX_RING_SIZE);
memset(&cp->tx_skb, 0, sizeof(struct ring_info) * CP_TX_RING_SIZE);
}
--
1.3.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 2/7] 8139cp: remove gratuitous indirection
dev is an argument of the current function. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> --- drivers/net/8139cp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) c48e9399e895834f26dff9149de1930ba18a0d6c diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c index 8f5d779..ae9bb75 100644 --- a/drivers/net/8139cp.c +++ b/drivers/net/8139cp.c @@ -571,7 +571,7 @@ rx_status_loop: if (netif_msg_rx_status(cp)) printk(KERN_DEBUG "%s: rx slot %d status 0x%x len %d\n", - cp->dev->name, rx_tail, status, len); + dev->name, rx_tail, status, len); buflen = cp->rx_buf_sz + RX_OFFSET; new_skb = dev_alloc_skb (buflen); @@ -581,7 +581,7 @@ rx_status_loop: } skb_reserve(new_skb, RX_OFFSET); - new_skb->dev = cp->dev; + new_skb->dev = dev; pci_unmap_single(cp->pdev, mapping, buflen, PCI_DMA_FROMDEVICE); -- 1.3.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 4/7] 8139cp: sync the device private data with its r8169 counterpart
struct cp_private is reorganized to be more easily compared between the
r8169 and the 8139cp drivers.
The alignment should not be impacted.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
d03d376dd29cae53bf70a21a0c26b306abe37326
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 0725681..9aef517 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -352,23 +352,23 @@ struct cp_private {
struct net_device_stats net_stats;
struct cp_extra_stats cp_stats;
- unsignedrx_tail cacheline_aligned;
+ unsignedrx_head cacheline_aligned;
+ unsignedrx_tail;
struct cp_desc *rx_ring;
struct sk_buff *rx_skb[CP_RX_RING_SIZE];
- unsignedrx_buf_sz;
unsignedtx_head cacheline_aligned;
unsignedtx_tail;
-
struct cp_desc *tx_ring;
struct ring_infotx_skb[CP_TX_RING_SIZE];
- dma_addr_t ring_dma;
+
+ unsignedrx_buf_sz;
+ unsignedwol_enabled : 1; /* Is Wake-on-LAN enabled? */
#if CP_VLAN_TAG_USED
struct vlan_group *vlgrp;
#endif
-
- unsigned intwol_enabled : 1; /* Is Wake-on-LAN enabled? */
+ dma_addr_t ring_dma;
struct mii_if_info mii_if;
};
--
1.3.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 1/7] 8139cp: trim ring_info
Fat removal: the mapping address is available from the Rx/Tx descriptors.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c | 33 -
1 files changed, 16 insertions(+), 17 deletions(-)
3598b57be449a2ee9178e5c511bdb1a8aaccba20
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 1428bb7..8f5d779 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -316,7 +316,6 @@ struct cp_desc {
struct ring_info {
struct sk_buff *skb;
- dma_addr_t mapping;
u32 len;
};
@@ -551,7 +550,7 @@ rx_status_loop:
break;
len = (status & 0x1fff) - 4;
- mapping = cp->rx_skb[rx_tail].mapping;
+ mapping = le64_to_cpu(desc->addr);
if ((status & (FirstFrag | LastFrag)) != (FirstFrag |
LastFrag)) {
/* we don't support incoming fragmented frames.
@@ -595,10 +594,8 @@ rx_status_loop:
skb_put(skb, len);
- mapping =
- cp->rx_skb[rx_tail].mapping =
- pci_map_single(cp->pdev, new_skb->data,
- buflen, PCI_DMA_FROMDEVICE);
+ mapping = pci_map_single(cp->pdev, new_skb->data, buflen,
+PCI_DMA_FROMDEVICE);
cp->rx_skb[rx_tail].skb = new_skb;
cp_rx_skb(cp, skb, desc);
@@ -717,18 +714,19 @@ static void cp_tx (struct cp_private *cp
unsigned tx_tail = cp->tx_tail;
while (tx_tail != tx_head) {
+ struct cp_desc *txd = cp->tx_ring + tx_tail;
struct sk_buff *skb;
u32 status;
rmb();
- status = le32_to_cpu(cp->tx_ring[tx_tail].opts1);
+ status = le32_to_cpu(txd->opts1);
if (status & DescOwn)
break;
skb = cp->tx_skb[tx_tail].skb;
BUG_ON(!skb);
- pci_unmap_single(cp->pdev, cp->tx_skb[tx_tail].mapping,
+ pci_unmap_single(cp->pdev, le64_to_cpu(txd->addr),
cp->tx_skb[tx_tail].len, PCI_DMA_TODEVICE);
if (status & LastFrag) {
@@ -827,7 +825,6 @@ #endif
wmb();
cp->tx_skb[entry].skb = skb;
- cp->tx_skb[entry].mapping = mapping;
cp->tx_skb[entry].len = len;
entry = NEXT_TX(entry);
} else {
@@ -845,7 +842,6 @@ #endif
first_mapping = pci_map_single(cp->pdev, skb->data,
first_len, PCI_DMA_TODEVICE);
cp->tx_skb[entry].skb = skb;
- cp->tx_skb[entry].mapping = first_mapping;
cp->tx_skb[entry].len = first_len;
entry = NEXT_TX(entry);
@@ -888,7 +884,6 @@ #endif
wmb();
cp->tx_skb[entry].skb = skb;
- cp->tx_skb[entry].mapping = mapping;
cp->tx_skb[entry].len = len;
entry = NEXT_TX(entry);
}
@@ -1091,6 +1086,7 @@ static int cp_refill_rx (struct cp_priva
for (i = 0; i < CP_RX_RING_SIZE; i++) {
struct sk_buff *skb;
+ dma_addr_t mapping;
skb = dev_alloc_skb(cp->rx_buf_sz + RX_OFFSET);
if (!skb)
@@ -1099,12 +1095,12 @@ static int cp_refill_rx (struct cp_priva
skb->dev = cp->dev;
skb_reserve(skb, RX_OFFSET);
- cp->rx_skb[i].mapping = pci_map_single(cp->pdev,
- skb->data, cp->rx_buf_sz, PCI_DMA_FROMDEVICE);
+ mapping = pci_map_single(cp->pdev, skb->data, cp->rx_buf_sz,
+PCI_DMA_FROMDEVICE);
cp->rx_skb[i].skb = skb;
cp->rx_ring[i].opts2 = 0;
- cp->rx_ring[i].addr = cpu_to_le64(cp->rx_skb[i].mapping);
+ cp->rx_ring[i].addr = cpu_to_le64(mapping);
if (i == (CP_RX_RING_SIZE - 1))
cp->rx_ring[i].opts1 =
cpu_to_le32(DescOwn | RingEnd | cp->rx_buf_sz);
@@ -1152,11 +1148,13 @@ static int cp_alloc_rings (struct cp_pri
static void cp_clean_rings (struct cp_private *cp)
{
+ struct cp_desc *desc;
unsigned i;
for (i = 0; i < CP_RX_RING_SIZE; i++) {
if (cp->rx_skb[i].skb) {
- pci_unmap_single(cp->pdev, cp->rx_skb[i].mapping,
+ desc = cp->rx_ring + i;
+ pci_unmap_single(cp->pdev, le64_to_cpu(desc->addr),
cp->rx_buf_sz, PCI_DMA_FROMDEVICE);
dev_kfree_skb(cp->rx_skb[i].skb);
}
@@ -1166,9 +1164,10 @@ static void cp_clean_rings (struct
[PATCH 5/7] 8139cp: removal of useless BUG_ON() check
netdev_priv() will provide a nice oops a few lines before the BUG_ON() check. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> --- drivers/net/8139cp.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) e68970e7543815133224f79a858e7c9e0c42f4de diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c index 9aef517..94ab3c3 100644 --- a/drivers/net/8139cp.c +++ b/drivers/net/8139cp.c @@ -2009,7 +2009,6 @@ static void cp_remove_one (struct pci_de struct net_device *dev = pci_get_drvdata(pdev); struct cp_private *cp = netdev_priv(dev); - BUG_ON(!dev); unregister_netdev(dev); iounmap(cp->regs); if (cp->wol_enabled) -- 1.3.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 0/7] 8139cp: misc minor changes
The serie contains the patches summarized below: - 1/7 trim ring_info - 2/7 remove gratuitous indirection - 3/7 ring_info removal for the receive path - 4/7 sync the device private data with its r8169 counterpart - 5/7 removal of useless BUG_ON() check - 6/7 pci_get_drvdata(pdev) can not be NULL in suspend handler - 7/7 use PCI_DEVICE() to shorten the PCI device table There is nothing critical in the serie as most of its content has slowly accumulated in various lost branches here. Some testing and review would be welcome. The patches are available at: - git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git 8139cp - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/8139cp -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] change max_dgram_qlen sysctl to __read_mostly
Change AF_UNIX sysctl_unix_max_dgram_qlen to __read_mostly. Signed-off-by: Brian Haley <[EMAIL PROTECTED]> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 7c91c20..b43a278 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -117,7 +117,7 @@ #include #include -int sysctl_unix_max_dgram_qlen = 10; +int sysctl_unix_max_dgram_qlen __read_mostly = 10; struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1]; DEFINE_SPINLOCK(unix_table_lock);
[PATCH] change somaxconn sysctl to __read_mostly
Change sysctl_somaxconn to __read_mostly.
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/socket.c b/net/socket.c
index f4d143c..e3d67fe 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1336,7 +1336,7 @@ asmlinkage long sys_bind(int fd, struct
* ready for listening.
*/
-int sysctl_somaxconn = SOMAXCONN;
+int sysctl_somaxconn __read_mostly = SOMAXCONN;
asmlinkage long sys_listen(int fd, int backlog)
{
Re: high latency with TCP connections
Kelly Burkhart wrote: On 8/30/06, David Miller <[EMAIL PROTECTED]> wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> > Expecting any performance with one byte write's is silly. This is absolutely true. TCP_NODELAY can only save you when you are sending a small amount of data "in aggregate", such as in an SSH or telnet session, whereas in the case being shown here a large amount of data is being sent in small chunks which will always get bad performance. The word performance in this list seems to always mean 'throughput'. It seems though that there could be some knob to tweak for those of us who don't care so much about throughput but care a great deal about latency. IIRC Apart from interactions with Nagle (TCP_NODELAY) or the mixing of packet and byte-based congestion control and avoidance heuristics, there really isn't much of anything else to tweak in TCP. If it can send data, it sends data. Where there _is_ a knob to turn these days might be down with the drivers and their NICs' use of interrupt coalescing: ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt rick jones - 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: Probably e1000 related Oops in 2.6.18-rc5
Krzysztof Oledzki wrote: Hello, My testing workstation running 2.6.18-rc5 Oopsed. It has a dualport e1000 card with bonding and vlans. All I have is three fotos made by a digital camera: http://www.ans.pl/Oops/1/ Hope it is enough. unfortunately the top of the OOPS is gone, and bonding+vlans makes this really very icky. I'm not quite sure this is an e1000 specific problem. Auke - 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 8/30/06, David Miller <[EMAIL PROTECTED]> wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> > Expecting any performance with one byte write's is silly. This is absolutely true. TCP_NODELAY can only save you when you are sending a small amount of data "in aggregate", such as in an SSH or telnet session, whereas in the case being shown here a large amount of data is being sent in small chunks which will always get bad performance. The word performance in this list seems to always mean 'throughput'. It seems though that there could be some knob to tweak for those of us who don't care so much about throughput but care a great deal about latency. -K - 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 Thursday 31 August 2006 19:12, Jean Tourrilhes wrote: > On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote: > > On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: > > > o modulation > > > o long/short retry > > > o relative power saving. > > > > I strongly disagree to these. > > And I strongly disagree with your disagrement ;-) > > > What's the point of adding more ioctls that we'll be implementing them > > as wrappers around nl80211? Right now, those new ioctls/options aren't > > implemented in *any* driver at all so they're completely useless, and > > just add more to the pile of historic baggage we end up carrying around. > > If we add these to mainline now, it's another thing we'll have to carry > > for a long time even though it currently has no users... > > 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 ? > I hope you realised that we are all trying to make 802.11 > support progress, each through our own ways. And that all those > efforts are not conflicting with each other. Yes. Why don't all people pull at the same rope end? > 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. > 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). I can't see how adding API reduces historic baggage. I don't think it's possible to reduce something by adding stuff to it. > Personally, I still have not seen the point of nl80211, as the > full Wireless Extension is already available over NetLink (have you > tried it ?). 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. Wireless Extensions are _horrible_ to implement and, most important, to get right. Yes, you say it's easy. But you implemented it. I also say understanding bcm43xx code is very easy. But I am sure that most people will strongly disagree here. I don't say you misdesigned WE. It was a good solution back when you designed it (1996?). WE is simply showing its age and should be replaced by nl80211. > > I'd much prefer merging nl80211 and putting any really *new* stuff into > > it directly. Of course this fragments the user space API for a while > > since you need to use two APIs then for the time being to configure all > > things, but we can move over all the rest of the configuration gradually > > and before we end up in mainline with the new API we can have that > > finished. > > Good luck with that plan, user-space is notorious to not like > entropy... > 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. 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. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18] WE-21 support (core API)
On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote: > On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: > > o modulation > > o long/short retry > > o relative power saving. > > I strongly disagree to these. And I strongly disagree with your disagrement ;-) > What's the point of adding more ioctls that we'll be implementing them > as wrappers around nl80211? Right now, those new ioctls/options aren't > implemented in *any* driver at all so they're completely useless, and > just add more to the pile of historic baggage we end up carrying around. > If we add these to mainline now, it's another thing we'll have to carry > for a long time even though it currently has no users... 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 ? I hope you realised that we are all trying to make 802.11 support progress, each through our own ways. And that all those efforts are not conflicting with each other. 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. 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). Personally, I still have not seen the point of nl80211, as the full Wireless Extension is already available over NetLink (have you tried it ?). 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. > I'd much prefer merging nl80211 and putting any really *new* stuff into > it directly. Of course this fragments the user space API for a while > since you need to use two APIs then for the time being to configure all > things, but we can move over all the rest of the configuration gradually > and before we end up in mainline with the new API we can have that > finished. Good luck with that plan, user-space is notorious to not like entropy... 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. > Or putting it the other way round, I'm ok with > * cleaning up the ssid mess > * adding RCPI (we'll probably be using it in nl80211 anyway, so it's >easier if we add it now and declare no support for other things) > * getting rid of get_wireless_stats (good one!) >[actually, I plan to get rid of wireless_handlers too] And if you look closely, you will realise the other features are also good for you ;-) > johannes Have fun... 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
Probably e1000 related Oops in 2.6.18-rc5
Hello, My testing workstation running 2.6.18-rc5 Oopsed. It has a dualport e1000 card with bonding and vlans. All I have is three fotos made by a digital camera: http://www.ans.pl/Oops/1/ Hope it is enough. Best regards, Krzysztof Olędzki
Re: [PATCH] WE-21 for bcm43xx (wireless-2.6 git)
On Thu, Aug 31, 2006 at 09:57:45AM -0400, John W. Linville wrote: > On Thu, Aug 31, 2006 at 08:22:22AM -0500, Larry Finger wrote: > > > John, have you merged, or do you plan to merge, "[PATCH 2.6.18] WE-21 > > support (core API)" into > > wireless-2.6? > > I guess that is still up for discussion. It looks like at least part > of it is desirable, but maybe not other parts. More details ? > Perhaps you should post the patch w/o WE-20 support. I'll make sure > they all get in at the same time (if at all). It does not really make sense has this patch only adds WE-21 support to the driver. > John Have fun... 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 2.6.18] WE-21 for bcm43xx (wireless-2.6 git)
On Thu, Aug 31, 2006 at 03:09:04PM +0200, Johannes Berg wrote: > Jean, > > > This is the version of the patch for out-of-tree, I guess you > > will need it. Not tested. > > We don't, neither softmac nor bcm43xx is maintained out-of-tree any > more. > > johannes Cool. I should have checked... 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: high latency with TCP connections
Alexander Vodomerov wrote: On Wed, Aug 30, 2006 at 02:39:55PM -0700, David Miller wrote: Expecting any performance with one byte write's is silly. This is absolutely true. TCP_NODELAY can only save you when you are sending a small amount of data "in aggregate", such as in an SSH or telnet session, whereas in the case being shown here a large amount of data is being sent in small chunks which will always get bad performance. Information is sent with one byte write's because it is not available at the moment of sending (it may be read from hardware device or user). If I change 1 to 10 or 100 nothing changes. I'm afraid there is a bit of misunderstanding here. Only very small amount of data is being sent over network. The total traffic for example I sent is only 10 bytes/s. After every 10th packet program does usleep(10) to simulate pause before next available data. There are really 3 factors: 1) total size of information is small 2) data for transferring is arrived by small portions from external source 3) it is very important that any portion should be delivered to receiver as soon as possible. Is TCP is good choice for such transfer or some other protocol is better suited? If message boundary preservation is a useful feature for your app, you could try SCTP. You should be able to do this by replacing IPPROTO_TCP with IPPROTO_SCTP and TCP_NODELAY with SCTP_NODELAY. Thanks Sridhar With best regards, Alexander. - 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 - 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, 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). -- 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 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. Can you reproduce this on older kernels? Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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
Unable to halt or reboot due to - unregister_netdevice: waiting for eth0.20 to become free. Usage count = 1
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? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
> Assuming the permission is granted the packet's secmark is > replaced with > the updated context. This updated secmark context would then > be used in > sock_rcv_skb() to make an access decision, yes? You got it. > > >> The ability to make access decisions based on the process > >>consuming the data and the data itself it one of the nicer > >>qualities of > >>NetLabel in my opinion. > > > > This nicer quality ends up being preserved as explained above :) > > It wasn't clear to me from your patch or the "master plan" what you > intended to do with the NetLabel context. I thought the "/* See if > CIPSO can flow in thru the current secmark here */" comment in your > patch was rather cryptic. That was a test for you :) > > > We just need to get out of the mindset of viewing netlabel > separately > > once we are past the reconciliation point. > > Agreed. Although to be honest, I think the NetLabel context can be > reconciled with the secmark and XFRM contexts just as easily using the > existing sock_rcv_skb() hook. Nope. That won't work for forwarded traffic. > I guess I need to see where the > xfrm[4|6]_policy_check() hooks are called from in the stack to better > understand ... You are on the right path here. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
Hi Again,
It took a while to find equipment for test environment, but now I
have a test environment that I can test.
Here is the result:
---
[17180051.768000] ip6_fragment: hlen = 0x818, len = 0x7ce, nexthdr=4
[17180051.84] [ cut here ]
[17180051.84] kernel BUG at net/ipv6/ip6_output.c:510!
[17180051.84] invalid opcode: [#1]
[17180051.84] SMP
[17180051.84] Modules linked in: ipmi_si ipmi_msghandler ide_cd cdrom
[17180051.84] CPU:0
[17180051.84] EIP:0060:[]Not tainted VLI
[17180051.84] EFLAGS: 00010296 (2.6.17.11-ns-pri-debug-p1 #6)
[17180051.84] EIP is at ip6_fragment+0x7f6/0x803
[17180051.84] eax: 0048 ebx: f75c4c5c ecx: c038f5bc edx: 0286
[17180051.84] esi: f7605c50 edi: ebp: f76e2c80 esp: f7605bb8
[17180051.84] ds: 007b es: 007b ss: 0068
[17180051.84] Process named (pid: 1899, threadinfo=f7604000 task=f75cead0)
[17180051.84] Stack: c0324600 0818 07ce 0004 f7605bdc
0400
[17180051.84]ffd14ca4 f7605ea8 0818 f77a4040 01fe
f755d080 f7976048
[17180051.84]f76e2c80 f7605c50 f7976040 f75c4a80 c02bb612 f76e2c80
c02bb40e c02bd66a
[17180051.84] Call Trace:
[17180051.84] ip6_output+0x3c/0x4c
ip6_output2+0x0/0x1c8
[17180051.84] ip6_push_pending_frames+0x250/0x390
udp_v6_push_pending_frames+0x13d/0x1a4
[17180051.84] udpv6_sendmsg+0x58a/0x953
udpv6_recvmsg+0x20c/0x303
[17180051.84] inet_sendmsg+0x4a/0x56
sock_sendmsg+0xeb/0x105
[17180051.84] __next_cpu+0x22/0x31
find_busiest_group+0xd6/0x305
[17180051.84] autoremove_wake_function+0x0/0x57
copy_from_user+0x46/0x7c
[17180051.84] copy_from_user+0x46/0x7c
sys_sendmsg+0x191/0x1f8
[17180051.84] futex_wait+0x129/0x238
find_extend_vma+0x29/0x7e
[17180051.84] default_wake_function+0x0/0x12
futex_wake+0x4a/0xba
[17180051.84] copy_from_user+0x46/0x7c
sys_socketcall+0x236/0x254
[17180051.84] syscall_call+0x7/0xb
[17180051.84] Code: 50 60 e9 36 f9 ff ff 0f b6 44 24 1b 8b 54 24 2c 89 44
24 0c 8b 45 60 c7 04 24 00 46 32 c0 89 54 24 04 89 44 24 08 e8 50 07 e6 ff <0f>
0b fe 01 41 13 32 c0 e9 68 f8 ff ff 55 57 56 31 f6 53 83 ec
[17180051.84] EIP: [] ip6_fragment+0x7f6/0x803 SS:ESP
0068:f7605bb8
---
I hope this helps.
Cheers,
--
cagri
On Tue, Aug 29, 2006 at 06:28:28PM +1000, Herbert Xu wrote:
>
> Thanks. Please try this patch and tell me if it prints anything out.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 4fb47a2..5e2e4ea 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -508,6 +508,10 @@ static int ip6_fragment(struct sk_buff *
> dev = rt->u.dst.dev;
> hlen = ip6_find_1stfragopt(skb, &prevhdr);
> nexthdr = *prevhdr;
> + if (unlikely(hlen > skb->len)) {
> + printk(KERN_CRIT "ip6_fragment: hlen = 0x%x, len = 0x%x,
> nexthdr=%d\n", hlen, skb->len, nexthdr);
> + BUG();
> + }
>
> mtu = dst_mtu(&rt->u.dst);
> if (np && np->frag_size < mtu) {
-
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: IPSec kernel oops on ppc64
It works! I applied the patch to linux-2.6.17 + patch-2.6.17-rc1 and tried icmp, tcp and udp as well as sftp with ipsec and they all worked. Thanks Regards, Joy >Herbert Xu writes: > >> Interesting. We were previously off by 28 bytes, now we're off by 8 :) > >You missed a couple of 'beqlr' instructions (branch if equal to LR). >I'd be interested to know if it still fails with the patch below. > >Thanks, >Paul. > >diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S >index fd66acf..7173ba9 100644 >--- a/arch/powerpc/lib/memcpy_64.S >+++ b/arch/powerpc/lib/memcpy_64.S >@@ -11,6 +11,7 @@ #include > > .align 7 > _GLOBAL(memcpy) >+ std r3,48(r1) /* save destination pointer for return value */ > mtcrf 0x01,r5 > cmpldi cr1,r5,16 > neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry >@@ -38,7 +39,7 @@ _GLOBAL(memcpy) > stdur9,16(r3) > bdnz1b > 3:std r8,8(r3) >- beqlr >+ beq 3f > addir3,r3,16 > ld r9,8(r4) > .Ldo_tail: >@@ -53,7 +54,8 @@ _GLOBAL(memcpy) > 2:bf cr7*4+3,3f > rotldi r9,r9,8 > stb r9,0(r3) >-3:blr >+3:ld r3,48(r1) /* return dest pointer */ >+ blr > > .Lsrc_unaligned: > srdir6,r5,3 >@@ -115,7 +117,7 @@ _GLOBAL(memcpy) > 5:srd r12,r9,r11 > or r12,r8,r12 > std r12,24(r3) >- beqlr >+ beq 4f > cmpwi cr1,r5,8 > addir3,r3,32 > sld r9,r9,r10 >@@ -167,4 +169,5 @@ _GLOBAL(memcpy) > 3:bf cr7*4+3,4f > lbz r0,0(r4) > stb r0,0(r3) >-4:blr >+4:ld r3,48(r1) /* return dest pointer */ >+ blr - 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] Wireless-2.6 changes for bcm43xx and SoftMAC for WE-21
John,
As discussed earlier, here is the wireless-2.6 patch for WE-21 in bcm43xx-softmac. The core patch
for the SSID length, which I believe is non-controversial, must be applied first.
Larry
--
Patch to make bcm43xx-softmac be compatible with the revised SSID length of
WE-21.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -80,10 +80,10 @@ ieee80211softmac_wx_set_essid(struct net
* If it's our network, ignore the change, we're already doing it!
*/
if((sm->associnfo.associating || sm->associated) &&
- (data->essid.flags && data->essid.length && extra)) {
+ (data->essid.flags && data->essid.length)) {
/* Get the associating network */
n = ieee80211softmac_get_network_by_bssid(sm,
sm->associnfo.bssid);
- if(n && n->essid.len == (data->essid.length - 1) &&
+ if(n && n->essid.len == data->essid.length &&
!memcmp(n->essid.data, extra, n->essid.len)) {
dprintk(KERN_INFO PFX "Already associating or associated to
"MAC_FMT"\n",
MAC_ARG(sm->associnfo.bssid));
@@ -109,8 +109,8 @@ ieee80211softmac_wx_set_essid(struct net
sm->associnfo.static_essid = 0;
sm->associnfo.assoc_wait = 0;
- if (data->essid.flags && data->essid.length && extra /*required?*/) {
- length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
+ if (data->essid.flags && data->essid.length) {
+ length = min((int) data->essid.length, IW_ESSID_MAX_SIZE);
if (length) {
memcpy(sm->associnfo.req_essid.data, extra, length);
sm->associnfo.static_essid = 1;
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -334,7 +334,7 @@ static int bcm43xx_wx_get_nick(struct ne
size_t len;
mutex_lock(&bcm->mutex);
- len = strlen(bcm->nick) + 1;
+ len = strlen(bcm->nick);
memcpy(extra, bcm->nick, len);
data->data.length = (__u16)len;
data->data.flags = 1;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
Venkat Yekkirala wrote: >>My main concern with these patches is that moving the >>NetLabel check out >>of selinux_socket_sock_rcv_skb() and into >>selinux_skb_policy_check() (as >>it is currently written) would force us to compare a packet's NetLabel >>with either the IPsec label or the secmark label > > Yes you would do these checks (while using a netlabel based off of the > secmark at that point) to enforce flow control and when they succeed, > you will copy netlabel into secmark. > >>and not the socket's >>label. > > The socket Vs. secmark check that happens later in rcv_skb will in fact be > looking at the cipso label that is by then a part of the secmark context. So what you envison is that when an MLS label is found on a packet using NetLabel the MLS label from the packet is attached to the secmark context (replacing the existing MLS label, if any) and the resulting context would be checked for a "flow_in" permission, yes? Assuming the permission is granted the packet's secmark is replaced with the updated context. This updated secmark context would then be used in sock_rcv_skb() to make an access decision, yes? >> The ability to make access decisions based on the process >>consuming the data and the data itself it one of the nicer >>qualities of >>NetLabel in my opinion. > > This nicer quality ends up being preserved as explained above :) It wasn't clear to me from your patch or the "master plan" what you intended to do with the NetLabel context. I thought the "/* See if CIPSO can flow in thru the current secmark here */" comment in your patch was rather cryptic. > We just need to get out of the mindset of viewing netlabel separately > once we are past the reconciliation point. Agreed. Although to be honest, I think the NetLabel context can be reconciled with the secmark and XFRM contexts just as easily using the existing sock_rcv_skb() hook. I guess I need to see where the xfrm[4|6]_policy_check() hooks are called from in the stack to better understand ... -- paul moore linux security @ hp - 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] Add netpoll/netconsole support to vlan devices
Greetings, I recently tried running netconsole via a vlan interface without luck, and decided to do something about it (see patch below). My interfaces look like this: eth0 Link encap:Ethernet HWaddr 00:14:5E:28:3C:2E UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11763760878 errors:0 dropped:0 overruns:0 frame:0 TX packets:13800040335 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3453951528686 (3.1 TiB) TX bytes:7086425530052 (6.4 TiB) Interrupt:169 eth0.20 Link encap:Ethernet HWaddr 00:14:5E:28:3C:2E inet addr:vvv.xxx.yyy.zzz Bcast:ggg.hhh.iii.jjj Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11759883828 errors:0 dropped:0 overruns:0 frame:0 TX packets:13800040452 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3194985806767 (2.9 TiB) TX bytes:6975984645540 (6.3 TiB) Trying to load netconsole fails miserably : [EMAIL PROTECTED] root]# modprobe netconsole netconsole=@/eth0,[EMAIL PROTECTED]/00:04:23:BF:D9:62 FATAL: Error inserting netconsole (/lib/modules/2.6.17.8/kernel/drivers/net/netconsole.ko): Invalid argument [EMAIL PROTECTED] root]# modprobe netconsole netconsole=@/eth0.20,[EMAIL PROTECTED]/00:04:23:BF:D9:62 FATAL: Error inserting netconsole (/lib/modules/2.6.17.8/kernel/drivers/net/netconsole.ko): Invalid argument And results in this in dmesg : netconsole: interface eth0 netconsole: remote port 10514 netconsole: remote IP aaa.bbb.ccc.ddd netconsole: remote ethernet address 00:04:23:bf:d9:62 netconsole: no IP address for eth0, aborting netconsole: local port 6665 netconsole: interface eth0.20 netconsole: remote port 10514 netconsole: remote IP aaa.bbb.ccc.ddd netconsole: remote ethernet address 00:04:23:bf:d9:62 netconsole: eth0.20 doesn't support polling, aborting. The actual interface is a e1000 and supports polling just fine. The problem is simply that netpoll won't play with eth0 since it has no IP and it won't play with eth0.20 either since it's a vlan interface and doesn't support polling even if the underlying device does. This is a problem for me since it means that several of my servers that are configured like this won't be able to use netconsole. So I set out to try and fix the problem by making the vlan device support polling if the underlying device supports polling. I have met with a resonable success in that the patch below seems to work. With this patch I can now load netconsole for eth0.20 and log messages are send just fine and can be recieved on the remote host. netconsole: local port 6665 netconsole: interface eth0.20 netconsole: remote port 10514 netconsole: remote IP aaa.bbb.ccc.ddd netconsole: remote ethernet address 00:04:23:bf:d9:62 netconsole: local IP vvv.xxx.yyy.zzz netconsole: network logging started Now, I would very much like to get this merged, but first I would appreciate some review of the patch. This part of the kernel is not one I know all too well, so I may have made a number of silly mistakes. If people would kindly take a look at the patch and point out any problems with it so I can fix it up and arrive at a version that's mergable, I'd greatly appreciate it. PS. If you reply to this on the netdev list, please keep me on Cc: since I'm only subscribed to linux-kernel. Kind regards, Jesper Juhl <[EMAIL PROTECTED]> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- net/8021q/vlan.c |5 + net/8021q/vlan_dev.c | 15 ++- 2 files changed, 19 insertions(+), 1 deletion(-) diff -upr linux-2.6.18-rc5-git2-orig/net/8021q/vlan.c linux-2.6.18-rc5-git2/net/8021q/vlan.c --- linux-2.6.18-rc5-git2-orig/net/8021q/vlan.c 2006-08-31 10:07:08.0 +0200 +++ linux-2.6.18-rc5-git2/net/8021q/vlan.c 2006-08-31 16:34:33.0 +0200 @@ -11,6 +11,7 @@ * Add HW acceleration hooks - David S. Miller ; * Correct all the locking - David S. Miller ; * Use hash table for VLAN groups - David S. Miller + * Add NETPOLL support - Jesper Juhl * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -512,6 +513,10 @@ static struct net_device *register_vlan_ } new_dev->hard_header_parse = real_dev->hard_header_parse; +#ifdef CONFIG_NET_POLL_CONTROLLER + new_dev->poll_controller = real_dev->poll_controller; +#endif + VLAN_DEV_INFO(new_dev)->vlan_id = VLAN_ID; /* 1 through VLAN_VID_MASK */ VLAN_DEV_INFO(new_dev)->real_dev = real_dev; VLAN_DEV_INFO(new_dev)->dent = NULL; diff -upr linux-2.6.18-rc5-git2-orig/net/8021q/vlan_dev.c linux-2.6.18-rc5-git2/net/8021q/vlan_dev.c --- linux-2.6.18-rc5-git2-orig/net/8021q/vlan_dev.c 2006-06-18 03:49:35.0 +0200 +++ linu
[PATCH 2.6.17 9/9] NetXen: CRB reg definitions
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_phan_reg.h
linux-2.6.17/drivers/net/netxen/netxen_nic_phan_reg.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_phan_reg.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_phan_reg.h 2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,195 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ */
+
+#ifndef __NIC_PHAN_REG_H_
+#define __NIC_PHAN_REG_H_
+
+/**
+ * CRB Registers or queue message done only at initialization time
+ **/
+
+/**
+ * The following 2 are the base adresses for the CRB registers and their
+ * offsets will be added to get addresses for the index addresses...
+ **/
+#define NIC_CRB_BASE_PORT1 NETXEN_CAM_RAM(0x200)
+#define NIC_CRB_BASE_PORT2 NETXEN_CAM_RAM(0x250)
+
+#define NETXEN_NIC_REG(X) (NIC_CRB_BASE_PORT1+(X))
+
+/**
+ * CrbPortPhanCntrHi/Lo is used to pass the address of HostPhantomIndex address
+ * which can be read by the Phantom host to get producer/consumer indexes from
+ * Phantom/Casper. If it is not HOST_SHARED_MEMORY, then the following
+ * registers will be used for the addresses of the ring's shared memory
+ * on the Phantom.
+ **/
+
+#define CRB_PHAN_CNTRL_LO_OFFSET NETXEN_NIC_REG(0x00)
+#define CRB_PHAN_CNTRL_HI_OFFSET NETXEN_NIC_REG(0x04)
+
+/* point to the indexes */
+#define CRB_CMD_PRODUCER_OFFSETNETXEN_NIC_REG(0x08)
+#define CRB_CMD_CONSUMER_OFFSETNETXEN_NIC_REG(0x0c)
+
+/* address of command descriptors in the host memory */
+#define CRB_HOST_CMD_ADDR_HI NETXEN_NIC_REG(0x30)
+#define CRB_HOST_CMD_ADDR_LO NETXEN_NIC_REG(0x34)
+
+/* The following 4 CRB registers are for doing performance coal */
+#define CRB_CMD_INTR_LOOP NETXEN_NIC_REG(0x38)
+#define CRB_CMD_DMA_LOOP NETXEN_NIC_REG(0x3c)
+#define CRB_RCV_INTR_LOOP NETXEN_NIC_REG(0x40)
+#define CRB_RCV_DMA_LOOP NETXEN_NIC_REG(0x44)
+
+/* Needed by the host to find out the state of Phantom's initialization */
+#define CRB_ENABLE_TX_INTR NETXEN_NIC_REG(0x4c)
+#define CRB_CMDPEG_STATE NETXEN_NIC_REG(0x50)
+#define CRB_CMDPEG_CMDRING NETXEN_NIC_REG(0x54)
+
+/* Interrupt coalescing parameters */
+#define CRB_GLOBAL_INT_COALNETXEN_NIC_REG(0x80)
+#define CRB_INT_COAL_MODE NETXEN_NIC_REG(0x84)
+#define CRB_MAX_RCV_BUFS NETXEN_NIC_REG(0x88)
+#define CRB_TX_INT_THRESHOLD NETXEN_NIC_REG(0x8c)
+#define CRB_RX_PKT_TIMER NETXEN_NIC_REG(0x90)
+#define CRB_TX_PKT_TIMER NETXEN_NIC_REG(0x94)
+#define CRB_RX_PKT_CNT NETXEN_NIC_REG(0x98)
+#define CRB_RX_TMR_CNT NETXEN_NIC_REG(0x9c)
+
+/* Register for communicating XG link status */
+#define CRB_XG_STATE NETXEN_NIC_REG(0xa0)
+
+/* Debug registers for controlling NIC pkt gen agent */
+#define CRB_AGENT_GO NETXEN_NIC_REG(0xb0)
+#define CRB_AGENT_TX_SIZE NETXEN_NIC_REG(0xb4)
+#define CRB_AGENT_TX_TYPE NETXEN_NIC_REG(0xb8)
+#define CRB_AGENT_TX_ADDR NETXEN_NIC_REG(0xbc)
+#define CRB_AGENT_TX_MSS NETXEN_NIC_REG(0xc0)
+
+/* Debug registers for observing NIC performance */
+#define CRB_TX_STATE NETXEN_NIC_REG(0xd0)
+#define CRB_TX_COUNT NETXEN_NIC_REG(0xd4)
+#define CRB_RX_STATE NETXEN_NIC_REG(0xd8)
+
+/* CRB registers per Rcv Descriptor ring */
+struct netxen_rcv_desc_crb {
+ u32 crb_rcv_producer_offset __attribute__ ((aligned(512)));
+ u32 crb_rcv_consumer_offset;
+ u32 crb_globalrcv_ring;
+};
+
+/*
+ * CRB registers used by the receive peg logic. One instance of these
+ * needs to be instantiated per instance of the receive peg.
+ */
+
+struct netxen_recv_crb {
+ struct netxen_rcv_desc_crb rcv_desc_crb[NUM_R
[PATCH 2.6.17 8/9] NetXen: Header file and ioctl header file
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hdr.h
linux-2.6.17/drivers/net/netxen/netxen_nic_hdr.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hdr.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hdr.h2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,611 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ */
+
+#ifndef __NETXEN_NIC_HDR_H_
+#define __NETXEN_NIC_HDR_H_
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include /* for memset */
+
+/*
+ * The basic unit of access when reading/writing control registers.
+ */
+
+typedef __le32 netxen_crbword_t; /* single word in CRB space */
+
+enum {
+ NETXEN_HW_H0_CH_HUB_ADR = 0x05,
+ NETXEN_HW_H1_CH_HUB_ADR = 0x0E,
+ NETXEN_HW_H2_CH_HUB_ADR = 0x03,
+ NETXEN_HW_H3_CH_HUB_ADR = 0x01,
+ NETXEN_HW_H4_CH_HUB_ADR = 0x06,
+ NETXEN_HW_H5_CH_HUB_ADR = 0x07,
+ NETXEN_HW_H6_CH_HUB_ADR = 0x08
+};
+
+/* Hub 0 */
+enum {
+ NETXEN_HW_MN_CRB_AGT_ADR = 0x15,
+ NETXEN_HW_MS_CRB_AGT_ADR = 0x25
+};
+
+/* Hub 1 */
+enum {
+ NETXEN_HW_PS_CRB_AGT_ADR = 0x73,
+ NETXEN_HW_SS_CRB_AGT_ADR = 0x20,
+ NETXEN_HW_RPMX3_CRB_AGT_ADR = 0x0b,
+ NETXEN_HW_QMS_CRB_AGT_ADR = 0x00,
+ NETXEN_HW_SQGS0_CRB_AGT_ADR = 0x01,
+ NETXEN_HW_SQGS1_CRB_AGT_ADR = 0x02,
+ NETXEN_HW_SQGS2_CRB_AGT_ADR = 0x03,
+ NETXEN_HW_SQGS3_CRB_AGT_ADR = 0x04,
+ NETXEN_HW_C2C0_CRB_AGT_ADR = 0x58,
+ NETXEN_HW_C2C1_CRB_AGT_ADR = 0x59,
+ NETXEN_HW_C2C2_CRB_AGT_ADR = 0x5a,
+ NETXEN_HW_RPMX2_CRB_AGT_ADR = 0x0a,
+ NETXEN_HW_RPMX4_CRB_AGT_ADR = 0x0c,
+ NETXEN_HW_RPMX7_CRB_AGT_ADR = 0x0f,
+ NETXEN_HW_RPMX9_CRB_AGT_ADR = 0x12,
+ NETXEN_HW_SMB_CRB_AGT_ADR = 0x18
+};
+
+/* Hub 2 */
+enum {
+ NETXEN_HW_NIU_CRB_AGT_ADR = 0x31,
+ NETXEN_HW_I2C0_CRB_AGT_ADR = 0x19,
+ NETXEN_HW_I2C1_CRB_AGT_ADR = 0x29,
+
+ NETXEN_HW_SN_CRB_AGT_ADR = 0x10,
+ NETXEN_HW_I2Q_CRB_AGT_ADR = 0x20,
+ NETXEN_HW_LPC_CRB_AGT_ADR = 0x22,
+ NETXEN_HW_ROMUSB_CRB_AGT_ADR = 0x21,
+ NETXEN_HW_QM_CRB_AGT_ADR = 0x66,
+ NETXEN_HW_SQG0_CRB_AGT_ADR = 0x60,
+ NETXEN_HW_SQG1_CRB_AGT_ADR = 0x61,
+ NETXEN_HW_SQG2_CRB_AGT_ADR = 0x62,
+ NETXEN_HW_SQG3_CRB_AGT_ADR = 0x63,
+ NETXEN_HW_RPMX1_CRB_AGT_ADR = 0x09,
+ NETXEN_HW_RPMX5_CRB_AGT_ADR = 0x0d,
+ NETXEN_HW_RPMX6_CRB_AGT_ADR = 0x0e,
+ NETXEN_HW_RPMX8_CRB_AGT_ADR = 0x11
+};
+
+/* Hub 3 */
+enum {
+ NETXEN_HW_PH_CRB_AGT_ADR = 0x1A,
+ NETXEN_HW_SRE_CRB_AGT_ADR = 0x50,
+ NETXEN_HW_EG_CRB_AGT_ADR = 0x51,
+ NETXEN_HW_RPMX0_CRB_AGT_ADR = 0x08
+};
+
+/* Hub 4 */
+enum {
+ NETXEN_HW_PEGN0_CRB_AGT_ADR = 0x40,
+ NETXEN_HW_PEGN1_CRB_AGT_ADR,
+ NETXEN_HW_PEGN2_CRB_AGT_ADR,
+ NETXEN_HW_PEGN3_CRB_AGT_ADR,
+ NETXEN_HW_PEGNI_CRB_AGT_ADR,
+ NETXEN_HW_PEGND_CRB_AGT_ADR,
+ NETXEN_HW_PEGNC_CRB_AGT_ADR,
+ NETXEN_HW_PEGR0_CRB_AGT_ADR,
+ NETXEN_HW_PEGR1_CRB_AGT_ADR,
+ NETXEN_HW_PEGR2_CRB_AGT_ADR,
+ NETXEN_HW_PEGR3_CRB_AGT_ADR
+};
+
+/* Hub 5 */
+enum {
+ NETXEN_HW_PEGS0_CRB_AGT_ADR = 0x40,
+ NETXEN_HW_PEGS1_CRB_AGT_ADR,
+ NETXEN_HW_PEGS2_CRB_AGT_ADR,
+ NETXEN_HW_PEGS3_CRB_AGT_ADR,
+ NETXEN_HW_PEGSI_CRB_AGT_ADR,
+ NETXEN_HW_PEGSD_CRB_AGT_ADR,
+ NETXEN_HW_PEGSC_CRB_AGT_ADR
+};
+
+/* Hub 6 */
+enum {
+ NETXEN_HW_CAS0_CRB_AGT_ADR = 0x46,
+ NETXEN_HW_CAS1_CRB_AGT_ADR = 0x47,
+ NETXEN_HW_CAS2_CRB_AGT_ADR = 0x48,
+ NETXEN_HW_CAS3_CRB_AGT_ADR = 0x49,
+ NETXEN_HW_NCM_CRB_AGT_ADR = 0x16,
+ NETXEN_HW_TMR_CRB_AGT_ADR = 0x17,
+ NETXEN_HW_XDMA_CRB_AGT_ADR = 0x05,
+ NETXEN_HW_OCM0_CRB_AGT_ADR = 0x06,
+ NETXEN_HW_OCM1_CRB_AGT_ADR = 0x07
+};
[PATCH 2.6.17 7/9] NetXen: hw access routines header file
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.h
linux-2.6.17/drivers/net/netxen/netxen_nic_hw.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hw.h 2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,499 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Structures, enums, and macros for the MAC
+ *
+ */
+
+#ifndef __NETXEN_NIC_HW_H_
+#define __NETXEN_NIC_HW_H_
+
+#include "netxen_nic_hdr.h"
+
+/* Hardware memory size of 128 meg */
+#define NETXEN_MEMADDR_MAX (128 * 1024 * 1024)
+
+#ifndef readq
+static inline u64 readq(void __iomem * addr)
+{
+ return readl(addr) | (((u64) readl(addr + 4)) << 32LL);
+}
+#endif
+
+#ifndef writeq
+static inline void writeq(u64 val, void __iomem * addr)
+{
+ writel(((u32) (val)), (addr));
+ writel(((u32) (val >> 32)), (addr + 4));
+}
+#endif
+
+#define NETXEN_NIC_HW_BLOCK_WRITE_64(DATA_PTR, ADDR, NUM_WORDS)\
+ do {\
+ int num;\
+ u64 *a = (u64 *) (DATA_PTR);\
+ u64 *b = (u64 *) (ADDR);\
+ for (num = 0; num < (NUM_WORDS); num++) {\
+ writeq(readq(a), b);\
+ b++;\
+ a++;\
+ } \
+ } while (0)
+
+#define NETXEN_NIC_HW_BLOCK_READ_64(DATA_PTR, ADDR, NUM_WORDS) \
+ do {\
+ int num;\
+ u64 *a = (u64 *) (DATA_PTR);\
+ u64 *b = (u64 *) (ADDR);\
+ for (num = 0; num < (NUM_WORDS); num++) {\
+ writeq(readq(b), a);\
+ b++;\
+ a++;\
+ } \
+ } while (0)
+
+#define NETXEN_PCI_MAPSIZE_BYTES (NETXEN_PCI_MAPSIZE << 20)
+
+#define NETXEN_NIC_LOCKED_READ_REG(X, Y) \
+ addr = (void __iomem *)(adapter->ahw.pci_base + X); \
+ *(u32 *)Y = readl(addr);
+
+#define NETXEN_NIC_LOCKED_WRITE_REG(X, Y) \
+ addr = (void __iomem *)(adapter->ahw.pci_base + X); \
+ writel(*(u32 *)Y, addr);
+
+struct netxen_port;
+void netxen_nic_set_link_parameters(struct netxen_port *port);
+struct netxen_adapter;
+void netxen_nic_flash_print(struct netxen_adapter *adapter);
+int netxen_nic_hw_write_wx(struct netxen_adapter *adapter, u64 off,
+ void *data, int len);
+void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
+unsigned long off, int data);
+int netxen_nic_hw_read_wx(struct netxen_adapter *adapter, u64 off,
+ void *data, int len);
+
+typedef u8 netxen_ethernet_macaddr_t[6];
+
+/* Nibble or Byte mode for phy interface (GbE mode only) */
+typedef enum {
+ NETXEN_NIU_10_100_MB = 0,
+ NETXEN_NIU_1000_MB
+} netxen_niu_gbe_ifmode_t;
+
+#define _netxen_crb_set_bit(var, bit) (var |= (1 << bit))
+#define _netxen_crb_clear_bit(var, bit) (var &= (~(1 << bit)))
+#define _netxen_crb_get_bit(var, bit) ((var >> bit) & 0x1)
+
+/*
+ * NIU GB MAC Config Register 0 (applies to GB0, GB1, GB2, GB3)
+ *
+ * Bit 0 : enable_tx => 1:enable frame xmit, 0:disable
+ * Bit 1 : tx_synced => R/O: xmit enable synched to xmit stream
+ * Bit 2 : enable_rx => 1:enable frame recv, 0:disable
+ * Bit 3 : rx_synced => R/O: recv enable sync
[PATCH 2.6.17 6/9] NetXen: Main header file
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic.h
linux-2.6.17/drivers/net/netxen/netxen_nic.h
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic.h2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,901 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ */
+
+#ifndef _NETXEN_NIC_H_
+#define _NETXEN_NIC_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "netxen_nic_hw.h"
+
+#define NETXEN_NIC_BUILD_NO "232"
+#define _NETXEN_NIC_LINUX_MAJOR 2
+#define _NETXEN_NIC_LINUX_MINOR 3
+#define _NETXEN_NIC_LINUX_SUBVERSION 57
+#define NETXEN_NIC_LINUX_VERSIONID "2.3.57"
+#define NETXEN_NIC_FW_VERSIONID "2.3.57"
+
+#define RCV_DESC_RINGSIZE \
+ (sizeof(struct rcv_desc_t) * adapter->max_rx_desc_count)
+#define STATUS_DESC_RINGSIZE \
+ (sizeof(struct status_desc_t)* adapter->max_rx_desc_count)
+#define TX_RINGSIZE\
+ (sizeof(struct netxen_cmd_buffer) * adapter->max_tx_desc_count)
+#define RCV_BUFFSIZE \
+ (sizeof(struct netxen_rx_buffer) * rcv_desc->max_rx_desc_count)
+#define find_diff_among(a,b,range) ((a)<(b)?((b)-(a)):((b)+(range)-(a)))
+
+#define NETXEN_NETDEV_STATUS 0x1
+
+#define ADDR_IN_WINDOW1(off) \
+ ((off > NETXEN_CRB_PCIX_HOST2) && (off < NETXEN_CRB_MAX)) ? 1 : 0
+
+/*
+ * normalize a 64MB crb address to 32MB PCI window
+ * To use NETXEN_CRB_NORMALIZE, window _must_ be set to 1
+ */
+#define NETXEN_CRB_NORMALIZE(adapter, reg) \
+ (void __iomem *)(ptrdiff_t)((adapter)->ahw.pci_base + (reg) \
+ - NETXEN_CRB_PCIX_HOST2 + NETXEN_CRB_PCIX_HOST)
+
+#define MAX_RX_BUFFER_LENGTH 2000
+#define MAX_RX_JUMBO_BUFFER_LENGTH 9046
+#define RX_DMA_MAP_LEN (MAX_RX_BUFFER_LENGTH - NET_IP_ALIGN)
+#define RX_JUMBO_DMA_MAP_LEN \
+ (MAX_RX_JUMBO_BUFFER_LENGTH - NET_IP_ALIGN)
+
+/*
+ * Maximum number of ring contexts
+ */
+#define MAX_RING_CTX 1
+
+/* Opcodes to be used with the commands */
+enum {
+ TX_ETHER_PKT = 0x01,
+/* The following opcodes are for IP checksum */
+ TX_TCP_PKT,
+ TX_UDP_PKT,
+ TX_IP_PKT,
+ TX_TCP_LSO,
+ TX_IPSEC,
+ TX_IPSEC_CMD
+};
+
+/* The following opcodes are for internal consumption. */
+#define NETXEN_CONTROL_OP 0x10
+#define PEGNET_REQUEST 0x11
+
+#defineMAX_NUM_CARDS 4
+
+#define MAX_BUFFERS_PER_CMD32
+
+/*
+ * Following are the states of the Phantom. Phantom will set them and
+ * Host will read to check if the fields are correct.
+ */
+#define PHAN_INITIALIZE_START 0xff00
+#define PHAN_INITIALIZE_FAILED 0x
+#define PHAN_INITIALIZE_COMPLETE 0xff01
+
+/* Host writes the following to notify that it has done the init-handshake */
+#define PHAN_INITIALIZE_ACK0xf00f
+
+#define NUM_RCV_DESC_RINGS 2 /* No of Rcv Descriptor contexts */
+
+/* descriptor types */
+#define RCV_DESC_NORMAL0x01
+#define RCV_DESC_JUMBO 0x02
+#define RCV_DESC_NORMAL_CTXID 0
+#define RCV_DESC_JUMBO_CTXID 1
+
+#define RCV_DESC_TYPE(ID) \
+ ((ID == RCV_DESC_JUMBO_CTXID) ? RCV_DESC_JUMBO : RCV_DESC_NORMAL)
+
+#define MAX_CMD_DESCRIPTORS1024
+#define MAX_RCV_DESCRIPTORS32768
+#define MAX_JUMBO_RCV_DESCRIPTORS 1024
+#define MAX_RCVSTATUS_DESCRIPTORS MAX_RCV_DESCRIPTORS
+#define MAX_JUMBO_RCV_DESC MAX_JUMBO_RCV_DESCRIPTORS
+#define MAX_RCV_DESC MAX_RCV_DESCRIPTORS
+#define MAX_RCVSTATUS_DESC MAX_RCV_DESCRIPTORS
+#define NUM_RCV_DESC (MAX_RCV_DESC + MAX_JUMBO_RCV_DESCRIPTORS)
+#define MAX_EPG_DESCR
[PATCH 2.6.17 5/9] NetXen: ethtool interface
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_ethtool.c
linux-2.6.17/drivers/net/netxen/netxen_nic_ethtool.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_ethtool.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_ethtool.c2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,696 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * ethtool support for netxen nic
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "netxen_nic_hw.h"
+#include "netxen_nic.h"
+#include "netxen_nic_phan_reg.h"
+#include "netxen_nic_ioctl.h"
+
+struct netxen_nic_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int stat_offset;
+};
+
+#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_port *)0)->m), \
+ offsetof(struct netxen_port, m)
+
+static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
+ {"rcvd_bad_skb", NETXEN_NIC_STAT(stats.rcvdbadskb)},
+ {"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
+ {"xmited_frames", NETXEN_NIC_STAT(stats.xmitedframes)},
+ {"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
+ {"bad_skb_len", NETXEN_NIC_STAT(stats.badskblen)},
+ {"no_cmd_desc", NETXEN_NIC_STAT(stats.nocmddescriptor)},
+ {"polled", NETXEN_NIC_STAT(stats.polled)},
+ {"uphappy", NETXEN_NIC_STAT(stats.uphappy)},
+ {"updropped", NETXEN_NIC_STAT(stats.updropped)},
+ {"uplcong", NETXEN_NIC_STAT(stats.uplcong)},
+ {"uphcong", NETXEN_NIC_STAT(stats.uphcong)},
+ {"upmcong", NETXEN_NIC_STAT(stats.upmcong)},
+ {"updunno", NETXEN_NIC_STAT(stats.updunno)},
+ {"skb_freed", NETXEN_NIC_STAT(stats.skbfreed)},
+ {"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
+ {"tx_null_skb", NETXEN_NIC_STAT(stats.txnullskb)},
+ {"csummed", NETXEN_NIC_STAT(stats.csummed)},
+ {"no_rcv", NETXEN_NIC_STAT(stats.no_rcv)},
+ {"rx_bytes", NETXEN_NIC_STAT(stats.rxbytes)},
+ {"tx_bytes", NETXEN_NIC_STAT(stats.txbytes)},
+};
+
+#define NETXEN_NIC_STATS_LEN \
+ sizeof(netxen_nic_gstrings_stats) / sizeof(struct netxen_nic_stats)
+
+static const char netxen_nic_gstrings_test[][ETH_GSTRING_LEN] = {
+ "Register_Test (offline)", "EEPROM_Test(offline)",
+ "Interrupt_Test (offline)", "Loopback_Test (offline)",
+ "Link_Test (on/offline)"
+};
+
+#define NETXEN_NIC_TEST_LEN sizeof(netxen_nic_gstrings_test) / ETH_GSTRING_LEN
+
+#define NETXEN_NIC_REGS_COUNT 42
+#define NETXEN_NIC_REGS_LEN (NETXEN_NIC_REGS_COUNT * sizeof(netxen_crbword_t))
+
+static int netxen_nic_get_eeprom_len(struct net_device *dev)
+{
+ struct netxen_port *port = netdev_priv(dev);
+ struct netxen_adapter *adapter = port->adapter;
+ int n;
+
+ if ((netxen_rom_fast_read(adapter, 0, &n) == 0) && (n & 0x8000)) {
+ n &= ~0x8000;
+ if (n < 1024)
+ return n;
+ }
+ return 0;
+}
+
+static void
+netxen_nic_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo)
+{
+ struct netxen_port *port = netdev_priv(dev);
+
+ strncpy(drvinfo->driver, "NetXen NIC Driver", 32);
+ strncpy(drvinfo->version, NETXEN_NIC_LINUX_VERSIONID, 32);
+ strncpy(drvinfo->fw_version, NETXEN_NIC_FW_VERSIONID, 32);
+ strncpy(drvinfo->bus_info, pci_name(port->pdev), 32);
+ drvinfo->n_stats = NETXEN_NIC_STATS_LEN;
+ drvinfo->testinfo_len = NETXEN_NIC_TEST_LEN;
+ drvinfo->regdump_len = NETXEN_NIC_REGS_LEN;
+ drvinfo->eedump_len = netxen_nic_get_eeprom_len(dev);
+}
+
+static int
+netxen_nic_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+{
+ struct netxen_port *port = netdev_priv(dev);
+ struct netxen_adapter *adapter = port->adapter;
+
+ /* read which mode */
+ if (adapter->ahw.board_ty
[PATCH 2.6.17 4/9] NetXen: intr routines and niu handling
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_isr.c
linux-2.6.17/drivers/net/netxen/netxen_nic_isr.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_isr.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_isr.c2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,301 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ */
+
+#include
+#include
+
+#include "netxen_nic.h"
+#include "netxen_nic_hw.h"
+#include "netxen_nic_phan_reg.h"
+
+/*
+ * netxen_nic_get_stats - Get System Network Statistics
+ * @netdev: network interface device structure
+ */
+struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+ struct net_device_stats *stats = &port->net_stats;
+
+ memset(stats, 0, sizeof(*stats));
+
+ /* total packets received */
+ stats->rx_packets = port->stats.no_rcv;
+ /* total packets transmitted*/
+ stats->tx_packets = port->stats.xmitedframes + port->stats.xmitfinished;
+ /* total bytes received */
+ stats->rx_bytes = port->stats.rxbytes;
+ /* total bytes transmitted */
+ stats->tx_bytes = port->stats.txbytes;
+ /* bad packets received */
+ stats->rx_errors = port->stats.rcvdbadskb;
+ /* packet transmit problems */
+ stats->tx_errors = port->stats.nocmddescriptor;
+ /* no space in linux buffers*/
+ stats->rx_dropped = port->stats.updropped;
+ /* no space available in linux */
+ stats->tx_dropped = port->stats.txdropped;
+
+ return stats;
+}
+
+long netxen_nic_enable_phy_interrupts(struct netxen_adapter *adapter,
+ long portno)
+{
+ long result = 0;
+
+ switch (adapter->ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ result = netxen_niu_gbe_enable_phy_interrupts(adapter, portno);
+ break;
+
+ case NETXEN_NIC_XGBE:
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_INT_MASK, 0x3f);
+ break;
+
+ default:
+ printk(KERN_ERR "%s: Unknown board type\n",
+ netxen_nic_driver_name);
+ result = -1;
+ }
+
+ return result;
+}
+
+long netxen_nic_disable_phy_interrupts(struct netxen_adapter *adapter,
+ long portno)
+{
+ long result = 0;
+
+ switch (adapter->ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ result = netxen_niu_gbe_disable_phy_interrupts(adapter, portno);
+ break;
+
+ case NETXEN_NIC_XGBE:
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_INT_MASK, 0x7f);
+ break;
+
+ default:
+ printk(KERN_ERR "%s: Unknown board type\n",
+ netxen_nic_driver_name);
+ result = -1;
+ }
+
+ return result;
+}
+
+long netxen_nic_clear_phy_interrupts(struct netxen_adapter *adapter,
+long portno)
+{
+ long result = 0;
+
+ switch (adapter->ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ result = netxen_niu_gbe_clear_phy_interrupts(adapter, portno);
+ break;
+
+ case NETXEN_NIC_XGBE:
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_ACTIVE_INT, -1);
+ break;
+
+ default:
+ printk(KERN_ERR "%s: Unknown board type\n",
+ netxen_nic_driver_name);
+ result = -1;
+ }
+
+ return result;
+}
+
+void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 portno,
+u32 link)
+{
+ struct netxen_port *pport = adapter->port[portno];
+ struct net_device *netdev = pport->netdev;
+
+ if (link)
+ netif_carrier_on(netdev);
+ else
+ netif_ca
[PATCH 2.6.17 3/9] NetXen: hw initialization routines
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_init.c
linux-2.6.17/drivers/net/netxen/netxen_nic_init.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_init.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_init.c 2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,1089 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Source file for NIC routines to initialize the Phantom Hardware
+ *
+ */
+
+#include
+#include
+#include "netxen_nic.h"
+#include "netxen_nic_hw.h"
+#include "netxen_nic_ioctl.h"
+#include "netxen_nic_phan_reg.h"
+
+struct crb_addr_pair {
+ long addr;
+ long data;
+};
+
+#define NETXEN_MAX_CRB_XFORM 60
+static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
+#define NETXEN_ADDR_ERROR ((unsigned long ) 0x )
+
+#define crb_addr_transform(name) \
+ crb_addr_xform[NETXEN_HW_PX_MAP_CRB_##name] = \
+ NETXEN_HW_CRB_HUB_AGT_ADR_##name << 20
+
+static void crb_addr_transform_setup(void)
+{
+ crb_addr_transform(XDMA);
+ crb_addr_transform(TIMR);
+ crb_addr_transform(SRE);
+ crb_addr_transform(SQN3);
+ crb_addr_transform(SQN2);
+ crb_addr_transform(SQN1);
+ crb_addr_transform(SQN0);
+ crb_addr_transform(SQS3);
+ crb_addr_transform(SQS2);
+ crb_addr_transform(SQS1);
+ crb_addr_transform(SQS0);
+ crb_addr_transform(RPMX7);
+ crb_addr_transform(RPMX6);
+ crb_addr_transform(RPMX5);
+ crb_addr_transform(RPMX4);
+ crb_addr_transform(RPMX3);
+ crb_addr_transform(RPMX2);
+ crb_addr_transform(RPMX1);
+ crb_addr_transform(RPMX0);
+ crb_addr_transform(ROMUSB);
+ crb_addr_transform(SN);
+ crb_addr_transform(QMN);
+ crb_addr_transform(QMS);
+ crb_addr_transform(PGNI);
+ crb_addr_transform(PGND);
+ crb_addr_transform(PGN3);
+ crb_addr_transform(PGN2);
+ crb_addr_transform(PGN1);
+ crb_addr_transform(PGN0);
+ crb_addr_transform(PGSI);
+ crb_addr_transform(PGSD);
+ crb_addr_transform(PGS3);
+ crb_addr_transform(PGS2);
+ crb_addr_transform(PGS1);
+ crb_addr_transform(PGS0);
+ crb_addr_transform(PS);
+ crb_addr_transform(PH);
+ crb_addr_transform(NIU);
+ crb_addr_transform(I2Q);
+ crb_addr_transform(EG);
+ crb_addr_transform(MN);
+ crb_addr_transform(MS);
+ crb_addr_transform(CAS2);
+ crb_addr_transform(CAS1);
+ crb_addr_transform(CAS0);
+ crb_addr_transform(CAM);
+ crb_addr_transform(C2C1);
+ crb_addr_transform(C2C0);
+}
+
+int netxen_init_firmware(struct netxen_adapter *adapter)
+{
+ u32 state = 0, loops = 0, err = 0;
+
+ /* Window 1 call */
+ state = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+
+ if (state == PHAN_INITIALIZE_ACK)
+ return 0;
+
+ while (state != PHAN_INITIALIZE_COMPLETE && loops < 2000) {
+ udelay(100);
+ /* Window 1 call */
+ state = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+
+ loops++;
+ }
+ if (loops >= 2000) {
+ printk(KERN_ERR "Cmd Peg initialization not complete:%x.\n",
+ state);
+ err = -EIO;
+ return err;
+ }
+ /* Window 1 call */
+ writel(PHAN_INITIALIZE_ACK,
+ NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+
+ return err;
+}
+
+void netxen_initialize_adapter_sw(struct netxen_adapter *adapter)
+{
+ int ctxid, ring;
+ u32 i;
+ u32 num_rx_bufs = 0;
+ struct netxen_rcv_desc_ctx *rcv_desc;
+
+ DPRINTK(INFO, "initializing some queues: %p\n", adapter);
+ for (ctxid = 0; ctxid < MAX_RCV_CTX; ++ctxid) {
+ for (ring = 0; ring < NUM_RCV_DESC_RINGS; ring++) {
+ struct net
[PATCH 2.6.17 2/9] NetXen: Hardware access routines
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.c
linux-2.6.17/drivers/net/netxen/netxen_nic_hw.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_hw.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_hw.c 2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,1102 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Source file for NIC routines to access the Phantom hardware
+ *
+ */
+
+#include "netxen_nic.h"
+#include "netxen_nic_hw.h"
+#include "netxen_nic_phan_reg.h"
+
+/* PCI Windowing for DDR regions. */
+
+#define ADDR_IN_RANGE(addr, low, high) \
+ (((addr) <= (high)) && ((addr) >= (low)))
+
+#define NETXEN_FLASH_BASE (BOOTLD_START)
+#define NETXEN_PHANTOM_MEM_BASE(NETXEN_FLASH_BASE)
+#define NETXEN_MAX_MTU 8000
+#define NETXEN_MTU_MASK0x
+#define NETXEN_WINDOW_ONE 0x200/* CRB Window: bit 25 of CRB address */
+
+unsigned long netxen_nic_pci_set_window(void __iomem * pci_base,
+ unsigned long long addr);
+void netxen_free_hw_resources(struct netxen_adapter *adapter);
+
+int netxen_nic_set_mac(struct net_device *netdev, void *p)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+ struct sockaddr *addr = p;
+
+ if (netif_running(netdev))
+ return -EBUSY;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
+ DPRINTK(INFO, "valid ether addr\n");
+ memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+
+ netxen_nic_macaddr_set(port, addr->sa_data);
+
+ return 0;
+}
+
+/**
+ * netxen_nic_set_multi - Multicast
+ **/
+void netxen_nic_set_multi(struct net_device *netdev)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+ struct dev_mc_list *mc_ptr;
+
+ mc_ptr = netdev->mc_list;
+ if (netdev->flags & IFF_PROMISC)
+ netxen_nic_set_promisc_mode(port);
+ else
+ netxen_nic_unset_promisc_mode(port);
+}
+
+/*
+ * netxen_nic_change_mtu - Change the Maximum Transfer Unit
+ * @returns 0 on success, negative on failure
+ */
+int netxen_nic_change_mtu(struct net_device *netdev, int new_mtu)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+
+ if (new_mtu & NETXEN_MTU_MASK)
+ return -EINVAL;
+
+ if (new_mtu > NETXEN_MAX_MTU) {
+ printk(KERN_ERR
+ "%s: %s MTU > NETXEN_MAX_MTU is not supported\n",
+ netxen_nic_driver_name, netdev->name);
+ return -EINVAL;
+ }
+
+ netxen_nic_set_mtu(port, new_mtu);
+ netdev->mtu = new_mtu;
+
+ return 0;
+}
+
+/*
+ * check if the firmware has been downloaded and ready to run and
+ * setup the address for the descriptors in the adapter
+ */
+int netxen_nic_hw_resources(struct netxen_adapter *adapter)
+{
+ struct netxen_hardware_context *hw = &adapter->ahw;
+ int i;
+ u32 state = 0;
+ void *addr;
+ int loops = 0, err = 0;
+ int ctx, ring;
+ u32 card_cmdring = 0;
+ struct netxen_rcv_desc_crb *rcv_desc_crb = NULL;
+ struct netxen_recv_context *recv_ctx;
+ struct netxen_rcv_desc_ctx *rcv_desc;
+ struct cmd_desc_type0_t *pcmd;
+
+ DPRINTK(INFO, "pci_base: %lx\n", adapter->ahw.pci_base);
+ DPRINTK(INFO, "crb_base: %lx %lx", NETXEN_PCI_CRBSPACE,
+ adapter->ahw.pci_base + NETXEN_PCI_CRBSPACE);
+ DPRINTK(INFO, "cam base: %lx %lx", NETXEN_CRB_CAM,
+ adapter->ahw.pci_base + NETXEN_CRB_CAM);
+ DPRINTK(INFO, "cam RAM: %lx %lx", NETXEN_CAM_RAM_BASE,
+ adapter->ahw.pci_base + NETXEN_CAM_RAM_BASE);
+ DPRINTK(INFO, "NIC base:%lx %lx\n", NIC_CRB_BASE_PORT1,
+ adapter->ahw.pci_base + NIC_CRB_BASE_PORT1);
+
+ /* Window 1 call */
+ card_cmdring = readl(NETXEN_C
[PATCH 2.6.17 1/9] NetXen: Makefile and driver main file
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/MAINTAINERS linux-2.6.17/MAINTAINERS
--- linux-2.6.17.orig/MAINTAINERS 2006-08-30 06:51:57.0 -0700
+++ linux-2.6.17/MAINTAINERS2006-08-30 06:56:27.0 -0700
@@ -1987,6 +1987,13 @@ L: netdev@vger.kernel.org
T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
S: Maintained
+NETXEN (1/10) GbE SUPPORT
+P: Amit S. Kale
+M: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
+W: http://www.netxen.com
+S: Supported
+
IPVS
P: Wensong Zhang
M: [EMAIL PROTECTED]
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/Kconfig linux-2.6.17/drivers/net/Kconfig
--- linux-2.6.17.orig/drivers/net/Kconfig 2006-08-30 06:51:55.0
-0700
+++ linux-2.6.17/drivers/net/Kconfig2006-08-30 06:54:30.0 -0700
@@ -2311,6 +2311,11 @@ config S2IO_NAPI
If in doubt, say N.
+config NETXEN_NIC
+ tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
+ help
+ This enables the support for NetXen's Gigabit Ethernet card.
+
endmenu
source "drivers/net/tokenring/Kconfig"
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/Makefile linux-2.6.17/drivers/net/Makefile
--- linux-2.6.17.orig/drivers/net/Makefile 2006-08-30 06:51:55.0
-0700
+++ linux-2.6.17/drivers/net/Makefile 2006-08-30 06:52:15.0 -0700
@@ -213,3 +213,4 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
obj-$(CONFIG_FS_ENET) += fs_enet/
+obj-$(CONFIG_NETXEN_NIC) += netxen/
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/Makefile
linux-2.6.17/drivers/net/netxen/Makefile
--- linux-2.6.17.orig/drivers/net/netxen/Makefile 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/Makefile2006-08-31 06:17:22.0
-0700
@@ -0,0 +1,35 @@
+# Copyright (C) 2003 - 2006 NetXen, Inc.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+# MA 02111-1307, USA.
+#
+# The full GNU General Public License is included in this distribution
+# in the file called LICENSE.
+#
+# Contact Information:
+#[EMAIL PROTECTED]
+# NetXen,
+# 3965 Freedom Circle, Fourth floor,
+# Santa Clara, CA 95054
+#
+# Makefile for the NetXen NIC Driver
+#
+
+
+obj-$(CONFIG_NETXEN_NIC) := netxen_nic.o
+
+netxen_nic-y := netxen_nic_hw.o netxen_nic_main.o netxen_nic_init.o \
+ netxen_nic_isr.o netxen_nic_ethtool.o netxen_nic_niu.o
diff -Narup -X linux-2.6.17.orig/Documentation/dontdiff
linux-2.6.17.orig/drivers/net/netxen/netxen_nic_main.c
linux-2.6.17/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.17.orig/drivers/net/netxen/netxen_nic_main.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.17/drivers/net/netxen/netxen_nic_main.c 2006-08-31
06:17:22.0 -0700
@@ -0,0 +1,1107 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Main source file for NetXen NIC Driver on Linux
+ *
+ */
+
+#include "netxen_nic_hw.h"
+
+#include "netxen_nic.h"
+#define DEFINE_GLOBAL_RECV_CRB
+#include "netxen_nic_phan_reg.h"
+#include "netxen_nic_ioctl.h"
+
+MODULE_DESCRIPTION("NetXen Multi port (1/10) Gigabit Network Driver");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(NETXEN_NIC
RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates
> My main concern with these patches is that moving the > NetLabel check out > of selinux_socket_sock_rcv_skb() and into > selinux_skb_policy_check() (as > it is currently written) would force us to compare a packet's NetLabel > with either the IPsec label or the secmark label Yes you would do these checks (while using a netlabel based off of the secmark at that point) to enforce flow control and when they succeed, you will copy netlabel into secmark. > and not the socket's > label. The socket Vs. secmark check that happens later in rcv_skb will in fact be looking at the cipso label that is by then a part of the secmark context. > The ability to make access decisions based on the process > consuming the data and the data itself it one of the nicer > qualities of > NetLabel in my opinion. This nicer quality ends up being preserved as explained above :) We just need to get out of the mindset of viewing netlabel separately once we are past the reconciliation point. - 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.6.17 0/9] NetXen: 1G/10G Ethernet Driver
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
Re: [PATCH] WE-21 for bcm43xx (wireless-2.6 git)
On Thu, Aug 31, 2006 at 08:22:22AM -0500, Larry Finger wrote: > John, have you merged, or do you plan to merge, "[PATCH 2.6.18] WE-21 support > (core API)" into > wireless-2.6? I guess that is still up for discussion. It looks like at least part of it is desirable, but maybe not other parts. Perhaps you should post the patch w/o WE-20 support. I'll make sure they all get in at the same time (if at all). John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18] WE-21 support (core API)
On Thu, 2006-08-31 at 06:51 -0700, Jouni Malinen wrote: > I don't know about the others, but long/short retry limits have users > (e.g., Host AP driver) and these drivers are currently forced to use a > hack to do this without this cleanup. Furthermore, this part does not > add a new ioctl. It does, however, add new parameters and things that'd need to be translated in the compat layer later. Hence, even there, I'd prefer to add them directly into nl80211. However, the compat code for that shouldn't be that bad, so I can see that as a softer target :) But I don't want to see new ioctls for sure. 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, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote: > On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: > > o modulation > > o long/short retry > > o relative power saving. > What's the point of adding more ioctls that we'll be implementing them > as wrappers around nl80211? Right now, those new ioctls/options aren't > implemented in *any* driver at all so they're completely useless, and > just add more to the pile of historic baggage we end up carrying around. > If we add these to mainline now, it's another thing we'll have to carry > for a long time even though it currently has no users... I don't know about the others, but long/short retry limits have users (e.g., Host AP driver) and these drivers are currently forced to use a hack to do this without this cleanup. Furthermore, this part does not add a new ioctl. -- Jouni MalinenPGP id EFC895FA - 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 Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: > o modulation > o long/short retry > o relative power saving. I strongly disagree to these. What's the point of adding more ioctls that we'll be implementing them as wrappers around nl80211? Right now, those new ioctls/options aren't implemented in *any* driver at all so they're completely useless, and just add more to the pile of historic baggage we end up carrying around. If we add these to mainline now, it's another thing we'll have to carry for a long time even though it currently has no users... I'd much prefer merging nl80211 and putting any really *new* stuff into it directly. Of course this fragments the user space API for a while since you need to use two APIs then for the time being to configure all things, but we can move over all the rest of the configuration gradually and before we end up in mainline with the new API we can have that finished. Or putting it the other way round, I'm ok with * cleaning up the ssid mess * adding RCPI (we'll probably be using it in nl80211 anyway, so it's easier if we add it now and declare no support for other things) * getting rid of get_wireless_stats (good one!) [actually, I plan to get rid of wireless_handlers too] 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] WE-21 for bcm43xx (wireless-2.6 git)
Michael Buesch wrote: > On Thursday 31 August 2006 02:57, Larry Finger wrote: >> >> +#if WIRELESS_EXT > 20 >> +#define IW_ESSID_FIX0 >> +#else >> +#define IW_ESSID_FIX1 >> +#endif > > Eh, was this useless #if in the original patch I signed-off, too? > Because I want to revert my sign-off. :) > This #if is useless, because we always deal with only one single > WE version in the kernel. #if WIRELESS_EXT will always be true. > So remove this and also remove the other #if below. > Yes, it was. I saw this, but left it in because I cannot control the inclusion of the other patch that brings the NET components up to WE-21, and it seemed that the behavior could be wrong if the kernel were at WE-20. I'm quite certain that the patch will _NOT_ be included in 2.6.18 as it is clearly not a bug fix. Once I see WE-21 in the kernel, I'll remove these #ifdef's and eliminate IW_ESSID_FIX. If I missed something, please let me know, and I'll resubmit the patch now. John, have you merged, or do you plan to merge, "[PATCH 2.6.18] WE-21 support (core API)" into wireless-2.6? Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[TCP]: Fix rcv mss estimate for LRO
Hi Dave:
The Xen performance problem turned out to be something else altogether.
It was an incorrect rcv mss estimate which leads to delayed acks. So
it's not a bug in Linux yet :) However, since we need this for LRO as
well, here's a patch for net-2.6.19.
[TCP]: Fix rcv mss estimate for LRO
By passing a Linux-generated TSO packet straight back into Linux, Xen
becomes our first LRO user :) Unfortunately, there is at least one spot
in our stack that needs to be changed to cope with this.
The receive MSS estimate is computed from the raw packet size. This is
broken if the packet is GSO/LRO. Fortunately the real MSS can be found
in gso_size so we simply need to use that if it is non-zero.
Real LRO NICs should of course set the gso_size field in future.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 104af5d..1fa1536 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -127,7 +127,7 @@ static void tcp_measure_rcv_mss(struct s
/* skb->len may jitter because of SACKs, even if peer
* sends good full-sized frames.
*/
- len = skb->len;
+ len = skb_shinfo(skb)->gso_size ?: skb->len;
if (len >= icsk->icsk_ack.rcv_mss) {
icsk->icsk_ack.rcv_mss = len;
} else {
-
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] drivers/net/{ne,smc-ultra}.c: Avoid compilation warnings by registering init and exit functions
This patch is against 2.6.17-11.
1) Meant to get rid of the following compilation warnings
WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text:
from .text between 'init_module' (at offset 0xeb) and 'ne_close'
WARNING: drivers/net/smc-ultra.o - Section mismatch: reference to
.init.data:ultra_portlist from .text between 'init_module' (at offset 0xa4) and
'ultra_close_card'
2) Isn't the registration of a module's __init and __exit functions while
making them
static much encouraged in 2.6? I followed the Linux Device Drivers book.
Signed-off-by: Shaul Karl <[EMAIL PROTECTED]>
---
drivers/net/ne.c|8 ++--
drivers/net/smc-ultra.c | 10 ++
2 files changed, 12 insertions(+), 6 deletions(-)
--- linux-source-2.6.17/drivers/net/ne.c.orig 2006-08-29 14:55:59.0
+0300
+++ linux-source-2.6.17/drivers/net/ne.c2006-08-29 18:27:13.0
+0300
@@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
is at boot) and so the probe will get confused by any other 8390 cards.
ISA device autoprobes on a running machine are not recommended anyway. */
-int init_module(void)
+static int __init init_ne_module(void)
{
int this_dev, found = 0;
@@ -867,7 +867,7 @@ static void cleanup_card(struct net_devi
release_region(dev->base_addr, NE_IO_EXTENT);
}
-void cleanup_module(void)
+static void __exit cleanup_ne_module(void)
{
int this_dev;
@@ -880,4 +880,8 @@ void cleanup_module(void)
}
}
}
+
+module_init(init_ne_module);
+module_exit(cleanup_ne_module);
+
#endif /* MODULE */
--- linux-source-2.6.17/drivers/net/smc-ultra.c.orig2006-08-29
15:03:33.0 +0300
+++ linux-source-2.6.17/drivers/net/smc-ultra.c 2006-08-29 18:29:53.0
+0300
@@ -553,8 +553,7 @@ MODULE_LICENSE("GPL");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
-int
-init_module(void)
+static int __init init_smcUltra_module(void)
{
struct net_device *dev;
int this_dev, found = 0;
@@ -594,8 +593,7 @@ static void cleanup_card(struct net_devi
iounmap(ei_status.mem);
}
-void
-cleanup_module(void)
+static void __exit cleanup_smcUltra_module(void)
{
int this_dev;
@@ -608,4 +606,8 @@ cleanup_module(void)
}
}
}
+
+module_init(init_smcUltra_module);
+module_exit(cleanup_smcUltra_module);
+
#endif /* MODULE */
-
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 for bcm43xx (wireless-2.6 git)
Jean, > This is the version of the patch for out-of-tree, I guess you > will need it. Not tested. We don't, neither softmac nor bcm43xx is maintained out-of-tree any more. 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] WE-21 for bcm43xx (wireless-2.6 git)
On Thursday 31 August 2006 02:57, Larry Finger wrote:
> John,
>
> Please apply Jean's patch to wireless-2.6. It should apply cleanly to the
> version you pushed earlier
> today (8/30). I have compiled and tested. For complete operation with WE-21,
> it also needs the patch
> entitled [PATCH 2.6.18] WE-21 support (core API) at
> (http://www.spinics.net/lists/netdev/msg13599.html). It works without that
> second patch, just at WE-20.
>
> Thanks,
>
> Larry
>
> ---
>
> Patch to update bcm43xx-SoftMAC for WE-21.
>
> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
>
> -
>
> diff -u a/net/ieee80211/softmac/ieee80211softmac_wx.c
> b/net/ieee80211/softmac/ieee80211softmac_wx.c
> --- a/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-08-29
> 14:45:56.0 -0700
> +++ b/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-08-30
> 14:56:35.0 -0700
> @@ -63,6 +63,12 @@ ieee80211softmac_wx_get_scan_results(str
> }
> EXPORT_SYMBOL_GPL(ieee80211softmac_wx_get_scan_results);
>
> +#if WIRELESS_EXT > 20
> +#define IW_ESSID_FIX 0
> +#else
> +#define IW_ESSID_FIX 1
> +#endif
Eh, was this useless #if in the original patch I signed-off, too?
Because I want to revert my sign-off. :)
This #if is useless, because we always deal with only one single
WE version in the kernel. #if WIRELESS_EXT will always be true.
So remove this and also remove the other #if below.
> int
> ieee80211softmac_wx_set_essid(struct net_device *net_dev,
> struct iw_request_info *info,
> @@ -80,10 +86,10 @@ ieee80211softmac_wx_set_essid(struct net
>* If it's our network, ignore the change, we're already doing it!
>*/
> if((sm->associnfo.associating || sm->associated) &&
> -(data->essid.flags && data->essid.length && extra)) {
> +(data->essid.flags && data->essid.length)) {
> /* Get the associating network */
> n = ieee80211softmac_get_network_by_bssid(sm,
> sm->associnfo.bssid);
> - if(n && n->essid.len == (data->essid.length - 1) &&
> + if(n && n->essid.len == (data->essid.length - IW_ESSID_FIX) &&
> !memcmp(n->essid.data, extra, n->essid.len)) {
> dprintk(KERN_INFO PFX "Already associating or
> associated to "MAC_FMT"\n",
> MAC_ARG(sm->associnfo.bssid));
> @@ -109,8 +115,8 @@ ieee80211softmac_wx_set_essid(struct net
> sm->associnfo.static_essid = 0;
> sm->associnfo.assoc_wait = 0;
>
> - if (data->essid.flags && data->essid.length && extra /*required?*/) {
> - length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
> + if (data->essid.flags && data->essid.length) {
> + length = min((int) data->essid.length - IW_ESSID_FIX,
> IW_ESSID_MAX_SIZE);
> if (length) {
> memcpy(sm->associnfo.req_essid.data, extra, length);
> sm->associnfo.static_essid = 1;
> diff -u a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c 2006-08-29
> 14:46:08.0 -0700
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c 2006-08-30
> 14:57:31.0 -0700
> @@ -334,7 +334,11 @@ static int bcm43xx_wx_get_nick(struct ne
> size_t len;
>
> mutex_lock(&bcm->mutex);
> +#if WIRELESS_EXT > 20
> + len = strlen(bcm->nick);
> +#else
> len = strlen(bcm->nick) + 1;
> +#endif
> memcpy(extra, bcm->nick, len);
> data->data.length = (__u16)len;
> data->data.flags = 1;
>
> ===
>
>
--
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
dropping [EMAIL PROTECTED]
As there were no real objections, I will be dropping this list shortly. No real traffic here anyway. Please use netdev until (if ever) we have a wireless-specific list. 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
