* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: David Miller @ 2011-05-02 22:55 UTC (permalink / raw)
To: jpirko; +Cc: mirqus, netdev, xemul
In-Reply-To: <20110430112817.GD2658@psychotron.orion>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 30 Apr 2011 13:28:17 +0200
> Fri, Apr 22, 2011 at 11:43:10AM CEST, mirqus@gmail.com wrote:
>>2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>>> The code is not needed because tb[IFLA_IFNAME] is already
>>> processed in rtnl_newlink(). Remove this redundancy.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>>Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>
> Sorry for troubles.
>
> For net-next-2.6 this is fixed by:
> http://patchwork.ozlabs.org/patch/93498/
>
> For net-2.6 I suggest to revert this patch:
>
> Subject: [PATCH net-2.6] Revert: veth: remove unneeded ifname code from veth_newlink()
>
> 84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743 caused regression on veth
> creation. This patch reverts the original one.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied, with "Reported-by: " added to give credit to Michał Mirosław.
^ permalink raw reply
* Re: [PATCH] usbnet: runtime pm: fix out of memory
From: David Miller @ 2011-05-02 22:52 UTC (permalink / raw)
To: tom.leiming; +Cc: netdev, linux-usb, oneukum
In-Reply-To: <1304066229-30875-1-git-send-email-tom.leiming@gmail.com>
From: tom.leiming@gmail.com
Date: Fri, 29 Apr 2011 16:37:09 +0800
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch makes use of the EVENT_DEV_OPEN flag introduced recently to
> fix one out of memory issue, which can be reproduced on omap3/4 based
> pandaboard/beagle XM easily with steps below:
...
Oliver please review this patch. Thanks!
> - enable runtime pm
> echo auto > /sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-1/1-1.1/power/control
>
> - ifconfig eth0 up
>
> - then out of memroy happened, see [1] for kernel message.
>
> Follows my analysis:
> - 'ifconfig eth0 up' brings eth0 out of suspend, and usbnet_resume
> is called to schedule dev->bh, then rx urbs are submited to prepare for
> recieving data;
>
> - some usbnet devices will produce garbage rx packets flood if
> info->reset is not called in usbnet_open.
>
> - so there is no enough chances for usbnet_bh to handle and release
> recieved skb buffers since many rx interrupts consumes cpu, so out of memory
> for atomic allocation in rx_submit happened.
>
> This patch fixes the issue by simply not allowing schedule of usbnet_bh until device
> is opened.
>
> [1], dmesg
> [ 234.712005] smsc95xx 1-1.1:1.0: rpm_resume flags 0x4
> [ 234.712066] usb 1-1.1: rpm_resume flags 0x0
> [ 234.712066] usb 1-1: rpm_resume flags 0x0
> [ 234.712097] usb usb1: rpm_resume flags 0x0
> [ 234.712127] usb usb1: usb auto-resume
> [ 234.712158] ehci-omap ehci-omap.0: resume root hub
> [ 234.754028] hub 1-0:1.0: hub_resume
> [ 234.754821] hub 1-0:1.0: port 1: status 0507 change 0000
> [ 234.756011] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> [ 234.756042] hub 1-0:1.0: rpm_resume flags 0x4
> [ 234.756072] usb usb1: rpm_resume flags 0x0
> [ 234.756164] usb usb1: rpm_resume returns 1
> [ 234.756195] hub 1-0:1.0: rpm_resume returns 0
> [ 234.756195] hub 1-0:1.0: rpm_suspend flags 0x4
> [ 234.756225] hub 1-0:1.0: rpm_suspend returns 0
> [ 234.756256] usb usb1: rpm_resume returns 0
> [ 234.757141] usb 1-1: usb auto-resume
> [ 234.793151] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
> [ 234.816558] usb 1-1: finish resume
> [ 234.817871] hub 1-1:1.0: hub_resume
> [ 234.818420] hub 1-1:1.0: port 1: status 0507 change 0000
> [ 234.820495] ehci-omap ehci-omap.0: reused qh eec50220 schedule
> [ 234.820495] usb 1-1: link qh256-0001/eec50220 start 1 [1/0 us]
> [ 234.820587] usb 1-1: rpm_resume returns 0
> [ 234.820800] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0000
> [ 234.820800] hub 1-1:1.0: rpm_resume flags 0x4
> [ 234.820831] hub 1-1:1.0: rpm_resume returns 0
> [ 234.820861] hub 1-1:1.0: rpm_suspend flags 0x4
> [ 234.820861] hub 1-1:1.0: rpm_suspend returns 0
> [ 234.821777] usb 1-1.1: usb auto-resume
> [ 234.868591] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002
> [ 234.868591] hub 1-1:1.0: rpm_resume flags 0x4
> [ 234.868621] hub 1-1:1.0: rpm_resume returns 0
> [ 234.868652] hub 1-1:1.0: rpm_suspend flags 0x4
> [ 234.868652] hub 1-1:1.0: rpm_suspend returns 0
> [ 234.879486] usb 1-1.1: finish resume
> [ 234.880279] usb 1-1.1: rpm_resume returns 0
> [ 234.880310] smsc95xx 1-1.1:1.0: rpm_resume returns 0
> [ 238.880187] ksoftirqd/0: page allocation failure. order:0, mode:0x20
> [ 238.880218] Backtrace:
> [ 238.880249] [<c01b9800>] (dump_backtrace+0x0/0xf8) from [<c065e1dc>] (dump_stack+0x18/0x1c)
> [ 238.880249] r6:00000000 r5:00000000 r4:00000020 r3:00000002
> [ 238.880310] [<c065e1c4>] (dump_stack+0x0/0x1c) from [<c026ece4>] (__alloc_pages_nodemask+0x620/0x724)
> [ 238.880340] [<c026e6c4>] (__alloc_pages_nodemask+0x0/0x724) from [<c02986d4>] (kmem_getpages.clone.34+0x34/0xc8)
> [ 238.880371] [<c02986a0>] (kmem_getpages.clone.34+0x0/0xc8) from [<c02988f8>] (cache_grow.clone.42+0x84/0x154)
> [ 238.880371] r6:ef871aa4 r5:ef871a80 r4:ef81fd40 r3:00000020
> [ 238.880401] [<c0298874>] (cache_grow.clone.42+0x0/0x154) from [<c0298b64>] (cache_alloc_refill+0x19c/0x1f0)
> [ 238.880432] [<c02989c8>] (cache_alloc_refill+0x0/0x1f0) from [<c0299804>] (kmem_cache_alloc+0x90/0x190)
> [ 238.880462] [<c0299774>] (kmem_cache_alloc+0x0/0x190) from [<c052e260>] (__alloc_skb+0x34/0xe8)
> [ 238.880493] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet])
> [ 238.880523] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf050d38>] (rx_complete+0x19c/0x1b0 [usbnet])
> [ 238.880737] [<bf050b9c>] (rx_complete+0x0/0x1b0 [usbnet]) from [<bf006fd0>] (usb_hcd_giveback_urb+0xa8/0xf4 [usbcore])
> [ 238.880737] r8:eeeced34 r7:eeecec00 r6:eeecec00 r5:00000000 r4:eec2dd20
> [ 238.880767] r3:bf050b9c
> [ 238.880859] [<bf006f28>] (usb_hcd_giveback_urb+0x0/0xf4 [usbcore]) from [<bf03c8f8>] (ehci_urb_done+0xb0/0xbc [ehci_hcd])
> [ 238.880859] r6:00000000 r5:eec2dd20 r4:eeeced44 r3:eec2dd34
> [ 238.880920] [<bf03c848>] (ehci_urb_done+0x0/0xbc [ehci_hcd]) from [<bf040204>] (qh_completions+0x308/0x3bc [ehci_hcd])
> [ 238.880920] r7:00000000 r6:eeda21a0 r5:ffdfe3c0 r4:eeda21ac
> [ 238.880981] [<bf03fefc>] (qh_completions+0x0/0x3bc [ehci_hcd]) from [<bf040ef8>] (scan_async+0xb0/0x16c [ehci_hcd])
> [ 238.881011] [<bf040e48>] (scan_async+0x0/0x16c [ehci_hcd]) from [<bf040fec>] (ehci_work+0x38/0x90 [ehci_hcd])
> [ 238.881042] [<bf040fb4>] (ehci_work+0x0/0x90 [ehci_hcd]) from [<bf042940>] (ehci_irq+0x300/0x34c [ehci_hcd])
> [ 238.881072] r4:eeeced34 r3:00000001
> [ 238.881134] [<bf042640>] (ehci_irq+0x0/0x34c [ehci_hcd]) from [<bf006828>] (usb_hcd_irq+0x40/0xac [usbcore])
> [ 238.881195] [<bf0067e8>] (usb_hcd_irq+0x0/0xac [usbcore]) from [<c0239764>] (handle_irq_event_percpu+0xb8/0x240)
> [ 238.881225] r6:eec504e0 r5:0000006d r4:eec504e0 r3:bf0067e8
> [ 238.881256] [<c02396ac>] (handle_irq_event_percpu+0x0/0x240) from [<c0239930>] (handle_irq_event+0x44/0x64)
> [ 238.881256] [<c02398ec>] (handle_irq_event+0x0/0x64) from [<c023bbd0>] (handle_level_irq+0xe0/0x114)
> [ 238.881286] r6:0000006d r5:c080c14c r4:c080c100 r3:00020000
> [ 238.881317] [<c023baf0>] (handle_level_irq+0x0/0x114) from [<c01ab090>] (asm_do_IRQ+0x90/0xd0)
> [ 238.881317] r5:00000000 r4:0000006d
> [ 238.881347] [<c01ab000>] (asm_do_IRQ+0x0/0xd0) from [<c06624d0>] (__irq_svc+0x50/0x134)
> [ 238.881378] Exception stack(0xef837e20 to 0xef837e68)
> [ 238.881378] 7e20: 00000001 00185610 016cc000 c00490c0 eb380000 ef800540 00000020 00004ae0
> [ 238.881408] 7e40: 00000020 bf0509f4 60000013 ef837e9c ef837e40 ef837e68 c0226f0c c0298ca0
> [ 238.881408] 7e60: 20000013 ffffffff
> [ 238.881408] r5:fa240100 r4:ffffffff
> [ 238.881439] [<c0298bb8>] (__kmalloc_track_caller+0x0/0x1d0) from [<c052e284>] (__alloc_skb+0x58/0xe8)
> [ 238.881469] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet])
> [ 238.881500] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf0513d8>] (usbnet_bh+0x1b4/0x250 [usbnet])
> [ 238.881530] [<bf051224>] (usbnet_bh+0x0/0x250 [usbnet]) from [<c01f912c>] (tasklet_action+0xb0/0x1f8)
> [ 238.881530] r6:00000000 r5:ef9757f0 r4:ef9757ec r3:bf051224
> [ 238.881561] [<c01f907c>] (tasklet_action+0x0/0x1f8) from [<c01f97ac>] (__do_softirq+0x140/0x290)
> [ 238.881561] r8:00000006 r7:00000101 r6:00000000 r5:c0806098 r4:00000001
> [ 238.881591] r3:c01f907c
> [ 238.881622] [<c01f966c>] (__do_softirq+0x0/0x290) from [<c01f99cc>] (run_ksoftirqd+0xd0/0x1f4)
> [ 238.881622] [<c01f98fc>] (run_ksoftirqd+0x0/0x1f4) from [<c02113b0>] (kthread+0x90/0x98)
> [ 238.881652] r7:00000013 r6:c01f98fc r5:00000000 r4:ef831efc
> [ 238.881683] [<c0211320>] (kthread+0x0/0x98) from [<c01f62f4>] (do_exit+0x0/0x374)
> [ 238.881713] r6:c01f62f4 r5:c0211320 r4:ef831efc
> [ 238.881713] Mem-info:
> [ 238.881744] Normal per-cpu:
> [ 238.881744] CPU 0: hi: 186, btch: 31 usd: 38
> [ 238.881744] CPU 1: hi: 186, btch: 31 usd: 169
> [ 238.881774] HighMem per-cpu:
> [ 238.881774] CPU 0: hi: 90, btch: 15 usd: 66
> [ 238.881774] CPU 1: hi: 90, btch: 15 usd: 86
> [ 238.881805] active_anon:544 inactive_anon:71 isolated_anon:0
> [ 238.881805] active_file:926 inactive_file:2538 isolated_file:0
> [ 238.881805] unevictable:0 dirty:10 writeback:0 unstable:0
> [ 238.881805] free:57782 slab_reclaimable:864 slab_unreclaimable:186898
> [ 238.881805] mapped:632 shmem:144 pagetables:50 bounce:0
> [ 238.881835] Normal free:1328kB min:3532kB low:4412kB high:5296kB active_anon:0kB inactive_anon:0kB active_file:880kB inactive_file:848kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:780288kB mlocked:0kB dirty:36kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:3456kB slab_unreclaimable:747592kB kernel_stack:392kB pagetables:200kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 238.881866] lowmem_reserve[]: 0 1904 1904
> [ 238.881896] HighMem free:229800kB min:236kB low:508kB high:784kB active_anon:2176kB inactive_anon:284kB active_file:2824kB inactive_file:9304kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243712kB mlocked:0kB dirty:4kB writeback:0kB mapped:2528kB shmem:576kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 238.881927] lowmem_reserve[]: 0 0 0
> [ 238.881958] Normal: 0*4kB 4*8kB 6*16kB 0*32kB 1*64kB 1*128kB 0*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 1344kB
> [ 238.882019] HighMem: 6*4kB 2*8kB 4*16kB 4*32kB 1*64kB 1*128kB 0*256kB 2*512kB 3*1024kB 0*2048kB 55*4096kB = 229800kB
> [ 238.882080] 3610 total pagecache pages
> [ 238.882080] 0 pages in swap cache
> [ 238.882080] Swap cache stats: add 0, delete 0, find 0/0
> [ 238.882110] Free swap = 0kB
> [ 238.882110] Total swap = 0kB
> [ 238.933776] 262144 pages of RAM
> [ 238.933776] 58240 free pages
> [ 238.933776] 10503 reserved pages
> [ 238.933776] 187773 slab pages
> [ 238.933807] 2475 pages shared
> [ 238.933807] 0 pages swap cached
>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> drivers/net/usb/usbnet.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 009bba3..9ab439d 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -645,6 +645,7 @@ int usbnet_stop (struct net_device *net)
> struct driver_info *info = dev->driver_info;
> int retval;
>
> + clear_bit(EVENT_DEV_OPEN, &dev->flags);
> netif_stop_queue (net);
>
> netif_info(dev, ifdown, dev->net,
> @@ -1524,9 +1525,12 @@ int usbnet_resume (struct usb_interface *intf)
> smp_mb();
> clear_bit(EVENT_DEV_ASLEEP, &dev->flags);
> spin_unlock_irq(&dev->txq.lock);
> - if (!(dev->txq.qlen >= TX_QLEN(dev)))
> - netif_start_queue(dev->net);
> - tasklet_schedule (&dev->bh);
> +
> + if (test_bit(EVENT_DEV_OPEN, &dev->flags)) {
> + if (!(dev->txq.qlen >= TX_QLEN(dev)))
> + netif_start_queue(dev->net);
> + tasklet_schedule (&dev->bh);
> + }
> }
> return 0;
> }
> --
> 1.7.4.1
>
^ permalink raw reply
* Re: [PATCH] smsc95xx: fix reset check
From: David Miller @ 2011-05-02 22:51 UTC (permalink / raw)
To: rabin; +Cc: steve.glendinning, netdev
In-Reply-To: <1304188167-18152-1-git-send-email-rabin@rab.in>
From: Rabin Vincent <rabin@rab.in>
Date: Sat, 30 Apr 2011 23:59:27 +0530
> The reset loop check should check the MII_BMCR register value for
> BMCR_RESET rather than for MII_BMCR (the register address, which also
> happens to be zero).
>
> Signed-off-by: Rabin Vincent <rabin@rab.in>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] tg3: Fix failure to enable WoL by default when possible
From: David Miller @ 2011-05-02 22:47 UTC (permalink / raw)
To: rjw; +Cc: netdev, linux-kernel, mcarlson, mchan, sfr, linux-next
In-Reply-To: <201104282302.15502.rjw@sisk.pl>
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Thu, 28 Apr 2011 23:02:15 +0200
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> tg3 is supposed to enable WoL by default on adapters which support
> that, but it fails to do so unless the adapter's
> /sys/devices/.../power/wakeup file contains 'enabled' during the
> initialization of the adapter. Fix that by making tg3 use
> device_set_wakeup_enable() to enable wakeup automatically whenever
> WoL should be enabled by default.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Applied, thanks Rafael.
Stephen, this patch is going to show up in net-2.6 and it will
generate a merge conflict with Joe Perches's commit in net-next-2.6
which converts tg3 to use a bitmap for the tp->tg3_flags* values.
--------------------
commit 63c3a66fe6c827a731dcbdee181158b295626f83
Author: Joe Perches <joe@perches.com>
Date: Tue Apr 26 08:12:10 2011 +0000
tg3: Convert u32 flag,flg2,flg3 uses to bitmap
--------------------
It should be easy to resolve, and you don't need to report this
to us when you hit it while building your -next tree, thanks :-)
I'll resolve it myself over the next day or two.
> ---
> drivers/net/tg3.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/drivers/net/tg3.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/tg3.c
> +++ linux-2.6/drivers/net/tg3.c
> @@ -12327,8 +12327,10 @@ static void __devinit tg3_get_eeprom_hw_
> if (val & VCPU_CFGSHDW_ASPM_DBNC)
> tp->tg3_flags |= TG3_FLAG_ASPM_WORKAROUND;
> if ((val & VCPU_CFGSHDW_WOL_ENABLE) &&
> - (val & VCPU_CFGSHDW_WOL_MAGPKT))
> + (val & VCPU_CFGSHDW_WOL_MAGPKT)) {
> tp->tg3_flags |= TG3_FLAG_WOL_ENABLE;
> + device_set_wakeup_enable(&tp->pdev->dev, true);
> + }
> goto done;
> }
>
> @@ -12461,8 +12463,10 @@ static void __devinit tg3_get_eeprom_hw_
> tp->tg3_flags &= ~TG3_FLAG_WOL_CAP;
>
> if ((tp->tg3_flags & TG3_FLAG_WOL_CAP) &&
> - (nic_cfg & NIC_SRAM_DATA_CFG_WOL_ENABLE))
> + (nic_cfg & NIC_SRAM_DATA_CFG_WOL_ENABLE)) {
> tp->tg3_flags |= TG3_FLAG_WOL_ENABLE;
> + device_set_wakeup_enable(&tp->pdev->dev, true);
> + }
>
> if (cfg2 & (1 << 17))
> tp->phy_flags |= TG3_PHYFLG_CAPACITIVE_COUPLING;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 1/5] networking: inappropriate ioctl operation should return ENOTTY
From: David Miller @ 2011-05-02 22:41 UTC (permalink / raw)
To: lifongsun; +Cc: alan, netdev, linux-kernel
In-Reply-To: <1303977891-29280-1-git-send-email-lifongsun@gmail.com>
From: Lifeng Sun <lifongsun@gmail.com>
Date: Thu, 28 Apr 2011 16:04:51 +0800
> ioctl() calls against a socket with an inappropriate ioctl operation
> are incorrectly returning EINVAL rather than ENOTTY:
>
> [ENOTTY]
> Inappropriate I/O control operation.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=33992
>
> Signed-off-by: Lifeng Sun <lifongsun@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:use help function of skb_checksum_start_offset to calculate offset
From: David Miller @ 2011-05-02 22:35 UTC (permalink / raw)
To: cmetcalf; +Cc: shanwei, netdev
In-Reply-To: <4DBF3037.30203@tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Mon, 2 May 2011 18:29:11 -0400
> On 5/2/2011 6:21 PM, David Miller wrote:
>> From: Chris Metcalf <cmetcalf@tilera.com>
>> Date: Mon, 2 May 2011 18:20:01 -0400
>>
>>> I took the drivers/net/tile/ change into my tree, but I'll defer to David
>>> or some other net person to take the net/ipv6/udp.c change. Thanks!
>> I took them both into my tree. Didn't you see my reply?
>
> I did, but I didn't see the change yet in .39-rc5, so I figured it would be
> harmless to also take it into the tile tree.
This change will show up in net-next-2.6 and as a consequence linux-2.6-next
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:use help function of skb_checksum_start_offset to calculate offset
From: Chris Metcalf @ 2011-05-02 22:29 UTC (permalink / raw)
To: David Miller; +Cc: shanwei, netdev
In-Reply-To: <20110502.152136.115919893.davem@davemloft.net>
On 5/2/2011 6:21 PM, David Miller wrote:
> From: Chris Metcalf <cmetcalf@tilera.com>
> Date: Mon, 2 May 2011 18:20:01 -0400
>
>> I took the drivers/net/tile/ change into my tree, but I'll defer to David
>> or some other net person to take the net/ipv6/udp.c change. Thanks!
> I took them both into my tree. Didn't you see my reply?
I did, but I didn't see the change yet in .39-rc5, so I figured it would be
harmless to also take it into the tile tree. And, I thought you might have
just taken the platform-independent part of the change. I'll revert the
tile part of the change out of my tree. Thanks!
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: dont hold rtnl mutex during netlink dump callbacks
From: David Miller @ 2011-05-02 22:27 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, kaber, netdev, remi.denis-courmont
In-Reply-To: <20110428084337.6b54603e@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 28 Apr 2011 08:43:37 -0700
> On Thu, 28 Apr 2011 10:56:07 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Four years ago, Patrick made a change to hold rtnl mutex during netlink
>> dump callbacks.
>>
>> I believe it was a wrong move. This slows down concurrent dumps, making
>> good old /proc/net/ files faster than rtnetlink in some situations.
>>
>> This occurred to me because one "ip link show dev ..." was _very_ slow
>> on a workload adding/removing network devices in background.
>>
>> All dump callbacks are able to use RCU locking now, so this patch does
>> roughly a revert of commits :
>>
>> 1c2d670f366 : [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
>> 6313c1e0992 : [RTNETLINK]: Remove unnecessary locking in dump callbacks
>>
>> This let writers fight for rtnl mutex and readers going full speed.
>>
>> It also takes care of phonet : phonet_route_get() is now called from rcu
>> read section. I renamed it to phonet_route_get_rcu()
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:use help function of skb_checksum_start_offset to calculate offset
From: Chris Metcalf @ 2011-05-02 22:20 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, netdev
In-Reply-To: <4DB1617D.30600@cn.fujitsu.com>
On 4/22/2011 7:07 AM, Shan Wei wrote:
> Although these are equivalent, but the skb_checksum_start_offset() is more readable.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> drivers/net/tile/tilepro.c | 2 +-
> net/ipv6/udp.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tile/tilepro.c b/drivers/net/tile/tilepro.c
> index 0825db6..1e980fd 100644
> --- a/drivers/net/tile/tilepro.c
> +++ b/drivers/net/tile/tilepro.c
> @@ -1930,7 +1930,7 @@ static int tile_net_tx(struct sk_buff *skb, struct net_device *dev)
> unsigned int len = skb->len;
> unsigned char *data = skb->data;
>
> - unsigned int csum_start = skb->csum_start - skb_headroom(skb);
> + unsigned int csum_start = skb_checksum_start_offset(skb);
>
> lepp_frag_t frags[LEPP_MAX_FRAGS];
>
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 15c3774..95c62a1 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1328,7 +1328,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb, u32 features)
> /* Do software UFO. Complete and fill in the UDP checksum as HW cannot
> * do checksum of UDP packets sent as multiple IP fragments.
> */
> - offset = skb->csum_start - skb_headroom(skb);
> + offset = skb_checksum_start_offset(skb);
> csum = skb_checksum(skb, offset, skb->len- offset, 0);
> offset += skb->csum_offset;
> *(__sum16 *)(skb->data + offset) = csum_fold(csum);
I took the drivers/net/tile/ change into my tree, but I'll defer to David
or some other net person to take the net/ipv6/udp.c change. Thanks!
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:use help function of skb_checksum_start_offset to calculate offset
From: David Miller @ 2011-05-02 22:21 UTC (permalink / raw)
To: cmetcalf; +Cc: shanwei, netdev
In-Reply-To: <4DBF2E11.3010904@tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Mon, 2 May 2011 18:20:01 -0400
> I took the drivers/net/tile/ change into my tree, but I'll defer to David
> or some other net person to take the net/ipv6/udp.c change. Thanks!
I took them both into my tree. Didn't you see my reply?
^ permalink raw reply
* net-2.6 state...
From: David Miller @ 2011-05-02 22:20 UTC (permalink / raw)
To: netdev
Right now I'm sorting through patchwork to make sure anything that
belongs in net-2.6, is there.
Then I'm going to push things out to Linus.
We will be in a more serious lock down mode after that. So I really
only want to see obvious critical fixes going into net-2.6. Even
comment typos will be put into net-next-2.6.
Please cooperate with this policy and everything will go smoothly.
There is nothing I like more than seeing people work on bug fixes at
this point in the -rc* series, so if you want to make me (as well as
the users reporting these things) really happy, fix some bugs. :-)
Thanks!
^ permalink raw reply
* RE: [E1000-devel] WoL stopped working after power off with 2.6.38 (e1000e specific?)
From: Allan, Bruce W @ 2011-05-02 22:07 UTC (permalink / raw)
To: Allan, Bruce W, Kamil Iskra, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
Cc: linux-pm@lists.linux-foundation.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001B54CE017@orsmsx509.amr.corp.intel.com>
>-----Original Message-----
>From: Allan, Bruce W [mailto:bruce.w.allan@intel.com]
>Sent: Monday, May 02, 2011 3:02 PM
>To: Kamil Iskra; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>Cc: linux-pm@lists.linux-foundation.org
>Subject: Re: [E1000-devel] WoL stopped working after power off with 2.6.38
>(e1000e specific?)
>
>>-----Original Message-----
>>From: Kamil Iskra [mailto:kamil@iskra.name]
>>Sent: Friday, April 29, 2011 10:45 PM
>>To: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>>Subject: [E1000-devel] WoL stopped working after power off with 2.6.38 (e1000e
>>specific?)
>>
>>[ Note: I'm not on these mailing lists, so be sure to Cc: me if you want
>>more info from me ]
>>
>>After upgrading from kernel 2.6.37 to 2.6.38, Wake on LAN after shutdown
>>stopped working for me on both of my Thinkpad laptops. Both systems use
>>the e1000e driver. One (a T61) has an 82566MM NIC, the other (an X201) an
>>82577LM. I'm running 64-bit Gentoo Linux with a custom compiled kernel.
>>The network driver is built into the kernel.
>>
>>Wake on LAN still works after suspend (S3), but not after a complete
>>shutdown (with power supply connected).
>>
>>I figured the updated e1000e driver in 2.6.38 was probably to blame,
>>however, after I copied the whole drivers/net/e1000e directory from the
>>2.6.37 over to the 2.6.38 tree and recompiled, the problem persisted, so I
>>don't know anymore.
>>
>>I modified the system shutdown sequence to invoke ifconfig and ethtool
>>right before the final halt. According to ifconfig, eth0 is down at that
>>point. According to ethtool, WoL is configured correctly ("Wake-on: g").
>>There is, however, a difference in the output of ethtool between the two
>>kernel versions. "Link detected:" shows "yes" with 2.6.37, but "no" with
>>2.6.38.
>>
>>A workaround that I found to work was to invoke "ifconfig eth0 up" right
>>before the halt.
>>
>>Any suggestions? Is this new behavior expected or is it a bug?
>
>WoL from S5 "works for me"(TM) using the e1000e driver on RHEL6 and 2.6.38.
>Could you provide your customer kernel configuration?
>
>Cc: linux-pm@lists.linux-foundation.org
>
>Thanks,
>Bruce.
:s/customer/custom/
^ permalink raw reply
* Re: pull request: batman-adv 2011-05-01
From: David Miller @ 2011-05-02 22:06 UTC (permalink / raw)
To: sven-KaDOiPu9UxWEi8DpZVb4nw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1304284234-27338-1-git-send-email-sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Date: Sun, 1 May 2011 23:10:30 +0200
> I would like to propose following patches for net-next-2.6/2.6.40. Marek
> Lindner continued to convert different datastructures to use RCU. Antonio
> Quartulli fixed an important bug introduced in the last patchset related to the
> update of the current gateway. He also did some minor cleanup work.
>
> I've removed the patch "net: batman-adv: remove rx_csum ethtool_ops" again
> because you already applied it in your branch.
I'll pull this, but I really want you to resolve atomic_dec_not_zero()
properly.
It does not belong in any batman-adv header file.
Instead it belongs in all of arch/${ARCH}/include/asm/atomic.h and
include/asm-generic/atomic.h
Please submit a patch which puts it in the proper place to linux-kernel
Don't worry about build problems resulting from this, I'll make sure
to deal with it properly when the change shows up in Linus's tree.
Thanks.
^ permalink raw reply
* RE: [E1000-devel] WoL stopped working after power off with 2.6.38 (e1000e specific?)
From: Allan, Bruce W @ 2011-05-02 22:02 UTC (permalink / raw)
To: Kamil Iskra, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
Cc: linux-pm@lists.linux-foundation.org
In-Reply-To: <20110430054519.GA9826@scooby.iskra.name>
>-----Original Message-----
>From: Kamil Iskra [mailto:kamil@iskra.name]
>Sent: Friday, April 29, 2011 10:45 PM
>To: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>Subject: [E1000-devel] WoL stopped working after power off with 2.6.38 (e1000e
>specific?)
>
>[ Note: I'm not on these mailing lists, so be sure to Cc: me if you want
>more info from me ]
>
>After upgrading from kernel 2.6.37 to 2.6.38, Wake on LAN after shutdown
>stopped working for me on both of my Thinkpad laptops. Both systems use
>the e1000e driver. One (a T61) has an 82566MM NIC, the other (an X201) an
>82577LM. I'm running 64-bit Gentoo Linux with a custom compiled kernel.
>The network driver is built into the kernel.
>
>Wake on LAN still works after suspend (S3), but not after a complete
>shutdown (with power supply connected).
>
>I figured the updated e1000e driver in 2.6.38 was probably to blame,
>however, after I copied the whole drivers/net/e1000e directory from the
>2.6.37 over to the 2.6.38 tree and recompiled, the problem persisted, so I
>don't know anymore.
>
>I modified the system shutdown sequence to invoke ifconfig and ethtool
>right before the final halt. According to ifconfig, eth0 is down at that
>point. According to ethtool, WoL is configured correctly ("Wake-on: g").
>There is, however, a difference in the output of ethtool between the two
>kernel versions. "Link detected:" shows "yes" with 2.6.37, but "no" with
>2.6.38.
>
>A workaround that I found to work was to invoke "ifconfig eth0 up" right
>before the halt.
>
>Any suggestions? Is this new behavior expected or is it a bug?
WoL from S5 "works for me"(TM) using the e1000e driver on RHEL6 and 2.6.38.
Could you provide your customer kernel configuration?
Cc: linux-pm@lists.linux-foundation.org
Thanks,
Bruce.
^ permalink raw reply
* Re: [PATCH] linux/stmmac.h: include <linux/platform_device.h> to remove compilation warning.
From: David Miller @ 2011-05-02 22:01 UTC (permalink / raw)
To: viresh.kumar
Cc: peppe.cavallaro, netdev, shiraz.hashim, armando.visconti,
deepak.sikri, viresh.linux
In-Reply-To: <2239eca1d15014be7b6d94f883f9492dc1fbc60a.1304317552.git.viresh.kumar@st.com>
From: Viresh Kumar <viresh.kumar@st.com>
Date: Mon, 2 May 2011 12:00:37 +0530
> stmmac.h uses struct platform_device and doesn't include
> <linux/platform_device.h>. And so we get following compilation warning while
> using this file:
> warning: ‘struct platform_device’ declared inside parameter list
>
> This patch includes <linux/platform_device.h> in stmmac.h to remove this warning
>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
This patch applies to neither net-2.6, nor net-next-2.6
The context around your change in all current trees looks a lot
different than what's in your patch.
In fact, even if I go through the entire history in GIT of this
header file, those STMAC_TYPE_0 defines are never there.
The string "STMAC_TYPE_0" doesn't even show up in a query to google
code search.
What tree are you even patching against?
^ permalink raw reply
* Re: [PATCH] amd8111e: trivial typo spelling: Negotitate -> Negotiate
From: David Miller @ 2011-05-02 21:47 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1304366369.7792.45.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Mon, 02 May 2011 12:59:29 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* [PATCH net-next-2.6] ipv4: Make sure flowi4->{saddr,daddr} are always set.
From: David Miller @ 2011-05-02 21:38 UTC (permalink / raw)
To: netdev
Slow path output route resolution always makes sure that
->{saddr,daddr} are set, and also if we trigger into IPSEC resolution
we initialize them as well, because xfrm_lookup() expects them to be
fully resolved.
But if we hit the fast path and flowi4->flowi4_proto is zero, we won't
do this initialization.
Therefore, move the IPSEC path initialization to the route cache
lookup fast path to make sure these are always set.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/route.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 93f71be..64f360d 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2675,6 +2675,10 @@ struct rtable *__ip_route_output_key(struct net *net, struct flowi4 *flp4)
dst_use(&rth->dst, jiffies);
RT_CACHE_STAT_INC(out_hit);
rcu_read_unlock_bh();
+ if (!flp4->saddr)
+ flp4->saddr = rth->rt_src;
+ if (!flp4->daddr)
+ flp4->daddr = rth->rt_dst;
return rth;
}
RT_CACHE_STAT_INC(out_hlist_search);
@@ -2772,15 +2776,10 @@ struct rtable *ip_route_output_flow(struct net *net, struct flowi4 *flp4,
if (IS_ERR(rt))
return rt;
- if (flp4->flowi4_proto) {
- if (!flp4->saddr)
- flp4->saddr = rt->rt_src;
- if (!flp4->daddr)
- flp4->daddr = rt->rt_dst;
+ if (flp4->flowi4_proto)
rt = (struct rtable *) xfrm_lookup(net, &rt->dst,
flowi4_to_flowi(flp4),
sk, 0);
- }
return rt;
}
--
1.7.4.5
^ permalink raw reply related
* Re: [PATCH] ipheth.c: Enable IP header alignment
From: L. Alberto Giménez @ 2011-05-02 21:12 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, dgiagio, dborca, pmcenery, david.hill, linux-usb,
netdev
In-Reply-To: <20110502.124622.226785624.davem@davemloft.net>
On Mon, May 02, 2011 at 12:46:22PM -0700, David Miller wrote:
>
> Why did this break things?
Hi, I don't know. As upstream is unresponsive and is applying patches to his
private repo without submitting them to the list (which I can understand), I
decided to submit the particular fix so mainline users can get tethering working
again.
I received a forwarded email with the patch (I think that's because I submitted
the driver to mainline) asking for the mainline driver status and if it was
being maintained.
>
> I'm not applying a fix when nobody can explain the reason why:
>
> 1) Things broke in the first place
> 2) Forcing reservation of 2 bytes fixes things
Honestly, I can't answer either of those ones. I just submitted a patch that
*seemed* to fix the problem (I don't own an iPhone device since long time ago),
after explictly requesting upstream to submit by himself, and getting a
negative.
> Where is the built in assumption about "2" and why does it exist? Why
> can't we fix this code not to have such assumptions in the first
> place?
Ditto.
At this point, I think that David, Diego or Daniel should step in if they want
to keep on with this discussion. I won't have problems if you want to take this
off-list.
Best regards,
--
L. Alberto Giménez
JabberID agimenez@jabber.sysvalve.es
GnuPG key ID 0x3BAABDE1
^ permalink raw reply
* Re: [PATCH] ipheth.c: Enable IP header alignment
From: Ben Hutchings @ 2011-05-02 21:04 UTC (permalink / raw)
To: L. Alberto Giménez
Cc: linux-kernel, dgiagio, dborca, davem, pmcenery, david.hill,
open list:USB SUBSYSTEM, open list:NETWORKING DRIVERS
In-Reply-To: <1304364912-15444-1-git-send-email-agimenez@sysvalve.es>
On Mon, 2011-05-02 at 21:35 +0200, L. Alberto Giménez wrote:
> Since commit ea812ca1b06113597adcd8e70c0f84a413d97544 (x86: Align skb w/ start
> of cacheline on newer core 2/Xeon Arch), NET_IP_ALIGN changed from 2 to 0, and
> the constant is used to reserve more room for the socket buffer.
>
> Some people have reported that tethering stopped working and David Hill
> submited a patch that redefined NET_IP_ALIGN. Pointed by Ben Hutchings, the
> patch has been reworked to use a private constant.
>
> I have no more an iPhone device to test it, so it is only compile-tested.
>
> Signed-off-by: L. Alberto Giménez <agimenez@sysvalve.es>
> ---
> drivers/net/usb/ipheth.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
> index 7d42f9a..8f1ffc7 100644
> --- a/drivers/net/usb/ipheth.c
> +++ b/drivers/net/usb/ipheth.c
> @@ -80,6 +80,8 @@
> #define IPHETH_CARRIER_CHECK_TIMEOUT round_jiffies_relative(1 * HZ)
> #define IPHETH_CARRIER_ON 0x04
>
> +#define IPHETH_IP_ALIGN 2
> +
> static struct usb_device_id ipheth_table[] = {
> { USB_DEVICE_AND_INTERFACE_INFO(
> USB_VENDOR_APPLE, USB_PRODUCT_IPHONE,
> @@ -205,15 +207,15 @@ static void ipheth_rcvbulk_callback(struct urb *urb)
> len = urb->actual_length;
> buf = urb->transfer_buffer;
>
> - skb = dev_alloc_skb(NET_IP_ALIGN + len);
> + skb = dev_alloc_skb(IPHETH_IP_ALIGN + len);
> if (!skb) {
> err("%s: dev_alloc_skb: -ENOMEM", __func__);
> dev->net->stats.rx_dropped++;
> return;
> }
>
> - skb_reserve(skb, NET_IP_ALIGN);
> - memcpy(skb_put(skb, len), buf + NET_IP_ALIGN, len - NET_IP_ALIGN);
> + skb_reserve(skb, IPHETH_IP_ALIGN);
> + memcpy(skb_put(skb, len), buf + IPHETH_IP_ALIGN, len - IPHETH_IP_ALIGN);
[...]
So this was using NET_IP_ALIGN as an offset into the URB. Which was
totally bogus, as its value has long been architecture-dependent. The
code is also claiming to put len bytes but only copying len - delta.
The correct code would be something like:
if (urb->actual_length <= IPHETH_IP_ALIGN) {
dev->net->stats.rx_length_errors++;
return;
}
len = urb->actual_length - IPHETH_IP_ALIGN;
buf = urb->transfer_buffer + IPHETH_IP_ALIGN;
dev_alloc_skb(len);
...
memcpy(skb_put(skb, len), buf, len);
Ben.
> skb->dev = dev->net;
> skb->protocol = eth_type_trans(skb, dev->net);
>
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Frequent spurious tx_timeouts for libertas
From: Ben Hutchings @ 2011-05-02 20:47 UTC (permalink / raw)
To: Daniel Drake
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless
In-Reply-To: <BANLkTi=FT4v=Jvv5bQpUX15R87kPudKq=Q@mail.gmail.com>
On Mon, 2011-05-02 at 20:59 +0100, Daniel Drake wrote:
> On 2 May 2011 03:24, Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org> wrote:
> >> Also, while looking at this code, I spotted a bug in dev_watchdog():
> >> /*
> >> * old device drivers set dev->trans_start
> >> */
> >> trans_start = txq->trans_start ? : dev->trans_start;
> >>
> >> i.e. it is trying to figure out whether to read trans_start from txq
> >> or dev. In both cases, trans_start is updated based on the value of
> >> jiffies, which will occasionally be 0 (as it wraps around). Therefore
> >> this line of code will occasionally make the wrong decision.
> >
> > No, I don't think so.
> >
> > If only dev->trans_start is being updated then the watchdog reads that.
> > If both txq->trans_start and dev->trans_start are being updated then it
> > doesn't matter much which the watchdog reads.
> > If only txq->trans_start is being updated then dev->trans_start is
> > always set to 0, so when txq->trans_start is 0 the watchdog still gets
> > 0.
>
> dev->trans_start is unconditionally initialized by dev_activate() in
> sch_generic.c:
>
> if (need_watchdog) {
> dev->trans_start = jiffies;
> dev_watchdog_up(dev);
> }
>
> so it is (usually) not 0.
[...]
You're right. Seems like we have an incomplete compatibility hack that
can hurt drivers that are doing the right thing.
For those few single-queue drivers that need to update the transmit
time, perhaps we could add a dev_trans_update() as a wrapper for
txq_trans_update(). Then delete net_device::trans_start and change
dev_trans_start() to avoid using it.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Frequent spurious tx_timeouts for libertas
From: Daniel Drake @ 2011-05-02 20:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless
In-Reply-To: <BANLkTi=FT4v=Jvv5bQpUX15R87kPudKq=Q@mail.gmail.com>
On 2 May 2011 20:59, Daniel Drake <dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org> wrote:
> dev->trans_start is unconditionally initialized by dev_activate() in
> sch_generic.c:
Also, many drivers (including libertas) set it in their tx_timeout handlers:
dev->trans_start = jiffies; /* prevent tx timeout */
I don't understand why (the TX timeout has already occurred, it can't
be prevented at that stage).
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] amd8111e: trivial typo spelling: Negotitate -> Negotiate
From: Joe Perches @ 2011-05-02 19:59 UTC (permalink / raw)
To: netdev
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/amd8111e.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
index 88495c4..241b185 100644
--- a/drivers/net/amd8111e.c
+++ b/drivers/net/amd8111e.c
@@ -106,7 +106,7 @@ MODULE_DESCRIPTION ("AMD8111 based 10/100 Ethernet Controller. Driver Version "M
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, amd8111e_pci_tbl);
module_param_array(speed_duplex, int, NULL, 0);
-MODULE_PARM_DESC(speed_duplex, "Set device speed and duplex modes, 0: Auto Negotitate, 1: 10Mbps Half Duplex, 2: 10Mbps Full Duplex, 3: 100Mbps Half Duplex, 4: 100Mbps Full Duplex");
+MODULE_PARM_DESC(speed_duplex, "Set device speed and duplex modes, 0: Auto Negotiate, 1: 10Mbps Half Duplex, 2: 10Mbps Full Duplex, 3: 100Mbps Half Duplex, 4: 100Mbps Full Duplex");
module_param_array(coalesce, bool, NULL, 0);
MODULE_PARM_DESC(coalesce, "Enable or Disable interrupt coalescing, 1: Enable, 0: Disable");
module_param_array(dynamic_ipg, bool, NULL, 0);
^ permalink raw reply related
* Re: Frequent spurious tx_timeouts for libertas
From: Daniel Drake @ 2011-05-02 19:59 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless
In-Reply-To: <1304303082.2833.159.camel@localhost>
On 2 May 2011 03:24, Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org> wrote:
>> Also, while looking at this code, I spotted a bug in dev_watchdog():
>> /*
>> * old device drivers set dev->trans_start
>> */
>> trans_start = txq->trans_start ? : dev->trans_start;
>>
>> i.e. it is trying to figure out whether to read trans_start from txq
>> or dev. In both cases, trans_start is updated based on the value of
>> jiffies, which will occasionally be 0 (as it wraps around). Therefore
>> this line of code will occasionally make the wrong decision.
>
> No, I don't think so.
>
> If only dev->trans_start is being updated then the watchdog reads that.
> If both txq->trans_start and dev->trans_start are being updated then it
> doesn't matter much which the watchdog reads.
> If only txq->trans_start is being updated then dev->trans_start is
> always set to 0, so when txq->trans_start is 0 the watchdog still gets
> 0.
dev->trans_start is unconditionally initialized by dev_activate() in
sch_generic.c:
if (need_watchdog) {
dev->trans_start = jiffies;
dev_watchdog_up(dev);
}
so it is (usually) not 0.
Thanks for your input on the tx timeout issue, now that I understand
it better I think the right plan of action is to remove it from
libertas entirely, I'll CC you on the patch.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 2/8] Add a new zerocopy device flag
From: Michael S. Tsirkin @ 2011-05-02 19:53 UTC (permalink / raw)
To: Shirley Ma
Cc: David Miller, Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev,
kvm, linux-kernel
In-Reply-To: <1304362028.20660.15.camel@localhost.localdomain>
On Mon, May 02, 2011 at 11:47:08AM -0700, Shirley Ma wrote:
> On Mon, 2011-05-02 at 13:42 +0300, Michael S. Tsirkin wrote:
> > This comment should specify what exactly is the promise the
> > device makes by setting this flag. Specifically, the
> > condition is that no skb fragments are used
> > after the uinfo callback has been called.
> >
> > The way it's implemented, it probably means the device
> > should not use any of skb_clone, expand head etc.
>
> Agree. Or maybe force a copy when device uses skb_clone, expand
> head ...?
>
> Thanks
> Shirley
Copy from userspace upfront without locking is probably cheaper?
--
MST
^ permalink raw reply
* Re: [PATCH] ipheth.c: Enable IP header alignment
From: David Miller @ 2011-05-02 19:46 UTC (permalink / raw)
To: agimenez
Cc: linux-kernel, dgiagio, dborca, pmcenery, david.hill, linux-usb,
netdev
In-Reply-To: <1304364912-15444-1-git-send-email-agimenez@sysvalve.es>
From: L. Alberto Giménez <agimenez@sysvalve.es>
Date: Mon, 2 May 2011 21:35:12 +0200
> Since commit ea812ca1b06113597adcd8e70c0f84a413d97544 (x86: Align skb w/ start
> of cacheline on newer core 2/Xeon Arch), NET_IP_ALIGN changed from 2 to 0, and
> the constant is used to reserve more room for the socket buffer.
>
> Some people have reported that tethering stopped working and David Hill
> submited a patch that redefined NET_IP_ALIGN. Pointed by Ben Hutchings, the
> patch has been reworked to use a private constant.
>
> I have no more an iPhone device to test it, so it is only compile-tested.
>
> Signed-off-by: L. Alberto Giménez <agimenez@sysvalve.es>
Why did this break things?
I'm not applying a fix when nobody can explain the reason why:
1) Things broke in the first place
2) Forcing reservation of 2 bytes fixes things
Where is the built in assumption about "2" and why does it exist? Why
can't we fix this code not to have such assumptions in the first
place?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox