dkuhn

interesting, I'll roll back to 6.4.0 then. I would have preferred to stay on 6.5.0 as the Ryzen fixes were enticing, but if this is going to continue I'll stick with 6.4.0

I am experiencing an issue where the docker service is hanging/crashing and not restarting. My Plex container appears to be part of the issue as its the only one that appears to go down while this is happening. I captured this section from the syslog - Mar 18 18:49:51 US-UNRAID01 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 Mar 18 18:49:51 US-UNRAID01 kernel: IP: tcp_push+0x4e/0xee Mar 18 18:49:51 US-UNRAID01 kernel: PGD 354206067 P4D 354206067 PUD 1c7b6e067 PMD 0 Mar 18 18:49:51 US-UNRAID01 kernel: Oops: 0002 [#1] PREEMPT SMP NOPTI Mar 18 18:49:51 US-UNRAID01 kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables vhost_net tun vhost tap veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat nfsv3 nfs lockd grace sunrpc md_mod edac_mce_amd kvm_amd kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 mpt3sas crypto_simd r8169 glue_helper ahci libahci wmi_bmof raid_class scsi_transport_sas cryptd i2c_piix4 mii ccp i2c_core wmi button acpi_cpufreq Mar 18 18:49:51 US-UNRAID01 kernel: CPU: 0 PID: 27023 Comm: Plex Media Serv Not tainted 4.14.25-unRAID #1 Mar 18 18:49:51 US-UNRAID01 kernel: Hardware name: System manufacturer System Product Name/PRIME X370-A, BIOS 0805 06/20/2017 Mar 18 18:49:51 US-UNRAID01 kernel: task: ffff8801f81e0e00 task.stack: ffffc90003da8000 Mar 18 18:49:51 US-UNRAID01 kernel: RIP: 0010:tcp_push+0x4e/0xee Mar 18 18:49:51 US-UNRAID01 kernel: RSP: 0018:ffffc90003dabc70 EFLAGS: 00010246 Mar 18 18:49:51 US-UNRAID01 kernel: RAX: 0000000000000000 RBX: 00000000000005a8 RCX: 0000000000000000 Mar 18 18:49:51 US-UNRAID01 kernel: RDX: 0000000000000000 RSI: 0000000000004040 RDI: ffff88010edd5800 Mar 18 18:49:51 US-UNRAID01 kernel: RBP: 0000000000000000 R08: 00000000000005a8 R09: ffffffff8151bec7 Mar 18 18:49:51 US-UNRAID01 kernel: R10: ffff88010edd5958 R11: 0000000000000000 R12: ffff88010edd5800 Mar 18 18:49:51 US-UNRAID01 kernel: R13: 0000000000000000 R14: ffff88000389ae00 R15: 00000000ffffffe0 Mar 18 18:49:51 US-UNRAID01 kernel: FS: 000014bb4e9fe700(0000) GS:ffff88041ec00000(0000) knlGS:0000000000000000 Mar 18 18:49:51 US-UNRAID01 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 18 18:49:51 US-UNRAID01 kernel: CR2: 0000000000000038 CR3: 00000001c7a8a000 CR4: 00000000003406f0 Mar 18 18:49:51 US-UNRAID01 kernel: Call Trace: Mar 18 18:49:51 US-UNRAID01 kernel: tcp_sendmsg_locked+0xa53/0xbac Mar 18 18:49:51 US-UNRAID01 kernel: tcp_sendmsg+0x23/0x35 Mar 18 18:49:51 US-UNRAID01 kernel: sock_sendmsg+0x14/0x1e Mar 18 18:49:51 US-UNRAID01 kernel: ___sys_sendmsg+0x1ab/0x229 Mar 18 18:49:51 US-UNRAID01 kernel: ? seccomp_run_filters+0xdc/0x106 Mar 18 18:49:51 US-UNRAID01 kernel: ? generic_file_read_iter+0x595/0x6e4 Mar 18 18:49:51 US-UNRAID01 kernel: ? __seccomp_filter+0x26/0x1c5 Mar 18 18:49:51 US-UNRAID01 kernel: ? dput+0x30/0x190 Mar 18 18:49:51 US-UNRAID01 kernel: ? __sys_sendmsg+0x3c/0x5d Mar 18 18:49:51 US-UNRAID01 kernel: __sys_sendmsg+0x3c/0x5d Mar 18 18:49:51 US-UNRAID01 kernel: do_syscall_64+0xfe/0x107 Mar 18 18:49:51 US-UNRAID01 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Mar 18 18:49:51 US-UNRAID01 kernel: RIP: 0033:0x14bb5b5c2a6d Mar 18 18:49:51 US-UNRAID01 kernel: RSP: 002b:000014bb4e9fd390 EFLAGS: 00000293 ORIG_RAX: 000000000000002e Mar 18 18:49:51 US-UNRAID01 kernel: RAX: ffffffffffffffda RBX: 000014bb4e9fd3c0 RCX: 000014bb5b5c2a6d Mar 18 18:49:51 US-UNRAID01 kernel: RDX: 0000000000004000 RSI: 000014bb4e9fd3c0 RDI: 0000000000000082 Mar 18 18:49:51 US-UNRAID01 kernel: RBP: 000014bb4e9fd3c0 R08: 000014bb2ac11458 R09: 000014bb2ac11468 Mar 18 18:49:51 US-UNRAID01 kernel: R10: 0000000000000001 R11: 0000000000000293 R12: 000014bb4e9fe5b8 Mar 18 18:49:51 US-UNRAID01 kernel: R13: 0000000000000001 R14: 0000000000000001 R15: 000014bb2ac11458 Mar 18 18:49:51 US-UNRAID01 kernel: Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 68 05 00 00 41 d1 e9 44 2b 8f 6c 06 00 00 44 03 8f 74 06 00 00 79 10 <80> 48 38 08 8b 8f 6c 06 00 00 89 8f 74 06 00 00 40 80 e6 01 74 Mar 18 18:49:51 US-UNRAID01 kernel: RIP: tcp_push+0x4e/0xee RSP: ffffc90003dabc70 Mar 18 18:49:51 US-UNRAID01 kernel: CR2: 0000000000000038 Mar 18 18:49:51 US-UNRAID01 kernel: ---[ end trace 76125233344d61b0 ]--- Not exactly sure what this means. I've also attached my anonymized diagnostics.zip file if anyone can lend a hand. I recently upgraded to 6.5.0-rc6 and added an MD1200 DAS with 12 disks. Hardware Info: M/B: ASUSTeK COMPUTER INC. - PRIME X370-A CPU: AMD Ryzen 7 1800X Eight-Core @ 3600 HVM: Enabled IOMMU: Enabled Cache: 768 kB, 4096 kB, 16384 kB Memory: 16 GB (max. installable capacity 64 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 9000 Kernel: Linux 4.14.25-unRAID x86_64 OpenSSL: 1.0.2n us-unraid01-diagnostics-20180318-1955.zip

I had some pretty heavy transcodes going on for almost the entire week. They finished, and I guess that's when the idle usage happened. It is also crashing during streams, but I attribute that to the fact that the CPU is going back to idle during a plex "throttled" stream as the CPU is faster than the transcode job! (Which, in my book is a good thing, assuming we can get that C state issue fixed)

Model: Custom M/B: ASUSTeK COMPUTER INC. - PRIME B350M-A CPU: AMD Ryzen 5 1600 Six-Core @ 3200 HVM: Enabled IOMMU: Enabled Cache: 576 kB, 3072 kB, 16384 kB Memory: 16 GB (max. installable capacity 16 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 9000 Kernel: Linux 4.9.28-unRAID x86_64 OpenSSL: 1.0.2k Uptime: 0 days, 07:23:50 No overclocks - completely stock. Didn't want to open that can of worms yet. https://puu.sh/vXEIT/475465ab36.rar That's the last log I have at the moment. It hasn't crashed today, will post a new log once it does.

I've been running troubleshooting mode each time it boots back up - will post logs next time it crashes. Logs haven't presented any telling errors so far, they just end. I am indeed running Plex as a docker container, but the transcode location is my cache SSD not /tmp. Docker containers: couchpotato deluge munin-server owncloud PlexMediaServer plexpy sabnzbd sonarr Plugins: Community Applications Dynamix SSD Trim Fix Common Problems Nerd Tools

https://forums.lime-technology.com/topic/57294-unraid-633-crashing/ Linking my post here as I just found this thread. Having stability issues even with Global C State Control set to "disabled". Worked for about a week then it crashed, and has been crashing every day since then.

Adding to this, I'm on Kernel 4.9.28-unRAID. Kernel 4.11 is available on kernel.org and includes new Ryzen code. Any chance that can be shipped soon, or do I need to build my own?

So disabling global C states helped immensely, but now I'm back to square one. The system seems to be crashing every day or so at this point. Complete lockup - look at the display and it presents the CLI login but accepts no input. Doesn't respond to ICMP. Resetting the system brings it back up until it crashes again. I have Fix Common Problems installed along with the Nerd Pack and mcelog. It was presenting a hardware error but complaining about mcelog a few days ago, but since I've installed it the error has not returned. Any ideas? Is this an issue with Ryzen still, or do I have something else going on?

Dope. Will make this change and monitor. Thanks for the quick suggestion!

So I recently installed an unraid 6.3.3 server that appears to be having crashing issues sporadically. I ran the CA fix common issues troubleshooting mode and logs are attached. Not sure what's going on. When it crashes it's as if the entire OS hangs, requiring a manual reset to come back. Nothing on the screen when it happens. Specs: AMD Ryzen 5 1600 16GB DDR4 RAM 5x 8TB WD Red (Array) 1x 525GB Crucial SSD (Cache) FCPsyslog_tail.txt us-unraid01-diagnostics-20170512-1650.zip