Re: Badness in cache_free_debugcheck at mm/slab.c:2315
From: Dave Jones <[EMAIL PROTECTED]> Date: Thu, 19 Jan 2006 01:38:24 -0500 > FWIW, the original bug reporter has followed up to report that this > is still present in a kernel based on 2.6.16rc1 I wonder if this is another -Os miscompile... I'll try to have a look. - 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: Badness in cache_free_debugcheck at mm/slab.c:2315
On Wed, Jan 11, 2006 at 11:53:15PM -0500, Dave Jones wrote: > We got this in Fedora bugzilla from a user running a 2.6.15-rc7-git2 vintage > kernel. This seemed important enough to warrant a closer look by someone > familiar > with recent networking changes in case this hasn't been reported/fixed yet. FWIW, the original bug reporter has followed up to report that this is still present in a kernel based on 2.6.16rc1 Dave > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177236 > > Jan 7 17:22:45 white kernel: mismatch in kmem_cache_free: expected cache > df7c9140, got df7c9200 > Jan 7 17:22:45 white kernel: df7c9200 is skbuff_head_cache. > Jan 7 17:22:45 white kernel: df7c9140 is skbuff_fclone_cache. > Jan 7 17:22:45 white kernel: Badness in cache_free_debugcheck at > mm/slab.c:2315 > (Not tainted) - 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: how to obtain detailed e1000 stats?
jamal wrote: On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote: jamal wrote: And if you are serious about performance you should use netlink. If you can show me a snippet of user-space code similar to the complexity of what I posted earlier, I'll actually do a benchmark against it and my code to see if they are roughly equal. If so, I'll purge this from my patch set and never bother anyone with it again... On the other hand, if it requires hard to find and/or half-assed libraries and lots of code, don't bother. Well, i can give you pointers and if you are really serious you will invest the time. - use iproute2 and see how one dumps netdevice stats - Continue by looking at iproute2/ip/ files iplink.c and ipaddress.c and note that: stats are stored in a TLV IFLA_STATS and are printed in print_linkinfo() The code is not much to study if you are serious about performance. Thomas Graf as well has been trying to make it simpler to do this kind stuff. I havent looked at it lately but should make it simpler. If you can beat the performance of that with your half-assed tool then i will be interested in showing up. For now you are on your own on or maybe someone else has time. Looks about as complex as last time I looked..lots of MACROs, constants, and powerful options that might make good sense for 'ip', but make using it in a stand-alone application difficult. I also notice that the lib/libnetlink.c file is GPL instead of LGPL, so I can't use it in my application anyway... 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: [PATCH] PCI Error Recovery: ixgb network device driver
>
> +#ifdef XXX_CONFIG_IXGB_EEH_RECOVERY
> + if(unlikely(icr==EEH_IO_ERROR_VALUE(4))) {
> + if (eeh_slot_is_isolated (adapter->pdev))
> + // disable_irq_nosync (adapter->pdev->irq);
> + return IRQ_NONE; /* Not our interrupt */
So does the return belong below the first or the second if()? It certainly
looks weird.
And returning IRQ_NONE looks wrong too - if means if
the hardware is broken and there is nobody else on the same interrupt
then the kernel will complain about buggy drivers, which is not true
here. Probably it needs a new IRQ_ERR return value or somesuch that
stops the complaining and acts otherwise like IRQ_NONE.
-Andi
-
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: how to obtain detailed e1000 stats?
On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote: > jamal wrote: > > And if you are serious about performance you should use netlink. > > If you can show me a snippet of user-space code similar to the > complexity of what I posted earlier, I'll actually do a benchmark > against it and my code to see if they are roughly equal. If so, I'll > purge this from my patch set and never bother anyone with it again... > > On the other hand, if it requires hard to find and/or half-assed libraries > and lots of code, don't bother. > Well, i can give you pointers and if you are really serious you will invest the time. - use iproute2 and see how one dumps netdevice stats - Continue by looking at iproute2/ip/ files iplink.c and ipaddress.c and note that: stats are stored in a TLV IFLA_STATS and are printed in print_linkinfo() The code is not much to study if you are serious about performance. Thomas Graf as well has been trying to make it simpler to do this kind stuff. I havent looked at it lately but should make it simpler. If you can beat the performance of that with your half-assed tool then i will be interested in showing up. For now you are on your own on or maybe someone else has time. 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: how to obtain detailed e1000 stats?
jamal wrote: On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote: shemminger wrote: It makes no sense to extend ethtool for something generic like that. It shouldn't be that hard to do netlink in some richer scripting language (like perl), but I haven't tried. If you're using perl, you've already given up performance, so just parse /proc/net/dev. I implemented my patch to more efficiently (and easily) grab the stats for 250 interfaces every few seconds. And if you are serious about performance you should use netlink. If you can show me a snippet of user-space code similar to the complexity of what I posted earlier, I'll actually do a benchmark against it and my code to see if they are roughly equal. If so, I'll purge this from my patch set and never bother anyone with it again... On the other hand, if it requires hard to find and/or half-assed libraries and lots of code, don't bother. Thanks, 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: how to obtain detailed e1000 stats?
On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote: > shemminger wrote: > > > It makes no sense to extend ethtool for something generic like that. > > It shouldn't be that hard to do netlink in some richer scripting > > language (like perl), but I haven't tried. > > If you're using perl, you've already given up performance, so just > parse /proc/net/dev. > > I implemented my patch to more efficiently (and easily) grab the stats for 250 > interfaces every few seconds. > And if you are serious about performance you should use netlink. 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
[2.6 patch] schedule SHAPER for removal
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 13 Jan 2006 --- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.0 +0100 +++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.0 +0100 @@ -164,0 +165,6 @@ +--- + +What: Traffic Shaper (CONFIG_SHAPER) +When: July 2006 +Why:obsoleted by the code in net/sched/ +Who:Adrian Bunk <[EMAIL PROTECTED] --- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.0 +0100 +++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.0 +0100 @@ -2663,7 +2663,7 @@ "SCSI generic support". config SHAPER - tristate "Traffic Shaper (EXPERIMENTAL)" + tristate "Traffic Shaper (OBSOLETE)" depends on EXPERIMENTAL ---help--- The traffic shaper is a virtual network device that allows you to - 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] [TRIVIAL] prism54/islpci_eth.c: dev_kfree_skb in irq context
> 2) I still do not understand this. Quote from the definition > of dev_kfree_skb_irq - > > /* Use this variant when it is known for sure that it > * is executing from interrupt context. > */ Should this comment should be ammended to include the interrupt disabled case? Graham - 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: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann <[EMAIL PROTECTED]> Date: Thu, 19 Jan 2006 01:57:37 +0100 > I'm not that familiar with the process for non-driver patches for > netdev (nor for device drivers as it seems ;-)), but my > understanding is that you should address those to Jeff Garzik as > well, asking for inclusion in the netdev-2.6 git tree in your > introductory '[PATCH 0/4]' mail. Those should be CC:'d to me, not Jeff, he has enough to review and merge :) - 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] Remove MANY unneeded header files in net/core/filter.c
On Wed, Jan 18, 2006 at 04:55:39PM -0800, Kris Katterjohn wrote:
>
> > > -#include
> >
> > We need this for skb->dev->ifindex.
>
> But we know we have struct net_device because it's used in linux/skbuff.h (for
> skb->dev of course). I'm not saying it doesn't make sense, just that it seems
> to
> me that it's probably not needed. No matter, though.
You can't rely on that because linux/skbuff.h may only provide a forward
declaration for the structure.
--
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: 32 bit (socket layer) ioctl emulation for 64 bit kernels
Am Wednesday 18 January 2006 07:56 schrieb Shaun Pereira: > Assuming you are happy with the state of the patches, is there anyway > for me to know if they will become a part of the next release? I don't see any more technical problems with your patches. You still need to proper patch description and Signed-off-by: line like it is described in Documentation/SubmittingPatches. You can add an 'Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>' line to the four patches you posted last if you like. > Usually submitted/reviewed patches to netdev does not not always > guarantee they will be acccepted/signed-off. > Any advice would be useful I'm not that familiar with the process for non-driver patches for netdev (nor for device drivers as it seems ;-)), but my understanding is that you should address those to Jeff Garzik as well, asking for inclusion in the netdev-2.6 git tree in your introductory '[PATCH 0/4]' mail. Since the official merge window for 2.6.16 is now over (2.6.16-rc1 has been released), it may have to wait for 2.6.17 to become part of the mainline kernel, that probably depends on Jeffs judgement. I would think it can still go in since it is a bug fix for the execution of 32 bit programs using x25 ioctls, but it's clearly not my decision ;-). Arnd <>< - 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] Remove MANY unneeded header files in net/core/filter.c
From: Herbert Xu Sent: 1/18/2006 4:02:18 PM > On Wed, Jan 18, 2006 at 02:15:37PM -0800, Kris Katterjohn wrote: > > > > #include > > #include > > -#include > > OK. > > > -#include > > Needed for GFP_*. Replace this with gfp.h if you want. > > > -#include > > -#include > > -#include > > -#include > > OK. > > > -#include > > We need this for skb->dev->ifindex. But we know we have struct net_device because it's used in linux/skbuff.h (for skb->dev of course). I'm not saying it doesn't make sense, just that it seems to me that it's probably not needed. No matter, though. > > -#include > > -#include > > -#include > > OK. > > > -#include > > OK, but you should add linux/spinlock.h. > > > -#include > > +#include > > +#include > > +#include > > Looks good. > > Thanks, All righty then. Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]> --- x/net/core/filter.c 2006-01-18 18:28:44.0 -0600 +++ y/net/core/filter.c 2006-01-18 18:28:33.0 -0600 @@ -18,21 +18,15 @@ #include #include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include #include +#include #include #include -#include -#include +#include +#include +#include +#include #include #include - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
From: Ben Greear <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 16:35:28 -0800 > We've had worse kernel bugs in official releases! Please document the change that made it into an official release that broke every user of a given piece of hardware, regardless of kernel configuration or chip revision of said hardware, and was performed by the vendor of that hardware. It doesn't happen, because vendors know they will get lynched if they don't at least reboot into the changes they are submitting and perform basic smoke tests. It doesn't happen unless you exert zero testing on your changes and all the vendors have been giving me an earfull in the past about how good quality control is only really obtainable if the vendor maintains the Linux driver. And this just proves such claims dead wrong and that vendors do cut corners. They make the same mistakes any non-vendor maintainer of a device driver might make. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
David S. Miller wrote: It's pretty stupid and counter productive, and in this case here resulted in Intel's engineering process looking rather poor. This e1000 incident is one of the worst vendor driver maintainence bombs I've seen in my 10+ years of doing Linux kernel work. We've had worse kernel bugs in official releases! The e1000 is generally a model of stability and performance, and Intel is one of the few companies with active developers on the mailing lists..so let's not be too critical! 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: e1000 breakage in Jeff's tree
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 19:10:32 -0500 > Its just plain inefficient. I think part of this has to do with Intel's internal legal policies for public code release. It's time consuming and highly encourages the engineers to batch code releases so that they minimize the times they have to go through the legal department. It's pretty stupid and counter productive, and in this case here resulted in Intel's engineering process looking rather poor. This e1000 incident is one of the worst vendor driver maintainence bombs I've seen in my 10+ years of doing Linux kernel work. If they don't fix their process and policies for external code releases, this "massive code drop" problem will never go away. - 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] bonding: allow bond to use TSO if slaves support it
On Wed, 18 Jan 2006, David S. Miller wrote: > > I thought we had fixed this already? Guess now :) > There was a patch some months ago to allow a bonding device to use zero-copy if all its slaves did - same idea (and implemented with the same code.) -- Arthur - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
From: "Ronciak, John" <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 15:46:24 -0800 > What was tested was the entire patch set which included the pre-fetch > patch. Therefore, you sent patches you know you had to make major surgery to before submission compared to what you actually tested. You submitted patches you did not test, period. There is never a good reason for this. And what happened here, e1000 broke for everyone, is a perfect reason why. Stop trying to defend yourselves, it looks really bad. How about: "We screwed up, sorry we won't do that again." - 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: how to obtain detailed e1000 stats?
shemminger wrote: It makes no sense to extend ethtool for something generic like that. It shouldn't be that hard to do netlink in some richer scripting language (like perl), but I haven't tried. If you're using perl, you've already given up performance, so just parse /proc/net/dev. I implemented my patch to more efficiently (and easily) grab the stats for 250 interfaces every few seconds. 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: e1000 breakage in Jeff's tree
Ronciak, John wrote: What was tested was the entire patch set which included the pre-fetch patch. Since there so much controversy over the pre-fetch patch let last time we moved that patch to the end of the patch set. Then we asked ourselves if we should send that patch out at all. We decided not to stir things up and leave that last patch (pre-fetch) out. This is what broke the patch set. So to make it less controversial we used the patch except we removed the actual pre-fetch calls from the patch and is now what has applied. We do test the patch sets before they go out but this time because of what has been happening we really needed to get them accepted so we pulled that one out. This was a mistake on our part but we were trying to do what was best all the way around. We should have also tested without that last patch applied which we didn't do. We would have obviously caught this if we did. This didn't prove anything, we just wanted to explain what happened. We are sorry for the thrash. We are working on other policies and procedures to help stop things like this from happening in the future. The ideal situation would be to send out patches as soon as they are created by the engineer. Maintain them publicly somewhere (preferably netdev-2.6.git#e1000). This gives developers ample time to review your work, and exposes the code to the largest Q/A lab in the world (the Internet). If patches need to be revised or even deleted from the queue, that's easy enough. Once changes are "cooked" sufficiently, we can push them upstream. Infrequent code drops just don't work, and we all waste valuable time rediffing and chasing kernel versions. I'm having this problem with the wireless side of Intel as well. Sourceforge download pages get updated with new driver versions, with the Linux kernel actually seeing associated patch submissions weeks, sometimes months later. Each code drop is a huge set of patches, and things come to a grinding halt while the dust settles, reconciling upstream changes with out-of-tree vendor changes. Its just plain inefficient. We already have processes in place, in Linux, to Q/A new code, and merge it into the codebase at a [moderately] sane pace. I would love it if Intel would embrace these processes, rather than inventing your own. We all want the same things... keeping the driver stable, supporting new hardware, improving performance where possible. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to obtain detailed e1000 stats?
Roberto Nibali wrote: + * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h + * get_rx_all: Return 1 if set, 0 if not. + * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h + * get_save_fcs: Return 1 if set, 0 if not. Something we would like to have in the standard kernel? I'd love to see them in the kernel..I have cooresponding patches for e100 and e1000 to support these features as well. However, the e1000 maintainers were not interested last I checked... I reckon we have new e1000 maintainers :). Is a 2.6.x version ready? Yep, it's not a big change..and the critical piece came from in Intel person originally. They just don't want to deal with the testing effort since few people would use this feature... On the longer run, well, the IFF_ACCEPT_ALL_FRAMES to me right now is more of academic (pktgen et al) value and regarding IFF_SAVE_FCS I'm not sure how people would use it. I don't see how not having IFF_ACCEPT_ALL_FRAMES would reap VLAN/priority information? Wouldn't this be a bug in tcpdump? Also how does the frame accounting work using this flag? Bad frames are still incremented in the stats, despite the kernel handling those frames. Accept all frames just tells the NIC to send up pkts with busted CRC and other errors that would normally cause the pkt to be dropped. Good for sniffing..probably bad for normal processing. If you use this with the SAVE_FCS option, then ethereal (and probably others) can receive a pkt with bad CRC and show you the CRC. It does not break normal packet processing. It is likely to break bridging untill/unless bridging has a tweak to realize to drop the last 4 bytes before sending... Regarding IFF_SAVE_FCS I could see a problem with handling the skb for NICs that do no have this flag set. It would break horribly or you would need to invent IFF_SEND_ALL_FRAMES. I have another patch that allows you to specify the 4-byte ethernet CRC on the end of a packet..that is what you are suggesting I believe. I used this to purposefully generate bogus packets to test the rx-all and save-fcs. This feature is also useful for network testing applications, perhaps for research into alternative crc methods..but otherwise pretty much useless. It could be used in conjunction with rx-fcs and bridging if you really wanted to. Slightely OT: What's the status of your VLAN MAC work? Is this for submission as well? Works good..would like to see it included..but it uses IOCTL interface and /proc, both of which are frowned upon by the powers that be. Other than it's use of un-cool API, it works just fine and has for several years. Meanwhile I've found your work on your OSS part of candelatech. Very interesting to me. Yep..my consolidated patches are there... A 2.6.15 patch will show up when I figure out why pktgen is crashing on 2.6.15.. Take it easy, 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: [PATCH] Remove MANY unneeded header files in net/core/filter.c
On Wed, Jan 18, 2006 at 02:15:37PM -0800, Kris Katterjohn wrote:
>
> #include
> #include
> -#include
OK.
> -#include
Needed for GFP_*. Replace this with gfp.h if you want.
> -#include
> -#include
> -#include
> -#include
OK.
> -#include
We need this for skb->dev->ifindex.
> -#include
> -#include
> -#include
OK.
> -#include
OK, but you should add linux/spinlock.h.
> -#include
> +#include
> +#include
> +#include
Looks good.
Thanks,
--
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: how to obtain detailed e1000 stats?
On Wed, 2006-01-18 at 14:37 -0800, Ben Greear wrote: > Roberto Nibali wrote: > >>> It looks like the e1000 driver gathers all kinds of stats. How do I > >>> access these from userspace? > >> > >> > >> /proc/net/dev will have many of the common ones, and ethtool should > >> get the rest. > >> > >> If you want a hack, I have a patch against the ethtool logic that > >> allows user-space to grab the netdev->stats struct and copy it > >> directly to user-space. This is easier and most likely more efficient > >> than parsing the /proc/net/dev file. > > > > > > Yes, please ;). I'd be interested in this patch as well. > > I'm manually pasting this out of my consolidated patch..it's against 2.6.15. > You should be able to ignore the send-to-self and crc related logic w/out > incident. > > If this won't work, I can send you a link to my full patch, but it has a lot > more than just this netdev stats hack in it It makes no sense to extend ethtool for something generic like that. It shouldn't be that hard to do netlink in some richer scripting language (like perl), but I haven't tried. - 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: how to obtain detailed e1000 stats?
Hmmm, most (if not all) of those you get using netlink, like so for example: ip -s -s link show dev eth0 But I see the incentive to add those to ethtool as well. Yes, I think you can get everything out of netlink..but I find the ethtool API much easier to use... I envision one tool to configure network related things through all OSI layers one day ;). The netlink API is not simple at first sight, however offers much benefit in long terms, I believe. + * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h + * get_rx_all: Return 1 if set, 0 if not. + * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h + * get_save_fcs: Return 1 if set, 0 if not. Something we would like to have in the standard kernel? I'd love to see them in the kernel..I have cooresponding patches for e100 and e1000 to support these features as well. However, the e1000 maintainers were not interested last I checked... I reckon we have new e1000 maintainers :). Is a 2.6.x version ready? On the longer run, well, the IFF_ACCEPT_ALL_FRAMES to me right now is more of academic (pktgen et al) value and regarding IFF_SAVE_FCS I'm not sure how people would use it. I don't see how not having IFF_ACCEPT_ALL_FRAMES would reap VLAN/priority information? Wouldn't this be a bug in tcpdump? Also how does the frame accounting work using this flag? Bad frames are still incremented in the stats, despite the kernel handling those frames. Regarding IFF_SAVE_FCS I could see a problem with handling the skb for NICs that do no have this flag set. It would break horribly or you would need to invent IFF_SEND_ALL_FRAMES. Slightely OT: What's the status of your VLAN MAC work? Is this for submission as well? Thanks for this patch, I wonder if this should be integrated into ethtool per default? Again..I'd love to see it in Meanwhile I've found your work on your OSS part of candelatech. Very interesting to me. Cheers, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: e1000 breakage in Jeff's tree
What was tested was the entire patch set which included the pre-fetch patch. Since there so much controversy over the pre-fetch patch let last time we moved that patch to the end of the patch set. Then we asked ourselves if we should send that patch out at all. We decided not to stir things up and leave that last patch (pre-fetch) out. This is what broke the patch set. So to make it less controversial we used the patch except we removed the actual pre-fetch calls from the patch and is now what has applied. We do test the patch sets before they go out but this time because of what has been happening we really needed to get them accepted so we pulled that one out. This was a mistake on our part but we were trying to do what was best all the way around. We should have also tested without that last patch applied which we didn't do. We would have obviously caught this if we did. This didn't prove anything, we just wanted to explain what happened. We are sorry for the thrash. We are working on other policies and procedures to help stop things like this from happening in the future. Cheers, John --- "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.", Benjamin Franklin 1755 > -Original Message- > From: David S. Miller [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 18, 2006 2:29 PM > To: Brandeburg, Jesse > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kirsher, Jeffrey T; > Ronciak, John; netdev@vger.kernel.org > Subject: Re: e1000 breakage in Jeff's tree > > > From: Jesse Brandeburg <[EMAIL PROTECTED]> > Date: Wed, 18 Jan 2006 14:20:28 -0800 (Pacific Standard Time) > > > The root cause of the bug is that the receive routine was > in a bad state > > because we didn't submit our prefetch patch, which > unfortunately didn't > > have just prefetchy things in it. > > So did you actually test the original patches set you sent out? > > Because of how it fails, and the fact that this basically broke > e1000 for everyone, it is impossible for me to see a way in > which you actually tested the patches you submitted yet still > this bug slipped through. > > Prove me wrong. :-) > - 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] PCI Error Recovery: e100 network device driver
Hi Jeff,
Please review, apply and forward upstream as appropriate.
--linas
[PATCH] PCI Error Recovery: e100 network device driver
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 <[EMAIL PROTECTED]>
---
commit 414eee4fa72175d3c0be116d6cb8b0634e4ae916
tree e1cc342377037142e0fd46f89b4cabaa3bb12adb
parent 113cc803a20d72ee5e3c92302ac5a06e0c651d01
author linas <[EMAIL PROTECTED]> Fri, 18 Nov 2005 16:23:26 -0600
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 05 Jan 2006 21:54:55 -0800
drivers/net/e100.c | 70
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 22cd045..095d953 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2704,6 +2704,75 @@ static void e100_shutdown(struct pci_dev
}
+/* -- PCI Error Recovery infrastructure -- */
+/** e100_io_error_detected() is called when PCI error is detected */
+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);
+
+ /* Same as calling e100_down(netdev_priv(netdev)), but generic */
+ netdev->stop(netdev);
+
+ /* Is a detach needed ?? */
+ // netif_device_detach(netdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/** e100_io_slot_reset is called after the pci bus has been reset.
+ * 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);
+
+ if(e100_hw_init(nic)) {
+ DPRINTK(HW, ERR, "e100_hw_init failed\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/** e100_io_resume is called when the error recovery driver
+ * tells us that its OK to resume normal operation.
+ */
+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,
.id_table = e100_id_table,
@@ -2714,6 +2783,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)
- End forwarded message -
-
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] PCI Error Recovery: e1000 network device driver
Hi Jeff,
Please review, apply and forward this patch upstream,
as appropriate.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
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.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
commit 113cc803a20d72ee5e3c92302ac5a06e0c651d01
tree aae6aa3b20f14a36eba84867c2406cbe385affad
parent 5a02e3abf1e74c159deca91d6af01297379eede7
author linas <[EMAIL PROTECTED]> Fri, 18 Nov 2005 16:23:54 -0600
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 05 Jan 2006 21:54:55 -0800
drivers/net/e1000/e1000_main.c | 101
1 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 438a931..76352fe 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -206,6 +206,16 @@ static void e1000_netpoll (struct net_de
void e1000_rx_schedule(void *data);
#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,
+};
+
/* Exported from other modules */
extern void e1000_check_options(struct e1000_adapter *adapter);
@@ -218,8 +228,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, <[EMAIL PROTECTED]>");
@@ -2941,6 +2952,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,
@@ -4331,4 +4346,88 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/* --- PCI Error Recovery infrastructure */
+/** e1000_io_error_detected() is called when PCI error is 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;
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/** e1000_io_slot_reset is called after the pci bus has been reset.
+ * Restart the card from scratch.
+ * 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(0 != PCI_FUNC (pdev->devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(&adapter->hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/** e1000_io_resume 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("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);
+
[PATCH] PCI Error Recovery: ixgb network device driver
Jeff,
Please review, apply and forward upstream the patch below,
for the Intel ixgb driver. Similar patches for the Intel e1000
and e100 to follow shortly.
--linas
On Wed, Jan 18, 2006 at 02:13:55PM -0800, Ronciak, John was heard to remark:
> Patches for e100, e1000 and ixgb need to go out to netdev and Jeff
> Garzik. We are co-maintainers with him. Jeff is the one who puts them
> into the actual kernel tree source however.
>
> > > > From: linas [mailto:[EMAIL PROTECTED]
> > > >
> > > > I'm trying to get this patch, and related patches for
> > > > the e100 and e1000, submitted into the mainline kernel.
> > > > I'd previously submitted these to GregKH, together with
> > > > some related patches; Jesse Brandeburg was kind enough
> > > > to ack them recently.
> > > >
> > > >
- Forwarded message from Greg KH <[EMAIL PROTECTED]> -
Subject: [PATCH] PCI Error Recovery: ixgb network device driver
In-Reply-To: <[EMAIL PROTECTED]>
X-Mailer: gregkh_patchbomb
Date: Thu, 5 Jan 2006 22:38:34 -0800
Message-Id: <[EMAIL PROTECTED]>
Reply-To: Greg K-H <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
From: Greg KH <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
[PATCH] PCI Error Recovery: ixgb network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ten-gigabit
ethernet ixgb device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 3c0006afdd8ade574257c88df81c93b0bb71b544
tree 4cc697ccc74b8d67a9f08e68f71584f9d538e90e
parent d78cde68ab78766c3a175466aa8adcbdc5520963
author linas <[EMAIL PROTECTED]> Fri, 18 Nov 2005 16:24:20 -0600
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 05 Jan
2006 21:54:55 -0800
drivers/net/ixgb/ixgb_main.c | 86
++
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c
b/drivers/net/ixgb/ixgb_main.c
index f9f77e4..166832c 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -132,6 +132,16 @@ static void ixgb_restore_vlan(struct ixg
static void ixgb_netpoll(struct net_device *dev);
#endif
+static pci_ers_result_t ixgb_io_error_detected (struct
pci_dev *pdev, pci_channel_state_t state);
+static pci_ers_result_t ixgb_io_slot_reset (struct pci_dev *pdev);
+static void ixgb_io_resume (struct pci_dev *pdev);
+
+static struct pci_error_handlers ixgb_err_handler = {
+ .error_detected = ixgb_io_error_detected,
+ .slot_reset = ixgb_io_slot_reset,
+ .resume = ixgb_io_resume,
+};
+
/* Exported from other modules */
extern void ixgb_check_options(struct ixgb_adapter *adapter);
@@ -141,6 +151,8 @@ static struct pci_driver ixgb_driver = {
.id_table = ixgb_pci_tbl,
.probe= ixgb_probe,
.remove = __devexit_p(ixgb_remove),
+ .err_handler = &ixgb_err_handler,
+
};
MODULE_AUTHOR("Intel Corporation, <[EMAIL PROTECTED]>");
@@ -1654,8 +1666,16 @@ ixgb_intr(int irq, void *data, struct pt
unsigned int i;
#endif
+#ifdef XXX_CONFIG_IXGB_EEH_RECOVERY
+ if(unlikely(icr==EEH_IO_ERROR_VALUE(4))) {
+ if (eeh_slot_is_isolated (adapter->pdev))
+ // disable_irq_nosync (adapter->pdev->irq);
+ return IRQ_NONE; /* Not our interrupt */
+ }
+#else
if(unlikely(!icr))
return IRQ_NONE; /* Not our interrupt */
+#endif /* CONFIG_IXGB_EEH_RECOVERY */
if(unlikely(icr & (IXGB_INT_RXSEQ | IXGB_INT_LSC))) {
mod_timer(&adapter->watchdog_timer, jiffies);
@@ -2125,4 +2145,70 @@ static void ixgb_netpoll(struct net_devi
}
#endif
+/* -- PCI Error Recovery infrastructure */
+/** ixgb_io_error_detected() is called when PCI error is detected */
+static pci_ers_result_t ixgb_io_error_detected (struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ixgb_adapter *adapter = netdev->priv;
+
+ if(netif_running(netdev))
+ ixgb_down(adapter, TRUE);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/** ixgb_io_slot_reset is called after the pci bus has been reset.
+ * Restart the card from scratch.
+ * Implementation resembles the first-half of the
+ * ixgb_resume routine.
+ */
+static pci_ers_result_t ixgb_io_slot_reset (struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ixgb_adapter *adapter = netdev->priv;
+
+ if(pci_enable_device(pdev)) {
+ printk(KERN_ERR "ixgb: Cannot re-enable PCI device after
reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ /* Perform card reset only on one instance of the card */
+ if (0 != PCI_FUNC (pdev->devfn))
+
Re: how to obtain detailed e1000 stats?
Roberto Nibali wrote: Hmmm, most (if not all) of those you get using netlink, like so for example: ip -s -s link show dev eth0 But I see the incentive to add those to ethtool as well. Yes, I think you can get everything out of netlink..but I find the ethtool API much easier to use... + * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h + * get_rx_all: Return 1 if set, 0 if not. + * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h + * get_save_fcs: Return 1 if set, 0 if not. Something we would like to have in the standard kernel? I'd love to see them in the kernel..I have cooresponding patches for e100 and e1000 to support these features as well. However, the e1000 maintainers were not interested last I checked... Thanks for this patch, I wonder if this should be integrated into ethtool per default? Again..I'd love to see it in 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: how to obtain detailed e1000 stats?
I'm manually pasting this out of my consolidated patch..it's against
2.6.15.
You should be able to ignore the send-to-self and crc related logic
w/out incident.
If this won't work, I can send you a link to my full patch, but it has a
lot
more than just this netdev stats hack in it
Thanks, this ought to do it.
Here is how you use it in user-space:
struct my_net_device_stats_32 {
uint32 rx_packets;/* total packets received*/
uint32 tx_packets;/* total packets transmitted*/
uint32 rx_bytes;/* total bytes received */
uint32 tx_bytes;/* total bytes transmitted*/
uint32 rx_errors;/* bad packets received*/
uint32 tx_errors;/* packet transmit problems*/
uint32 rx_dropped;/* no space in linux buffers*/
uint32 tx_dropped;/* no space available in linux*/
uint32 multicast;/* multicast packets received*/
uint32 collisions;
/* detailed rx_errors: */
uint32 rx_length_errors;
uint32 rx_over_errors;/* receiver ring buff overflow*/
uint32 rx_crc_errors;/* recved pkt with crc error*/
uint32 rx_frame_errors;/* recv'd frame alignment error */
uint32 rx_fifo_errors;/* recv'r fifo overrun*/
uint32 rx_missed_errors;/* receiver missed packet*/
/* detailed tx_errors */
uint32 tx_aborted_errors;
uint32 tx_carrier_errors;
uint32 tx_fifo_errors;
uint32 tx_heartbeat_errors;
uint32 tx_window_errors;
/* for cslip etc */
uint32 rx_compressed;
uint32 tx_compressed;
};
Hmmm, most (if not all) of those you get using netlink, like so for example:
ip -s -s link show dev eth0
But I see the incentive to add those to ethtool as well.
+ * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h
+ * get_rx_all: Return 1 if set, 0 if not.
+ * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h
+ * get_save_fcs: Return 1 if set, 0 if not.
Something we would like to have in the standard kernel?
+/* 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;
+}
Simple enough.
int dev_ethtool(struct ifreq *ifr)
@@ -793,18 +881,28 @@ int dev_ethtool(struct ifreq *ifr)
if (!dev || !netif_device_present(dev))
return -ENODEV;
-if (!dev->ethtool_ops)
-goto ioctl;
-
if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd)))
return -EFAULT;
-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)
+ goto ioctl;
+
switch (ethcmd) {
case ETHTOOL_GSET:
Thanks for this patch, I wonder if this should be integrated into
ethtool per default?
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
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] bonding: allow bond to use TSO if slaves support it
From: Arthur Kepner <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 14:37:57 -0800 (PST) > Add NETIF_F_TSO to BOND_INTERSECT_FEATURES so that it can be > used by a bonding device iff all its slave devices support TSO. > > Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]> I thought we had fixed this already? Guess now :) Jeff, you got 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 2/2] MAINTAINERS: add entry for wireless networking
Both applied, thanks John. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
Jesse Brandeburg <[EMAIL PROTECTED]> wrote: > > On Wed, 18 Jan 2006, Andrew Morton wrote: > > git-bisect of mainline claims that the regression was introduced by commit > > 0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance". > > Jeff(K), I can test patches... > > it appears git bisect is wrong, there is nothing in that patch that would > have broken the receives. I didn't determine whether rx or tx were failing, or both. But yes, when I reverted just that change, it didn't fix things. So perhaps I did again screw up the bisecting. But I did it very carefully. Or perhaps that patch did indeed break tx or rx, and there was another, later patch which also broke tx or rx. > however i believe that is a side issue. > > the 0-8 patchset that I sent earlier today should *finish* the application > of our patch series, and also fix the bug you noticed. > > The root cause of the bug is that the receive routine was in a bad state > because we didn't submit our prefetch patch, which unfortunately didn't > have just prefetchy things in it. > > yuck. anyway please let us know if the new patches work better for you. Yes, today's e1000 update fixes the problem I was seeing, 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
[PATCH] bonding: allow bond to use TSO if slaves support it
Add NETIF_F_TSO to BOND_INTERSECT_FEATURES so that it can be
used by a bonding device iff all its slave devices support TSO.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
Arthurdiff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1145,7 +1145,8 @@ int bond_sethwaddr(struct net_device *bo
}
#define BOND_INTERSECT_FEATURES \
- (NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM)
+ (NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM|\
+ NETIF_F_TSO)
/*
* Compute the common dev->feature set available to all slaves. Some
@@ -4080,6 +4081,7 @@ static void bond_ethtool_get_drvinfo(str
static struct ethtool_ops bond_ethtool_ops = {
.get_tx_csum= ethtool_op_get_tx_csum,
+ .get_tso= ethtool_op_get_tso,
.get_sg = ethtool_op_get_sg,
.get_drvinfo= bond_ethtool_get_drvinfo,
};
[patch 1/2] MAINTAINERS: correct location for net-2.6.git
Correct location info for net-2.6 git tree. Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- MAINTAINERS |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6d1b048..0d0f8a8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1841,7 +1841,7 @@ M:[EMAIL PROTECTED] P: Patrick McHardy M: [EMAIL PROTECTED] L: netdev@vger.kernel.org -T: git kernel.org:/pub/scm/linux/kernel/davem/net-2.6.git +T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git S: Maintained IPVS -- 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: Questions on Chelsio NICs
David S. Miller wrote: From: Ben Greear <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 11:12:54 -0800 Well, to answer myself: I found the problem. Pktgen's multi-skb trick only works if the device makes no change to the skb. But, the cxgb driver pushes a header on the front of the skb... So, you just can't use the multi-skb pktgen option with this driver... That definitely needs some fixing. Such an assumption is very wrong, in general. This would break also with several FDDI drivers, for example. An idea might be to preallocate a ring or list of SKBs, prefill them out, and do that instead of what the current code does. Yep..this breaks not only with chelsio but also with vlans since they change skb->dev on the way down the stack Pre-allocating doesn't help much because at 10Gbe NICs you could very quickly send your entire RAM! Probably the best bet is to use some sort of skb recycling where you quickly switch back skb->dev and the head/tail pointers as soon as the NIC releases it's last reference Thanks, 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
[patch 2/2] MAINTAINERS: add entry for wireless networking
Add an entry to MAINTAINERS for wireless networking, just so people know whom to bless with patches. Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6d1b048..23aca6f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1844,6 +1844,13 @@ L: netdev@vger.kernel.org T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git S: Maintained +NETWORKING [WIRELESS] +P: John W. Linville +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git +S: Maintained + IPVS P: Wensong Zhang M: [EMAIL PROTECTED] -- 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: how to obtain detailed e1000 stats?
Roberto Nibali wrote:
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space to grab the netdev->stats struct and copy it
directly to user-space. This is easier and most likely more efficient
than parsing the /proc/net/dev file.
Yes, please ;). I'd be interested in this patch as well.
I'm manually pasting this out of my consolidated patch..it's against 2.6.15.
You should be able to ignore the send-to-self and crc related logic w/out
incident.
If this won't work, I can send you a link to my full patch, but it has a lot
more than just this netdev stats hack in it
Here is how you use it in user-space:
struct my_net_device_stats_32 {
uint32 rx_packets; /* total packets received */
uint32 tx_packets; /* total packets transmitted*/
uint32 rx_bytes; /* total bytes received */
uint32 tx_bytes; /* total bytes transmitted */
uint32 rx_errors;/* bad packets received */
uint32 tx_errors;/* packet transmit problems */
uint32 rx_dropped; /* no space in linux buffers*/
uint32 tx_dropped; /* no space available in linux */
uint32 multicast;/* multicast packets received */
uint32 collisions;
/* detailed rx_errors: */
uint32 rx_length_errors;
uint32 rx_over_errors; /* receiver ring buff overflow */
uint32 rx_crc_errors;/* recved pkt with crc error*/
uint32 rx_frame_errors; /* recv'd frame alignment error */
uint32 rx_fifo_errors; /* recv'r fifo overrun */
uint32 rx_missed_errors; /* receiver missed packet */
/* detailed tx_errors */
uint32 tx_aborted_errors;
uint32 tx_carrier_errors;
uint32 tx_fifo_errors;
uint32 tx_heartbeat_errors;
uint32 tx_window_errors;
/* for cslip etc */
uint32 rx_compressed;
uint32 tx_compressed;
};
struct cmd_my_net_device_stats_32 {
uint32 ecmd; /* ethtool command */
struct my_net_device_stats_32 stats_32;
};
struct cmd_my_net_device_stats_32 cmd_stats_32;
memset(&cmd_stats_32, 0, sizeof(cmd_stats_32));
struct ifreq ifr;
int fd = socket(PF_INET, SOCK_DGRAM, 0);
if (fd < 0) {
cerr << "ERROR: socket: " << strerror(errno) << endl;
}
else {
memset(&ifr, 0, sizeof(struct ifreq));
strcpy(ifr.ifr_name, dev_name);
ifr.ifr_addr.sa_family = AF_INET;
cmd_stats_32.ecmd = /*ETHTOOL_GNDSTATS*/ 0x70;
ifr.ifr_data = (char*)(&cmd_stats_32);
if (ioctl(fd, SIOCETHTOOL, &ifr) < 0) {
use_gndstats = false;
}
else {
found_one = true;
}
close(fd);
}
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -1,4 +1,4 @@
-/*
+/* -*-linux-c-*-
* ethtool.h: Defines for Linux ethtool.
*
* Copyright (C) 1998 David S. Miller (davem@redhat.com)
@@ -307,7 +307,11 @@ int ethtool_op_set_ufo(struct net_device
* phys_id: Identify the device
* get_stats: Return statistics about the device
* get_perm_addr: Gets the permanent hardware address
- *
+ * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h
+ * get_rx_all: Return 1 if set, 0 if not.
+ * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h
+ * get_save_fcs: Return 1 if set, 0 if not.
+ *
* Description:
*
* get_settings:
@@ -366,12 +370,24 @@ struct ethtool_ops {
int (*get_stats_count)(struct net_device *);
void(*get_ethtool_stats)(struct net_device *, struct ethtool_stats
*, u64 *);
int (*get_perm_addr)(struct net_device *, struct ethtool_perm_addr
*, u8 *);
+ int (*set_rx_all)(struct net_device *, u32);
+ int (*get_rx_all)(struct net_device *, u32 *);
+ int (*set_save_fcs)(struct net_device *, u32);
+ int (*get_save_fcs)(struct net_device *, u32 *);
int (*begin)(struct net_device *);
void(*complete)(struct net_device *);
u32 (*get_ufo)(struct net_device *);
int (*set_ufo)(struct net_device *, u32);
};
+
+/* for dumping net-device statistics */
+struct ethtool_ndstats {
+ u32 cmd;/* ETHTOOL_GNDSTATS */
+ u8 data[0];/* sizeof(struct net_device_stats) */
+};
+
+
/* CMDs currently supported */
#define ETHTOOL_GSET 0x0001 /* Get settings. */
#define ETHTOOL_SSET 0x0002 /* Set settings. */
@@ -409,6 +425,15 @@ struct ethtool_ops {
#define ETHTOOL_GUFO 0x0021 /* Get UFO enable (ethtool_value) */
#define ETHTOOL_SUFO 0x0022 /* Set UFO enable (ethtool_value) */
+
+#define ETHTOOL_GND
Re: IRDA maintainer status
From: Jean Tourrilhes <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 14:24:24 -0800 > They are mostly using BlueTooth nowadays :-( This is not strictly the case, especially in Asia. Most of the current LG and Samsung phones out in South Korea are still IRDA. In fact my USA Samsung E635 is IRDA and not bluetooth. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
From: Jesse Brandeburg <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 14:20:28 -0800 (Pacific Standard Time) > The root cause of the bug is that the receive routine was in a bad state > because we didn't submit our prefetch patch, which unfortunately didn't > have just prefetchy things in it. So did you actually test the original patches set you sent out? Because of how it fails, and the fact that this basically broke e1000 for everyone, it is impossible for me to see a way in which you actually tested the patches you submitted yet still this bug slipped through. Prove me wrong. :-) - 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: [GIT PATCHES] TIPC fixes
From: Per Liden <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 01:52:40 +0100 (CET) > Here is a set of patches in response to the initial criticism/comments > that TIPC received. > > The reason why these patches touch so many files is the fix to avoid > namespace pullution. Please see diffstat and commit log below. > > Please pull from: > > git://tipc.cslab.ericsson.net/pub/git/tipc.git > > Thanks > /Per Pulled, 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: IRDA maintainer status
On Wed, Jan 18, 2006 at 02:07:18PM -0800, David S. Miller wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Wed, 18 Jan 2006 10:52:26 -0800 > > > Dave, Jean says he really doesn't have time to much IRDA any more. > > The following would help motivate someone who has more time. > > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > Applied. > > We need to find some cell phone maniac or somthing :-) They are mostly using BlueTooth nowadays :-( 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] Fix multiple bugs in IGMPv3
From: David Stevens <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 15:17:24 -0700 > The below "jumbo" patch fixes the following problems in IGMPv3. Looks good, applied. Thanks David. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 breakage in Jeff's tree
On Wed, 18 Jan 2006, Andrew Morton wrote: git-bisect of mainline claims that the regression was introduced by commit 0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance". Jeff(K), I can test patches... it appears git bisect is wrong, there is nothing in that patch that would have broken the receives. however i believe that is a side issue. the 0-8 patchset that I sent earlier today should *finish* the application of our patch series, and also fix the bug you noticed. The root cause of the bug is that the receive routine was in a bad state because we didn't submit our prefetch patch, which unfortunately didn't have just prefetchy things in it. yuck. anyway please let us know if the new patches work better for you. Thanks, Jesse - 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: Questions on Chelsio NICs
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 17:01:46 -0800
> int rsrv = (odev->hard_header_len + 16) & ~0xF;
>
>
> skb = alloc_skb(info->cur_pkt_size + 64 + rsrv, GFP_ATOMIC);
>
>
> /* Make some extra space, align on 16-byte boundary
>* (helps Chelsio) Used to be just a default 16 for
>* everyone...
>*/
> skb_reserve(skb, rsrv);
Thanks for pointing this out, I've checked in the following fix.
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 3827f88..da16f8f 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -1860,13 +1860,14 @@ static struct sk_buff *fill_packet_ipv4(
*/
mod_cur_headers(pkt_dev);
- skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + 16, GFP_ATOMIC);
+ datalen = (odev->hard_header_len + 16) & ~0xf;
+ skb = alloc_skb(pkt_dev->cur_pkt_size + 64 + datalen, GFP_ATOMIC);
if (!skb) {
sprintf(pkt_dev->result, "No memory");
return NULL;
}
- skb_reserve(skb, 16);
+ skb_reserve(skb, datalen);
/* Reserve for ethernet and IP header */
eth = (__u8 *) skb_push(skb, 14);
-
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] Remove MANY unneeded header files in net/core/filter.c
From: Herbert Xu Sent: 1/18/2006 12:26:12 PM > On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote: > > > > Since it can't be a module and is always built in, we can just remove the > > EXPORT_SYMBOL()s, right? > > No, these are there so that other modules can use these symboles. Okay, gotcha. I went through again and I'm pretty confident in this patch. I added a few headers, some of which whose #includes were nested 2/3 files into others. Let me know what you think (or if you see any obvious screwups). Thanks! --- x/net/core/filter.c 2006-01-18 16:08:42.0 -0600 +++ y/net/core/filter.c 2006-01-18 16:08:36.0 -0600 @@ -18,21 +18,12 @@ #include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include #include #include #include -#include -#include +#include +#include +#include #include #include - 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: [git patches] e1000 fixes
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Let's see how this goes... if there are further problems, I'll just > revert the entire thing, and push these changes (and the previous set) > into upstream-2.6.17 branch. > > I don't mind them updating the defconfig files, even though most people > are too slack to worry about it, since its pretty clear the default > choice. > > > Please pull from 'upstream-fixes' branch of > master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git These patches fix e1000 for me, 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
[PATCH] Fix multiple bugs in IGMPv3
The below "jumbo" patch fixes the following problems in IGMPv3.
1) fix "mld_marksources()" to
a) send nothing when all queried sources are excluded
b) send full exclude report when source queried sources are
not excluded
c) don't schedule a timer when there's nothing to report
2) fix "add_grec()" to send empty-source records when it should
The original check doesn't account for a non-empty source
list with all sources inactive; the new code keeps that
short-circuit case, and also generates the group header
with an empty list if needed.
3) fix mca_crcount decrement to be after add_grec(), which needs
its original value
4) add/remove delete records and prevent current advertisements
when an exclude-mode filter moves from "active" to "inactive"
or vice versa based on new filter additions.
Items 1-3 are just IPv4 versions of the IPv6 bugs found
by Yan Zheng and fixed earlier. Item #4 is a related bug that
affects exclude-mode change records only (but not queries) and
also occurs in IPv6 (IPv6 version coming soon).
+-DLS
[in-line for viewing, attached for applying]
Signed-off-by: David L Stevens <[EMAIL PROTECTED]>
diff -ruNp linux-2.6.15/net/ipv4/igmp.c linux-2.6.15IGMP1/net/ipv4/igmp.c
--- linux-2.6.15/net/ipv4/igmp.c2006-01-02 19:21:10.0
-0800
+++ linux-2.6.15IGMP1/net/ipv4/igmp.c 2006-01-17 16:08:42.0
-0800
@@ -231,7 +231,18 @@ static int is_in(struct ip_mc_list *pmc,
case IGMPV3_MODE_IS_EXCLUDE:
if (gdeleted || sdeleted)
return 0;
- return !(pmc->gsquery && !psf->sf_gsresp);
+ if (!(pmc->gsquery && !psf->sf_gsresp)) {
+ if (pmc->sfmode == MCAST_INCLUDE)
+ return 1;
+ /* don't include if this source is excluded
+* in all filters
+*/
+ if (psf->sf_count[MCAST_INCLUDE])
+ return type == IGMPV3_MODE_IS_INCLUDE;
+ return pmc->sfcount[MCAST_EXCLUDE] ==
+ psf->sf_count[MCAST_EXCLUDE];
+ }
+ return 0;
case IGMPV3_CHANGE_TO_INCLUDE:
if (gdeleted || sdeleted)
return 0;
@@ -383,7 +394,7 @@ static struct sk_buff *add_grec(struct s
struct igmpv3_report *pih;
struct igmpv3_grec *pgr = NULL;
struct ip_sf_list *psf, *psf_next, *psf_prev, **psf_list;
- int scount, first, isquery, truncate;
+ int scount, stotal, first, isquery, truncate;
if (pmc->multiaddr == IGMP_ALL_HOSTS)
return skb;
@@ -393,25 +404,13 @@ static struct sk_buff *add_grec(struct s
truncate = type == IGMPV3_MODE_IS_EXCLUDE ||
type == IGMPV3_CHANGE_TO_EXCLUDE;
+ stotal = scount = 0;
+
psf_list = sdeleted ? &pmc->tomb : &pmc->sources;
- if (!*psf_list) {
- if (type == IGMPV3_ALLOW_NEW_SOURCES ||
- type == IGMPV3_BLOCK_OLD_SOURCES)
- return skb;
- if (pmc->crcount || isquery) {
- /* make sure we have room for group header and at
-* least one source.
-*/
- if (skb && AVAILABLE(skb) < sizeof(struct
igmpv3_grec)+
- sizeof(__u32)) {
- igmpv3_sendpack(skb);
- skb = NULL; /* add_grhead will get a new
one */
- }
- skb = add_grhead(skb, pmc, type, &pgr);
- }
- return skb;
- }
+ if (!*psf_list)
+ goto empty_source;
+
pih = skb ? (struct igmpv3_report *)skb->h.igmph : NULL;
/* EX and TO_EX get a fresh packet, if needed */
@@ -424,7 +423,6 @@ static struct sk_buff *add_grec(struct s
}
}
first = 1;
- scount = 0;
psf_prev = NULL;
for (psf=*psf_list; psf; psf=psf_next) {
u32 *psrc;
@@ -458,7 +456,7 @@ static struct sk_buff *add_grec(struct s
}
psrc = (u32 *)skb_put(skb, sizeof(u32));
*psrc = psf->sf_inaddr;
- scount++;
+ scount++; stotal++;
if ((type == IGMPV3_ALLOW_NEW_SOURCES ||
type == IGMPV3_BLOCK_OLD_SOURCES) && psf->sf_crcount)
{
psf->sf_crcount--;
@@ -473,6 +471,21 @@ static struct sk_buff *add_grec(struct s
}
psf_prev = psf;
}
+
+empty_source:
+ if (!stotal) {
+ if (type == IGMPV3_ALLOW_NEW_SOURCES ||
+ type == IGMPV3_BLOCK_OLD_SOURCES)
+ return skb;
+ if (pmc->crcount ||
Re: Questions on Chelsio NICs
From: Ben Greear <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 11:12:54 -0800 > Well, to answer myself: I found the problem. Pktgen's multi-skb > trick only works if the device makes no change to the skb. But, the > cxgb driver pushes a header on the front of the skb... > > So, you just can't use the multi-skb pktgen option with this driver... That definitely needs some fixing. Such an assumption is very wrong, in general. This would break also with several FDDI drivers, for example. An idea might be to preallocate a ring or list of SKBs, prefill them out, and do that instead of what the current code does. - 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: IRDA maintainer status
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 18 Jan 2006 10:52:26 -0800 > Dave, Jean says he really doesn't have time to much IRDA any more. > The following would help motivate someone who has more time. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied. We need to find some cell phone maniac or somthing :-) - 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] sk98lin: module table alias
On Wed, Jan 18, 2006 at 11:56:26AM -0800, Stephen Hemminger wrote: > > > Nack. changing module tables in one driver depending on another driver > > > is always bogus. Better send a patch to udev/modutils/whatever > > > maintainers > > > to prefer one over the others. > > Is there really any such stuff in there? > > Talking to myself again... > Newest version of module-init-tools has a nice blacklist feature. > The bigger problem is that module config file seems to be a per-distro thing. For Fedora, I'm taking the easy option for FC5 - disable building sk98lin :-) Over time, I wouldn't be surprised if other distros did the same thing. It doesn't solve the problem for people building their own kernels though. How about kconfig hackery to make only one of them selectable, but both visible (until sk98lin gets removed) ? Dave - 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] Remove MANY unneeded header files in net/core/filter.c
From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 19 Jan 2006 07:26:12 +1100 > On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote: > > > > Since it can't be a module and is always built in, we can just remove the > > EXPORT_SYMBOL()s, right? > > No, these are there so that other modules can use these symboles. Kris, see how hard this is? :-) - 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
Repost [PATCH 3 of 3] ipoib: fix error handling
Sorry about reposting: the message didnt seem to make it to netdev.
---
The following patch is not directly related to the destructor issue,
but I'm posting it here fore completeness since it needs to be applied on top of
the previous pair of patches in the destructor series.
---
Fix error handling in neigh_add_path.
Reduce code duplication by implementing alloc/free functions for ipoib_neigh.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c
===
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12
20:48:06.0 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12
20:48:43.0 +0200
@@ -246,8 +246,7 @@ static void path_free(struct net_device
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
- *to_ipoib_neigh(neigh->neighbour) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -475,7 +474,7 @@ static void neigh_add_path(struct sk_buf
struct ipoib_path *path;
struct ipoib_neigh *neigh;
- neigh = kmalloc(sizeof *neigh, GFP_ATOMIC);
+ neigh = ipoib_neigh_alloc(skb->dst->neighbour);
if (!neigh) {
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -483,8 +482,6 @@ static void neigh_add_path(struct sk_buf
}
skb_queue_head_init(&neigh->queue);
- neigh->neighbour = skb->dst->neighbour;
- *to_ipoib_neigh(skb->dst->neighbour) = neigh;
/*
* We can only be called from ipoib_start_xmit, so we're
@@ -497,7 +494,7 @@ static void neigh_add_path(struct sk_buf
path = path_rec_create(dev,
(union ib_gid *)
(skb->dst->neighbour->ha + 4));
if (!path)
- goto err;
+ goto err_path;
__path_add(dev, path);
}
@@ -527,10 +524,9 @@ static void neigh_add_path(struct sk_buf
return;
err:
- *to_ipoib_neigh(skb->dst->neighbour) = NULL;
list_del(&neigh->list);
- kfree(neigh);
-
+err_path:
+ ipoib_neigh_free(neigh);
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -757,8 +753,7 @@ static void ipoib_neigh_destructor(struc
if (neigh->ah)
ah = neigh->ah;
list_del(&neigh->list);
- *to_ipoib_neigh(n) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -766,6 +761,26 @@ static void ipoib_neigh_destructor(struc
if (ah)
ipoib_put_ah(ah);
}
+
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour)
+{
+ struct ipoib_neigh *neigh;
+
+ neigh = kmalloc(sizeof *neigh, GFP_ATOMIC);
+ if (!neigh)
+ return NULL;
+
+ neigh->neighbour = neighbour;
+ *to_ipoib_neigh(neighbour) = neigh;
+
+ return neigh;
+}
+
+void ipoib_neigh_free(struct ipoib_neigh *neigh)
+{
+ *to_ipoib_neigh(neigh->neighbour) = NULL;
+ kfree(neigh);
+}
static int ipoib_neigh_setup_dev(struct net_device *dev, struct neigh_parms
*parms)
{
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
2006-01-12 20:32:08.0 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-12
20:48:43.0 +0200
@@ -113,8 +113,7 @@ static void ipoib_mcast_free(struct ipoi
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
- *to_ipoib_neigh(neigh->neighbour) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -720,13 +719,11 @@ out:
if (skb->dst&&
skb->dst->neighbour &&
!*to_ipoib_neigh(skb->dst->neighbour)) {
- struct ipoib_neigh *neigh = kmalloc(sizeof *neigh,
GFP_ATOMIC);
+ struct ipoib_neigh *neigh =
ipoib_neigh_alloc(skb->dst->neighbour);
if (neigh) {
kref_get(&mcast->ah->ref);
neigh->ah = mcast->ah;
- neigh->neighbour = skb->dst->neighbour;
- *to_ipoib_neigh(skb->dst->neighbour) = neigh;
list_add_tail(&neigh->list, &mcast->neigh_list);
}
}
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib.h
=
Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms
Quoting Shirley Ma <[EMAIL PROTECTED]>: > Subject: Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms > > > >+ if (neigh->parms->neigh_destructor) > >+ (neigh->parms->neigh_destructor)(neigh); > > Is that safe without checking neigh->parms here? Yes, we have neigh_parms_put(neigh->parms); a couple of lines below. -- MST - 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 RESEND netdev-2.6 1/8] e1000: Added disable packet split capability
Jesse Brandeburg wrote: Adds the ability to disability packet split at compile time and use the legacy receive path on PCI express hardware. Made this a CONFIG option and modified the Kconfig, to reflect the new option. Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> applied 1-8. It's not normally the case that you update other arches defconfigs, but I let it slide in this case. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help with e1000 issue?
On 1/18/06, Christopher Friesen <[EMAIL PROTECTED]> wrote: > > We're seeing an issue with an e1000 device. After some time (4-8 hrs > typically) it jams itself up and refuses to receive any more packets. > > We're running 2.6.10, but with the e1000 driver from 2.6.14. just so you've got all the latest bug fixes can you try the driver from http://prdownloads.sf.net/e1000/e1000-6.3.9.tar.gz I haven't heard any reports of a jammed receiver. see below > Outgoing packets seem to be fine, incoming packets just increment the > error count. > > ethtool device specific stats show the following counters > > rx_fifo_errors: 1714150 > rx_no_buffer_count: 299 > rx_missed_errors: 1714150 > > The fifo and missed errors seem to actually be counting the same thing, > the "Missed Packets Count" error register. yeah thats a problem we've already addresssed. > From the chip docs: > On the jammed device, dumping the registers gives the following, > indicating that the head and tail pointers are equal: > >Receive buffer size: 2048 > 0x02808: RDLEN (Receive desc length) 0x1000 > 0x02810: RDH (Receive desc head) 0x0060 > 0x02818: RDT (Receive desc tail) 0x0060 > 0x02820: RDTR (Receive delay timer) 0x > > So, somehow we're getting into a state where we can't receive packets, > and we're never getting out of that state. Are you sure that you're able to transmit and you aren't just handing it to the hardware and it never gets out? tcpdump on a remote machine would verify. RDH==RDT should never happen during runtime because the hardware will lock thinking it has an empty ring. what hardware do you have (lspci -vvv) what is the machine? do you have a test that reproduces this? Thanks for the report, get back to us with the follow up data. Jesse PS for very e1000 specific questions like this you're welcome to include [EMAIL PROTECTED] too. - 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
Repost [PATCH 1 of 3] move destructor to struct neigh_parms
Sorry about reposting: the message didnt seem to make it to netdev.
---
Hi!
struct neigh_ops currently has a destructor field, unused by in-kernel
drivers outside the infiniband subtree.
infiniband ipoib in-tree driver currently uses this field, and we've
run into problems: since the destructor is shared between neighbours
that belong to different net devices, there's no way to set/clear it
safely.
It would be good to know what the design was
behind putting the destructor method there in the first place.
The following patch moves this field to neigh_parms where it can
be safely set, together with its twin neigh_setup.
Two additional patches in the patch series
update ipoib to use this new interface.
Please Cc me on replies, I'm not on the list.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which is not, so that multiple drivers can set
it safely.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.15/net/core/neighbour.c
===
--- linux-2.6.15.orig/net/core/neighbour.c 2006-01-12 11:58:15.0
+0200
+++ linux-2.6.15/net/core/neighbour.c 2006-01-12 20:10:00.0 +0200
@@ -586,8 +586,8 @@ void neigh_destroy(struct neighbour *nei
kfree(hh);
}
- if (neigh->ops && neigh->ops->destructor)
- (neigh->ops->destructor)(neigh);
+ if (neigh->parms->neigh_destructor)
+ (neigh->parms->neigh_destructor)(neigh);
skb_queue_purge(&neigh->arp_queue);
Index: linux-2.6.15/include/net/neighbour.h
===
--- linux-2.6.15.orig/include/net/neighbour.h 2006-01-03 05:21:10.0
+0200
+++ linux-2.6.15/include/net/neighbour.h2006-01-12 20:09:27.0
+0200
@@ -68,6 +68,7 @@ struct neigh_parms
struct net_device *dev;
struct neigh_parms *next;
int (*neigh_setup)(struct neighbour *);
+ void(*neigh_destructor)(struct neighbour *);
struct neigh_table *tbl;
void*sysctl_table;
@@ -145,7 +146,6 @@ struct neighbour
struct neigh_ops
{
int family;
- void(*destructor)(struct neighbour *);
void(*solicit)(struct neighbour *, struct sk_buff*);
void(*error_report)(struct neighbour *, struct
sk_buff*);
int (*output)(struct sk_buff*);
--
MST
-
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
Repost [PATCH 2 of 3] ipoib: move destructor to struct neigh_parms
Sorry about reposting: the message didnt seem to make it to netdev.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which is not, so that multiple drivers can set
it safely.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c
===
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12
20:30:52.0 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12
20:31:26.0 +0200
@@ -247,7 +247,6 @@ static void path_free(struct net_device
if (neigh->ah)
ipoib_put_ah(neigh->ah);
*to_ipoib_neigh(neigh->neighbour) = NULL;
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
}
@@ -530,7 +529,6 @@ static void neigh_add_path(struct sk_buf
err:
*to_ipoib_neigh(skb->dst->neighbour) = NULL;
list_del(&neigh->list);
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
++priv->stats.tx_dropped;
@@ -769,21 +767,9 @@ static void ipoib_neigh_destructor(struc
ipoib_put_ah(ah);
}
-static int ipoib_neigh_setup(struct neighbour *neigh)
-{
- /*
-* Is this kosher? I can't find anybody in the kernel that
-* sets neigh->destructor, so we should be able to set it here
-* without trouble.
-*/
- neigh->ops->destructor = ipoib_neigh_destructor;
-
- return 0;
-}
-
static int ipoib_neigh_setup_dev(struct net_device *dev, struct neigh_parms
*parms)
{
- parms->neigh_setup = ipoib_neigh_setup;
+ parms->neigh_destructor = ipoib_neigh_destructor;
return 0;
}
--
MST
-
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 RESEND netdev-2.6 1/8] e1000: Added disable packet split capability
Adds the ability to disability packet split at compile time and use the legacy receive path on PCI express hardware. Made this a CONFIG option and modified the Kconfig, to reflect the new option. Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- arch/arm/configs/ep80219_defconfig |1 + arch/arm/configs/iq31244_defconfig |1 + arch/arm/configs/iq80321_defconfig |1 + arch/arm/configs/iq80331_defconfig |1 + arch/arm/configs/iq80332_defconfig |1 + arch/i386/defconfig|2 ++ arch/ia64/configs/gensparse_defconfig |1 + arch/ia64/configs/tiger_defconfig |1 + arch/ia64/configs/zx1_defconfig|1 + arch/ia64/defconfig|1 + arch/parisc/configs/a500_defconfig |1 + arch/parisc/configs/c3000_defconfig|1 + arch/powerpc/configs/cell_defconfig|1 + arch/powerpc/configs/g5_defconfig |1 + arch/powerpc/configs/iseries_defconfig |1 + arch/powerpc/configs/maple_defconfig |1 + arch/powerpc/configs/ppc64_defconfig |1 + arch/powerpc/configs/pseries_defconfig |1 + arch/ppc/configs/bamboo_defconfig |1 + arch/ppc/configs/katana_defconfig |1 + arch/ppc/configs/mpc834x_sys_defconfig |1 + arch/ppc/configs/power3_defconfig |1 + arch/sparc64/defconfig |1 + arch/x86_64/defconfig |1 + drivers/net/Kconfig|9 + drivers/net/e1000/e1000_main.c |4 ++-- 26 files changed, 36 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/ep80219_defconfig b/arch/arm/configs/ep80219_defconfig --- a/arch/arm/configs/ep80219_defconfig +++ b/arch/arm/configs/ep80219_defconfig @@ -522,6 +522,7 @@ CONFIG_E100=y # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/arm/configs/iq31244_defconfig b/arch/arm/configs/iq31244_defconfig --- a/arch/arm/configs/iq31244_defconfig +++ b/arch/arm/configs/iq31244_defconfig @@ -493,6 +493,7 @@ CONFIG_NETDEVICES=y # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/arm/configs/iq80321_defconfig b/arch/arm/configs/iq80321_defconfig --- a/arch/arm/configs/iq80321_defconfig +++ b/arch/arm/configs/iq80321_defconfig @@ -415,6 +415,7 @@ CONFIG_NETDEVICES=y # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/arm/configs/iq80331_defconfig b/arch/arm/configs/iq80331_defconfig --- a/arch/arm/configs/iq80331_defconfig +++ b/arch/arm/configs/iq80331_defconfig @@ -496,6 +496,7 @@ CONFIG_NETDEVICES=y # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/arm/configs/iq80332_defconfig b/arch/arm/configs/iq80332_defconfig --- a/arch/arm/configs/iq80332_defconfig +++ b/arch/arm/configs/iq80332_defconfig @@ -496,6 +496,7 @@ CONFIG_NETDEVICES=y # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/i386/defconfig b/arch/i386/defconfig --- a/arch/i386/defconfig +++ b/arch/i386/defconfig @@ -644,6 +644,8 @@ CONFIG_8139TOO_PIO=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set +# CONFIG_E1000_NAPI is not set +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/ia64/configs/gensparse_defconfig b/arch/ia64/configs/gensparse_defconfig --- a/arch/ia64/configs/gensparse_defconfig +++ b/arch/ia64/configs/gensparse_defconfig @@ -557,6 +557,7 @@ CONFIG_E100=m # CONFIG_DL2K is not set CONFIG_E1000=y # CONFIG_E1000_NAPI is not set +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/ia64/configs/tiger_defconfig b/arch/ia64/configs/tiger_defconfig --- a/arch/ia64/configs/tiger_defconfig +++ b/arch/ia64/configs/tiger_defconfig @@ -565,6 +565,7 @@ CONFIG_E100=m # CONFIG_DL2K is not set CONFIG_E1000=y # CONFIG_E1000_NAPI is not set +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set diff --git a/arch/ia64/configs/zx1_defconfig
[PATCH RESEND netdev-2.6 3/8] e1000: Added functions to save and restore config
These functions help restore the driver to active configuration when coming out
of resume for power management.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 60 +++-
1 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4437,6 +4437,54 @@ e1000_set_spd_dplx(struct e1000_adapter
}
#ifdef CONFIG_PM
+/* these functions save and restore 16 or 64 dwords (64-256 bytes) of config
+ * space versus the 64 bytes that pci_[save|restore]_state handle
+ */
+#define PCIE_CONFIG_SPACE_LEN 256
+#define PCI_CONFIG_SPACE_LEN 64
+static int
+e1000_pci_save_state(struct e1000_adapter *adapter)
+{
+ struct pci_dev *dev = adapter->pdev;
+ int size;
+ int i;
+ if (adapter->hw.mac_type >= e1000_82571)
+ size = PCIE_CONFIG_SPACE_LEN;
+ else
+ size = PCI_CONFIG_SPACE_LEN;
+
+ WARN_ON(adapter->config_space != NULL);
+
+ adapter->config_space = kmalloc(size, GFP_KERNEL);
+ if (!adapter->config_space) {
+ DPRINTK(PROBE, ERR, "unable to allocate %d bytes\n", size);
+ return -ENOMEM;
+ }
+ for (i = 0; i < (size / 4); i++)
+ pci_read_config_dword(dev, i * 4, &adapter->config_space[i]);
+ return 0;
+}
+
+static void
+e1000_pci_restore_state(struct e1000_adapter *adapter)
+{
+ struct pci_dev *dev = adapter->pdev;
+ int size;
+ int i;
+ if (adapter->config_space == NULL)
+ return;
+ if (adapter->hw.mac_type >= e1000_82571)
+ size = PCIE_CONFIG_SPACE_LEN;
+ else
+ size = PCI_CONFIG_SPACE_LEN;
+ for (i = 0; i < (size / 4); i++)
+ pci_write_config_dword(dev, i * 4, adapter->config_space[i]);
+ kfree(adapter->config_space);
+ adapter->config_space = NULL;
+ return;
+}
+#endif /* CONFIG_PM */
+
static int
e1000_suspend(struct pci_dev *pdev, pm_message_t state)
{
@@ -4451,6 +4499,14 @@ e1000_suspend(struct pci_dev *pdev, pm_m
if(netif_running(netdev))
e1000_down(adapter);
+#ifdef CONFIG_PM
+ /* implement our own version of pci_save_state(pdev) because pci
+* express adapters have larger 256 byte config spaces */
+ retval = e1000_pci_save_state(adapter);
+ if (retval)
+ return retval;
+#endif
+
status = E1000_READ_REG(&adapter->hw, STATUS);
if(status & E1000_STATUS_LU)
wufc &= ~E1000_WUFC_LNKC;
@@ -4507,8 +4563,6 @@ e1000_suspend(struct pci_dev *pdev, pm_m
DPRINTK(PROBE, ERR, "Error enabling D3 cold wake\n");
}
- pci_save_state(pdev);
-
if(adapter->hw.mac_type >= e1000_82540 &&
adapter->hw.media_type == e1000_media_type_copper) {
manc = E1000_READ_REG(&adapter->hw, MANC);
@@ -4537,6 +4591,7 @@ e1000_suspend(struct pci_dev *pdev, pm_m
return 0;
}
+#ifdef CONFIG_PM
static int
e1000_resume(struct pci_dev *pdev)
{
@@ -4548,6 +4603,7 @@ e1000_resume(struct pci_dev *pdev)
retval = pci_set_power_state(pdev, PCI_D0);
if (retval)
DPRINTK(PROBE, ERR, "Error in setting power state\n");
+ e1000_pci_restore_state(adapter);
ret_val = pci_enable_device(pdev);
pci_set_master(pdev);
-
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 RESEND netdev-2.6 4/8] e1000: Added functions declarations
Added e1000_mc_addr_list_update Added e1000_read_reg_io Added e1000_enable_pciex_master These are not static functions, that is why we have them declared in the header. Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_hw.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h --- a/drivers/net/e1000/e1000_hw.h +++ b/drivers/net/e1000/e1000_hw.h @@ -377,6 +377,7 @@ int32_t e1000_swfw_sync_acquire(struct e void e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask); /* Filters (multicast, vlan, receive) */ +void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t * mc_addr_list, uint32_t mc_addr_count, uint32_t pad, uint32_t rar_used_count); uint32_t e1000_hash_mc_addr(struct e1000_hw *hw, uint8_t * mc_addr); void e1000_mta_set(struct e1000_hw *hw, uint32_t hash_value); void e1000_rar_set(struct e1000_hw *hw, uint8_t * mc_addr, uint32_t rar_index); @@ -401,7 +402,9 @@ void e1000_read_pci_cfg(struct e1000_hw void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value); /* Port I/O is only supported on 82544 and newer */ uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port); +uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset); void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value); +void e1000_enable_pciex_master(struct e1000_hw *hw); int32_t e1000_disable_pciex_master(struct e1000_hw *hw); int32_t e1000_get_software_semaphore(struct e1000_hw *hw); void e1000_release_software_semaphore(struct e1000_hw *hw); - 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 RESEND netdev-2.6 7/8] e1000: fix receive breakage
in attempting to not send the "prefetch" patch, we broke the receive code,
this patch fixes that issue.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -88,8 +88,6 @@
* sessions are active and log a message
* 6.2.2 7/21/05
* o used fixed size descriptors for all MTU sizes, reduces memory load
- * 6.2.1 7/21/05
- * o Performance tweaks, including copybreak and prefetch
* 6.1.2 4/13/05
* o Fixed ethtool diagnostics
* o Enabled flow control to take default eeprom settings
@@ -3615,8 +3613,8 @@ e1000_clean_rx_irq(struct e1000_adapter
{
struct net_device *netdev = adapter->netdev;
struct pci_dev *pdev = adapter->pdev;
- struct e1000_rx_desc *rx_desc;
- struct e1000_buffer *buffer_info;
+ struct e1000_rx_desc *rx_desc, *next_rxd;
+ struct e1000_buffer *buffer_info, *next_buffer;
unsigned long flags;
uint32_t length;
uint8_t last_byte;
@@ -3629,7 +3627,7 @@ e1000_clean_rx_irq(struct e1000_adapter
buffer_info = &rx_ring->buffer_info[i];
while (rx_desc->status & E1000_RXD_STAT_DD) {
- struct sk_buff *skb;
+ struct sk_buff *skb, *next_skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if (*work_done >= work_to_do)
@@ -3638,6 +3636,13 @@ e1000_clean_rx_irq(struct e1000_adapter
#endif
status = rx_desc->status;
skb = buffer_info->skb;
+ buffer_info->skb = NULL;
+
+ if (++i == rx_ring->count) i = 0;
+ next_rxd = E1000_RX_DESC(*rx_ring, i);
+ next_buffer = &rx_ring->buffer_info[i];
+ next_skb = next_buffer->skb;
+
cleaned = TRUE;
cleaned_count++;
pci_unmap_single(pdev,
@@ -3769,6 +3774,8 @@ next_desc:
cleaned_count = 0;
}
+ rx_desc = next_rxd;
+ buffer_info = next_buffer;
}
rx_ring->next_to_clean = i;
@@ -3794,13 +3801,13 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
struct e1000_rx_ring *rx_ring)
#endif
{
- union e1000_rx_desc_packet_split *rx_desc;
+ union e1000_rx_desc_packet_split *rx_desc, *next_rxd;
struct net_device *netdev = adapter->netdev;
struct pci_dev *pdev = adapter->pdev;
- struct e1000_buffer *buffer_info;
+ struct e1000_buffer *buffer_info, *next_buffer;
struct e1000_ps_page *ps_page;
struct e1000_ps_page_dma *ps_page_dma;
- struct sk_buff *skb;
+ struct sk_buff *skb, *next_skb;
unsigned int i, j;
uint32_t length, staterr;
int cleaned_count = 0;
@@ -3809,9 +3816,9 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
i = rx_ring->next_to_clean;
rx_desc = E1000_RX_DESC_PS(*rx_ring, i);
staterr = le32_to_cpu(rx_desc->wb.middle.status_error);
+ buffer_info = &rx_ring->buffer_info[i];
while (staterr & E1000_RXD_STAT_DD) {
- buffer_info = &rx_ring->buffer_info[i];
ps_page = &rx_ring->ps_page[i];
ps_page_dma = &rx_ring->ps_page_dma[i];
#ifdef CONFIG_E1000_NAPI
@@ -3819,14 +3826,19 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
break;
(*work_done)++;
#endif
+ skb = buffer_info->skb;
+
+ if (++i == rx_ring->count) i = 0;
+ next_rxd = E1000_RX_DESC_PS(*rx_ring, i);
+ next_buffer = &rx_ring->buffer_info[i];
+ next_skb = next_buffer->skb;
+
cleaned = TRUE;
cleaned_count++;
pci_unmap_single(pdev, buffer_info->dma,
buffer_info->length,
PCI_DMA_FROMDEVICE);
- skb = buffer_info->skb;
-
if (unlikely(!(staterr & E1000_RXD_STAT_EOP))) {
E1000_DBG("%s: Packet Split buffers didn't pick up"
" the full packet\n", netdev->name);
@@ -3908,6 +3920,9 @@ next_desc:
cleaned_count = 0;
}
+ rx_desc = next_rxd;
+ buffer_info = next_buffer;
+
staterr = le32_to_cpu(rx_desc->wb.middle.status_error);
}
rx_ring->next_to_clean = i;
-
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 netdev-2.6 0/8] e1000: remaining patches and fixes
Made the suggested changes to the disable packet split patch. These were diff'd with Garzik's latest netdev-2.6 head. !! Please use this patch set instead of the previous 0-6 set NOTE: because these changes are just regenerating the first 6 and then the 7th and 8th fixes the compile warning and the lack of data traffic, we need these to be applied all or nothing. For those who are interested, the reason the driver didn't work is because we had attempted to not submit the "prefetch" patch due to it generating thrash, and in the process broke the driver without that patch. patch 7 fixes that issue without including prefetch. The following series implements... 1. Added disable packet split capability (as a CONFIG option) 2. Added RX buffer enhancements 3. Added functions to save and restore config 4. Added functions declaration 5. Fix whitespace 6. Added driver comments 7. fix the receive path 8. fix the compile warning thank you for your patience while we "git" our act together. Jesse -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND netdev-2.6 6/8] e1000: Added driver comments
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_main.c | 72 +--- 1 files changed, 67 insertions(+), 5 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -29,11 +29,73 @@ #include "e1000.h" /* Change Log - * 6.0.58 4/20/05 - * o Accepted ethtool cleanup patch from Stephen Hemminger - * 6.0.44+ 2/15/05 - * o applied Anton's patch to resolve tx hang in hardware - * o Applied Andrew Mortons patch - e1000 stops working after resume + * 6.3.9 12/16/2005 + * o incorporate fix for recycled skbs from IBM LTC + * 6.3.7 11/18/2005 + * o Honor eeprom setting for enabling/disabling Wake On Lan + * 6.3.5 11/17/2005 + * o Fix memory leak in rx ring handling for PCI Express adapters + * 6.3.4 11/8/05 + * o Patch from Jesper Juhl to remove redundant NULL checks for kfree + * 6.3.2 9/20/05 + * o Render logic that sets/resets DRV_LOAD as inline functions to + * avoid code replication. If f/w is AMT then set DRV_LOAD only when + * network interface is open. + * o Handle DRV_LOAD set/reset in cases where AMT uses VLANs. + * o Adjust PBA partioning for Jumbo frames using MTU size and not + * rx_buffer_len + * 6.3.1 9/19/05 + * o Use adapter->tx_timeout_factor in Tx Hung Detect logic + (e1000_clean_tx_irq) + * o Support for 8086:10B5 device (Quad Port) + * 6.2.14 9/15/05 + * o In AMT enabled configurations, set/reset DRV_LOAD bit on interface + * open/close + * 6.2.13 9/14/05 + * o Invoke e1000_check_mng_mode only for 8257x controllers since it + * accesses the FWSM that is not supported in other controllers + * 6.2.12 9/9/05 + * o Add support for device id E1000_DEV_ID_82546GB_QUAD_COPPER + * o set RCTL:SECRC only for controllers newer than 82543. + * o When the n/w interface comes down reset DRV_LOAD bit to notify f/w. + * This code was moved from e1000_remove to e1000_close + * 6.2.10 9/6/05 + * o Fix error in updating RDT in el1000_alloc_rx_buffers[_ps] -- one off. + * o Enable fc by default on 82573 controllers (do not read eeprom) + * o Fix rx_errors statistic not to include missed_packet_count + * o Fix rx_dropped statistic not to include missed_packet_count + (Padraig Brady) + * 6.2.98/30/05 + * o Remove call to update statistics from the controller ib e1000_get_stats + * 6.2.88/30/05 + * o Improved algorithm for rx buffer allocation/rdt update + * o Flow control watermarks relative to rx PBA size + * o Simplified 'Tx Hung' detect logic + * 6.2.7 8/17/05 + * o Report rx buffer allocation failures and tx timeout counts in stats + * 6.2.6 8/16/05 + * o Implement workaround for controller erratum -- linear non-tso packet + * following a TSO gets written back prematurely + * 6.2.5 8/15/05 + * o Set netdev->tx_queue_len based on link speed/duplex settings. + * o Fix net_stats.rx_fifo_errors <[EMAIL PROTECTED]> + * o Do not power off PHY if SoL/IDER session is active + * 6.2.4 8/10/05 + * o Fix loopback test setup/cleanup for 82571/3 controllers + * o Fix parsing of outgoing packets (e1000_transfer_dhcp_info) to treat + * all packets as raw + * o Prevent operations that will cause the PHY to be reset if SoL/IDER + * sessions are active and log a message + * 6.2.2 7/21/05 + * o used fixed size descriptors for all MTU sizes, reduces memory load + * 6.2.1 7/21/05 + * o Performance tweaks, including copybreak and prefetch + * 6.1.2 4/13/05 + * o Fixed ethtool diagnostics + * o Enabled flow control to take default eeprom settings + * o Added stats_lock around e1000_read_phy_reg commands to avoid concurrent + * calls, one from mii_ioctl and other from within update_stats while + * processing MIIREG ioctl. */ char e1000_driver_name[] = "e1000"; - 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: State of the Union: Wireless / 802.11 master device
On Wed, Jan 18, 2006 at 09:18:26AM +0100, Feyd wrote: > With fullmac devices the master interface makes no sense, it cannot be > used for neither the sniffing or QoS. The design where the master device > is something else than net_device is cleaner, it treats both soft/fullmac > devices equaly, without need to special-case one of them. This may be the case with designs that do not provide anything else than a simple interface for delivering and receiving frames. However, the benefits--and I would be prepared to say even requirements--of having a master device are extensive enough to use it with many wlan designs. If a generic design is desired for both types, even fullmac devices would need to keep the master netdev even if it is not really needed. Other option would be to make it optional to add the master netdev and have something else presenting the wlan device. In addition, even fullmac devices may have uses for master netdev. For example, in AP mode with dynamic VLAN configuration (RADIUS authentication server selecting which VLAN to use), there may be benefits of being able to use multiple virtual interfaces (netdevs) that would logically be collected into master netdev for scheduling and transmission. -- 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: wireless: the contenders
On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote: > On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote: > > John W. Linville wrote: > > > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus > > >changes I recently sent to Jeff. Those changes are also available on > > >the "upstream-jgarzik" branch, but it is frozen to when I requested > > >Jeff's pull. > > > Typically I do not update 'master' unless I am also updating 'upstream' > > with vanilla Linus changes, in order to avoid screwing up the tree heads > > and the diff. When I do update 'master' from 'upstream', it is a > > trivial matter to then pull those changes into 'upstream': > > Good info...thanks! > > FWIW, I have an "origin" branch that corresponds to Linus' tree. > I think that probably enables the same kind of usage as you noted...? Yep, it doesn't matter what you call it. I avoid 'origin' since a 'git pull' without arguments will automatically update that (and possibly master too). But it's just a name. Any branch with vanilla Linus tree in it will achieve the behavior I described. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND netdev-2.6 2/8] e1000: Added RX buffer enhancements
Align the prefetches to a dword to help speed them up.
Recycle skb's and early replenish.
Force memory writes to complete before fetching more descriptors.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 137 +++-
1 files changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1653,23 +1653,8 @@ e1000_setup_rctl(struct e1000_adapter *a
rctl |= adapter->rx_buffer_len << 0x11;
} else {
rctl &= ~E1000_RCTL_SZ_4096;
- rctl |= E1000_RCTL_BSEX;
- switch (adapter->rx_buffer_len) {
- case E1000_RXBUFFER_2048:
- default:
- rctl |= E1000_RCTL_SZ_2048;
- rctl &= ~E1000_RCTL_BSEX;
- break;
- case E1000_RXBUFFER_4096:
- rctl |= E1000_RCTL_SZ_4096;
- break;
- case E1000_RXBUFFER_8192:
- rctl |= E1000_RCTL_SZ_8192;
- break;
- case E1000_RXBUFFER_16384:
- rctl |= E1000_RCTL_SZ_16384;
- break;
- }
+ rctl &= ~E1000_RCTL_BSEX;
+ rctl |= E1000_RCTL_SZ_2048;
}
#ifndef CONFIG_E1000_DISABLE_PACKET_SPLIT
@@ -3571,7 +3556,6 @@ e1000_clean_rx_irq(struct e1000_adapter
struct pci_dev *pdev = adapter->pdev;
struct e1000_rx_desc *rx_desc;
struct e1000_buffer *buffer_info;
- struct sk_buff *skb;
unsigned long flags;
uint32_t length;
uint8_t last_byte;
@@ -3581,9 +3565,10 @@ e1000_clean_rx_irq(struct e1000_adapter
i = rx_ring->next_to_clean;
rx_desc = E1000_RX_DESC(*rx_ring, i);
+ buffer_info = &rx_ring->buffer_info[i];
- while(rx_desc->status & E1000_RXD_STAT_DD) {
- buffer_info = &rx_ring->buffer_info[i];
+ while (rx_desc->status & E1000_RXD_STAT_DD) {
+ struct sk_buff *skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if(*work_done >= work_to_do)
@@ -3591,6 +3576,7 @@ e1000_clean_rx_irq(struct e1000_adapter
(*work_done)++;
#endif
status = rx_desc->status;
+ skb = buffer_info->skb;
cleaned = TRUE;
cleaned_count++;
pci_unmap_single(pdev,
@@ -3598,20 +3584,50 @@ e1000_clean_rx_irq(struct e1000_adapter
buffer_info->length,
PCI_DMA_FROMDEVICE);
- skb = buffer_info->skb;
length = le16_to_cpu(rx_desc->length);
- if(unlikely(!(rx_desc->status & E1000_RXD_STAT_EOP))) {
- /* All receives must fit into a single buffer */
- E1000_DBG("%s: Receive packet consumed multiple"
- " buffers\n", netdev->name);
- dev_kfree_skb_irq(skb);
+ skb_put(skb, length);
+
+ if (!(status & E1000_RXD_STAT_EOP)) {
+ if (!rx_ring->rx_skb_top) {
+ rx_ring->rx_skb_top = skb;
+ rx_ring->rx_skb_top->len = length;
+ rx_ring->rx_skb_prev = skb;
+ } else {
+ if (skb_shinfo(rx_ring->rx_skb_top)->frag_list)
{
+ rx_ring->rx_skb_prev->next = skb;
+ skb->prev = rx_ring->rx_skb_prev;
+ } else {
+
skb_shinfo(rx_ring->rx_skb_top)->frag_list = skb;
+ }
+ rx_ring->rx_skb_prev = skb;
+ rx_ring->rx_skb_top->data_len += length;
+ }
goto next_desc;
+ } else {
+ if (rx_ring->rx_skb_top) {
+ if (skb_shinfo(rx_ring->rx_skb_top)
+ ->frag_list) {
+ rx_ring->rx_skb_prev->next = skb;
+ skb->prev = rx_ring->rx_skb_prev;
+ } else
+ skb_shinfo(rx_ring->rx_skb_top)
+ ->frag_list = skb;
+
+ rx_ring->rx_skb_top->data_len += length;
+ rx_ring->rx_skb_top->len +=
+ rx_ring->rx_skb_top->data_l
[PATCH RESEND netdev-2.6 8/8] e1000: fix compile warning
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2186,9 +2186,9 @@ e1000_leave_82542_rst(struct e1000_adapt
e1000_pci_set_mwi(&adapter->hw);
if (netif_running(netdev)) {
- e1000_configure_rx(adapter);
/* No need to loop, because 82542 supports only 1 queue */
struct e1000_rx_ring *ring = &adapter->rx_ring[0];
+ e1000_configure_rx(adapter);
adapter->alloc_rx_buf(adapter, ring, E1000_DESC_UNUSED(ring));
}
}
-
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
help with e1000 issue?
We're seeing an issue with an e1000 device. After some time (4-8 hrs typically) it jams itself up and refuses to receive any more packets. We're running 2.6.10, but with the e1000 driver from 2.6.14. Outgoing packets seem to be fine, incoming packets just increment the error count. ethtool device specific stats show the following counters rx_fifo_errors: 1714150 rx_no_buffer_count: 299 rx_missed_errors: 1714150 The fifo and missed errors seem to actually be counting the same thing, the "Missed Packets Count" error register. From the chip docs: "Counts the number of missed packets. Packets are missed when the receive FIFO has insufficient space to store the incoming packet. This can be caused because of too few buffers allocated, or because there is insufficient bandwidth on the PCI bus. Events setting this counter cause RXO, the Receiver Overrun Interrupt, to be set. This register does not increment if receives are not enabled." The no buffer count is similar, based on the "Receive No Buffers Count" register. From the docs: "This register counts the number of times that frames were received when there were no available buffers in host memory to store those frames (receive descriptor head and tail pointers were equal). The packet is still received if there is space in the FIFO. This register only increments if receives are enabled." On the jammed device, dumping the registers gives the following, indicating that the head and tail pointers are equal: Receive buffer size: 2048 0x02808: RDLEN (Receive desc length) 0x1000 0x02810: RDH (Receive desc head) 0x0060 0x02818: RDT (Receive desc tail) 0x0060 0x02820: RDTR (Receive delay timer) 0x So, somehow we're getting into a state where we can't receive packets, and we're never getting out of that state. Anyone have any ideas? Chris - 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: wireless: the contenders
On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote: > John W. Linville wrote: > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus > >changes I recently sent to Jeff. Those changes are also available on > >the "upstream-jgarzik" branch, but it is frozen to when I requested > >Jeff's pull. > Typically I do not update 'master' unless I am also updating 'upstream' > with vanilla Linus changes, in order to avoid screwing up the tree heads > and the diff. When I do update 'master' from 'upstream', it is a > trivial matter to then pull those changes into 'upstream': Good info...thanks! FWIW, I have an "origin" branch that corresponds to Linus' tree. I think that probably enables the same kind of usage as you noted...? Thanks, 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: wireless: the contenders
John W. Linville wrote: First, the news everyone will like. Thanks to the kernel.org team I now have a place to publish a wireless tree: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git The tree there has a number of branches, so many that you need a scorecard... Branches The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus changes I recently sent to Jeff. Those changes are also available on the "upstream-jgarzik" branch, but it is frozen to when I requested Jeff's pull. Minor git administrative note... In my trees, the 'master' branch is always vanilla Linus, and I never ever apply my own changes to it. This enables commands such as git diff master..upstream > patch git log master..upstream > log.txt git log master..upstream | git shortlog > shortlog.txt to work as expected. Typically I do not update 'master' unless I am also updating 'upstream' with vanilla Linus changes, in order to avoid screwing up the tree heads and the diff. When I do update 'master' from 'upstream', it is a trivial matter to then pull those changes into 'upstream': git checkout -f upstream git pull . master Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] [RFC] Infiniband: connection abstraction
On Wed, 2006-01-18 at 08:08 +0100, Arjan van de Ven wrote: > the dual license text needs a bit of clarification I suspect to make > explicit that the "or BSD" part only applies when used entirely outside > the linux kernel. (that already is the case, just it's not explicit. > Making that explicit would be good). One appropriate way to do that would be to mark all IB-related exported symbols as EXPORT_SYMBOL_GPL. http://vger.kernel.org/majordomo-info.html
Re: [Bcm43xx-dev] wireless: the contenders
On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote: > On Wednesday 18 January 2006 21:06, John W. Linville wrote: > > The tree also has "softmac" and "dscape" branches. The "softmac" > > branch includes the Johannes Berg softmac code as well as the the > > BCM43xx driver based upon that code. The "dscape" branch includes > > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver > > ported to the DeviceScape stack. > > Are you going to keep it synced with our repository? > I think it should be possible to automatically send patches for > every change in our tree to you. I am not 100% sure (but 99%). > I will look at it tomorrow. If you'll send me patches, I'll apply them... John P.S. Please do what you can to make them comply w/ kernel patch posting conventions: http://linux.yyz.us/patch-format.html -- 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] Remove MANY unneeded header files in net/core/filter.c
On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote:
>
> Since it can't be a module and is always built in, we can just remove the
> EXPORT_SYMBOL()s, right?
No, these are there so that other modules can use these symboles.
--
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: [Bcm43xx-dev] wireless: the contenders
On Wednesday 18 January 2006 21:06, John W. Linville wrote: > The tree also has "softmac" and "dscape" branches. The "softmac" > branch includes the Johannes Berg softmac code as well as the the > BCM43xx driver based upon that code. The "dscape" branch includes > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver > ported to the DeviceScape stack. Are you going to keep it synced with our repository? I think it should be possible to automatically send patches for every change in our tree to you. I am not 100% sure (but 99%). I will look at it tomorrow. -- Greetings Michael. pgpnXJIwxkVyc.pgp Description: PGP signature
wireless: the contenders
First, the news everyone will like. Thanks to the kernel.org team I now have a place to publish a wireless tree: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git The tree there has a number of branches, so many that you need a scorecard... Branches The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus changes I recently sent to Jeff. Those changes are also available on the "upstream-jgarzik" branch, but it is frozen to when I requested Jeff's pull. The tree also has "softmac" and "dscape" branches. The "softmac" branch includes the Johannes Berg softmac code as well as the the BCM43xx driver based upon that code. The "dscape" branch includes the DeviceScape patches from Jiri Benc as well as the BCM43xx driver ported to the DeviceScape stack. The fact that the BCM43xx team has ported their driver to both stacks provides us an excellent opportunity for some objective, "apples to apples" comparisons between the major stacks. I would like to take this opportunity to thank them for taking the trouble to do that work and to make both versions available for comparison. BTW, those trying to actually use the dscape code will want to poke around Jiri's kernel.org directories: http://www.kernel.org/pub/linux/kernel/people/jbenc/ Jiri has some information there that will likely be useful to you. The other branches are for administrative purposes, and can mostly be ignored. Patches --- Along with bugfixes and enhancements to the current code (which will be targeting the "master" branch), I would like to see driver and stack patches for both the "softmac" and "dscape" branches. I would like to see what is really out there before making a final call on which stack to adopt permanently. If you have an out-of-tree driver which targets either (or both) stacks, please send patches. If you are working on porting an in-kernel driver to one of these stacks (either from the other stack or from its private stack), please send patches. If you have fixes or enhancements pending for either of these stacks, then please send patches. Don't waste any time with your patches. There is good reason to make a decision quickly, and plenty of pressure to do so. Your code could be a significant factor in making that decision. I know that many of you believe that this approach is a bad idea, for a variety of reasons. I find those arguments valid, and even persuasive. The point of this exercise is NOT to push two stacks forward into Linus' kernel. The point is to catalog the true state of affairs and to collect as large a wireless driver codebase as possible. You might think of this as a Domesday Book (http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless. Summary --- Hopefully the act of collecting these patches will also allow the less motivated among us to have a chance to evaluate the stacks involved. There are bound to be some wise and skilled kernel hackers out there that are just a little too busy to track-down all these patches themselves... :-) I appreciate all the commentary and ideas expressed over the past couple of weeks. I also think the driver writers are doing a good job with what they've been given so far. I hope this helps to bring the driver guys in out of the cold, and to put some weight behind the discussions of where we need to go. Thanks, 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] trivial untested cleanup for skge.
I roll it into the next set of skge maintenance patches. - 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] sk98lin: module table alias
On Wed, 18 Jan 2006 11:29:09 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Wed, 18 Jan 2006 19:07:42 + > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote: > > > The following removes the pci device module alias if both skge and sk98lin > > > are compiled as modules. This means the clueless user who builds both > > > modules > > > will get the skge driver loaded. If they really want to run sk98lin, they > > > can always modprobe it explicitly. > > > > Nack. changing module tables in one driver depending on another driver > > is always bogus. Better send a patch to udev/modutils/whatever maintainers > > to prefer one over the others. > > Is there really any such stuff in there? Talking to myself again... Newest version of module-init-tools has a nice blacklist feature. The bigger problem is that module config file seems to be a per-distro thing. So Jeff, go ahead and skip this patch. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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: how to obtain detailed e1000 stats?
It looks like the e1000 driver gathers all kinds of stats. How do I access these from userspace? /proc/net/dev will have many of the common ones, and ethtool should get the rest. If you want a hack, I have a patch against the ethtool logic that allows user-space to grab the netdev->stats struct and copy it directly to user-space. This is easier and most likely more efficient than parsing the /proc/net/dev file. Yes, please ;). I'd be interested in this patch as well. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - 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] sk98lin: module table alias
On Wed, 18 Jan 2006 19:07:42 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote: > > The following removes the pci device module alias if both skge and sk98lin > > are compiled as modules. This means the clueless user who builds both > > modules > > will get the skge driver loaded. If they really want to run sk98lin, they > > can always modprobe it explicitly. > > Nack. changing module tables in one driver depending on another driver > is always bogus. Better send a patch to udev/modutils/whatever maintainers > to prefer one over the others. Is there really any such stuff in there? -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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: IRDA maintainer status
On Wed, Jan 18, 2006 at 10:52:26AM -0800, Stephen Hemminger wrote: > Dave, Jean says he really doesn't have time to much IRDA any more. > The following would help motivate someone who has more time. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Thanks ;-) (Unfortunately, from the traffic on the irda mailing list, it won't make much difference). 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: Questions on Chelsio NICs
Ben Greear wrote: Hello! I got my chelsio NICs in a machine running 2.6.15 + my hacks today and started playing with it... I noticed one immediate problem with pktgen, and fixed my pktgen to respect the hard-header-len that the chelsio driver reports. My pktgen doesn't track mainline very well, but the change is to do something like this in the fill_packet method: int rsrv = (odev->hard_header_len + 16) & ~0xF; skb = alloc_skb(info->cur_pkt_size + 64 + rsrv, GFP_ATOMIC); /* Make some extra space, align on 16-byte boundary * (helps Chelsio) Used to be just a default 16 for * everyone... */ skb_reserve(skb, rsrv); I do notice something strange though: If I use the pktgens multi-pkt feature, the duplicate packets are never actually sent!!! Well, to answer myself: I found the problem. Pktgen's multi-skb trick only works if the device makes no change to the skb. But, the cxgb driver pushes a header on the front of the skb... So, you just can't use the multi-skb pktgen option with this driver... 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: [PATCH 2/2] sk98lin: module table alias
On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote: > The following removes the pci device module alias if both skge and sk98lin > are compiled as modules. This means the clueless user who builds both modules > will get the skge driver loaded. If they really want to run sk98lin, they > can always modprobe it explicitly. Nack. changing module tables in one driver depending on another driver is always bogus. Better send a patch to udev/modutils/whatever maintainers to prefer one over the others. - 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] sk98lin: module table alias
The following removes the pci device module alias if both skge and sk98lin
are compiled as modules. This means the clueless user who builds both modules
will get the skge driver loaded. If they really want to run sk98lin, they
can always modprobe it explicitly.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- git-2.6.orig/drivers/net/sk98lin/skge.c
+++ git-2.6/drivers/net/sk98lin/skge.c
@@ -5120,7 +5120,10 @@ static struct pci_device_id skge_pci_tbl
{ 0 }
};
+/* If new skge driver is available, then prefer that one. */
+#ifndef CONFIG_SKGE_MODULE
MODULE_DEVICE_TABLE(pci, skge_pci_tbl);
+#endif
static struct pci_driver skge_driver = {
.name = "sk98lin",
-
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/2] sk98lin obsolence
Take experimental tag of skge and sky2. Mark sk98lin driver for future removal. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- git-2.6.orig/Documentation/feature-removal-schedule.txt +++ git-2.6/Documentation/feature-removal-schedule.txt @@ -6,6 +6,14 @@ be removed from this file. --- +What: sk98lin +When December 2006 +Files: drivers/net/sk98lin/* +Why: Superseded by the more supportable skge and sky2 drivers. +Who: Stephen Hemminger <[EMAIL PROTECTED]> + +--- + What: devfs When: July 2005 Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs --- git-2.6.orig/MAINTAINERS +++ git-2.6/MAINTAINERS @@ -2448,6 +2448,10 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +SK98LIN DRIVER +L: netdev@vger.kernel.org +S: Obsolete + SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS P: Stephen Hemminger M: [EMAIL PROTECTED] --- git-2.6.orig/drivers/net/Kconfig +++ git-2.6/drivers/net/Kconfig @@ -2013,8 +2013,8 @@ config SIS190 will be called sis190. This is recommended. config SKGE - tristate "New SysKonnect GigaEthernet support (EXPERIMENTAL)" - depends on PCI && EXPERIMENTAL + tristate "SysKonnect GigaEthernet support" + depends on PCI select CRC32 ---help--- This driver support the Marvell Yukon or SysKonnect SK-98xx/SK-95xx @@ -2024,22 +2024,23 @@ config SKGE It does not support the link failover and network management features that "portable" vendor supplied sk98lin driver does. - config SKY2 - tristate "SysKonnect Yukon2 support (EXPERIMENTAL)" - depends on PCI && EXPERIMENTAL + tristate "SysKonnect Yukon2 support" + depends on PCI select CRC32 ---help--- - This driver support the Marvell Yukon 2 Gigabit Ethernet adapter. + This driver supports gigabit adapters based on the Marvell Yukon 2 + chipset (88E8053). To compile this driver as a module, choose M here: the module will be called sky2. This is recommended. config SK98LIN - tristate "Marvell Yukon Chipset / SysKonnect SK-98xx Support" + tristate "Marvell Yukon Chipset / SysKonnect SK-98xx Support (obsolete vendor driver)" depends on PCI + default N ---help--- - Say Y here if you have a Marvell Yukon or SysKonnect SK-98xx/SK-95xx + Original vendor driver for Marvell Yukon or SysKonnect SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter. The following adapters are supported by this driver: - 3Com 3C940 Gigabit LOM Ethernet Adapter @@ -2109,10 +2110,9 @@ config SK98LIN Questions concerning this driver may be addressed to: <[EMAIL PROTECTED]> - If you want to compile this driver as a module ( = code which can be - inserted in and removed from the running kernel whenever you want), - say M here and read . The module will - be called sk98lin. This is recommended. + This driver is being phased out and use of skge instead is + recommended. + config VIA_VELOCITY tristate "VIA Velocity support" - 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
IRDA maintainer status
Dave, Jean says he really doesn't have time to much IRDA any more. The following would help motivate someone who has more time. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- git-2.6.orig/MAINTAINERS +++ git-2.6/MAINTAINERS @@ -1398,7 +1398,7 @@ IRDA SUBSYSTEM P: Jean Tourrilhes L: [EMAIL PROTECTED] (subscribers-only) W: http://irda.sourceforge.net/ -S: Maintained +S: Odd Fixes ISAPNP P: Jaroslav Kysela - 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: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction
On Wed, Jan 18, 2006 at 10:19:01AM -0800, Sean Hefty wrote: > Roland Dreier wrote: > > > + UCMA_MAX_BACKLOG= 128 > > > >Is there any reason that we might want to make this a tunable? Maybe > >as a module parameter that's writable in sysfs... > > There's no reason not to make this tunable. Yes, there are reasons to NOT make something a tunable: o increases system complexity (admin) o increases the amount of documentation (learning curve) o increases test matrix/cost (devel/support cost) o generally hurts performance (var vs a constant of the same value) Any reason to make something a tunable has to compensate for the above drawbacks. An answer to Roland's question is a reasonable prerequisite if someone wants add a tunable. IB doesn't have the much in /sys/class/infiniband* or module parameters and I think that's a Good Thing. grant - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 09/13] mv643xx_eth: Hold spinlocks only where needed
On Wed, Jan 18, 2006 at 04:26:00PM +0100, Olaf Hering wrote:
> I havent checked if this patch is the culprit, but 2.6.16-rc1-git1 does
> lockup after modprobe -v mv643xx_eth , dhcpcd eth2.
> Have to find a serial console for the pegasos, all I get on console is
>
> BUG: spinlock recursion on CPU#0, dhcpcd/2844
> lock: dd96f148, .magic: dead4ead, .owner: dhcpcd/2844, .owner_cpu:0
> BUG: spinlock lockup on CPU#0, dhcpdcd/2844, dd96f148
Olaf, would you please try the patch below. It works for me.
Thanks,
-Dale
From: Dale Farnsworth <[EMAIL PROTECTED]>
This patch eliminates a spinlock recursion bug I introduced recently.
Since eth_port_send() is always called with the lock held, we simply
remove the locking inside the function itself.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
mv643xx_eth.c | 13 -
1 file changed, 13 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-18
11:12:07.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-18
11:13:44.0 -0700
@@ -2617,7 +2617,6 @@
struct eth_tx_desc *current_descriptor;
struct eth_tx_desc *first_descriptor;
u32 command;
- unsigned long flags;
/* Do not process Tx ring in case of Tx ring resource error */
if (mp->tx_resource_err)
@@ -2634,8 +2633,6 @@
return ETH_ERROR;
}
- spin_lock_irqsave(&mp->lock, flags);
-
mp->tx_ring_skbs++;
BUG_ON(mp->tx_ring_skbs > mp->tx_ring_size);
@@ -2685,15 +2682,11 @@
mp->tx_resource_err = 1;
mp->tx_curr_desc_q = tx_first_desc;
- spin_unlock_irqrestore(&mp->lock, flags);
-
return ETH_QUEUE_LAST_RESOURCE;
}
mp->tx_curr_desc_q = tx_next_desc;
- spin_unlock_irqrestore(&mp->lock, flags);
-
return ETH_OK;
}
#else
@@ -2704,14 +2697,11 @@
int tx_desc_used;
struct eth_tx_desc *current_descriptor;
unsigned int command_status;
- unsigned long flags;
/* Do not process Tx ring in case of Tx ring resource error */
if (mp->tx_resource_err)
return ETH_QUEUE_FULL;
- spin_lock_irqsave(&mp->lock, flags);
-
mp->tx_ring_skbs++;
BUG_ON(mp->tx_ring_skbs > mp->tx_ring_size);
@@ -2742,12 +2732,9 @@
/* Check for ring index overlap in the Tx desc ring */
if (tx_desc_curr == tx_desc_used) {
mp->tx_resource_err = 1;
-
- spin_unlock_irqrestore(&mp->lock, flags);
return ETH_QUEUE_LAST_RESOURCE;
}
- spin_unlock_irqrestore(&mp->lock, flags);
return ETH_OK;
}
#endif
-
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: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction
Roland Dreier wrote: > + UCMA_MAX_BACKLOG= 128 Is there any reason that we might want to make this a tunable? Maybe as a module parameter that's writable in sysfs... There's no reason not to make this tunable. - Sean - 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: [openib-general] RE: [PATCH 2/5] [RFC] Infiniband: connection abstraction
Grant Grundler wrote: Is this code going to get invoked very often? In practice, it would be invoked when matching any listen requests originating from the CMA (RDMA connection abstraction). hrm..I'm not sure how to translate your answer into a workload. e.g. which netperf or netpipe test would excercise this alot? Or would it take something like MPI or specweb/ttcp? The code will be invoked at least once for every connection that is established. e.g something like: for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE/sizeof(unsigned long); i++) ((unsigned long *)dst)[i] = ((unsigned long *)src)[i] & ((unsigned long *)mask)[i]; Yes - something like this should work. Thanks. Do you need a patch? I can submit one but it will be untested. I will incorporate the change with the next set of updates. Someone else pointed out that I'd need to make sure that there won't be any alignment issues. - Sean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 09/13] mv643xx_eth: Hold spinlocks only where needed
On Wed, Jan 18, 2006 at 04:26:00PM +0100, Olaf Hering wrote: > On Mon, Jan 16, Dale Farnsworth wrote: > > > This driver has historically held a spin_lock during the entire open > > and stop functions and while receiving multiple packets. This is > > unecessarily long and holds locks during calls that may sleep. > > This patch reduces the size of windows where locks are held. > > I havent checked if this patch is the culprit, but 2.6.16-rc1-git1 does > lockup after modprobe -v mv643xx_eth , dhcpcd eth2. > Have to find a serial console for the pegasos, all I get on console is > > BUG: spinlock recursion on CPU#0, dhcpcd/2844 > lock: dd96f148, .magic: dead4ead, .owner: dhcpcd/2844, .owner_cpu:0 > BUG: spinlock lockup on CPU#0, dhcpdcd/2844, dd96f148 Thanks. That patch is indeed the culprit. I'll send a patch to Olaf for testing in the next hour or so. -Dale - 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: [openib-general] RE: [PATCH 2/5] [RFC] Infiniband: connection abstraction
On Wed, Jan 18, 2006 at 09:46:03AM -0800, Sean Hefty wrote: > Grant Grundler wrote: > >>+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask) ... > >Is this code going to get invoked very often? > > In practice, it would be invoked when matching any listen requests > originating from the CMA (RDMA connection abstraction). hrm..I'm not sure how to translate your answer into a workload. e.g. which netperf or netpipe test would excercise this alot? Or would it take something like MPI or specweb/ttcp? > >If so, can the mask operation use a "native" size since > >IB_CM_PRIVATE_DATA_COMPARE_SIZE is hard coded to 64 byte? > > > >e.g something like: > > for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE/sizeof(unsigned > > long); > > i++) > > ((unsigned long *)dst)[i] = ((unsigned long *)src)[i] > > & ((unsigned long *)mask)[i]; > > Yes - something like this should work. Thanks. Do you need a patch? I can submit one but it will be untested. thanks, grant - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [openib-general] RE: [PATCH 2/5] [RFC] Infiniband: connection abstraction
Grant Grundler wrote:
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] & mask[i];
+}
Is this code going to get invoked very often?
In practice, it would be invoked when matching any listen requests originating
from the CMA (RDMA connection abstraction).
If so, can the mask operation use a "native" size since
IB_CM_PRIVATE_DATA_COMPARE_SIZE is hard coded to 64 byte?
e.g something like:
for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE/sizeof(unsigned long);
i++)
((unsigned long *)dst)[i] = ((unsigned long *)src)[i]
& ((unsigned long *)mask)[i];
Yes - something like this should work. Thanks.
- Sean
-
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] s390: Remove CVS generated information.
From: Heiko Carstens <[EMAIL PROTECTED]> - Remove all CVS generated information like e.g. revision IDs from drivers/s390 and include/asm-s390 (none present in arch/s390). - Add newline at end of arch/s390/lib/Makefile to avoid diff message. Acked-by: Andreas Herrmann <[EMAIL PROTECTED]> Acked-by: Frank Pavlic <[EMAIL PROTECTED]> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- arch/s390/lib/Makefile |2 +- drivers/s390/block/dasd.c |1 - drivers/s390/block/dasd_3370_erp.c |1 - drivers/s390/block/dasd_3990_erp.c |1 - drivers/s390/block/dasd_9336_erp.c |1 - drivers/s390/block/dasd_9343_erp.c |1 - drivers/s390/block/dasd_cmb.c |2 -- drivers/s390/block/dasd_devmap.c |1 - drivers/s390/block/dasd_diag.c |1 - drivers/s390/block/dasd_diag.h |1 - drivers/s390/block/dasd_eckd.c |1 - drivers/s390/block/dasd_eckd.h |1 - drivers/s390/block/dasd_erp.c |1 - drivers/s390/block/dasd_fba.c |1 - drivers/s390/block/dasd_fba.h |1 - drivers/s390/block/dasd_genhd.c|1 - drivers/s390/block/dasd_int.h |1 - drivers/s390/block/dasd_ioctl.c|2 -- drivers/s390/block/dasd_proc.c |1 - drivers/s390/char/tape_34xx.c |5 ++--- drivers/s390/char/tape_class.c |4 ++-- drivers/s390/char/tape_class.h |2 +- drivers/s390/char/tape_core.c |5 ++--- drivers/s390/cio/airq.c|2 -- drivers/s390/cio/blacklist.c |1 - drivers/s390/cio/ccwgroup.c|1 - drivers/s390/cio/chsc.c|1 - drivers/s390/cio/cio.c |1 - drivers/s390/cio/cmf.c |2 +- drivers/s390/cio/css.c |1 - drivers/s390/cio/device.c |1 - drivers/s390/cio/device_ops.c |2 -- drivers/s390/cio/qdio.c|5 + drivers/s390/cio/qdio.h|2 -- drivers/s390/crypto/z90common.h|2 -- drivers/s390/crypto/z90crypt.h |2 -- drivers/s390/crypto/z90hardware.c |6 -- drivers/s390/crypto/z90main.c | 10 -- drivers/s390/net/claw.c| 11 +-- drivers/s390/net/claw.h|2 +- drivers/s390/net/ctcdbug.c |5 + drivers/s390/net/ctcdbug.h |4 +--- drivers/s390/net/ctcmain.c | 19 ++- drivers/s390/net/ctcmain.h |4 drivers/s390/net/ctctty.c |2 -- drivers/s390/net/ctctty.h |2 -- drivers/s390/net/cu3088.c |2 -- drivers/s390/net/fsm.c |2 -- drivers/s390/net/fsm.h |2 -- drivers/s390/net/iucv.c| 16 +--- drivers/s390/net/lcs.c |5 + drivers/s390/net/lcs.h |2 -- drivers/s390/net/netiucv.c | 15 +-- drivers/s390/net/qeth.h|2 -- drivers/s390/net/qeth_eddp.c |5 + drivers/s390/net/qeth_eddp.h |6 ++ drivers/s390/net/qeth_fs.h |5 - drivers/s390/net/qeth_main.c | 13 ++--- drivers/s390/net/qeth_mpc.c|2 -- drivers/s390/net/qeth_mpc.h|4 drivers/s390/net/qeth_proc.c |4 +--- drivers/s390/net/qeth_sys.c|4 +--- drivers/s390/net/qeth_tso.h|4 +--- drivers/s390/s390_rdev.c |1 - drivers/s390/scsi/zfcp_aux.c |2 -- drivers/s390/scsi/zfcp_ccw.c |2 -- drivers/s390/scsi/zfcp_dbf.c |2 -- drivers/s390/scsi/zfcp_def.h |2 -- drivers/s390/scsi/zfcp_erp.c |2 -- drivers/s390/scsi/zfcp_ext.h |2 -- drivers/s390/scsi/zfcp_fsf.c |2 -- drivers/s390/scsi/zfcp_qdio.c |2 -- drivers/s390/scsi/zfcp_scsi.c |2 -- drivers/s390/scsi/zfcp_sysfs_adapter.c |2 -- drivers/s390/scsi/zfcp_sysfs_driver.c |2 -- drivers/s390/scsi/zfcp_sysfs_port.c|2 -- drivers/s390/scsi/zfcp_sysfs_unit.c|2 -- include/asm-s390/dasd.h|2 -- include/asm-s390/qdio.h|2 -- 79 files changed, 27 insertions(+), 223 deletions(-) diff -urpN linux-2.6/arch/s390/lib/Makefile linux-2.6-patched/arch/s390/lib/Makefile --- linux-2.6/arch/s390/lib/Makefile2006-01-18 17:25:20.0 +0100 +++ linux-2.6-patched/arch/s390/lib/Makefile2006-01-18 17:25:47.0 +0100 @@ -6,4 +6,4 @@ EXTRA_AFLAGS := -traditional lib-y += delay.o string.o lib-y += $(if $(CONFIG_64BIT),uaccess64.o,uaccess.o) -lib-$(CONFIG_SMP) += spinlock.o \ No newline at end of file +lib-$(CONFIG_SMP) += spinlock.o diff -urpN linux-2.6/drivers/s390/block/das
Re: wireless: recap of current issues (other issues / fake ethernet)
On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote: > prism2 usb is even worse - the urb is build of some control structure, the > 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits > in the control structure decide whether the 802.11 or the 802.3 header is > used to create the frame sent to the air. I actually maintain a prism2 usb driver. It's host interface is truly fscked, and then there are the unfixable hardware bugs... But back to your point -- It's actually true of all prism2 devices. You can use one header or the other, but space for both is part of the fixed packet structure. Meanwhile, I've only seen one wireless chipset that *requires* 802.3 headers, and that is the prism54/prismGT/Indigo/Duette (FullMAC mode). Those adapters (except for the Indigo, which never made it into production anyway) can run in a softmac mode, which uses regular 802.11 headers. It's actually fairly common that hardware devices have the 802.11 header separated from the 802.11 payload slightly, if for no other reason that they need space to add the encryption headers. You can't make any assumptions. > Fortunately, a driver should be able to specify it's additional memory need > at > the front of the frame via hard_header_len. Some drivers will need to do some > ugly memmove()s at the packet begin then. This amount also varies with different encryption modes. And don't forget you also need space for an LLC+SNAP header and finally, you need a frame footer for encryption as well. > .. and it gets even worse as soon as we start encrypting packets. I think we > should start using the netdev wiki at http://linux-net.osdl.org/ to collect > information. For this part of the discussion, we need to know what transmit > frame formats different hardware needs. They're all over the map, yes.. there's no guarantee that the frame will be contiguious. It's annoying.. They also vary depending on encrpytion mode. Keep the 802.11 stack generic; split the packet into its logical block. On a per-frame basis, you have: - 802.11 header (variable length) - Encryption header (variable length) - LLC+SNAP header on payload (which we may need to add) - actual payload - Encryption footer (variable length) How's this strawman proposal: wiphy_frame_xmit (struct wiphy_dev *dev, struct sk_buff *skb); skb->data points to the raw payload, with LLC+SNAP header. skb->cb points to a structure that has, among other things: - 802.11 header + length - encryption header + length - encryption footer + length - desired data rate(s), antenna, rts/cts, and other tx params. - hw/sw encryption flag, and the key needed to encrypt. Given that I haven't seen two chipsets that do thigns the same way, there's little point in making the stack generic enough to rearrange these bits in the correct places. That said, we could provide a generic coalesce method for the general swcrypto+payload case, where the hardware would presumably treat it as an opaque payload. Each driver would be responsible for rearranging these chunks as appropriate, ideally using scatter-gather DMA. That's why the chunks are all specified as chunk+len; the driver can blindly copy the chunks without worrying about their contents. Chipsets that require payload padding when using crypto can tell the 802.11 stack of this requirement, and the stack will pass the appropriate pads in via the crypt_header and crypt_footer. I've put this stuff on the wiki, for what it's worth. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpGWgP3HKuy5.pgp Description: PGP signature
Re: how to obtain detailed e1000 stats?
Christopher Friesen wrote: It looks like the e1000 driver gathers all kinds of stats. How do I access these from userspace? /proc/net/dev will have many of the common ones, and ethtool should get the rest. If you want a hack, I have a patch against the ethtool logic that allows user-space to grab the netdev->stats struct and copy it directly to user-space. This is easier and most likely more efficient than parsing the /proc/net/dev file. Thanks, Ben Thanks, Chris - 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 -- 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: wireless: recap of current issues (stack)
On Wed, Jan 18, 2006 at 09:32:49AM +, Simon Kelley wrote: > That may be rather over-optimistic: the Atmel hardware dosen't even > produce consistent results over different chip revs. But each chip on its own is fairly consistent, which is all that random users care about. "More bars mean better signal!" :) > One technique which I implemented in the Atmel driver and which improved > signal quality reporting greatly was to factor in the time-decaying > average of the missed-beacon rate. Yeah, this technique works quite well. Every wireless chipset I've seen can attach a header to received frames that includes things like signal strength, and sometimes noise levels as well. It's trivial to strip this off and pass it via an out-of-band structure (pointed to in skb->cb), along with other pertinent information like frequency, hardware timestamps, etc. This structure would be stripped before it's passed into netif_rx(). As well as giving the stack real-time information about signal levels, rx data rates, and stuff like that, this technique makes monitor mode a lot simpler across different hardware types, as you can just build the "monitor header" in one place in the stack, just before it goes to the netif_rx() call... Once you have this real-time signal information.. it opens up the door for many things in the stack, like opportunistic scanning or roamimg triggered by signal thresholds, etc... and userspace polling can just pull the current state whenever it wants. It's also a useful input into a rate control algorithm. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpfBBgsndwvl.pgp Description: PGP signature
Re: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction
> +UCMA_MAX_BACKLOG= 128 Is there any reason that we might want to make this a tunable? Maybe as a module parameter that's writable in sysfs... - R. - 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: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction
> +struct ucma_file {
> +struct semaphoremutex;
This should be a struct mutex instead, I think.
> +static DECLARE_MUTEX(ctx_mutex);
Same here.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 09/13] mv643xx_eth: Hold spinlocks only where needed
On Mon, Jan 16, Dale Farnsworth wrote: > This driver has historically held a spin_lock during the entire open > and stop functions and while receiving multiple packets. This is > unecessarily long and holds locks during calls that may sleep. > This patch reduces the size of windows where locks are held. I havent checked if this patch is the culprit, but 2.6.16-rc1-git1 does lockup after modprobe -v mv643xx_eth , dhcpcd eth2. Have to find a serial console for the pegasos, all I get on console is BUG: spinlock recursion on CPU#0, dhcpcd/2844 lock: dd96f148, .magic: dead4ead, .owner: dhcpcd/2844, .owner_cpu:0 BUG: spinlock lockup on CPU#0, dhcpdcd/2844, dd96f148 -- short story of a lazy sysadmin: alias appserv=wotan - 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
