Whenever I am running Parity operations, I get several segfault issues.

Apr 28 18:23:59 Persephone kernel: r8169 0000:06:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM

Apr 28 18:23:59 Persephone kernel: mpt3sas 0000:07:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM

Apr 28 18:24:03 Persephone emhttpd: read SMART /dev/sdj

Apr 28 18:25:05 Persephone kernel: Web Content[3244676]: segfault at 0 ip 000014e69f8a12e8 sp 00007ffc56e301f0 error 6 in libxul.so[30a02e8,14e69f3bf000+6411000] likely on CPU 19 (core 35, socket 0)

Apr 28 18:25:05 Persephone kernel: Code: ff ff ff f0 48 ff 4f 08 0f 85 14 ff ff ff 48 8b 07 ff 50 28 e9 09 ff ff ff 48 8d 05 3c be 28 fd 48 8b 0d 7b 86 3f 06 48 89 01 <c7> 04 25 00 00 00 00 62 01 00 00 e8 c8 41 f2 05 e8 53 41 f2 05 cc

I would suspect the RAM, but the memtest passed after 1 pass, and it's, so far, only during parity operations.

persephone-diagnostics-20260428-1823.zip

Let memtest run for several hours

Hmm, is there a generally accepted duration? Unfortunately, I built it too well, and its kinda a prod env for me. even as a hobbyist. But I can try and let it run overnight?

I even hate to mention this out of fear, but I did just replace my CPU. I would see some kernel issues with the old CPU, but sparingly. I upgraded the CPU in question. Is it possible that a newer CPU would exacerbate a failing RAM?

Since it's a 13900K it could very well be the Intel 13/14 gen issue.

welp, either way I bet it's the CPU as it's the only new thing to have changed. Memtest ran for 10 hours, no issues. Guess I'll be making a return. in terms of the 13/14th gen issue, it could be. I upgraded the BIOS before installation, but who knows.

Pretty common issues with these CPUs, even with updated BIOS. Know of users who are on their 3rd and 4th CPU,the 13900/14900K especially seems to be the worst offenders.

Got the og cpu back in and no issues, so pretty cut and dry.

tried a different CPU and still an issue, not sure what the deal is, but only 1 CPU seems to work, and then anything else just does't its all error 6, though I am dubious to think that out of 3 CPUs, only 1 works

this time i9-12900k

persephone-diagnostics-20260504-1907.zip

It's still crashing. Either those CPUs are bad or there's another hardware issue, like board or RAM.

There has not been a crash, just noticing the logs, in my own investigation, I found 3 things that stand out

1. PID task limit on a Docker that is CPU pinned
2. Kernel clock unsynchronized errors
3. There were 2 files that a Docker container was trying to access that did not have permissions to anything that was repeatedly spammed by the Docker task.

I fixed the last and nothing since last night. I am just not sure what the risk is of letting it go like this.

Summary: RAM tested good and stable for years, 3 CPUs, 2 are known good. The last thing is the mobo to see if there are any noticeable issues. I am wondering if any software issues might cause this before it becomes expensive.

actually I think my docker might be currupted

root@Persephone:~# docker system df

TYPE TOTAL ACTIVE SIZE RECLAIMABLE

Images 44 33 35.11GB 30.5GB (86%)

Containers 34 34 3.798GB 0B (0%)

Local Volumes 136 1 138.4MB 113.6MB (82%)

Build Cache 0 0 0B 0B

root@Persephone:~# docker system prune

WARNING! This will remove:

- all stopped containers

- all networks not used by at least one container

- all dangling images

- unused build cache

Are you sure you want to continue? [y/N] y

Total reclaimed space: 0B

root@Persephone:~#

Why am I not reclaiming the unused space.

12 hours ago, Zechositus said:

There has not been a crash

I meant there are multiple apps crashing/segfaulting, this is typcially hardwar erlated:

May 4 17:51:03 Persephone kernel: Web Content[2914015]: segfault at 0 ip 000014bc94080ea4 sp 00007ffcb8b7dbe0 error 6 in libxul.so[3c7fea4,14bc92fbf000+6411000] likely on CPU 4 (core 8, socket 0)

May 4 17:51:03 Persephone kernel: Code: 10 48 8b 3c 24 48 85 ff 0f 84 43 fc ff ff 48 8b 07 ff 50 10 e9 38 fc ff ff 48 8d 05 10 ba 57 fc 48 8b 0d bf 8a 81 05 48 89 01 <c7> 04 25 00 00 00 00 dc 01 00 00 e8 0c 46 34 05 e8 97 45 34 05 cc

May 4 17:51:03 Persephone kernel: camoufox-bin[2914208]: segfault at 0 ip 000055d0be4ec8e3 sp 00007ffffa7f1940 error 6 in camoufox-bin[838e3,55d0be491000+78000] likely on CPU 8 (core 16, socket 0)

May 4 17:51:03 Persephone kernel: Code: 04 25 28 00 00 00 48 3b 44 24 10 75 2d 48 c1 ea 04 48 89 d0 48 83 c4 18 c3 48 8d 05 20 bb f8 ff 48 8d 0d 18 17 02 00 48 89 01 <c7> 04 25 00 00 00 00 2b 01 00 00 e8 ad 54 fb ff e8 b8 b6 01 00 cc

But you can try recreating the docker image to see if that helps.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file

Then:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications

Also see below if you have any custom docker networks:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

I believe it is this

https://github.com/ThePhaseless/Byparr/issues/322

I resolved the problem. 2 things were happening that resulted in the seg fault.

1. UnRaid uses the same kernel for the OS as for the Docker containers, unless I am mistaken, but I couldn't find anything to the contrary, and I had a failing Docker container that was crashing repeatedly after hitting the PID limit, making it intermittent. https://github.com/ThePhaseless/Byparr/issues/322

2. The higher clock rate of the new CPU was creating a race condition for an invalid memory address due to the crash, hence all of my segfaults were the same error 6 of a write condition.

Replacing the failing flaresolverr container with another flaresolver rectified my issues, both the PID limit, the segfaults, and the stability of containers using the flaresolverr. 20 hours of no Segfault, previously every 6 hours, and even my temps are down a bit.