On 03/22/2018 03:16 AM, Jakob Unterwurzacher wrote:
> On 21.03.18 21:52, John Fastabend wrote:
>> Can you try this,
>>
>> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>> index d4907b5..1e596bd 100644
>> --- a/include/net/sch_generic.h
>> +++ b/include/net/sch_generic.h
>> @@
On 03/22/2018 03:16 AM, Jakob Unterwurzacher wrote:
> On 21.03.18 21:52, John Fastabend wrote:
>> Can you try this,
>>
>> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>> index d4907b5..1e596bd 100644
>> --- a/include/net/sch_generic.h
>> +++ b/include/net/sch_generic.h
>> @@
On 21.03.18 21:52, John Fastabend wrote:
Can you try this,
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d4907b5..1e596bd 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -30,6 +30,7 @@ struct qdisc_rate_table {
enum qdisc_state_t {
On 21.03.18 21:52, John Fastabend wrote:
Can you try this,
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d4907b5..1e596bd 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -30,6 +30,7 @@ struct qdisc_rate_table {
enum qdisc_state_t {
On 03/21/2018 12:44 PM, Jakob Unterwurzacher wrote:
> On 21.03.18 19:43, John Fastabend wrote:
>> Thats my theory at least. Are you able to test a patch if I generate
>> one to fix this?
>
> Yes, no problem.
Can you try this,
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
On 03/21/2018 12:44 PM, Jakob Unterwurzacher wrote:
> On 21.03.18 19:43, John Fastabend wrote:
>> Thats my theory at least. Are you able to test a patch if I generate
>> one to fix this?
>
> Yes, no problem.
Can you try this,
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
On 21.03.18 19:43, John Fastabend wrote:
Thats my theory at least. Are you able to test a patch if I generate
one to fix this?
Yes, no problem.
I just tested with the flag change you suggested (see below, I had to
keep TCQ_F_CPUSTATS to prevent a crash) and I have NOT seen OOO so far.
On 21.03.18 19:43, John Fastabend wrote:
Thats my theory at least. Are you able to test a patch if I generate
one to fix this?
Yes, no problem.
I just tested with the flag change you suggested (see below, I had to
keep TCQ_F_CPUSTATS to prevent a crash) and I have NOT seen OOO so far.
On 03/21/2018 03:01 AM, Jakob Unterwurzacher wrote:
> On 16.03.18 11:26, Jakob Unterwurzacher wrote:
>> On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each other.
The test tool sends UDP packets containing a counter and listens on
On 03/21/2018 03:01 AM, Jakob Unterwurzacher wrote:
> On 16.03.18 11:26, Jakob Unterwurzacher wrote:
>> On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each other.
The test tool sends UDP packets containing a counter and listens on
On 16.03.18 11:26, Jakob Unterwurzacher wrote:
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each
other. The test tool sends UDP packets containing a counter and
listens on the other interface, it is available at
On 16.03.18 11:26, Jakob Unterwurzacher wrote:
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each
other. The test tool sends UDP packets containing a counter and
listens on the other interface, it is available at
On 19.03.18 13:32, Paolo Abeni wrote:
Is not clear to me if you can reproduce the bug with the vanilla
kernel, or if you need some out-of-tree nic driver. Can you please
clarify which NIC/driver are you using?
Yes I reproduced it with a vanilla kernel. I use two off-the-shelf USB
NICs, lsusb
On 19.03.18 13:32, Paolo Abeni wrote:
Is not clear to me if you can reproduce the bug with the vanilla
kernel, or if you need some out-of-tree nic driver. Can you please
clarify which NIC/driver are you using?
Yes I reproduced it with a vanilla kernel. I use two off-the-shelf USB
NICs, lsusb
Hi,
On Fri, 2018-03-16 at 11:26 +0100, Jakob Unterwurzacher wrote:
> On 15.03.18 23:30, John Fastabend wrote:
> > > I have reproduced it using two USB network cards connected to each other.
> > > The test tool sends UDP packets containing a counter and listens on the
> > > other interface, it
Hi,
On Fri, 2018-03-16 at 11:26 +0100, Jakob Unterwurzacher wrote:
> On 15.03.18 23:30, John Fastabend wrote:
> > > I have reproduced it using two USB network cards connected to each other.
> > > The test tool sends UDP packets containing a counter and listens on the
> > > other interface, it
On Friday, March 16, 2018, 11:26:47 AM CET Jakob Unterwurzacher wrote:
> On 15.03.18 23:30, John Fastabend wrote:
> >> I have reproduced it using two USB network cards connected to each other.
> >> The test tool sends UDP packets containing a counter and listens on the
> >> other interface, it
On Friday, March 16, 2018, 11:26:47 AM CET Jakob Unterwurzacher wrote:
> On 15.03.18 23:30, John Fastabend wrote:
> >> I have reproduced it using two USB network cards connected to each other.
> >> The test tool sends UDP packets containing a counter and listens on the
> >> other interface, it
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each other. The
test tool sends UDP packets containing a counter and listens on the other
interface, it is available at
https://github.com/jakob-tsd/pfifo_stress/blob/master/pfifo_stress.py
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each other. The
test tool sends UDP packets containing a counter and listens on the other
interface, it is available at
https://github.com/jakob-tsd/pfifo_stress/blob/master/pfifo_stress.py
On 03/15/2018 11:08 AM, Jakob Unterwurzacher wrote:
> On 14.03.18 05:03, John Fastabend wrote:
>> On 03/13/2018 11:35 AM, Dave Taht wrote:
>>> On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
>>> wrote:
During stress-testing our "ucan"
On 03/15/2018 11:08 AM, Jakob Unterwurzacher wrote:
> On 14.03.18 05:03, John Fastabend wrote:
>> On 03/13/2018 11:35 AM, Dave Taht wrote:
>>> On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
>>> wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
On 14.03.18 05:03, John Fastabend wrote:
On 03/13/2018 11:35 AM, Dave Taht wrote:
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we
On 14.03.18 05:03, John Fastabend wrote:
On 03/13/2018 11:35 AM, Dave Taht wrote:
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets
On 14.03.18 05:03, John Fastabend wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
delivered out-of-order.
Is the stress-testing tool available somewhere? What type of packets
are
On 14.03.18 05:03, John Fastabend wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
delivered out-of-order.
Is the stress-testing tool available somewhere? What type of packets
are
On 03/13/2018 11:35 AM, Dave Taht wrote:
> On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
> wrote:
>> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
>> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of
On 03/13/2018 11:35 AM, Dave Taht wrote:
> On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
> wrote:
>> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
>> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
>> delivered out-of-order.
>>
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
> delivered out-of-order.
>
> We
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
> delivered out-of-order.
>
> We have tracked the problem down to the driver
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on
Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of
packets are delivered out-of-order.
We have tracked the problem down to the driver interface level, and it
seems that the driver's
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on
Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of
packets are delivered out-of-order.
We have tracked the problem down to the driver interface level, and it
seems that the driver's
32 matches
Mail list logo