I use Arch Linux. Since kernel 5.18.15 (and still in 5.18.16 and 5.19), then whenever my laptop suspends my home network goes down. My Dell XPS 13 9300 model laptop is connected to a Dell WD19TB dock which is connected via ethernet network to my main home router. When the laptop suspends, it puts that dock ethernet connection in an odd state which locks up all the ethernet switch ports on that router (and thus disables the attached wifi access point which most of my family rely on). If I disconnect that ethernet cable, or the dock cable to the laptop, or wake up my laptop, then the router and network immediately recover. It only happens when using the dock ethernet connection. If I disconnect the dock network cable but keep the dock connected and then use a USB ethernet dongle connected directly to the laptop then the problem does not occur. Since I can reproduce the problem on call, I have bisected the kernel between previous good 5.18.14 and bad 5.18.15 and found the problem commit is https://patchwork.kernel.org/project/netdevbpf/patch/20220718082120.10957-391-nic_swsd@realtek.com/ I applied a revert of that commit on current Arch kernel 5.19 which is what I am currently running and of course it runs fine.
I noticed this regression report seems to be ignored and consider forwarding it to the responsible developer. But before that a quick question: is the issue still present in the latest kenrels like 6.0-rc2 or the latest 5.19.y release?
I have the exact same issue with Lenovo P1 and thunderbolt 3 dock. My network also goes down in exactly the same way, and reverting the same commit fixes the issue. Issue is present in 6.0-rc2 as well.
At the time I raised this bug (about 3 weeks ago) bugzilla would not let me add the author of that offending commit as a CC. So I sent a link directly to him in email. He (Hayes) replied to me directly a few times back and forward asking for various tests and data. Then he sent me a patch which fixed the problem. A few days later he submitted this patch https://lore.kernel.org/lkml/20220818080620.14538-394-nic_swsd@realtek.com/ which is slightly different to the original one he sent me but also fixes the problem. I have been successfully applying that driver mod that each time as Arch updates it's kernel (currently 5.19.3). I guess I was expecting he (or an automation) would come back here and update this bug.
(In reply to Mark Blakeney from comment #3) > He (Hayes) replied to me directly a few times back and > forward asking for various tests and data. Ha, interesting, that's not how he should have done it, but whatever. :-D > https://lore.kernel.org/lkml/20220818080620.14538-394-nic_swsd@realtek.com/ Ahh, great, thx! > I guess I was expecting he (or an automation) would come back here and > update this bug. Fun fact: this it not even the place where this particular bug should have been reported in the first place (to quote https://docs.kernel.org/admin-guide/reporting-issues.html, which is prominently linked on the front page of this bugzilla instance: "Find out how and where its developers expect reports. Note: most of the time this won’t be bugzilla.kernel.org"). But whatever, that doesn't matter much if the problem got resolved somehow. [and yes, that's definitely not how things should be, but they just happend to be like that currently for historic reasons].
The fix for this is included in new stable 5.19.6 and also in new LTS 5.15.64 so this bug can be closed.
Hi, I passed here, just a few days, on that bug report, searching information about the same problem reported here : since little more than a month, all my network was going down because of Ethernet PAUSE frames, flooded by my ThinkPad USB-C Dock Gen2 (40AS) each time my Thinkpad T480 was going to sleep. I found many reports pointing at usb ethernet chipsets lazyingly implementing the Ethernet specs, but was not convienced : all my setup was ok before of a bulk of updates and changes I made on my entire setup (from my laptop to my ISP box through my router) When I found the source of the problem, the Ethernet USB on my dock, I started to search recent changes on the r8152 driver and bug reports, and finally here. A chance that the fix was rapidly integrated in the kernel and pushed to the distributions (Fedora in my case). Just updating the kernel to 5.19.8 instantly fixes the problem. So many thanks to you Mark for your report, Thorsten for the followup, and for the kernel developers involved in the fix-revert/review and finally merge. I thing you fixes headaches for others like me ;)
Since I raised this bug it seems I am allowed to close it. It was fixed back in stable kernel 5.19.6 and also in LTS 5.15.64 so closing it now.