Arch Linux Forums

[wrong thread, sorry]

system information Current installed kernel:6.18.49-2-lts CPU:AMD Ryzen 7 6800H GPU:AMD Radeon 680M integrated graphics Laptop:Lenovo ThinkBook 16+ BIOS:J6CN50WW BIOS date:09/27/2024 Before testing Linux, I reset all BIOS settings to factory defaults, except for the Secure Boot setting, which I left manually configured. There is no CPU overclocking, Curve Optimizer, PBO tuning, custom UMA configuration, or other performance-related BIOS modification currently applied. Problem The machine randomly reboots when running Linux. The problem already happens inside the Arch Linux live environment, before the OS is installed. Normally the live environment survives for somewhere around 10–20 minutes and then suddenly reboots. Sometimes it lasts longer or shorter, so the interval is not completely fixed. I have seen this happen while the system was idle as well as while I was actively installing packages. The BIOS setup screen itself is stable. I left the machine sitting inside the BIOS for about 30 minutes and it did not reboot. I have also used Windows on this laptop before. Windows sometimes BSODed during the boot process, before successfully reaching the desktop, but once Windows successfully booted, I do not remember it ever randomly rebooting by itself during normal use. This makes me unsure whether this is a Linux power-management/kernel issue, a firmware issue, or some underlying CPU/RAM/platform stability problem. I should also mention that I am still a newbie when it comes to

drankinatty wrote: it would save the sets in a form to be loaded by ipset on restart/reboot. Not the answer to your question, but just reflection: isn't the point of dynamic rules precisely to fill it dynamically at runtime? I.e. default ruleset is written by user and stored in /etc/ntfables.conf once. After it is loaded, services extend the ruleset with their rules as they start, generating rules from own configs/databases etc.

Is there any way to see the old pages whenever searching stuff up on the Wiki? The new pages seem out of place in comparison to other pages on the wiki.

Seth wrote: Is there any reference for your hardware and this you've based this action on? Yes, from here Seth wrote: From #4 that might imply that hda jack retask was always inert? Possibly? I think I was misremembering, I believe it worked when on Fedora? (Either the front speakers didn't work or they were really quiet after applying this config.) I used to use a 2012 HP laptop which I no longer have, HDAJackRetask was similarly being obnoxious. Nothing was applying, and this was in 2024. Maybe it's related? Is there any way I can apply this pin config manually? Seth wrote: Are you still applying "snd_intel_dspcfg.dsp_driver=1"? Yes, I am. Side tangent: HDAJackRetask has become more and more annoying in the past week or two when I've been desperately trying to figure this out, randomly freezing. In case this is just ALSA tripping, I've also submitted a bug report to Kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=221962

Ah, GeForce GTX 1050 Ti is NV137. You should use either nvidia-580xx-dkms or nouveau .

Apparently, thonny-5.0.0-1 expects a version of uv_build lower than 0.12.0. As the version in the Arch repos currently sits at 0.12.10, build fails like so: ERROR Unmet dependencies (checked against /usr/bin/python): uv_build =0.11.6 wanted: =0.11.6 found: 0.12.10 ==> ERROR: A failure occurred in build(). Aborting... Editing the pyproject.toml file to accept version 0.12.10 makes the build complete without errors, and Thonny seems to run just fine thus far. Just ran across this and thought I'd spare the next person a bit of grief. I'd've put this in a comment below the thonny AUR entry, but new registrations are still closed. Maybe someone with an existing AUR account could copy-paste it there or something.

Hello, recently I've been experiencing weird stuttering on my second monitor, and im not quite sure what it is? I dont know much about hardware or why this might be happening so I sadly cant provide much info on my own. The best I have so far is the following: - I am using the framework model 13 - I have the second monitor connected via a displayport cable - When I turn DPMS off on my built in monitor the stuttering on the second one stops, - The built in monitor experiences no stuttering even when the other monitor is turned on - There is no weird cpu or (from what I can see) GPU load, and thermals with nothing open are all between 30 and 40 degrees celsius. - The monitor stutters even if I have nothing but a graphical session open - This did not use to be an issue in the past I hope someone more experienced than me can help me figure out whats going in, and I thank them in advance Small edit: this seems to be an issue with niri specifically, as sway has zero stuttering. Bellow is my installed version of niri: - niri 26.04-1

https://aur.archlinux.org/packages/arduino-ide was updated to 2.3.10 and depends on electron30 . Try building & installing that version. Moderator Note moving to AUR Issues, Discussion & PKGBUILD Requests

Your 0a5c:5842 case is adjacent to the 0a5c:5843 issue I reproduced, but the log points to an earlier initialization/firmware identity failure rather than the final enrollment timeout: repeated USH status 0xb, then FwUpgradeError 0x1c, followed by the device being ignored and NoSuchDevice. Before attempting any firmware change, verify that the fingerprint sensor is enabled in BIOS, identify the exact ControlVault/CID and sensor PID, and ensure the matching libfprint-tod plus libfprint-2-tod1-broadcom files are installed. A recent reply in this thread reports a Latitude 5520 working after installing fprintd, both AUR TOD packages, re-enabling the sensor in BIOS, and rebooting. The safe inspection tooling and reproducible notes are here: https://github.com/GrecAndrei/controlva … ey-toolkit . The controller deliberately does not flash firmware; mismatched CV3 firmware can make initialization worse.

Thank you for this

Your 0a5c:5843 symptom (enrollment reaches ~90%, then enroll-unknown-error / Device status 11) matches a ControlVault 3 protocol issue I reproduced on a Dell Latitude 7400. The vendor TOD stack can see the reader but misses the host-timestamp interrupt, so the final enrollment stage times out. I fixed my unit with the source-built shim and reproducible notes here: https://github.com/GrecAndrei/controlva … ey-toolkit The relevant sequence was: install the matching Broadcom TOD/libfprint packages, disable USB autosuspend for 0a5c:5843, install broadcom-host-event-shim, restart fprintd, then test from the terminal before KDE: fprintd-enroll -f right-index-finger $USER fprintd-verify -f right-index-finger $USER In journalctl, the healthy path reports identify status=0 and result=1. The shim handles only the host-timestamp event and does not read or store biometric data. I would not flash the Dell Windows firmware bundle; the included controller is inventory/inspection/sync-clock only because an interrupted or mismatched update can brick the ControlVault.