* Re: [PATCH] ipv4: route.c cleanup
From: Eric Dumazet @ 2012-08-02 9:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120802.014534.1221330015548828529.davem@davemloft.net>
On Thu, 2012-08-02 at 01:45 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 02 Aug 2012 09:49:13 +0200
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Remove some unused includes and sysctls after route cache removal.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> I'm largely against removing the (now pointless) sysctls.
>
> If the settings do nothing, so be it.
>
> But it shouldn't generate warnings and errors during bootup,
> which is what removing them is going to do.
Are you referring to a stale key in your /etc/sysctl.conf ?
I see no distro setting any of the route knob in their sysctl.conf file.
[PATCH v2] ipv4: route.c cleanup
Remove unused includes after IP cache removal
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/route.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index c035251..67790ba 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -70,7 +70,6 @@
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/mm.h>
-#include <linux/bootmem.h>
#include <linux/string.h>
#include <linux/socket.h>
#include <linux/sockios.h>
@@ -80,7 +79,6 @@
#include <linux/netdevice.h>
#include <linux/proc_fs.h>
#include <linux/init.h>
-#include <linux/workqueue.h>
#include <linux/skbuff.h>
#include <linux/inetdevice.h>
#include <linux/igmp.h>
@@ -88,11 +86,9 @@
#include <linux/mroute.h>
#include <linux/netfilter_ipv4.h>
#include <linux/random.h>
-#include <linux/jhash.h>
#include <linux/rcupdate.h>
#include <linux/times.h>
#include <linux/slab.h>
-#include <linux/prefetch.h>
#include <net/dst.h>
#include <net/net_namespace.h>
#include <net/protocol.h>
^ permalink raw reply related
* Re: [PATCH] ipv4: route.c cleanup
From: David Miller @ 2012-08-02 9:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1343899420.9299.118.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Aug 2012 11:23:40 +0200
> On Thu, 2012-08-02 at 01:45 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 02 Aug 2012 09:49:13 +0200
>>
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > Remove some unused includes and sysctls after route cache removal.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> I'm largely against removing the (now pointless) sysctls.
>>
>> If the settings do nothing, so be it.
>>
>> But it shouldn't generate warnings and errors during bootup,
>> which is what removing them is going to do.
>
> Are you referring to a stale key in your /etc/sysctl.conf ?
>
> I see no distro setting any of the route knob in their sysctl.conf file.
I'm talking about anyone, and people do set these knobs. I've been
told by people at some large search engine that they, in fact, have
to :-)
> [PATCH v2] ipv4: route.c cleanup
>
> Remove unused includes after IP cache removal
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I'll apply this one, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-02 10:28 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Pavel Emelyanov, Linux Netdev List, David Miller
In-Reply-To: <878ve0dtw3.fsf@xmission.com>
On Tue, 2012-07-31 at 04:58 -0700, Eric W. Biederman wrote:
> Making lo the particularly interesting case.
BTW, I noticed in my benchmarks, that once I remove the contention on
dst refcnt (using a percpu cache of dsts), I have a strange performance
cost accessing net->loopback_dev->ifindex in ip_route_output_key.
Strange because I see no false sharing on this ifindex location for
loopback device.
So we probably can save some cycles adding a net->loopback_ifindex
to remove one dereference.
If ifindex are per network space, I guess we'll need to change
arp_hashfn() or else we'll use some slots more than others.
diff --git a/include/net/arp.h b/include/net/arp.h
index 7f7df93..37aac58 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -10,7 +10,7 @@ extern struct neigh_table arp_tbl;
static inline u32 arp_hashfn(u32 key, const struct net_device *dev, u32 hash_rnd)
{
- u32 val = key ^ dev->ifindex;
+ u32 val = key ^ (u32)(unsigned long)dev;
return val * hash_rnd;
}
^ permalink raw reply related
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: Fengguang Wu @ 2012-08-02 10:44 UTC (permalink / raw)
To: Greg KH
Cc: LKML, devel@driverdev.osuosl.org, Karsten Keil, Joe Perches,
open list:ISDN SUBSYSTEM
In-Reply-To: <20120802040158.GA11860@localhost>
[Add more CC]
On Thu, Aug 02, 2012 at 12:01:58PM +0800, Fengguang Wu wrote:
> Remove the non-sense isdnloop revision transform code, so as to fix:
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> drivers/isdn/isdnloop/isdnloop.c | 13 ++-----------
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> --- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-05-24 19:03:06.748430938 +0800
> +++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-02 11:57:16.806437909 +0800
> @@ -16,7 +16,7 @@
> #include <linux/sched.h>
> #include "isdnloop.h"
>
> -static char *revision = "$Revision: 1.11.6.7 $";
> +static char *revision = "1.11.6.7";
> static char *isdnloop_id = "loop0";
>
> MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
> @@ -1494,16 +1494,7 @@ isdnloop_addcard(char *id1)
> static int __init
> isdnloop_init(void)
> {
> - char *p;
> - char rev[10];
> -
> - if ((p = strchr(revision, ':'))) {
> - strcpy(rev, p + 1);
> - p = strchr(rev, '$');
> - *p = 0;
> - } else
> - strcpy(rev, " ??? ");
> - printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
> + printk(KERN_NOTICE "isdnloop-ISDN-driver Rev %s\n", revision);
>
> if (isdnloop_id)
> return (isdnloop_addcard(isdnloop_id));
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Olivier Sobrie @ 2012-08-02 10:53 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <5017DD5B.2030701@pengutronix.de>
Hello,
On Tue, Jul 31, 2012 at 03:27:55PM +0200, Marc Kleine-Budde wrote:
> We can continue the review process, this problem has to be sorted out
> before I can apply this patch to linux-can-next tree.
Ok.
> > 1) With the short circuit:
> >
> > I perform the test you described. It showed that the Kvaser passes from
> > ERROR-WARNING to ERROR-PASSIVE and then BUS-OFF. But after going to the
> > state BUS-OFF it comes back to ERROR-WARNING.
> >
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> > can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>
> Why don't we have any rx/tx numbers in the error frame?
Because the hardware seems to not update the tx/rx_errors_count
fields :-(
> From the hardware point of view the short circuit and open end tests
> look good. Please adjust the driver to turn off the CAN interface in
> case of a bus off if restart_ms is 0.
And in the case where restart_ms is not 0? Don't I've to put it off so
and drop the frame?
I actually implemeted it as you said and here is what I observed in
candump output with restart_ms set to 100 ms:
t0: Short circuit between CAN-H and CAN-L + cansend can1 123#1122
can1 2000008C [8] 00 04 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 2000008C [8] 00 10 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 200000C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
...
can1 2000008C [8] 00 04 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-warning}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 2000008C [8] 00 10 90 00 00 00 00 00 ERRORFRAME
controller-problem{rx-error-passive}
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-error
can1 200000C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
bus-off
bus-error
t1: short circuit removed
can1 123 [2] 11 22
can1 20000100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
restarted-after-bus-of
The echo coming before the restart looks weird? No?
Shouldn't we drop the frame once BUF-OFF is reached?
> >>>>> + if ((priv->can.state == CAN_STATE_ERROR_WARNING) ||
> >>>>> + (priv->can.state == CAN_STATE_ERROR_PASSIVE)) {
> >>>>> + cf->data[1] = (txerr > rxerr) ?
> >>>>> + CAN_ERR_CRTL_TX_PASSIVE
> >>>>> + : CAN_ERR_CRTL_RX_PASSIVE;
>
> Please use CAN_ERR_CRTL_RX_WARNING, CAN_ERR_CRTL_TX_WARNING where
> appropriate.
Ok. As the hardware doesn't report good values for txerr and rxerr, I'll
also remove the tests on txerr and rxerr.
I observed the same behavior with the original driver.
I asked Kvaser for this problem. I've to wait before their developer is
back (same for the GPL issue).
> >>>>> +static int kvaser_usb_get_berr_counter(const struct net_device *netdev,
> >>>>> + struct can_berr_counter *bec)
> >>>>> +{
> >>>>> + struct kvaser_usb_net_priv *priv = netdev_priv(netdev);
> >>>>> +
> >>>>> + bec->txerr = priv->bec.txerr;
> >>>>> + bec->rxerr = priv->bec.rxerr;
>
> I think you can copy the struct like this:
>
> *bec = priv->bec;
Thanks. I'll remove the function kvaser_usb_get_berr_counter as the
hardware seems to never report txerr and rxerr.
I'll look deeper at this driver during the week-end if possible...
Thanks a lot for your help,
--
Olivier
^ permalink raw reply
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: Greg KH @ 2012-08-02 10:56 UTC (permalink / raw)
To: Fengguang Wu
Cc: LKML, devel@driverdev.osuosl.org, Karsten Keil, Joe Perches,
open list:ISDN SUBSYSTEM
In-Reply-To: <20120802104456.GA21537@localhost>
On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote:
> [Add more CC]
That's not going to do much, you just sent them a patch they can't apply
without editing by hand :(
^ permalink raw reply
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: Dan Carpenter @ 2012-08-02 10:57 UTC (permalink / raw)
To: Fengguang Wu
Cc: Greg KH, devel@driverdev.osuosl.org, Joe Perches, Karsten Keil,
LKML, open list:ISDN SUBSYSTEM
In-Reply-To: <20120802104456.GA21537@localhost>
On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote:
> [Add more CC]
>
That's not helpful... Resend the patch to netdev in a way that
applies.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] isdnloop: fix and simplify isdnloop_init()
From: Fengguang Wu @ 2012-08-02 11:01 UTC (permalink / raw)
To: Dan Carpenter
Cc: Greg KH, devel@driverdev.osuosl.org, Joe Perches, Karsten Keil,
LKML, open list:ISDN SUBSYSTEM
In-Reply-To: <20120802105736.GJ4352@mwanda>
On Thu, Aug 02, 2012 at 01:57:36PM +0300, Dan Carpenter wrote:
> On Thu, Aug 02, 2012 at 06:44:56PM +0800, Fengguang Wu wrote:
> > [Add more CC]
> >
>
> That's not helpful... Resend the patch to netdev in a way that
> applies.
OK, sorry...
^ permalink raw reply
* [PATCH] isdnloop: fix and simplify isdnloop_init()
From: Fengguang Wu @ 2012-08-02 11:05 UTC (permalink / raw)
To: open list:ISDN SUBSYSTEM
Cc: Dan Carpenter, Greg KH, devel@driverdev.osuosl.org, Joe Perches,
Karsten Keil, LKML
Fix a buffer overflow bug by removing the revision transform code.
[ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[ 22.097508] isdnloop: (loop0) virtual card added
[ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[ 22.174400]
[ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[ 22.624071] Call Trace:
[ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
[ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
drivers/isdn/isdnloop/isdnloop.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
--- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-05-24 19:03:06.748430938 +0800
+++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-02 11:57:16.806437909 +0800
@@ -16,7 +16,7 @@
#include <linux/sched.h>
#include "isdnloop.h"
-static char *revision = "$Revision: 1.11.6.7 $";
+static char *revision = "1.11.6.7";
static char *isdnloop_id = "loop0";
MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
@@ -1494,16 +1494,7 @@ isdnloop_addcard(char *id1)
static int __init
isdnloop_init(void)
{
- char *p;
- char rev[10];
-
- if ((p = strchr(revision, ':'))) {
- strcpy(rev, p + 1);
- p = strchr(rev, '$');
- *p = 0;
- } else
- strcpy(rev, " ??? ");
- printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
+ printk(KERN_NOTICE "isdnloop-ISDN-driver Rev %s\n", revision);
if (isdnloop_id)
return (isdnloop_addcard(isdnloop_id));
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric W. Biederman @ 2012-08-02 11:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Pavel Emelyanov, Linux Netdev List, David Miller
In-Reply-To: <1343903310.9299.184.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Tue, 2012-07-31 at 04:58 -0700, Eric W. Biederman wrote:
>
>> Making lo the particularly interesting case.
>
>
> BTW, I noticed in my benchmarks, that once I remove the contention on
> dst refcnt (using a percpu cache of dsts), I have a strange performance
> cost accessing net->loopback_dev->ifindex in ip_route_output_key.
>
> Strange because I see no false sharing on this ifindex location for
> loopback device.
>
> So we probably can save some cycles adding a net->loopback_ifindex
> to remove one dereference.
I am going to let Pavel tackle the actual work because only migration
really cares and he is working on migration right now.
But assuming we merge the per network namespace ifindex counter we
can change net->loopback_dev->ifindex to LOOPBACK_IFINDEX and
define "#define LOOPBACK_IFINDEX 1"
Certainly that works in the initial network namespace today and might be
worth testing.
> If ifindex are per network space, I guess we'll need to change
> arp_hashfn() or else we'll use some slots more than others.
Darn. I hate being right about there being a few places to fix
up.
ndisc_hashfn also has the same limitation.
Eric
> diff --git a/include/net/arp.h b/include/net/arp.h
> index 7f7df93..37aac58 100644
> --- a/include/net/arp.h
> +++ b/include/net/arp.h
> @@ -10,7 +10,7 @@ extern struct neigh_table arp_tbl;
>
> static inline u32 arp_hashfn(u32 key, const struct net_device *dev, u32 hash_rnd)
> {
> - u32 val = key ^ dev->ifindex;
> + u32 val = key ^ (u32)(unsigned long)dev;
>
> return val * hash_rnd;
> }
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Marc Kleine-Budde @ 2012-08-02 11:56 UTC (permalink / raw)
To: Olivier Sobrie; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <20120802105358.GA23787@hposo>
[-- Attachment #1: Type: text/plain, Size: 4693 bytes --]
On 08/02/2012 12:53 PM, Olivier Sobrie wrote:
>>> 1) With the short circuit:
>>>
>>> I perform the test you described. It showed that the Kvaser passes from
>>> ERROR-WARNING to ERROR-PASSIVE and then BUS-OFF. But after going to the
>>> state BUS-OFF it comes back to ERROR-WARNING.
>>>
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
>>
>> Why don't we have any rx/tx numbers in the error frame?
>
> Because the hardware seems to not update the tx/rx_errors_count
> fields :-(
Okay.
>> From the hardware point of view the short circuit and open end tests
>> look good. Please adjust the driver to turn off the CAN interface in
>> case of a bus off if restart_ms is 0.
>
> And in the case where restart_ms is not 0? Don't I've to put it off so
> and drop the frame?
No, don't drop the frame. restart-ms != 0 means the controller is
automatically restarted after the specified time (if the controller
supports). Or in your and the at91 case, automatically.
> I actually implemeted it as you said and here is what I observed in
> candump output with restart_ms set to 100 ms:
>
> t0: Short circuit between CAN-H and CAN-L + cansend can1 123#1122
> can1 2000008C [8] 00 04 90 00 00 00 00 00 ERRORFRAME
> controller-problem{rx-error-warning}
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-error
> can1 2000008C [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> controller-problem{rx-error-passive}
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-error
> can1 200000C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-off
> bus-error
> ...
> can1 2000008C [8] 00 04 90 00 00 00 00 00 ERRORFRAME
> controller-problem{rx-error-warning}
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-error
> can1 2000008C [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> controller-problem{rx-error-passive}
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-error
> can1 200000C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME
> protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> bus-off
> bus-error
>
> t1: short circuit removed
> can1 123 [2] 11 22
> can1 20000100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
> restarted-after-bus-of
>
> The echo coming before the restart looks weird? No?
> Shouldn't we drop the frame once BUF-OFF is reached?
No, I don't think so. But wait for Wolfgang, here's more into error
handling then me.
>
>>>>>>> + if ((priv->can.state == CAN_STATE_ERROR_WARNING) ||
>>>>>>> + (priv->can.state == CAN_STATE_ERROR_PASSIVE)) {
>>>>>>> + cf->data[1] = (txerr > rxerr) ?
>>>>>>> + CAN_ERR_CRTL_TX_PASSIVE
>>>>>>> + : CAN_ERR_CRTL_RX_PASSIVE;
>>
>> Please use CAN_ERR_CRTL_RX_WARNING, CAN_ERR_CRTL_TX_WARNING where
>> appropriate.
> Ok. As the hardware doesn't report good values for txerr and rxerr, I'll
> also remove the tests on txerr and rxerr.
> I observed the same behavior with the original driver.
> I asked Kvaser for this problem. I've to wait before their developer is
> back (same for the GPL issue).
Okay.
>>>>>>> +static int kvaser_usb_get_berr_counter(const struct net_device *netdev,
>>>>>>> + struct can_berr_counter *bec)
>>>>>>> +{
>>>>>>> + struct kvaser_usb_net_priv *priv = netdev_priv(netdev);
>>>>>>> +
>>>>>>> + bec->txerr = priv->bec.txerr;
>>>>>>> + bec->rxerr = priv->bec.rxerr;
>>
>> I think you can copy the struct like this:
>>
>> *bec = priv->bec;
>
> Thanks. I'll remove the function kvaser_usb_get_berr_counter as the
> hardware seems to never report txerr and rxerr.
Sounds reasonable.
BTW: is it possible to update the firmware on these devices?
> I'll look deeper at this driver during the week-end if possible...
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Olivier Sobrie @ 2012-08-02 12:16 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <501A6AE7.9060508@pengutronix.de>
On Thu, Aug 02, 2012 at 01:56:23PM +0200, Marc Kleine-Budde wrote:
> BTW: is it possible to update the firmware on these devices?
Yes it possible. But I don't know how to do it... I never did it.
I saw on their website that they propose a zipfile with new firmwares.
Inside the zipfile there is a tool 'Update.exe' which, I suppose, does
the upgrade.
Kr,
--
Olivier
^ permalink raw reply
* Re: [PATCH] firmware: Remove obsolete Chelsio cxgb3 firmware
From: Tim Gardner @ 2012-08-02 12:28 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, paul.gortmaker, ben, JBottomley, dan.j.williams,
divy, netdev
In-Reply-To: <20120802.002000.2023014747210925552.davem@davemloft.net>
On 08/02/2012 01:20 AM, David Miller wrote:
>
> "git am" refuses to apply this to current 'net':
>
> Applying: firmware: Remove obsolete Chelsio cxgb3 firmware
> error: removal patch leaves file contents
> error: firmware/cxgb3/t3fw-7.10.0.bin.ihex: patch does not apply
>
Paul Gortmaker suggested I use 'git format-patch --irreversible-delete'
to produce shorter patches, but then even I can't reapply it.
How about a pull request against net-next instead ?
The following changes since commit 1a9b4993b70fb1884716902774dc9025b457760d:
Merge branch 'upstream' of
git://git.linux-mips.org/pub/scm/ralf/upstream-linus (2012-08-01
16:47:15 -0700)
are available in the git repository at:
git://kernel.ubuntu.com/rtg/net-next.git master
for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
-0600)
----------------------------------------------------------------
Tim Gardner (1):
firmware: Remove obsolete Chelsio cxgb3 firmware
firmware/Makefile | 1 -
firmware/cxgb3/t3fw-7.10.0.bin.ihex | 1935
-----------------------------------
2 files changed, 1936 deletions(-)
delete mode 100644 firmware/cxgb3/t3fw-7.10.0.bin.ihex
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: [PATCH] cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN
From: Peter Meiser @ 2012-08-02 12:30 UTC (permalink / raw)
To: public-netdev-u79uwXL29TY76Z2rM5mHXA,
public-linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1343155402.29196.7.camel@dcbw.foobar.com>
Hello,
looking at http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Main_Page#Supported_devices, there are branded Ericsson devices from Dell and Toshiba.
The to-be-added vendor IDs are 0x413c for Dell and 0x0930 for Toshiba.
Please find attached a patch to add these vendor IDs.
Signed-off-by: Peter Meiser <meiser@gmx-topmail.de>
---
diff -Naur a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1233,6 +1233,26 @@
.driver_info = (unsigned long) &wwan_info,
},
+ /* Dell branded MBM devices like DW5550 */
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x413c,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) &wwan_info,
+ },
+
+ /* Toshiba branded MBM devices */
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x0930,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) &wwan_info,
+ },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Marc Kleine-Budde @ 2012-08-02 12:33 UTC (permalink / raw)
To: Olivier Sobrie; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <20120802121643.GA12913@hposo>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On 08/02/2012 02:16 PM, Olivier Sobrie wrote:
> On Thu, Aug 02, 2012 at 01:56:23PM +0200, Marc Kleine-Budde wrote:
>> BTW: is it possible to update the firmware on these devices?
>
> Yes it possible. But I don't know how to do it... I never did it.
> I saw on their website that they propose a zipfile with new firmwares.
> Inside the zipfile there is a tool 'Update.exe' which, I suppose, does
> the upgrade.
...on windows only :). If they would be cool, they support dfu.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: David Stevens @ 2012-08-02 12:58 UTC (permalink / raw)
To: Dragos Ilie; +Cc: netdev, netdev-owner
In-Reply-To: <CAOLNa-dCpLG4XCarzbSb=ptu-KGVX_Fghv4Z_CDQ8HBF_n-rGQ@mail.gmail.com>
netdev-owner@vger.kernel.org wrote on 07/26/2012 10:57:43 AM:
> RFC 3810 says that the timeout should be computed as
> Robustness_Variable * Query_Interval + Query_Response_Interval. This
> suggests that the line where switchback is computed should be changed
> to something like
>
> switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
>
> where 125 is the default Query_Interval in seconds
Dragos,
I agree that it's too short, but this shouldn't be using the
default value, but rather the actual value of the querier, if one is
present,
as calculated from a QQIC in a query. I suggest saving the QQI,
decoded, in a new "idev->mc_qqi" which should be initialized to 125
but updated by received queries and then using:
switchback = idev->mc_qrv * idev->mc_qqi * HZ + max_delay;
+-DLS
^ permalink raw reply
* [PATCH 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-02 13:00 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, netdev
Cc: mypopydev
Current kernel change the skb's net device with output device before netfilter FORWARD chain,
that will lead to can't match the IPv6 multicast packets with input net device in netfilter
FORWARD chain.
the test case for reproduce this issue as follow:
IPv6 multicast udp stream from eth0(input device) to eth1(output device)
Dst Addr: Port
{ff03::4}:6789 --->
Router
+---------------------------+
-------> | [eth0] --FORWARD--> [eth1]| ------->
+---------------------------+
ip6tables -I FORWARD -p udp -i eth0 -o eth1 --dst ff03::4 -j ACCEPT [first rules ]
ip6tables -A FORWARD -p udp -i eth1 -o eth1 --dst ff03::4 -j ACCEPT [second rules]
Before fix this issue, it will match the second rules not the first rules. you can used
command "ip6tables -L -vnx" to check the match result.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv6/ip6mr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 4532973..a9d3dd7 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1946,7 +1946,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
* result in receiving multiple packets.
*/
dev = vif->dev;
- skb->dev = dev;
+
vif->pkt_out++;
vif->bytes_out += skb->len;
--
1.7.2.5
^ permalink raw reply related
* Is it the right time to write to you?))
From: Justina Tores @ 2012-08-02 13:12 UTC (permalink / raw)
To: steve@aviaselect.com
I'm ur sweetest strawberry. A chick from your hottest fantasies!
I could demonstrate images of mine if you want it and u'll understand that I am right.
All of ur dreams would be about me!
My name is Justina and I'm a very playful female.
Let's have some chat and there're no hesitations u will be wishing me! Maybe we will go somewhere, go traveling or have fun in my bedroom.
Let's start satisfying ur fantasies together, honey!
^ permalink raw reply
* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Olivier Sobrie @ 2012-08-02 13:20 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <501A73B4.6030203@pengutronix.de>
On Thu, Aug 02, 2012 at 02:33:56PM +0200, Marc Kleine-Budde wrote:
> On 08/02/2012 02:16 PM, Olivier Sobrie wrote:
> > On Thu, Aug 02, 2012 at 01:56:23PM +0200, Marc Kleine-Budde wrote:
> >> BTW: is it possible to update the firmware on these devices?
> >
> > Yes it possible. But I don't know how to do it... I never did it.
> > I saw on their website that they propose a zipfile with new firmwares.
> > Inside the zipfile there is a tool 'Update.exe' which, I suppose, does
> > the upgrade.
>
> ...on windows only :). If they would be cool, they support dfu.
Indeed. I'll check if they are cool ;-)
--
Olivier
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: Dragos Ilie @ 2012-08-02 13:28 UTC (permalink / raw)
To: David Stevens; +Cc: netdev, netdev-owner
In-Reply-To: <OFB6FB6105.8DE1252A-ON85257A4E.004637D4-85257A4E.00474EEF@us.ibm.com>
On Thu, Aug 2, 2012 at 2:58 PM, David Stevens <dlstevens@us.ibm.com> wrote:
> netdev-owner@vger.kernel.org wrote on 07/26/2012 10:57:43 AM:
>
>> RFC 3810 says that the timeout should be computed as
>> Robustness_Variable * Query_Interval + Query_Response_Interval. This
>> suggests that the line where switchback is computed should be changed
>> to something like
>>
>> switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
>>
>> where 125 is the default Query_Interval in seconds
>
> Dragos,
> I agree that it's too short, but this shouldn't be using the
> default value, but rather the actual value of the querier, if one is
> present,
> as calculated from a QQIC in a query. I suggest saving the QQI,
> decoded, in a new "idev->mc_qqi" which should be initialized to 125
> but updated by received queries and then using:
>
> switchback = idev->mc_qrv * idev->mc_qqi * HZ + max_delay;
>
> +-DLS
>
David,
MLDv1 packets do not have a QQIC field in the Query header. That is a
available for MLDv2 only. Consequently, MLDv1 queriers should fallback
on the Query Interval variable, which has a default value of 125
seconds. Since the Query Interval value is not user-configurable, I
assume that using the default value is a reasonable choice.
RFC 3810(MLDv2) does mention that the Older Version Querier Present
Timeout must be calculated using the Query Interval from the last
received Query. I think the RFC is wrong on that point because I don't
see how a MLDv1 querier can convey its Query Interval to a listener.
Regards,
Dragos
^ permalink raw reply
* Re: v3.5: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: George Spelvin @ 2012-08-02 13:32 UTC (permalink / raw)
To: romieu; +Cc: linux, netdev
In-Reply-To: <20120801232953.3791.qmail@science.horizon.com>
My, that was exciting.
I rebooted with the drastic timeout reduction I proposed last night.
(Actuallly, I compiled a version before I realized TSO could increase the
output size, so it was set to (HZ/150) = 2 jiffies.)
Anyway, it worked fine last night, and *didn't* display the NETDEV
WATCHDOG warning on reboot.
But this morning at uptime 12 hours, (and as the office was filling up
in the morning, although there certainly was *some* traffic overnight),
things went pear-shaped:
Aug 2 12:45:11: ------------[ cut here ]------------
Aug 2 12:45:11: WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xe9/0x154()
Aug 2 12:45:11: Hardware name: MS-7376
Aug 2 12:45:11: NETDEV WATCHDOG: inside (r8169): transmit queue 0 timed out
Aug 2 12:45:11: Pid: 0, comm: swapper/3 Not tainted 3.5.0-00021-gc432f46 #162
Aug 2 12:45:11: Call Trace:
Aug 2 12:45:11: <IRQ> [<ffffffff8131d2c2>] ? dev_watchdog+0xe9/0x154
Aug 2 12:45:11: [<ffffffff810254c9>] ? warn_slowpath_common+0x71/0x85
Aug 2 12:45:11: [<ffffffff8131d1d9>] ? netif_tx_lock+0x7a/0x7a
Aug 2 12:45:11: [<ffffffff81025541>] ? warn_slowpath_fmt+0x45/0x4a
Aug 2 12:45:11: [<ffffffff8103cf28>] ? hrtimer_interrupt+0x100/0x1a4
Aug 2 12:45:11: [<ffffffff8131d1c6>] ? netif_tx_lock+0x67/0x7a
Aug 2 12:45:11: [<ffffffff8131d2c2>] ? dev_watchdog+0xe9/0x154
Aug 2 12:45:11: [<ffffffff8104e800>] ? clockevents_program_event+0x9a/0xb6
Aug 2 12:45:11: [<ffffffff8102ea43>] ? run_timer_softirq+0x17e/0x20b
Aug 2 12:45:11: [<ffffffff8102a9b1>] ? __do_softirq+0x80/0x102
Aug 2 12:45:11: [<ffffffff81411f4c>] ? call_softirq+0x1c/0x30
Aug 2 12:45:11: [<ffffffff810032f4>] ? do_softirq+0x2c/0x60
Aug 2 12:45:11: [<ffffffff8102abe4>] ? irq_exit+0x3a/0x91
Aug 2 12:45:11: [<ffffffff81003141>] ? do_IRQ+0x81/0x97
Aug 2 12:45:11: [<ffffffff81410567>] ? common_interrupt+0x67/0x67
Aug 2 12:45:11: <EOI> [<ffffffff81007d63>] ? default_idle+0x1e/0x32
Aug 2 12:45:11: [<ffffffff81007e87>] ? amd_e400_idle+0xb7/0xd4
Aug 2 12:45:11: [<ffffffff81008501>] ? cpu_idle+0x58/0x98
Aug 2 12:45:11: ---[ end trace d46f8d5c6451870e ]---
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: net_ratelimit: 255 callbacks suppressed
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: net_ratelimit: 258 callbacks suppressed
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: net_ratelimit: 262 callbacks suppressed
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: net_ratelimit: 262 callbacks suppressed
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: net_ratelimit: 259 callbacks suppressed
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: net_ratelimit: 261 callbacks suppressed
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: net_ratelimit: 248 callbacks suppressed
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: net_ratelimit: 248 callbacks suppressed
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: net_ratelimit: 258 callbacks suppressed
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:45:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: net_ratelimit: 258 callbacks suppressed
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: net_ratelimit: 252 callbacks suppressed
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: net_ratelimit: 253 callbacks suppressed
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: net_ratelimit: 260 callbacks suppressed
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: net_ratelimit: 261 callbacks suppressed
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:21: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: net_ratelimit: 269 callbacks suppressed
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:26: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: net_ratelimit: 263 callbacks suppressed
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:31: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: net_ratelimit: 260 callbacks suppressed
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:36: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: net_ratelimit: 266 callbacks suppressed
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:41: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: net_ratelimit: 254 callbacks suppressed
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:46: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: net_ratelimit: 257 callbacks suppressed
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:51: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:52: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:52: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: net_ratelimit: 257 callbacks suppressed
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:56: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:57: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:57: r8169 0000:02:00.0: inside: link up
Aug 2 12:46:57: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: net_ratelimit: 246 callbacks suppressed
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:01: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:02: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:02: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:02: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:02: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:06: net_ratelimit: 265 callbacks suppressed
Aug 2 12:47:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:06: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:07: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:11: net_ratelimit: 252 callbacks suppressed
Aug 2 12:47:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:11: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:12: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:16: net_ratelimit: 254 callbacks suppressed
Aug 2 12:47:16: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:17: r8169 0000:02:00.0: inside: link up
# The following is me trying "ifconfig down" and "ip link set up" from
# the console to try to restart things. First attempts didn't work, but
# something seems to have fixed it not long after.
Aug 2 12:47:18: r8169 0000:02:00.0: inside: link down
Aug 2 12:47:18: r8169 0000:02:00.0: inside: link down
Aug 2 12:47:18: IPv6: ADDRCONF(NETDEV_UP): inside: link is not ready
Aug 2 12:47:18: r8169 0000:02:00.0: inside: link down
Aug 2 12:47:21: IPv6: ADDRCONF(NETDEV_CHANGE): inside: link becomes ready
Aug 2 12:47:21: net dmz: Setting full-duplex based on MII#1 link partner capability of 45e1
Aug 2 12:47:21: net cable: Setting full-duplex based on MII#1 link partner capability of 41e1
Aug 2 12:47:37: r8169 0000:02:00.0: inside: link down
Aug 2 12:47:37: r8169 0000:02:00.0: inside: link down
Aug 2 12:47:37: IPv6: ADDRCONF(NETDEV_UP): inside: link is not ready
Aug 2 12:47:39: net_ratelimit: 58 callbacks suppressed
Aug 2 12:47:39: r8169 0000:02:00.0: inside: link up
Aug 2 12:47:39: IPv6: ADDRCONF(NETDEV_CHANGE): inside: link becomes ready
Aug 2 12:47:40: net dmz: Setting full-duplex based on MII#1 link partner capability of 45e1
Aug 2 12:47:40: net cable: Setting full-duplex based on MII#1 link partner capability of 41e1
After it came back, I did a few simple stress tests, which it survived just fine:
ping -c 1000000 -l 50 -f:
1000000 packets transmitted, 1000000 received, 0% packet loss, time 14503ms
rtt min/avg/max/mdev = 0.043/0.138/0.686/0.053 ms, pipe 50, ipg/ewma 0.014/0.102 ms
ping -s 1472 -c 1000000 -l 50 -f:
1000000 packets transmitted, 1000000 received, 0% packet loss, time 30672ms
rtt min/avg/max/mdev = 0.156/0.330/1.364/0.055 ms, pipe 50, ipg/ewma 0.030/0.350 ms
4 GiB of wire-speed copy from /dev/zero to /dev/null (dd bs=65536 count=65536 | nc):
4294967296 bytes (4.3 GB) copied, 36.6281 s, 117 MB/s
Very odd. I'm posting this in case it is of any debugging assistance.
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: David Stevens @ 2012-08-02 13:57 UTC (permalink / raw)
To: Dragos Ilie; +Cc: netdev, netdev-owner
In-Reply-To: <CAOLNa-dj1N-3Lo6Bu8X4H51gxBs4B2V0qWSDFQ-2qQzjEApJfw@mail.gmail.com>
Dragos Ilie <dragos.ilie@gmail.com> wrote on 08/02/2012 09:28:49 AM:
> MLDv1 packets do not have a QQIC field in the Query header. That is a
> available for MLDv2 only. Consequently, MLDv1 queriers should fallback
> on the Query Interval variable, which has a default value of 125
> seconds. Since the Query Interval value is not user-configurable, I
> assume that using the default value is a reasonable choice.
The QQIC would come from v2 queries prior to the v1 query that
triggered us to switch to v1. But, see below.
> RFC 3810(MLDv2) does mention that the Older Version Querier Present
> Timeout must be calculated using the Query Interval from the last
> received Query. I think the RFC is wrong on that point because I don't
> see how a MLDv1 querier can convey its Query Interval to a listener.
I'll look through this some more. I think using a fixed timeout
is a bad idea since it doesn't account for shorter or longer interval
queriers intentionally configured that way. Ideally it should,
of course, be a positive indication that the v1 querier is gone
based on v1 querier data (your point).
+-DLS
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: Dragos Ilie @ 2012-08-02 14:03 UTC (permalink / raw)
To: David Stevens; +Cc: netdev, netdev-owner
In-Reply-To: <OF675087EF.EDC93ADE-ON85257A4E.004B2D96-85257A4E.004CB6BE@us.ibm.com>
On Thu, Aug 2, 2012 at 3:57 PM, David Stevens <dlstevens@us.ibm.com> wrote:
> Dragos Ilie <dragos.ilie@gmail.com> wrote on 08/02/2012 09:28:49 AM:
>
>> MLDv1 packets do not have a QQIC field in the Query header. That is a
>> available for MLDv2 only. Consequently, MLDv1 queriers should fallback
>> on the Query Interval variable, which has a default value of 125
>> seconds. Since the Query Interval value is not user-configurable, I
>> assume that using the default value is a reasonable choice.
>
> The QQIC would come from v2 queries prior to the v1 query that
> triggered us to switch to v1. But, see below.
How about the scenario where you have only MLDv1 queriers? There will
be no prior v2 query
>
>> RFC 3810(MLDv2) does mention that the Older Version Querier Present
>> Timeout must be calculated using the Query Interval from the last
>> received Query. I think the RFC is wrong on that point because I don't
>> see how a MLDv1 querier can convey its Query Interval to a listener.
>
> I'll look through this some more. I think using a fixed timeout
> is a bad idea since it doesn't account for shorter or longer interval
> queriers intentionally configured that way. Ideally it should,
> of course, be a positive indication that the v1 querier is gone
> based on v1 querier data (your point).
>
> +-DLS
>
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: David Stevens @ 2012-08-02 14:25 UTC (permalink / raw)
To: Dragos Ilie; +Cc: netdev, netdev-owner
In-Reply-To: <CAOLNa-cMkHaFxoWym-oVT6i7ZZ25tZPxaAEcwUuT1TB4kPGfag@mail.gmail.com>
netdev-owner@vger.kernel.org wrote on 08/02/2012 10:03:24 AM:
> > The QQIC would come from v2 queries prior to the v1 query that
> > triggered us to switch to v1. But, see below.
>
> How about the scenario where you have only MLDv1 queriers? There will
> be no prior v2 query
Yes, this is why I suggested initializing it to the
default of 125. If we actually saw v2 queries with different
intervals, we'd adjust longer or shorter, but use the default
only when we had no queries to update it.
+-DLS
^ permalink raw reply
* Huge performance degradation for UDP between kernel 2.4.17 and 2.6.x
From: leroy christophe @ 2012-08-02 14:02 UTC (permalink / raw)
To: netdev
Hi
I'm having a big issue with UDP. Using a powerpc board (MPC860).
With our board running kernel 2.4.17, I'm able to send 160000 voice
packets (UDP, 96 bytes per packet) in 11 seconds.
With the same board running either Kernel 2.6.35.14 or Kernel 3.4.7, I
need 55 seconds to send the same amount of packets.
Is there anything to tune in order to get same output rate as with
Kernel 2.4 ?
Regards
Christophe
^ 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