Closed tomrutsaert closed 1 month ago
Is there a log? What led you to find this file?
This thread in discord: https://discord.com/channels/1072614816579063828/1226572714668724286/1275179629350490135
I knew already it was in udev, see discourse. and NullUnit pointed to the command and the file. And when I proposed to him to override the file in etc, his problem was fixed. It was also fixed for me, and for another user in discourse
OK here's the relevant information:
cat /lib/udev/rules.d/30-linksys-ae1200.rules
ACTION=="add",ATTRS{idVendor}=="13b1",ATTRS{idProduct}=="0bdc",
RUN+="/sbin/modprobe brcmfmac"
RUN+="/bin/sh -c 'echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id'"
Nullunit — 08/19/2024 4:21 PM here is the full command: /bin/sh -c echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id I see references to Linksys AE1200 on the web about this Nullunit — 08/19/2024 4:30 PM looks like it is the /lib/udev/rules.d/30-linksys-ae1200.rules file is has the RUN+= lines, so RUN keeps growing and growing Nullunit — 08/19/2024 4:59 PM I needed to add --network=host to my docker build and docker run commands otherwise while looking at "udevadm monitor", there are lots of UDEV add and remove events now it is nice and quiet, hope that helps anyone else with this issue. If docker uses the network "bridge", it acts like a wifi USB dongle is inserted and removed a ton of times
I've recently run into this problematic behavior, too...
For reference, we added this udev rule here: https://github.com/ublue-os/config/pull/214
I'm struggling to grok why docker run, though it SHOULD trigger a lot of udev activity for veth devices, would trigger:
ACTION=="add",ATTRS{idVendor}=="13b1",ATTRS{idProduct}=="0bdc"
But it does, and this is not very good.
I'd like to figure out why this is happening and correct the udev rule if possible.
If that's not possible, I think this would be a good candidate for a rule which gets added via a ujust
recipe for users with this hardware, rather than force users who use docker to disable it.
I've tested the workaround provided in the forum thread:
$ # given a system where a docker-compose up -d would cause a lot of stutter, and while playing music
$ sudo touch /etc/udev/rules.d/30-linksys-ae1200.rules
$ # now immediately, with no other commands
$ docker-compose up -d # this is in a project dir with a lot of containers which had been causing a lot of stutter
$ # observe, no stutter
I'm still confused why this rule causes this problem, but I also haven't looked very carefully.
I've created a PR with the revert for the problematic rule.
Users which desire it can certainly create it locally, but it's far too problematic to exist by default IMHO.
This was resolved by https://github.com/ublue-os/config/commit/2c66163f748d46ce85bfe8701213f8a9cfd60ffd
Describe the bug
I’ve experienced stuttering issues with my desktop environment, specificly when running Docker containers or performing Maven builds (that use Docker test-containers in tests), on three different UBlue-based operating systems (Aurora, Bluefin-DX, and a custom Sway image) on two separate machines.
The culprit is /lib/udev/rules.d/30-linksys-ae1200.rules overriding this file by placing an empty file in /etc/udev/rules.d/30-linksys-ae1200.rules, the stuttering goes away.
This was experienced by 3 different users, and the workaround fixes it for all.
More info see: https://universal-blue.discourse.group/t/mouse-music-stutter-when-starting-many-docker-containers/3470
What did you expect to happen?
I did not expect any stutter, as fedora workstation 40 for the same workload also does not have the stutter.
Output of
rpm-ostree status
No response
Output of
groups
No response
Extra information or context
No response