On Fri, 19 Oct 2018 17:59:21 +1030, Jonathan Woithe wrote:
> On 10/18/18 08:15, Jonathan Woithe wrote:
> > On Thu, Oct 18, 2018 at 08:03:32AM +0200, Heiner Kallweit wrote:
> > > Proposed fix is here:
> > > https://patchwork.ozlabs.org/patch/985014/
> > > Would
On Thu, Oct 18, 2018 at 01:52:33PM +0200, Holger Hoffstätte wrote:
> On 10/18/18 08:15, Jonathan Woithe wrote:
> > On Thu, Oct 18, 2018 at 08:03:32AM +0200, Heiner Kallweit wrote:
> > > Proposed fix is here:
> > > https://patchwork.ozlabs.org/patch/985014/
> > >
On Thu, Oct 18, 2018 at 08:03:32AM +0200, Heiner Kallweit wrote:
> On 18.10.2018 07:58, Jonathan Woithe wrote:
> > On Thu, Oct 18, 2018 at 01:30:51AM +0200, Francois Romieu wrote:
> >> Holger Hoffstätte :
> >> [...]
> >> The bug will induce delayed rx
On Thu, Oct 18, 2018 at 01:30:51AM +0200, Francois Romieu wrote:
> Holger Hoffstätte :
> [...]
> > I continued to use the BQL patch in my private tree after it was reverted
> > and also had occasional timeouts, but *only* after I started playing
> > with ethtool to change offload settings. Without
On Wed, Dec 20, 2017 at 03:50:11PM +1030, Jonathan Woithe wrote:
> On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote:
> > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote:
> > > This clearly indicates that not every card using the r8169 driver is
>
On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote:
> On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote:
> > This clearly indicates that not every card using the r8169 driver is
> > vulnerable to the problem. It also explains why Holger was unable to
&g
Hi again
This is a follow up to my earlier message.
On Tue, Dec 19, 2017 at 09:02:25AM +1030, Jonathan Woithe wrote:
> On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote:
> > Since I've seen your postings several times now with no comment or
> > resolution
>
Hi Holger
On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote:
> On 12/18/17 06:49, Jonathan Woithe wrote:
> > Resend to netdev. LKML CCed in case anyone in the wider kernel community
> > can suggest a way forward. Please CC responses if replying only to LKML.
&g
,
despite the identification of the commit which broke it. Cards using this
driver will therefore remain unusable for certain workloads utilising UDP.
- Original message from 14 Nov 2017 -
Date: Tue, 14 Nov 2017 16:09:23 +1030
From: Jonathan Woithe
To: netdev@vger.kernel.org
Subject: Re
22:50AM +0200, Francois Romieu wrote:
> > Jonathan Woithe :
> > [...]
> > > to mainline (in which case I'll keep watching out for it)? Or is the
> > > out-of-tree workaround mentioned above considered to be the long term
> > > fix for those who encounter
On Thu, Jun 23, 2016 at 01:22:50AM +0200, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > to mainline (in which case I'll keep watching out for it)? Or is the
> > out-of-tree workaround mentioned above considered to be the long term
> > fix for those who encou
On Thu, Jun 23, 2016 at 01:22:50AM +0200, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > to mainline (in which case I'll keep watching out for it)? Or is the
> > out-of-tree workaround mentioned above considered to be the long term
> > fix for those who encou
On Wed, Jun 22, 2016 at 01:09:57AM +0200, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > Is there any chance that this regression can be resolved? It's been 6
> > months since the last contact was received from the list in relation to this
> > issue. If
Hi all
On Wed, Jun 01, 2016 at 10:01:23AM +0930, Jonathan Woithe wrote:
> On Wed, May 18, 2016 at 04:21:37PM +0930, Jonathan Woithe wrote:
> > On Thu, Apr 07, 2016 at 12:14:18PM +0930, Jonathan Woithe wrote:
> > > On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wro
On Wed, May 18, 2016 at 04:21:37PM +0930, Jonathan Woithe wrote:
> On Thu, Apr 07, 2016 at 12:14:18PM +0930, Jonathan Woithe wrote:
> > On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wrote:
> > > On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
>
On Thu, Apr 07, 2016 at 12:14:18PM +0930, Jonathan Woithe wrote:
> On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wrote:
> > On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
> > > Jonathan Woithe :
> > > [...]
> > > > Any thought
On Thu, Apr 07, 2016 at 12:14:18PM +0930, Jonathan Woithe wrote:
> On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wrote:
> > On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
> > > Jonathan Woithe :
> > > [...]
> > > > Any thought
On Mon, Feb 08, 2016 at 01:03:19PM +1030, Jonathan Woithe wrote:
> On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
> > Jonathan Woithe :
> > [...]
> > > Any thoughts or progress at this stage? Are there further tests you need
> > > me
> >
Hi Francois
On Wed, Dec 02, 2015 at 12:58:52AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > Any thoughts or progress at this stage? Are there further tests you need me
> > to do ?
>
> Yes but you should expect two more days without signal.
FYI I am no
On Mon, Nov 23, 2015 at 12:02:44AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > I'm a little confused though as to which patch you want me to apply. There
> > was an inline patch against r8169.c in your message, and then there was
> > another patch
On Fri, Nov 20, 2015 at 11:45:34PM +0100, Francois Romieu wrote:
> The hardware stats are not exactly clear. Is the initial Tx - Rx packet
> difference (6) at the hardware stats level expected ?
Sorry, I missed this question earlier. When speaking to the external
device, each UDP command packet t
On Mon, Nov 23, 2015 at 12:02:44AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > I'm a little confused though as to which patch you want me to apply. There
> > was an inline patch against r8169.c in your message, and then there was
> > another patch
On Sat, Nov 21, 2015 at 11:36:27PM +0100, Francois Romieu wrote:
> Francois Romieu :
> [...]
>
> If you can crash your system at will, you may apply the patch below to
> da78dbff2e05630921c551dbbc70a4b7981a8fff ("r8169: remove work from irq
> handler.") parent (aka 1e874e041fc7c222cbd85b20c440607
On Thu, Nov 19, 2015 at 01:56:08AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > I could try. What's the most reliable way to determine this? Use regular
> > ethtool queries about the time of the failures?
>
> If you are neither space nor cpu c
On Thu, Nov 19, 2015 at 01:56:08AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > I could try. What's the most reliable way to determine this? Use regular
> > ethtool queries about the time of the failures?
>
> If you are neither space nor cpu c
On Wed, Nov 18, 2015 at 12:21:08AM +0100, Francois Romieu wrote:
> Jonathan Woithe :
> [...]
> > It would be advantageous if we could upgrade this Linux system to a kernel
> > more recent than 2.6.35.11, but that will require a resolution to this
> > problem. Since 2.6.3
Hi all
Back in March/April 2013 I instigated this thread in connection with what
appeared to be a regression in the r8169 driver. To briefly recap, we have
external hardware which transfers data at moderate rates (150-300 Mbits/sec)
to a Linux system using UDP packets. The transfer stream lasts
27 matches
Mail list logo
