Dear Webmail account User, This message is from Webmail account update Service team messaging center to all subscribers/webmail users. We are currently upgrading our data base and e- mail center due to an unusual activities identified in our email system. We are deleting all unused Webmail Accounts. to create space for new ones. You are required to verify your webmail account by Confirming your Webmail identity. This will prevent your Webmail account from been closed during ...

This patch updates the logic used to communicate with the mgmt unit. It also adds a version check for a newer mgmt unit firmware. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>

This patch bumps the version up to 63 Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>

As for other printks, someone with 8139cp should experience the same bug. --

I don't think it will. -funroll-loops is pretty clear defined. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

gcc 4.4 will have a way to do that per function, but earlier you would need to move it to a separate file and specify the option only for that. Doing so would be still a good idea compared to your patch because the code will be cleaner and might be more adaptable to future architectures It cannot do much without profile feedback because Yes I know, sorry for that. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

I'm writing a new dma driver. My DMAC has multiple channels and only one channel is capable for generic memcpy and other channels have fixed role. Does new framework allow dma driver make only one channel public? Or should I register two dma_device for DMA_MEMCPY and DMA_SLAVE? Could you give me some advice? --- Atsushi Nemoto --

The virt-manager console is basically just a plain old boring VNC client. It uses GTK-VNC to establish its VNC network connection, and that doesn't do anything unusual AFAIK. We use getaddrinfo() to resolve the hostname, and then try each of its results in turn, until we succesfully connect to the VNC server. We don't explicitly bind() to the client port, just let the kernel pick it for us. The code in question, is the "gvnc_open_host" method from gvnc.c, which starts at about line ...

From: Steve Hodgson <shodgson@solarflare.com> Enable a firmware option that appears to be necessary for reliable operation. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/tenxpress.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/net/sfc/tenxpress.c b/drivers/net/sfc/tenxpress.c index 9ecb77d..19cfc31 100644 --- a/drivers/net/sfc/tenxpress.c +++ b/drivers/net/sfc/tenxpress.c @@ -67,6 +67,8 @@ #define ...

Sorry about that; I should have separated them out more clearly. 1. Patches 3, 6-13 and 20 fix bugs introduced or exposed by the changes already accepted for .29. I regret that I couldn't send these earlier but I simply didn't have near-production hardware or firmware to test against until the last couple of weeks. 2. Patches 16 and 19 add new hardware support without affecting the behaviour on old hardware. 3. Patches 14, 15, 17 and 18 are fairly trivial fixes supporting ...

From: Steve Hodgson <shodgson@solarflare.com> Early versions of the SFX7101 firmware could complete link training in a state where it would not adequately cancel noise (Solarflare bug 10750). We previously worked around this by resetting the PHY after seeing many Ethernet CRC errors. This workaround is unsafe since it takes no account of the interval between errors; it also appears to be unnecessary with production firmware. Therefore remove it. Signed-off-by: Ben Hutchings ...

This workaround is not specific to rev A. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/workarounds.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/sfc/workarounds.h b/drivers/net/sfc/workarounds.h index 420fe15..b810dcd 100644 --- a/drivers/net/sfc/workarounds.h +++ b/drivers/net/sfc/workarounds.h @@ -54,7 +54,7 @@ #define EFX_WORKAROUND_8071 EFX_WORKAROUND_FALCON_A /* Need to send XNP pages for 100BaseT ...

From: Steve Hodgson <shodgson@solarflare.com> Depending on the loopback mode, there may be no pertinent link state bits. In this case we test the PHYXS RX fault bit instead. Make sure to do this in all cases where there are no link state bits. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/mdio_10g.c | 16 +++++++++------- 1 files changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/net/sfc/mdio_10g.c b/drivers/net/sfc/mdio_10g.c index ...

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/sfe4001.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/sfc/sfe4001.c b/drivers/net/sfc/sfe4001.c index c7c95db..853057e 100644 --- a/drivers/net/sfc/sfe4001.c +++ b/drivers/net/sfc/sfe4001.c @@ -375,17 +375,25 @@ static void sfn4111t_fini(struct efx_nic *efx) i2c_unregister_device(efx->board_info.hwmon_client); } -static struct i2c_board_info ...

