Re: [git patches] net driver fixes (50% rebased)
From: Jeff Garzik [EMAIL PROTECTED] Date: Sun, 24 Feb 2008 00:20:41 -0500 This is a 50% resend, rebased on top of net-2.6. Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: Pulled and pushed back out, thanks 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: [git patches] net driver fixes
David Miller wrote: Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) My main issues/motivations were: * quite simply, just force of habit: I'm used to basing off of a recent Linus tree, to guarantee buildboot testing against the latest. * worry about testing against a too-old tree, where non-networking fixes may have a relevant impact on my to-be-pushed netdrvr fixes. But in this case it's fair to say there are no such issues, and it was mainly just out of habit. So (as you saw in last email)... rebased and resend. 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: [git patches] net driver fixes
From: Jeff Garzik [EMAIL PROTECTED] Date: Sun, 24 Feb 2008 00:48:54 -0500 I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) ... So (as you saw in last email)... rebased and resend. Thanks :) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 11:55:57 -0500 Note: this is based off of Linus's latest commit (5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous submissions are now upstream (thanks!). The whole point of my not rebasing net-2.6 is so that you can always use it as a base. With what you've giving me now I either have to: 1) Pull in Linus's tree to net-2.6, then pull from you. 2) Pull in directly from you to get it all. The whole point of my not touching or rebasing net-2.6 is so that everyonce can simply use it as a base and just keep working relative to it. If you have some need for upstream stuff outside networking (f.e. some ACPI bug prevents interrupts from working or there is some build failure), you can clone Linus's tree and pull net-2.6 and your driver bits into there for building and testing. Thanks for your consideration, I'm trying to show you mine by giving everyone a relatively stable tree in which all networking development can occur. -- 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] net driver fixes
From: J. Bruce Fields [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 16:23:02 -0500 On Wed, Feb 20, 2008 at 01:15:30PM -0800, David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 11:55:57 -0500 Note: this is based off of Linus's latest commit (5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous submissions are now upstream (thanks!). The whole point of my not rebasing net-2.6 is so that you can always use it as a base. With what you've giving me now I either have to: 1) Pull in Linus's tree to net-2.6, then pull from you. 2) Pull in directly from you to get it all. Why are either of those a problem? Because it forces me to pull Linus's upstream into net-2.6, I don't have any choice in the matter. -- 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] net driver fixes
On Wed, Feb 20, 2008 at 01:15:30PM -0800, David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 11:55:57 -0500 Note: this is based off of Linus's latest commit (5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous submissions are now upstream (thanks!). The whole point of my not rebasing net-2.6 is so that you can always use it as a base. With what you've giving me now I either have to: 1) Pull in Linus's tree to net-2.6, then pull from you. 2) Pull in directly from you to get it all. Why are either of those a problem? --b. -- 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] net driver fixes
On Wed, Feb 20, 2008 at 01:42:57PM -0800, David Miller wrote: From: J. Bruce Fields [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 16:23:02 -0500 On Wed, Feb 20, 2008 at 01:15:30PM -0800, David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 11:55:57 -0500 Note: this is based off of Linus's latest commit (5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous submissions are now upstream (thanks!). The whole point of my not rebasing net-2.6 is so that you can always use it as a base. With what you've giving me now I either have to: 1) Pull in Linus's tree to net-2.6, then pull from you. 2) Pull in directly from you to get it all. Why are either of those a problem? Because it forces me to pull Linus's upstream into net-2.6, I don't have any choice in the matter. Right. I'm wondering what the problems are that you see with that. The advantages include earlier warning of merge problems, and avoidance of duplicate commits--if Jeff's done work that depends on patches that already upstream, then he either does that work against upstream, or includes backported patches in the branch he asks you to pull, and you end up with both the original and the backported patch. Which isn't the end of the world, but the resulting history seems messier than necessary. Or I guess you could both wait to do this merge until you're ready to pull in Linus's latest? For non-git-using testers there may be an advantage to always keeping a tree based on the latest tagged release, as it may simplify providing them with patches in some cases. But if the goal is to provide a basis for other maintainer's work, I'd've thought the best policy would be just to track the tip of every relevant branch (which includes Linus's in this case). --b. -- 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] net driver fixes
From: J. Bruce Fields [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 17:25:30 -0500 The advantages include earlier warning of merge problems, and avoidance of duplicate commits--if Jeff's done work that depends on patches that already upstream, then he either does that work against upstream, or includes backported patches in the branch he asks you to pull, and you end up with both the original and the backported patch. Which isn't the end of the world, but the resulting history seems messier than necessary. Or I guess you could both wait to do this merge until you're ready to pull in Linus's latest? I do a test pull and build of net-2.6 into Linus's current tree before I send Linus a pull request. If any non-trivial merges are necessary, which hasn't happened yet at all, I would then do a merge into my net-2.6 tree and resolve the conflicts. There is no reason for someone downstream of net-2.6 to do 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: [git patches] net driver fixes
David Miller [EMAIL PROTECTED] : [...] Because it forces me to pull Linus's upstream into net-2.6, I don't have any choice in the matter. Jeff's choice is a bit surprizing. That being said, it would had been nice to fast-forward net-2.6 from a442585952f137bd4cdb1f2f3166e4157d383b82 to Linus's upstream before applying the content of 12aa343add3eced38a44bdb612b35fdf634d918c in order to keep the drift with Linus's branch to a minimum during the bugfix cycle. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
From: Francois Romieu [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 23:40:53 +0100 David Miller [EMAIL PROTECTED] : [...] Because it forces me to pull Linus's upstream into net-2.6, I don't have any choice in the matter. Jeff's choice is a bit surprizing. That being said, it would had been nice to fast-forward net-2.6 from a442585952f137bd4cdb1f2f3166e4157d383b82 to Linus's upstream before applying the content of 12aa343add3eced38a44bdb612b35fdf634d918c in order to keep the drift with Linus's branch to a minimum during the bugfix cycle. Keep in mind there are also pending fixes in my net-2.6 tree which Linus hasn't pulled in yet as well. I watch Linus's tree closely, and I'll see any potential merge issue long before it matters, and I always double check before pushing stuff out to him. My job as tree master is to deal with all the merge hassles, should they occur. But up until now everything networking has gone through my tree and everything is fine. The net-2.6 tree isn't even a week old. I planned to pull Linus's tree in right before I leave for a short trip tomorrow afternoon. I'm really not being allowed to make that choice by how these changes are being merged to me. Heck, Jeff even thanked me for making my net-2.6 tree stable and not rebasing, so his method of merging this stuff is doubly surprising for me. Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. Thanks! -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 15 Feb 2008 11:03:14 -0500 Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem Pulled and pushed out. As I mentioned to John Linville just now, I'm going to try and keep net-2.6 running as long as I can without rebasing. So you can just keep piling patches into your upstream-davem branch without fear of my turning your world upside down with a rebase :-) -- 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] net driver fixes
David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 15 Feb 2008 11:03:14 -0500 Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem Pulled and pushed out. As I mentioned to John Linville just now, I'm going to try and keep net-2.6 running as long as I can without rebasing. So you can just keep piling patches into your upstream-davem branch without fear of my turning your world upside down with a rebase :-) Thanks, it's appreciated! 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: [git patches] net driver fixes
Jeff Garzik (1):
[netdrvr] sis190: build fix
But you did it wrong...
sis190.c b/drivers/net/sis190.c
index b570402..2e9e88b 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -326,7 +326,7 @@ static const struct {
{ SiS 191 PCI Gigabit Ethernet adapter },
};
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static struct pci_device_id sis190_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
The __devinitdata is OK, it is the following _devinitdata that had to be
_devinitconst.
Sam
--
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] net driver fixes
Sam Ravnborg wrote:
Jeff Garzik (1):
[netdrvr] sis190: build fix
But you did it wrong...
sis190.c b/drivers/net/sis190.c
index b570402..2e9e88b 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -326,7 +326,7 @@ static const struct {
{ SiS 191 PCI Gigabit Ethernet adapter },
};
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static struct pci_device_id sis190_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
The __devinitdata is OK, it is the following _devinitdata that had to be
_devinitconst.
Cool. Either way is fine with me. I just wanted to get a build fix
upstream ASAP, one I was sure would work.
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: [git patches] net driver fixes
Sam Ravnborg [EMAIL PROTECTED] :
[...]
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static struct pci_device_id sis190_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
The __devinitdata is OK, it is the following _devinitdata that had
to be _devinitconst.
Strangely enough, removing the devinitdata from the sis190_pci_tbl
silents the error message here. Do you have an explanation ?
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
On Wed, Jan 30, 2008 at 11:47:11PM +0100, Francois Romieu wrote:
Sam Ravnborg [EMAIL PROTECTED] :
[...]
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static struct pci_device_id sis190_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
The __devinitdata is OK, it is the following _devinitdata that had
to be _devinitconst.
Strangely enough, removing the devinitdata from the sis190_pci_tbl
silents the error message here. Do you have an explanation ?
gcc compalins if you add const and non-const data to the same section
which is the case in this driver.
The bug are exposed now where __devinitdata are no longer an empty define.
Sam
--
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] net driver fixes
From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 23 Jan 2008 05:05:18 -0500 master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem Pulled into net-2.6, thanks 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: [git patches] net driver fixes
Well, it's 2.6.24-rc7 already - any news? I put this into my net-2.6 tree last night since Jeff asked me to look over critical networking driver stuff for a little while. Thanks, they are upstream now and it did fix tulip in my PPC - network is stable again. -- Meelis Roos ([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: [git patches] net driver fixes
JG A couple [minorly] notable wireless bug fixes, and plenty of viro fixes JG for obscure issues :) What about the tulip NAPI fix from Stephen Hemminger? Without this, my tulip is hosed easily. The thread where I reported it was Badness at net/core/dev.c:2199, around Dec 16. That's going up in the first post-Xmas batch. Well, it's 2.6.24-rc7 already - any news? -- Meelis Roos ([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: [git patches] net driver fixes
From: Meelis Roos [EMAIL PROTECTED] Date: Mon, 7 Jan 2008 14:44:03 +0200 (EET) JG A couple [minorly] notable wireless bug fixes, and plenty of viro fixes JG for obscure issues :) What about the tulip NAPI fix from Stephen Hemminger? Without this, my tulip is hosed easily. The thread where I reported it was Badness at net/core/dev.c:2199, around Dec 16. That's going up in the first post-Xmas batch. Well, it's 2.6.24-rc7 already - any news? I put this into my net-2.6 tree last night since Jeff asked me to look over critical networking driver stuff for a little while. -- 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] net driver fixes
On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote: A couple [minorly] notable wireless bug fixes, and plenty of viro fixes for obscure issues :) Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also belongs in the same set. If you need a resend - tell... There's another pile in drivers/net/wireless, but that's for linville to forward when he gets around to it. Pure annotation patches belong to past-2.6.24 merge. I also have starfire and epic100 fixes, but that'll have to wait until I get around to putting the cards into sparc box (mcast breakage for starfire and full-driver one for epic100; since nobody had cared for the latter since 2.3.late, well...) I think I'll have an ipg fix for you tomorrow, but I want to RTFM first to make sure that it makes sense. And there are several interesting issues in atl1, netxen and cxgb3, but those will have to wait for when I get around to asking maintainers just what the hell did they mean those to do. FWIW, drivers/net is fairly noise-free wrt sparse endianness warnings in my tree; the main exceptions are prism54 (oid_mgt.c and the nightmares it pulls) and skfp (AIX-shared vendor driver; 'nuff said, IMO). BTW, if you still have any documentation for xircom_cb from your fighting tulip-related stuff, it would be welcome - there are some oddities with rx ring handling (assuming that we care about that driver at all and it's not on the way out, that 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
Re: [git patches] net driver fixes
Al Viro wrote: On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote: A couple [minorly] notable wireless bug fixes, and plenty of viro fixes for obscure issues :) Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also belongs in the same set. If you need a resend - tell... I applied it to #upstream (2.6.25) since forcedeth is not on any big-endian platforms AFAIK. Is it .24 material for some obvious reason, which I missed? :) There's another pile in drivers/net/wireless, but that's for linville to forward when he gets around to it. Pure annotation patches belong to past-2.6.24 merge. I also have starfire and epic100 fixes, but that'll have to wait until I get around to putting the cards into sparc box (mcast breakage for starfire and full-driver one for epic100; since nobody had cared for the latter since 2.3.late, well...) I have an epic100 card too if you need it (though it sounds like you have something testable). I think I'll have an ipg fix for you tomorrow, but I want to RTFM first to make sure that it makes sense. And there are several interesting issues in atl1, netxen and cxgb3, but those will have to wait for when I get around to asking maintainers just what the hell did they mean those to do. FWIW, drivers/net is fairly noise-free wrt sparse endianness warnings in my tree; the main exceptions are prism54 (oid_mgt.c and the nightmares it pulls) and skfp (AIX-shared vendor driver; 'nuff said, IMO). Awesome :) BTW, if you still have any documentation for xircom_cb from your fighting tulip-related stuff, it would be welcome - there are some oddities with rx ring handling (assuming that we care about that driver at all and it's not on the way out, that is). xircom_tulip_cb should probably be deleted, since it is the crappier of the two drivers for the same hardware (xircom_cb being the other one). xircom_cb _the driver_ is pretty odd. It is less like tulip than it should be, actually. There are several things that could have been done to improve the throughput/etc. of the driver, but it was more important at the time to simply find a driver that always worked. IIRC its RX filtering was broken, implying the need to enable promisc mode just to receive packets normally. 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: [git patches] net driver fixes
On Sun, Dec 23, 2007 at 01:42:14AM -0500, Jeff Garzik wrote: I applied it to #upstream (2.6.25) since forcedeth is not on any big-endian platforms AFAIK. All right, then... I hadn't been sure if it's onboard-only, that's all. I have an epic100 card too if you need it (though it sounds like you have something testable). Picked one for a fiver on ebay, just need to get around to putting it into that U60 box and testing; not a problem, just hadn't got around to doing that yet. -- 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] net driver fixes
Jeff Garzik wrote: A couple serious fixes (wireless, e100, sky2) and a bevy of minor ones. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Hi Jeff, Should I resend the 2 cxgb3 patches posted on 12/05 and 12/06 ? I did not see them getting applied to the #upstream branch today. Cheers, Divy -- 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] net driver fixes
Divy Le Ray wrote: Jeff Garzik wrote: A couple serious fixes (wireless, e100, sky2) and a bevy of minor ones. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Hi Jeff, Should I resend the 2 cxgb3 patches posted on 12/05 and 12/06 ? I did not see them getting applied to the #upstream branch today. Cheers, Divy -- 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 The last thing I have from you, in netdev#upstream, is commit 75758e8aa4b7d5c651261ce653dd8d0b716e1eda Author: Divy Le Ray [EMAIL PROTECTED] Date: Wed Dec 5 10:15:01 2007 -0800 cxgb3 - T3C support update Update GPIO mapping for T3C. Update xgmac for T3C support. Fix typo in mtu table. and there's nothing in my inbox. So if that is not the change you want, yes, please do resend. 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: [git patches] net driver fixes
http://vger.kernel.org/majordomo-info.html The last thing I have from you, in netdev#upstream, is commit 75758e8aa4b7d5c651261ce653dd8d0b716e1eda Author: Divy Le Ray [EMAIL PROTECTED] Date: Wed Dec 5 10:15:01 2007 -0800 cxgb3 - T3C support update Update GPIO mapping for T3C. Update xgmac for T3C support. Fix typo in mtu table. and there's nothing in my inbox. So if that is not the change you want, yes, please do resend. Okay, I just resent. You originally attempted to apply these patches to the #upstream-fixes branch, which failed for the 2 patches i just reposted. I guess it is why they're no longer in your inbox. Cheers, Divy -- 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] net driver fixes
On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c | 19 +++
drivers/net/ehea/ehea.h |5 -
drivers/net/ehea/ehea_main.c | 16 ++--
drivers/net/phy/phy.c|4 ++--
drivers/net/phy/phy_device.c |4 ++--
drivers/net/sky2.c |9 -
drivers/net/spider_net.c | 12
7 files changed, 41 insertions(+), 28 deletions(-)
Hans-Jürgen Koch (1):
Fix a lock problem in generic phy code
Ishizaki Kou (1):
spidernet: fix interrupt reason recognition
Jan-Bernd Themann (2):
ehea: propagate physical port state
ehea: fix last_rx update
Luca Tettamanti (1):
atl1: disable broken 64-bit DMA
Stephen Hemminger (1):
sky2: restore multicast list on resume and other ops
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 3c1984e..f23e13c 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2203,21 +2203,20 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
struct net_device *netdev;
struct atl1_adapter *adapter;
static int cards_found = 0;
- bool pci_using_64 = true;
int err;
err = pci_enable_device(pdev);
if (err)
return err;
- err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
+ /*
+ * 64-bit DMA currently has data corruption problems, so let's just
+ * use 32-bit DMA for now. This is a big hack that is probably wrong.
+ */
+ err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (err) {
- err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
- if (err) {
- dev_err(pdev-dev, no usable DMA configuration\n);
- goto err_dma;
- }
- pci_using_64 = false;
+ dev_err(pdev-dev, no usable DMA configuration\n);
+ goto err_dma;
}
/* Mark all PCI regions associated with PCI device
* pdev as being reserved by owner atl1_driver_name
@@ -2282,7 +2281,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev-ethtool_ops = atl1_ethtool_ops;
adapter-bd_number = cards_found;
- adapter-pci_using_64 = pci_using_64;
/* setup the private structure */
err = atl1_sw_init(adapter);
@@ -2299,9 +2297,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
*/
/* netdev-features |= NETIF_F_TSO; */
- if (pci_using_64)
- netdev-features |= NETIF_F_HIGHDMA;
-
netdev-features |= NETIF_F_LLTX;
/*
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index d67f97b..8d58be5 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSION EHEA_0073
+#define DRV_VERSION EHEA_0074
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -402,6 +402,8 @@ struct ehea_mc_list {
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
+#define EHEA_PHY_LINK_UP 1
+#define EHEA_PHY_LINK_DOWN 0
#define EHEA_MAX_PORT_RES 16
struct ehea_port {
struct ehea_adapter *adapter;/* adapter that owns this port */
@@ -427,6 +429,7 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
+ u8 phy_link;
u8 full_duplex;
u8 autoneg;
u8 num_def_qps;
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index db57474..717b129 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -53,17 +53,21 @@ static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 0;
static int num_tx_qps = EHEA_NUM_TX_QP;
+static int prop_carrier_state = 0;
module_param(msg_level, int, 0);
module_param(rq1_entries, int, 0);
module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
+module_param(prop_carrier_state, int, 0);
module_param(use_mcs, int, 0);
module_param(num_tx_qps, int, 0);
MODULE_PARM_DESC(num_tx_qps, Number of TX-QPS);
MODULE_PARM_DESC(msg_level, msg_level);
+MODULE_PARM_DESC(prop_carrier_state, Propagate carrier state of physical
+ port to stack. 1:yes, 0:no. Default = 0 );
WTF? why would the default be to _not_ propagate carrier state? Are
there some mitigating circumstances that require this driver to not
notify the stack of carrier on/off? Userspace stuff really should know
about the carrier state, and this disables it by default.
Dan
MODULE_PARM_DESC(rq3_entries, Number of entries for Receive Queue 3
[2^x - 1], x = [6..14]. Default =
Re: [git patches] net driver fixes
Dan Williams wrote: WTF? why would the default be to _not_ propagate carrier state? Are there some mitigating circumstances that require this driver to not notify the stack of carrier on/off? Userspace stuff really should know about the carrier state, and this disables it by default. The commit explains that... 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: [git patches] net driver fixes
On Fri, 2007-09-14 at 14:17 -0400, Jeff Garzik wrote: Dan Williams wrote: WTF? why would the default be to _not_ propagate carrier state? Are there some mitigating circumstances that require this driver to not notify the stack of carrier on/off? Userspace stuff really should know about the carrier state, and this disables it by default. The commit explains that... I admit that I probably don't understand the system architecture of where ehea would be used, but would this cause /sys/class/net/ethX/carrier to be TRUE even if the device has no carrier? That seems quite wrong IMHO. When does ehea not have a carrier? And in that case, does sysfs say 1 or 0 for the carrier? Dan - 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] net driver fixes
Dan Williams [EMAIL PROTECTED] wrote: [...] I admit that I probably don't understand the system architecture of where ehea would be used, but would this cause /sys/class/net/ethX/carrier to be TRUE even if the device has no carrier? That seems quite wrong IMHO. When does ehea not have a carrier? And in that case, does sysfs say 1 or 0 for the carrier? I don't work on ehea, but I'm generally familiar with it, and particularly with this patch. The usual environment for ehea devices is on large systems subdivided into multiple logical partitions. One ehea device serves many partitions. By having ehea always report link up to the logical ports (the ports seen by the partitions), the partitions can communicate amongst themselves even if the external ports (the ports that go to the switch or whatever) have no link. The ehea device, more or less, acts as a switch connecting the partitions together. This switch type of functionality is not dependent upon the link state of the external ports (any more than the functionality of any switch is dependent upon whether or not it is connected to a gateway). This, if I'm not mistaken, is the way ehea has always operated until this particular patch was added. This patch (to optionally pass carrier state to the logical ports) was added largely for bonding, so that the bonding driver can detect link failures on the external ports (when so desired). The default behavior remains the original behavior, i.e., do not pass external port link state to the logical ports. Anyway, to answer your question, the carrier state reported for the ehea interface on the partition will always be true. Think of it as reporting the link state from the logical interface to the switch that connects the partitions; that link exists only within the ehea device itself, and really can't fail unless the ehea device itself fails. With the new option enabled, then ehea is more or less mimicing a trunk failover type of function, and passing the carrier state of the external switch port to the internal port. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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: [git patches] net driver fixes
On Fri, 2007-09-14 at 12:19 -0700, Jay Vosburgh wrote: Dan Williams [EMAIL PROTECTED] wrote: [...] I admit that I probably don't understand the system architecture of where ehea would be used, but would this cause /sys/class/net/ethX/carrier to be TRUE even if the device has no carrier? That seems quite wrong IMHO. When does ehea not have a carrier? And in that case, does sysfs say 1 or 0 for the carrier? I don't work on ehea, but I'm generally familiar with it, and particularly with this patch. The usual environment for ehea devices is on large systems subdivided into multiple logical partitions. One ehea device serves many partitions. By having ehea always report link up to the logical ports (the ports seen by the partitions), the partitions can communicate amongst themselves even if the external ports (the ports that go to the switch or whatever) have no link. (forgive my ignorance of course) So essentially the ehea device has a 1(+) external ports that may/may not be connected, but all lpars share the physical hardware itself, which is quite happy to let all the lpars talk to each other essentially via loopback even if there is no actual carrier detected on the external port(s)? How does addressing work here, is it just L2 addresses? Feel free to point me to some docs and tell me to shut up :) At least these days module parameters can be changed at runtime through sysfs. Stuff that can only be set at module load doesn't provide userspace the flexibility it needs to configure stuff on the fly. Dan The ehea device, more or less, acts as a switch connecting the partitions together. This switch type of functionality is not dependent upon the link state of the external ports (any more than the functionality of any switch is dependent upon whether or not it is connected to a gateway). This, if I'm not mistaken, is the way ehea has always operated until this particular patch was added. This patch (to optionally pass carrier state to the logical ports) was added largely for bonding, so that the bonding driver can detect link failures on the external ports (when so desired). The default behavior remains the original behavior, i.e., do not pass external port link state to the logical ports. Anyway, to answer your question, the carrier state reported for the ehea interface on the partition will always be true. Think of it as reporting the link state from the logical interface to the switch that connects the partitions; that link exists only within the ehea device itself, and really can't fail unless the ehea device itself fails. With the new option enabled, then ehea is more or less mimicing a trunk failover type of function, and passing the carrier state of the external switch port to the internal port. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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: [git patches] net driver fixes
Dan Williams [EMAIL PROTECTED] wrote: [...] So essentially the ehea device has a 1(+) external ports that may/may not be connected, but all lpars share the physical hardware itself, which is quite happy to let all the lpars talk to each other essentially via loopback even if there is no actual carrier detected on the external port(s)? [...] Yes. [...] How does addressing work here, is it just L2 addresses? Yes. The logical ports all have unique MAC addresses. [...] Feel free to point me to some docs and tell me to shut up :) http://www.redbooks.ibm.com/redpieces/abstracts/redp4340.html I found this via google; I haven't read it in detail, but it seems to cover the HEA architecture at a high level. It talks about the whole IVE (integrated virtual ethernet: the adapter, hypervisor, etc) system, but HEA is part of that, so it's probably got the answers you're looking for. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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: [git patches] net driver fixes
Dan Williams wrote:
On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c | 19 +++
drivers/net/ehea/ehea.h |5 -
drivers/net/ehea/ehea_main.c | 16 ++--
drivers/net/phy/phy.c|4 ++--
drivers/net/phy/phy_device.c |4 ++--
drivers/net/sky2.c |9 -
drivers/net/spider_net.c | 12
7 files changed, 41 insertions(+), 28 deletions(-)
Hans-Jürgen Koch (1):
Fix a lock problem in generic phy code
Ishizaki Kou (1):
spidernet: fix interrupt reason recognition
Jan-Bernd Themann (2):
ehea: propagate physical port state
ehea: fix last_rx update
maybe a little bit late with this comment:
ehea_error(Failed setting port speed);
}
}
- netif_carrier_on(port-netdev);
+ if (!prop_carrier_state || (port-phy_link == EHEA_PHY_LINK_UP))
+ netif_carrier_on(port-netdev);
+
kfree(cb4);
out:
return ret;
@@ -869,13 +875,19 @@ static void ehea_parse_eqe(struct ehea_adapter *adapter,
u64 eqe)
}
if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PORT_UP, eqe)) {
+ port-phy_link = EHEA_PHY_LINK_UP;
if (netif_msg_link(port))
ehea_info(%s: Physical port up,
port-netdev-name);
+ if (prop_carrier_state)
+ netif_carrier_on(port-netdev);
} else {
+ port-phy_link = EHEA_PHY_LINK_DOWN;
if (netif_msg_link(port))
ehea_info(%s: Physical port down,
port-netdev-name);
+ if (prop_carrier_state)
+ netif_carrier_off(port-netdev);
maybe it was better to code this as 'ehea_carrier_off/on()' which then tests
(prop_carrier_state) - this now begs for regressions where this isn't properly
done in future commits, and on top of that there are all these extra conditions now.
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
Satyam Sharma wrote: On Mon, 30 Jul 2007, Jeff Garzik wrote: true, we should just remove the dev==NULL check Patch below: [PATCH] nmclan_cs: Remove bogus (dev==NULL) check in mace_interrupt() The (dev == NULL) check in drivers/net/pcmcia/nmclan_cs.c:mace_interrupt() handler is always false, so let's remove it. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] --- drivers/net/pcmcia/nmclan_cs.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) ACK, but patch does not apply to netdev-2.6.git#upstream alas - 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] net driver fixes
On Mon, 30 Jul 2007, Jeff Garzik wrote:
true, we should just remove the dev==NULL check
Patch below:
[PATCH] nmclan_cs: Remove bogus (dev==NULL) check in mace_interrupt()
The (dev == NULL) check in drivers/net/pcmcia/nmclan_cs.c:mace_interrupt()
handler is always false, so let's remove it.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/net/pcmcia/nmclan_cs.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c
index 73da611..3446be9 100644
--- a/drivers/net/pcmcia/nmclan_cs.c
+++ b/drivers/net/pcmcia/nmclan_cs.c
@@ -1000,12 +1000,6 @@ static irqreturn_t mace_interrupt(int irq, void *dev_id)
int status;
int IntrCnt = MACE_MAX_IR_ITERATIONS;
- if (dev == NULL) {
-DEBUG(2, mace_interrupt(): irq 0x%X for unknown device.\n,
- irq);
-return IRQ_NONE;
- }
-
if (lp-tx_irq_disabled) {
printk(
(lp-tx_irq_disabled?
-
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] net driver fixes
On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
...
maximilian attems (1):
starfire list alpha as 64 bit arch
...
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
* This SUCKS.
* We need a much better method to determine if dma_addr_t is 64-bit.
*/
-#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__)
|| defined (__ia64__) || defined(__mips64__) || (defined(__mips__)
defined(CONFIG_HIGHMEM) defined(CONFIG_64BIT_PHYS_ADDR))
+#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__)
|| defined (__ia64__) || defined(__alpha__) || defined(__mips64__) ||
(defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
/* 64-bit dma_addr_t */
#define ADDR_64BITS /* This chip uses 64 bit addresses. */
#define netdrv_addr_t u64
...
The patch is correct and definitely the best solution at this time of
the 2.6.22 development cycle.
But the comment in the context exactly matches what I thought when
I saw this code...
Does anyone have a suggestion how to do this better?
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
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] net driver fixes
On Tue, 3 Jul 2007 00:13:29 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
...
maximilian attems (1):
starfire list alpha as 64 bit arch
...
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
* This SUCKS.
* We need a much better method to determine if dma_addr_t is 64-bit.
*/
-#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) ||
defined(__x86_64__) || defined (__ia64__) || defined(__mips64__) ||
(defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
+#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) ||
defined(__x86_64__) || defined (__ia64__) || defined(__alpha__) ||
defined(__mips64__) || (defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
/* 64-bit dma_addr_t */
#define ADDR_64BITS/* This chip uses 64 bit addresses. */
#define netdrv_addr_t u64
...
The patch is correct and definitely the best solution at this time of
the 2.6.22 development cycle.
But the comment in the context exactly matches what I thought when
I saw this code...
Does anyone have a suggestion how to do this better?
cu
Adrian
Yeah, write code that handles it in compiler. Like:
if (sizeof(dma_addr_t) sizeof(u32)) {
do something...
}
That means that it gets checked even if optimizer removes it as
unneeded.
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
On Thu, 29 Mar 2007, Jeff Garzik wrote: Guennadi Liakhovetski wrote: Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Can you resend the patch to me, please? Easier for the system to apply than the URL... Sure, attached below. I think, though, this patch is already in someone's tree. Andrew has applied it to -mm under the name ppp-dont-leak-an-sk_buff-on-interface-destruction.patch but then dropped with the reasoning This patch was dropped because it was merged into mainline or a subsystem tree. So, maybe it is now in Samuel's IrDA tree. Samuel?So, maybe all you have to do is to pull it from his tree. Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany Don't leak an sk_buff on interface destruction. Signed-off-by: G. Liakhovetski [EMAIL PROTECTED] --- a/drivers/net/ppp_generic.c 2007-03-23 13:04:04.0 +0100 +++ b/drivers/net/ppp_generic.c 2007-03-23 13:05:29.0 +0100 @@ -2544,6 +2544,9 @@ ppp-active_filter = NULL; #endif /* CONFIG_PPP_FILTER */ + if (ppp-xmit_pending) + kfree_skb(ppp-xmit_pending); + kfree(ppp); } - 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] net driver fixes
On 3/30/2007, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007, Jeff Garzik wrote: Guennadi Liakhovetski wrote: Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Can you resend the patch to me, please? Easier for the system to apply than the URL... Sure, attached below. I think, though, this patch is already in someone's tree. Andrew has applied it to -mm under the name ppp-dont-leak-an-sk_buff-on-interface-destruction.patch but then dropped with the reasoning This patch was dropped because it was merged into mainline or a subsystem tree. So, maybe it is now in Samuel's IrDA tree. Samuel?So, maybe all you have to do is to pull it from his tree. It's already in Linus tree, and has landed there through davem's net-2.6 tree. So, this is all taken care of, Jeff doesn't need to worry about this one. Cheers, Samuel. Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany Don't leak an sk_buff on interface destruction. Signed-off-by: G. Liakhovetski [EMAIL PROTECTED] --- a/drivers/net/ppp_generic.c2007-03-23 13:04:04.0 +0100 +++ b/drivers/net/ppp_generic.c2007-03-23 13:05:29.0 +0100 @@ -2544,6 +2544,9 @@ ppp-active_filter = NULL; #endif /* CONFIG_PPP_FILTER */ + if (ppp-xmit_pending) + kfree_skb(ppp-xmit_pending); + kfree(ppp); } - 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] net driver fixes
Guennadi Liakhovetski wrote: Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Can you resend the patch to me, please? Easier for the system to apply than the URL... 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: [git patches] net driver fixes
Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Thanks Guennadi --- Guennadi Liakhovetski - 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] net driver fixes
On Tue, 6 Mar 2007, Jeff Garzik wrote:
Jay Vosburgh (3):
bonding: Improve IGMP join processing
ip_mc_rejoin_group: Kill warning about unused variable `in_dev' when
CONFIG_IP_MULTICAST is not set.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 1c6a084..8cedb2a 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1255,9 +1255,9 @@ out:
*/
void ip_mc_rejoin_group(struct ip_mc_list *im)
{
+#ifdef CONFIG_IP_MULTICAST
struct in_device *in_dev = im-interface;
-#ifdef CONFIG_IP_MULTICAST
if (im-multiaddr == IGMP_ALL_HOSTS)
return;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
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] net driver fixes
From: Geert Uytterhoeven [EMAIL PROTECTED] Date: Mon, 12 Mar 2007 11:02:43 +0100 (CET) On Tue, 6 Mar 2007, Jeff Garzik wrote: Jay Vosburgh (3): bonding: Improve IGMP join processing ip_mc_rejoin_group: Kill warning about unused variable `in_dev' when CONFIG_IP_MULTICAST is not set. Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] Applied, thanks Geert. - 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] net driver fixes
On Thu, 1 Mar 2007, Kok, Auke wrote: Linus Torvalds wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. Just out of curiosity, which e1000 chipset+motherboard are you running this on? The kernel prints out: e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:76:c7:eb:fe e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection and lspci says: 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 0001 Flags: bus master, fast devsel, latency 0, IRQ 506 Memory at e040 (32-bit, non-prefetchable) [size=128K] Memory at e0424000 (32-bit, non-prefetchable) [size=4K] I/O ports at 20c0 [size=32] Capabilities: access denied 00: 86 80 4a 10 07 04 10 00 02 00 00 02 00 00 00 00 10: 00 00 40 e0 00 40 42 e0 c1 20 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 01 00 30: 00 00 00 00 c8 00 00 00 00 00 00 00 0b 01 00 00 It's an Intel system (Host bridge: Intel Corporation 82Q963/Q965) with integrated graphics: PCI ID 8086:2990 (rev 02) for the host bridge. DMI info isn't very interesting, but it's an all-Intel board: OEM-specific Type Strings: Intel_ASF Intel_ASF_001 .. Base Board Information Manufacturer: Intel Corporation Product Name: DQ965GF Version: AAD41676-305 Serial Number: BQGF635009R2 ... BIOS Information Vendor: Intel Corp. Version: CO96510J.86A.4462.2006.0804.2059 Release Date: 08/04/2006 so it's all-intel chipset, all-intel board, and all-intel BIOS ;) there have been problems reported with AMT2 on several chipsets (AMT2 is not supported under linux, unlike AMT1), and having it enabled in the BIOS produces this phenomenon. Is there some way to at least disable AMT2 from the Linux driver (ie I assume this is some issue of Intel not documenting it all - but maybe you can add a turn off that bit to the affected chip). If I'm not the only one to see it, it's obviously not just my personal ethernet switch bug, but apparently the e1000 becoming confused by some link detection event (and powering down the switch probably just gets it out of its confusion). Linus - 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] net driver fixes
Linus Torvalds wrote: On Thu, 1 Mar 2007, Kok, Auke wrote: and lspci says: 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02) DMI info isn't very interesting, but it's an all-Intel board: so it's all-intel chipset, all-intel board, and all-intel BIOS ;) It's like the devil plays with it. We just discussed adding a piece of text about this issue to our README. there have been problems reported with AMT2 on several chipsets (AMT2 is not supported under linux, unlike AMT1), and having it enabled in the BIOS produces this phenomenon. Is there some way to at least disable AMT2 from the Linux driver (ie I assume this is some issue of Intel not documenting it all - but maybe you can add a turn off that bit to the affected chip). Our suggestion is (IOW will be in the README) to turn AMT2 off completely in the BIOS, but I'll investigate if your suggestion is possible. It may be another workaround but this one indeed hurts. If I'm not the only one to see it, it's obviously not just my personal ethernet switch bug, but apparently the e1000 becoming confused by some link detection event (and powering down the switch probably just gets it out of its confusion). No, this fits the description perfectly of this issue. I'll get right on it and owe you a patch for the `e1000: not ready for irq` problem too, which seems to hold out after tests... Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. I tried to do bisection, but my log made no sense, since it seemed to say that the problem was introduced between git commits 2442d310 and bff288c1, and there aren't even any commits to drivers/net/ in that range! SO... It seems to be that what actually happened is that my switch got confused (I ended up just power-cycling the switch when I hit the impossible situation, and that seems to be what made it start working again, rather than any kernel changes due to bisection ;) Regardless, the spam the logs every second is a *bad* idea. I'll try to see if I can re-create the problem (probably not), but I thought I'd report this message spamming regardless. If there really is some link problem, no way do I want to see a message about it every second for all eternity. Hmm? Does this once a second link issue ring any bells for anybody? Suggested fixes? I realize people do want to know about link problems, but that was a bit excessive and since it happened with a reboot, I thought it was a kernel bug (it may still be - I'll have to try to recreate it, but my suspicion right now is that the reboot just caused some noise and/or link renegotiation on the ethernet link that was what actually confused my switch). Linus - 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] net driver fixes
On 3/1/07, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. I tried to do bisection, but my log made no sense, since it seemed to say that the problem was introduced between git commits 2442d310 and bff288c1, and there aren't even any commits to drivers/net/ in that range! SO... It seems to be that what actually happened is that my switch got confused (I ended up just power-cycling the switch when I hit the impossible situation, and that seems to be what made it start working again, rather than any kernel changes due to bisection ;) Regardless, the spam the logs every second is a *bad* idea. I'll try to see if I can re-create the problem (probably not), but I thought I'd report this message spamming regardless. If there really is some link problem, no way do I want to see a message about it every second for all eternity. Hmm? Does this once a second link issue ring any bells for anybody? Suggested fixes? I realize people do want to know about link problems, but that was a bit excessive and since it happened with a reboot, I thought it was a kernel bug (it may still be - I'll have to try to recreate it, but my suspicion right now is that the reboot just caused some noise and/or link renegotiation on the ethernet link that was what actually confused my switch). I have seen this occasionally with the e1000 on Xscale IOP development boards. The driver prints the up/down messages and makes no progress. I can also confirm that resetting the switch (SMC8505T) fixed things for me. It might be nice to just print e1000 link can not be established try resetting your switch? after some time. It's not clear what the steps are to reproduce this, and it doesn't happen frequently enough to be a show stopper in my environment. The IOP boards in the lab typically run an NFS root and are often power cycled without running shutdown. So at least an I see it too for what it's worth. Linus -- Dan - 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] net driver fixes
Linus Torvalds wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. Just out of curiosity, which e1000 chipset+motherboard are you running this on? there have been problems reported with AMT2 on several chipsets (AMT2 is not supported under linux, unlike AMT1), and having it enabled in the BIOS produces this phenomenon. I have to dig up which nic was affected, don't know by heart. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
Auke Kok wrote: Jeff Garzik wrote: Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Forgive me for not seeing the 'pulled' message! I still don't see them in your tree on kernel.org either. Is it just slow again? hrm, no, at the time of your message everything has been mirrored out. So, WYSIWYG. I ACK'd your latest update of the patch series, so resend the pull info and I'll pull. Sorry about that. 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: [git patches] net driver fixes
Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Given the past history of breakage during -rc from huge Intel fix patchsets, there's no way I'm going to push those fixes to Linus without plenty of testing in -mm first. 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: [git patches] net driver fixes
Jeff Garzik wrote: Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Forgive me for not seeing the 'pulled' message! I still don't see them in your tree on kernel.org either. Is it just slow again? Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [git patches] net driver fixes
Hi Jeff,
Could you apply the updates for ucc_geth driver?
The patches from Timur that make the driver compile correctly on 2.6.20.
[PATCH] Fix phy_read/write redefinition errors in ucc_geth_phy.c
[PATCH] Update ucc_geth.c for new workqueue structure
The patch from Ahmed that cleans up some unnecessary casts.
[PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups
- Leo
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik
Sent: Monday, January 08, 2007 5:48 PM
To: Andrew Morton; Linus Torvalds
Cc: netdev@vger.kernel.org; LKML
Subject: [git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/e1000/e1000_main.c |6
drivers/net/ixgb/ixgb.h |1 +
drivers/net/ixgb/ixgb_ethtool.c |1 +
drivers/net/ixgb/ixgb_hw.c |3 +-
drivers/net/ixgb/ixgb_main.c| 57
++
drivers/net/qla3xxx.c | 38 +++--
drivers/net/wireless/ipw2100.c |2 +-
drivers/s390/net/qeth_main.c| 13 +---
include/net/ieee80211.h |2 +-
9 files changed, 88 insertions(+), 35 deletions(-)
Aaron Salter (1):
ixgb: Write RA register high word first, increment version
Heiko Carstens (1):
qeth: fix uaccess handling and get rid of unused variable
Jeff Garzik (1):
Revert e1000: disable TSO on the 82544 with slab debugging
Jesse Brandeburg (2):
ixgb: Fix early TSO completion
ixgb: Maybe stop TX if not enough free descriptors
Ron Mercer (2):
qla3xxx: Remove NETIF_F_LLTX from driver features.
qla3xxx: Add delay to NVRAM register access.
Zhu Yi (2):
ieee80211: WLAN_GET_SEQ_SEQ fix (select correct region)
ipw2100: Fix dropping fragmented small packet problem
diff --git a/drivers/net/e1000/e1000_main.c
b/drivers/net/e1000/e1000_main.c
index 4c1ff75..c6259c7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -995,12 +995,6 @@ e1000_probe(struct pci_dev *pdev,
(adapter-hw.mac_type != e1000_82547))
netdev-features |= NETIF_F_TSO;
-#ifdef CONFIG_DEBUG_SLAB
- /* 82544's work arounds do not play nicely with DEBUG SLAB */
- if (adapter-hw.mac_type == e1000_82544)
- netdev-features = ~NETIF_F_TSO;
-#endif
-
#ifdef NETIF_F_TSO6
if (adapter-hw.mac_type e1000_82547_rev_2)
netdev-features |= NETIF_F_TSO6;
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index 50ffe90..f4aba43 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -171,6 +171,7 @@ struct ixgb_adapter {
/* TX */
struct ixgb_desc_ring tx_ring cacheline_aligned_in_smp;
+ unsigned int restart_queue;
unsigned long timeo_start;
uint32_t tx_cmd_type;
uint64_t hw_csum_tx_good;
diff --git a/drivers/net/ixgb/ixgb_ethtool.c
b/drivers/net/ixgb/ixgb_ethtool.c
index cd22523..82c044d 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -79,6 +79,7 @@ static struct ixgb_stats ixgb_gstrings_stats[] = {
{tx_window_errors, IXGB_STAT(net_stats.tx_window_errors)},
{tx_deferred_ok, IXGB_STAT(stats.dc)},
{tx_timeout_count, IXGB_STAT(tx_timeout_count) },
+ {tx_restart_queue, IXGB_STAT(restart_queue) },
{rx_long_length_errors, IXGB_STAT(stats.roc)},
{rx_short_length_errors, IXGB_STAT(stats.ruc)},
#ifdef NETIF_F_TSO
diff --git a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c
index 02089b6..ecbf458 100644
--- a/drivers/net/ixgb/ixgb_hw.c
+++ b/drivers/net/ixgb/ixgb_hw.c
@@ -399,8 +399,9 @@ ixgb_init_rx_addrs(struct ixgb_hw *hw)
/* Zero out the other 15 receive addresses. */
DEBUGOUT(Clearing RAR[1-15]\n);
for(i = 1; i IXGB_RAR_ENTRIES; i++) {
- IXGB_WRITE_REG_ARRAY(hw, RA, (i 1), 0);
+ /* Write high reg first to disable the AV bit first */
IXGB_WRITE_REG_ARRAY(hw, RA, ((i 1) + 1), 0);
+ IXGB_WRITE_REG_ARRAY(hw, RA, (i 1), 0);
}
return;
diff --git a/drivers/net/ixgb/ixgb_main.c
b/drivers/net/ixgb/ixgb_main.c
index e628126..a083a91 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -36,7 +36,7 @@ static char ixgb_driver_string[] = Intel(R)
PRO/10GbE Network
Driver;
#else
#define DRIVERNAPI -NAPI
#endif
-#define DRV_VERSION 1.0.117-k2DRIVERNAPI
+#define DRV_VERSION 1.0.126-k2DRIVERNAPI
char ixgb_driver_version[] = DRV_VERSION;
static char ixgb_copyright[] = Copyright (c) 1999-2006 Intel
Corporation.;
@@ -1287,6 +1287,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter, struct
sk_buff
*skb,
struct ixgb_buffer *buffer_info;
int len = skb-len;
Re: [git patches] net driver fixes
Li Yang-r58472 wrote: Hi Jeff, Could you apply the updates for ucc_geth driver? The patches from Timur that make the driver compile correctly on 2.6.20. [PATCH] Fix phy_read/write redefinition errors in ucc_geth_phy.c [PATCH] Update ucc_geth.c for new workqueue structure The patch from Ahmed that cleans up some unnecessary casts. [PATCH 2.6.20-rc3] UCC Ether driver: kmalloc casting cleanups I don't have any of these in my queue. 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: [git patches] net driver fixes
On Thu, Aug 24, 2006 at 12:54:57AM -0400, Jeff Garzik wrote: Besides via-rhine NAPI (optional) and the UCC gige driver (optional), just the collected fixes for drivers/net/. Please pull from 'upstream-greg' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-greg Pulled from, and pushed out. thanks, greg k-h - 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] net driver fixes
On Wed, Aug 09, 2006 at 02:25:39AM -0400, Jeff Garzik wrote: Please pull from 'upstream-greg' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-greg to receive the following updates: drivers/net/myri10ge/myri10ge.c |2 +- net/core/wireless.c | 24 +++- 2 files changed, 24 insertions(+), 2 deletions(-) Applied, thanks. greg k-h - 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] net driver fixes
Jeff, Noticed Andy's gianfar fixes aren't in here. I'd be good to see if we can get them in for 2.6.17 - kumar On Apr 12, 2006, at 5:14 PM, Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git to receive the following updates: drivers/net/b44.c | 64 ++- drivers/net/bnx2.c|2 drivers/net/hydra.h | 177 -- drivers/net/ixgb/ixgb_main.c | 13 ++- drivers/net/mv643xx_eth.c | 19 +++- drivers/net/natsemi.c |2 drivers/net/pcmcia/axnet_cs.c |2 drivers/net/skge.c|2 drivers/net/sky2.c|6 - drivers/net/sky2.h|2 drivers/net/starfire.c|2 drivers/net/typhoon.c |2 drivers/net/via-rhine.c |7 - 13 files changed, 67 insertions(+), 233 deletions(-) Adrian Bunk: drivers/net/via-rhine.c: make a function static remove drivers/net/hydra.h Andreas Schwab: Use pci_set_consistent_dma_mask in ixgb driver Brent Cook: mv643xx_eth: Always free completed tx descs on tx interrupt Dale Farnsworth: mv643xx_eth: Fix tx_timeout to only conditionally wake tx queue Gary Zambrano: b44: disable default tx pause b44: increase version to 1.00 Jeff Garzik: [netdrvr b44] trim trailing whitespace Komuro: network: axnet_cs.c: add missing 'PRIV' in ei_rx_overrun Randy Dunlap: net drivers: fix section attributes for gcc Roger Luethi: via-rhine: execute bounce buffers code on Rhine-I only Stephen Hemminger: dlink pci cards using wrong driver sky2: bad memory reference on dual port cards - 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] net driver fixes
Kumar Gala wrote: Jeff, Noticed Andy's gianfar fixes aren't in here. I'd be good to see if we can get them in for 2.6.17 Never saw them... - 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] net driver fixes
On Apr 12, 2006, at 5:45 PM, Jeff Garzik wrote: Kumar Gala wrote: Jeff, Noticed Andy's gianfar fixes aren't in here. I'd be good to see if we can get them in for 2.6.17 Never saw them... Odd, posted to netdev, Andy may not have copied you on them. http://marc.theaimsgroup.com/?l=linux-netdevm=114437381506340w=2 - 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] net driver fixes
Kumar Gala wrote: On Apr 12, 2006, at 5:45 PM, Jeff Garzik wrote: Kumar Gala wrote: Jeff, Noticed Andy's gianfar fixes aren't in here. I'd be good to see if we can get them in for 2.6.17 Never saw them... Odd, posted to netdev, Andy may not have copied you on them. http://marc.theaimsgroup.com/?l=linux-netdevm=114437381506340w=2 That's fine, but I don't have it. Please resend, git-applymbox doesn't work on URLs. 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: [git patches] net driver fixes
On Thu, 16 Mar 2006, Jeff Garzik wrote: Please pull from 'upstream-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git The commit comments for the Chelsio driver fix are a bit unfortunate. The array clearly _does_ have three elements, it's just that the code used to access the fourth (that didn't exist), and now it accesses the third. So when the commit says The array should contain 2 elements it's just being really confused. Of course, using an array index of cmdQ_restarted[2] without any explanation for why it's index 2, the bug was inevitable. Maybe a symbolic value for the magic array indices? Linus - 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] net driver fixes
Wolfgang Hoffmann wrote: On Friday 24 February 2006 06:22, Jeff Garzik wrote: Please pull from 'upstream-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git [...] Stephen Hemminger: sky2: yukon-ec-u chipset initialization sky2: limit coalescing values to ring size sky2: poke coalescing timer to fix hang sky2: force early transmit status sky2: use device iomem to access PCI config sky2: close race on IRQ mask update. [...] Thanks for the update. Still I'm seeing reproducable hangs with this version of sky2 (as reported in bugzilla 6084 and discussed on netdev). Stephen, if there is anything I can do to narrow down my hangs a bit more systematically, please let me know, I'd be happy to help. Wolfgang There is an outstanding bug where the sky2 will hang if it receives a packet larger than the MTU. At this point, there isn't enough information on chip behavior to fix. You could try using a larger mut or patching the driver so that the rx_buffer_size is always big (like 4k). - 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] net driver fixes
On Friday 24 February 2006 17:14, Stephen Hemminger wrote: There is an outstanding bug where the sky2 will hang if it receives a packet larger than the MTU. At this point, there isn't enough information on chip behavior to fix. You could try using a larger mut or patching the driver so that the rx_buffer_size is always big (like 4k). I've raised the MTU from 1500 to 3000 and still reproduced the hang. Would you mind sending me a patch for forcing rx_buffer_size to 4k, so I can try that, or is no sense in that, given that raising the MTU didn't help? Concerning information on chip behavior, are you missing vendor specs, or could I be helpful by reproducing the hang with an instrumented driver that gives more information about the chip status at hang time? Another thing that may be worth to find out is why 0.13 with Carl-Daniel Hailfingers fix works. I didn't see a single hang with that version. I'm currently resorting to that version, but well ... I'd really like to help get this driver working robustly. I'm not enough into networking to help by coding, but yes I'll give feedback on any driver version you send me. I'd just like to provide you more helpful data than repeating new version still hangs ;-) Wolfgang - 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] net driver fixes
On Friday 24 February 2006 06:22, Jeff Garzik wrote: Please pull from 'upstream-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git [...] Stephen Hemminger: sky2: yukon-ec-u chipset initialization sky2: limit coalescing values to ring size sky2: poke coalescing timer to fix hang sky2: force early transmit status sky2: use device iomem to access PCI config sky2: close race on IRQ mask update. [...] Thanks for the update. Still I'm seeing reproducable hangs with this version of sky2 (as reported in bugzilla 6084 and discussed on netdev). Stephen, if there is anything I can do to narrow down my hangs a bit more systematically, please let me know, I'd be happy to help. Wolfgang - 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] net driver fixes
On Sun, 31 Jul 2005, Jeff Garzik wrote: Please pull from the 'upstream-fixes' branch of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git to obtain the fixes described in the attached diffstat/changelog/patch. Could you please try to edit the emails you apply to something prettier than this: [PATCH] Fix OMAP specific typo in smc91x.h --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff, Here's a little patch fixing a typo in smc91x.h. Regards, Tony --ReaqsoxgOBHFXBhH Content-Type: text/x-chdr; charset=us-ascii Content-Disposition: inline; filename=patch-fix-typo-smc91x.h Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Ugh. It's not like we want people saying Hi there in our changelogs. Linus - 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
