gnarface | cousin_luigi: the system i found that bios bug in with was also AMD | 03:41 |
---|---|---|
gnarface | s/with// | 03:41 |
gnarface | one thing i discovered that was a very reliable way to reproduce the problem was to scp a very large file to it | 03:43 |
gnarface | it would sometimes be fine for weeks if idle, and without any sustained disk/io, any amount of cpu load was fine | 03:44 |
gnarface | if you can take a summary of which power management features are provided by your bios, i may be able to sanity check them for you | 03:45 |
gnarface | some of these old AMD motherboard bioses in the wild, even in their most recent versions available, are still floating around out there with some nasty bugs | 03:46 |
gnarface | (the other "wontfix" bug i've discovered proliferating seems to be an issue just with the samsung evo SSDs) | 03:47 |
cousin_luigi | gnarface: How do I do that? | 07:23 |
cousin_luigi | I mean, is there a tool or you mean from the post menu?? | 07:25 |
gnarface | cousin_luigi: i meant from the post menu, sorry | 07:27 |
cousin_luigi | nm, will try, but it's a rather simple thing | 07:29 |
gnarface | yea, sometimes they just don't give you the options you need, it's a pity | 07:30 |
gnarface | Dell BIOS used to be like that, though i admit i haven't seen one lately | 07:30 |
gnarface | ASUS seems to ship a lot of these bugs too, but at least they give you a way to shut off the broken features | 07:31 |
gnarface | if there's some "advanced" mode try to find it | 07:34 |
cousin_luigi | gnarface: https://imgur.com/a/OH7FFCs | 07:36 |
cousin_luigi | (note, I'm not sure those are the current settings, that's a video I took months ago) | 07:37 |
gnarface | cousin_luigi: wow, is that all? i see what you mean... | 07:53 |
cousin_luigi | gnarface: It's a thin client, not a regular motherboard | 07:54 |
cousin_luigi | Will also run memtest86+ later. | 07:54 |
gnarface | cousin_luigi: i do wonder if the super vague "Idle power Savings" = "Extended" could be a vague simplification of several other controls... i'd be curious what the other options were besides "extended" and maybe try one of the other settings | 07:55 |
gnarface | like for example if there were 5 settings and "Extended" was the maximum setting, i'd try the one immediately below that first | 07:56 |
gnarface | and as for the S5 thing... i had no idea it even went up to S5, that one's new to me, but i see you have it disabled already | 07:56 |
gnarface | if you have a way to check the power usage at idle and there's a change that clearly saves a static amount of watts but only literally just about 2-3 of them, i'd say that'd be a prime suspect | 07:57 |
gnarface | when i was initially troubleshooting this, i was told by several people that it was a sign the CPU was going bad, not the RAM, but after changing the CPU twice i started getting more pedantic about my testing regime, and managed to deductively isolate that "C1E Powersaving" feature toggle as the culprit | 07:59 |
gnarface | but with comparatively less granular controls, all you can really do is the same process and hope one of the batches of features these options you have includes it | 08:00 |
gnarface | batches of several at once that these options are masquerading for, really, i suspect | 08:01 |
cousin_luigi | gnarface: I don't recall any further options, also see last picture I added | 08:02 |
gnarface | (though i'm not sure, i assume the "Runtime Power Management" thing is just whether to allow the kernel to change the cpu clockspeed through the regular cpufreq modules or not) | 08:02 |
gnarface | (and that one you'll definitely want) | 08:02 |
cousin_luigi | gnarface: The only thing I could do was changing the governor, which I set to powersave | 08:02 |
cousin_luigi | The rest is internally managed, apparently | 08:03 |
gnarface | if it's the same thing i was running into, the actual clock speed or governor you use won't end up mattering much, what will really matter is sustained disk io | 08:03 |
gnarface | not that it can't happen on a relatively idle system, but sustained disk io was the one thing i found to reliably increase the chances of it happening | 08:04 |
cousin_luigi | gnarface: The device is used as a router, with root mounted read only. | 08:04 |
gnarface | hmm, well for what it's worth temperature sensor polling seemed to be equivalent to disk io for the purposes of triggering the problem | 08:05 |
cousin_luigi | temperature you say hmmm | 08:05 |
gnarface | yea, the first mitigating factor was i took temperature polling out of the munin runs' task set | 08:06 |
cousin_luigi | "munin"? | 08:06 |
gnarface | just generic system monitoring software | 08:06 |
cousin_luigi | I see. I reduced the idle fan speed to the minimum, to see if I could reduce the noise. | 08:07 |
cousin_luigi | But I'm not 100% sure it didn't happen before. | 08:07 |
gnarface | anyway, that dropped the frequency of the occurances a lot, it wasn't until later i discovered the much more reliable triggering use case of scping a big disk image up | 08:07 |
cousin_luigi | I see. Will try a parameter at the time. Yesterday I removed the NIC firmware, since the tg3 module appears to work correctly even without it. And at the same speed. | 08:08 |
gnarface | within a few gigabytes of transfer that would cause the problem 100% | 08:08 |
gnarface | but it had to be going onto disk, it didn't seem to matter if it was just passing through | 08:08 |
gnarface | i'm not sure what analogues your system might have to that basic type of traffic that might be triggering this but it seems possible there's something | 08:09 |
gnarface | cousin_luigi: by the way, if the fan has 3 or more wires going into it, i'd strongly recommend letting the bios handle it as generously as possible, but i do sympathize with wanting to make things quieter... i doubt that's the cause of the issue here either way | 08:12 |
gnarface | cousin_luigi: if this is a amd64 cpu in this device, i would strongly recommend loading the amd64-microcode though | 08:13 |
gnarface | amd64-microcode package, i meant | 08:13 |
gnarface | cousin_luigi: oh and to be absolutely clear, temperatures didn't affect it, what affected it was how often the motherboard sensors were polled | 08:20 |
gnarface | why just that and disk io, i could only speculate | 08:20 |
cousin_luigi | gnarface: Hmm, not loaded by default on devuan. | 09:15 |
cousin_luigi | And memtest86+ had a successful pass. | 09:15 |
cousin_luigi | gnarface: So, you would recommend removing blacklist microcode? | 09:16 |
cousin_luigi | How do I check if the cpu microcode has been loaded? | 09:48 |
cousin_luigi | oh, it's in dmesg | 09:49 |
cousin_luigi | hmm, do I really need to unblacklist the ucode if it's already in the initrd? | 09:55 |
gnarface | cousin_luigi: blacklist? not sure what you're talking about there. afaik all i've ever had to do was install the package... | 10:23 |
gnarface | it isn't installed by default because it's in non-free (non-free-firmware, as of daedalus) but still sometimes carries important security and stability fixes | 10:24 |
gnarface | i can't be sure that's relevant to your issue here but it's a good idea to have it either way | 10:25 |
gnarface | since we're not sure what else you might be missing if you were missing that, check to make sure you have acpid installed... it's critical for functional power management in varying degrees depending on the hardware | 10:27 |
cousin_luigi | gnarface: Please check /etc/modprobe.d/amd64-microcode-blacklist.conf | 10:28 |
cousin_luigi | That comes by default with amd64-microcode | 10:28 |
cousin_luigi | hmm, acpid is not installed | 10:29 |
gnarface | cousin_luigi: oh, i see. yea i have that too, i hadn't realized that was there... that's interesting.... maybe you're right though and the initrd does it so this one doesn't have to... | 10:30 |
cousin_luigi | gnarface: Meanwhile, the damn thing crapped out on me again, removed the governor thing to see if it makes a difference | 10:30 |
cousin_luigi | now, one can see the microcode version in kern.log, but how does one make sure it's the latest one? | 10:32 |
gnarface | cousin_luigi: ah, check /usr/share/doc/amd64-microcode/README.Debian.gz | 10:32 |
cousin_luigi | (I thought I did) | 10:32 |
gnarface | cousin_luigi: it says with the default debian kernel it should be enough to just install the package | 10:32 |
gnarface | and it is doing it from the initrd, where it's safer, that's what i'm gathering from this | 10:32 |
cousin_luigi | indeed, that was my conclusion as well | 10:33 |
gnarface | but it also says you can trigger a manual immediate microcode update if you want with: echo 1 > /sys/devices/system/cpu/microcode/reload | 10:33 |
gnarface | but it says specifically, "DO THIS ONLY WHEN YOU KNOW BETTER" | 10:33 |
cousin_luigi | I get a permission denied | 10:33 |
gnarface | it says you need to be root | 10:34 |
cousin_luigi | which I am | 10:34 |
gnarface | hmm | 10:34 |
cousin_luigi | perhaps I need to load that module first? | 10:34 |
gnarface | no, i wouldn't | 10:34 |
gnarface | i would just assume it's working TBH until i talked to someone smarter | 10:34 |
cousin_luigi | anyway, it's not a big deal since I've rebooted a number of things | 10:34 |
cousin_luigi | times* | 10:34 |
gnarface | when you said it died just now, was that with acpid running? | 10:35 |
cousin_luigi | no | 10:35 |
cousin_luigi | acpid wasn't even instaleld | 10:35 |
cousin_luigi | installed* | 10:35 |
cousin_luigi | Will have to wait a bit, I suppose. | 10:36 |
gnarface | i've only seen it actually cause stability problems on nvidia video cards when missing, but we're just crossing stuff off the list to make the list shorter here | 10:36 |
gnarface | powersave was probably the most reliable cpufreq governor but it might be worth trying ondemand and schedutil just to see if it changes anything about the randomness, that could be a clue | 10:37 |
cousin_luigi | By the way, would you force amdgpu when the default is radeon? I returned that to default too. The card is not in use anyway. | 10:39 |
gnarface | i would decide by the card generation i have, some can do both and in that range, some are better at one than the other | 10:39 |
gnarface | off the top of my head i'm not super clear on the ones closer to the transition point | 10:40 |
gnarface | anything after RX 480 i'd definitely go amdgpu though | 10:40 |
gnarface | either way, if you're using a graphical desktop make sure you have enough of the mesa packages installed to actually use the driver right... it tends to miss a few by default | 10:41 |
cousin_luigi | gnarface: No, it's headless. I would consider changing it only for stability and power consumption purposes. | 10:42 |
gnarface | at one point there was also a "radeonsi" kernel scheduler | 10:42 |
gnarface | for a certain amount of the cards, i think also the ones close to the transition point, that scheduler will make a world of difference in performance, reportedly | 10:43 |
gnarface | that might be stale news | 10:43 |
gnarface | i'm not sure if it will matter if you're running headless | 10:43 |
cousin_luigi | I think it is a southern islands device actually | 10:43 |
bob123 | Hi all . I would be grateful for help or advice. This error breaks Devuan, the system becomes uncontrollable, the cursor moves randomly, the pages themselves close, etc. | 11:22 |
bob123 | This error occurs on qemu-devuan. Local machine -Devuan, virtual machine -Devuan | 11:22 |
bob123 | This is the error | 11:22 |
bob123 | kernel: [362.059103] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 | 11:22 |
bob123 | 2024-01-29T11:06:02.376836-05:00 bob123 kernel: [ 362.059948] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. | 11:22 |
gnarface | my first advice for bob123 is to stick around longer | 12:20 |
cousin_luigi | By the way, what is the function of acpid if there's no keyboard, nor monitor? | 13:06 |
djph | cousin_luigi: power control for all the other hardware? | 13:08 |
cousin_luigi | hmm | 13:08 |
nemo | hey folks. I've had the weird situation for a while, that a bunch of my packages have been held. and I'm trying to figure out what triggered it | 18:26 |
nemo | so. I tried manually installing one for more of a hint | 18:26 |
nemo | apt install libsmbclient... | 18:27 |
nemo | and it said. "limbsmclient : Depends: samba-libs 2:4.19.4 but 2.4.18 .. etc libtalloc2 2.4.1~ but 2.4.0-f2... libtevent0 0.15.0 but 0.14.1-1... unable to correct you have held broken packages | 18:27 |
nemo | so. now my question is. how do I figure out where those versions are coming from? | 18:28 |
nemo | hm. maybe synaptic can magically figure it out for me. it seems good at traversing package graphs sometimes. | 18:28 |
nemo | ... if synaptic is actually working. I've had a lot of trouble with it lately | 18:28 |
djph | nemo: did you forget to run apt-get update first? | 18:29 |
nemo | nope | 18:29 |
nemo | s/libmbsmclient/libsmbclient/ | 18:30 |
djph | crossing daedalus and non-daedalus repos? | 18:32 |
djph | pft, apt-cache depends doesn't give the version | 18:32 |
nemo | djph: don't think so... checking | 18:51 |
nemo | djph: nope | 18:51 |
nemo | 4 lines in sources.list main security updates backports | 18:52 |
nemo | hm. I did have to add non-free to backports though | 18:52 |
nemo | let's see why | 18:52 |
gnarface | are you aware they moved a bunch of drivers from "non-free" to the new "non-free-firmware" as of daedalus? | 18:53 |
nemo | it was a deprecated pos that I despise. cylance | 18:54 |
nemo | removing it now | 18:54 |
nemo | let's see if that helps | 18:54 |
nemo | gnarface: not sure I need that right now, but definitely good to know. thanks. | 18:55 |
nemo | maybe if I'm mucking about w/ amd + opencl again and want to avoide a frankenpackage | 18:55 |
nemo | damn. removing cylance did not help | 18:55 |
nemo | is there any easy way to figure out why stuff is being kept back? | 18:55 |
nemo | I guess I can just keep running apt install over and over as I descend the packages | 18:56 |
nemo | deb.devuan.org/merged is correct location right? | 18:56 |
djph | hm, packages.debian.org sayos libsmbclient depends on samba-libs 2.4.17 ... | 18:58 |
djph | oh wait, *backports* though ... that pulls in 2.4.19 ... | 18:59 |
djph | 23 2:4.19.4 ... i'm not seeing a 2:4.18.x anywhere in bookworm's repos though | 19:00 |
nemo | this is so weird. I've tried explicitly enumerating each package and it isn't going further down the tree | 19:08 |
nemo | https://m8y.org/tmp/devuan_broken.txt | 19:11 |
nemo | open to any suggestions | 19:12 |
nemo | let me see what else is under /etc/apt | 19:12 |
nemo | going to try to clean it up a bit | 19:12 |
nemo | remove some foo~ files etc | 19:12 |
nemo | could I possibly have old config under /etc/apt/apt.conf.d that could be a problem? | 19:13 |
nemo | hm. nothing too worrying there, eyeballing it. all seems pretty sensible | 19:14 |
nemo | I do have an /etc/apt/preferences.d I don't remember setting called "avoid-systemd" that pins the package systemd-sysv to "Pin: release o=Debian" and "Pin-Priority: -1" | 19:15 |
nemo | I would hope that isn't an issue | 19:15 |
nemo | everything else seems fine. so confused | 19:16 |
nemo | is there a way to make apt regenerate whatever caches of package dependencies it might have? | 19:16 |
nemo | maybe I can get some clues w/ apt-cache depends | 19:31 |
nemo | aptitude says my choices are to leave those 3 packages alone | 19:42 |
nemo | orrrr remove gvfs-backends libldb2 libsmbclient mate-desktop-* python3-smbc and samba-libs | 19:43 |
nemo | so... I guess I'm leaving those packages alone | 19:43 |
nemo | hopefully it's not a problem | 19:43 |
nemo | for anyone wondering here. was given a solution that seems to work | 19:58 |
nemo | apt install -t daedalus-backports libsmbclient | 19:58 |
nemo | apparently it wasn't using the backports package... | 19:58 |
nemo | after running that. nothing stuck | 19:58 |
eyalroz | I need your help, my friends... | 20:58 |
eyalroz | with initramfs-tools after an apt-get dist-upgrade a week or so ago. | 20:59 |
eyalroz | well, first, it was failing because it looked for /sbin/dmsetup and wasn't finding it, since it's under /usr/sbin, | 20:59 |
eyalroz | but I've already gotten used to this pattern, so I figured out that was the case and fixed it. | 21:00 |
eyalroz | But now, it insists on finding certain rules in /usr/lib/udev/rules.d, which have to do with dm, and those rules don't exist | 21:01 |
eyalroz | Uh, sorry, I meant to say, the rules don't exist under /lib/udev ; but they do exist under /lib/udev/ - which also has its own rules directory | 21:02 |
eyalroz | Those sets of rules are quite confusing... some of the rules are here, some are there. | 21:03 |
eyalroz | Can I safely merge them? | 21:09 |
eyalroz | And should I actually merge /usr/lib/udev into /lib/udev entirely? | 21:09 |
rwp | eyalroz, The current direction is that Devuan will follow Debian with the UsrMerge. This patch has been proposed and will likely be accepted: https://git.devuan.org/devuan/base-files/commit/fc611fab26716b829c3cd85eb3a45d2dcae0d3d4 | 21:33 |
rwp | Which means that if you can rescue the system enough to boot that the way forward is most likely to "apt-get install usrmerge" and then reinstall and dpkg-reconfigure as needed to get the initramfs rebuilt. | 21:33 |
eyalroz | rwp: So, I managed to get the initramfs-tools to configure | 21:38 |
eyalroz | And my system never stopped booting | 21:39 |
eyalroz | It's just that I did some of that usrmerge'ing manually | 21:39 |
eyalroz | So I am a bit hesitant about what would happen when I try to install this - with my file moves and symlinks and such | 21:40 |
rwp | I suggest using the debian-installer netinst iso to boot and then use Advanced->Rescue mode to rescue the system. Or other favorite boot iso if you like. But Rescue mode guides through it nicely. | 21:40 |
rwp | I am rather in the same position. I have hacked on my system quite a bit too. So not sure what usrmerge is going to do. I need to inspect it. | 21:40 |
rwp | I think all of the work is being in the postinst script. So I need to "less /var/lib/dpkg/info/usrmerge.postinst" and browse and inspect it. | 21:41 |
rwp | That's after it has been installed on a system. But I can look at it on another system. Or "apt-get download usrmerge" and then unpack the .deb and look at the script from the package. | 21:43 |
nemo | FWIW, the whole reason I was attempting to update samba, is still broken | 21:53 |
nemo | basically I was hitting this: | 21:54 |
nemo | https://lore.kernel.org/all/ZZhrpNJ3zxMR8wcU@eldamar.lan/ | 21:54 |
nemo | appears to be a kernel regression pulled in from upstream | 21:54 |
nemo | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060005 the debian bug | 21:54 |
rwp | The Linux 6 series kernel has had quite a few bugs recently. I am still pinning to 6.4 which is before other badness for me. I haven't had time to test newer kernels. | 21:57 |
nemo | it looks like a kernel maintainer created a build in that bug that people are confirming fixed | 21:59 |
nemo | how would I check to see if this has made it to "try" server yet? | 21:59 |
rwp | Sorry but I could not parse your question. Meanwhile... I suggest booting a previously known good kernel. | 22:01 |
nemo | rwp: he made a build that people tested. my understanding is that before something goes out to backports, it goes through a "try" repository first with debian | 22:10 |
nemo | rwp: I figured I could use that. but. yes this regressed very recently, so I guess I can just switch to a slightly older kernel | 22:10 |
rwp | Linux 6 has been a rough path. Good luck! | 22:15 |
coyotes4ys | help! i have crowz devuan, openbox, and i keep having it freeze up in various ways: twice today i was playing a video and everything froze including inputs, then once everything froze except the mouse cursor could be moved but clicking did nothing, then a few minutes ago i could still type things in term but everything came back command not found or input error (iirc) | 23:24 |
coyotes4ys | help! i'm back | 23:31 |
coyotes4ys_ | anybody here? i really need help | 23:33 |
coyotes4ys_ | AEonFyr, krzych, nckx i'm sorry to call random people but i really need some help on crowz devuan | 23:35 |
coyotes4ys_ | ugh | 23:36 |
eyalroz | rwp: I don't need a rescure, I boot fine... anyway, I'll try downloading and checking what it does.. | 23:41 |
rwp | When that hit me in Unstable my system would not boot due to the corrupted initramfs. I needed to rescue my system. | 23:42 |
coyotes4ys_ | rescue how | 23:42 |
coyotes4ys_ | thank you rwp how? | 23:42 |
rwp | Hi coyotes4ys! That comment was intended for eyalroz and our previous discussion. | 23:43 |
coyotes4ys_ | oh | 23:43 |
coyotes4ys_ | i am having a serious prob, system keeps crashing | 23:43 |
rwp | coyotes4ys, as to your problem, what graphics adaptor do you have? (Please don't say nVidia. Unless it is. Then do admit to it.) | 23:44 |
coyotes4ys__ | whiskeylake-u gt2 [uhd graphics 620] | 23:46 |
coyotes4ys__ | rwp | 23:46 |
rwp | That's the Intel graphics which is in Linux kernel main and should be good. I am using it too on my other machine and it works okay. Should be anyway. | 23:50 |
rwp | After a freeze is there anything interesting in /var/log/syslog? (I always ask but I never find anything about freezes when I am having problems either.) | 23:51 |
rwp | Unfortunately I am in the middle of $WORK stuff and also don't really know what to suggest. Maybe others in the channel will have better ideas. Good luck! | 23:52 |
coyotes4ys | help me! | 23:56 |
coyotes4ys | rwp i'm back | 23:56 |
coyotes4ys | did you get my answer | 23:56 |
coyotes4ys | for anyone who wants to help, first my system was crashing but still displaying deskptop etc as before, but inputs wouldn't work or only somewhat worked, | 23:57 |
rrq | coyotes4ys: is the disk(s) full? | 23:58 |
coyotes4ys | thank you rrq! no not full | 23:58 |
coyotes4ys | thunar and conky show hundreds of gigs free | 23:58 |
coyotes4ys | also just now the thing went straight to asus boot options, no bootable os detected! twice this happened, then third time, crowz devuan came back up and i'm in that now! | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!