[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next date => thread ]
Reinstalled an old HP box with a new SSD.
Installed Debian Trixie using the RC2 installer.
Went with Gnome Desktop and both liking it and hating it in equal
measure. Using KDE on Debian stable before. It has stolen all my nice
KDE settings, but also it gets most things right by default (except it
seems to love the microphone in the webcam over the microphone on my
wireless headset). I probably should just disable the microphone on the
webcam as I'd only use if as microphone of last resort (best way to
disable?). Bluetooth support is better, not sure if that is GNOME or
the slightly newer kernel or some other set of tools (bluez version),
but bluetooth support is my bane in 2025.
On boot I see a bunch of ACPI and other errors I didn't see with the
previous Debian version, I'm pretty sure there were some complaints
logged previously, but I've tried debugging ACPI before and I'm not
that clever, but usually doesn't matter in my experience. Otherwise
everything seems to work.
The performance was shoddy, on inspection systemd-udev is eating CPU
cycles, polling a PCI device too frequently. Looks like I am seeing
almost exactly this issue:
https://askubuntu.com/questions/1028883/ubuntu-18-04-systemd-udevd-uses-high-cpu-conflict-with-wifi
But I think it is a different device.
# udevadm monitor
Gives a lot of lines extremely similar to this one.
KERNEL[17049.078965] change /devices/pci0000:00/0000:00:13.0/usb3/3-
1/3-1.1/3-1.1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)
I believe this is the SD card reader, in particular sdb was a 32GB SD
card with a copy of my car's satnav data on (long story).
System is one of these:
System Info: #1
Manufacturer: "HP"
Product: "450-a160na"
SD reader shows as:
Model: "Generic SD/MMC/MS PRO"
Vendor: "Generic-"
Device: "SD/MMC/MS PRO"
Having pulled the card out restarted the systemd processes, and stuck
it in, it mounts as expected now, and no errors or run away CPU.
I have that nagging feeling I've finally cleared the error for now but
maybe not fixed it.
Anyone got any good recommendations for a desktop tool to alert on
rogue processes or a nice GNOME backdrop CPU monitor? I figure there
has to be a better way then checking after a conference call why the
sound was so terrible.
What precisely is going on? I noted udisks-daemon was also consuming
CPU at one point, so I assume there was some internal discussion
between udisks-daemon and systemd-udev about whether to mount this
volume. There are a bunch of read errors and the like, but nothing
reproducible, and the problem remained after removing the SD card.
I guess it could be poorly inserted Sd card, or a hardware fault
arising from fitting the new SSD. I barely use the SSD card reader,
indeed mostly to update my car's satnav data (Google maps is better).
But I'm not sure I want to disable it in hardware by unplugging it from
the motherboard.
--
The Mailing List for the Devon & Cornwall LUG
FAQ: https://www.dcglug.org.uk/faq/