Tristankin

Yep, the change in directory fixed it. Not sure what is causing it but changing appdata to cache ONLY and moving the config directory to cache fixed it. 12 Day uptime so far.

/dev/shm

I have just changed it. I don't think anything was moved as I was in prefer mode. All good so far but thank you for the heads up. I guess I will have to be more proactive with backing up appdata too. But if it makes the system stable I am happy.

OK, so I didn't end up changing the container but I did check out the discussion on said container. I found a discussion about changing the appdata directory from /mnt/user to /mnt/cache. @muzo178 Could you try this too to see if it makes a difference with your container? So far I have had almost 4 days uptime. It's either the above or turning off VT-d.

I'm using binhex/plex, I doubt it is very different though.

Yep, 100% rock solid. 4.x kernel has 0 issues.

I have already changed over to ipvlan as part of the upgrade.

But I would need to turn off plex to isolate it correct? It happens randomly so I would need to turn off my plex service for a few days to test correct? Ok, so need to keep the monitor plugged in and turned on till it crashes.

I did post my diagnostics but here they are again. Yeah, syslog doesn't catch anything. So if i issue that commend it will prevent sleep and show the last error on the screen so when I swap out the dummy plug for the monitor again I can grab a screenshot? I have about 50 users on my plex so I can't see a good way of switching over to jellyfin, that would be a last resort option. firefly-diagnostics-20230127-1210.zip

I changed to UEFI this time around too, previous attempts in 6.9 and 6.10 were in bios mode. I have isolated the the dockers to just be the plex one as it is the only one using the igpu. If hardware transcoding is turned off then the system is fine. If everything else is turned off except for plex with hw transcodes it fails. There are no VMs on the machine, only docker containers. I have reset the bios multiple times and upgraded it with the upgrade to 6.11 It is specifically the i915 in the 5.x kernel causing the freezes from what I can tell, but there is nothing out of the ordinary with my setup. As I mentioned, 100% flawless on 6.8.3

Well that is great for you but you understand it really doesn't help me out. Anything different you can see from your config to mine? I have had years of stable operation with 6.8.3. Anything with the 5.x kernel freezes. Do you have VT-d enabled on your system? I am not the only one experiencing this problem so there is something causing an issue and after trying to find a solution for over a year I am still no closer. You can understand that is pretty frustrating right?

