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
> > > vulnerable to the
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
> > reproduce the res
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
> reproduce the result on his system: the PCIe cards do not appear to suffer
> from the pro
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
> > I've decided to try
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.
> >
> > It seems tha
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.
>
> It seems that this 4+ year old regression in the r8169 driver (documented in
> this thread on netdev
: r8169 regression: UDP packets dropped intermittantly
As far as I am aware there were no follow up comments to my last post on
this subject on 24 March 2017. The text of that post is included below for
reference. To summarise: a short test program which reliably triggered the
problem was written in
As far as I am aware there were no follow up comments to my last post on
this subject on 24 March 2017. The text of that post is included below for
reference. To summarise: a short test program which reliably triggered the
problem was written in the hope it would assist in the repair of this
regr
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 encounter the problem?
>
> It's a
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 encounter the problem?
>
> It's a
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 the problem?
It's a workaround. Nothing less, nothing more.
IIRC the ga311 irq signaling was a bit
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 the r8169 driver is to remain brok
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 the r8169 driver is to remain broken with respect to UDP traffic
> then we will have no choice but to factor
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 wrote:
> > > > On Wed, Dec
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:
> > > > Jonathan Woithe :
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 thoughts or progress at this stage? Are there fu
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 thoughts or progress at this stage? Are there fu
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
> > > to do ?
> >
> > Yes but you should ex
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 now back from annual leave a
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.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kern
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 to r8169.c in the form of an at
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 to r8169.c in the form of an at
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 to r8169.c in the form of an attachment. Both patches removed
> the include of asm/system.h but the rest
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
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 1e874e041fc7c222cbd85b20c4406070be1f687a) and
build it in a current tree (say 4.2).
If it works it will be
Jonathan Woithe :
[...]
> This indicates to me that in the fault condition, packets coming into the PC
> are being held by the lower layers (perhaps even the hardware) for a very
> long time, and in fact only seem to be released once a packet is queued for
> transmission.
>
> I then ran a test us
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 constrained:
>
> while : ; do
>
On Thu, 2015-11-19 at 22:44 +0100, Francois Romieu wrote:
> Eric Dumazet :
> [...]
> > This looks like a race when/if RX happens very shortly after one
> > transmit.
> >
> > Francois, are we really saving lot of cpu cycles testing status ?
>
> I'm not sure. An extra smp_rmb and three cache lines
Eric Dumazet :
[...]
> This looks like a race when/if RX happens very shortly after one
> transmit.
>
> Francois, are we really saving lot of cpu cycles testing status ?
I'm not sure. An extra smp_rmb and three cache lines at most when
there really isn't any work ? Probably not worth it.
Can yo
On Thu, 2015-11-19 at 17:27 +1030, Jonathan Woithe wrote:
> 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?
> >
>
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 constrained:
>
> while : ; do
>
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 constrained:
while : ; do
echo $(date +%s.%N):$(ethtool -d eth0 raw on | base64 -w 0):$(ethtool
-S eth0
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.35.11 works while current k
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.35.11 works while current kernels do not, the only other
> option is to stick with 2.6.35.11. Is ther
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
36 matches
Mail list logo
