Tristankin

If anyone else stumbles across this. It was a hardware issue. I replaced the PSU and RAM, still got crashes. Ended up being the CPU, crashed whenever it was running a version newer than 6.8.3. I recently replaced the i3-9100 with a i7-9700T and the issue has been solved.

This took me a while to work out so I thought I would share my swag config to hopefully help others in the future. htpasswd configured specifically for the admin section as I would like to be able to add nodes while remote from the server swag htpasswd -c /config/nginx/.htpasswd create a file in proxy-confs, I used headscale.subdomain.conf Both headscale and headscale-admin on my proxynet so containers can be called by name rather than ip. server { listen 443 ssl; listen [::]:443 ssl; server_name hs.[yourdomian.com]; include /config/nginx/ssl.conf; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app headscale; set $upstream_port 8085; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_buffering off; add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; auth_basic off; } location /admin/ { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app headscale-admin; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_buffering off; add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; } } Also some changes need to be made to the headscale config as described here: https://gist.github.com/Und3rf10w/1cd618f0656191b7db30fb29aaa35678

Yeah, good idea to check hardware. I have been through the ram replacement route myself (and PSU, and sata card). My system seems particularly sensitive to crashes which forced me to stick to 6.8.3 for 5 years. 7.0.1 was the first new release that seems stable. Crashes occurred as soon as I went to 7.2.2 but I haven't tried the versions between yet. The other things that I tried were to move the transcode directory from /dev/shm to a tmpfs mount in the go file and pining all services off CPU 0 to leave that for unraid itself.

I think 7.2.2 isn't playing nice with the intel iGPU, try rolling back the OS. https://forums.unraid.net/bug-reports/prereleases/69x-611x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-not-alder-lake-r1674/page/14/?tab=comments#comment-36452

I think its a 7.2 issue, I had the same problem with crashes, pretty sure its linked to the intel iGPU https://forums.unraid.net/bug-reports/prereleases/69x-611x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-not-alder-lake-r1674/page/14/?tab=comments#comment-36452

It might be 7.2? Try rolling back the version. I had a similar issue with 7.2.2 https://forums.unraid.net/bug-reports/prereleases/69x-611x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-not-alder-lake-r1674/page/14/?tab=comments#comment-36452

Try blacklisting the gpu and removing intel gpu top. You may be experiencing the following issue.

Let us know how you fare.

Hi All, Just wondering if I could get a little help creating a Profile override in plex. I have created the profiles folder in the appdata directory for Plex Media Server, but I am not sure where in the logs I am meant to be checking to see if the override is being loaded. Old forum posts point to a dlna service debug log but I am assuming this is an older way the logging worked. Let me know where I am meant to be looking and that would be great.

I can confirm that transcoding does not need to be in use to cause the crash.

@Thanassos @Migz93 @dlandon I have submitted a bug report for this

For those who want to follow the bug report or to add their own findings, here is the link.

Yeah, seems to be many people in the same boat with the i915 module on 6.9.x and 6.10 releases. Probably would be a good time to submit a bug report, and it would also be good if the mods and community stop blaming these hangs on hardware issues when the system shows empty logs on intel hardware with the i915 module loaded. All pretty easy touchpoints to pick up on in the diagnostics report.

Which version of unraid did you end up running? Sorry no one reached out to help.

Do you have the i915 module loaded? I am having the same issue with 6.9.x. Only fix is either to unload the i915 module or roll back to 6.8.3. For some the 6.10-RC2 might fix the issue but I haven't tested this personally yet.

Theoretically they are just two methods of loading the module, the only difference is 6.9.x is loaded when a file exists where in 6.10.x it is loaded when the system detects the relevant hardware. I think the main reason for this was to make sure the module was loaded for people booting with a GUI. I think the main difference is the upgrade in kernel potentially. Early 5.x kernels were plagued with intel binary blob issues but this should have been cleared up by the kernel in 6.9.2. Obs not though. I might try an upgrade when I get a free weekend and report back.

6.9.2 Backup file, let me know if you want it shared, but the following should answer your queries. Go is empty, and i do have the touch file. I haven't tried 6.10 but I understand the touch operation is no longer required.

Hmmm, not there yet potentially. @muzo178 still nothing in the syslog from those crashes?

Whatever failed you would hope to see it in the syslog. It's a weird one for sure. Perhaps 6.10 might be a good option for intel iGPU users. I'm going to hold out until the official release is out and all the kinks are worked out. 6.8.3 is working well for the time being with some hacks to community applications to keep the docker updates coming though.

Did you reboot after the touch file? You should not need to make the dev/dri directory. This is created when the module is loaded.

You set their network as the delugevpn container and pipe all the ports for the apps you want passed through by forwarding the ports in deluge contaner config. There are guides out there.

Thanks for the update, hoping RC2 might be an option. Looking forward to future updates.

Sorry I couldn't be of further assistance, hopefully someone more knowledgeable chimes in.

Looking into other cases of rcu_sched self-detected stalls seem to point to cache corruption. I'm looking to see if there is anything specific for BTRFS checks. Other posts have also talked about power supply low power control settings in bios. Other things to check are ram overclocking and disabling some of the low power c states.