* 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 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 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 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] 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] 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] 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 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 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/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 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 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 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: 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
* [PATCH] MACB: Set PHY address in kernel parameters
From: Anders Darander @ 2010-03-31 7:51 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: David S. Miller, Jiri Pirko, Erik Waling, Patrick McHardy,
Anders Darander, Grant Likely, netdev, linux-kernel
From: Anders Darander <ad@datarespons.se>
Add the possibility to set the phy address. This is needed if an integrated
switch is connected to the MAC, as it is often the case that the highest port
is the one connected to the MAC of the MCU.
E.g. in the case of the Micrel KSZ8873, port 3 is the one to connect to the
MCU, thus, the MAC needs to connect to phy address 0x03, instead of the first
phy found.
Signed-off-by: Anders Darander <ad@datarespons.se>
---
drivers/net/macb.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c8a18a6..9b4e301 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -53,6 +53,14 @@
#define MACB_RX_INT_FLAGS (MACB_BIT(RCOMP) | MACB_BIT(RXUBR) \
| MACB_BIT(ISR_ROVR))
+/*
+ * Setup PHY probeing
+ */
+
+static int phy_addr = PHY_MAX_ADDR;
+module_param(phy_addr, ushort, 0);
+MODULE_PARAM_DESC(phy_addr, "PHY address connected to the MACB");
+
static void __macb_set_hwaddr(struct macb *bp)
{
u32 bottom;
@@ -193,7 +201,11 @@ static int macb_mii_probe(struct net_device *dev)
struct eth_platform_data *pdata;
int ret;
- phydev = phy_find_first(bp->mii_bus);
+ if (phy_addr >= PHY_MAX_ADDRESS)
+ phydev = phy_find_first(bp->mii_bus);
+ else
+ phydev = bp->mii_bus->phy_map[phy_addr];
+
if (!phydev) {
printk (KERN_ERR "%s: no PHY found\n", dev->name);
return -1;
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Sascha Hauer @ 2010-03-31 7:57 UTC (permalink / raw)
To: Bryan Wu
Cc: gerg, amit.kucheria, kernel-team, netdev, linux-kernel,
linux-arm-kernel, w.sang
In-Reply-To: <1269597052-10104-1-git-send-email-bryan.wu@canonical.com>
On Fri, Mar 26, 2010 at 05:50:52PM +0800, Bryan Wu wrote:
> BugLink: http://bugs.launchpad.net/bugs/457878
>
> - removed old MII phy control code
> - add phylib supporting
> - add ethtool interface to make user space NetworkManager works
>
> Tested on Freescale i.MX51 Babbage board.
>
> This patch is based on a patch from Frederic Rodo <fred.rodo@gmail.com>
>
Hi Bryan,
The MII speed is calculated twice with this patch applied, one time
in fec_enet_mii_init and one time in fec_enet_init.
The patch didn't work for me because the calculation is wrong (which of
course is not your fault, it was wrong before).
According to the Datasheet the MII clock is clk_get_rate() / (MII * 2).
When we want to have a clock of 2.5MHz we have to do:
clk_get_rate() / 5000000
With rounding this would be:
(clk_get_rate() + 4999999) / 5000000
So you might want to add the following to your patch:
fep->phy_speed = ((clk_get_rate(fep->clk) + 4999999) / 5000000) << 1;
Otherwise the patch looks good to me.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* iproute2: silence errors about kernel missing 6rd on "ip tun show".
From: Andreas Henriksson @ 2010-03-31 8:08 UTC (permalink / raw)
To: shemminger, Alexandre Cassen; +Cc: 575970, netdev
Hello!
As reported in http://bugs.debian.org/575970 there is currently a warning
printed for every tunnel when using latest iproute2 on atleast <= 2.6.32
kernels (missing 6rd?!).
The attached patch avoids perror when errno is EINVAL, which I assume
is the way to detect missing 6rd support. A better/cleaner
method to detect and avoid 6rd when there's no kernel support
is more then welcome.
Regards,
Andreas Henriksson
diff --git a/ip/tunnel.c b/ip/tunnel.c
index d389e86..bbb60bf 100644
--- a/ip/tunnel.c
+++ b/ip/tunnel.c
@@ -29,6 +29,7 @@
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#include <errno.h>
#include <netinet/in.h>
#include <linux/if.h>
#include <linux/ip.h>
@@ -168,7 +169,7 @@ int tnl_del_ioctl(const char *basedev, const char *name, void *p)
return err;
}
-static int tnl_gen_ioctl(int cmd, const char *name, void *p)
+static int tnl_gen_ioctl(int cmd, const char *name, void *p, int quiet)
{
struct ifreq ifr;
int fd;
@@ -178,7 +179,7 @@ static int tnl_gen_ioctl(int cmd, const char *name, void *p)
ifr.ifr_ifru.ifru_data = p;
fd = socket(preferred_family, SOCK_DGRAM, 0);
err = ioctl(fd, cmd, &ifr);
- if (err)
+ if (err && !quiet)
perror("ioctl");
close(fd);
return err;
@@ -186,15 +187,18 @@ static int tnl_gen_ioctl(int cmd, const char *name, void *p)
int tnl_prl_ioctl(int cmd, const char *name, void *p)
{
- return tnl_gen_ioctl(cmd, name, p);
+ return tnl_gen_ioctl(cmd, name, p, 0);
}
int tnl_6rd_ioctl(int cmd, const char *name, void *p)
{
- return tnl_gen_ioctl(cmd, name, p);
+ return tnl_gen_ioctl(cmd, name, p, 0);
}
int tnl_ioctl_get_6rd(const char *name, void *p)
{
- return tnl_gen_ioctl(SIOCGET6RD, name, p);
+ int err = tnl_gen_ioctl(SIOCGET6RD, name, p, 1);
+ if (err && errno != EINVAL)
+ perror("ioctl");
+ return err;
}
^ permalink raw reply related
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Wolfram Sang @ 2010-03-31 8:10 UTC (permalink / raw)
To: Sascha Hauer
Cc: Bryan Wu, gerg, amit.kucheria, kernel-team, netdev, linux-kernel,
linux-arm-kernel
In-Reply-To: <20100331075746.GO2241@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
> With rounding this would be:
>
> (clk_get_rate() + 4999999) / 5000000
Better use DIV_ROUND_UP(clk_get_rate(), 5000000)?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Sascha Hauer @ 2010-03-31 8:12 UTC (permalink / raw)
To: Bryan Wu, gerg, netdev, kernel-team, linux-kernel,
linux-arm-kernel, w.sang
In-Reply-To: <20100326102957.GG5539@matterhorn.verdurent.com>
On Fri, Mar 26, 2010 at 12:29:57PM +0200, Amit Kucheria wrote:
> On 10 Mar 26, Bryan Wu wrote:
> > BugLink: http://bugs.launchpad.net/bugs/457878
> >
> > - removed old MII phy control code
> > - add phylib supporting
> > - add ethtool interface to make user space NetworkManager works
> >
> > Tested on Freescale i.MX51 Babbage board.
> >
> > This patch is based on a patch from Frederic Rodo <fred.rodo@gmail.com>
> >
> > Cc: Frederic Rodo <fred.rodo@gmail.com>
> > Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
>
> While I ack this patch, I wonder if we should add to the various board
> Kconfig options, a dependency select'ing the right phylib for that board.
>
> This would prevent breakage of ethernet on those boards because they forgot
> to select the right phylib after this change.
I wouldn't go that far. I never saw a board which doesn't work with the
generic phy implementation, so I would only select the specific phy if
I knew that the generic phy does not work.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Sascha Hauer @ 2010-03-31 8:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: Bryan Wu, gerg, amit.kucheria, kernel-team, netdev, linux-kernel,
linux-arm-kernel
In-Reply-To: <20100331081004.GB23391@pengutronix.de>
On Wed, Mar 31, 2010 at 10:10:04AM +0200, Wolfram Sang wrote:
> > With rounding this would be:
> >
> > (clk_get_rate() + 4999999) / 5000000
>
> Better use DIV_ROUND_UP(clk_get_rate(), 5000000)?
Yes.
Sometimes I wish the useful assorted kernel helper of the day in my
fortune :)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support.
From: Tejun Heo @ 2010-03-31 8:17 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: <m11vf12ayb.fsf@fess.ebiederm.org>
Hello, Eric.
On 03/31/2010 04:43 PM, Eric W. Biederman wrote:
>> 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.
Yeah, well, in a sense. It's all a matter of degree.
> 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.
Well, I guess all I wanna say is... is there *ANY* way to do it w/
less callbacks? It's very difficult to follow what's going on for
what.
If you think all those callbacks are absolute necessities, can you
please at least add boatload of comments around them explaning what
they're meant to do and how they're gonna be used? It's probably
because I don't have any experience with namespaces but I really can't
wrap my head around it as it currently stands.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support.
From: Tejun Heo @ 2010-03-31 8:22 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: <4BB30520.2030100@kernel.org>
Just wanna add a bit more.
On 03/31/2010 05:17 PM, Tejun Heo wrote:
> If you think all those callbacks are absolute necessities, can you
> please at least add boatload of comments around them explaning what
> they're meant to do and how they're gonna be used? It's probably
> because I don't have any experience with namespaces but I really can't
> wrap my head around it as it currently stands.
The reason why I talked about proper layering is the same reason.
It's very difficult to review your code because I have no idea how
those callbacks are meant to be used and gonna behave and that lowers
maintainability significantly in the long run. If at all possible,
please make it implement a discrete function which is used to
implement something higher up. If it's already done like that and I'm
just being stupid, please feel free to enlighten me.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] MACB: Set PHY address in kernel parameters
From: Patrick McHardy @ 2010-03-31 8:28 UTC (permalink / raw)
To: Anders Darander
Cc: Haavard Skinnemoen, David S. Miller, Jiri Pirko, Erik Waling,
Anders Darander, Grant Likely, netdev, linux-kernel
In-Reply-To: <1270021902-6556-1-git-send-email-anders.darander@gmail.com>
Anders Darander wrote:
> From: Anders Darander <ad@datarespons.se>
>
> Add the possibility to set the phy address. This is needed if an integrated
> switch is connected to the MAC, as it is often the case that the highest port
> is the one connected to the MAC of the MCU.
>
> E.g. in the case of the Micrel KSZ8873, port 3 is the one to connect to the
> MCU, thus, the MAC needs to connect to phy address 0x03, instead of the first
> phy found.
>
> Signed-off-by: Anders Darander <ad@datarespons.se>
> ---
> drivers/net/macb.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index c8a18a6..9b4e301 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -53,6 +53,14 @@
> #define MACB_RX_INT_FLAGS (MACB_BIT(RCOMP) | MACB_BIT(RXUBR) \
> | MACB_BIT(ISR_ROVR))
>
> +/*
> + * Setup PHY probeing
> + */
> +
> +static int phy_addr = PHY_MAX_ADDR;
> +module_param(phy_addr, ushort, 0);
> +MODULE_PARAM_DESC(phy_addr, "PHY address connected to the MACB");
> +
> static void __macb_set_hwaddr(struct macb *bp)
> {
> u32 bottom;
> @@ -193,7 +201,11 @@ static int macb_mii_probe(struct net_device *dev)
> struct eth_platform_data *pdata;
> int ret;
>
> - phydev = phy_find_first(bp->mii_bus);
> + if (phy_addr >= PHY_MAX_ADDRESS)
> + phydev = phy_find_first(bp->mii_bus);
> + else
> + phydev = bp->mii_bus->phy_map[phy_addr];
This looks like you need to use an unsigned to avoid negative
indices.
^ permalink raw reply
* Re: [PATCH RFC] fix problems with NETIF_F_HIGHDMA in networking drivers v2
From: FUJITA Tomonori @ 2010-03-31 8:35 UTC (permalink / raw)
To: davem
Cc: fujita.tomonori, hancockrwd, linux-kernel, netdev, linux-usb,
bzolnier
In-Reply-To: <20100325.203520.234306178.davem@davemloft.net>
On Thu, 25 Mar 2010 20:35:20 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Date: Fri, 26 Mar 2010 12:33:12 +0900
>
> > On Thu, 25 Mar 2010 19:03:37 -0600
> > Robert Hancock <hancockrwd@gmail.com> wrote:
> >
> >> This seems like it could be a reasonable approach. The only thing is
> >> that in this code you're returning 1 if the parent device has no DMA
> >> mask set. Wouldn't it make more sense to return 0 in this case? I'm
> >> assuming that in that situation it's a virtual device not backed by
> >> any hardware and there should be no DMA mask restriction...
> >
> > I chose the safer option because I don't know enough how net_device
> > structure is used. If returning zero in such case is always safe, it's
> > fine by me. any example of such virtual device driver?
>
> Like Fujita I'd rather play it safe here.
>
> Even for virtual devices, DMA information up to the root bus
> ought to be sane.
Agreed.
Here's the patch in the proper format.
Probably, PCI_DMA_BUS_IS_PHYS should be renamed to something like
DMA_BUS_IS_PHYS and moved to the better place. Then we can avoid
including linux/pci.h.
=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] net: change illegal_highdma to use dma_mask
Robert Hancock pointed out two problems about NETIF_F_HIGHDMA:
-Many drivers only set the flag when they detect they can use 64-bit DMA,
since otherwise they could receive DMA addresses that they can't handle
(which on platforms without IOMMU/SWIOTLB support is fatal). This means that if
64-bit support isn't available, even buffers located below 4GB will get copied
unnecessarily.
-Some drivers set the flag even though they can't actually handle 64-bit DMA,
which would mean that on platforms without IOMMU/SWIOTLB they would get a DMA
mapping error if the memory they received happened to be located above 4GB.
http://lkml.org/lkml/2010/3/3/530
We can use the dma_mask if we need bouncing or not here. Then we can
safely fix drivers that misuse NETIF_F_HIGHDMA.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
net/core/dev.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5e3dc28..3a09f76 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -129,6 +129,7 @@
#include <linux/jhash.h>
#include <linux/random.h>
#include <trace/events/napi.h>
+#include <linux/pci.h>
#include "net-sysfs.h"
@@ -1790,14 +1791,21 @@ static inline int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
{
#ifdef CONFIG_HIGHMEM
int i;
+ if (!(dev->features & NETIF_F_HIGHDMA)) {
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
+ if (PageHighMem(skb_shinfo(skb)->frags[i].page))
+ return 1;
+ }
- if (dev->features & NETIF_F_HIGHDMA)
- return 0;
-
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- if (PageHighMem(skb_shinfo(skb)->frags[i].page))
- return 1;
+ if (PCI_DMA_BUS_IS_PHYS) {
+ struct device *pdev = dev->dev.parent;
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ dma_addr_t addr = page_to_phys(skb_shinfo(skb)->frags[i].page);
+ if (!pdev->dma_mask || addr + PAGE_SIZE - 1 > *pdev->dma_mask)
+ return 1;
+ }
+ }
#endif
return 0;
}
--
1.7.0
^ permalink raw reply related
* Re: [PATCH v3 04/12] l2tp: Add ppp device name to L2TP ppp session data
From: David Miller @ 2010-03-31 8:46 UTC (permalink / raw)
To: jchapman; +Cc: shemminger, netdev
In-Reply-To: <4BB2FD0D.1080105@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Wed, 31 Mar 2010 08:43:09 +0100
> 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.
Existing stuff you shouldn't move around, people do depend on it
and thus it has to be retained.
But for new stuff, we can try to think about better ways to export the
information if possible.
^ 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