Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9

[Michal Pecio]

On Thu, 30 Apr 2026 05:36:06 +0200, Birger Koblitz wrote:
> Thanks Michal, for your explanations!
> On 29/04/2026 8:02 pm, Michal Pecio wrote:
> >>> What does interrupt mitigation do?
> >>>
> >>> Is this a different name for interrupt coalescence, where the MAC
> >>> delays interrupts for a period of time so more packets are in the
> >>> receive ring when it does interrupt, so reducing the number of
> >>> interrupts, and bigger bursts of packets are processed at once?
> >>>      
> >>
> >> I do not understand what the mechanism behind this is, there is no
> >> more documentation in the original driver. I experimented with this
> >> for some time and the effect that I see is that it prevents
> >> interrupts after shutdown.  
> > 
> > What do you mean by "after shutdown", driver unbind? You shouldn't be
> > seeing URB completions then if the disconnect() method unlinks them.
> > And if it doesn't, completions may be using driver data after free.
> > 
> > Or maybe you have pending URBs while calling set_configuration() or
> > set_interface(), which is dodgy too but at least not asking for panic.
> > 
> > Other cause of ESHUTDOWN might be serious host controller failure, but
> > you would likely get other log noise with that, at least with xhci.
> > 
> > What shows up if you repro with this enabled?
> > echo 'module usbcore +p' >/proc/dynamic_debug/control
> >   
> 
> With shutdown, I meant shutting down the driver: the error happens when 
> unloading the driver using rmmod, e.g. when testing different driver 
> versions.

Sorry, I remembered wrong. That UAF problem only applies to control
URBs on endpoint 0. All other URBs are removed by USB core *before*
rtl8152_disconnect() is called. So it doesn't need to unlink them
and it cannot predict when the URBs will be nuked by core.

> What I see when turning on debugging is this:
> [373042.499758] r8152 2-1:1.0 enx88c9b3b53125: carrier on
> [373104.440114] usbcore: deregistering interface driver r8152
> [373104.440141] xhci_hcd 0000:0c:00.0: shutdown urb 000000005501f8cc 
> ep1in-bulk
> [373104.440146] xhci_hcd 0000:0c:00.0: shutdown urb 0000000066ae4a92 
> ep1in-bulk
> [373104.440148] xhci_hcd 0000:0c:00.0: shutdown urb 00000000e9728025 
> ep1in-bulk
> [373104.440151] xhci_hcd 0000:0c:00.0: shutdown urb 00000000fa874ca0 
> ep1in-bulk
> [373104.440153] xhci_hcd 0000:0c:00.0: shutdown urb 000000006006ed5d 
> ep1in-bulk
> [373104.440156] xhci_hcd 0000:0c:00.0: shutdown urb 00000000a5bee1e7 
> ep1in-bulk
> [373104.440158] xhci_hcd 0000:0c:00.0: shutdown urb 00000000bc3a3ab0 
> ep1in-bulk
> [373104.440160] xhci_hcd 0000:0c:00.0: shutdown urb 0000000080a63692 
> ep1in-bulk
> [373104.440163] xhci_hcd 0000:0c:00.0: shutdown urb 0000000025af4e6e 
> ep1in-bulk
> [373104.440165] xhci_hcd 0000:0c:00.0: shutdown urb 0000000056d7e76e 
> ep1in-bulk
> [373104.440472] xhci_hcd 0000:0c:00.0: shutdown urb 00000000d8814536 
> ep3in-intr

And that's what happens in the log above, for the reason below:

[  +0,000015]  usb_hcd_flush_endpoint.cold+0xa/0x23 [usbcore]
[  +0,000050]  usb_disable_endpoint+0x52/0xa0 [usbcore]
[  +0,000048]  usb_disable_interface.cold+0x3f/0x4e [usbcore]
[  +0,000038]  usb_unbind_interface+0x138/0x2f0 [usbcore]
[  +0,000048]  device_release_driver_internal+0x194/0x200

> [373104.440790] r8152 2-1:1.0 enx88c9b3b53125: Stop submitting intr, 
> status -108

So this message is harmless. I'm also seeing it with RTL8153 if the
interface is up at the time of rmmod.

> In the past I have also seen the following, but am not able to reproduce it:
> [371283.534041] r8152-cfgselector 2-1: USB disconnect, device number 25
> [371283.534470] r8152 2-1:1.0 enx00e04c680023: Stop submitting intr, 
> status -108

Apparently the disconnect message is logged before calling
rtl8152_disconnect(), so that's probably harmless too.

I'm not sure how tweaking some HW registers prevents it. Maybe it
causes the HW to complete the URB (but why?) at the right moment so
that it isn't pending during usb_disable_endpoint(), IDK, weird.

Regards,
Michal