Hi,
first of all, please keep me in CC as I am currently not subscribed to LKML.
> From: Tomas Szepe
> Date: Sun, 22 Feb 2015 01:41:51 +0100
>
Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results
in a driver that retains the problem.
>>>
>>> OK, could you test follow
From: Tomas Szepe
Date: Sun, 22 Feb 2015 01:41:51 +0100
>> > Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results
>> > in a driver that retains the problem.
>>
>> OK, could you test following patch instead ?
>
> Yup, but tough luck: 3.19.0 + 0bec3b70 + this patch -> problem pr
> > Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results
> > in a driver that retains the problem.
>
> OK, could you test following patch instead ?
Yup, but tough luck: 3.19.0 + 0bec3b70 + this patch -> problem present.
--
Tomas Szepe
--
To unsubscribe from this list: send th
On Sat, 2015-02-21 at 20:05 +0100, Tomas Szepe wrote:
> Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results
> in a driver that retains the problem.
OK, could you test following patch instead ?
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8
> > Could Tomas try following fix ?
>
> In addition -- Tomas, on your affected board -- did you try
> turning off gso/tso?
>
> Holger Hoffstätte mentioned on lkml that his affected r8169 nic is
> stable with xmit_more+bql after disabling gso/tso on the nic
>
> (ethtool -k $dev to display setting
> > David, please consider reverting
> >
> > 1e918876853aa85435e0f17fd8b4a92dcfff53d6
> > (r8169: add support for Byte Queue Limits)
> >
> > and
> >
> > 0bec3b700d106a8b0a34227b2976d1a582f1aab7
> > (r8169: add support for xmit_more)
> >
> > I cannot reproduce any hangs (tried for 2days with
Eric Dumazet wrote:
> On Sat, 2015-02-21 at 18:46 +0100, Florian Westphal wrote:
> > Eric Dumazet wrote:
> > > Hold on.
> > >
> > > I believe there is one race in the way you access skb->xmit_more _after_
> > >
> > > txd->opts1 = cpu_to_le32(status);
> > >
> > > After this point, TX might have
On Sat, 2015-02-21 at 18:46 +0100, Florian Westphal wrote:
> Eric Dumazet wrote:
> > Hold on.
> >
> > I believe there is one race in the way you access skb->xmit_more _after_
> >
> > txd->opts1 = cpu_to_le32(status);
> >
> > After this point, TX might have completed and TX completion already ha
Eric Dumazet wrote:
> Hold on.
>
> I believe there is one race in the way you access skb->xmit_more _after_
>
> txd->opts1 = cpu_to_le32(status);
>
> After this point, TX might have completed and TX completion already have
> freed skb
Hmm, I _thought_ HW would not start xmit of this descriptor
On Sat, 2015-02-21 at 11:31 +0100, Florian Westphal wrote:
> Tomas Szepe wrote:
> > > I tried to reproduce this without success so far on my RTL8168d/8111d
> > > device.
> > > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the
> > > last 5 hours and so far I saw no watchdog tx
On Sat, 21 Feb 2015 11:31:04 +0100, Florian Westphal wrote:
> Tomas Szepe wrote:
>> > I tried to reproduce this without success so far on my RTL8168d/8111d
>> > device.
>> > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the
>> > last 5 hours and so far I saw no watchdog tx t
Tomas Szepe wrote:
> > I tried to reproduce this without success so far on my RTL8168d/8111d
> > device.
> > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the
> > last 5 hours and so far I saw no watchdog tx timeouts.
> >
> > I'll keep this running for a day or so to see if
> > > Since linux-3.18.0, r8169 is having problems driving one of my add-on
> > > PCIe NICs. The interface is losing link for several seconds at a time,
> > > the frequency being about once a minute when the traffic is high.
> > >
> > > The first loss of link is accompanied by the message "NETDEV
Hi,
> > > Since linux-3.18.0, r8169 is having problems driving one of my add-on
> > > PCIe NICs. The interface is losing link for several seconds at a time,
> > > the frequency being about once a minute when the traffic is high.
> > >
> > > The first loss of link is accompanied by the message "N
Florian Westphal wrote:
> Tomas Szepe wrote:
> > Hi,
> >
> > Since linux-3.18.0, r8169 is having problems driving one of my add-on
> > PCIe NICs. The interface is losing link for several seconds at a time,
> > the frequency being about once a minute when the traffic is high.
> >
> > The first
On Fri, 06 Feb 2015 15:04:50 +0100, Tomas Szepe wrote:
> Unfortunately, I have to take this back. I made the conclusion too early.
> The problem appears with this patch applied, too, only perhaps later and
> with a different frequency pattern.
+1 can confirm - I also see the stack trace in quest
> > > Since linux-3.18.0, r8169 is having problems driving one of my add-on
> > > PCIe NICs. The interface is losing link for several seconds at a time,
> > > the frequency being about once a minute when the traffic is high.
> > > ...
> >
> > Thanks for reporting this! I'm no lkml subscriber and
Ehlo,
> > Since linux-3.18.0, r8169 is having problems driving one of my add-on
> > PCIe NICs. The interface is losing link for several seconds at a time,
> > the frequency being about once a minute when the traffic is high.
> > ...
>
> Thanks for reporting this! I'm no lkml subscriber and thus
Tomas Szepe wrote:
> Hi,
>
> Since linux-3.18.0, r8169 is having problems driving one of my add-on
> PCIe NICs. The interface is losing link for several seconds at a time,
> the frequency being about once a minute when the traffic is high.
>
> The first loss of link is accompanied by the messag
Hi,
Since linux-3.18.0, r8169 is having problems driving one of my add-on
PCIe NICs. The interface is losing link for several seconds at a time,
the frequency being about once a minute when the traffic is high.
The first loss of link is accompanied by the message "NETDEV WATCHDOG:
eth1 (r8169):
20 matches
Mail list logo