Reviewing commit a9d8f9110d7e953c2f2b521087a4179677843c2a I see use of a hashinfo->bsockets field that : - lacks proper lock/synchronization - suffers from cache line ping pongs on SMP Also there might be a problem at line 175 if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { spin_unlock(&head->lock); goto again; If we entered inet_csk_get_port() with a non null snum, we can "goto again" while it was not expected. diff --git a/net/ipv4/inet_connection_sock.c ...

[Empty message]

2.6.29-rc contains UDP receive improvements (lockless) Problem is multicast handling was not yet updated, but could be :) I was asking you "cat /proc/interrupts" because I believe you might have a problem NIC interrupts being handled by one CPU only (when having problems) --

Denying there is a bug is... well... I dont know what to say. Are you kidding ? bsockets is not part of socket structure, but part of "struct inet_hashinfo", shared by all cpus and accessed several thousand times per second on many machines. Please read the comment three lines after 'the free alignemnt slot' you chose.... You just introduced one write on a cache line that is supposed to *not* be written. unsigned int bhash_size; int ...

Hum, I just checked and indeed there is a problem... #define SUM_COUNTER(s,c) do { (s).bcnt += (c).bcnt; (s).pcnt += (c).pcnt; } while(0) need to be changed to use #define SUM_COUNTER(s, c) do { xt_incr_counter(s, (c).cnt, (c).pcnt);} while (0) --

Register multiple dma_devices, the public one with a DMA_MEMCPY, and the fixed role devices with DMA_PRIVATE, DMA_MEMCPY, and DMA_SLAVE capabilities. DMA_PRIVATE ensures that a channel is never considered for public consumption. -- Dan --

From: Stephen Hemminger <shemminger@vyatta.com> Applied, thanks a lot Stephen. --

From: Ben Hutchings <bhutchings@solarflare.com> Please resend the pure bug fixes. Thank you. --

From: Roel Kluin <roel.kluin@gmail.com> Good catch Roel, patch applied. --

From: Michael Tokarev <mjt@tls.msk.ru> I'll take a look at this, thanks for the report. --

From: Steve Glendinning <steve.glendinning@smsc.com> Applied, thanks Steve. --

From: Alexey Dobriyan <adobriyan@gmail.com> Then you give me no choice, I have to apply this patch :-) Thanks! --

From: Benjamin ZORES <benjamin.zores@alcatel-lucent.fr> Patch applied, thank you. --

Patch applied, thanks! --

From: Herbert Xu <herbert@gondor.apana.org.au> Looks good, applied. I rewrote the commit message as follows so that it actually matches what happens in the fix ;-) -------------------- packet: Avoid lock_sock in mmap handler As the mmap handler gets called under mmap_sem, and we may grab mmap_sem elsewhere under the socket lock to access user data, we should avoid grabbing the socket lock in the mmap handler. Since the only thing we care about in the mmap handler is for pg_vec* to be ...

From: Willy Tarreau <w@1wt.eu> Such a check could have performance ramifications, I wouldn't risk it and already I intend to push Jarek's page allocator Any NIC, even the dumbest ones, can be made to receive into pages. --

From: Roland Dreier <rdreier@cisco.com> local_bh_{enable,disable}() nests, so this is not a problem --

From: Willy Tarreau <w@1wt.eu> For a dumb NIC you wouldn't split, you'd receive directly, the entire packet, into part of a page. Then right befire you give it to the stack, you pull the ethernet header from the page into the linear area. --

More bug fixes, highlights: 1) IP-Config can loop forever retrying due to a bug in how the retry counter is initialized. Fix from Benjamin Zores. 2) iSCSI OOPS fixes from Herbert Xu and Shyam Iyer. 3) Several IPV6 multicast routing bug fixes from Thomas Goff. 4) Wireless bug fixes via John Linville. 5) E1000 shared interrupt handling fix from Jesse Brandeburg. 6) UDP port bind performance regression fix from Eric Dumazet. This came from the port randomization ...

From: Rusty Russell <rusty@rustcorp.com.au> Right, no hurry. --

From: Alex Williamson <alex.williamson@hp.com> Rusty, are these good? If so, would you like you or I to take them? Thanks. --

