* Re: eth1: Detected Hardware Unit Hang
From: Paweł Staszewski @ 2010-03-31 7:47 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Linux Network Development list, e1000-devel@lists.sourceforge.net
In-Reply-To: <4BB0E394.2060908@itcare.pl>
Hello
I reproduce this problem on other machine with the same hardware and
here is dmesg output: (kernel 2.6.33)
Mar 27 18:19:16 TM_01_C1 [1817894.769395] 0000:04:00.0: eth0: Detected
Hardware Unit Hang:
Mar 27 18:19:16 TM_01_C1 [1817894.769396] TDH <2e>
Mar 27 18:19:16 TM_01_C1 [1817894.769397] TDT <1a>
Mar 27 18:19:16 TM_01_C1 [1817894.769397] next_to_use <1a>
Mar 27 18:19:16 TM_01_C1 [1817894.769398] next_to_clean <2d>
Mar 27 18:19:16 TM_01_C1 [1817894.769398] buffer_info[next_to_clean]:
Mar 27 18:19:16 TM_01_C1 [1817894.769399] time_stamp <11b1591e9>
Mar 27 18:19:16 TM_01_C1 [1817894.769399] next_to_watch <2f>
Mar 27 18:19:16 TM_01_C1 [1817894.769400] jiffies <11b1592e4>
Mar 27 18:19:16 TM_01_C1 [1817894.769401] next_to_watch.status <0>
Mar 27 18:19:16 TM_01_C1 [1817894.769401] MAC Status <80080783>
Mar 27 18:19:16 TM_01_C1 [1817894.769402] PHY Status <796d>
Mar 27 18:19:16 TM_01_C1 [1817894.769402] PHY 1000BASE-T Status <3800>
Mar 27 18:19:16 TM_01_C1 [1817894.769403] PHY Extended Status <3000>
Mar 27 18:19:16 TM_01_C1 [1817894.769404] PCI Status <10>
Mar 27 18:19:18 TM_01_C1 [1817896.773365] 0000:04:00.0: eth0: Detected
Hardware Unit Hang:
Mar 27 18:19:18 TM_01_C1 [1817896.773367] TDH <2e>
Mar 27 18:19:18 TM_01_C1 [1817896.773368] TDT <1a>
Mar 27 18:19:18 TM_01_C1 [1817896.773368] next_to_use <1a>
Mar 27 18:19:18 TM_01_C1 [1817896.773369] next_to_clean <2d>
Mar 27 18:19:18 TM_01_C1 [1817896.773369] buffer_info[next_to_clean]:
Mar 27 18:19:18 TM_01_C1 [1817896.773370] time_stamp <11b1591e9>
Mar 27 18:19:18 TM_01_C1 [1817896.773370] next_to_watch <2f>
Mar 27 18:19:18 TM_01_C1 [1817896.773371] jiffies <11b1594d8>
Mar 27 18:19:18 TM_01_C1 [1817896.773372] next_to_watch.status <0>
Mar 27 18:19:18 TM_01_C1 [1817896.773372] MAC Status <80080783>
Mar 27 18:19:18 TM_01_C1 [1817896.773373] PHY Status <796d>
Mar 27 18:19:18 TM_01_C1 [1817896.773373] PHY 1000BASE-T Status <3800>
Mar 27 18:19:18 TM_01_C1 [1817896.773374] PHY Extended Status <3000>
Mar 27 18:19:18 TM_01_C1 [1817896.773375] PCI Status <10>
Mar 27 18:19:20 TM_01_C1 [1817898.769353] 0000:04:00.0: eth0: Detected
Hardware Unit Hang:
Mar 27 18:19:20 TM_01_C1 [1817898.769355] TDH <2e>
Mar 27 18:19:20 TM_01_C1 [1817898.769355] TDT <1a>
Mar 27 18:19:20 TM_01_C1 [1817898.769356] next_to_use <1a>
Mar 27 18:19:20 TM_01_C1 [1817898.769356] next_to_clean <2d>
Mar 27 18:19:20 TM_01_C1 [1817898.769357] buffer_info[next_to_clean]:
Mar 27 18:19:20 TM_01_C1 [1817898.769358] time_stamp <11b1591e9>
Mar 27 18:19:20 TM_01_C1 [1817898.769358] next_to_watch <2f>
Mar 27 18:19:20 TM_01_C1 [1817898.769359] jiffies <11b1596cc>
Mar 27 18:19:20 TM_01_C1 [1817898.769359] next_to_watch.status <0>
Mar 27 18:19:20 TM_01_C1 [1817898.769360] MAC Status <80080783>
Mar 27 18:19:20 TM_01_C1 [1817898.769361] PHY Status <796d>
Mar 27 18:19:20 TM_01_C1 [1817898.769361] PHY 1000BASE-T Status <3800>
Mar 27 18:19:20 TM_01_C1 [1817898.769362] PHY Extended Status <3000>
Mar 27 18:19:20 TM_01_C1 [1817898.769362] PCI Status <18>
Mar 27 18:19:21 TM_01_C1 [1817899.773012] ------------[ cut here
]------------
Mar 27 18:19:21 TM_01_C1 [1817899.773023] WARNING: at
net/sched/sch_generic.c:255 dev_watchdog+0x130/0x1d3()
Mar 27 18:19:21 TM_01_C1 [1817899.773026] Hardware name: X7DCT
Mar 27 18:19:21 TM_01_C1 [1817899.773028] NETDEV WATCHDOG: eth0
(e1000e): transmit queue 0 timed out
Mar 27 18:19:21 TM_01_C1 [1817899.773030] Modules linked in: coretemp
hwmon_vid hwmon [last unloaded: w83627hf]
Mar 27 18:19:21 TM_01_C1 [1817899.773038] Pid: 0, comm: swapper Not
tainted 2.6.33 #2
Mar 27 18:19:21 TM_01_C1 [1817899.773040] Call Trace:
Mar 27 18:19:21 TM_01_C1 [1817899.773042] <IRQ> [<ffffffff813003b3>] ?
dev_watchdog+0x130/0x1d3
Mar 27 18:19:21 TM_01_C1 [1817899.773050] [<ffffffff813003b3>] ?
dev_watchdog+0x130/0x1d3
Mar 27 18:19:21 TM_01_C1 [1817899.773055] [<ffffffff81032d1a>] ?
warn_slowpath_common+0x77/0xa3
Mar 27 18:19:21 TM_01_C1 [1817899.773059] [<ffffffff81032da2>] ?
warn_slowpath_fmt+0x51/0x59
Mar 27 18:19:21 TM_01_C1 [1817899.773064] [<ffffffff8102910c>] ?
enqueue_task_fair+0x3e/0xa1
Mar 27 18:19:21 TM_01_C1 [1817899.773068] [<ffffffff8102f0c2>] ?
try_to_wake_up+0x368/0x379
Mar 27 18:19:21 TM_01_C1 [1817899.773072] [<ffffffff812ee612>] ?
netdev_drivername+0x3b/0x40
Mar 27 18:19:21 TM_01_C1 [1817899.773075] [<ffffffff813003b3>] ?
dev_watchdog+0x130/0x1d3
Mar 27 18:19:21 TM_01_C1 [1817899.773079] [<ffffffff81026d60>] ?
__wake_up+0x30/0x44
Mar 27 18:19:21 TM_01_C1 [1817899.773082] [<ffffffff81300283>] ?
dev_watchdog+0x0/0x1d3
Mar 27 18:19:21 TM_01_C1 [1817899.773087] [<ffffffff8103f5d1>] ?
run_timer_softirq+0x200/0x29e
Mar 27 18:19:21 TM_01_C1 [1817899.773091] [<ffffffff810386f6>] ?
__do_softirq+0xd7/0x195
Mar 27 18:19:21 TM_01_C1 [1817899.773099] [<ffffffff810152b3>] ?
lapic_next_event+0x18/0x1d
Mar 27 18:19:21 TM_01_C1 [1817899.773104] [<ffffffff81002e0c>] ?
call_softirq+0x1c/0x28
Mar 27 18:19:21 TM_01_C1 [1817899.773107] [<ffffffff81004811>] ?
do_softirq+0x31/0x63
Mar 27 18:19:21 TM_01_C1 [1817899.773110] [<ffffffff810384eb>] ?
irq_exit+0x36/0x78
Mar 27 18:19:21 TM_01_C1 [1817899.773113] [<ffffffff81015d0b>] ?
smp_apic_timer_interrupt+0x87/0x95
Mar 27 18:19:21 TM_01_C1 [1817899.773117] [<ffffffff810028d3>] ?
apic_timer_interrupt+0x13/0x20
Mar 27 18:19:21 TM_01_C1 [1817899.773119] <EOI> [<ffffffff81008bdd>] ?
mwait_idle+0x9b/0xa0
Mar 27 18:19:21 TM_01_C1 [1817899.773126] [<ffffffff81001385>] ?
cpu_idle+0x53/0x8b
Mar 27 18:19:21 TM_01_C1 [1817899.773128] ---[ end trace
4ac842842c6f54b3 ]---
ethtool -i eth0
driver: e1000e
version: 1.0.2-k2
firmware-version: 0.15-5
bus-info: 0000:04:00.0
NIC statistics:
rx_packets: 8202754725
tx_packets: 7398272195
rx_bytes: 4373145698252
tx_bytes: 5234354904619
rx_broadcast: 59775
tx_broadcast: 405
rx_multicast: 0
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 1185
rx_missed_errors: 1466
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 12
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 4373145698252
rx_csum_offload_good: 8084424290
rx_csum_offload_errors: 5690
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 48588
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
Wnen this occured traffic was about - RX: 360Mbit/s and TX: 340Mbit -
for eth0 interface.
W dniu 2010-03-29 19:29, Paweł Staszewski pisze:
> lspci -vvv + ethtool -S in attached files.
>
> Network traffic when i get this info:
> eth1: RX: 157.22 Mb/s TX: 379.27 Mb/s
>
> ethtool -i eth1
> driver: e1000e
> version: 1.0.2-k2
> firmware-version: 0.5-7
> bus-info: 0000:05:00.0
> This is: Intel Corporation 82573L Gigabit Ethernet Controller
>
>
> But in this server i have another gigabit interface:
> Intel Corporation 82573E Gigabit Ethernet Controller
> this interface has two times more traffic than eth0 (82573L)
> ethtool -i eth0
> driver: e1000e
> version: 1.0.2-k2
> firmware-version: 0.15-5
> bus-info: 0000:04:00.0
>
> And also this server was working 4months without problems on 2.6.29.1
> kernel
>
> Drivers that I use for e1000e are from kernel (standard kernel
> build-in e1000e driver).
> I don't tried other drivers.
>
> This is production server so I can't make too much tests.
>
>
> W dniu 2010-03-29 18:41, Allan, Bruce W pisze:
>> [adding e1000-devel]
>>
>> Please provide more information:
>> * what NIC/LOM is this on (preferably send full output from lspci -vvv)
>> * what type of networking workload is running at the time the hang
>> occurred
>> * a dump of the NIC/LOM statistics might also help (ethtool -S eth1)
>>
>> Have you tried the latest standalone e1000e driver on e1000.sf.net?
>> Does it reproduce the issue?
>>
>> If we cannot reproduce the hang in-house, would you be able/willing
>> to run a debug driver to gather more information?
>>
>> Thanks,
>> Bruce.
>>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org
>> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Pawel Staszewski
>> Sent: Monday, March 29, 2010 8:34 AM
>> To: Linux Network Development list
>> Subject: eth1: Detected Hardware Unit Hang
>>
>> After update to kernel from 2.6.29.1 to 2.6.33.1 i have this info in
>> dmesg:
>>
>> 0000:05:00.0: eth1: Detected Hardware Unit Hang:
>> TDH<1e>
>> TDT<a>
>> next_to_use<a>
>> next_to_clean<1d>
>> buffer_info[next_to_clean]:
>> time_stamp<33bae15>
>> next_to_watch<20>
>> jiffies<33bafaf>
>> next_to_watch.status<0>
>> MAC Status<80080783>
>> PHY Status<796d>
>> PHY 1000BASE-T Status<3800>
>> PHY Extended Status<3000>
>> PCI Status<10>
>> 0000:05:00.0: eth1: Detected Hardware Unit Hang:
>> TDH<1e>
>> TDT<a>
>> next_to_use<a>
>> next_to_clean<1d>
>> buffer_info[next_to_clean]:
>> time_stamp<33bae15>
>> next_to_watch<20>
>> jiffies<33bb1a3>
>> next_to_watch.status<0>
>> MAC Status<80080783>
>> PHY Status<796d>
>> PHY 1000BASE-T Status<3800>
>> PHY Extended Status<3000>
>> PCI Status<10>
>> 0000:05:00.0: eth1: Detected Hardware Unit Hang:
>> TDH<1e>
>> TDT<a>
>> next_to_use<a>
>> next_to_clean<1d>
>> buffer_info[next_to_clean]:
>> time_stamp<33bae15>
>> next_to_watch<20>
>> jiffies<33bb397>
>> next_to_watch.status<0>
>> MAC Status<80080783>
>> PHY Status<796d>
>> PHY 1000BASE-T Status<3800>
>> PHY Extended Status<3000>
>> PCI Status<10>
>> ------------[ cut here ]------------
>> WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x118/0x19c()
>> Hardware name: X7DCT
>> NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
>> Modules linked in:
>> Pid: 0, comm: swapper Not tainted 2.6.33.1 #2
>> Call Trace:
>> [<c1024e3d>] ? warn_slowpath_common+0x52/0x71
>> [<c1024e49>] ? warn_slowpath_common+0x5e/0x71
>> [<c1024e8e>] ? warn_slowpath_fmt+0x26/0x2a
>> [<c1261f54>] ? dev_watchdog+0x118/0x19c
>> [<c102135c>] ? __wake_up+0x29/0x39
>> [<c10320c6>] ? insert_work+0x40/0x44
>> [<c1261e3c>] ? dev_watchdog+0x0/0x19c
>> [<c102cc15>] ? run_timer_softirq+0x11a/0x173
>> [<c1028e5b>] ? __do_softirq+0x74/0xdf
>> [<c1028ee9>] ? do_softirq+0x23/0x27
>> [<c10290be>] ? irq_exit+0x26/0x58
>> [<c10102d7>] ? smp_apic_timer_interrupt+0x6c/0x76
>> [<c12c5f9a>] ? apic_timer_interrupt+0x2a/0x30
>> [<c1007e06>] ? mwait_idle+0x49/0x4e
>> [<c10017e8>] ? cpu_idle+0x41/0x5a
>> ---[ end trace bcca9926a046332c ]---
>>
>>
>> With kernel 2.6.29.1 all was ok.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 04/12] l2tp: Add ppp device name to L2TP ppp session data
From: James Chapman @ 2010-03-31 7:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20100330092914.4f3e9ed3@nehalam>
Stephen Hemminger wrote:
> On Tue, 30 Mar 2010 17:17:46 +0100
> James Chapman <jchapman@katalix.com> wrote:
>
>> When dumping L2TP PPP sessions using /proc/net/l2tp, get
>> the assigned PPP device name from PPP using ppp_dev_name().
>>
>> Signed-off-by: James Chapman <jchapman@katalix.com>
>> Reviewed-by: Randy Dunlap <randy.dunlap@oracle.com>
>>
>
> Why is this a necessary API?
> Why not put it in debugfs if just a debugging tool?
With the original driver (merged in 2.6.23), some people use horrible
hacks in scripts to derive info about their L2TP connections from /proc.
So I was reluctant to move it to debugfs in the new driver. If it is ok
to move an existing /proc file to debugfs, I'm happy to do so. People
should obtain such info from their L2TP userspace daemon, or through
netlink anyway.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support.
From: Eric W. Biederman @ 2010-03-31 7:43 UTC (permalink / raw)
To: Tejun Heo
Cc: Greg Kroah-Hartman, Kay Sievers, linux-kernel, Cornelia Huck,
linux-fsdevel, Eric Dumazet, Benjamin LaHaise, Serge Hallyn,
netdev, Benjamin Thery
In-Reply-To: <4BB2F083.1050803@kernel.org>
Tejun Heo <tj@kernel.org> writes:
> Hello, Eric.
>
> On 03/31/2010 03:31 AM, Eric W. Biederman wrote:
>> What this patch does is to add an additional tag field to the
>> sysfs dirent structure. For directories that should show different
>> contents depending on the context such as /sys/class/net/, and
>> /sys/devices/virtual/net/ this tag field is used to specify the
>> context in which those directories should be visible. Effectively
>> this is the same as creating multiple distinct directories with
>> the same name but internally to sysfs the result is nicer.
>
> This has become a long running project. :-)
>
> The way to implement partial visibility seems much cleaner now and I
> don't have any objection. Thanks for cleaning up the whole sysfs and
> implementing this properly. Unfortunately, I still feel quite
> uncomfortable about how the scope of visibility is determined and how
> deep knowledge about specific namespace implementation seeps down to
> kobject / sysfs layer. It almost looks like a gross layering
> violation.
The problem is how sysfs and the kobject layer expose things to
userspace. Maintaining backwards compatibility to userspace in sysfs
while making changes in the rest of the kernel is hard.
Having been through the rest of the kernel and changed every other
significant interface I think I can say that without bias.
> Is it at all possible to implement it in properly layered manner?
> ie. sysfs providing mechanisms for selective visibility, driver model
> wraps it and exports it and namespace implements namespaces on top of
> those mechanisms?
I think that is roughly what I have.
> I can see that there should be some interaction
> between the driver model and namespaces but I can't see why that
> information should be visible deep down in kobject and sysfs.
At this point you seem to be asking for perfection instead of something
that is merely good enough. I am open to suggestions for something
better but overall the code is as good as I can get it. The code
does not impose any real maintenance problems. The code does not
impose any real performance problems. The code works. It is time to
use this stuff, and stop keeping devices out of the kobject layer
because sysfs and the kobject layer can not cope with the reality
of the rest of the kernel.
As for the layering itself. Down in sysfs there are only two bits
visible. A void * pointer that in addition to the name is what we use
to define selective visibility. A context that we capture when we
mount sysfs. Those bits are fundamental things sysfs needs to do.
Capturing the namespaces of interest when mounting sysfs allows us to
display with different mounts of sysfs what a single mount of sysfs
can not show.
Eric
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: use NAPI for xmit (UNTESTED)
From: Shirley Ma @ 2010-03-31 7:13 UTC (permalink / raw)
To: Rusty Russell; +Cc: Michael S. Tsirkin, netdev, Herbert Xu
In-Reply-To: <201003311429.57793.rusty@rustcorp.com.au>
On Wed, 2010-03-31 at 14:29 +1030, Rusty Russell wrote:
> +static int virtnet_xmit_poll(struct napi_struct *xmit_napi, int
> budget)
> +{
> + struct virtnet_info *vi =
> + container_of(xmit_napi, struct virtnet_info,
> xmit_napi);
> +
> + /* Don't access vq/capacity at same time as start_xmit. */
> + __netif_tx_lock(netdev_get_tx_queue(vi->dev, 0),
> smp_processor_id());
> +
> + vi->capacity += free_old_xmit_skbs(vi);
> + if (vi->capacity >= 2 + MAX_SKB_FRAGS) {
> + /* Suppress further xmit interrupts. */
> + vi->svq->vq_ops->disable_cb(vi->svq);
> + napi_complete(xmit_napi);
> +
> + /* Don't wake it if link is down. */
> + if (likely(netif_carrier_ok(vi->vdev)))
This should be if (likely(netif_carrier_ok(vi->dev)))
> + netif_wake_queue(vi->dev);
> + }
> +
> + __netif_tx_unlock(netdev_get_tx_queue(vi->dev, 0));
> + return 1;
> +}
> +
I tested the backport patch with vhost on, the initial netperf test
result showed BW performance decreased 10% with same cpu utilization. I
will look at it tomorrow.
Shirley
^ permalink raw reply
* Re: [PATCH] net/pcmcia 3com: replacements of printk() with dev_info() and friends (fwd)
From: Dominik Brodowski @ 2010-03-31 7:05 UTC (permalink / raw)
To: Alexander Kurz
Cc: David S. Miller, Ken Kawasaki, Magnus Damm, Ben Hutchings, netdev,
linux-kernel
In-Reply-To: <alpine.DEB.1.10.1003302019200.11637@blala.de>
Hey,
On Tue, Mar 30, 2010 at 09:01:41PM +0400, Alexander Kurz wrote:
> I wrote a patch as suggested by kernel-janitors.
> It is my first patch, so I highly welcome comments and hints,
> thanks, Alexander Kurz
>
> ---------- Forwarded message ----------
> Date: Tue, 30 Mar 2010 18:55:33 +0400 (MSD)
> From: Alexander Kurz <akurz@blala.de>
> To: kernel-janitors@vger.kernel.org
> Subject: [PATCH] net/pcmcia 3com: replacements of printk() with dev_info()
> and
> friends
>
> Hello List,
> I wrote a patch replacing some printk() with dev_info() and friends
> for 3com 16-bit PCMCIA cards.
> As this is my first linux patch, comments are welcome,
> thanks, Alexander Kurz
>
> ---------- Forwarded message ----------
> Date: Tue, 30 Mar 2010 18:51:43 +0400
> From: Alexander Kurz <akurz@blala.de>
> To: akurz@blala.de
>
> >From 84616314b126b730528ca10e704d80eabad96ff8 Mon Sep 17 00:00:00 2001
> From: Alexander Kurz <akurz@kbdbabel.org>
> Date: Tue, 30 Mar 2010 12:08:54 +0200
> Subject: [PATCH] net/pcmcia 3com: replacements of printk() with dev_info()
> and friends
> as suggested by kernel-janitors for 3com 16-bit PCMCIA cards
that's two "forwarded message" messages too much :) Other than that, the
only issue I see is that there's a "Signed-off-by"-Line missing. See
Documentation/SubmittingPatches for details.
Best,
Dominik
^ permalink raw reply
* Re: [PATCH 1/1] fix net/core/dst.c coding style error and warnings
From: David Miller @ 2010-03-31 6:59 UTC (permalink / raw)
To: chavey; +Cc: netdev, therbert
In-Reply-To: <pvmzl1qoo73.fsf@chavey.mtv.corp.google.com>
From: chavey@google.com
Date: Mon, 29 Mar 2010 13:41:36 -0700
> Fix coding style errors and warnings output while running checkpatch.pl
> on the file net/core/dst.c.
>
> Signed-off-by: chavey <chavey@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: remove redundant code
From: David Miller @ 2010-03-31 6:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1269961335.2012.66.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 30 Mar 2010 17:02:15 +0200
> eth_type_trans(skb, netdev) does the "skb->dev = netdev;"
> initialization, we can remove it from various network drivers.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] tipc: define needless global scoped variable static
From: David Miller @ 2010-03-31 6:57 UTC (permalink / raw)
To: hagen; +Cc: netdev, per.liden
In-Reply-To: <1269995052-10905-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Wed, 31 Mar 2010 02:24:12 +0200
> struct _zone *tipc_zones has local scope level and
> should defined with the correct scoping.
>
> CC: Per Liden <per.liden@nospam.ericsson.com>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: eliminate useless code
From: David Miller @ 2010-03-31 6:57 UTC (permalink / raw)
To: hagen; +Cc: netdev, vladislav.yasevich
In-Reply-To: <1269995097-11206-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Wed, 31 Mar 2010 02:24:57 +0200
> Remove duplicate declaration of symbol: struct hlist_node *node was
> already declared, the seconds declaration shadows the first one.
>
> CC: Vlad Yasevich <vladislav.yasevich@hp.com>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCH] skb_put: remove not needed check for skb linearity
From: David Miller @ 2010-03-31 6:55 UTC (permalink / raw)
To: paulius.zaleckas; +Cc: netdev
In-Reply-To: <20100330130131.8432.43671.stgit@pauliusz>
From: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Date: Tue, 30 Mar 2010 16:01:31 +0300
> It is safe to call skb_put() on packets containing fragments.
>
> Actually I have a case where I allocate packet header with some
> extra headroom and then I dynamically add data as frag_list. After
> adding frags I have to add more data to header and skb_put()
> just BUG's on me :)
>
> And we will save couple instructions for CPU.
>
> Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
No, you really cannot do this, that check is very much intentional and
needs to be there. Otherwise we will allow violations of the
semantics of the SKB data area.
Once you put even one byte of non-linear data into the skb, all data
must be "put" to the end of that non-linear area, without exception.
You can't just stuff arbitrary things "in-between" the linear and the
non-linear stuff.
You'll need to find a way to construct your SKBs properly such that
the entirety of the linear area is constructed before you start
adding non-linear elements.
^ permalink raw reply
* Re: [PATCH 0/6] tagged sysfs support
From: Eric W. Biederman @ 2010-03-31 6:52 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg Kroah-Hartman, Greg KH, linux-kernel, Tejun Heo,
Cornelia Huck, linux-fsdevel, Eric Dumazet, Benjamin LaHaise,
Serge Hallyn, netdev
In-Reply-To: <s2hac3eb2511003302251rcbae8767ne21e9daf1546c849@mail.gmail.com>
Kay Sievers <kay.sievers@vrfy.org> writes:
> On Wed, Mar 31, 2010 at 01:04, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> Kay Sievers <kay.sievers@vrfy.org> writes:
>
> Yeah, /sys/bus/, which is the only sane layout of the needlessly
> different 3 versions of the same thing (bus, class, block).
>
> /sys/bus/<subsys> can just be a plain symlinks to the
> /sys/subsystem/<subsys> directories.
>
> /sys/class/<subsys> *could* be a symlink to the
> /sys/subsystem/<subsys>/devices/ directory, but we really don't want
> to continue to stupidly mix subsystem-wide control files with device
> lists anymore. The "devices" directory needs to be a strict list of
> devices, not some collection of random stuff, that it is today. :)
>
> So we either leave all the conceptually broken class attributes behind
> us, and put them at the /sys/subsystem/<subsys>/ level only, or we
> need to create the /sys/class/<subsys>/* stuff all as symlinks like we
> do today. I expect, we have to create /sys/class as we do today.
Ideally we will keep new subsystem attributes from creeping into
/sys/class/xxxx/ directories.
> Another problem to solve is that sysfs does not allow us to symlink
> regular files, only directories, so we can currently not create the
> class-wide attributes as symlinks to the proper file in
> /sys/subsystem/.
That seems to be part of the everything is a kobject interface, and
all kobjects are directories. I don't think supporting the symlinks
will be particularly hard, although there are issues to consider with
respect to making the symlinks come and go when the attributes do.
>>
>> I'm not entirely clear on what you are doing but it all sounds like it
>> will fit within what I am doing.
>
> The goal is to unify the 3 needlessly different versions of "device
> lists of the same subsystem". We have /sys/class, /sys/bus,
> /sys/block, and all of them will be unified at /sys/subsystem/ leaving
> the old names as compat links only. Unlike block and class, the
> /sys/subsystem/<subsys> directory can be extended with custom
> subdirectories and files, without mixing random files into device
> lists.
That makes sense. I took a quick look and /sys/block is already
a compatibility define. So I don't expect any issues there.
At a practical level there don't appear to be too many class attributes
that will cause problems, but even a couple are enough to be a pain.
> Yeah, it did not makes sense it the first place to mix devices lists
> with global attributes. It's a real mess what people do in sysfs.
I was very disappointed in sysfs the first time I saw someone add writable
attributes. But sysfs is here now.
Eric
^ permalink raw reply
* Re: [PATCH 1/2] netdev: ethtool RXHASH flag
From: David Miller @ 2010-03-31 6:52 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100329174727.4654e19c@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 29 Mar 2010 17:47:27 -0700
> This adds ethtool and device feature flag to allow control
> of receive hashing offload.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> ---
> Supersedes earlier patch, decided to call it RXHASH not RSS since
> we don't care about other vendors acronyms
Ah, now I understand, ignore my other email.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/2] netdev: add support for Receive Side Scaling hash control
From: David Miller @ 2010-03-31 6:52 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100328154448.701c89ee@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sun, 28 Mar 2010 15:44:48 -0700
> This adds ethtool and device feature flag to allow control
> of Receive Side Scaling hashing supported by many modern
> controllers.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> ---
> I am working on RSS for sky2 device, but the hardware isn't fully cooperating
> but thought others might want to use same API.
I assume you didn't intend this to be applied because it uses
the same value as you choose for RXHASH.
If you want this applied, resubmit against your RXHASH changes.
Thanks!
^ permalink raw reply
* Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support.
From: Tejun Heo @ 2010-03-31 6:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg Kroah-Hartman, Kay Sievers, linux-kernel, Cornelia Huck,
linux-fsdevel, Eric Dumazet, Benjamin LaHaise, Serge Hallyn,
netdev, Benjamin Thery
In-Reply-To: <1269973889-25260-3-git-send-email-ebiederm@xmission.com>
Hello, Eric.
On 03/31/2010 03:31 AM, Eric W. Biederman wrote:
> What this patch does is to add an additional tag field to the
> sysfs dirent structure. For directories that should show different
> contents depending on the context such as /sys/class/net/, and
> /sys/devices/virtual/net/ this tag field is used to specify the
> context in which those directories should be visible. Effectively
> this is the same as creating multiple distinct directories with
> the same name but internally to sysfs the result is nicer.
This has become a long running project. :-)
The way to implement partial visibility seems much cleaner now and I
don't have any objection. Thanks for cleaning up the whole sysfs and
implementing this properly. Unfortunately, I still feel quite
uncomfortable about how the scope of visibility is determined and how
deep knowledge about specific namespace implementation seeps down to
kobject / sysfs layer. It almost looks like a gross layering
violation.
Is it at all possible to implement it in properly layered manner?
ie. sysfs providing mechanisms for selective visibility, driver model
wraps it and exports it and namespace implements namespaces on top of
those mechanisms? I can see that there should be some interaction
between the driver model and namespaces but I can't see why that
information should be visible deep down in kobject and sysfs.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module
From: David Miller @ 2010-03-31 6:46 UTC (permalink / raw)
To: wg; +Cc: iws, linux-kernel, socketcan-core, netdev, sameo
In-Reply-To: <4BB1B2DA.60002@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Tue, 30 Mar 2010 10:14:18 +0200
> Ira W. Snyder wrote:
>> The Janz VMOD-ICAN3 is a MODULbus daughterboard which fits onto any
>> MODULbus carrier board. It is an intelligent CAN controller with a
>> microcontroller and associated firmware.
>>
>> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Since this driver depends upon the MFD stuff and that goes
through other maintainers, just toss this CAN driver in
via whatever tree the MFD thing goes through and add my:
Acked-by: David S. Miller <davem@davemloft.net>
Thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: add per-packet timestamping
From: David Miller @ 2010-03-31 6:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, nicholasx.d.nunley
In-Reply-To: <20100326213545.19028.21468.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 26 Mar 2010 14:36:47 -0700
> From: Nick Nunley <nicholasx.d.nunley@intel.com>
>
> This patch adds support for per-packet timestamping for the
> 82580 adapter. The rx timestamp code is also pulled out of the
> inlined rx hotpath and instead moved to a seperate function.
>
> This version adds a comment explaining the per-packet timestamping
> code added to igb_hwtstamp_ioctl().
>
> Signed-off-by: Nicholas Nunley <nicholasx.d.nunley@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next trivial] MAINTAINERS: ipg: Jesse Huang's email address bounces
From: David Miller @ 2010-03-31 6:42 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <1269801736.1500.36.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Sun, 28 Mar 2010 11:42:16 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next trivial] drivers/net/ipg: Remove invalid IPG_DDEBUG_MSG uses, neaten
From: David Miller @ 2010-03-31 6:42 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, jesse, netdev, linux-kernel
In-Reply-To: <1269801345.1500.32.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Sun, 28 Mar 2010 11:35:45 -0700
> Some no longer valid IPG_DDEBUG_MSG uses are removed
> Validate IPG_DDEBUG_MSG arguments when not #defined
> Neaten #defines
> marco/macro typo correction
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 (TAKE 2)] ipv6: Use __fls() instead of fls() in __ipv6_addr_diff().
From: David Miller @ 2010-03-31 6:40 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <201003291600.o2TG05VI032167@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 30 Mar 2010 01:00:05 +0900
> Because we have ensured that the argument is non-zero,
> it is better to use __fls() and generate better code.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6 fib: Use "Sweezle" to optimize addr_bit_test().
From: David Miller @ 2010-03-31 6:40 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <201003271124.o2RBOGjT006944@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sat, 27 Mar 2010 20:24:16 +0900
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] sctp: Use ipv6_addr_diff() in sctp_v6_addr_match_len().
From: David Miller @ 2010-03-31 6:40 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <201003261834.o2QIYUhQ009920@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sat, 27 Mar 2010 03:34:30 +0900
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ipv6 mcast: Introduce include/net/mld.h for MLD definitions.
From: David Miller @ 2010-03-31 6:27 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20100330.232344.177012600.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 30 Mar 2010 23:23:44 -0700 (PDT)
> From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Mon, 29 Mar 2010 20:01:22 +0900
>
>> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> Applied, thanks.
Nevermind, reverted, breaks the build:
net/ipv6/mcast.c: In function ‘igmp6_event_query’:
net/ipv6/mcast.c:1134: error: implicit declaration of function ‘mld_msg’
net/ipv6/mcast.c:1134: warning: assignment makes pointer from integer without a cast
net/ipv6/mcast.c: In function ‘igmp6_event_report’:
net/ipv6/mcast.c:1254: warning: assignment makes pointer from integer without a cast
make[2]: *** [net/ipv6/mcast.o] Error 1
make[1]: *** [net/ipv6] Error 2
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
CC [M] drivers/net/e1000e/lib.o
LD [M] drivers/net/e1000e/e1000e.o
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/3] bridge br_multicast: Make functions less ipv4 dependent.
From: David Miller @ 2010-03-31 6:24 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, shemminger
In-Reply-To: <201003291101.o2TB1R0W006599@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Mon, 29 Mar 2010 20:01:27 +0900
> Introduce struct br_ip{} to store ip address and protocol
> and make functions more generic so that we can support
> both IPv4 and IPv6 with less pain.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Stephen said he would clean up the macros and he seemed to imply
therefore that he'd resubmit these, so I'll leave patches #2 and #3 to
him.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ipv6 mcast: Introduce include/net/mld.h for MLD definitions.
From: David Miller @ 2010-03-31 6:23 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <201003291101.o2TB1MWQ006587@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Mon, 29 Mar 2010 20:01:22 +0900
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] rps: keep the old behavior on SMP without rps
From: Changli Gao @ 2010-03-31 6:16 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, xiaosuo
keep the old behavior on SMP without rps
RPS introduces a lock operation to per cpu variable input_pkt_queue on
SMP whenever rps is enabled or not. On SMP without RPS, this lock isn't
needed at all.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/core/dev.c | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3e7fa16..d154f3b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -207,6 +207,20 @@ static inline struct hlist_head *dev_index_hash(struct net *net, int ifindex)
return &net->dev_index_head[ifindex & (NETDEV_HASHENTRIES - 1)];
}
+static inline void rps_lock(struct softnet_data *queue)
+{
+#ifdef CONFIG_RPS
+ spin_lock(&queue->input_pkt_queue.lock);
+#endif
+}
+
+static inline void rps_unlock(struct softnet_data *queue)
+{
+#ifdef CONFIG_RPS
+ spin_unlock(&queue->input_pkt_queue.lock);
+#endif
+}
+
/* Device list insertion */
static int list_netdevice(struct net_device *dev)
{
@@ -2314,13 +2328,13 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu)
local_irq_save(flags);
__get_cpu_var(netdev_rx_stat).total++;
- spin_lock(&queue->input_pkt_queue.lock);
+ rps_lock(queue);
if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
if (queue->input_pkt_queue.qlen) {
enqueue:
__skb_queue_tail(&queue->input_pkt_queue, skb);
- spin_unlock_irqrestore(&queue->input_pkt_queue.lock,
- flags);
+ rps_unlock(queue);
+ local_irq_restore(flags);
return NET_RX_SUCCESS;
}
@@ -2342,7 +2356,7 @@ enqueue:
goto enqueue;
}
- spin_unlock(&queue->input_pkt_queue.lock);
+ rps_unlock(queue);
__get_cpu_var(netdev_rx_stat).dropped++;
local_irq_restore(flags);
@@ -2767,19 +2781,19 @@ int netif_receive_skb(struct sk_buff *skb)
EXPORT_SYMBOL(netif_receive_skb);
/* Network device is going away, flush any packets still pending */
-static void flush_backlog(struct net_device *dev, int cpu)
+static void flush_backlog(void *arg)
{
- struct softnet_data *queue = &per_cpu(softnet_data, cpu);
+ struct net_device *dev = arg;
+ struct softnet_data *queue = &__get_cpu_var(softnet_data);
struct sk_buff *skb, *tmp;
- unsigned long flags;
- spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
+ rps_lock(queue);
skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
if (skb->dev == dev) {
__skb_unlink(skb, &queue->input_pkt_queue);
kfree_skb(skb);
}
- spin_unlock_irqrestore(&queue->input_pkt_queue.lock, flags);
+ rps_unlock(queue);
}
static int napi_gro_complete(struct sk_buff *skb)
@@ -3092,14 +3106,16 @@ static int process_backlog(struct napi_struct *napi, int quota)
do {
struct sk_buff *skb;
- spin_lock_irq(&queue->input_pkt_queue.lock);
+ local_irq_disable();
+ rps_lock(queue);
skb = __skb_dequeue(&queue->input_pkt_queue);
if (!skb) {
__napi_complete(napi);
spin_unlock_irq(&queue->input_pkt_queue.lock);
break;
}
- spin_unlock_irq(&queue->input_pkt_queue.lock);
+ rps_unlock(queue);
+ local_irq_enable();
__netif_receive_skb(skb);
} while (++work < quota && jiffies == start_time);
@@ -5549,7 +5565,6 @@ void netdev_run_todo(void)
while (!list_empty(&list)) {
struct net_device *dev
= list_first_entry(&list, struct net_device, todo_list);
- int i;
list_del(&dev->todo_list);
if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
@@ -5561,8 +5576,7 @@ void netdev_run_todo(void)
dev->reg_state = NETREG_UNREGISTERED;
- for_each_online_cpu(i)
- flush_backlog(dev, i);
+ on_each_cpu(flush_backlog, dev, 1);
netdev_wait_allrefs(dev);
^ permalink raw reply related
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