* [PATCH 2/2] e1000: fix mismerge skb_put.
From: Kok, Auke @ 2006-04-18 19:40 UTC (permalink / raw)
To: Garzik, Jeff, netdev, Miller, David
Cc: Ronciak, John, Brandeburg, Jesse, Kirsher, Jeff, Kok, Auke, akpm
In-Reply-To: <20060418193950.16262.10757.stgit@gitlost.site>
Seems there was a bit of a fix needed to due a bad merge in the legacy
receive path. Fixes a panic due to skb_over_panic.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 2b8bced..fb8cef6 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3585,8 +3585,7 @@ e1000_clean_rx_irq(struct e1000_adapter
buffer_info->skb = skb;
goto next_desc;
}
- } else
- skb_put(skb, length);
+ }
/* code added for copybreak, this should improve
* performance for small packets with large amounts
--
Auke Kok <auke-jan.h.kok@intel.com>
Intel Pro Ethernet Driver Group
LAN Access Division / Digital Enterprise Group
^ permalink raw reply related
* [RFC PATCH 1/8] pcmcia: add new ID to pcnet_cs
From: Dominik Brodowski @ 2006-04-18 20:15 UTC (permalink / raw)
To: netdev
Please review these patches which I inted to push upstream for 2.6.17 soon.
Thanks,
Dominik
Subject: [PATCH] pcmcia: add new ID to pcnet_cs
This adds a new ID to pcnet_cs, as noted by Kuro Moji.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/pcnet_cs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
af6f85925c2984c3596ba480c19573e55724bbdf
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index 506e777..d090df4 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/drivers/net/pcmcia/pcnet_cs.c
@@ -1639,6 +1639,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_DEVICE_PROD_ID12("CONTEC", "C-NET(PC)C-10L", 0x21cab552, 0xf6f90722),
PCMCIA_DEVICE_PROD_ID12("corega", "FEther PCC-TXF", 0x0a21501a, 0xa51564a2),
PCMCIA_DEVICE_PROD_ID12("corega K.K.", "corega EtherII PCC-T", 0x5261440f, 0xfa9d85bd),
+ PCMCIA_DEVICE_PROD_ID12("corega K.K.", "corega EtherII PCC-TD", 0x5261440f, 0xc49bd73d),
PCMCIA_DEVICE_PROD_ID12("Corega K.K.", "corega EtherII PCC-TD", 0xd4fdcbd8, 0xc49bd73d),
PCMCIA_DEVICE_PROD_ID12("corega K.K.", "corega Ether PCC-T", 0x5261440f, 0x6705fcaa),
PCMCIA_DEVICE_PROD_ID12("corega K.K.", "corega FastEther PCC-TX", 0x5261440f, 0x485e85d9),
--
1.2.6
^ permalink raw reply related
* Re: [TCP]: Fix truesize underflow
From: David S. Miller @ 2006-04-18 20:19 UTC (permalink / raw)
To: netdev
Cc: herbert, bb, kernel, nipsy, jesse.brandeburg, jrlundgren, cat,
djani22, yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, ak, jgarzik
In-Reply-To: <200604181829.59686.netdev@axxeo.de>
From: Ingo Oeser <netdev@axxeo.de>
Date: Tue, 18 Apr 2006 18:29:59 +0200
> But shouldn't we put this kind of hairy manipulation into some nice
> functions? Driver writers were already confused by all that size,
> len and truesize stuff, as this bug showed.
It's 2 lines and frankly it's a bit context dependant. I think
Herbert's fix is fine for now.
In the long term, yes, a lot of these weird manipulations need to
be consolidated in well defined functions to make maintainence
and auditing easier.
^ permalink raw reply
* Re: [TCP]: Fix truesize underflow
From: David S. Miller @ 2006-04-18 20:22 UTC (permalink / raw)
To: herbert
Cc: bb, kernel, nipsy, jesse.brandeburg, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, ak, jgarzik
In-Reply-To: <20060418123204.GA3962@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 18 Apr 2006 22:32:04 +1000
> You're absolutely right about there being a problem with the TSO packet
> trimming code. The cause of this lies in the tcp_fragment() function.
>
> When we allocate a fragment for a completely non-linear packet the
> truesize is calculated for a payload length of zero. This means that
> truesize could in fact be less than the real payload length.
>
> When that happens the TSO packet trimming can cause truesize to become
> negative. This in turn can cause sk_forward_alloc to be -n * PAGE_SIZE
> which would trigger the warning.
>
> I've copied the code you used in tso_fragment which should work here.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks for discovering this, very nice work Herbert.
So what we find out time and time again, is that the TSO splitting and
trimming code enforces that the skb->truesize of every TCP packet must
be accurate at all times.
I think it is deserving of some run time assertions, else these bugs
will elude us continually. Luckily there are only a few places that
would need the run time assertion checks on skb->truesize, and I'll
try to spend a few cycles on implementing this soon.
Patch applied, thanks a lot!
^ permalink raw reply
* Re: [RFC PATCH 1/8] pcmcia: add new ID to pcnet_cs
From: Jeff Garzik @ 2006-04-18 20:35 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: netdev
In-Reply-To: <20060418201522.GA32341@isilmar.linta.de>
Dominik Brodowski wrote:
> Please review these patches which I inted to push upstream for 2.6.17 soon.
> Thanks,
> Dominik
>
> Subject: [PATCH] pcmcia: add new ID to pcnet_cs
>
> This adds a new ID to pcnet_cs, as noted by Kuro Moji.
>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
ACK, thanks for CC'ing netdev
Jeff
^ permalink raw reply
* Re: [PATCH 0/4]: Fix several errors in extension header handling.
From: David S. Miller @ 2006-04-18 21:49 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20060419.002045.85775401.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Wed, 19 Apr 2006 00:20:45 +0900 (JST)
> Following changesets fix several errors in extension header handling.
> I'd propose to push them (except 4/4, maybe) to -stable.
>
> [PATCH 1/4] [IPV6]: Ensure to have hop-by-hop options in our header of &sk_buff.
> [PATCH 2/4] [IPV6] XFRM: Don't use old copy of pointer after pskb_may_pull().
> [PATCH 3/4] [IPV6] XFRM: Fix decoding session with preceding extension header(s).
> [PATCH 4/4] [IPV6]: Clean up hop-by-hop options handler.
All applied, and I agree with pushing 1-3 into -stable,
please send it.
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: David S. Miller @ 2006-04-18 21:54 UTC (permalink / raw)
To: herbert; +Cc: shemminger, netdev
In-Reply-To: <E1FVk6q-0000Tf-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 18 Apr 2006 16:54:48 +1000
> Looking at this again, the root of this problem is the IGMPv3
> patch which started using the skb->nh.iph->protocol as a key.
>
> So what we really should do is make the protocol an explicit parameter
> to the ip_route_input function. This will make it clear to all the
> users which include some pretty weird cases that the protocol is needed.
>
> In fact I'm unsure as to whether all the other users of ip_route_input
> is safe as it is regarding the protocol.
There are other areas of the packet which are interpreted in various
ways. For example, the martian source handling will dump the MAC
directly from skb->mac.raw into the kernel logs.
The output path is so much cleaner, because things like the protocol
are filled out in the struct flowi so there is no need to be parsing
the SKB in any way.
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Herbert Xu @ 2006-04-18 22:08 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, netdev
In-Reply-To: <20060418.145416.114278524.davem@davemloft.net>
On Tue, Apr 18, 2006 at 02:54:16PM -0700, David S. Miller wrote:
>
> There are other areas of the packet which are interpreted in various
> ways. For example, the martian source handling will dump the MAC
> directly from skb->mac.raw into the kernel logs.
That's scary. I think this stuff needs an audit.
> The output path is so much cleaner, because things like the protocol
> are filled out in the struct flowi so there is no need to be parsing
> the SKB in any way.
Absolutely. I think we should put Stephen's patch in ASAP. Once the
immediate problem is gone we can take our time and make the input path
more like the output.
At the end of this I'd like to see the skb argument from ip_route_input
replaced by a dst_entry.
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
* [patch] Re: r8169 locks up in 2.6.16.5
From: Francois Romieu @ 2006-04-18 23:04 UTC (permalink / raw)
To: Thomas A. Oehser; +Cc: netdev
In-Reply-To: <20060418004358.GA8967@jupiter.toms.net>
Thomas A. Oehser <tom@toms.net> :
[...]
> It is actually about a 30GB transfer, it was just after the first
> 170Mb that it failed. The command in question is just a simple
> "nc -l -p 12345|buffer|cpio -iumdB", and the sender may well be
> able to generate the data faster than the receiving disk can save
> it, as the sender is a raid-1 mirror and the receiver is a raid-5
> array, I would expect the raid-5 write penalty and the raid-1 read
> speed to make it have to block for most of the transfer. It didn't
> take long to get that far- um, I think only 2 or 3 minutes before
> it locked up.
The r8169 offers 48 kb of Rx fifo. 170 Mb in 2~3 minutes is under 2 Mb/s.
Even if the traffic is very bursty, something seems to stall the PCI bus.
I'm a bit surprized.
Anyway, can you give the patch below a try and tell if it changes
something ? If so, an updated output of 'ethtool -S' would be welcome.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 0ad3310..f9da390 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -256,10 +256,11 @@ enum RTL8169_register_content {
RxOK = 0x01,
/* RxStatusDesc */
- RxRES = 0x00200000,
- RxCRC = 0x00080000,
- RxRUNT = 0x00100000,
- RxRWT = 0x00400000,
+ RxFOVF = (1 << 23),
+ RxRWT = (1 << 22),
+ RxRES = (1 << 21),
+ RxRUNT = (1 << 20),
+ RxCRC = (1 << 19),
/* ChipCmdBits */
CmdReset = 0x10,
@@ -2435,6 +2436,10 @@ rtl8169_rx_interrupt(struct net_device *
tp->stats.rx_length_errors++;
if (status & RxCRC)
tp->stats.rx_crc_errors++;
+ if (status & RxFOVF) {
+ rtl8169_schedule_work(dev, rtl8169_reset_task);
+ tp->stats.rx_fifo_errors++;
+ }
rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
} else {
struct sk_buff *skb = tp->Rx_skbuff[entry];
^ permalink raw reply related
* Re: [TCP]: Fix truesize underflow
From: Herbert Xu @ 2006-04-18 23:27 UTC (permalink / raw)
To: David S. Miller
Cc: bb, kernel, nipsy, jesse.brandeburg, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, ak, jgarzik
In-Reply-To: <20060418.132256.110004342.davem@davemloft.net>
On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
>
> I think it is deserving of some run time assertions, else these bugs
> will elude us continually. Luckily there are only a few places that
> would need the run time assertion checks on skb->truesize, and I'll
> try to spend a few cycles on implementing this soon.
Yes indeed. One place that comes to mind would be tcp_trim_head just
before we munge truesize.
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] ip_route_input panic fix
From: Alexey Kuznetsov @ 2006-04-18 23:52 UTC (permalink / raw)
To: Herbert Xu; +Cc: Stephen Hemminger, davem, netdev
In-Reply-To: <E1FVk6q-0000Tf-00@gondolin.me.apana.org.au>
Hello!
> Looking at this again, the root of this problem is the IGMPv3
> patch which started using the skb->nh.iph->protocol as a key.
No, root is that this fake skb was not properly initialized.
It should, it should be a good real IP skb.
> In fact I'm unsure as to whether all the other users of ip_route_input
> is safe as it is regarding the protocol.
ip_route_input takes skb as an argument exactly because it needs nothing
but skb and there is always an skb, when we "input".
ip_route_output would be happy to take an skb as well,
but unfortuntely it happens before we have an skb.
I do not see anything scary here: agree, when skb->nh happens to be undefined,
such skb would crash almost any place in IP stack. :-)
Actually, this weird case in inet_get_route() is the only place, where
a dummy skb is used and it is needed mostly to resolve multicast routes.
In this case this fake skb really passes through all the engine, even
delivered to user space in some sense, and when the route is resolved,
the same skb is submitted to netlink socket. I remember, Dave found
something very bad about this and this even deserved a place in TODO list,
but franky speaking I did not understand what is so wrong with this trick.
Alexey
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/netlink/: possible cleanups
From: Philip Craig @ 2006-04-19 0:02 UTC (permalink / raw)
To: David S. Miller; +Cc: bunk, netdev, linux-kernel
In-Reply-To: <20060413.132603.94193712.davem@davemloft.net>
On 04/14/2006 06:26 AM, David S. Miller wrote:
> These interfaces were added so that new users of netlink could
> write their code more easily.
>
> Unused does not equate to "comment out or delete".
Does a GENETLINK Kconfig option make sense (possibly dependant on
EMBEDDED)? I'm unsure whether these interfaces are going to be used
in core networking code that can't be disabled anyway.
^ permalink raw reply
* [PATCH] softmac: report SIOCGIWAP event upon association
From: Daniel Drake @ 2006-04-19 0:02 UTC (permalink / raw)
To: johannes; +Cc: softmac-dev, netdev
wpa_supplicant requires some notification when association has completed, and
this is the way to do it.
Before this patch, wpa_supplicant just times out when trying to associate,
even though the association completed successfully in the background. This was
reported at
http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg00959.html
After this patch, wpa_supplicant works for me. I have tested connecting to a
WEP network.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16 23:55:23.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-19 01:08:40.000000000 +0100
@@ -282,6 +282,8 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211_assoc_response * resp,
struct ieee80211softmac_network *net)
{
+ union iwreq_data wrqu;
+
mac->associnfo.associating = 0;
mac->associated = 1;
if (mac->set_bssid_filter)
@@ -290,6 +292,10 @@ ieee80211softmac_associated(struct ieee8
netif_carrier_on(mac->dev);
mac->association_id = le16_to_cpup(&resp->aid);
+
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ memcpy(wrqu.ap_addr.sa_data, net->bssid, ETH_ALEN);
+ wireless_send_event(mac->dev, SIOCGIWAP, &wrqu, NULL);
}
/* received frame handling functions */
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Herbert Xu @ 2006-04-19 0:17 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Stephen Hemminger, davem, netdev
In-Reply-To: <20060418235222.GA20504@ms2.inr.ac.ru>
On Wed, Apr 19, 2006 at 03:52:22AM +0400, Alexey Kuznetsov wrote:
>
> Actually, this weird case in inet_get_route() is the only place, where
There is also the ARP code which passes an ARP packet through that
would get dereferenced as an IP packet. Granted this shouldn't crash
because nh is set properly.
But we really should make up our mind as to whether the routing key
comes from the arguments to ip_route_input (src/dst/...) or the skb.
Using both is just asking for trouble.
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 2.6.16-rc5] S2io: Receive packet classification and steering mechanisms
From: Ravinandan Arakali @ 2006-04-19 0:38 UTC (permalink / raw)
To: jgarzik, netdev
In-Reply-To: <MAEEKMLDLDFEGKHNIJHICENMCCAA.ravinandan.arakali@neterion.com>
Hi Jeff,
Any comments on the below patch ?
Thanks,
Ravi
-----Original Message-----
From: Ravinandan Arakali [mailto:Ravinandan.Arakali@neterion.com]
Sent: Friday, March 10, 2006 12:32 PM
To: jgarzik@pobox.com; netdev@vger.kernel.org
Cc: raghavendra.koushik@neterion.com; ravinandan.arakali@neterion.com;
leonid.grossman@neterion.com; rapuru.sriram@neterion.com;
ananda.raju@neterion.com; alicia.pena@neterion.com;
sivakumar.subramani@neterion.com
Subject: [PATCH 2.6.16-rc5] S2io: Receive packet classification and
steering mechanisms
Hi,
Attached below is a patch to several receive packet classification
and steering mechanisms for Xframe NIC hw channels. Current Xframe ASIC
supports one hardware channel per CPU, up to 8 channels. This number
will increase in the next ASIC release. A channel could be attached to a
specific MSI-X vector (with an independent interrupt moderation scheme),
which in turn can be bound to a CPU.
Follow-up patches will provide some enhancements for the default tcp
workload balancing across hw channels, as well as an optional hw channel
interface. The interface is intended to be very generic (not specific to
Xframe hardware).
The following mechanisms are supported in this patch:
Note: The steering type can be specified at load time with
parameter rx_steering_type. Values supported are 1(port based),
2(RTH), 4(SPDM), 8(MAC addr based).
1. RTH(Receive traffic hashing):
Steering is based on socket tuple (or a subset) and the popular Jenkins
hash is used for RTH. This lets the receive processing to be spanned out
to multiple CPUs, thus reducing single CPU bottleneck on Rx path.
Hash-based steering can be used when it is desired to balance an
unlimited number or TCP sessions across multiple CPUs but the exact
mapping between a particular session and a particular cpu is not
important.
configuration: A mask(specified using loadable parameter rth_fn_and_mask)
can be used to select a subset of TCP/UDP tuple for hash calculation.
eg. To mask source port for TCP/IPv4 configuration,
# insmod s2io.ko rx_steering_type=2 rth_fn_and_mask=0x0101
LSB specifies RTH function type and MSB the mask. A full description
is provided at the beginning of s2io.c
2. port based:
Steering is done based on source/destination TCP/UDP port number.
configuration: Interface used is netlink sockets. Can specify port
number(s), TCP/UDP type, source/destination port.
3. MAC address-based:
Done based on destination MAC address of packet. Xframe can be
configured with multiple unicast MAC addresses.
configuration: Load-time parameters multi_mac_cnt and multi_macs
can be used to specify no. of MAC addresses and list of unicast
addresses.
eg. insmod s2io.ko rx_steering_type=8 multi_mac_cnt=3
multi_macs=00:0c:fc:00:00:22, 00:0c:fc:00:01:22, 00:0c:fc:00:02:22
Packets received with default destination MAC address will be steered to
ring0. Packets with destination MAC addresses specified by multi_macs are
steered to ring1, ring2... respectively.
4. SPDM (Socket Pair Direct Match).
Steering is based on exact socket tuple (or a subset) match.
SPDM steering can be used when the exact mapping between a particular
session and a particular cpu is desired.
configuration: Interface used is netlink sockets. Can specify
socket tuple values. If any of the values(say source port) needs
to be "don't care", specify 0xFFFF.
Signed-off-by: Raghavendra Koushik <raghavendra.koushik@neterion.com>
Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com>
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
---
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Alexey Kuznetsov @ 2006-04-19 1:00 UTC (permalink / raw)
To: herbert, shemminger, davem, netdev
Hello!
> There is also the ARP code which passes an ARP packet through that
> would get dereferenced as an IP packet. Granted this shouldn't crash
> because nh is set properly.
And points to something which is not an IP header. So, iph->protocol
is something funny. :-)
It is plain luck that this never happens, ARP packets
with multicast addresses are filtered out.
Mess, I agree.
> But we really should make up our mind as to whether the routing key
> comes from the arguments to ip_route_input (src/dst/...) or the skb.
>
> Using both is just asking for trouble.
Well, both sets are present only for use the same function in ARP.
So, arguments. Actually, skb can be preserved, but it should not be used
for anything but debugging or for hints, when we should not create
cache entry.
BTW, I cannot figure out what ip_check_mc() tries to do with protocol
(which is __u16 by some reason). If it creates cache entry, protocol
is not checked. Funny.
Alexey
^ permalink raw reply
* Re: [PATCH 2.6.16-rc5] S2io: Receive packet classification and steering mechanisms
From: Andi Kleen @ 2006-04-19 0:59 UTC (permalink / raw)
To: ravinandan.arakali; +Cc: jgarzik, netdev
In-Reply-To: <MAEEKMLDLDFEGKHNIJHIAEIGCDAA.ravinandan.arakali@neterion.com>
On Wednesday 19 April 2006 02:38, Ravinandan Arakali wrote:
> configuration: A mask(specified using loadable parameter rth_fn_and_mask)
> can be used to select a subset of TCP/UDP tuple for hash calculation.
> eg. To mask source port for TCP/IPv4 configuration,
> # insmod s2io.ko rx_steering_type=2 rth_fn_and_mask=0x0101
> LSB specifies RTH function type and MSB the mask. A full description
> is provided at the beginning of s2io.c
I don't think it's a good idea to introduce such weird and hard to understand
module parameters for this. I would be better to define a generic
internal kernel interface between stack and driver. Perhaps starting
with a standard netlink interface for this might be a good start
until the stack learns how to use this on its own.
> 3. MAC address-based:
> Done based on destination MAC address of packet. Xframe can be
> configured with multiple unicast MAC addresses.
>
> configuration: Load-time parameters multi_mac_cnt and multi_macs
> can be used to specify no. of MAC addresses and list of unicast
> addresses.
> eg. insmod s2io.ko rx_steering_type=8 multi_mac_cnt=3
> multi_macs=00:0c:fc:00:00:22, 00:0c:fc:00:01:22, 00:0c:fc:00:02:22
> Packets received with default destination MAC address will be steered to
> ring0. Packets with destination MAC addresses specified by multi_macs are
> steered to ring1, ring2... respectively.
The obvious way to do this nicely would be to allow to define multiple
virtual interfaces where the mac addresses can be set using the usual ioctls.
-Andi
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Alexey Kuznetsov @ 2006-04-19 0:59 UTC (permalink / raw)
To: herbert, shemminger, davem, netdev
Hello!
> There is also the ARP code which passes an ARP packet through that
> would get dereferenced as an IP packet. Granted this shouldn't crash
> because nh is set properly.
And point to something which is not an IP header. So, iph->protocol
is something funny. :-)
It is plain luck that this never happens, ARP packets
with multicast addresses are filtered out.
Mess, I agree.
> But we really should make up our mind as to whether the routing key
> comes from the arguments to ip_route_input (src/dst/...) or the skb.
>
> Using both is just asking for trouble.
Well, both sets are present only for use the same function in ARP.
So, arguments. skb can be even preserved, but it should not be used
for anything but debugging or for hints, when we should not create
cache entry.
BTW, I cannot figure out what ip_check_mc tries to do with protocol
(which is __u16 by some reason). If it creates cache entry, protocol
is not checked. Funny.
Alexey
^ permalink raw reply
* Re: [PATCH 0/4]: Fix several errors in extension header handling.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-04-19 2:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060418.144914.24796175.davem@davemloft.net>
In article <20060418.144914.24796175.davem@davemloft.net> (at Tue, 18 Apr 2006 14:49:14 -0700 (PDT)), "David S. Miller" <davem@davemloft.net> says:
> All applied, and I agree with pushing 1-3 into -stable,
> please send it.
Done. Thanks.
--yoshfuji
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: David S. Miller @ 2006-04-19 3:53 UTC (permalink / raw)
To: kuznet; +Cc: herbert, shemminger, netdev
In-Reply-To: <20060418235222.GA20504@ms2.inr.ac.ru>
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Wed, 19 Apr 2006 03:52:22 +0400
> Actually, this weird case in inet_get_route() is the only place, where
> a dummy skb is used and it is needed mostly to resolve multicast routes.
> In this case this fake skb really passes through all the engine, even
> delivered to user space in some sense, and when the route is resolved,
> the same skb is submitted to netlink socket. I remember, Dave found
> something very bad about this and this even deserved a place in TODO list,
> but franky speaking I did not understand what is so wrong with this trick.
Problem there is via rt_fill_info(). When multicast route cannot be
found by ipmr, it tries to use this netlink SKB to send out a probe.
ipmr_get_route() is the trouble maker. If ipmr_cache_find() cannot
find an entry, it tries to use the netlink SKB to send out an ipv4
packet, completely mangling it, via ipmr_cache_unresolved().
Even worse it may even free the skb on us, or queue it to
mroute_socket.
It is pure disaster, this entire code path.
^ permalink raw reply
* [patch 01/10] tulip: NatSemi DP83840A PHY fix
From: akpm @ 2006-04-19 4:03 UTC (permalink / raw)
To: jeff; +Cc: linville, netdev, akpm, T-Bone, grundler, jgarzik, varenet
From: Thibaut VARENE <T-Bone@parisc-linux.org>
Fix a problem with Tulip 21142 HP branded PCI cards (PN#: B5509-66001),
which feature a NatSemi DP83840A PHY.
Without that patch, it is impossible to properly initialize the card's PHY,
and it's thus impossible to monitor/configure it.
It's a timing/posting problem, and it is solved exactly the same way Grant
fixed it elsewhere already.
Signed-off-by: Thibaut VARENE <varenet@parisc-linux.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/tulip/media.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletion(-)
diff -puN drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix drivers/net/tulip/media.c
--- devel/drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix 2006-04-10 23:21:18.000000000 -0700
+++ devel-akpm/drivers/net/tulip/media.c 2006-04-10 23:21:18.000000000 -0700
@@ -261,11 +261,27 @@ void tulip_select_media(struct net_devic
u16 *reset_sequence = &((u16*)(p+3))[init_length];
int reset_length = p[2 + init_length*2];
misc_info = reset_sequence + reset_length;
- if (startup)
+ if (startup) {
+ int timeout = 10; /* max 1 ms */
for (i = 0; i < reset_length; i++)
iowrite32(get_u16(&reset_sequence[i]) << 16, ioaddr + CSR15);
+
+ /* flush posted writes */
+ ioread32(ioaddr + CSR15);
+
+ /* Sect 3.10.3 in DP83840A.pdf (p39) */
+ udelay(500);
+
+ /* Section 4.2 in DP83840A.pdf (p43) */
+ /* and IEEE 802.3 "22.2.4.1.1 Reset" */
+ while (timeout-- &&
+ (tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+ udelay(100);
+ }
for (i = 0; i < init_length; i++)
iowrite32(get_u16(&init_sequence[i]) << 16, ioaddr + CSR15);
+
+ ioread32(ioaddr + CSR15); /* flush posted writes */
} else {
u8 *init_sequence = p + 2;
u8 *reset_sequence = p + 3 + init_length;
_
^ permalink raw reply
* [patch 03/10] PCI Error Recovery: e1000 network device driver
From: akpm @ 2006-04-19 4:04 UTC (permalink / raw)
To: jeff; +Cc: linville, netdev, akpm, linas, jesse.brandeburg
From: Linas Vepstas <linas@linas.org>
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit ethernet
e1000 device driver. The patch has been tested, and appears to work well.
[akpm@osdl.org: minor cleanups]
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/e1000/e1000_main.c | 116 ++++++++++++++++++++++++++++++-
1 files changed, 115 insertions(+), 1 deletion(-)
diff -puN drivers/net/e1000/e1000_main.c~pci-error-recovery-e1000-network-device-driver drivers/net/e1000/e1000_main.c
--- devel/drivers/net/e1000/e1000_main.c~pci-error-recovery-e1000-network-device-driver 2006-04-14 23:41:33.000000000 -0700
+++ devel-akpm/drivers/net/e1000/e1000_main.c 2006-04-14 23:41:33.000000000 -0700
@@ -227,6 +227,16 @@ static int e1000_resume(struct pci_dev *
static void e1000_netpoll (struct net_device *netdev);
#endif
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
+static void e1000_io_resume(struct pci_dev *pdev);
+
+static struct pci_error_handlers e1000_err_handler = {
+ .error_detected = e1000_io_error_detected,
+ .slot_reset = e1000_io_slot_reset,
+ .resume = e1000_io_resume,
+};
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
@@ -236,8 +246,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .err_handler = &e1000_err_handler,
};
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
@@ -3076,6 +3087,10 @@ e1000_update_stats(struct e1000_adapter
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
+ /* Prevent stats update while adapter is being reset */
+ if (adapter->link_speed == 0)
+ return;
+
spin_lock_irqsave(&adapter->stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
@@ -4626,4 +4641,103 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/**
+ * e1000_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e1000_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot. Implementation
+ * resembles the first-half of the e1000_resume routine.
+ */
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "e1000: Cannot re-enable PCI device after "
+ "reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ pci_enable_wake(pdev, 3, 0);
+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+
+ /* Perform card reset only on one instance of the card */
+ if (PCI_FUNC (pdev->devfn) != 0)
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(&adapter->hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e1000_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation. Implementation resembles the
+ * second-half of the e1000_resume routine.
+ */
+static void e1000_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+ uint32_t manc, swsm;
+
+ if (netif_running(netdev)) {
+ if (e1000_up(adapter)) {
+ printk(KERN_ERR "e1000: can't bring device back up "
+ "after reset\n");
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+
+ if (adapter->hw.mac_type >= e1000_82540 &&
+ adapter->hw.media_type == e1000_media_type_copper) {
+ manc = E1000_READ_REG(&adapter->hw, MANC);
+ manc &= ~(E1000_MANC_ARP_EN);
+ E1000_WRITE_REG(&adapter->hw, MANC, manc);
+ }
+
+ switch (adapter->hw.mac_type) {
+ case e1000_82573:
+ swsm = E1000_READ_REG(&adapter->hw, SWSM);
+ E1000_WRITE_REG(&adapter->hw, SWSM, swsm | E1000_SWSM_DRV_LOAD);
+ break;
+ default:
+ break;
+ }
+
+ if (netif_running(netdev))
+ mod_timer(&adapter->watchdog_timer, jiffies);
+}
+
/* e1000_main.c */
_
^ permalink raw reply
* [patch 04/10] PCI Error Recovery: e100 network device driver
From: akpm @ 2006-04-19 4:04 UTC (permalink / raw)
To: jeff; +Cc: linville, netdev, akpm, linas, jesse.brandeburg
From: linas@austin.ibm.com (Linas Vepstas)
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/e100.c | 75 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+)
diff -puN drivers/net/e100.c~pci-error-recovery-e100-network-device-driver drivers/net/e100.c
--- devel/drivers/net/e100.c~pci-error-recovery-e100-network-device-driver 2006-04-10 23:21:20.000000000 -0700
+++ devel-akpm/drivers/net/e100.c 2006-04-10 23:21:20.000000000 -0700
@@ -2726,6 +2726,80 @@ static void e100_shutdown(struct pci_dev
DPRINTK(PROBE,ERR, "Error enabling wake\n");
}
+/* ------------------ PCI Error Recovery infrastructure -------------- */
+/**
+ * e100_io_error_detected - called when PCI error is detected.
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ */
+static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+
+ /* Similar to calling e100_down(), but avoids adpater I/O. */
+ netdev->stop(netdev);
+
+ /* Detach; put netif into state similar to hotplug unplug. */
+ netif_poll_enable(netdev);
+ netif_device_detach(netdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e100_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ /* Only one device per card can do a reset */
+ if (0 != PCI_FUNC(pdev->devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+ e100_hw_reset(nic);
+ e100_phy_init(nic);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e100_io_resume - resume normal operations
+ * @pdev: Pointer to PCI device
+ *
+ * Resume normal operations after an error recovery
+ * sequence has been completed.
+ */
+static void e100_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ /* ack any pending wake events, disable PME */
+ pci_enable_wake(pdev, 0, 0);
+
+ netif_device_attach(netdev);
+ if (netif_running(netdev)) {
+ e100_open(netdev);
+ mod_timer(&nic->watchdog, jiffies);
+ }
+}
+
+static struct pci_error_handlers e100_err_handler = {
+ .error_detected = e100_io_error_detected,
+ .slot_reset = e100_io_slot_reset,
+ .resume = e100_io_resume,
+};
static struct pci_driver e100_driver = {
.name = DRV_NAME,
@@ -2737,6 +2811,7 @@ static struct pci_driver e100_driver = {
.resume = e100_resume,
#endif
.shutdown = e100_shutdown,
+ .err_handler = &e100_err_handler,
};
static int __init e100_init_module(void)
_
^ permalink raw reply
* [patch 05/10] e1000: prevent statistics from getting garbled during reset
From: akpm @ 2006-04-19 4:04 UTC (permalink / raw)
To: jeff
Cc: linville, netdev, akpm, linas, jeffrey.t.kirsher,
jesse.brandeburg, john.ronciak
From: Linas Vepstas <linas@austin.ibm.com>
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream. This patch skips statistics data collection if the
PCI device is not on the bus.
This patch presumes that an earlier patch,
[PATCH] PCI Error Recovery: e1000 network device driver
has already been applied.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: John Ronciak <john.ronciak@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/e1000/e1000_main.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletion(-)
diff -puN drivers/net/e1000/e1000_main.c~e1000-prevent-statistics-from-getting-garbled-during-reset drivers/net/e1000/e1000_main.c
--- devel/drivers/net/e1000/e1000_main.c~e1000-prevent-statistics-from-getting-garbled-during-reset 2006-04-14 23:41:34.000000000 -0700
+++ devel-akpm/drivers/net/e1000/e1000_main.c 2006-04-14 23:41:34.000000000 -0700
@@ -3082,14 +3082,20 @@ void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
- /* Prevent stats update while adapter is being reset */
+ /*
+ * Prevent stats update while adapter is being reset, or if the pci
+ * connection is down.
+ */
if (adapter->link_speed == 0)
return;
+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+ return;
spin_lock_irqsave(&adapter->stats_lock, flags);
_
^ permalink raw reply
* [patch 10/10] e1000: fix media_type <-> phy_type thinko
From: akpm @ 2006-04-19 4:04 UTC (permalink / raw)
To: jeff; +Cc: linville, netdev, akpm, willy, jesse.brandeburg, john.ronciak
From: Willy TARREAU <willy@w.ods.org>
Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced a thinko
in e1000_main.c : e1000_media_type_copper is compared to hw.phy_type
instead of hw.media_type. Original patch proposed by Jesse Brandeburg was
correct, but what has been merged is not.
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: "Ronciak, John" <john.ronciak@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/e1000/e1000_main.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/e1000/e1000_main.c~e1000-fix-media_type-phy_type-thinko drivers/net/e1000/e1000_main.c
--- devel/drivers/net/e1000/e1000_main.c~e1000-fix-media_type-phy_type-thinko 2006-04-17 21:42:32.000000000 -0700
+++ devel-akpm/drivers/net/e1000/e1000_main.c 2006-04-17 21:43:30.000000000 -0700
@@ -4195,7 +4195,7 @@ e1000_mii_ioctl(struct net_device *netde
spin_unlock_irqrestore(&adapter->stats_lock, flags);
return -EIO;
}
- if (adapter->hw.phy_type == e1000_media_type_copper) {
+ if (adapter->hw.media_type == e1000_media_type_copper) {
switch (data->reg_num) {
case PHY_CTRL:
if (mii_reg & MII_CR_POWER_DOWN)
_
^ 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