On Fri Jun 12, 2026 at 3:03 PM CEST, Andrea della Porta wrote:

On 14:53 Fri 12 Jun     , Nicolai Buchwitz wrote:

quoted

On 12.6.2026 14:51, Andrea della Porta wrote:

quoted

quoted

The commit message describes it as RP1 specific, but it gets applied
to all
other variants?

I've seen this issue happening only on RaspberryPi 5, but AFAIK it
could affect also other MACB blocks connected through PCIe, so it
may be widespread (even though it should have probably already been
noticed in the past). In the orginal driver there's no timeout callback
defined and this is much like pretgending the issue causing the timeout
to happen to go away without doing anything (whatever the cause ot the
specific hw are). So in my opinion we can just extend that to all MACB.
Or maybe we should execute the restart conditionally on
.compatible = "raspberrypi,rp1-gem"?

I just observed the issue once, but other people reported it to be happen
more
frequently. If we can narrow down a reproducer, it would be good to test on
other
blocks too (like EyeQ at Théo's).|

So maybe you can imagine a good repro for this issue?

Sure, it's happening quite often during bulk dataflow, at least
on my RPi5.
It can be reproduced with the following, issued from the DUT:

  iperf -c <SERVER_IP> -P 10 -t 3000 -w 4M -i 1

plus, of course, the related command on server side: iperf -s.

It usually happens a couple of times withing a few hours.

Thanks for the reproducer command; I'll run it next week.
I'd be surprised if it reproduced on hardware that isn't the Pi 5.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com