Another one today. I have turned off VT-d to see if that makes any difference. Jan 27 13:04:31 Firefly kernel: md: sync done. time=62729sec Jan 27 13:04:31 Firefly kernel: md: recovery thread: exit status: 0 Jan 27 15:04:33 Firefly emhttpd: spinning down /dev/sdj Jan 27 15:04:33 Firefly emhttpd: spinning down /dev/sdg Jan 27 15:04:33 Firefly emhttpd: spinning down /dev/sde Jan 27 15:11:10 Firefly emhttpd: spinning down /dev/sdh Jan 27 15:11:10 Firefly emhttpd: spinning down /dev/sdc Jan 27 15:36:15 Firefly emhttpd: read SMART /dev/sdg Jan 27 15:56:21 Firefly emhttpd: spinning down /dev/sdb Jan 27 16:06:22 Firefly emhttpd: read SMART /dev/sdh Jan 27 16:06:22 Firefly emhttpd: read SMART /dev/sdc Jan 27 16:56:01 Firefly emhttpd: read SMART /dev/sde Jan 27 18:02:34 Firefly emhttpd: read SMART /dev/sdb Jan 27 18:08:04 Firefly emhttpd: spinning down /dev/sdh Jan 27 18:08:04 Firefly emhttpd: spinning down /dev/sdc Jan 27 21:06:15 Firefly kernel: microcode: microcode updated early to revision 0xf0, date = 2021-11-12 Jan 27 21:06:15 Firefly kernel: Linux version 5.19.17-Unraid (root@Develop) (gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #2 SMP PREEMPT_DYNAMIC Wed Nov 2 11:54:15 PDT 2022 Jan 27 21:06:15 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot

So I gave 6.11.5 a go. Still getting hangs. I removed everything from the go file, installed intel-gpu-top, changed over from macvlan to ip. I upgraded the bios to the latest version, turned off all C states, unplugged hdmi kvm switcher and replaced with a dummy hdmi plug. I have been on 6.8.3 for months without a single freeze but as soon as I change over to 5.x kernel versions the freezes still occur. Jan 26 01:10:19 Firefly rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="14592" x-info="https://www.rsyslog.com"] start Jan 26 08:44:23 Firefly crond[1056]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Jan 26 18:32:38 Firefly kernel: md: sync done. time=63099sec Jan 26 18:32:38 Firefly kernel: md: recovery thread: exit status: 0 Jan 26 19:38:33 Firefly kernel: microcode: microcode updated early to revision 0xf0, date = 2021-11-12 Jan 26 19:38:33 Firefly kernel: Linux version 5.19.17-Unraid (root@Develop) (gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #2 SMP PREEMPT_DYNAMIC Wed Nov 2 11:54:15 PDT 2022 Still happening every 2-5 days. No consistency to when it is happening. I did notice these but I assume they are just dodgy files. Did not cause a freeze. Everything else looks fine. Jan 13 21:14:09 Firefly kernel: Plex Transcoder[21796]: segfault at 18 ip 0000154d3caea3ca sp 00007ffe25bf21d0 error 4 in libavcodec.so.59[154d3c782000+3d8000] Jan 13 21:14:09 Firefly kernel: Code: 4c 89 eb 0f 84 dc 00 00 00 c7 83 1c 07 00 00 01 00 00 00 48 8b 83 d0 01 00 00 48 3b 83 e8 01 00 00 7d 19 48 8b 83 c0 01 00 00 <48> 8b 40 18 48 2b 83 f8 01 00 00 48 89 83 00 02 00 00 49 83 bd b8 Jan 13 21:14:59 Firefly kernel: Plex Transcoder[23296]: segfault at 18 ip 000014fa1a6ea3ca sp 00007ffd66073280 error 4 in libavcodec.so.59[14fa1a382000+3d8000] Jan 13 21:14:59 Firefly kernel: Code: 4c 89 eb 0f 84 dc 00 00 00 c7 83 1c 07 00 00 01 00 00 00 48 8b 83 d0 01 00 00 48 3b 83 e8 01 00 00 7d 19 48 8b 83 c0 01 00 00 <48> 8b 40 18 48 2b 83 f8 01 00 00 48 89 83 00 02 00 00 49 83 bd b8 Diagnostics attached. But I assume that rolling back to 6.8.3 is going to be the solution for now. firefly-diagnostics-20230127-1210.zip

Let us know how you fare.

Ah yeah OK, the previews. Did not think of that. 5.x kernel intel drivers have been known to be a bit shit, and also I have heard reports that the dummy plug has been more important since the 5.x releases (somewhere in this thread from memory) The bit that also is making it all very hard to identify is that there is never anything logged in syslog. Which makes the failure appear as a hardware one, but I am pretty darn sure it is an unlogged gpu fault.

Myself and other users have noted that the crashes stop occurring when the i915 module is blacklisted.

Hard keeping up with all the questions coming from edits. The reboots are random and would often happen overnight with no transcoding. 2100 has been tried since then for testing. I have VLANS turned off so that should not be the issue? I will also have to do the upgrade again as I am still on 6.8.3. But I couldn't put up with a year of testing till now with constant freezes.

Corsair Vengeance LPX 16GB (2x8GB) 2400MHz CL16 DDR4 (running at 2100MT/s from memory) I was running on an undervolt on 6.8.3 then reset the bios after i was getting restarts on 6.9.x so I doubt that is the issue. (back to standard voltages) I had 6 months without freezes before the upgrade to 6.9.x and have had 6 months without freezers since the downgrade to 6.8.3 I will check the details about BAR and make sure the bios is up to date. It is currently 8°C and midnight here in Australia and I would need to crawl under the house.

I wish the alderlakers would make their own damn threads too. No this is instability with the i915 driver as reported by various members in this particular thread. All currently "supported" by the used kernel. (just look back through the thread) I am using a i3-9100. I took out the modifications in the go file in the upgrade. No undervolting, no tuning. Honestly all of this is covered in the thread attached to the initial bug report so I feel I am having to once again repeat myself. I was encouraged to make a bug report by the mods after complaining enough in the general forum for months and getting no help. Consensus was eventually that the intel iGPU drivers in the kernel are flakey. I have been trying to find a solution since 12 March 2021

Sure, I have been reporting this issue for 6 months but now you want to know about my system setup? Using the HDMI dummy plug, what do you want to know about my BIOS? Binhex-Plex. Doesn't need to be transcoding though, as the initial report..... Why do I have 0 resets on 6.8.3 but multiple freezes a week on 6.9.x+

This is the problem that I initially brought up this bug report for. I have an 9th gen cpu with a system stuck on 6.8.3 because its the last 4.x kernel and therefore the last time the i915 driver was stable. Looking forward to the next release candidate so I can finally upgrade my system.

RC3 should have some improvements. Can users please report their experiences with 6.10-RC3 here?

is i915 more stable in this release?

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.

Yep, can confirm 9th gen, i3 9100. No go with all 6.9.x and 6.10-RC