3 ms·

I bought a custom-built Rzyen-based PC around Easter, and I have experienced some issues with it; I am not sure, though, were to put the blame (CPU, motherboard

by krylon 9y ago

I bought a custom-built Rzyen-based PC around Easter, and I have experienced some issues with it; I am not sure, though, were to put the blame (CPU, motherboard/firmware, operating system (which is openSUSE Tumbleweed)). Under heavy load, the machine has performed most gracefully. However, the machine does freeze (almost) completely when left idle for a while (usually > 1 hour). When it happens, it sometimes still responds to pings, but nothing more; if I try to ssh into it from my laptop, I do not even receive a TCP ACK. Unfortunately, I guess, there is no Kernel Panic, so no memory dump I could inspect or send to somebody who actually knows how to make sense of it. On the upside, I have gotten into the habit of putting the machine into standby when I leave it alone for more than a couple of minutes, and I was pleasantly surprised that Suspend-to-Disk is a very acceptable option with an M.2 SSD. ;-P Asus (who built my mainboard) releases firmware updates (which include microcode updates) on a fairly regular basis, so I hope this problem will be fixed eventually. I knew there was a risk of something like this happening when I got this machine, and overall, I am not disappointed. Otherwise, I am _very_ happy with the machine.

stefantalpalaru 9y ago
> However, the machine does freeze (almost) completely when left idle for a while (usually > 1 hour). Try disabling the C6 power state from BIOS: https://www.reddit.com/r/hardware/comments/6rklcf/ryzen_segfaulting_under_heavy_load/dl66o4b/ https://www.reddit.com/r/hardware/comments/6rklcf/ryzen_segf...
- krylon 9y ago
  Thanks for the hint!
- theandrewbailey 9y ago
  I'll definitely try this. I downgraded my latest BIOS because I couldn't stand the random crashes that had no rhyme or reason (crashed during gaming, youtube, encrypting my drives, emailing, browsing, among other activities).
exikyut 9y ago
> When it happens, it sometimes still responds to pings, but nothing more; if I try to ssh into it from my laptop, I do not even receive a TCP ACK. Interesting. Pinging is handled entirely by the kernel. I wonder if the ACK code path has to enter and leave userspace before the response comes out the network card? If disabling C6 (as per other comments) doesn't fix it, one possible place to start would be 1. Something like "while true; do date > file; sync; sleep 1; done" to track when userspace dies. (Okay, a proper C program that does fdatasync() just for that file would probably be better.) 2. Get inspired by http://elixir.free-electrons.com/linux/latest/source/drivers/base/power/trace.c http://elixir.free-electrons.com/linux/latest/source/drivers..., which borrows your system's RTC as non-volatile storage with simple write semantics - maybe you can borrow the year/month fields to store the current HH:MM. If on reboot the stored value matches wall clock time from another source (synced with the PC beforehand) at the moment you pull the plug, the kernel was still running. Then you could eg use the whole value to trace kernel locks and major mutexes etc. 3. Actually, if you can ping the kernel and that works, you could abuse the network stack to get data out!! Eg, pinging with certain bits set in the packet could trigger some magic code that returns system info. ICMP PING tunneling is a thing, and you could totally use this. "But... I just want to use my computer..." That's fair - waiting for someone else to fix everything works too :P
- dom0 9y ago
  > Interesting. Pinging is handled entirely by the kernel. I wonder if the ACK code path has to enter and leave userspace before the response comes out the network card? Normally there is an incoming backlog, i.e. the kernel accepts (SYN/ACKs) incoming connections before accept(2) happens; accept(2) just pops a connection off the backlog.
tarruda 9y ago
I had a similar problem with my ryzen 1700/asrock x370 taichi: Every time I left computer idle, when I came back it was frozen. I didn't try pinging to see if it responded. What solved the problem for me completely was blacklisting the nouveau module for nvidia(about two weeks without a single freeze). In my case it was an option because I use an AMD gpu for linux and a nvidia for passthrough, so I have no need for the nouveau module to be loaded. BTW this is where I got the hint: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 What I got from this is that it is not an nouveau driver bug, but rather a hardware bug that has a greater chance of being triggered if the module is loaded. The same thread suggests that disabling ASLR is also a valid workaround.
- krylon 9y ago
  Thanks for that advice! Unfortunately, I have an nVidia GPU, and I use the nouveau driver, because apparently using nVidia's proprietary driver on Tumbleweed is a huge PITA. Maybe I will have to bite that bullet eventually, though.

by krylon 9y ago

stefantalpalaru 9y ago

> However, the machine does freeze (almost) completely when left idle for a while (usually > 1 hour). Try disabling the C6 power state from BIOS: https://www.reddit.com/r/hardware/comments/6rklcf/ryzen_segfaulting_under_heavy_load/dl66o4b/ https://www.reddit.com/r/hardware/comments/6rklcf/ryzen_segf...

krylon 9y ago
Thanks for the hint!
theandrewbailey 9y ago
I'll definitely try this. I downgraded my latest BIOS because I couldn't stand the random crashes that had no rhyme or reason (crashed during gaming, youtube, encrypting my drives, emailing, browsing, among other activities).

exikyut 9y ago

> When it happens, it sometimes still responds to pings, but nothing more; if I try to ssh into it from my laptop, I do not even receive a TCP ACK. Interesting. Pinging is handled entirely by the kernel. I wonder if the ACK code path has to enter and leave userspace before the response comes out the network card? If disabling C6 (as per other comments) doesn't fix it, one possible place to start would be 1. Something like "while true; do date > file; sync; sleep 1; done" to track when userspace dies. (Okay, a proper C program that does fdatasync() just for that file would probably be better.) 2. Get inspired by http://elixir.free-electrons.com/linux/latest/source/drivers/base/power/trace.c http://elixir.free-electrons.com/linux/latest/source/drivers..., which borrows your system's RTC as non-volatile storage with simple write semantics - maybe you can borrow the year/month fields to store the current HH:MM. If on reboot the stored value matches wall clock time from another source (synced with the PC beforehand) at the moment you pull the plug, the kernel was still running. Then you could eg use the whole value to trace kernel locks and major mutexes etc. 3. Actually, if you can ping the kernel and that works, you could abuse the network stack to get data out!! Eg, pinging with certain bits set in the packet could trigger some magic code that returns system info. ICMP PING tunneling is a thing, and you could totally use this. "But... I just want to use my computer..." That's fair - waiting for someone else to fix everything works too :P

dom0 9y ago
> Interesting. Pinging is handled entirely by the kernel. I wonder if the ACK code path has to enter and leave userspace before the response comes out the network card? Normally there is an incoming backlog, i.e. the kernel accepts (SYN/ACKs) incoming connections before accept(2) happens; accept(2) just pops a connection off the backlog.

tarruda 9y ago

I had a similar problem with my ryzen 1700/asrock x370 taichi: Every time I left computer idle, when I came back it was frozen. I didn't try pinging to see if it responded. What solved the problem for me completely was blacklisting the nouveau module for nvidia(about two weeks without a single freeze). In my case it was an option because I use an AMD gpu for linux and a nvidia for passthrough, so I have no need for the nouveau module to be loaded. BTW this is where I got the hint: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 What I got from this is that it is not an nouveau driver bug, but rather a hardware bug that has a greater chance of being triggered if the module is loaded. The same thread suggests that disabling ASLR is also a valid workaround.

krylon 9y ago
Thanks for that advice! Unfortunately, I have an nVidia GPU, and I use the nouveau driver, because apparently using nVidia's proprietary driver on Tumbleweed is a huge PITA. Maybe I will have to bite that bullet eventually, though.