Hardware setup:
A router connected to a netgear switch, which is connected to both a Dell Laptop (though a Dell thunderbolt dock) and a Mac Studio
Steps to reproduce:
Start pinging the router on the laptop, which works
Put Mac to sleep
Wait ~45 seconds
Notice that the laptop can no longer ping the router!
Press the power button on the Mac
Immediately, the laptop can ping the router again!
Nothing interesting shows up in the journal of the laptop. I’m a noob to debugging these sorts of issues, and I’m happy to gather any other info that would be helpful.
My asahi-diagnose: asahi-diagnose.txt · GitHub (I didn’t see a way to upload a text file to this forum? Images but no log attachments is surprising)
EDIT: eventaully, the laptop does emit
kernel: r8152 6-2.4:1.0 enp6s0u2u4: Tx timeout
kernel: r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
kernel: r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
kernel: r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
kernel: r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
Well that is certainly weird. First, the big picture: The only legitimate way the Studio can break your network is by flooding it with traffic (assuming your other network equipment is functioning correctly). However, that r8152 error on the laptop suggests something is broken there, since a flooded network should not cause that kind of kernel error transmitting packets (Ethernet is generally nonblocking unless flow control is used, but AIUI that is rare; instead switches just drop excess traffic).
I would say, do a tcpdump -ni enp6s0u2u4 on your laptop when the Studio goes to sleep and see if that starts flooding output. If so, please paste a few lines of it so we have an idea of what’s going on.
I tried it locally and I cannot reproduce the issue. However, I did get this on resume:
That’s a translation fault on the IOMMU attached to the 10gbps controller, so that suggests something is wrong (though the machine did come back after wakeup, including the Ethernet). It’s not impossible that under the right circumstances, that fault could cause the NIC to flood packets out the port somehow.
I would say, open a bug here so this gets tracked. I’m not sure I can take a look at it soon, but we should track it so it gets looked at at some point. The short-term solution, though, is to just not put the Studio to sleep. The power savings of sleep vs. idle are relatively small, and should be insignificant for a machine attached to mains power, so you really won’t get much benefit out of it over just leaving it running.
Edit: ping -fing the Studio while suspending leads to more faults, so yeah, there is definitely something wrong with the suspend handling in the NIC driver, IOMMU, or both. Still can’t repro any kind of flooding behavior though.