From: David Miller <davem@davemloft.net> This should fix it: tun: Add some missing TUN compat ioctl translations. Based upon a report from Michael Tokarev <mjt@tls.msk.ru>: Just saw in dmesg: ioctl32(kvm:4408): Unknown cmd fd(9) cmd(800454cf){t:'T';sz:4} arg(ffc668e4) on /dev/net/tun Signed-off-by: David S. Miller <davem@davemloft.net> --- fs/compat_ioctl.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/fs/compat_ioctl.c ...

Hi Herbert, I'll give these patches a try within a day or two. Please note that the 6Gb/s rate is achieved on a low perf server. Using this server makes it easy to witness the impact of optimizations. Faster boxes reach line rate. Just want to make clear that cxgb3 HW is not limited to 6Gb/s ;) Cheers, Divy --

Hi All, I am using a very simple setup: a linux server (linux 2.6.28.2, amd64) with 12 nics, almost each connected host has a nic uniquely to itself. On the server a program is running (poc-2250 to be precise) that streams data to multicast address ff05::4242. This data should be forwarded by the kernel to all interfaces that have hosts that are joined to ff05::4242. As it is such a simple setup, I do not want to use PIM nor a router application featuring PIM, I am using MLD messages ...

Either fix racoon to use xfrm or go with a properly maintained key manager like one of the *swans. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Yes, I think a good strace vs. a bad strace would be really helpful in these cases. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

I don't know about the rest but bnx2x is certainly OK since it only does so with IRQ enabled. It is legal to call skb_linearize as long as you're sure that IRQs are enabled, which is always the case for hard_start_xmit upon entry. So the only time you can't call it in hard_start_xmit is if you've just disabled IRQs yourself. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: ...

Well, doing the copy under sk_lock is pretty common through all protocols. So I think it'd be safer to change the other path, which is doing the odd thing here, i.e., ->mmap() grabbing the socket lock while holding mmap_sem. In fact, it would appear that we don't really need the socket lock in ->mmap() since it only needs to ensure that pg_vec* doesn't get yanked or changed. So this patch should work: packet: Avoid lock_sock in mmap handler As the mmap handler gets called under ...

gro: Open-code memcpy in napi_fraginfo_skb This patch optimises napi_fraginfo_skb to only copy the bits necessary. We also open-code the memcpy so that the alignment information is always available to gcc. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> --- net/core/dev.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 3742397..d55f725 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2541,6 +2541,8 @@ ...

Heh, that sentence should be removed from the description. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Dave pointed out that a spin lock is illegal for this purpose as vm_insert_page can do a GFP_KERNEL allocation. So I've added a mutex for this. I've also widened the critical section in packet_set_ring since we need the mapped check to be within it. packet: Avoid lock_sock in mmap handler As the mmap handler gets called under mmap_sem, and we may grab mmap_sem elsewhere under the socket lock to access user data, we should avoid grabbing the socket lock in the mmap handler. Since the ...

It should be the same as the kernel that you did the last test on, i.e., the one that was giving 5.7Gb/s but please reconfirm Of course, any inferences that it was limited wasn't intentional :) Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

>>>>> "Ira" == Ira Snyder <iws@ovro.caltech.edu> writes: Ira> Hello, Ira> I'm working on a Freescale MPC8349EMDS board. I have been Ira> booting it over NFS for a long time now. I try to run the latest Ira> git kernels to find possible problems. Ira> Recently, I haven't been able to boot over NFS anymore. When the machine Ira> tries to bring up the ethernet interface, it just hangs forever. There Ira> are no softlockup warnings, the machine has locked up completely. FYI, I'm ...

(Changed In-Reply-To) OK, thanks, Jarek P. -------------> PATCH 3/3 pkt_sched: sch_htb: Use workqueue to schedule after too many events. Patrick McHardy <kaber@trash.net> suggested using a workqueue instead of hrtimers to trigger netif_schedule() when there is a problem with setting exact time of this event: 'The differnce - yeah, it shouldn't make much, mainly wake up the qdisc earlier (but not too early) after "too many events" occured _and_ no further enqueue events wake up the qdisc ...

On Fri, Jan 30, 2009 at 11:49:47PM +1100, Herbert Xu wrote: So, Dave is stronger than the temptation... Jarek P. --

