I’m running xUbuntu 16.04 on an Asrock X370 Taichi motherboard with a Ryzen 7 1800X CPU and 32GB of memory (2 16GB Kingston ValueRAM KVR24E17D8/16 DDR4-2400 16GB/2Gx72 ECC). This memory is not on the QVL. UEFI version is P4.70.
Global C-state is disabled; Vcore is 1.3625, SoC is 1.1. SMT is on.
I use zenstates.py to be sure C6 is disabled.
Processor is UA 1741SUS and is from an RMA.
Kernel is 4.15.0-24-generic #26~16.04.1-Ubuntu SMP
Video is from a Asus Geforce GTX 1050TI with proprietary driver 390.48
I’ve run kill-ryzen for 24 hours without errors using a 17.04 live disk. I’ve run memtest86 for 24 hours without errors.
Everything sounds copacetic doesn’t it? However, on a regular basis, Thunderbird or Corebird will Segfault. Usually this happens when the system is idle.
Usually it’s Thunderbird which crashes. I’ve not noticed any other application crashes.
Any suggestions on tracking this problem down and fixing it?
Is your system unstable without C-States disabled? Disabling them should not be a solution. If you have to disable C-States to get a stable system, you need to RMA the CPU.
run ryzen-kill again without c-states disabled and see what happens.
With the exception of the Thunderbird segfaults, the system is stable; I tried disabling c-states to see if that would help with Tbird. I need to disable C6 to keep the system from hanging when idling. The C6 thing seems to be pretty common.
It’s just not enough information to make even an informed guess.
Thunderbird or Corebird segfaulting could also be a completely unrelated software issue.
What I can say is that I have not yet seen this issue where at idle on a bad/good Ryzen only a specific application will segfault. If the chip or board was bad it was affecting everything, especially under load.
I can’t help you with this.
Maybe try a different OS and see if it happens again or with other applications.
I have my doubts it’s a hardware problem, but if it is, and this is a stretch, it could be a issue somewhere on the mainboard.
I’m going to assume that your board BIOS is up to date as usual.
I’d pretty much come to the same conclusion myself. I’m tempted to try xUbuntu 18.04, but I’m not sure it’s different enough from 16.04 to accomplish anything. I can try Fedora or Manjaro. Both seem to be pretty cutting edge. Both are missing things I’ve gotten used to… Sigh. Need to ponder how best to do this without shooting myself in the foot.
I am running Kubuntu 18.04 on the X470 Taichi ultimate with a 2700.
Gonna let thunderbird run in the background for a while, I’m not using the program myself.
I know, lot’s of differences and I don’t expect any conclusive result from this.
It’s been a while since I last tried either one, but IIRC, VMware workstation didn’t work either place. I couldn’t build makemkv on one or both. Sorry for not having a very good memory. There are workarounds for everything of course.
Install another M.2 drive for a new OS leaving the 16.04 drive in place for dual boot.
Install xUbuntu 18.04 on the new drive and copy my home directory over from the 16.04 system. Install my “bread and butter” apps and try it out for a few days.
If the app crashes go away, do my Happy Dance and move on; otherwise, try another Linux variant on the new drive. I’m thinking either Fedora or Manjaro. Both have their advantages and disadvantages, but I’m not going to worry about that very much until I need to.
By the way, I spun up Fedora and Manjaro VMs last night and kicked the tires of both. On Fedora, makemkv didn’t compile. There’s a patch for that, but the same thing happened with Fedora 27(?). Manjaro ticked all the right boxes except for Semaphor from Spideroak. I didn’t see any simple way to get it to work on Manjaro. That’s hardly an exhaustive test, but it served as a mental refresher for me.
Sorry I was gone so long, but I thought I’d post a follow-up. It’s probably a software bug. I completely rebuilt my Thunderbird configuration from scratch and the problem went away. It’s certainly not conclusive, but short of building Thunderbird from source and running gdb… Well, I’m gonna call it solved.