Hi there,

I had this problem exactly a week ago and I ended up having to power off by the button and restarting and checking parity.

Thought everything was fine but like I said, it happened again at almost the exact same time whilst doing something similar (browsing in sonarr).

Anyway, same thing happened, couldn't log into the UI, docker image containers would load but incredibly slowly.  I managed to shut one down and then a couple of minutes later all came back as normal.  I have the syslog server on this time and nothing looks too untoward to me but then, I don't really know what I'm looking at

 

This happened about an hour before the crash

Quote

Feb  5 09:10:31 Tower winbindd[13856]: [2024/02/05 09:10:31.161071,  0] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn)
Feb  5 09:10:31 Tower winbindd[13856]:   open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED

 

but the actual crash happened somewhere between these two moments and nothing was logged

 

Quote

Feb  5 10:21:06 Tower kernel: mdcmd (65): set md_write_method 1
Feb  5 10:21:06 Tower kernel:
Feb  5 10:45:51 Tower webGUI: Successful login user root from 192.168.1.3

 

then there's this which looks like it may be relevant?

 

Quote

Feb  5 11:05:25 Tower kernel: <TASK>
Feb  5 11:05:25 Tower kernel: dump_stack_lvl+0x44/0x5c
Feb  5 11:05:25 Tower kernel: dump_header+0x4a/0x211
Feb  5 11:05:25 Tower kernel: oom_kill_process+0x80/0x111
Feb  5 11:05:25 Tower kernel: out_of_memory+0x3b3/0x3e5
Feb  5 11:05:25 Tower kernel: __alloc_pages_slowpath.constprop.0+0x6f5/0x8f8
Feb  5 11:05:25 Tower kernel: __alloc_pages+0x132/0x1e8
Feb  5 11:05:25 Tower kernel: folio_alloc+0x14/0x35
Feb  5 11:05:25 Tower kernel: __filemap_get_folio+0x185/0x213
Feb  5 11:05:25 Tower kernel: ? preempt_latency_start+0x1e/0x46
Feb  5 11:05:25 Tower kernel: filemap_fault+0x317/0x52f
Feb  5 11:05:25 Tower kernel: __do_fault+0x2d/0x6b
Feb  5 11:05:25 Tower kernel: __handle_mm_fault+0xa22/0xcf9
Feb  5 11:05:25 Tower kernel: handle_mm_fault+0x13d/0x20f
Feb  5 11:05:25 Tower kernel: do_user_addr_fault+0x2c3/0x48d
Feb  5 11:05:25 Tower kernel: exc_page_fault+0xfb/0x11d
Feb  5 11:05:25 Tower kernel: asm_exc_page_fault+0x22/0x30
Feb  5 11:05:25 Tower kernel: RIP: 0033:0x1466c5ce7480
Feb  5 11:05:25 Tower kernel: Code: Unable to access opcode bytes at 0x1466c5ce7456.
Feb  5 11:05:25 Tower kernel: RSP: 002b:0000146627d36718 EFLAGS: 00010246
Feb  5 11:05:25 Tower kernel: RAX: 0000000000000890 RBX: 00000000000008a8 RCX: 0000000000000000
Feb  5 11:05:25 Tower kernel: RDX: 0000000000000000 RSI: 00000000000008a8 RDI: 000014662f9a1038
Feb  5 11:05:25 Tower kernel: RBP: 0000146627d36760 R08: 000014662b06b7c0 R09: 0000000000080000
Feb  5 11:05:25 Tower kernel: R10: 000000000000001e R11: 0000000000000206 R12: 0000000000000000
Feb  5 11:05:25 Tower kernel: R13: 000014662f9a1038 R14: 00000000000008a8 R15: 0000000000000000
Feb  5 11:05:25 Tower kernel: </TASK>

 

full syslog and diagnostics attached.

 

Would be great if someone could shed some light on the issue and possibly present a solution?

 

Thanks all.

tower-diagnostics-20240205-1122.zip syslog-192.168.1.200.log

Did you find any solution to this? I have the same problem, I thought it was one of my nvmes as it failed SMART. But after replacing it the same thing happened again just hours later.