[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be30fd08-0347-4c0c-a31b-bceae00b6a60@kernel.org>
Date: Tue, 15 Jul 2025 12:40:23 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
Neal Cardwell <ncardwell@...gle.com>
Cc: Simon Horman <horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...gle.com>,
Willem de Bruijn <willemb@...gle.com>, netdev@...r.kernel.org,
eric.dumazet@...il.com, "David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 0/8] tcp: receiver changes
Hi Paolo,
On 15/07/2025 12:14, Paolo Abeni wrote:
> On 7/15/25 11:21 AM, Matthieu Baerts wrote:
>> On 15/07/2025 10:25, Paolo Abeni wrote:
>>> @Matttbe: can you reproduce the flakes locally? if so, does reverting
>>> that series stop them? (not that I'm planning a revert, just to validate
>>> my guess).
>>
>> I'm trying to reproduce this locally on top of net-next, no luck so far.
>> I will also continue to monitor the MPTCP CI.
>>
>> For the moment, I don't think it might be linked to this series:
>
> Agreed. I did not notice the pending mptcp patches, which are a more
> relevant suspect here.
>
>> Eventually, because the failure is due to a poll timed out, and other
>> unrelated tests have failed at that time too, could it be due to
>> overloaded test machines?
>
> Not for a 60s timeout, I guess :-P
:)
The poll timeout is set to 10s I think. But yes, it is still too long to
be caused by an overloaded test machine I suppose.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
Powered by blists - more mailing lists