The server boots up and goes down a few minutes later with these screenshots form the console. I couldn't find anything searching. Is anyone familiar with this?

Enable the syslog server and post that after a crash together with fresh diagnostics.

@JorgeB

 

Attaching the ZIP file 

 

Crash started on - Jan 21 22:05:25 

 

I can see the kernal stuff being logged around Jan 21 22:05:50

 

Edit: Also posting the syslog 

tower-diagnostics-20250122-1323.zip

Syslog.txt

Edited January 22, 20251 yr by Vulpita

There are many call traces before that, they appear to be related to Plex and/or the iGPU, does it crash without using Plex?

The crashes only started happening in a middle of a plex stream or when a plex stream was about to start. What part of the logs did you look at to determine this? I'd like to be able to troubleshoot better 

 

This also happened a bit in December 20th, as you can see in the syslog.txt the same type of kernel messages 

Edited January 22, 20251 yr by Vulpita

From the 20th, the first call trace, which is typically the most important one, mentions Plex:

 

Dec 20 06:41:14 Tower kernel: BUG: Bad page map in process Plex Transcoder  pte:000000ff pmd:1059e9067

 

The there are constant call traces after that for some time, and some mention the iGPU, e.g.:

 

Dec 20 06:41:22 Tower kernel: general protection fault, maybe for address 0xffffea000d1ee1e8: 0000 [#1] PREEMPT SMP PTI
Dec 20 06:41:22 Tower kernel: CPU: 2 PID: 19452 Comm: Plex Transcoder Tainted: P    B      O       6.1.118-Unraid #1
Dec 20 06:41:22 Tower kernel: Hardware name: System manufacturer System Product Name/Z170 PRO GAMING, BIOS 3805 05/16/2018
Dec 20 06:41:22 Tower kernel: RIP: 0010:__cmpxchg_double_slab.constprop.0.isra.0+0x28/0x71
Dec 20 06:41:22 Tower kernel: Code: cc cc 89 f8 41 55 48 89 f7 4d 89 cd 0f ba e0 1e 41 54 49 89 d4 55 48 89 cd 53 4c 89 c3 41 52 73 13 48 89 d0 48 89 ca 4c 89 c9 <f0> 48 0f c7 4e 20 75 31 eb 26 48 89 34 24 e8 55 fd ff ff 48 8b 3c
Dec 20 06:41:22 Tower kernel: RSP: 0018:ffffc90020ba3810 EFLAGS: 00010087
Dec 20 06:41:22 Tower kernel: RAX: 0000000080200013 RBX: 0000000000000000 RCX: 00000001ffff7fff
Dec 20 06:41:22 Tower kernel: RDX: 00000001ffffffff RSI: ffffea000d1ee1c8 RDI: ffffea000d1ee1c8
Dec 20 06:41:22 Tower kernel: RBP: 00000001ffffffff R08: 0000000000000000 R09: 00000001ffff7fff
Dec 20 06:41:22 Tower kernel: R10: ffff88819426ca00 R11: 0000000000002000 R12: 0000000080200013
Dec 20 06:41:22 Tower kernel: R13: 00000001ffff7fff R14: 00000000ffffffff R15: 0000000000000202
Dec 20 06:41:22 Tower kernel: FS:  000014658e7c0808(0000) GS:ffff888a0ed00000(0000) knlGS:0000000000000000
Dec 20 06:41:22 Tower kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 20 06:41:22 Tower kernel: CR2: 000014657a48aff0 CR3: 000000016e44e004 CR4: 00000000003706e0
Dec 20 06:41:22 Tower kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec 20 06:41:22 Tower kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Dec 20 06:41:22 Tower kernel: Call Trace:
Dec 20 06:41:22 Tower kernel: <TASK>
Dec 20 06:41:22 Tower kernel: ? __die_body+0x1a/0x5c
Dec 20 06:41:22 Tower kernel: ? die_addr+0x38/0x51
Dec 20 06:41:22 Tower kernel: ? exc_general_protection+0x30f/0x345
Dec 20 06:41:22 Tower kernel: ? asm_exc_general_protection+0x22/0x30
Dec 20 06:41:22 Tower kernel: ? __cmpxchg_double_slab.constprop.0.isra.0+0x28/0x71
Dec 20 06:41:22 Tower kernel: ___slab_alloc+0xc4/0x6fe
Dec 20 06:41:22 Tower kernel: ? i915_sched_node_add_dependency+0x25/0x6b [i915]
Dec 20 06:41:22 Tower kernel: ? __mod_timer+0x207/0x232
Dec 20 06:41:22 Tower kernel: ? slab_free_freelist_hook.constprop.0+0x3b/0xaf
Dec 20 06:41:22 Tower kernel: ? i915_sched_node_add_dependency+0x25/0x6b [i915]
Dec 20 06:41:22 Tower kernel: __slab_alloc.constprop.0+0x5a/0x85
Dec 20 06:41:22 Tower kernel: ? i915_sched_node_add_dependency+0x25/0x6b [i915]
Dec 20 06:41:22 Tower kernel: kmem_cache_alloc+0x97/0x14d
Dec 20 06:41:22 Tower kernel: i915_sched_node_add_dependency+0x25/0x6b [i915]
Dec 20 06:41:22 Tower kernel: i915_request_await_dma_fence+0x104/0x249 [i915]
Dec 20 06:41:22 Tower kernel: i915_request_await_object+0x4e/0x7b [i915]
Dec 20 06:41:22 Tower kernel: i915_gem_do_execbuffer+0x1430/0x1aff [i915]
Dec 20 06:41:22 Tower kernel: ? memcg_rstat_updated+0x23/0x77
Dec 20 06:41:22 Tower kernel: ? __slab_free+0x83/0x229
Dec 20 06:41:22 Tower kernel: ? post_alloc_hook+0x13/0x5f
Dec 20 06:41:22 Tower kernel: ? kernel_init_pages+0x38/0x46
Dec 20 06:41:22 Tower kernel: ? prep_new_page+0x1c/0x4c
Dec 20 06:41:22 Tower kernel: ? get_page_from_freelist+0x78b/0x8da
Dec 20 06:41:22 Tower kernel: ? slab_free_freelist_hook.constprop.0+0x3b/0xaf
Dec 20 06:41:22 Tower kernel: ? slab_post_alloc_hook+0x4d/0x15e
Dec 20 06:41:22 Tower kernel: ? kvmalloc_node+0x44/0xbc
Dec 20 06:41:22 Tower kernel: i915_gem_execbuffer2_ioctl+0x174/0x1f5 [i915]
Dec 20 06:41:22 Tower kernel: ? i915_gem_do_execbuffer+0x1aff/0x1aff [i915]
Dec 20 06:41:22 Tower kernel: drm_ioctl_kernel+0xe3/0x13f [drm]
Dec 20 06:41:22 Tower kernel: ? _raw_spin_unlock+0x14/0x29
Dec 20 06:41:22 Tower kernel: drm_ioctl+0x266/0x36f [drm]
Dec 20 06:41:22 Tower kernel: ? i915_gem_do_execbuffer+0x1aff/0x1aff [i915]
Dec 20 06:41:22 Tower kernel: vfs_ioctl+0x1b/0x2f
Dec 20 06:41:22 Tower kernel: __do_sys_ioctl+0x52/0x78
Dec 20 06:41:22 Tower kernel: do_syscall_64+0x65/0x7b
Dec 20 06:41:22 Tower kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8

 

thanks for that information. So it looks like it crashed again around 1/23/2025 15:20 ish, I dont think anyone was using plex. I'm looking through he logs but I can't see any trace calls like before. The attached syslog also doesn't show anything. Can I turn on more verbose logging somewhere?

 

Attaching a fresh diag

 

 

syslog.log tower-diagnostics-20250123-1816.zip

1 hour ago, Vulpita said:

Can I turn on more verbose logging somewhere?

Nope, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the docker containers. 

So I did a memtest for the sake of it and one of the sticks failed. I removed it and ran the memtest again on just 32gb and it passed. Do you think that could possibly cause that? Would there be any error logging on unraid that would suggest bad ram

It could be for sure, with bad RAM there can be some clues sometimes logged, but nothing other times.

Ok thanks a lot Jorge. I will update this thread if anymore crashes occur. Thanks for all the help so far