* [PATCH] Fix some #includes in CAN drivers
From: Hans J. Koch @ 2010-04-08 19:25 UTC (permalink / raw)
To: socketcan-core
Cc: netdev, kernel, Barry Song, Chris Elston, Christian Pellegrin,
Wolfgang Grandegger, Sebastian Haas, Per Dalen, Pavel Cheblakov,
Oliver Hartkopp, Anant Gole
In the current implementation, CAN drivers need to #include <linux/can.h>
_before_ they #include <linux/can/dev.h>, which is both ugly and
unnecessary.
Fix this by including <linux/can.h> in <linux/can/dev.h> and remove the
#include <linux/can.h> lines from drivers.
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
---
drivers/net/can/at91_can.c | 1 -
drivers/net/can/bfin_can.c | 1 -
drivers/net/can/mcp251x.c | 1 -
drivers/net/can/mscan/mpc5xxx_can.c | 1 -
drivers/net/can/mscan/mscan.c | 1 -
drivers/net/can/sja1000/ems_pci.c | 1 -
drivers/net/can/sja1000/kvaser_pci.c | 1 -
drivers/net/can/sja1000/plx_pci.c | 1 -
drivers/net/can/sja1000/sja1000.c | 1 -
drivers/net/can/sja1000/sja1000_isa.c | 1 -
drivers/net/can/sja1000/sja1000_of_platform.c | 1 -
drivers/net/can/sja1000/sja1000_platform.c | 1 -
drivers/net/can/ti_hecc.c | 1 -
include/linux/can/dev.h | 1 +
14 files changed, 1 insertion(+), 13 deletions(-)
Index: linux-2.6.34-rc/include/linux/can/dev.h
===================================================================
--- linux-2.6.34-rc.orig/include/linux/can/dev.h 2010-04-08 19:37:34.000000000 +0200
+++ linux-2.6.34-rc/include/linux/can/dev.h 2010-04-08 19:37:50.000000000 +0200
@@ -14,6 +14,7 @@
#ifndef CAN_DEV_H
#define CAN_DEV_H
+#include <linux/can.h>
#include <linux/can/netlink.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/at91_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/at91_can.c 2010-04-08 20:52:22.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/at91_can.c 2010-04-08 20:52:47.000000000 +0200
@@ -35,7 +35,6 @@
#include <linux/string.h>
#include <linux/types.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/bfin_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/bfin_can.c 2010-04-08 20:53:15.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/bfin_can.c 2010-04-08 20:53:25.000000000 +0200
@@ -18,7 +18,6 @@
#include <linux/skbuff.h>
#include <linux/platform_device.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/mcp251x.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mcp251x.c 2010-04-08 20:53:47.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mcp251x.c 2010-04-08 20:54:04.000000000 +0200
@@ -58,7 +58,6 @@
*
*/
-#include <linux/can.h>
#include <linux/can/core.h>
#include <linux/can/dev.h>
#include <linux/can/platform/mcp251x.h>
Index: linux-2.6.34-rc/drivers/net/can/ti_hecc.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/ti_hecc.c 2010-04-08 20:54:35.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/ti_hecc.c 2010-04-08 20:54:45.000000000 +0200
@@ -47,7 +47,6 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
#include <linux/can/platform/ti_hecc.h>
Index: linux-2.6.34-rc/drivers/net/can/mscan/mpc5xxx_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mscan/mpc5xxx_can.c 2010-04-08 20:55:16.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mscan/mpc5xxx_can.c 2010-04-08 20:55:26.000000000 +0200
@@ -25,7 +25,6 @@
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/netdevice.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/of_platform.h>
#include <sysdev/fsl_soc.h>
Index: linux-2.6.34-rc/drivers/net/can/mscan/mscan.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mscan/mscan.c 2010-04-08 20:55:55.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mscan/mscan.c 2010-04-08 20:56:08.000000000 +0200
@@ -28,7 +28,6 @@
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/list.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/ems_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/ems_pci.c 2010-04-08 20:56:48.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/ems_pci.c 2010-04-08 20:57:17.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/kvaser_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/kvaser_pci.c 2010-04-08 20:57:39.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/kvaser_pci.c 2010-04-08 20:57:49.000000000 +0200
@@ -36,7 +36,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/plx_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/plx_pci.c 2010-04-08 20:58:00.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/plx_pci.c 2010-04-08 20:58:09.000000000 +0200
@@ -26,7 +26,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000.c 2010-04-08 20:59:31.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000.c 2010-04-08 20:59:50.000000000 +0200
@@ -60,7 +60,6 @@
#include <linux/skbuff.h>
#include <linux/delay.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_isa.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_isa.c 2010-04-08 20:59:55.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_isa.c 2010-04-08 21:00:06.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/delay.h>
#include <linux/irq.h>
#include <linux/io.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/platform/sja1000.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_of_platform.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_of_platform.c 2010-04-08 20:58:44.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_of_platform.c 2010-04-08 20:58:52.000000000 +0200
@@ -38,7 +38,6 @@
#include <linux/interrupt.h>
#include <linux/netdevice.h>
#include <linux/delay.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/of_platform.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_platform.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_platform.c 2010-04-08 20:59:04.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_platform.c 2010-04-08 20:59:11.000000000 +0200
@@ -24,7 +24,6 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/irq.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/platform/sja1000.h>
#include <linux/io.h>
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Ben Hutchings @ 2010-04-08 19:35 UTC (permalink / raw)
To: Laurent Chavey; +Cc: davem, netdev, therbert
In-Reply-To: <w2i97949e3e1004081217jdeca953dz162c62b61c0e8f72@mail.gmail.com>
On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
[...]
> >> +enum ethtool_loopback_type {
> >> + ETH_MAC = 0x00000001,
> >> + ETH_PHY_INT = 0x00000002,
> >> + ETH_PHY_EXT = 0x00000004
> >> +};
> > [...]
> >
> > There are many different places you can loop back within a MAC or PHY,
> > not to mention bypassing the MAC altogether. See
> > drivers/net/sfc/mcdi_pcol.h, starting from the line
> > '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
> > loopback modes on at least one board.
> >
> > Also are these supposed to be an enumeration or flags? In theory you
> those are enums that can be or together.
I.e. they are flags. So how do you answer this:
> > could use wire-side and host-side loopback at the same time if they
> > don't overlap, but it's probably too much trouble to bother with. Any
> > other combination is meaningless.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH 1/1] add ethtool loopback support
From: Jeff Garzik @ 2010-04-08 19:51 UTC (permalink / raw)
To: Ben Hutchings, chavey; +Cc: davem, netdev, therbert
In-Reply-To: <1270751373.5055.22.camel@achroite.uk.solarflarecom.com>
On 04/08/2010 02:29 PM, Ben Hutchings wrote:
> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>> From: Ranjit Manomohan<ranjitm@google.com>
>> Date: Wed, 7 Apr 2010 15:19:48 -0700
>>
>> Add an ethtool option to use internal loopback mode for testing.
>> This feature is used for component and driver test coverage by putting
>> the device in hardware loopback mode and sending / receiving network
>> traffic from a user application to test the hardware and driver
>> transmit / receive paths.
>>
>> Signed-off-by: laurent chavey<chavey@google.com>
>> ---
>> include/linux/ethtool.h | 16 ++++++++++++++++
>> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index b33f316..df1dcc7 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -292,6 +292,18 @@ struct ethtool_stats {
>> __u64 data[0];
>> };
>>
>> +/* for setting the NIC into loopback mode */
>> +struct ethtool_loopback {
>> + u32 cmd; /* ETHTOOL_SLOOPBACK */
>> + u32 type; /* ethtool_loopback_type */
>> +};
>> +
>> +enum ethtool_loopback_type {
>> + ETH_MAC = 0x00000001,
>> + ETH_PHY_INT = 0x00000002,
>> + ETH_PHY_EXT = 0x00000004
>> +};
> [...]
>
> There are many different places you can loop back within a MAC or PHY,
> not to mention bypassing the MAC altogether. See
> drivers/net/sfc/mcdi_pcol.h, starting from the line
> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
> loopback modes on at least one board.
>
> Also are these supposed to be an enumeration or flags? In theory you
> could use wire-side and host-side loopback at the same time if they
> don't overlap, but it's probably too much trouble to bother with. Any
> other combination is meaningless.
Additionally, ethtool is intended as an interface that exports
capabilities generally useful to users. Is this feature really
something that users will make use of? It seems more in the realm of
design validation
The existing ETHTOOL_TEST ioctl was intended as a coarse-grained method
of verifying that the NIC is working, because fine-grained tests are
inevitably both NIC-specific, and too involved for all but the most
sophisticated users (read: the designers who built the NIC).
So, consider this a _weak_ objection. Sure we could implement this, but
will it really be useful to most users?
Jeff
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Rick Jones @ 2010-04-08 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Hutchings, chavey, davem, netdev, therbert
In-Reply-To: <4BBE33C9.5000507@garzik.org>
> Additionally, ethtool is intended as an interface that exports
> capabilities generally useful to users. Is this feature really
> something that users will make use of? It seems more in the realm of
> design validation
In enterprise days gone by, performing loopback tests were a part of hardware
problem diagnosis in the field - either by SEs or customers.
rick jones
^ permalink raw reply
* Re: linux-next: powerpc boot failure
From: David Miller @ 2010-04-08 20:13 UTC (permalink / raw)
To: tony.luck; +Cc: timo.teras, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <o2s12c511ca1004081155o9b28c9f5hdfadd075913f1fcf@mail.gmail.com>
From: Tony Luck <tony.luck@intel.com>
Date: Thu, 8 Apr 2010 11:55:34 -0700
> I tried the patch you just posted. Compiling with it gave this warning:
>
> net/xfrm/xfrm_policy.c: In function ‘__xfrm_lookup’:
> net/xfrm/xfrm_policy.c:1735: warning: ‘num_xfrms’ may be used
> uninitialized in this function
This is just because gcc is stupid, you can ignore this.
It can't see that when a real 'err' error is returned we never end up
referencing the num_xfrms value.
> but the patched kernel booted ok.
Thanks for testing, I pushed Timo's fix to net-next-2.6 earlier today
so it'll hopefully show up in the next linux-next.
^ permalink raw reply
* Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-08 20:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI, Al Viro
In-Reply-To: <alpine.LFD.2.00.1004071444440.3586-GpypE611fyS63QaFMGN2QEqCLAeBNdoH@public.gmane.org>
On Thursday 08 April 2010, Linus Torvalds wrote:
>
> On Wed, 7 Apr 2010, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15718
> > Subject : File corruption regression on NFS related to commit 1f36f774
> > Submitter : Boaz Harrosh <bharrosh-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
> > Date : 2010-03-24 15:49 (15 days old)
> > First-Bad-Commit: http://git.kernel.org/git/linus/1f36f774b22a0ceb7dd33eca626746c81a97b6a5
> > Message-ID : <4BAA3493.1030802-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126944579810350&w=4
> > Handled-By : Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>
> I think this one is fixed by commit 3e297b61349.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15716
> > Subject : ata2: lost interrupt with kernel 2.6.34-rc1
> > Submitter : Andrew Benton <b3nton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-11 16:57 (28 days old)
> > Message-ID : <4B992110.2090300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126832670609705&w=4
> > Handled-By : Jeff Garzik <jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
>
> And isn't this the already long-fixed commit 332ac7ff77cd?
>
> That bugzilla entry is a duplicate of
>
> https://bugzilla.kernel.org/show_bug.cgi?id=15537
>
> as far as I can see.
Yes, my bad, sorry. Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15715
> > Subject : vmscan: underflow for get_scan_ratio
> > Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-30 5:53 (9 days old)
> > First-Bad-Commit: http://git.kernel.org/git/linus/84b18490d1f1bc7ed5095c929f78bc002eb70f26
> > Message-ID : <20100330055304.GA2983-U5EdaLXB8smDugQYiPIPGdh3ngVCH38I@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126992842105754&w=4
> > Handled-By : KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> > Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> That commit got reverted. See commit d6da1a5abc.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15674
> > Subject : [2.6.34-rc2 NFS4 oops] open error path failure...
> > Submitter : Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-29 18:36 (10 days old)
> > Message-ID : <6278d2221003291136p6481fe8emfb039403343c082-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126988782722711&w=2
>
> This smells like the same LOOKUP_DIRECTORY thing as the first entry, but..
>
> Al?
This one has been fixed too, I see, so closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15600
> > Subject : CONFIG_NO_BOOTMEM woes, 2.6.34-rc1
> > Submitter : Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Date : 2010-03-15 15:28 (24 days old)
> > Message-ID : <4B9E5211.9000204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126866691701926&w=2
>
> These should hopefully be all fixed. There was some confusion over this,
> but the report that said it wasn't fixed in -rc3 was apparently not true
> after all. Several commits, but mainly commit eed63519e, iirc.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15518
> > Subject : CONFIG_NO_BOOTMEM=y breaks boot on 32bit
> > Submitter : Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
> > Date : 2010-03-11 15:37 (28 days old)
>
> Duplicate entry. See above.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15480
> > Subject : [regression] Fails to boot properly unless given pci=nocrs
> > Submitter : Yanko Kaneti <yaneti-jUE9FD3ILm5BDgjK7y7TUQ@public.gmane.org>
> > Date : 2010-03-09 01:24 (30 days old)
> > Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
> > Patch : http://lkml.org/lkml/2010/3/11/512
>
> These are merged already. Commits d558b483d5, eb9fc8ef7cb etc.
Closed.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Laurent Chavey @ 2010-04-08 21:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Hutchings, davem, netdev, therbert
In-Reply-To: <4BBE33C9.5000507@garzik.org>
On Thu, Apr 8, 2010 at 12:51 PM, Jeff Garzik <jeff@garzik.org> wrote:
> On 04/08/2010 02:29 PM, Ben Hutchings wrote:
>>
>> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>>>
>>> From: Ranjit Manomohan<ranjitm@google.com>
>>> Date: Wed, 7 Apr 2010 15:19:48 -0700
>>>
>>> Add an ethtool option to use internal loopback mode for testing.
>>> This feature is used for component and driver test coverage by putting
>>> the device in hardware loopback mode and sending / receiving network
>>> traffic from a user application to test the hardware and driver
>>> transmit / receive paths.
>>>
>>> Signed-off-by: laurent chavey<chavey@google.com>
>>> ---
>>> include/linux/ethtool.h | 16 ++++++++++++++++
>>> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>>> index b33f316..df1dcc7 100644
>>> --- a/include/linux/ethtool.h
>>> +++ b/include/linux/ethtool.h
>>> @@ -292,6 +292,18 @@ struct ethtool_stats {
>>> __u64 data[0];
>>> };
>>>
>>> +/* for setting the NIC into loopback mode */
>>> +struct ethtool_loopback {
>>> + u32 cmd; /* ETHTOOL_SLOOPBACK */
>>> + u32 type; /* ethtool_loopback_type */
>>> +};
>>> +
>>> +enum ethtool_loopback_type {
>>> + ETH_MAC = 0x00000001,
>>> + ETH_PHY_INT = 0x00000002,
>>> + ETH_PHY_EXT = 0x00000004
>>> +};
>>
>> [...]
>>
>> There are many different places you can loop back within a MAC or PHY,
>> not to mention bypassing the MAC altogether. See
>> drivers/net/sfc/mcdi_pcol.h, starting from the line
>> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
>> loopback modes on at least one board.
>>
>> Also are these supposed to be an enumeration or flags? In theory you
>> could use wire-side and host-side loopback at the same time if they
>> don't overlap, but it's probably too much trouble to bother with. Any
>> other combination is meaningless.
>
>
> Additionally, ethtool is intended as an interface that exports capabilities
> generally useful to users. Is this feature really something that users will
> make use of? It seems more in the realm of design validation
>
> The existing ETHTOOL_TEST ioctl was intended as a coarse-grained method of
> verifying that the NIC is working, because fine-grained tests are inevitably
> both NIC-specific, and too involved for all but the most sophisticated users
> (read: the designers who built the NIC).
>
> So, consider this a _weak_ objection. Sure we could implement this, but
> will it really be useful to most users?
we have some autotests that make use of this feature for e1000(e), forcedeth and
tg3 that we would like to share with the community to do perf / functional tests
regression.
>
> Jeff
>
>
>
^ permalink raw reply
* Re: HTB - What's the minimal value for 'rate' parameter?
From: Jarek Poplawski @ 2010-04-08 21:33 UTC (permalink / raw)
To: Antonio Almeida; +Cc: netdev, kaber, davem, devik
In-Reply-To: <z2q298f5c051004080407r5dfb27fai74c5cf74d0048ca5@mail.gmail.com>
Antonio Almeida wrote, On 04/08/2010 01:07 PM:
> Hi!
Hi!
> I've been using HTB for a while, and we've already sent some e-mails
> each other when resolving HTB accuracy issue.
> When using HTB, I realised that for some configurations the rate limit
> doesn't work.
> I suspect that the problem is the minimum value of rate parameter,
> which I cant figure out what is.
>
> I simple configuration that turns out to be wrong is as fallows: The
> root (1:1) gets the link bandwidth configuration; the second (1:2) is
> set to 4096Kbit; then I have two branches (1:10 and 1:11) with rate
> 1024Kbit and ceil 4096Kbit; and finally a leaf class in each branch
> (1:111 below 1:11, and 1:101 below 1:10) with rate 8bit and ceil
> 4096Kbit, and the same priority.
> I don't want to have sustained rate, and since I must configure 'rate'
> parameter I decide to set it to 8bits - which is the minimal accepted
> value. My cue goes for 'rate' parameter. If I set 'rate' parameter to
> 1Kbit for instance, the problem disappears and the shaping is done
> perfectly.
>
> So, I'm looking for help to find out if the problem is actually in
> this parameter configuration or if it's just coincidence and I'll get
> the same problem ahead :(
> What's the minimal value for 'rate' parameter using HTB qdisc?
I think "reasonable" or "minimally useful" (for common use) should be
enough, and 8bits meaning one 1500 byte packet per 25 minutes or
something, doesn't look like this to me.
This changelog:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4a710c4a7490587406462bf1d54504b7783d7d7
mentions ~2 minutes as max time for accounting, so 1 max packet
per 2 minutes should give such a minimal rate, I guess, but I'd
still multiply it a few times to call it useful.
Regards,
Jarek P.
^ permalink raw reply
* [PATCH] cnic: Give a chance for the uio device to be opened before failing the path request
From: Benjamin Li @ 2010-04-08 21:34 UTC (permalink / raw)
To: netdev@vger.kernel.org, Michael Chan; +Cc: Benjamin Li, Eddie Wai
There is a timing condition; where the time between the CNIC's
/dev/uio* device registration and then the issuing of path requests
messages is faster the brcm_iscsiuio daemon initializing.
This can be seen if one sets the machine to automatically login into
iSCSI targets. Then reset the network and iscsi daemons in quick
succession. The login will fail because iscsid will only try
a couple of times in quick succession. This patch will allow some
additional needed time for the brcm_iscsiuio daemon to initialize
before failing the path request call.
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Eddie Wai <waie@broadcom.com>
---
drivers/net/cnic.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 9781942..897f171 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -274,9 +274,17 @@ static int cnic_send_nlmsg(struct cnic_local *cp, u32 type,
u16 len = 0;
u32 msg_type = ISCSI_KEVENT_IF_DOWN;
struct cnic_ulp_ops *ulp_ops;
+ int count = 0;
- if (cp->uio_dev == -1)
+ while (count < 40 && cp->uio_dev == -1) {
+ msleep(50);
+ count++;
+ }
+
+ if (cp->uio_dev == -1) {
+ netdev_warn(cp->dev->netdev, "no uio dev to send nl request\n");
return -ENODEV;
+ }
if (csk) {
len = sizeof(path_req);
--
1.6.1.2
^ permalink raw reply related
* Re: [PATCH 1/1] add ethtool loopback support
From: Laurent Chavey @ 2010-04-08 22:43 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, therbert
In-Reply-To: <1270755356.5055.23.camel@achroite.uk.solarflarecom.com>
On Thu, Apr 8, 2010 at 12:35 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
>> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
>> > On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
> [...]
>> >> +enum ethtool_loopback_type {
>> >> + ETH_MAC = 0x00000001,
>> >> + ETH_PHY_INT = 0x00000002,
>> >> + ETH_PHY_EXT = 0x00000004
>> >> +};
>> > [...]
>> >
>> > There are many different places you can loop back within a MAC or PHY,
>> > not to mention bypassing the MAC altogether. See
>> > drivers/net/sfc/mcdi_pcol.h, starting from the line
>> > '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
>> > loopback modes on at least one board.
>> >
>> > Also are these supposed to be an enumeration or flags? In theory you
>> those are enums that can be or together.
>
> I.e. they are flags. So how do you answer this:
>
>> > could use wire-side and host-side loopback at the same time if they
>> > don't overlap, but it's probably too much trouble to bother with. Any
>> > other combination is meaningless.
since the intent is to enable the sending and receiving of packets at
the hw/driver interfaces, a simple loopback mode on/off is sufficient
and the ethtool_loopback_type are not necessary. the implementor can choose
how to implement the loopback. From drivers/net/sfc/mcdi_pcol.h it is clear
that unless ethtool_loopback_type as defined are meaningless.
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> 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
* 2.6.34-rc3-git8: Reported regressions 2.6.32 -> 2.6.33
From: Rafael J. Wysocki @ 2010-04-08 22:54 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.32 regressions introduced before
2.6.33, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.32 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-04-09 140 34 33
2010-03-21 133 38 34
2010-02-21 115 34 27
2010-02-15 112 34 31
2010-02-07 97 27 20
2010-02-01 85 26 21
2010-01-24 75 29 23
2010-01-10 55 33 21
2009-12-29 36 34 27
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15733
Subject : Crash when accessing nonexistent GTT entries in i915
Submitter : Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date : 2010-03-10 22:09 (30 days old)
Message-ID : <1268258994.2183.14.camel@carter>
References : http://marc.info/?l=linux-kernel&m=126825901326111&w=4
Handled-By : Zhenyu Wang <zhenyuw@linux.intel.com>
Andrew Morton <akpm@linux-foundation.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15714
Subject : PROBLEM: intelfb driver causes trace
Submitter : Troilo, Domenic <Domenic.Troilo@gwl.ca>
Date : 2010-04-01 14:52 (8 days old)
Message-ID : <CBF11783AA883E41A86C009F3AE5D47F0CAE08C1@GWCORPMAIL4.gwl.bz>
References : http://marc.info/?l=linux-kernel&m=127013359722664&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15710
Subject : NumLock LED stays on after PC poweroff.
Submitter : aceman <acelists@atlas.sk>
Date : 2010-04-07 15:13 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15699
Subject : rt2500usb driver cannot remain connected
Submitter : <abcd@gentoo.org>
Date : 2010-04-05 19:30 (4 days old)
Handled-By : Ivo van Doorn <IvDoorn@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15695
Subject : calling pm-suspend freezes system
Submitter : Werner Lemberg <wl@gnu.org>
Date : 2010-04-05 05:13 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15693
Subject : Plugging or unplugging notebook charger renders Atheros card unusable
Submitter : <registosites1@hotmail.com>
Date : 2010-04-04 21:03 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15604
Subject : r8169: Reports incorrect link information
Submitter : Michael B. Trausch <mike@trausch.us>
Date : 2010-03-22 04:19 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15585
Subject : [Bisected Regression in 2.6.32.8] i915 with KMS enabled causes memorycorruption when resuming from suspend-to-disk
Submitter : M. Vefa Bicakci <bicave@superonline.com>
Date : 2010-03-13 5:11 (27 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/d8e0902806c0bd2ccc4f6a267ff52565a3ec933b
Message-ID : <4B9B1E8F.5090806@superonline.com>
References : http://marc.info/?l=linux-kernel&m=126845754409543&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15544
Subject : black screen upon S3 resume, syslog has "render error" and "page table error"
Submitter : Sanjoy Mahajan <sanjoy@mit.edu>
Date : 2010-03-16 00:45 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15534
Subject : 07ca:b808 crashing and breaking usb's
Submitter : Alex Fiestas <alex@eyeos.org>
Date : 2010-03-14 15:56 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15525
Subject : Blank screen after some time, after hibernation/suspend
Submitter : <capsel@matrix.inten.pl>
Date : 2010-03-12 17:24 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15502
Subject : render error detected, EIR: 0x00000010
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2010-03-10 05:45 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15466
Subject : 2.6.33 dies on modprobe
Submitter : M G Berberich <berberic@fmi.uni-passau.de>
Date : 2010-02-28 22:12 (40 days old)
Message-ID : <20100228221257.GA8858@invalid>
References : http://marc.info/?l=linux-kernel&m=126739570819208&w=2
Handled-By : Américo Wang <xiyou.wangcong@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15465
Subject : 2.6.33 problems
Submitter : werner@guyane.dyn-o-saur.com
Date : 2010-02-27 17:09 (41 days old)
Message-ID : <1267290551.13148@guyane.dyn-o-saur.com>
References : http://marc.info/?l=linux-kernel&m=126729183719672&w=2
Handled-By : Tejun Heo <tj@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15454
Subject : r8169 exits with error -22 since 2.6.33
Submitter : Conrad Kostecki <ConiKost@gmx.de>
Date : 2010-03-05 22:32 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15439
Subject : Laptop does consume more power when booted "cold" -- Thinkpad X200s
Submitter : <johannes.schlatow@googlemail.com>
Date : 2010-03-03 23:09 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15418
Subject : battery status info broken; missing entry in ec_dmi_table for specific MSI hardware (notebook)
Submitter : Tom-Steve Watzke <tswatzke@arcor.de>
Date : 2010-03-01 07:25 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15392
Subject : The kernel does not start up.
Submitter : Kristóf Ralovich <kristof.ralovich@gmail.com>
Date : 2010-02-25 06:52 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15376
Subject : regression (oops) with usb in 2.6.33-rc8
Submitter : Christophe Fergeau <cfergeau@mandriva.com>
Date : 2010-02-23 10:58 (45 days old)
Handled-By : Sarah Sharp <sarah.a.sharp@linux.intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15317
Subject : Lockdep report while running aplay with pulse as the default
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-13 17:17 (55 days old)
Message-ID : <201002131217.10579.edt@aei.ca>
References : http://marc.info/?l=linux-kernel&m=126608146427546&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15311
Subject : Starting pulseaudio causes a NULL pointer hit
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-14 23:41 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15305
Subject : Dell video dies when booting
Submitter : David Ronis <ronis@ronispc.chem.mcgill.ca>
Date : 2010-02-14 1:07 (54 days old)
Message-ID : <1266109622.11290.10.camel@montroll.chem.mcgill.ca>
References : http://marc.info/?l=linux-kernel&m=126611098225127&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15278
Subject : lockdep warning for iscsi in 2.6.33-rc6
Submitter : Tao Ma <tao.ma@oracle.com>
Date : 2010-02-09 6:59 (59 days old)
Message-ID : <4B7107CF.3060703@oracle.com>
References : http://marc.info/?l=linux-kernel&m=126569884330200&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15277
Subject : 2.6.33-rc6 crashes on resume
Submitter : Bill Davidsen <davidsen@roadwarrior3.tmr.com>
Date : 2010-02-08 23:03 (60 days old)
Message-ID : <4B70982F.8090208@roadwarrior3.tmr.com>
References : http://marc.info/?l=linux-kernel&m=126567021801935&w=2
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15276
Subject : latest git kernel: general protection fault: 0000 [#1]
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2010-02-09 8:36 (59 days old)
Message-ID : <20100209083605.GA1766@arch.tripp.de>
References : http://marc.info/?l=linux-kernel&m=126570498804223&w=2
Handled-By : Jérôme Glisse <glisse@freedesktop.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15259
Subject : Corruption with OpenGL since Intel's big DRM push on i945
Submitter : Alexandre Demers <papouta@hotmail.com>
Date : 2010-02-08 13:19 (60 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/76446cac68568fc7f5168a27deaf803ed22a4360
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15246
Subject : BUG: Bad page state in process portageq
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-02-07 0:45 (61 days old)
References : http://marc.info/?l=linux-kernel&m=126550356515887&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15244
Subject : PROBLEM: hda-intel divide by zero kernel crash in azx_position_ok()
Submitter : Jody Bruchon <jody@nctritech.com>
Date : 2010-02-06 0:32 (62 days old)
References : http://marc.info/?l=linux-kernel&m=126541276028173&w=2
Handled-By : Takashi Iwai <tiwai@suse.de>
Jody Bruchon <jody@nctritech.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject : System panic under load with clockevents_program_event
Submitter : okias <d.okias@gmail.com>
Date : 2010-01-17 13:03 (82 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject : soft lockup in dmesg after suspend/resume
Submitter : ykzhao <yakui.zhao@intel.com>
Date : 2010-01-04 5:36 (95 days old)
References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject : tbench regression with 2.6.33-rc1
Submitter : Lin Ming <ming.m.lin@intel.com>
Date : 2009-12-25 11:11 (105 days old)
References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject : WARNING: at kernel/lockdep.c:2830
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-12-27 13:35 (103 days old)
References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject : Misdetection of the TV output
Submitter : Santi <santi@agolina.net>
Date : 2009-12-12 13:28 (118 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/27dfaf4f5825a119305db1bc63bef30ed400e376
Handled-By : Zhao Yakui <yakui.zhao@intel.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15328
Subject : high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
Submitter : John W. Linville <linville@tuxdriver.com>
Date : 2010-02-16 20:25 (52 days old)
Handled-By : Francisco Jerez <currojerez@riseup.net>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25118
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.32 and 2.6.33, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14885
Please let the tracking teak know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2010-04-08 22:59 UTC (permalink / raw)
To: John Linn
Cc: David Miller, netdev, linux-next, linux-kernel, jtyner,
grant.likely
In-Reply-To: <6125d80a-81d5-4699-ac6e-9408bd0c1145@SG2EHSMHS010.ehs.local>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Hi John,
On Thu, 8 Apr 2010 08:15:12 -0600 John Linn <John.Linn@xilinx.com> wrote:
>
> I'm not pushing back here, just trying to make sure I understand and do
> it better next time :)
>
> I don't see that my patch has touched that part of the driver as that
> call was already in the driver before my patch (but maybe I'm just
> missing it).
>
> My patch did change the dependency in the Kconfig so that it only
> depends on powerpc rather than powerpc DCR and maybe that exposed
> something that wasn't previously exposed.
Yeah, virt_to_bus() is only defined on 32bit PowerPC, not 64 bit.
CONFIG_PPC is set for both 32 and 64 bit PowerPC builds.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: linux-next: build failure after merge of the final tree
From: John Linn @ 2010-04-08 23:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, jtyner,
grant.likely
In-Reply-To: <20100409085918.cc984fb1.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Thursday, April 08, 2010 4:59 PM
> To: John Linn
> Cc: David Miller; netdev@vger.kernel.org; linux-next@vger.kernel.org;
linux-kernel@vger.kernel.org;
> jtyner@cs.ucr.edu; grant.likely@secretlab.ca
> Subject: Re: linux-next: build failure after merge of the final tree
>
> Hi John,
>
> On Thu, 8 Apr 2010 08:15:12 -0600 John Linn <John.Linn@xilinx.com>
wrote:
> >
> > I'm not pushing back here, just trying to make sure I understand and
> > do it better next time :)
> >
> > I don't see that my patch has touched that part of the driver as
that
> > call was already in the driver before my patch (but maybe I'm just
> > missing it).
> >
> > My patch did change the dependency in the Kconfig so that it only
> > depends on powerpc rather than powerpc DCR and maybe that exposed
> > something that wasn't previously exposed.
>
> Yeah, virt_to_bus() is only defined on 32bit PowerPC, not 64 bit.
>
> CONFIG_PPC is set for both 32 and 64 bit PowerPC builds.
> --
Thanks for confirming that. Spun a new patch (set) to hopefully take
care of that.
-- John
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH] vhost: Make it more scalable by creating a vhost thread per device.
From: Sridhar Samudrala @ 2010-04-09 0:05 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Tom Lendacky, netdev, kvm@vger.kernel.org
In-Reply-To: <1270488911.27874.43.camel@w-sridhar.beaverton.ibm.com>
On Mon, 2010-04-05 at 10:35 -0700, Sridhar Samudrala wrote:
> On Sun, 2010-04-04 at 14:14 +0300, Michael S. Tsirkin wrote:
> > On Fri, Apr 02, 2010 at 10:31:20AM -0700, Sridhar Samudrala wrote:
> > > Make vhost scalable by creating a separate vhost thread per vhost
> > > device. This provides better scaling across multiple guests and with
> > > multiple interfaces in a guest.
> >
> > Thanks for looking into this. An alternative approach is
> > to simply replace create_singlethread_workqueue with
> > create_workqueue which would get us a thread per host CPU.
> >
> > It seems that in theory this should be the optimal approach
> > wrt CPU locality, however, in practice a single thread
> > seems to get better numbers. I have a TODO to investigate this.
> > Could you try looking into this?
>
> Yes. I tried using create_workqueue(), but the results were not good
> atleast when the number of guest interfaces is less than the number
> of CPUs. I didn't try more than 8 guests.
> Creating a separate thread per guest interface seems to be more
> scalable based on the testing i have done so far.
>
> I will try some more tests and get some numbers to compare the following
> 3 options.
> - single vhost thread
> - vhost thread per cpu
> - vhost thread per guest virtio interface
Here are the results with netperf TCP_STREAM 64K guest to host on a
8-cpu Nehalem system. It shows cumulative bandwidth in Mbps and host
CPU utilization.
Current default single vhost thread
-----------------------------------
1 guest: 12500 37%
2 guests: 12800 46%
3 guests: 12600 47%
4 guests: 12200 47%
5 guests: 12000 47%
6 guests: 11700 47%
7 guests: 11340 47%
8 guests: 11200 48%
vhost thread per cpu
--------------------
1 guest: 4900 25%
2 guests: 10800 49%
3 guests: 17100 67%
4 guests: 20400 84%
5 guests: 21000 90%
6 guests: 22500 92%
7 guests: 23500 96%
8 guests: 24500 99%
vhost thread per guest interface
--------------------------------
1 guest: 12500 37%
2 guests: 21000 72%
3 guests: 21600 79%
4 guests: 21600 85%
5 guests: 22500 89%
6 guests: 22800 94%
7 guests: 24500 98%
8 guests: 26400 99%
Thanks
Sridhar
^ permalink raw reply
* Re: linux-next: powerpc boot failure
From: Stephen Rothwell @ 2010-04-09 0:08 UTC (permalink / raw)
To: Timo Teräs; +Cc: David Miller, netdev, linux-next, LKML
In-Reply-To: <4BBD966D.8020404@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
Hi Timo,
On Thu, 08 Apr 2010 11:40:13 +0300 Timo Teräs <timo.teras@iki.fi> wrote:
>
> Can you try if this helps?
That patch allows my machine to boot.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] vhost: Make it more scalable by creating a vhost thread per device.
From: Rick Jones @ 2010-04-09 0:14 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Michael S. Tsirkin, Tom Lendacky, netdev, kvm@vger.kernel.org
In-Reply-To: <1270771542.31186.397.camel@w-sridhar.beaverton.ibm.com>
> Here are the results with netperf TCP_STREAM 64K guest to host on a
> 8-cpu Nehalem system.
I presume you mean 8 core Nehalem-EP, or did you mean 8 processor Nehalem-EX?
Don't get me wrong, I *like* the netperf 64K TCP_STREAM test, I lik it a lot!-)
but I find it incomplete and also like to run things like single-instance TCP_RR
and multiple-instance, multiple "transaction" (./configure --enable-burst)
TCP_RR tests, particularly when concerned with "scaling" issues.
happy benchmarking,
rick jones
> It shows cumulative bandwidth in Mbps and host
> CPU utilization.
>
> Current default single vhost thread
> -----------------------------------
> 1 guest: 12500 37%
> 2 guests: 12800 46%
> 3 guests: 12600 47%
> 4 guests: 12200 47%
> 5 guests: 12000 47%
> 6 guests: 11700 47%
> 7 guests: 11340 47%
> 8 guests: 11200 48%
>
> vhost thread per cpu
> --------------------
> 1 guest: 4900 25%
> 2 guests: 10800 49%
> 3 guests: 17100 67%
> 4 guests: 20400 84%
> 5 guests: 21000 90%
> 6 guests: 22500 92%
> 7 guests: 23500 96%
> 8 guests: 24500 99%
>
> vhost thread per guest interface
> --------------------------------
> 1 guest: 12500 37%
> 2 guests: 21000 72%
> 3 guests: 21600 79%
> 4 guests: 21600 85%
> 5 guests: 22500 89%
> 6 guests: 22800 94%
> 7 guests: 24500 98%
> 8 guests: 26400 99%
>
> Thanks
> Sridhar
>
>
> --
> 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: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Elina Pasheva @ 2010-04-09 0:39 UTC (permalink / raw)
To: David Miller
Cc: dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Rory Filer, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20100407.214530.05341654.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, 2010-04-07 at 21:45 -0700, David Miller wrote:
> From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
> Date: Mon, 5 Apr 2010 18:39:08 -0700
>
> > Subject: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> > From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
>
> I want you to tell me exactly how you generated this patch.
>
> It doesn't apply, and I suspect that you tried to fix the excess empty
> lines at the end of certain files by editing the patch by hand.
>
> If so, did you test the result?
>
> The patch is corrupted and more importantly git won't accept it.
>
> davem@sunset:~/src/GIT/net-2.6$ git am --signoff re-submit3-ANNOUNCEMENT-NET-usb-sierra_net.c-driver.patch
> Applying: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> /home/davem/src/GIT/net-2.6/.git/rebase-apply/patch:36: new blank line at EOF.
> +
> error: drivers/net/usb/sierra_net.c: does not exist in index
> Patch failed at 0001 re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
>
Hi Dave,
I reproduced the problem here.
I fixed it by adding an empty sierra_net.c file in my master branch
(net-2.6).
Regards,
Elina
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2010-04-09 0:41 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, chavey
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/core/ethtool.c between commit
5a0e3ad6af8660be21ca98a971cd00f331318c05 ("include cleanup: Update gfp.h
and slab.h includes to prepare for breaking implicit slab.h inclusion
from percpu.h") from Linus' tree and commit
97f8aefbbfb5aa5c9944e5fa8149f1fdaf71c7b6 ("net: fix ethtool coding style
errors and warnings") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix
for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/core/ethtool.c
index 9d55c57,99e9f85..0000000
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@@ -18,8 -18,7 +18,8 @@@
#include <linux/ethtool.h>
#include <linux/netdevice.h>
#include <linux/bitops.h>
+ #include <linux/uaccess.h>
+#include <linux/slab.h>
- #include <asm/uaccess.h>
/*
* Some useful ethtool_ops methods that're device independent.
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Jeff Garzik @ 2010-04-09 0:46 UTC (permalink / raw)
To: Laurent Chavey; +Cc: Ben Hutchings, davem, netdev, therbert
In-Reply-To: <j2r97949e3e1004081543h6258125dm60083556ff28fa88@mail.gmail.com>
On 04/08/2010 06:43 PM, Laurent Chavey wrote:
> On Thu, Apr 8, 2010 at 12:35 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
>> On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
>>> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
>>> <bhutchings@solarflare.com> wrote:
>>>> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>> [...]
>>>>> +enum ethtool_loopback_type {
>>>>> + ETH_MAC = 0x00000001,
>>>>> + ETH_PHY_INT = 0x00000002,
>>>>> + ETH_PHY_EXT = 0x00000004
>>>>> +};
>>>> [...]
>>>>
>>>> There are many different places you can loop back within a MAC or PHY,
>>>> not to mention bypassing the MAC altogether. See
>>>> drivers/net/sfc/mcdi_pcol.h, starting from the line
>>>> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
>>>> loopback modes on at least one board.
>>>>
>>>> Also are these supposed to be an enumeration or flags? In theory you
>>> those are enums that can be or together.
>>
>> I.e. they are flags. So how do you answer this:
>>
>>>> could use wire-side and host-side loopback at the same time if they
>>>> don't overlap, but it's probably too much trouble to bother with. Any
>>>> other combination is meaningless.
> since the intent is to enable the sending and receiving of packets at
> the hw/driver interfaces, a simple loopback mode on/off is sufficient
> and the ethtool_loopback_type are not necessary. the implementor can choose
> how to implement the loopback. From drivers/net/sfc/mcdi_pcol.h it is clear
> that unless ethtool_loopback_type as defined are meaningless.
If an off/on switch is sufficient, the existing ethtool flags interface
should work just fine.
Jeff
^ permalink raw reply
* Re: mmotm 2010-04-05-16-09 uploaded
From: Valdis.Kletnieks @ 2010-04-09 0:50 UTC (permalink / raw)
To: Patrick McHardy
Cc: Andrew Morton, Peter Zijlstra, Ingo Molnar, David S. Miller,
linux-kernel, netfilter-devel, netdev
In-Reply-To: <4BBDF7E7.708@trash.net>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Thu, 08 Apr 2010 17:36:07 +0200, Patrick McHardy said:
> Valdis.Kletnieks@vt.edu wrote:
> > Well, it *changed* it. Does the rcu_defererence_check() only fire on the
> > first time it hits something, so we've fixed the first one and now we get to
> > see the second one?
>
> It appears that way, otherwise you should have seen a second warning in
> nf_conntrack_ecache the last time.
>
> > (For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm
> > OK on that, just want to know up front.)
>
> I went through the other files and I believe this should be it.
> We already removed most of these incorrect rcu_dereference()
> calls a while back.
Confirming - the second version of the patch fixes all the network-related
RCU complaints I've been able to trigger...
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [RFC] [PATCH v2 3/3] Let host NIC driver to DMA to guest user space.
From: Stephen Hemminger @ 2010-04-09 0:52 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, mst@redhat.com,
jdike@c2.user-mode-linux.org, davem@davemloft.net
In-Reply-To: <97F6D3BD476C464182C1B7BABF0B0AF5C17B5C2A@shzsmsx502.ccr.corp.intel.com>
On Tue, 6 Apr 2010 14:26:29 +0800
"Xin, Xiaohui" <xiaohui.xin@intel.com> wrote:
> >How do you deal with the DoS problem of hostile user space app posting huge
> >number of receives and never getting anything.
>
> That's a problem we are trying to deal with. It's critical for long term.
> Currently, we tried to limit the pages it can pin, but not sure how much is reasonable.
> For now, the buffers submitted is from guest virtio-net driver, so it's safe in some extent
> just for now.
It is critical even now. Once you get past toy benchmarks you will see things like
Java processes with 1000 threads all reading at once.
^ permalink raw reply
* Re: 2.6.34-rc3-git8: Reported regressions 2.6.32 -> 2.6.33
From: Gertjan van Wingerde @ 2010-04-09 2:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <cjwJ7Pf9h0L.A.9pB.1DmvLB@chimera>
On 04/09/10 00:54, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15699
> Subject : rt2500usb driver cannot remain connected
> Submitter : <abcd@gentoo.org>
> Date : 2010-04-05 19:30 (4 days old)
> Handled-By : Ivo van Doorn <IvDoorn@gmail.com>
>
This one ought to be fixed by commit 9e76ad2a27f592c1390248867391880c7efe78b3
in Linus' tree.
---
Gertjan.
^ permalink raw reply
* Re: FEC driver: rcv is not +last
From: Bryan Wu @ 2010-04-09 5:42 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: netdev, Sascha Hauer
In-Reply-To: <20100408104033.GI3787@darwin>
On 04/08/2010 06:40 PM, Matthias Kaehlcke wrote:
> hi,
>
> i have problems with the FEC on a i.MX25 3-Stack board. the kernel is
> v2.6.34-rc2 plus the following patch:
> http://patchwork.ozlabs.org/patch/41235/
>
> the following traces are generated at boot time:
>
> FEC Ethernet Driver
> fec: PHY @ 0x1, ID 0x20005ce1 -- unknown PHY!
> ...
Matt,
please try this patch on your hardware, it introduced phylib supporting in fec.c
driver:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/012214.html
Thanks
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer +86.138-1617-6545 Mobile
Ubuntu Kernel Team | Hardware Enablement Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
^ permalink raw reply
* Re: net-next: 2.6.34-rc1 regression: panic when running diagnostic on interface with IPv6
From: Stephen Hemminger @ 2010-04-09 0:54 UTC (permalink / raw)
To: David Miller; +Cc: emil.s.tantilov, netdev
In-Reply-To: <20100405.165317.89399272.davem@davemloft.net>
On Mon, 05 Apr 2010 16:53:17 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
> Date: Mon, 5 Apr 2010 17:50:38 -0600
>
> > David Miller wrote:
> >> From: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
> >> Date: Mon, 5 Apr 2010 17:03:56 -0600
> >>
> >>> David Miller wrote:
> >>>> From: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
> >>>> Date: Tue, 23 Mar 2010 12:28:08 -0600
> >>>>
> >>>>> Bisecting points to this patch:
> >>>>> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=84e8b803f1e16f3a2b8b80f80a63fa2f2f8a9be6
> >>>>>
> >>>>> And I confirmed that the issue goes away after reverting it.
> >>>>>
> >>>>> Steps to reproduce:
> >>>>> 1. Load the driver and configure IPv6 address.
> >>>>> 2. Run ethtool diag:
> >>>>> ethtool -t eth0
> >>>>>
> >>>>> 3. If this doesn't brake it try again, or just do ifdown/up. Other
> >>>>> operations on the interface will eventually panic the system:
> >>>>
> >>>> Stephen please fix this, thanks.
> >>>
> >>> Just FYI - I still see this issue with latest pull from net-2.6.
> >>
> >> It's net-next-2.6 that introduced the problem and has the follow-on
> >> fixes, not net-2.6
> >
> > Same in net-next:
>
> Ok, Stephen please look into this, we've had this regression
> for almost two weeks now.
I can't reproduce it, on e1000e.
Since the symptoms match the original problem that you already fixed,
I have to assume that it is fixed but the reporter (Emil) had not
updated his kernel correctly.
^ permalink raw reply
* Re: [v3 Patch 2/3] bridge: make bridge support netpoll
From: Cong Wang @ 2010-04-09 5:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Jeff Moyer, Matt Mackall, bonding-devel, Jay Vosburgh,
David Miller
In-Reply-To: <20100408083710.2b61ee44@nehalam>
Stephen Hemminger wrote:
> On Thu, 8 Apr 2010 02:18:58 -0400
> Amerigo Wang <amwang@redhat.com> wrote:
>
>> Based on the previous patch, make bridge support netpoll by:
>>
>> 1) implement the 2 methods to support netpoll for bridge;
>>
>> 2) modify netpoll during forwarding packets via bridge;
>>
>> 3) disable netpoll support of bridge when a netpoll-unabled device
>> is added to bridge;
>>
>> 4) enable netpoll support when all underlying devices support netpoll.
>>
>> Cc: David Miller <davem@davemloft.net>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
>> Cc: Matt Mackall <mpm@selenic.com>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>> ---
>>
>> Index: linux-2.6/net/bridge/br_device.c
>> ===================================================================
>> --- linux-2.6.orig/net/bridge/br_device.c
>> +++ linux-2.6/net/bridge/br_device.c
>> @@ -13,8 +13,10 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/netdevice.h>
>> +#include <linux/netpoll.h>
>> #include <linux/etherdevice.h>
>> #include <linux/ethtool.h>
>> +#include <linux/list.h>
>>
>> #include <asm/uaccess.h>
>> #include "br_private.h"
>> @@ -162,6 +164,59 @@ static int br_set_tx_csum(struct net_dev
>> return 0;
>> }
>>
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> +bool br_devices_support_netpoll(struct net_bridge *br)
>> +{
>> + struct net_bridge_port *p;
>> + bool ret = true;
>> + int count = 0;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&br->lock, flags);
>> + list_for_each_entry(p, &br->port_list, list) {
>> + count++;
>> + if (p->dev->priv_flags & IFF_DISABLE_NETPOLL
>> + || !p->dev->netdev_ops->ndo_poll_controller)
>> + ret = false;
>> + }
>> + spin_unlock_irqrestore(&br->lock, flags);
>> + return count != 0 && ret;
>> +}
>> +
>> +static void br_poll_controller(struct net_device *br_dev)
>> +{
>> + struct netpoll *np = br_dev->npinfo->netpoll;
>> +
>> + if (np->real_dev != br_dev)
>> + netpoll_poll_dev(np->real_dev);
>> +}
>> +
>> +void br_netpoll_cleanup(struct net_device *br_dev)
>> +{
>> + struct net_bridge *br = netdev_priv(br_dev);
>> + struct net_bridge_port *p, *n;
>> + const struct net_device_ops *ops;
>> +
>> + br->dev->npinfo = NULL;
>> + list_for_each_entry_safe(p, n, &br->port_list, list) {
>> + if (p->dev) {
>> + ops = p->dev->netdev_ops;
>> + if (ops->ndo_netpoll_cleanup)
>> + ops->ndo_netpoll_cleanup(p->dev);
>> + else
>> + p->dev->npinfo = NULL;
>> + }
>> + }
>> +}
>> +
>> +#else
>> +
>> +void br_netpoll_cleanup(struct net_device *br_dev)
>> +{
>> +}
>> +
>> +#endif
>
> Could you use more stub functions to eliminate #ifdef's in code.
Probably no, because only br_netpoll_cleanup() will be called
no matter if CONFIG_NET_POLL_CONTROLLER is defined.
>> @@ -50,7 +51,13 @@ int br_dev_queue_push_xmit(struct sk_buf
>> else {
>> skb_push(skb, ETH_HLEN);
>>
>> - dev_queue_xmit(skb);
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + if (skb->dev->priv_flags & IFF_IN_NETPOLL) {
>> + netpoll_send_skb(skb->dev->npinfo->netpoll, skb);
>> + skb->dev->priv_flags &= ~IFF_IN_NETPOLL;
>> + } else
>> +#endif
>
> There is no protection on dev->priv_flags for SMP access.
> It would better bit value in dev->state if you are using it as control flag.
>
> Then you could use
> if (unlikely(test_and_clear_bit(__IN_NETPOLL, &skb->dev->state)))
> netpoll_send_skb(...)
>
Yes? netpoll_send_skb() needs to see IFF_IN_NETPOLL is set, so
we can't clear this bit before calling it.
But we do need a find a safe way to check/set this flag.
>> static void __br_deliver(const struct net_bridge_port *to, struct sk_buff *skb)
>> {
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + struct net_bridge *br = to->br;
>> + if (br->dev->priv_flags & IFF_IN_NETPOLL) {
>> + struct netpoll *np;
>> + to->dev->npinfo = skb->dev->npinfo;
>> + np = skb->dev->npinfo->netpoll;
>> + np->real_dev = np->dev = to->dev;
>> + to->dev->priv_flags |= IFF_IN_NETPOLL;
>> + }
>> +#endif
>
> This is n hot path, so use unlikely()
Ok, good point.
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> + if (br_devices_support_netpoll(br)) {
>> + br->dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
>> + if (br->dev->npinfo)
>> + dev->npinfo = br->dev->npinfo;
>> + } else if (!(br->dev->priv_flags & IFF_DISABLE_NETPOLL)) {
>> + br->dev->priv_flags |= IFF_DISABLE_NETPOLL;
>> + printk(KERN_INFO "New device %s does not support netpoll\n",
>> + dev->name);
>> + printk(KERN_INFO "Disabling netpoll for %s\n",
>> + br->dev->name);
>
> One message is sufficient.
>
Yes? The first messages explains the reason for the second message.
Thanks.
^ 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