Patch 1: David Miller's red-black tree code, tweaked for 2.6.22.6, with some bugfixes -Tom --- diff -ur linux-2.6.22.6/include/linux/skbuff.h linux-2.6.22.6-rbtree-davem-fixed/include/linux/skbuff.h --- linux-2.6.22.6/include/linux/skbuff.h 2007-08-30 23:21:01.000000000 -0700 +++ linux-2.6.22.6-rbtree-davem-fixed/include/linux/skbuff.h 2007-09-13 18:23:16.000000000 -0700 @@ -18,6 +18,7 @@ #include <linux/compiler.h> #include <linux/time.h> #include <linux/cache.h> +#inclu...

On 100mbit versions, the driver always reports gigabit speed available. The correct modes are already computed, then overwritten. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> --- a/drivers/net/sky2.c 2007-09-19 09:18:50.000000000 -0700 +++ b/drivers/net/sky2.c 2007-09-19 09:19:35.000000000 -0700 @@ -2841,13 +2841,6 @@ static int sky2_get_settings(struct net_ ecmd->supported = sky2_supported_modes(hw); ecmd->phy_address = PHY_ADDR_MARV; if (sky2_is_copper...

Will something like SKY2_HW_NEWER_PHY age well? Won't that leave things Might the same thing apply with SKY2_HW_NEW_LE? rick jones -

The length check for truncated frames was not correctly handling the case where VLAN acceleration had already read the tag. Also, the Yukon EX has some features that use high bit of status as security tag. Signed-off-by: Pierre-Yves Ritschard <pyr@spootnik.org> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> --- a/drivers/net/sky2.c 2007-09-17 16:51:53.000000000 -0700 +++ b/drivers/net/sky2.c 2007-09-17 17:03:25.000000000 -0700 @@ -2103,6 +2103,13 @@ static struct ...

Patches against 2.6.23 to fix bugs and support newest FE+ chip. These patches conflict with those in netdev-2.6 upstream branch, Jeff how do you want to resolve that? -- Stephen Hemminger <shemminger@linux-foundation.org> -

A driver writer from another operating system hinted that the versions of Yukon 2 chip with rambuffer (EC and XL) have a hardware bug that if the FIFO ever gets completely full it will hang. Sounds like a classic ring full vs ring empty wrap around bug. As a workaround, use the existing watchdog timer to check for ring full lockup. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> --- a/drivers/net/sky2.c 2007-09-19 10:05:15.000000000 -0700 +++ b/drivers/net/sky2.c 2007...

From: Nagendra Tomar <tomer_iisc@yahoo.com> I already replied to your patch posting explaining that whatever is not setting SOCK_NOSPACE should be fixed instead. Please address that, thanks. -

Definitely not ! The point is that the "tcp write space available" wakeup does not get called if SOCK_NOSPACE bit is not set. This was fine when the wakeup was merely a wakeup (since SOCK_NOSPACE bit indicated that someone really cared abt the wakeup). Now after the introduction of callback'ed wakeups, we might have some work to do inside the callback even if there is nobody interested in the wakeup at that point of time. In this particular case the ep_poll_callback is not getting called...

From: Nagendra Tomar <tomer_iisc@yahoo.com> I guess this means you also noticed that you are removing the one and only test of this bit too? You can't remove this, it's critical for performance. -

allyesconfig CC drivers/net/wireless/p54pci.o LD drivers/net/wireless/built-in.o drivers/net/wireless/b43legacy/built-in.o: In function `tsf_read_file': drivers/net/wireless/b43legacy/debugfs.c:80: multiple definition of `tsf_read_file' drivers/net/wireless/b43/built-in.o:net-2.6.24/drivers/net/wireless/b43/debugfs.c:80: first defined here drivers/net/wireless/b43legacy/built-in.o: In function `ucode_regs_read_file': net-2.6.24/drivers/net/wireless/b43legacy/debugfs.c:106: multiple de...

David, The patch below was sent to John Linville yesterday. Obviously, it didn't get included before he pushed to you. With this patch, all the debugfs names become static, and avoid the namespace clash with b43. In addition, Michael Buesch has a similar patch pending for b43. Larry ======================================== There are additional sparse warnings in b43legacy. None of them result in program errors, but are fixed for completeness. Signed-off-by: Larry Finger <Larry.Finger@lw...

Jeff, Greg, Gary, and Dave, These patches build upon the SSB bus support added to net-2.6.24 to support the b43 wireless driver. Since Dave has that support in his tree, I'm asking him to merge these patches as well. The first patch changes b44 from being a PCI (i.e. SSB-in-drag) device to being a native SSB device. This has little effect one way or the other for laptop/desktop/server machines. But, some embedded devices have b44 hardware but no PCI bus (i.e. just SSB). This patch enables the...

From: "John W. Linville" <linville@tuxdriver.com> I've merged the B44 driver conversion into my tree. I'll let Greg take in the OHCI thing. I would suggest that he queue it up, and then once I get the net-2.6.24 tree into the merge window (which contains the SSB stack) he can push the OHCI change in afterwards. -

Jeff & Dave, This patch adds the p54 driver for prism54 hardware using the "soft MAC" firmware. It includes modules for both PCI and USB drivers. This driver has been in Fedora (both F7 and rawhide) for some time and has generally performed well. No doubt there are some problems with the code, but still I think it would be better to mainline the driver than to keep it out of stream. Thanks, John --- The patch is available here: [ message continues ]

From: Christoph Hellwig <hch@infradead.org> The next time I rebase I'll try to take care of this for both this driver and the iwlwifi stuff. -

There were complaints about the nonsensical wireless/mac80211 directory. But if there are enough files, a driver should definitely get its own directory. Like life, it's a balance. If it's just one or two C files, a directory might be overkill. If it's more, it definitely warrants a sub-dir. Jeff -

From: "John W. Linville" <linville@tuxdriver.com> Merged to net-2.6.24, thanks John. -

Jeff & Dave, This patch adds z1211 (previously known as zd1211rw-mac80211), a driver for Zydas ZD1211 hardware. This driver has proven very robust -- Fedora 7 uses this driver and I don't think I have any open bugzillas for it. Either the driver works well, or no one as using it...given the common availability of the hardware, I have to presume the former. :-) This driver is mostly a port of zd1211rw to the mac80211 infrastructure. In fact, most zd1211rw patches have been mirrored direct...

I apologise for being inactive over the last few weeks, I've been moving back from the US to the UK and then moving back to university. However I am now just-about-settled and will be active again soon. I would like to this until 2.6.25 until I have had time to clear up some final issues and do more testing myself of zd1211rw-mac80211. I also think we need to discuss the rename... (just to clarify to others: this is the first I heard of this merge before John posted it). John, thanks a ...

I don't understand your point. We already have this driver in mainline Linux. zd1211rw-mac80211 does not currently add anything to the user experience over the existing driver, other than automatic rate adaption which is nice but hasn't proven itself to be of much importance given that the existing driver has lots of happy users and has never done it. Also, this merge has been proposed in a form other than what me and Ulrich were envisioning (at least from earlier discussions). We want to ...

From: "John W. Linville" <linville@tuxdriver.com> Agreed, merged into net-2.6.24, thanks John. -

From: Michael Buesch <mb@bu3sch.de> I agreed with John to merge this in myself, but this patch applied to the old driver aparently, not the new z1211 one. Can you resend this patch against the new driver so I can add it to net-2.6.24? Thanks! -

Ok, as has been hinted at with some postings from Krishna and others, we still have some mutual exclusion issues in the new NAPI code. In short, the napi->quota updates happen outside of the sections where the code stream "owns" the napi_struct instance, so it can be modified in parallel on multiple cpus, the n->quota can go negative, and the quota bug checks trigger. It just seems that gradually I'm reverting every single cleanup done by Stephen in his original patch, first the list hand...

On Wed, 19 Sep 2007 10:35:08 -0700 (PDT) There might be a future problem if some driver decided to change weight often on the fly? Perhaps you need to sample it once in start of napi_schedule. -

> If an application is calling rdma_resolve_ip() and a status of -ENODATA is returned from addr_resolve_local/remote(), the timeout mechanism waits until the application's timeout occurs before rechecking the address resolution status; the application will wait until it's full timeout occurs. This case is seen when the work thread call to process_req() is made before the arp packet is processed. I don't understand the issue. process_req() is invoked whenever a This patch looks unrelated to Steve...