DQpxbGdlOiBGaXggd2FybmluZ3MgaW4gZGVidWdnaW5nIGNvZGUuDQoNCmRyaXZlcnMvbmV0L3Fs Z2UvcWxnZV9kYmcuYzogSW4gZnVuY3Rpb24g4oCYcWxfZHVtcF9xZGV24oCZOg0KZHJpdmVycy9u ZXQvcWxnZS9xbGdlX2RiZy5jOjM2OTogd2FybmluZzogY2FzdCB0byBwb2ludGVyIGZyb20gaW50 ZWdlciBvZiBkaWZmZXJlbnQgc2l6ZQ0KZHJpdmVycy9uZXQvcWxnZS9xbGdlX2RiZy5jOjM3Mzog d2FybmluZzogY2FzdCB0byBwb2ludGVyIGZyb20gaW50ZWdlciBvZiBkaWZmZXJlbnQgc2l6ZQ0K ZHJpdmVycy9uZXQvcWxnZS9xbGdlX2RiZy5jOiBJbiBmdW5jdGlvbiDigJhxbF9kdW1wX3R4X3Jp bmfigJk6DQpkcml2ZXJzL25ldC9xbGdlL3FsZ2VfZGJn...

I just checked the following two build warning fixes to net-next-2.6 Signed-off-by: David S. Miller <davem@davemloft.net> --

The nr_conns variable in the sync message header is only eight bits wide and will overflow on interfaces with a large MTU. As a result the backup won't parse all connections contained in the sync buffer. On regular ethernet with an MTU of 1500 this isn't a problem, because we can't overflow the value, but consider jumbo frames being used on a cross-over connection between both directors. We now restrict the size of the sync buffer, so that we never put more than 255 connections into a single sync b...

On Fri, 19 Sep 2008 12:18:41 -0600 that's not a good answer. There are reasons for moving interrupts that are a sysadmin choice (like power management policy that if the system is seriously idle, that all interrupts go to one of the sockets so that the others can stay in low power mode). Putting the policy in the kernel to prohibit such admin choices sounds like a bad idea to me. There are better ways to do what you want, for example by exposing a "preferred cpu" somewhere so that irqbalance will...

On Fri, 19 Sep 2008 17:24:00 -0500 that's only true if you have at least the amount of queues as you have logical cpus. Ask SGI about how many cpus they have in 3 years, and then ask your NIC vendor how many queues they have planned for ;-) and a per-cpu lock isn't really all THAT expensive. the really big advantage is that you no longer cacheline bounce to hell and back... and that you have either way. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion an...

From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com> No way. Let irqbalanced implement the policy. Just configure as many queues as possible and let it figure out what to do. --

From: Matthew Wilcox <matthew@wil.cx> More code for irqbalanced to write, to look for the files and directories under there, etc. Harder to make work with simple individual driver backports, which you know dists are going to want to do. That's why. No, this new subdirectory thing isn't a good idea. --

From: Le Rouzic <aime.le-rouzic@bull.net> Generally, if you just point people at some web site instead of posting your code as well partitioned patches against the current kernel to this mailing list, people aren't even going to look at your stuff. Myself included. If it doesn't get posted to the mailing list, it might as well not exist. You're making people go through extra effort to see your work. --

There was a trivial bug in the R2 code. From 97ad23f4696a322cb3bc379a25a8c0f6526751d6 Mon Sep 17 00:00:00 2001 From: Ralf Baechle <ralf@linux-mips.org> Date: Fri, 19 Sep 2008 14:05:53 +0200 Subject: [PATCH] [MIPS] Fix 64-bit csum_partial, __csum_partial_copy_user and csum_partial_copy On 64-bit machines it wouldn't handle a possible carry when adding the 32-bit folded checksum and checksum argument. While at it, add a few trivial optimizations, also for R2 processors. Signed-off-by: ...

It's probably easier for people to test a single patch now and it can then be split at the commitment time. Of course if something actually breaks, then keeping changes combined won't help tracking down the cause. ;) Maciej --

Hi Jeff, our internal regression found 2 more qeth bugs. shortlog: Ursula Braun (2) qeth: use firmware MAC-address for layer2 hsi-devices qeth: avoid qeth recovery problems Thanks, Frank -- --

From: Ursula Braun <ursula.braun@de.ibm.com> Do not touch IFF_UP flag during qeth recovery, but invoke dev_close() in case of failing recovery. Cancel outstanding control commands in case of Data Checks or Channel Checks. Do not invoke qeth_l2_del_all_mc() in case of a hard stop to speed up removal of qeth devices. Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/qeth_core_main.c | 4 +++...

(cc's added) (googles "nfs: RPC call returned error 1") hm, there has been a dribble of reports going back several years, but nothing conclusive afaict. --

On Thu, 2008-09-18 at 19:38 -0700, David Miller wrote: What about the case where an interrupt is shared between RX and TX completions? Our hardware is very flexible in this regard, but based on performance testing prior to the introduction of TX multiqueue we currently allocate multiple interrupts for RX completions and share the first with TX completions. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department...

myri10ge uses the same interrupts for TX and RX. The current name is eth%d:slice-%d but we could change it if there's a consensus. Brice --

1) bnx2 records MSI vector as 16-bit value, which breaks due to 2.6.27 io_apic.c changes on x86, use 32-bit value instead. From Benjamin Li. 2) Due to missing locking, EEPROM/NVRAM can be corrupted making the card subsequently nearly unusable. Fix from Christopher Li. 3) UDP receive path can try to recursively lock a socket and deadlock, regression from 2.6.26 Reported by lockdep and fixed by Herbert Xu. 4) Three SCTP fixes from Vlad Yasevich: a) OOPS when processing INI...

From: Jeff Garzik <jeff@garzik.org> Pulled, thanks a lot Jeff. --

Currently dequeueing a packet and requeueing the same packet will cause a different packet to be pulled on the next dequeue. This change forces requeue to rewind the current_band. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> --- net/sched/sch_multiq.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/net/sched/sch_multiq.c b/net/sched/sch_multiq.c index 5d9cd68..915f314 100644 --- a/net/sched/sch_multiq.c +++ b/net/sched/sch_multiq.c @@ -97,...

From: "Randy.Dunlap" <rdunlap@xenotime.net> It's so much less work for me to click a bunch of buttons on a web page and work in batch mode, than it is to give personalized responses. When you're applying 40, 50 patches in a day, every minute in the workflow starts to count. I was hoping those ACK emails would be one of the things I could stop doing if patchwork is effective. Not immediately, but eventually. --

From: Rick Jones <rick.jones2@hp.com> I honestly don't know, but my guess would be know. We could ask the patchwork author for this feature, as this stuff is actively maintained. --

Could patchworks please generate the ACK mail automatically? --

then you get to choose, I suppose. Meaning look at the patchwork queue, which I did, and it looks good. -- ~Randy --

From: Jeff Garzik <jeff@garzik.org> Pulled, thanks Jeff. I'll push this to net-next-2.6 after a quick build sanity test. --

Yes it is, my mistake. The patch below will be better. --- drivers/net/r8169.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 73 insertions(+), 1 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index befc927..cff8dd6 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -1910,6 +1910,75 @@ static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp) } } +static int rtl_eeprom_read(struct pci_dev *pdev, int cap,...

On Fri, Sep 19, 2008 at 05:16:32PM +0200, Jarek Poplawski wrote: Hmm... probably false alarm. It seems there have to be same wake_queue after all. Sorry, Jarek P. --