> For several network drivers it was reported that using > __napi_schedule_irqoff() is unsafe with forced threading. One way to > fix this is switching back to __napi_schedule, but then we lose the > benefit of the irqoff version in general. As stated by Eric it doesn't > make sense to make the minimal hard irq handlers in drivers using NAPI > a thread. Therefore ensure that the hard irq handler is never > thread-ified. > > Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff") > Link: https://lkml.org/lkml/2020/10/18/19 > Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> > --- > drivers/net/ethernet/realtek/r8169_main.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/realtek/r8169_main.c > b/drivers/net/ethernet/realtek/r8169_main.c > index 7d366b036..3b6ddc706 100644 > --- a/drivers/net/ethernet/realtek/r8169_main.c > +++ b/drivers/net/ethernet/realtek/r8169_main.c ...
Hi! This patch actually breaks r8169 with threadirqs on an old box where it was working before: [ 0.000000] DMI: Gigabyte Technology Co., Ltd. GA-MA790FX-DQ6/GA-MA790FX-DQ6, BIOS F7g 07/19/2010 ... [ 1.072676] r8169 0000:02:00.0 eth0: RTL8168b/8111b, 00:1a:4d:5d:6b:c3, XID 380, IRQ 18 ... [ 8.850099] genirq: Flags mismatch irq 18. 00010080 (eth0) vs. 00002080 (ahci[0000:05:00.0]) (error is reported to userspace, interface failed to bring up). Reverting the patch fixes the problem.