Uhh, sorry, just found the original submission [1].
[1] https://marc.info/?l=linux-netdev&m=151009763926816&w=2
10.11.2017 14:15, Oleksandr Natalenko wrote:
Hi.
I'm running the machine with this patch applied for 7 hours now, and
the warning hasn't appeared yet. Typically, it should be there w
Hi.
I'm running the machine with this patch applied for 7 hours now, and the
warning hasn't appeared yet. Typically, it should be there within the
first hour.
I'll keep an eye on it for a longer time, but as of now it looks good.
Some explanation on this please?
Thanks!
06.11.2017 23:27, Y
On Fri, Oct 27, 2017 at 1:38 PM, Eric Dumazet wrote:
>
> On Wed, Oct 25, 2017 at 10:37 PM, Yuchung Cheng wrote:
> > On Wed, Oct 25, 2017 at 7:07 PM, Alexei Starovoitov
> > wrote:
> >>
> >> On Thu, Sep 28, 2017 at 04:36:58PM -0700, Yuchung Cheng wrote:
> >> > On Thu, Sep 28, 2017 at 1:14 AM, Olek
On Wed, Oct 25, 2017 at 10:37 PM, Yuchung Cheng wrote:
> On Wed, Oct 25, 2017 at 7:07 PM, Alexei Starovoitov
> wrote:
>>
>> On Thu, Sep 28, 2017 at 04:36:58PM -0700, Yuchung Cheng wrote:
>> > On Thu, Sep 28, 2017 at 1:14 AM, Oleksandr Natalenko
>> > wrote:
>> > > Hi.
>> > >
>> > > Won't tell abo
On Wed, Oct 25, 2017 at 7:07 PM, Alexei Starovoitov
wrote:
>
> On Thu, Sep 28, 2017 at 04:36:58PM -0700, Yuchung Cheng wrote:
> > On Thu, Sep 28, 2017 at 1:14 AM, Oleksandr Natalenko
> > wrote:
> > > Hi.
> > >
> > > Won't tell about panic in tcp_sacktag_walk() since I cannot trigger it
> > > inte
On Thu, Sep 28, 2017 at 04:36:58PM -0700, Yuchung Cheng wrote:
> On Thu, Sep 28, 2017 at 1:14 AM, Oleksandr Natalenko
> wrote:
> > Hi.
> >
> > Won't tell about panic in tcp_sacktag_walk() since I cannot trigger it
> > intentionally, but setting net.ipv4.tcp_retrans_collapse to 0 *does not* fix
> >
On Thu, Sep 28, 2017 at 1:14 AM, Oleksandr Natalenko
wrote:
> Hi.
>
> Won't tell about panic in tcp_sacktag_walk() since I cannot trigger it
> intentionally, but setting net.ipv4.tcp_retrans_collapse to 0 *does not* fix
> warning in tcp_fastretrans_alert() for me.
Hi Oleksandr: no retrans_collaps
Hi.
Won't tell about panic in tcp_sacktag_walk() since I cannot trigger it
intentionally, but setting net.ipv4.tcp_retrans_collapse to 0 *does not* fix
warning in tcp_fastretrans_alert() for me.
On středa 27. září 2017 2:18:32 CEST Yuchung Cheng wrote:
> On Tue, Sep 26, 2017 at 5:12 PM, Yuchung
On Tue, Sep 26, 2017 at 5:12 PM, Yuchung Cheng wrote:
> On Tue, Sep 26, 2017 at 6:10 AM, Roman Gushchin wrote:
>>> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>>> >
>>> > > Hello.
>>> > >
>>> > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in
>>> > > the
>>> >
On Tue, Sep 26, 2017 at 6:10 AM, Roman Gushchin wrote:
>> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>> >
>> > > Hello.
>> > >
>> > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in
>> > > the
>> > > warning shown below. Most of the time it is harmless, but rar
> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
> >
> > > Hello.
> > >
> > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> > > warning shown below. Most of the time it is harmless, but rarely it just
> > > causes either freeze or (I believe, this is related
On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>
> > Hello.
> >
> > Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> > warning shown below. Most of the time it is harmless, but rarely it just
> > causes either freeze or (I believe, this is related too) panic in
> Hello.
>
> Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> warning shown below. Most of the time it is harmless, but rarely it just
> causes either freeze or (I believe, this is related too) panic in
> tcp_sacktag_walk() (because sk_buff passed to this function is
On Tue, Sep 19, 2017 at 4:04 AM, Oleksandr Natalenko
wrote:
> Hi.
>
> 18.09.2017 23:40, Yuchung Cheng wrote:
>>
>> I assume this kernel does not have the patch that Neal proposed in his
>> first reply?
>
>
> Correct.
>
>> The main warning needs to be triggered by another peculiar SACK that
>> kick
And 2 more events:
===
$ dmesg --time-format iso | grep RIP
…
2017-09-19T16:52:21,623328+0200 RIP: 0010:tcp_undo_cwnd_reduction+0xbd/0xd0
2017-09-19T16:52:40,455296+0200 RIP: 0010:tcp_fastretrans_alert+0x7c8/0x990
2017-09-19T16:52:41,047378+0200 RIP: 0010:tcp_undo_cwnd_reduction+0xbd/0xd0
…
2017-0
Hi.
18.09.2017 23:40, Yuchung Cheng wrote:
I assume this kernel does not have the patch that Neal proposed in his
first reply?
Correct.
The main warning needs to be triggered by another peculiar SACK that
kicks the sender into recovery again (after undo). Please let it run
longer if possible
On Mon, Sep 18, 2017 at 1:46 PM, Oleksandr Natalenko
wrote:
> Actually, same warning was just triggered with RACK enabled. But main warning
> was not triggered in this case.
Thanks.
I assume this kernel does not have the patch that Neal proposed in his
first reply?
The main warning needs to be t
Actually, same warning was just triggered with RACK enabled. But main warning
was not triggered in this case.
===
Sep 18 22:44:32 defiant kernel: [ cut here ]
Sep 18 22:44:32 defiant kernel: WARNING: CPU: 1 PID: 702 at net/ipv4/
tcp_input.c:2392 tcp_undo_cwnd_reduction+0xb
OK,
with:
net.ipv4.tcp_recovery = 0
net.ipv4.tcp_fack = 0
and your patch I got the following warning within 10 min uptime:
===
Sep 18 22:18:34 defiant kernel: [ cut here ]
Sep 18 22:18:34 defiant kernel: WARNING: CPU: 0 PID: 702 at net/ipv4/
tcp_input.c:2392 tcp_undo_cwn
On pondělí 18. září 2017 20:01:42 CEST Yuchung Cheng wrote:
> Yes since it is disabled in the upstream by default. Although you can
> experiment FACK enabled additionally.
OK.
> Do we know the crash you first experienced is tied to this issue?
No, unfortunately. I wasn't able to re-create it aga
On Mon, Sep 18, 2017 at 10:59 AM, Oleksandr Natalenko
wrote:
> OK. Should I keep FACK disabled?
Yes since it is disabled in the upstream by default. Although you can
experiment FACK enabled additionally.
Do we know the crash you first experienced is tied to this issue?
>
> On pondělí 18. září 20
OK. Should I keep FACK disabled?
On pondělí 18. září 2017 19:51:21 CEST Yuchung Cheng wrote:
> Can you try this patch to verify my theory with tcp_recovery=0 and 1? thanks
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 5af2f04f8859..9253d9ee7d0e 100644
> --- a/net/ipv4/tcp_i
On Mon, Sep 18, 2017 at 10:18 AM, Yuchung Cheng wrote:
> On Sun, Sep 17, 2017 at 11:43 AM, Oleksandr Natalenko
> wrote:
>> Hi.
>>
>> Just to note that it looks like disabling RACK and re-enabling FACK prevents
>> warning from happening:
>>
>> net.ipv4.tcp_fack = 1
>> net.ipv4.tcp_recovery = 0
>>
On Sun, Sep 17, 2017 at 11:43 AM, Oleksandr Natalenko
wrote:
> Hi.
>
> Just to note that it looks like disabling RACK and re-enabling FACK prevents
> warning from happening:
>
> net.ipv4.tcp_fack = 1
> net.ipv4.tcp_recovery = 0
>
> Hope I get semantics of these tunables right.
Thanks.
One differe
Hi.
Just to note that it looks like disabling RACK and re-enabling FACK prevents
warning from happening:
net.ipv4.tcp_fack = 1
net.ipv4.tcp_recovery = 0
Hope I get semantics of these tunables right.
On pátek 15. září 2017 21:04:36 CEST Oleksandr Natalenko wrote:
> Hello.
>
> With net.ipv4.tcp
Hello.
With net.ipv4.tcp_fack set to 0 the warning still appears:
===
» sysctl net.ipv4.tcp_fack
net.ipv4.tcp_fack = 0
» LC_TIME=C dmesg -T | grep WARNING
[Fri Sep 15 20:40:30 2017] WARNING: CPU: 1 PID: 711 at net/ipv4/tcp_input.c:
2826 tcp_fastretrans_alert+0x7c8/0x990
[Fri Sep 15 20:40:30
On Fri, Sep 15, 2017 at 1:03 AM, Oleksandr Natalenko
wrote:
> Hi.
>
> I've applied your test patch but it doesn't fix the issue for me since the
> warning is still there.
>
> Were you able to reproduce it?
Hi,
Thanks for testing that. That is a very useful data point.
I was able to cook up a pa
Hi.
I've applied your test patch but it doesn't fix the issue for me since the
warning is still there.
Were you able to reproduce it?
On pondělí 11. září 2017 1:59:02 CEST Neal Cardwell wrote:
> Thanks for the detailed report!
>
> I suspect this is due to the following commit, which happened b
On Sun, Sep 10, 2017 at 4:53 PM, Oleksandr Natalenko
wrote:
> Hello.
>
> Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> warning shown below. Most of the time it is harmless, but rarely it just
> causes either freeze or (I believe, this is related too) panic in
> tcp_s
Hello.
Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
warning shown below. Most of the time it is harmless, but rarely it just
causes either freeze or (I believe, this is related too) panic in
tcp_sacktag_walk() (because sk_buff passed to this function is NULL).
Unf
30 matches
Mail list logo