Hi all, We've been having some issues with multicast packet loss, we were wondering if anyone knows anything about the behavior we're seeing. Background: we use multicast messaging with lots of messages per sec for our work. We recently transitioned many of our systems from an Ubuntu Dapper Drake ia32 distribution to Ubuntu Hardy Heron x86_64. Since the transition, we've noticed much more multicast packet loss, and we think it's related to the transition. Our particular theory is that it's ...

Then here, add: #else static inline void __init overo_init_smsc911x(void) { return; } This allows you to drop the #ifdefs below and have it look a little cleaner. Other than that, looks OK to me. --

Contact Mr Francis Scott for the sum of £800,000 pounds GBP. Email: directiveboard24@ymail.com Tel:+44:7045731829 Names:............ Address:.............. Country:................ Phone No:................... Occupation:.................. Age:.......... Fax:.............. Regards Mrs.Caroline Jude --

Like Eric mentioned, I'd start with a latest kernel if at all possible. If it doesn't happen there, you're work is half over, you just need to figure out what changed, and tell Canonical to backport it. From there, you can solve this like most packet loss issues are solved: 1) Determine if its a rx or tx packet loss. From your comments above it sounds like this is an rx side issue 2) Look at statistics from the hardware to the application. Use ethtool & /proc/net/dev to get hardware ...

This time it fails with different error on loading after suspend/resume cycle - 1196.873608] tg3 0000:0e:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1196.873620] tg3 0000:0e:00.0: setting latency timer to 64 [ 1196.880017] tg3 0000:0e:00.0: PME# disabled [ 1196.996270] tg3: (0000:0e:00.0) phy probe failed, err -19 [ 1197.508033] tg3: Problem fetching invariants of chip, aborting. [ 1197.508048] tg3 0000:0e:00.0: PCI INT A disabled Parag --

Totally worth having this problem from a "getting an opportunity to understand" standpoint. This confirms my long standing suspicion that bugs in Linux kernel are merely a handiwork of few clever people to get more people to understand and contribute :) Any how here is the pre-suspend lspci -vvxxx output followed by diff -u - 00:00.0 Host bridge: Intel Corporation 5400 Chipset Memory Controller Hub (rev 20) Subsystem: Hewlett-Packard Company Device 1307 Control: I/O- Mem- ...

[Empty message]

And i use kernel 2.6.28.2 my lspci shows my intel card as: ... 01:00.0 Ethernet controller: Intel Corporation Device 10dd (rev 01) ... My installed card in this machine is: Intel® 82598EB 10 Gigabit Ethernet Controller with CX4 interface --

That is what netperf service demand is for :) so you can see the effect of changes even when you are link-bound. rick jones --

Thanks for testing. Well, I'm not sure if tg3 is at fault, really. What happens if you unload tg3 before suspend and load it back after the resume? Rafael --

It seems like something between the tg3 chip and the host CPU doesn't work correctly after resume, Linus is right. I wonder if this change makes any difference: --- linux-2.6.orig/drivers/pci/pci-driver.c +++ linux-2.6/drivers/pci/pci-driver.c @@ -501,6 +501,9 @@ static int pci_pm_suspend(struct device if (pci_has_legacy_pm_support(pci_dev)) return pci_legacy_suspend(dev, PMSG_SUSPEND); + if (!drv || !drv->pm) + return 0; + if (drv && drv->pm && drv->pm->suspend) { error ...

Hmm, I prefer initialize buffer, then set sg to refer to it. Seems to make Or "return status == VIRTIO_NET_OK;" ? See what I mean about nit-picking? Rusty. --

Still nitpicking. We'll wrestle a bit more, then I'll ack them to you. These are 2.6.30 material, so no huge hurry AFAICT? Thanks, Rusty. --

Hmm, this check duplicates the one in virtnet_send_command; after Comment above/beside these two perhaps? /* Supported if VIRTIO_NET_F_CTRL_RX */ Cheers, Rusty. --

Gumstix will soon be shipping a variant of their Summit board that includes an SMSC9221 ethernet interface. This patch is intended to provide support via the smsc911x driver when enabled in defconfig. The final submission of course will also include an updated defconfig. Signed-off-by: Steve Sakoman <steve@sakoman.com> --- diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 9995ac2..97d95a4 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ ...

