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

[Birger Koblitz <mail@birger-koblitz.de>]

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. 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
[373104.440790] r8152 2-1:1.0 enx88c9b3b53125: Stop submitting intr, 
status -108
[373104.479779] r8152 2-1:1.0: rtl8153_unload called
[373104.534682] usbcore: deregistering device driver r8152-cfgselector
[373104.534704] r8152-cfgselector 2-1: unregistering interface 2-1:1.0
[373104.534826] r8152-cfgselector 2-1: usb_disable_device nuking non-ep0 
URBs

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

Also, I only see the issue on slow 5GBit USB-C connections, sometimes 
with the RTL8157, basically every time with the RTL8159, and so far 
never on a 20GBit USB-C connection, so the mitigation is probably some 
kind of interrupt coalescing.

Birger