[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c580367c-7f66-4f3a-bfe4-53e5103e200c@gmail.com>
Date: Fri, 18 Oct 2024 07:32:24 +0200
From: Heiner Kallweit <hkallweit1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Realtek linux nic maintainers <nic_swsd@...ltek.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Andrew Lunn <andrew+netdev@...n.ch>, Pengyu Ma <mapengyu@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] r8169: avoid unsolicited interrupts
On 18.10.2024 04:52, Andrew Lunn wrote:
> On Thu, Oct 17, 2024 at 11:22:20PM +0200, Heiner Kallweit wrote:
>> On 17.10.2024 08:05, Heiner Kallweit wrote:
>>> It was reported that after resume from suspend a PCI error is logged
>>> and connectivity is broken. Error message is:
>>> PCI error (cmd = 0x0407, status_errs = 0x0000)
>>> The message seems to be a red herring as none of the error bits is set,
>>> and the PCI command register value also is normal. Exception handling
>>> for a PCI error includes a chip reset what apparently brakes connectivity
>>> here. The interrupt status bit triggering the PCI error handling isn't
>>> actually used on PCIe chip versions, so it's not clear why this bit is
>>> set by the chip.
>>> Fix this by ignoring interrupt status bits which aren't part of the
>>> interrupt mask.
>>> Note that RxFIFOOver needs a special handling on certain chip versions,
>>> it's handling isn't changed with this patch.
>>>
>>> Fixes: 0e4851502f84 ("r8169: merge with version 8.001.00 of Realtek's r8168 driver")
>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219388
>>> Tested-by: Pengyu Ma <mapengyu@...il.com>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>>> ---
>>
>> When doing some unrelated performance tests I found that this patch breaks
>> connectivity under heavy load. Please drop it.
>> I'll investigate and come up with an alternative way to fix the reported issue.
>
> You should be able to mark your own patches are change request etc.
>
When doing this years ago, don't recall which subsystem it was, the maintainer
wasn't too happy that somebody else was changing the status of patches in patchwork.
Next time I'll do so, thanks for the hint.
> Andrew
>
Heiner
> ---
> pw-bot: cr
Powered by blists - more mailing lists