* Re: [patch] add net_device_stats support to ethtool
From: Ben Greear @ 2008-01-16 18:46 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: netdev
In-Reply-To: <200801161834.m0GIYCIr027613@sallyv1.ics.uci.edu>
Dan Nicolaescu wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
> > Dan Nicolaescu wrote:
> > > Hi,
> > >
> > > I have posted this patch in the past with absolutely no reply.
> > > I would appreciate some sort of feedback of the form interested/not
> > > interested. Should I just drop it?
> > >
> > >
> > I like it, but why not offer this for all devices since they all have
> > these stats.
> >
> > Could add new handlers called something like .get_strings_generic, or
> > just add this to the higher-level ethtool handling before it looks for
> > handlers.
>
> If I get your point, then the difference would be that drivers would add
> to the initialization of the ethtool structure something like:
>
I meant something more like this (this will not apply..I hand-edited it
to remove
some extraneous crap from my patch...and I'm sure it's white-space damaged).
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c5e0593..095d1eb 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
+/* Handle some generic ethtool commands here */
+static int ethtool_get_netdev_stats(struct net_device *dev, void
*useraddr) {
+
+ struct ethtool_ndstats* nds = (struct ethtool_ndstats*)(useraddr);
+
+ struct net_device_stats *stats = dev->get_stats(dev);
+ if (stats) {
+ if (copy_to_user(nds->data, stats, sizeof(*stats))) {
+ return -EFAULT;
+ }
+ }
+ else {
+ return -EOPNOTSUPP;
+ }
+ return 0;
+}
+
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct ifreq *ifr)
@@ -796,9 +884,6 @@ int dev_ethtool(struct ifreq *ifr)
if (!dev || !netif_device_present(dev))
return -ENODEV;
- if (!dev->ethtool_ops)
- return -EOPNOTSUPP;
-
if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd)))
return -EFAULT;
@@ -823,12 +908,25 @@ int dev_ethtool(struct ifreq *ifr)
return -EPERM;
}
- if (dev->ethtool_ops->begin)
+ if (dev->ethtool_ops && dev->ethtool_ops->begin)
if ((rc = dev->ethtool_ops->begin(dev)) < 0)
return rc;
old_features = dev->features;
+ /* Handle some generic operations that do not require specific
+ * ethtool handlers.
+ */
+ switch (ethcmd) {
+ case ETHTOOL_GNDSTATS:
+ return ethtool_get_netdev_stats(dev, useraddr);
+ default:
+ break;
+ }
+
+ if (!dev->ethtool_ops)
+ return -EOPNOTSUPP;
+
switch (ethcmd) {
case ETHTOOL_GSET:
rc = ethtool_get_settings(dev, useraddr);
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [Bugme-new] [Bug 9758] New: net_device refcnt bug when NFQUEUEing bridged packets
From: Stephen Hemminger @ 2008-01-16 18:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <478D8F29.5040703@trash.net>
On Wed, 16 Jan 2008 05:59:21 +0100
Patrick McHardy <kaber@trash.net> wrote:
> Patrick McHardy wrote:
> > Very nice catch, that explains quite a few bug reports about
> > refcnt leaks. Your patch looks correct and performs the copying
> > in the logically correct place, it would be nicer to keep this
> > crap limited to bridge netfilter however.
> >
> > What should work is to perform the copying in br_netfilter.c
> > at the spots where phsyoutdev is assigned. As an optimization
> > we should be able to avoid the copying in most cases by
> > checking that the bridge info has a refcount above 1.
> >
> > Could you test whether this patch also fixes the problem?
>
>
> That patch had a bug, we need to set the refcount of the
> new bridge info to 1 after performing the copy.
>
This looks good, but you could use a structure assignment rather memcpy
(just a personal style preference because assignment is typed and memcpy
is not).
^ permalink raw reply
* Re: memory leakage in bridge(kernel-2.6.23.14)
From: Stephen Hemminger @ 2008-01-16 19:04 UTC (permalink / raw)
To: wyb; +Cc: netdev
In-Reply-To: <200801161006.AZZ53966@topsec.com.cn>
On Wed, 16 Jan 2008 18:04:53 +0800
<wyb@topsec.com.cn> wrote:
>
> In SMP, if a bridge fdb is being created when another CPU at the same time
> delete the bridge, this newly created fdb may incur a leakage:
>
> CPU0:
>
> static void del_nbp(struct net_bridge_port *p)
> {
> /*
> * CPU1 enter br_fdb_update(), bridge port is still valid.
> */
> ......
> spin_lock_bh(&br->lock);
> br_stp_disable_port(p);
> spin_unlock_bh(&br->lock);
>
> br_ifinfo_notify(RTM_DELLINK, p);
>
> br_fdb_delete_by_port(br, p, 1);
>
> /*
> * CPU1 call fdb_create() for the being deleted bridge,
> * a fdb would be add to bridge's fdb hash table, and will never
> * be freed. because when deleting a bridge, linux flush fdb for
> each
> * bridge port, but this newly created fdb belong to no bridge port
> */
> ......
> }
>
> To fix this, fdb_create() should be changed to:
> {
> struct net_bridge_fdb_entry *fdb;
>
> /*
> * if the bridge port is deleted, then return.
> */
> if (!(source->state == BR_STATE_LEARNING ||
> source->state == BR_STATE_FORWARDING))
> return;
>
> fdb = kmem_cache_alloc(br_fdb_cache, GFP_ATOMIC);
> if (fdb) {
> memcpy(fdb->addr.addr, addr, ETH_ALEN);
> atomic_set(&fdb->use_count, 1);
> hlist_add_head_rcu(&fdb->hlist, head);
>
> fdb->dst = source;
> fdb->is_local = is_local;
> fdb->is_static = is_local;
> fdb->ageing_timer = jiffies;
> }
> return fdb;
> }
>
That check is not enough, since the state might change during
fdb_create.
I think fdb_delete_by_port needs to be moved after RCU barrier event.
Something like this (untested) patch.
--- a/net/bridge/br_if.c 2008-01-16 11:00:09.000000000 -0800
+++ b/net/bridge/br_if.c 2008-01-16 11:01:11.000000000 -0800
@@ -116,6 +116,9 @@ static void destroy_nbp_rcu(struct rcu_h
{
struct net_bridge_port *p =
container_of(head, struct net_bridge_port, rcu);
+
+ br_fdb_delete_by_port(p->br, p, 1);
+
destroy_nbp(p);
}
@@ -143,8 +146,6 @@ static void del_nbp(struct net_bridge_po
br_ifinfo_notify(RTM_DELLINK, p);
- br_fdb_delete_by_port(br, p, 1);
-
list_del_rcu(&p->list);
rcu_assign_pointer(dev->br_port, NULL);
^ permalink raw reply
* Re: SO_RCVBUF doesn't change receiver advertised window
From: Ritesh Kumar @ 2008-01-16 19:27 UTC (permalink / raw)
To: Bill Fink; +Cc: netdev
In-Reply-To: <20080116045026.eb62287a.billfink@mindspring.com>
On 1/16/08, Bill Fink <billfink@mindspring.com> wrote:
> On Tue, 15 Jan 2008, Ritesh Kumar wrote:
>
> > Hi,
> > I am using linux 2.6.20 and am trying to limit the receiver window
> > size for a TCP connection. However, it seems that auto tuning is not
> > turning itself off even after I use the syscall
> >
> > rwin=65536
> > setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, sizeof(rwin));
> >
> > and verify using
> >
> > getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, &rwin_size);
> >
> > that RCVBUF indeed is getting set (the value returned from getsockopt
> > is double that, 131072).
>
> Linux doubles what you requested, and then uses (by default) 1/4
> of the socket space for overhead, so you effectively get 1.5 times
> what you requested as an actual advertised receiver window, which
> means since you specified 64 KB, you actually get 96 KB.
>
> > The above calls are made before connect() on the client side and
> > before bind(), accept() on the server side. Bulk data is being sent
> > from the client to the server. The client and the server machines also
> > have tcp_moderate_rcvbuf set to 0 (though I don't think that's really
> > needed; setting a value to SO_RCVBUF should automatically turnoff auto
> > tuning.).
> >
> > However the tcp trace shows the SYN, SYN/ACK and the first few packets as:
> > 14:34:18.831703 IP 192.168.1.153.45038 > 192.168.2.204.9999: S
> > 3947298186:3947298186(0) win 5840 <mss 1460,sackOK,timestamp 2842625
> > 0,nop,wscale 5>
> > 14:34:18.836000 IP 192.168.2.204.9999 > 192.168.1.153.45038: S
> > 3955381015:3955381015(0) ack 3947298187 win 5792 <mss
> > 1460,sackOK,timestamp 2843649 2842625,nop,wscale 2>
> > 14:34:18.837654 IP 192.168.1.153.45038 > 192.168.2.204.9999: . ack 1
> > win 183 <nop,nop,timestamp 2842634 2843649>
> > 14:34:18.837849 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> > 1:1449(1448) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
> > 14:34:18.837851 IP 192.168.1.153.45038 > 192.168.2.204.9999: P
> > 1449:1461(12) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
> > 14:34:18.839001 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> > 1449 win 2172 <nop,nop,timestamp 2843652 2842634>
> > 14:34:18.839011 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> > 1461 win 2172 <nop,nop,timestamp 2843652 2842634>
> > 14:34:18.840875 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> > 1461:2909(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> > 14:34:18.840997 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> > 2909:4357(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> > 14:34:18.841120 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> > 4357:5805(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> > 14:34:18.841244 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> > 5805:7253(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> > 14:34:18.841388 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> > 2909 win 2896 <nop,nop,timestamp 2843655 2842637>
> > 14:34:18.841399 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> > 4357 win 3620 <nop,nop,timestamp 2843655 2842637>
> > 14:34:18.841413 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> > 5805 win 4344 <nop,nop,timestamp 2843655 2842637>
> >
> > As you can see, the syn and syn ack show rcv windows to be 5840 and
> > 5792 and it automatically increases for the receiver to values 2172
> > till 4344 and more in the later part of the trace till 24214.
>
> Since the window scale was 2, the final advertised receiver window
> you indicate of 24214 gives 2^2*24214 or right around 96 KB, which
> is what is expected given the way Linux works.
>
> -Bill
Thanks for the explanation Bill. That surely clears part of my doubt.
However, why doesn't linux advertise 24214 in the SYN packets? I was
hoping that the moment I setup a RCVBUF, linux would pre-allocate
buffers and drop any autotuning. Doesn't the above behavior count as
autotuning?
Ritesh
^ permalink raw reply
* Re: SO_RCVBUF doesn't change receiver advertised window
From: John Heffner @ 2008-01-16 19:42 UTC (permalink / raw)
To: Ritesh Kumar; +Cc: Bill Fink, netdev
In-Reply-To: <f47983b00801161127u5fa4de0bgf53bb3b8fc57a3c7@mail.gmail.com>
Ritesh Kumar wrote:
> On 1/16/08, Bill Fink <billfink@mindspring.com> wrote:
>> On Tue, 15 Jan 2008, Ritesh Kumar wrote:
>>
>>> Hi,
>>> I am using linux 2.6.20 and am trying to limit the receiver window
>>> size for a TCP connection. However, it seems that auto tuning is not
>>> turning itself off even after I use the syscall
>>>
>>> rwin=65536
>>> setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, sizeof(rwin));
>>>
>>> and verify using
>>>
>>> getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, &rwin_size);
>>>
>>> that RCVBUF indeed is getting set (the value returned from getsockopt
>>> is double that, 131072).
>> Linux doubles what you requested, and then uses (by default) 1/4
>> of the socket space for overhead, so you effectively get 1.5 times
>> what you requested as an actual advertised receiver window, which
>> means since you specified 64 KB, you actually get 96 KB.
>>
>>> The above calls are made before connect() on the client side and
>>> before bind(), accept() on the server side. Bulk data is being sent
>>> from the client to the server. The client and the server machines also
>>> have tcp_moderate_rcvbuf set to 0 (though I don't think that's really
>>> needed; setting a value to SO_RCVBUF should automatically turnoff auto
>>> tuning.).
>>>
>>> However the tcp trace shows the SYN, SYN/ACK and the first few packets as:
>>> 14:34:18.831703 IP 192.168.1.153.45038 > 192.168.2.204.9999: S
>>> 3947298186:3947298186(0) win 5840 <mss 1460,sackOK,timestamp 2842625
>>> 0,nop,wscale 5>
>>> 14:34:18.836000 IP 192.168.2.204.9999 > 192.168.1.153.45038: S
>>> 3955381015:3955381015(0) ack 3947298187 win 5792 <mss
>>> 1460,sackOK,timestamp 2843649 2842625,nop,wscale 2>
>>> 14:34:18.837654 IP 192.168.1.153.45038 > 192.168.2.204.9999: . ack 1
>>> win 183 <nop,nop,timestamp 2842634 2843649>
>>> 14:34:18.837849 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
>>> 1:1449(1448) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
>>> 14:34:18.837851 IP 192.168.1.153.45038 > 192.168.2.204.9999: P
>>> 1449:1461(12) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
>>> 14:34:18.839001 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
>>> 1449 win 2172 <nop,nop,timestamp 2843652 2842634>
>>> 14:34:18.839011 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
>>> 1461 win 2172 <nop,nop,timestamp 2843652 2842634>
>>> 14:34:18.840875 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
>>> 1461:2909(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
>>> 14:34:18.840997 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
>>> 2909:4357(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
>>> 14:34:18.841120 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
>>> 4357:5805(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
>>> 14:34:18.841244 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
>>> 5805:7253(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
>>> 14:34:18.841388 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
>>> 2909 win 2896 <nop,nop,timestamp 2843655 2842637>
>>> 14:34:18.841399 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
>>> 4357 win 3620 <nop,nop,timestamp 2843655 2842637>
>>> 14:34:18.841413 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
>>> 5805 win 4344 <nop,nop,timestamp 2843655 2842637>
>>>
>>> As you can see, the syn and syn ack show rcv windows to be 5840 and
>>> 5792 and it automatically increases for the receiver to values 2172
>>> till 4344 and more in the later part of the trace till 24214.
>> Since the window scale was 2, the final advertised receiver window
>> you indicate of 24214 gives 2^2*24214 or right around 96 KB, which
>> is what is expected given the way Linux works.
>>
>> -Bill
>
> Thanks for the explanation Bill. That surely clears part of my doubt.
> However, why doesn't linux advertise 24214 in the SYN packets? I was
> hoping that the moment I setup a RCVBUF, linux would pre-allocate
> buffers and drop any autotuning. Doesn't the above behavior count as
> autotuning?
Linux also starts all connections with a small advertised window. It
only grows the window after observing the ratio of data to overhead in
received packets. If it receives only small packets from the sender
with a high overhead ratio, it will only open the window just far enough
that it doesn't overflow the receive buffer. This algorithm (look for
rcv_ssthresh in the code) controls the advertised window given a receive
buffer size. This is separate from autotuning, which adjusts the buffer
size. You're correct that autotuning is disabled when SO_RCVBUF is set,
but the "receive slow-start" is always used.
-John
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Willy Tarreau @ 2008-01-16 20:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Herbert Xu, cfriesen, davem, netdev, linux-kernel
In-Reply-To: <20080116065836.GA1638@ff.dom.local>
On Wed, Jan 16, 2008 at 07:58:36AM +0100, Jarek Poplawski wrote:
> On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
> ...
> > Well people are always going to operate on this model for commercial
> > reasons. FWIW I used to work for a company that stuck to a specific
> > version of the Linux kernel, and I suppose I still do even now :)
> >
> > But the important thing is that if you're going to do that, then the
> > cost that comes with it should be borne by the company and not the
> > community.
>
> Sure. But the most sad thing is there seems to be not so much savings
> in this (unless a company isn't sure of its near future). Trying to
> upgrade and test current products with current kernels, even if not
> necessary, should be always useful and make developing of new products
> faster and better fit (and of course, BTW, make the kernel better on
> time).
you can work with latest release provided that you always have a fallback
to an earlier one. That way, you don't bet too much on something you don't
completely control. If it works, it tells you you'll be able to completely
exploit its new possibilities in next product release, and if it breaks,
it's easy to issue a fix to get back to earlier, well-tested version.
Regards,
Willy
^ permalink raw reply
* Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville @ 2008-01-16 21:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Dave,
One more fix for rfkill in 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
---
The following changes since commit cbd9c883696da72b2b1f03f909dbacc04bbf8b58:
Linus Torvalds (1):
Linux 2.6.24-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
Eric Paris (1):
rfkill: call rfkill_led_trigger_unregister() on error
net/rfkill/rfkill.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index 4469a7b..d06d338 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -392,11 +392,14 @@ int rfkill_register(struct rfkill *rfkill)
rfkill_led_trigger_register(rfkill);
error = rfkill_add_switch(rfkill);
- if (error)
+ if (error) {
+ rfkill_led_trigger_unregister(rfkill);
return error;
+ }
error = device_add(dev);
if (error) {
+ rfkill_led_trigger_unregister(rfkill);
rfkill_remove_switch(rfkill);
return error;
}
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-16 21:27 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
A few more fixes for 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit cbd9c883696da72b2b1f03f909dbacc04bbf8b58:
Linus Torvalds (1):
Linux 2.6.24-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Ivo van Doorn (1):
rt2x00: Fix ieee80211 payload alignment
Marc Pignat (1):
wireless/libertas support for 88w8385 sdio older revision
Randy Dunlap (1):
hostap: section mismatch warning
Stefano Brivio (2):
ipw2200: fix typo in kerneldoc
b43: fix use-after-free rfkill bug
drivers/net/wireless/b43/rfkill.c | 11 ++++++-----
drivers/net/wireless/hostap/hostap_plx.c | 6 +++---
drivers/net/wireless/ipw2200.c | 2 +-
drivers/net/wireless/libertas/if_sdio.c | 4 ++++
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 11 +++++++++--
6 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
index 98cf70c..11f53cb 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -138,8 +138,11 @@ void b43_rfkill_init(struct b43_wldev *dev)
rfk->rfkill->user_claim_unsupported = 1;
rfk->poll_dev = input_allocate_polled_device();
- if (!rfk->poll_dev)
- goto err_free_rfk;
+ if (!rfk->poll_dev) {
+ rfkill_free(rfk->rfkill);
+ goto err_freed_rfk;
+ }
+
rfk->poll_dev->private = dev;
rfk->poll_dev->poll = b43_rfkill_poll;
rfk->poll_dev->poll_interval = 1000; /* msecs */
@@ -175,8 +178,7 @@ err_unreg_rfk:
err_free_polldev:
input_free_polled_device(rfk->poll_dev);
rfk->poll_dev = NULL;
-err_free_rfk:
- rfkill_free(rfk->rfkill);
+err_freed_rfk:
rfk->rfkill = NULL;
out_error:
rfk->registered = 0;
@@ -195,6 +197,5 @@ void b43_rfkill_exit(struct b43_wldev *dev)
rfkill_unregister(rfk->rfkill);
input_free_polled_device(rfk->poll_dev);
rfk->poll_dev = NULL;
- rfkill_free(rfk->rfkill);
rfk->rfkill = NULL;
}
diff --git a/drivers/net/wireless/hostap/hostap_plx.c b/drivers/net/wireless/hostap/hostap_plx.c
index 040dc3e..cbf15d7 100644
--- a/drivers/net/wireless/hostap/hostap_plx.c
+++ b/drivers/net/wireless/hostap/hostap_plx.c
@@ -608,7 +608,7 @@ static void prism2_plx_remove(struct pci_dev *pdev)
MODULE_DEVICE_TABLE(pci, prism2_plx_id_table);
-static struct pci_driver prism2_plx_drv_id = {
+static struct pci_driver prism2_plx_driver = {
.name = "hostap_plx",
.id_table = prism2_plx_id_table,
.probe = prism2_plx_probe,
@@ -618,13 +618,13 @@ static struct pci_driver prism2_plx_drv_id = {
static int __init init_prism2_plx(void)
{
- return pci_register_driver(&prism2_plx_drv_id);
+ return pci_register_driver(&prism2_plx_driver);
}
static void __exit exit_prism2_plx(void)
{
- pci_unregister_driver(&prism2_plx_drv_id);
+ pci_unregister_driver(&prism2_plx_driver);
}
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 88062c1..003f73f 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -4935,7 +4935,7 @@ static int ipw_queue_reset(struct ipw_priv *priv)
/**
* Reclaim Tx queue entries no more used by NIC.
*
- * When FW adwances 'R' index, all entries between old and
+ * When FW advances 'R' index, all entries between old and
* new 'R' index need to be reclaimed. As result, some free space
* forms. If there is enough free space (> low mark), wake Tx queue.
*
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index b24425f..4f1efb1 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -871,6 +871,10 @@ static int if_sdio_probe(struct sdio_func *func,
if (sscanf(func->card->info[i],
"ID: %x", &model) == 1)
break;
+ if (!strcmp(func->card->info[i], "IBIS Wireless SDIO Card")) {
+ model = 4;
+ break;
+ }
}
if (i == func->card->num_info) {
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 6d5d9ab..04663eb 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -149,7 +149,7 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
* The data behind the ieee80211 header must be
* aligned on a 4 byte boundary.
*/
- align = NET_IP_ALIGN + (2 * (header_size % 4 == 0));
+ align = header_size % 4;
/*
* Allocate the sk_buffer, initialize it and copy
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index ab4797e..568d738 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -245,13 +245,20 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
* Allocate a new sk buffer to replace the current one.
* If allocation fails, we should drop the current frame
* so we can recycle the existing sk buffer for the new frame.
+ * As alignment we use 2 and not NET_IP_ALIGN because we need
+ * to be sure we have 2 bytes room in the head. (NET_IP_ALIGN
+ * can be 0 on some hardware). We use these 2 bytes for frame
+ * alignment later, we assume that the chance that
+ * header_size % 4 == 2 is bigger then header_size % 2 == 0
+ * and thus optimize alignment by reserving the 2 bytes in
+ * advance.
*/
frame_size = entry->ring->data_size + entry->ring->desc_size;
- skb = dev_alloc_skb(frame_size + NET_IP_ALIGN);
+ skb = dev_alloc_skb(frame_size + 2);
if (!skb)
goto skip_entry;
- skb_reserve(skb, NET_IP_ALIGN);
+ skb_reserve(skb, 2);
skb_put(skb, frame_size);
/*
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* sctp use-uninitialized warning in net-2.6.25
From: Andrew Morton @ 2008-01-16 21:59 UTC (permalink / raw)
To: netdev
net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this function
It is not obvious that this is a false positive.
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Jarek Poplawski @ 2008-01-16 22:42 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, cfriesen, davem, netdev, linux-kernel
In-Reply-To: <20080116200458.GC8953@1wt.eu>
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
> you can work with latest release provided that you always have a fallback
> to an earlier one. That way, you don't bet too much on something you don't
> completely control. If it works, it tells you you'll be able to completely
> exploit its new possibilities in next product release, and if it breaks,
> it's easy to issue a fix to get back to earlier, well-tested version.
Of course, this way looks preferable, but sometimes maybe too costly,
especially with some complex systems. Actually, I don't even think
this have to be fully (production ready) implemented or workable.
Probably there would be even enough to maintain some simplified kind
of test checking how current kernel changes could affect such a system,
and how new versions of this system are better, BTW.
Regards,
Jarek P.
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-16 22:58 UTC (permalink / raw)
To: hadi; +Cc: timo.teras, netdev
In-Reply-To: <1200491531.4457.91.camel@localhost>
jamal <hadi@cyberus.ca> wrote:
>
> There are two issues that are inter-mingled in there. The most important
> is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither is portable. So we
should discourage people from using af_key wherever possible.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Herbert Xu @ 2008-01-16 23:17 UTC (permalink / raw)
To: David Stevens; +Cc: herbert, davem, netdev, wangchen
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens <dlstevens@us.ibm.com> wrote:
>
> The patch was to support the ICMPMsgStats table. Since none of
> certain
> types of output ICMP messages are generated by the kernel, but are
> required
> by the RFC, counting raw sockets is intentional (and the only way those
> ICMP
> types can be counted at all).
> Raw UDP packets would not be counted either before or after the
> patch,
> but aren't part of the ICMPMsgStats table. Adding those might be
> worthwhile,
> but it isn't quite the hole that the ICMP out stats were, since there is a
> cooked interface for UDP output that counts the common use, at least.
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: David Stevens @ 2008-01-17 0:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, herbert, netdev, netdev-owner, wangchen
In-Reply-To: <E1JFHVh-00012A-00@gondolin.me.apana.org.au>
netdev-owner@vger.kernel.org wrote on 01/16/2008 03:17:29 PM:
> Fair enough. How about moving this code back into icmp.c and just
> add a new count call in raw.c? The push pending function is used on
> the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly wasn't
cleaner. You have to peek on the queue, which I didn't
want to do for all the SMP issues that brings in, and
then replicate all the code push_pending_frames does to
get you a protocol header pointer in one buffer, and there
are multiple ways in the raw path to get you there (so the
counter code itself would appear in multiple places).
I don't think the 2 instructions measurably impact
anything in the fast path and that is the earliest common
point for the multiple paths to generate ICMP output where
the header and type are available without replicating code.
So, simplicity is exactly why I put it there, rather than
the "obvious" places at the higher layer. :-) It's probably
the better, single place to put the other protocol "out messages"
counters, too, since those probably also have multiple paths
that end up here, but ICMPMsgStats was all that patch was
after.
+-DLS
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Wang Chen @ 2008-01-17 0:55 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, davem, netdev
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens said the following on 2008-1-17 0:23:
> Wang,
> I think your patch is correct; did you test the same case for
> IPv6?
>
I've tested IPv4, but IPv6 not yet.
If Davem accept this one, I will see the IPv6, or you take care of it.
--
WCN
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:25 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <478E1479.3020204@iki.fi>
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent across all netlink
not just ipsec. Thats why i said it had broader implications.
OTOH, theres a clear issue with pf_key.
> No. I'm not creating second copies of the SADB/SPD entries. The entries
> are just added to one more list.
Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list?
Also what happens on modification?
> If more entries are added, you can get notifications of them.
how would a user app (example racoon) appropriately deal with it?
Example an entry sits in the dump-list, it gets deleted - an event gets
generated user-space and later that entry shows up in user space dump.
cheers,
jamal
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: timo.teras, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like racoon which depend on pfkey
are unfortunately beyond repair. Timo has a pretty good handle on the
issue from what i have seen so far, so it pretty much seems to be there
without significant changes (if the two issues are separated).
cheers,
jamal
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-17 2:17 UTC (permalink / raw)
To: jamal; +Cc: timo.teras, netdev
In-Reply-To: <1200533980.4451.100.camel@localhost>
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>
> I wouldnt disagree except some apps like racoon which depend on pfkey
> are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [patch] add net_device_stats support to ethtool
From: Dan Nicolaescu @ 2008-01-17 5:13 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <478E5122.1060009@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> Dan Nicolaescu wrote:
> > Ben Greear <greearb@candelatech.com> writes:
> >
> > > Dan Nicolaescu wrote:
> > > > Hi,
> > > >
> > > > I have posted this patch in the past with absolutely no reply.
> > > > I would appreciate some sort of feedback of the form interested/not
> > > > interested. Should I just drop it?
> > > >
> > > > > I like it, but why not offer this for all devices since
> > they all have
> > > these stats.
> > >
> > > Could add new handlers called something like .get_strings_generic, or
> > > just add this to the higher-level ethtool handling before it looks for
> > > handlers.
> >
> > If I get your point, then the difference would be that drivers would add
> > to the initialization of the ethtool structure something like:
> >
> I meant something more like this (this will not apply..I hand-edited
> it to remove
> some extraneous crap from my patch...and I'm sure it's white-space damaged).
OK.
Hopefully someone can pick up these patches to be merged...
^ permalink raw reply
* Re: [PATCH 3/4] bonding: Fix work rearming
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116133646.GE2307@ff.dom.local>
> But, since during this change from sysfs cancel_delayed_work_sync()
> could be probably used, and it's rather efficient with killing
> rearming works, it seems this check could be unnecessary yet.
What going to be cancelled in bonding_store_miimon() when setting miimon to 0
is arp monitor, not mii monitor. So, this check will be needed to stop
rearming mii monitor when value 0 is set to miimon.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [PATCH 4/4] bonding: Fix some RTNL taking
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116124450.GD2307@ff.dom.local>
> Maybe I'm wrong, but since this read_lock() is given and taken anyway,
> it seems this looks a bit better to me (why hold this rtnl longer
> than needed?):
> read_unlock(&bond->lock);
> rtnl_unlock();
> read_lock(&bond->lock);
Seems better.
> On the other hand, probably 'if (bond->kill_timers)' could be repeated
> after this read_lock() retaking.
Sorry, what do you mean? (A case that bond->kill_timers = 1 is done during
lock retaking, and work being queued only to do 'if (bond->kill_timers)'? If
so, I think that won't differ much.)
> If this if () is really necessary here, then this should be better
> before "delay = ..." with a block.
I agree.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 5:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: jamal, netdev
In-Reply-To: <20080117021743.GA5182@gondor.apana.org.au>
jamal wrote:
> On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
>> > No. I'm not creating second copies of the SADB/SPD entries. The entries
>> > are just added to one more list.
>
> Ah, sorry - yes, that sounds reasonable.
> So what happens if i delete an entry; does it get removed from the list?
> Also what happens on modification?
If the entry is removed befored it is dumped, it wont be dumped at all.
The state during dump code execution is returned. Depending when the
modification occurs it might or might not be reflected in the dumped
entry.
>> > If more entries are added, you can get notifications of them.
>
> how would a user app (example racoon) appropriately deal with it?
> Example an entry sits in the dump-list, it gets deleted - an event gets
> generated user-space and later that entry shows up in user space dump.
You listen for the events. It is guaranteed that if the dumping code
does return the entry to be deleted, the deletion notification will
occur after that dump entry.
Herbert Xu wrote:
> On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>> I wouldnt disagree except some apps like racoon which depend on pfkey
>> are unfortunately beyond repair. Timo has a pretty good handle on the
>
> Racoon doesn't use pfkey dumping as far as I know.
ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
make it use netlink; it relies heavily all around the code to pfkey
structs. It also runs on BSD so we cannot rip pfkey away; adding a
layer to work with both pfkey and netlink would be doable, but just a
lot of work.
Also ipsec-tools racoon seems to be the default IKE daemon in some
popular distros. So for the time being I think pfkey is an evil we have
to live with.
Cheers,
Timo
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 6:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: hadi, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> jamal <hadi@cyberus.ca> wrote:
>> There are two issues that are inter-mingled in there. The most important
>> is pf_key not being robust on dump. The other being the accurracy of
>
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
Cheers,
Timo
^ permalink raw reply
* [PATCH] request_irq() always returns -EINVAL with a NULL handler.
From: Rusty Russell @ 2008-01-17 6:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been found
earlier.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/3c503.c | 2 +-
drivers/net/e2100.c | 2 +-
drivers/net/eepro.c | 2 +-
drivers/net/hp.c | 2 +-
kernel/irq/manage.c | 1 +
5 files changed, 5 insertions(+), 4 deletions(-)
diff -r 0b7e4fbb6238 drivers/net/3c503.c
--- a/drivers/net/3c503.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/3c503.c Thu Jan 17 16:40:28 2008 +1100
@@ -379,7 +379,7 @@ el2_open(struct net_device *dev)
outb(EGACFR_NORM, E33G_GACFR); /* Enable RAM and interrupts. */
do {
- if (request_irq (*irqp, NULL, 0, "bogus", dev) != -EBUSY) {
+ if (can_request_irq(*irqp, 0)) {
/* Twinkle the interrupt, and check if it's seen. */
unsigned long cookie = probe_irq_on();
outb_p(0x04 << ((*irqp == 9) ? 2 : *irqp), E33G_IDCFR);
diff -r 0b7e4fbb6238 drivers/net/e2100.c
--- a/drivers/net/e2100.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/e2100.c Thu Jan 17 16:40:28 2008 +1100
@@ -202,7 +202,7 @@ static int __init e21_probe1(struct net_
if (dev->irq < 2) {
int irqlist[] = {15,11,10,12,5,9,3,4}, i;
for (i = 0; i < 8; i++)
- if (request_irq (irqlist[i], NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irqlist[i], 0)) {
dev->irq = irqlist[i];
break;
}
diff -r 0b7e4fbb6238 drivers/net/eepro.c
--- a/drivers/net/eepro.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/eepro.c Thu Jan 17 16:40:28 2008 +1100
@@ -914,7 +914,7 @@ static int eepro_grab_irq(struct net_dev
eepro_sw2bank0(ioaddr); /* Switch back to Bank 0 */
- if (request_irq (*irqp, NULL, IRQF_SHARED, "bogus", dev) != EBUSY) {
+ if (can_request_irq(*irqp, IRQF_SHARED)) {
unsigned long irq_mask;
/* Twinkle the interrupt, and check if it's seen */
irq_mask = probe_irq_on();
diff -r 0b7e4fbb6238 drivers/net/hp.c
--- a/drivers/net/hp.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/hp.c Thu Jan 17 16:40:28 2008 +1100
@@ -170,7 +170,7 @@ static int __init hp_probe1(struct net_d
int *irqp = wordmode ? irq_16list : irq_8list;
do {
int irq = *irqp;
- if (request_irq (irq, NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irq, 0)) {
unsigned long cookie = probe_irq_on();
/* Twinkle the interrupt, and check if it's seen. */
outb_p(irqmap[irq] | HP_RUN, ioaddr + HP_CONFIGURE);
diff -r 0b7e4fbb6238 kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:49:34 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 16:40:28 2008 +1100
@@ -252,6 +252,7 @@ int can_request_irq(unsigned int irq, un
return !action;
}
+EXPORT_SYMBOL(can_request_irq);
void compat_irq_chip_set_default_handler(struct irq_desc *desc)
{
^ permalink raw reply
* [PATCH] BUG_ON() bad input to request_irq
From: Rusty Russell @ 2008-01-17 6:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Andrew Morton
In-Reply-To: <200801171757.59026.rusty@rustcorp.com.au>
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
kernel/irq/manage.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff -r c2eb8ef5a0be kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:48:03 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 15:49:33 2008 +1100
@@ -532,13 +532,12 @@ int request_irq(unsigned int irq, irq_ha
* which interrupt is which (messes up the interrupt freeing
* logic etc).
*/
- if ((irqflags & IRQF_SHARED) && !dev_id)
- return -EINVAL;
+ BUG_ON((irqflags & IRQF_SHARED) && !dev_id);
+ BUG_ON(!handler);
+
if (irq >= NR_IRQS)
return -EINVAL;
if (irq_desc[irq].status & IRQ_NOREQUEST)
- return -EINVAL;
- if (!handler)
return -EINVAL;
action = kmalloc(sizeof(struct irqaction), GFP_ATOMIC);
^ permalink raw reply
* [PATCH] e1000e Kconfig: remove ref to nonexistant docs
From: Jason Uhlenkott @ 2008-01-17 7:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Auke Kok
There is no Documentation/networking/e1000e.txt.
Signed-off-by: Jason Uhlenkott <jasonuhl@jasonuhl.org>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
---
Index: linux/drivers/net/Kconfig
===================================================================
--- linux.orig/drivers/net/Kconfig 2008-01-16 17:48:03.041103083 -0800
+++ linux/drivers/net/Kconfig 2008-01-16 23:00:23.647430487 -0800
@@ -1976,9 +1976,6 @@
<http://support.intel.com>
- More specific information on configuring the driver is in
- <file:Documentation/networking/e1000e.txt>.
-
To compile this driver as a module, choose M here. The module
will be called e1000e.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox