I just upgraded to 6.3.1 last night and upon trying to access the GUI today found it unresponsive.  I was able to telnet into the server and take a look at the syslog (below) but couldn't get it to shut down cleanly and had to force restart it.  Looks like a kernel panic - any ideas?  I realize I don't have all the debug information necessary to do a full debug, but figured someone might recognize something here.

 

Feb 12 03:40:01 Tower kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
Feb 12 03:40:01 Tower kernel: IP: [<ffffffff8117c87d>] __discard_prealloc+0x97/0xb1
Feb 12 03:40:01 Tower kernel: PGD 447ccc067
Feb 12 03:40:01 Tower kernel: PUD 447ccb067
Feb 12 03:40:01 Tower kernel: PMD 0
Feb 12 03:40:01 Tower kernel:
Feb 12 03:40:01 Tower kernel: Oops: 0002 [#1] PREEMPT SMP
Feb 12 03:40:01 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod igb ptp pps_core fbcon bitblit ast fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font ttm coretemp drm_kms_helper kvm_intel cfbfillrect cfbimgblt cfbcopyarea kvm drm agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops fb i2c_i801 i2c_smbus mvsas fbdev libsas ahci i2c_algo_bit i2c_core libahci scsi_transport_sas ipmi_si acpi_cpufreq [last unloaded: pps_core]
Feb 12 03:40:01 Tower kernel: CPU: 5 PID: 8016 Comm: shfs Not tainted 4.9.8-unRAID #1
Feb 12 03:40:01 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./C2750D4I, BIOS P2.80 12/04/2014
Feb 12 03:40:01 Tower kernel: task: ffff88046d7f1700 task.stack: ffffc900110a8000
Feb 12 03:40:01 Tower kernel: RIP: 0010:[<ffffffff8117c87d>]  [<ffffffff8117c87d>] __discard_prealloc+0x97/0xb1
Feb 12 03:40:01 Tower kernel: RSP: 0018:ffffc900110abbc8  EFLAGS: 00010246
Feb 12 03:40:01 Tower kernel: RAX: ffff88033c0bab48 RBX: ffff88033c0bab20 RCX: 0000000000000000
Feb 12 03:40:01 Tower kernel: RDX: ffffc900101c51e8 RSI: ffff88033c0bab20 RDI: ffffc900110abce0
Feb 12 03:40:01 Tower kernel: RBP: ffffc900110abbf0 R08: 000000000004ccbb R09: 000000000004ccbb
Feb 12 03:40:01 Tower kernel: R10: ffffc900110abbc8 R11: 00000000ffffffff R12: ffffc900110abce0
Feb 12 03:40:01 Tower kernel: R13: ffff88033c0babc0 R14: 0000000000000000 R15: ffff8804697b9800
Feb 12 03:40:01 Tower kernel: FS:  00002b070aefd700(0000) GS:ffff88047fd40000(0000) knlGS:0000000000000000
Feb 12 03:40:01 Tower kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 12 03:40:01 Tower kernel: CR2: 0000000000000008 CR3: 0000000468946000 CR4: 00000000001006e0
Feb 12 03:40:01 Tower kernel: Stack:
Feb 12 03:40:01 Tower kernel: ffffc900101a5000 ffffc900110abce0 ffffc900101c51e8 ffffc900110abce0
Feb 12 03:40:01 Tower kernel: ffff8804697b9800 ffffc900110abc18 ffffffff8117c8ff ffff88046d7f1700
Feb 12 03:40:01 Tower kernel: ffff8804697b9800 ffffc900101a5000 ffffc900110abcb8 ffffffff81198f3c
Feb 12 03:40:01 Tower kernel: Call Trace:
Feb 12 03:40:01 Tower kernel: [<ffffffff8117c8ff>] reiserfs_discard_all_prealloc+0x48/0x51
Feb 12 03:40:01 Tower kernel: [<ffffffff81198f3c>] do_journal_end+0x3e5/0xc54
Feb 12 03:40:01 Tower kernel: [<ffffffff81199cff>] journal_end+0xad/0xb0
Feb 12 03:40:01 Tower kernel: [<ffffffff8118a478>] reiserfs_dirty_inode+0x6a/0x7a
Feb 12 03:40:01 Tower kernel: [<ffffffff810af64c>] ? from_kuid+0x9/0xb
Feb 12 03:40:01 Tower kernel: [<ffffffff81143021>] __mark_inode_dirty+0x32/0x1e3
Feb 12 03:40:01 Tower kernel: [<ffffffff81186498>] reiserfs_setattr+0x254/0x286
Feb 12 03:40:01 Tower kernel: [<ffffffff81136b13>] ? current_time+0x54/0x5d
Feb 12 03:40:01 Tower kernel: [<ffffffff81138522>] notify_change+0x237/0x376
Feb 12 03:40:01 Tower kernel: [<ffffffff811470f3>] utimes_common+0x114/0x166
Feb 12 03:40:01 Tower kernel: [<ffffffff8112c9ac>] ? getname_flags+0x4f/0x154
Feb 12 03:40:01 Tower kernel: [<ffffffff8112cd1d>] ? user_path_at_empty+0x32/0x38
Feb 12 03:40:01 Tower kernel: [<ffffffff81147233>] do_utimes+0xee/0x120
Feb 12 03:40:01 Tower kernel: [<ffffffff81147352>] SyS_utimensat+0x74/0x83
Feb 12 03:40:01 Tower kernel: [<ffffffff8167d1b7>] entry_SYSCALL_64_fastpath+0x1a/0xa9
Feb 12 03:40:01 Tower kernel: [<ffffffff8167d1b7>] ? entry_SYSCALL_64_fastpath+0x1a/0xa9
Feb 12 03:40:01 Tower kernel: Code: 1c 75 bb 0f 0b 85 c0 74 12 48 8b 93 e8 00 00 00 4c 89 ee 4c 89 e7 e8 42 6f 00 00 48 8b 4b 28 48 8d 43 28 44 89 73 1c 48 8b 53 30 <48> 89 51 08 48 89 0a 48 89 43 28 48 89 43 30 5b 41 5c 41 5d 41
Feb 12 03:40:01 Tower kernel: RIP  [<ffffffff8117c87d>] __discard_prealloc+0x97/0xb1
Feb 12 03:40:01 Tower kernel: RSP <ffffc900110abbc8>
Feb 12 03:40:01 Tower kernel: CR2: 0000000000000008
Feb 12 03:40:01 Tower kernel: ---[ end trace 14f13a623de27424 ]---

If you don't get a response with some other ideas, I would suggest that if it happens again that you type the command  diagnostics  on the command line.  That will write the diagnostic file on the flash drive (either in the root or logs folder).  You can then post that file up to this thread.

A kernel oops is like a kernel panic but not quite as bad - a panic is always fatal, while after an oops it can usually continue though the system will be unreliable so even if it had remained responsive you would need to reboot. My advice is the usual: check memory, look for a BIOS update, wait for a new kernel or roll back if you have to.

Also, because reiserfs is mentioned in the Call Trace, use Check Disk File systems to check all of your data drives that are formatted with ReiserFS.  Hopefully, you won't find any problems!  But if you do, fix them right there, with whatever instruction it gives you.

 

I should add 'Oops' and 'BUG' to my panic post!

Thanks for the tips folks.  Will run reiserfsck and hopefully it comes back clean.  No issues since that once, so maybe it's a one-time event.  Maybe.