this post was submitted on 11 Jan 2024
36 points (92.9% liked)

Linux

48655 readers
1989 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
36
Random application segfaults on Arch (lemm.ee)
submitted 11 months ago* (last edited 11 months ago) by [email protected] to c/[email protected]
34 comments fedilink hide all child comments
 

Hi everyone,

ever since I switched to Arch about two months ago, most applications segfault multiple times a day. There doesn't seem to be any pattern for the crashes, sometimes it's even happening while idling (e.g. reading a news article).

Things I've tried without any luck so far:

  • Running Firefox in safe-mode without any extensions
  • Switching from regular to LTS kernel
  • Disable Hardware Acceleration in Firefox
  • Change RAM speed and timings
  • Run Memtest successfully
  • Replace entire RAM with a new certified kit
  • Use only a single RAM slot
  • Apply Ryzen fixes (iommu=soft, limit c-states)
  • Use only a single CPU core (maxcpus=1)
  • Downgrade Nvidia driver to 535xx
  • Use Nouveau instead of the nvidia driver
  • Use Openbox instead of KDE
  • Disable zswap and THP

Here's full journalctl from a day where both Spotify and Firefox crashed at the end, a few seconds after each other:

https://pastebin.com/BH0LMnD9

Some more info about my system:

  • Ryzen 5 3600X
  • MSI B450M PRO-VDH Max
  • 32GB RAM @ 3200MHz
  • Geforce RTX 2070 SUPER (using nvidia-dkms)
  • Plasma 5.27.10 on X11

I'm pretty sure that it's not hardware related, because I've booted up a Debian 12 live image where everything ran for several hours without a crash. But it seems to be Arch related, as I also booted up a fresh EndeavourOS live image (so basically Arch), where applications also randomly segfaulted. Any idea why everything works fine on Debian but not on Arch? Debian uses the 6.1 kernel, which I already tried, so that's not it.

Let me know if you need any more information that might help solve this issue. Thanks!

Edit [solved]: It looks like disabling PBO in the UEFI/BIOS did the trick. The strange thing is, after enabling it again, it's still not crashing again. Someone suspected that the MoBo default/training settings were faulty, so I guess this was a very rare case here. That's probably why it took so long to find a solution. Thanks everyone for helping me out!

all 36 comments
sorted by: hot top controversial new old
[–] [email protected] 10 points 11 months ago (1 children)

The crashes are in the middle of browsers (both Firefox and chrome embedded in Spotify), if you try a simple mprime stress test (from the AUR mprime-bin) does it crash too?

[–] cbarrick 5 points 11 months ago

Yeah, this sounds somewhat like unstable hardware.

Definitely start with a stress test or memory test.

[–] mmstick 8 points 11 months ago* (last edited 11 months ago) (1 children)

Make sure you have the latest firmware for your motherboard. This sounds like unstable voltages for memory, or an overly-aggressive PBO curve. Did you try disabling the XMP profile on the RAM, disabling PBO, and upping the voltages (within safe limits) of the SOC, DDR, and VDDP? You might find some useful info here[0] or here[1] if you intend to run your memory at 3200 MHz.

[–] [email protected] 2 points 11 months ago (2 children)

Motherboard firmware is up-to-date, and I've already tried disabling XMP. I'll give disabling PBO a try, thanks!

I don't necessarily have to run at 3200MHz, if it means that the system is finally stable. But since it's already crashing at the default 2133MHz, I suppose there's no use in playing with the voltages?

[–] mmstick 2 points 11 months ago* (last edited 11 months ago) (1 children)

It's difficult to say for sure with certainty what the issue is without trial and error. I would expect that the motherboard's manufacturer would make sure that their board can successfully pass all tests with the standard JEDEC spec for DDR4 (2133 MHz).

Since you say that you've tried different RAM kits, another alternative could be the cleanliness of power from the power supply. Perhaps there is intermittent voltage droop, and you need to experiment with the Load Line Calibration settings to adjust for vdroop between idle and load. Disabling frequency boosting and manually setting the CPU frequency could help check if it's related to that. PBO curves might be undervolting too much while idle.

[–] [email protected] 3 points 11 months ago (1 children)

I'm a bit speechless right now. I've disabled PBO and didn't have a single crash since then, everything's been running fine for hours. Just to make sure that this really was the issue, I've enabled PBO again - but still haven't experienced any crashes in the last hours. I have no idea how simply disabling and then enabling the feature again fixed my issue, but for now it seems like all is well.

Do you have any explanation for this weird behavior?

Anyway, thank you very much for your suggestion, looks like this actually did the trick!

[–] mmstick 3 points 11 months ago* (last edited 11 months ago)

Sounds like voltage droop and/or a motherboard with faulty automatic "training" settings. I don't recall if the Ryzen 3000 had custom PBO curves, but tweaking this can fix it. Upping LLC and the SOC and CPU voltage slightly alternatively could help. Though I've had my most stable overclock by disabling PBO entirely and using a manual CPU multiplier.

[–] [email protected] 1 points 11 months ago

Try running a memtest, if it's not voltages it could be a faulty ram stick. I've had it where data gets written, but what is read is garbage, corrupted some pretty important files on my system when I ran an update and it used that faulty section for it's buffer.