On Thu, 29 Jan 2009 10:35:44 +0000 The problem is only in the net-next tree (not mainline 2.6.29-rcX). Bisected down to this commit is the problem: a9d8f9110d7e953c2f2b521087a4179677843c2a is first bad commit commit a9d8f9110d7e953c2f2b521087a4179677843c2a Author: Evgeniy Polyakov <zbr@ioremap.net> Date: Mon Jan 19 16:46:02 2009 -0800 inet: Allowing more than 64k connections and heavily optimize bind(0) time. With simple extension to the binding mechanism, which allows to ...

More of Eric's suggestions, handle the case of aggregation of counters correctly. Unfortunately, can't easily make xt_add_counter inline because DEFINE_PER_CPU doesn't seem to export to modules correctly. -- --

On Fri, 30 Jan 2009 17:57:21 +1100 Or netconsole. netconsole calls start_xmit from IRQ but it is safe since netconsole doesn't send fragmented skb's --

Replace existing reader/writer lock with Read-Copy-Update to elminate the overhead of a read lock on each incoming packet. This should reduce the overhead of iptables especially on SMP systems. The previous code used a reader-writer lock for two purposes. The first was to ensure that the xt_table_info reference was not in process of being changed. Since xt_table_info is only freed via one routine, it was a direct conversion to RCU. The other use of the reader-writer lock was to to block ...

Later patches change the locking on xt_table and the initialization of the lock element is not needed since the lock is always initialized in xt_table_register anyway. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- net/ipv4/netfilter/arptable_filter.c | 2 -- net/ipv4/netfilter/iptable_filter.c | 1 - net/ipv4/netfilter/iptable_mangle.c | 1 - net/ipv4/netfilter/iptable_raw.c | 1 - net/ipv4/netfilter/iptable_security.c | 1 - ...

The initialization of the lock element is not needed since the lock is always initialized in ebt_register_table. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- net/bridge/netfilter/ebtable_broute.c | 1 - net/bridge/netfilter/ebtable_filter.c | 1 - net/bridge/netfilter/ebtable_nat.c | 1 - 3 files changed, 3 deletions(-) --- a/net/bridge/netfilter/ebtable_broute.c 2009-01-27 17:09:10.313100854 -0800 +++ b/net/bridge/netfilter/ebtable_broute.c 2009-01-27 ...

Change to proper type on private pointer rather than anonymous void. Keep active elements on same cache line. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- include/linux/netfilter/x_tables.h | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/include/linux/netfilter/x_tables.h 2009-01-26 17:24:43.251543415 -0800 +++ b/include/linux/netfilter/x_tables.h 2009-01-26 17:29:12.510649107 -0800 @@ -349,9 +349,6 @@ struct xt_table { struct list_head ...

I don't think that's right. Now you don't end up calling pci_pm_default_suspend_generic() at all, and this no pci_save_state(). But I think it could easily be the call to pci_disable_enabled_device(). It does that if (atomic_read(&dev->enable_cnt)) do_pci_disable_device(dev); and that ends up disabling PCI_COMMAND_MASTER and then calling pcibios_disable_device(). Any device we have ever done pci_enable_device() on would trigger this, which includes PCIE bridges, for ...

It might also be instructive to see the same thing for a working kernel. I assume plain 2.6.28 works for you? Linus --

Yes, good thing to test. See my previous email - maybe it's a bridge. Linus --

I thought it was the standard behaviour. That may explain why I Maybe that would be enough as a definitive fix for a stable release, so that we can go on with deeper changes in newer Are there NICs out there able to do that themselves or does the driver need to rely on complex hacks in order to achieve this ? Willy --

So it is not explicit bind call, but port autoselection in the connect(). Can you check what errno is returned? Did I understand it right, that connect fails, you try different address, but then suddenly all those sockets become 'alive'? -- Evgeniy Polyakov --

It should contain rough number of sockets, there is no need to be very I used free alignment slot so that socket structure would not be I think it should be smallest_size != -1, since we really want to goto to the again label when hueristic is used, which in turn changes smallest_size. -- Evgeniy Polyakov --