diff mbox series

[net] r8169: avoid unsolicited interrupts

Message ID b8e7df14-d95e-4aab-b0e3-3b90ae0d3c21@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [net] r8169: avoid unsolicited interrupts | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag present in non-next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 5 this patch: 5
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers fail 1 blamed authors not CCed: romieu@fr.zoreil.com; 2 maintainers not CCed: andrew+netdev@lunn.ch romieu@fr.zoreil.com
netdev/build_clang success Errors and warnings before: 3 this patch: 3
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 4 this patch: 4
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 12 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/contest success net-next-2024-10-17--18-00 (tests: 776)

Commit Message

Heiner Kallweit Oct. 17, 2024, 6:05 a.m. UTC
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@gmail.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/net/ethernet/realtek/r8169_main.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Simon Horman Oct. 17, 2024, 4:07 p.m. UTC | #1
On Thu, Oct 17, 2024 at 08:05:16AM +0200, 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@gmail.com>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Reviewed-by: Simon Horman <horms@kernel.org>
Heiner Kallweit Oct. 17, 2024, 9:22 p.m. UTC | #2
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@gmail.com>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.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.
Andrew Lunn Oct. 18, 2024, 2:52 a.m. UTC | #3
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@gmail.com>
> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.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.

    Andrew

---
pw-bot: cr
Heiner Kallweit Oct. 18, 2024, 5:32 a.m. UTC | #4
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@gmail.com>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.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
Andrew Lunn Oct. 18, 2024, 1:01 p.m. UTC | #5
> > 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.

To clarify, you can change it using the pw-bot.

Put

pw-bot: cr
 
somewhere in the email to set it to Change Request.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#updating-patch-status

	Andrew
diff mbox series

Patch

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 1a4d834c2..322a1e930 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4805,7 +4805,11 @@  static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
 	struct rtl8169_private *tp = dev_instance;
 	u32 status = rtl_get_events(tp);
 
-	if ((status & 0xffff) == 0xffff || !(status & tp->irq_mask))
+	if ((status & 0xffff) == 0xffff)
+		return IRQ_NONE;
+
+	status &= tp->irq_mask | RxFIFOOver;
+	if (!status)
 		return IRQ_NONE;
 
 	if (unlikely(status & SYSErr)) {