[–] [email protected] 7 points 11 months ago* (last edited 11 months ago) (2 children)

Could be a defective library that's used by many apps. Glibc, etc. That said, if something like this is that broken, others should be complaining about it too.

[–] [email protected] 6 points 11 months ago

One crash was in libxul and the other in libcef I doubt this is a specific lib

[–] [email protected] 4 points 11 months ago (2 children)

Maybe a corrupt download/copy of a library.... Try a reinstall of say glibc ?

[–] [email protected] 1 points 11 months ago

This is a good idea, but they probably need to figure out which lib is shitting the bed first. There's too many libs to try otherwise.

[–] [email protected] 1 points 11 months ago

Maybe a corrupt download/copy of a library… Try a reinstall of say glibc ?

Doesn't explain why it also crashes in an EndeavourOS live image...

[–] lemming741 6 points 11 months ago (1 children)

I had a 3700x that was doing that sort of thing. It seemed mostly random, but moving big files would crash it pretty often. It ran memtest86 for 3 days no problem. I replaced part by part, and it ended up being the CPU. I'd bought it second hand so it may have been abused.

[–] [email protected] 1 points 11 months ago (2 children)

But if it's a faulty CPU, wouldn't it also crash on Debian?

[–] [email protected] 6 points 11 months ago (1 children)

Wild guess, there could be differences in compilation optimization that expose this hypothetical proc defect on Arch but not on Debian. Try a day or two of mprime as some others suggested.

[–] [email protected] 3 points 11 months ago (1 children)

Try a day or two of mprime as some others suggested.

That wouldn't necessarily reveal a faulty CPU or firmware. I used to have a 3600x that would sometimes crash on idle at low clocks but would run cinebench or geekbench all day and all night.

[–] [email protected] 1 points 11 months ago

For sure. It would catch a subset of issues.

[–] lemming741 1 points 11 months ago

I would think so, but it sounds similar enough with the symptoms and very similar on the model CPU so I thought I'd mention it

[–] [email protected] 4 points 11 months ago (1 children)

Can you enable core dumps and get stack traces? From there you should be able to figure out which shared library is broken.

[–] [email protected] 2 points 11 months ago

Uhm, isn't that what can be found at the end of the journalctl log I posted? Or are you talking about something different?

[–] [email protected] 4 points 11 months ago (1 children)

I’m pretty sure that it’s not hardware related

Random segfaulting is not something that "just happens" because of an OS misconfiguration, then if the same problem happens on Arch as well as on a clean EndeavourOS live image it convinces me that it is in fact hardware related somehow. As you have already replaced the RAM, my guess is CPU or motherboard issue.

Zen2/B450 is a widely used and well supported configuration on Linux that you normally shouldn't have issues with, but Zen2 CPUs are rather notorious for having fragile memory controllers, and sometimes dodgy AGESA firmware releases that can cause issues on some CPUs. I used to have a 3600X myself that started crashing at idle around a particular firmware release of my motherboard, and it was fixed by a subsequent release.

BTW the fact that it doesn't happen on Debian doesn't necessarily mean that Arch is the culprit. It could just be that Debian is not triggering the fault because of different, perhaps more conservative, compiler optimizations.

As a last ditch effort, you could try resetting your entire UEFI (bios) settings to default, preferably by pulling the CMOS battery.

BTW, is it only GUI applications that are segfaulting? Or other programs as well? Do you have an old spare GPU you can test with?

[–] [email protected] 2 points 11 months ago (1 children)

I already did a UEFI reset, that didn't help. As far as I can tell, it's only GUI applications, I haven't seen a segfault for something else so far. Unfortunately I don't have any other GPU right now.

It seems that a solution was found though (at least for now, it didn't crash since a few hours) here: https://lemm.ee/comment/8161085

[–] [email protected] 2 points 11 months ago

Glad to hear that disabling PBO helped, but it does indicate that something may not be entirely healthy with your CPU (or with the way the motherboard is driving it, that also can't be excluded)

[–] [email protected] 2 points 11 months ago (1 children)

I would guess that this is ~~CPU~~ SSD issue you ran an live debian image from an usb and did not encounter any crashes.

[–] [email protected] 2 points 11 months ago

But I also ran a live EndeavourOS from USB and the same crashes happened.

[–] [email protected] 1 points 11 months ago (1 children)

Try increasing RAM voltage? Might make it more stable under load. I had a similar issue, clean memtest, but games would randomly crash. Increasing RAM voltage fixed it.

[–] [email protected] 1 points 11 months ago (1 children)

What voltage should I try? It's currently at 1.35V, and I've read somewhere that this is the highest "safe" voltage.

[–] [email protected] 1 points 11 months ago* (last edited 11 months ago)

I jumped to 1.4V which afaik is safe. But i cant guarentee anything. Going up slowly might be better, but stop at 1.4?

Corsair says 1.4 is safe: https://help.corsair.com/hc/en-us/articles/360052448851-Tips-on-safely-overclocking-memory

[–] [email protected] 1 points 11 months ago

Could you try an older endeavour os image?

This sounds very much like a driver/firmware/hardware issue