DavejaVu

Very interesting. I have a Supermicro X11SSH-TF with Xeon E3-1275v6, and when I try to upgrade from 6.10.3 (which is rock solid) to 6.11.5 it locks up hard almost immediately as well, if it even makes it through boot. I've had issues where the system locks up hard when I try to use the iGPU to transcode, so I've stopped doing that until some magic version appears where it works, but the system is stable with 6.10.3 otherwise. I may have to try disabling it in BIOS as well. Not ideal. but may be the only way to run 6.11.x+ unless someone sorts it out.

I'm having a similar issue with QuickSync locking the system up hard. This is on a Supermicro X11SSH-TF with E3-1275v6, 16GB of memory. I've had it happen with Plex, Handbrake, and, lately, I've been using Tdarr, all of which can trigger the issue seemingly at random. I thought it might be a thermal issue, but after putting a giant CPU cooler on, it hasn't seemed to resolve the issue. Doesn't look like anything gets written to syslog, so I've had to do a hard boot via IPMI. Would love to be resolve this so I can use transcoding consistently. It can work for relatively long periods, or fail a couple of files in. Is 16GB not enough memory maybe?

I'm using an E3-1275v6 with P630 in a Handbrake docker doing QuickSync-based h.265 conversions and it seems to be working fine. I had been using it for Plex as well but there was something that would happen where the box would lock up randomly when using both so I disabled it for Plex for now. May have been a thermal issue, and I've upgraded cooling since as well. Not sure if that helps, but it's another data point.

In the 'Create VM' screen, the P630 shows up under 'Graphics Card' as 'Intel HD Graphics P630 (00:02.0) and I can start up a VM using that, but that removes VNC as an option and I'm not seeing anything through the physical port, so I'm not sure how to actually attach to the VM to do an install, or to even see if it's working. Bit of a chicken and egg problem.

I have what may be a very stupid question, but I recently upgraded my Unraid system to a Xeon E3-1275v6 (on a Supermicro X11SSH-TF), and was wondering if I might be able to put the integrated P630 GPU into use for doing some encoding/transcoding work? It seems like the VM creation screen shows the P630 as a potential graphics card, and I'm able to start the VM but...how do I see the output from it? Tried connecting a monitor to the server and that's just showing the typical console, so I'm at a bit of a loss as to if this is even possible. Any pointers are appreciated. Thanks!

There's a new project I stumbled across on reddit called Liquid-dl that looks promising: https://github.com/Kthulu120/liquid_dl Options are still pretty basic, but it looks like it could become a very useful tool and they already have an unraid-friendly version. Not sure if it's what you're looking for, but may be worth looking at how the container was created?

As long as Apache can read/serve the directory the files are in, you should be good to go. Just make sure it's using HTTPS and it requires authentication. No need to get fancy with a real cert unless you really want to. Yeah, I know IDM on Windows kinda defeats the purpose of Unraid-based dockerized apps, but after trying a LOT of download managers and FTP clients to deal with European peering, IDM outperforms everything else I've tried. It's a dedicated server I'm hitting, so I run 32 threads against it and get pretty decent throughput without worrying about causing issues for the neighbors. If your box is a shared one, may want to be a little more kind. Can't really help you with the lack of a GUI for lftp, though it wouldn't be terribly hard to write a basic one I would think. Personally, I don't mind CLI-based tools but I'm old and used to suffering. One other thing, speaking of peering...you may want to try some other providers to see if you can get better peering. I've been through a few different shared and dedicated providers in NL, FR, and DE, and they definitely have different speeds to me. Time of day seems to make a difference as well.

lftp works pretty well once you tune the config file, but as you mentioned, it's command-line only. I just use a screen instance and let a mirror command run in the background overnight. It doesn't saturate my connection but it's reasonable. One thing I've had really good luck with from my seedbox is transferring files via HTTPS and a segmented downloader like Internet Download Manager. For whatever reason I get much higher throughput that way vs (S)FTP(S). May want to give it a shot. Another possibility that may help is to route traffic through CloudFlare's CDN, which a lot of people do to make their Plex streaming more solid. May or may not help for regular file transfers though.

I finished converting 14 disks from Reiser to XFS about 5 days ago and things seem stable since. I realize this isn't that interesting of a data point because it's not a long time, but that's the longest uptime I've had since upgrading to 6.3.x. And, agreed, I did everything via rsync so it's entirely possible that the act of recreating everything in a new dir structure cleaned up something. Still, it seems that ReiserFS is a quasi-supported relic at this point, so moving off of it seems to be advised. While the rsync method works well, it's a bit tedious...would be nice to have a more automated method for those of us who have been upgrading our systems over the years.

No reiser messages in syslog after the initial boot stuff some days ago. But, your question adds to my suspicion that I need to go down to path of migrating to XFS rather soon. I did a reiserfsck on all the disks after a recent kernel oops (another thread) that came back clean. Looks like the system decided for me. While troubleshooting I did a 'lsof' that hung, and I wasn't able to log back in from either telnet or console, so I've reset and it's now checking that dirty, dirty filesystem. So much for that I guess. Still would like to understand why shfs decided to go crazy.

Appreciate the quick response. I issued a 'poweroff' that has been sitting in a window untouched (unbanged?) for 5 minutes now that isn't doing anything. Server doesn't want to die apparently. Any other ideas? Just another (minor) data point: even though the primary GUI is unresponsive, I have a half dozen containers that are all responding like nothing is happening.

Also - any suggestions on how to cleanly reboot at this point? Nothing seems to do anything: poweroff, powerdown, shutdown, reboot just give syslog messages: Feb 16 16:21:24 Tower shutdown[31150]: shutting down for system halt Feb 16 16:22:04 Tower in.telnetd[31777]: connect from 192.168.1.10 (192.168.1.10) Feb 16 16:22:10 Tower login[31779]: ROOT LOGIN on '/dev/pts/0' from '192.168.1.10' Feb 16 16:22:15 Tower shutdown[31948]: shutting down for system halt Feb 16 16:22:31 Tower in.telnetd[32156]: connect from 192.168.1.10 (192.168.1.10) Feb 16 16:22:35 Tower login[32158]: ROOT LOGIN on '/dev/pts/1' from '192.168.1.10' Feb 16 16:22:38 Tower root: /usr/local/sbin/powerdown has been deprecated Feb 16 16:22:38 Tower shutdown[32240]: shutting down for system halt Feb 16 16:23:36 Tower in.telnetd[659]: connect from 192.168.1.10 (192.168.1.10) Feb 16 16:23:39 Tower login[660]: ROOT LOGIN on '/dev/pts/4' from '192.168.1.10' Feb 16 16:23:49 Tower root: /usr/local/sbin/powerdown has been deprecated Feb 16 16:23:49 Tower shutdown[946]: shutting down for system reboot Feb 16 16:24:42 Tower in.telnetd[1878]: connect from 192.168.1.10 (192.168.1.10) Feb 16 16:24:46 Tower login[1879]: ROOT LOGIN on '/dev/pts/5' from '192.168.1.10' Feb 16 16:24:47 Tower shutdown[1947]: shutting down for system reboot Unless someone has an idea on how to deal with this, I'll have to go in via IPMI and reset the server, which I'm sure will mean a nice day-long parity check. Starting to regret this upgrade...

I'm seeing the same thing, no cache_dirs plugin here, and yes there are ReiserFS shares. Seemed to happen when I tried to delete a bunch of files, but that may be coincidental. top - 16:15:19 up 4 days, 2:11, 1 user, load average: 7.02, 7.16, 7.17 Tasks: 420 total, 2 running, 417 sleeping, 0 stopped, 1 zombie %Cpu(s): 0.5 us, 13.3 sy, 0.0 ni, 86.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16410152 total, 921220 free, 1721092 used, 13767840 buff/cache KiB Swap: 0 total, 0 free, 0 used. 13508808 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6464 root 20 0 1031988 7600 744 S 99.7 0.0 150:20.69 shfs Nothing interesting in syslog, GUI unresponsive: Feb 16 01:20:32 Tower kernel: mdcmd (151): spindown 6 Feb 16 01:20:33 Tower kernel: mdcmd (152): spindown 7 Feb 16 01:20:34 Tower kernel: mdcmd (153): spindown 8 Feb 16 01:20:34 Tower kernel: mdcmd (154): spindown 9 Feb 16 01:20:35 Tower kernel: mdcmd (155): spindown 10 Feb 16 01:20:41 Tower kernel: mdcmd (156): spindown 11 Feb 16 03:30:28 Tower kernel: mdcmd (157): spindown 3 Feb 16 03:30:57 Tower kernel: mdcmd (158): spindown 4 Feb 16 03:31:05 Tower kernel: mdcmd (159): spindown 11 Feb 16 03:31:08 Tower kernel: mdcmd (160): spindown 0 Feb 16 03:31:08 Tower kernel: mdcmd (161): spindown 2 Feb 16 03:31:08 Tower kernel: mdcmd (162): spindown 6 Feb 16 03:31:09 Tower kernel: mdcmd (163): spindown 7 Feb 16 03:31:10 Tower kernel: mdcmd (164): spindown 8 Feb 16 03:31:10 Tower kernel: mdcmd (165): spindown 9 Feb 16 03:31:11 Tower kernel: mdcmd (166): spindown 10 Feb 16 03:31:13 Tower kernel: mdcmd (167): spindown 1 Feb 16 03:31:14 Tower kernel: mdcmd (168): spindown 5 Feb 16 10:42:14 Tower in.telnetd[7649]: connect from 192.168.1.10 (192.168.1.10) Feb 16 10:42:21 Tower login[7650]: ROOT LOGIN on '/dev/pts/0' from '192.168.1.10' Feb 16 11:49:40 Tower kernel: mdcmd (169): spindown 1 Feb 16 11:49:41 Tower kernel: mdcmd (170): spindown 5 Feb 16 12:16:15 Tower kernel: mdcmd (171): spindown 4 Feb 16 12:16:15 Tower kernel: mdcmd (172): spindown 6 Feb 16 12:16:16 Tower kernel: mdcmd (173): spindown 7 Feb 16 12:16:17 Tower kernel: mdcmd (174): spindown 8 Feb 16 12:16:17 Tower kernel: mdcmd (175): spindown 9 Feb 16 12:16:18 Tower kernel: mdcmd (176): spindown 10 Feb 16 12:16:18 Tower kernel: mdcmd (177): spindown 11 Feb 16 13:18:43 Tower kernel: mdcmd (178): spindown 1 Feb 16 13:18:44 Tower kernel: mdcmd (179): spindown 5 Feb 16 14:11:27 Tower in.telnetd[27488]: connect from 192.168.1.10 (192.168.1.10) Feb 16 14:11:31 Tower login[27489]: ROOT LOGIN on '/dev/pts/3' from '192.168.1.10'

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.

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 ]---

Ah, I didn't notice the component difference there...probably should have diffed it against the original. Good advice on the BIOS...let me try that and if it keeps occurring I'll start a new thread with fill diags. Thanks.

I seem to be seeing the same thing in 6.2.4 where upon every reboot, I see: Dec 12 19:16:18 Tower kernel: ------------[ cut here ]------------ Dec 12 19:16:18 Tower kernel: WARNING: CPU: 7 PID: 2135 at ./arch/x86/include/asm/thread_info.h:236 SyS_rt_sigsuspend+0x8f/0x9e() Dec 12 19:16:18 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 fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font ast drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea ttm drm coretemp kvm_intel agpgart syscopyarea sysfillrect sysimgblt kvm fb_sys_fops mvsas fb i2c_i801 fbdev i2c_algo_bit libsas ahci i2c_core libahci scsi_transport_sas ipmi_si acpi_cpufreq [last unloaded: pps_core] Dec 12 19:16:18 Tower kernel: CPU: 7 PID: 2135 Comm: Threadpool work Not tainted 4.4.30-unRAID #2 Dec 12 19:16:18 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 Dec 12 19:16:18 Tower kernel: 0000000000000000 ffff88044ba0fee0 ffffffff8136f79f 0000000000000000 Dec 12 19:16:18 Tower kernel: 00000000000000ec ffff88044ba0ff18 ffffffff8104a4ab ffffffff8105569b Dec 12 19:16:18 Tower kernel: fffffffffffffdfe 000000000000d266 000000000000000d 000000000000a0c4 Dec 12 19:16:18 Tower kernel: Call Trace: Dec 12 19:16:18 Tower kernel: [<ffffffff8136f79f>] dump_stack+0x61/0x7e Dec 12 19:16:18 Tower kernel: [<ffffffff8104a4ab>] warn_slowpath_common+0x8f/0xa8 Dec 12 19:16:18 Tower kernel: [<ffffffff8105569b>] ? SyS_rt_sigsuspend+0x8f/0x9e Dec 12 19:16:18 Tower kernel: [<ffffffff8104a568>] warn_slowpath_null+0x15/0x17 Dec 12 19:16:18 Tower kernel: [<ffffffff8105569b>] SyS_rt_sigsuspend+0x8f/0x9e Dec 12 19:16:18 Tower kernel: [<ffffffff81629c2e>] entry_SYSCALL_64_fastpath+0x12/0x6d Dec 12 19:16:18 Tower kernel: ---[ end trace 36a511110db2574a ]--- Things seem to be working okay, but it's always concerning to see something like that in the syslog. Any ideas? I can provide a full log if it will be of assistance.

Fair enough, and thanks very much for the information. The tree rebuild seems to have gone through with nothing in lost+found, so it seems like I may have escaped anything nasty. Still poking around but haven't seen anything corrupted yet. Whew.

I ran through a 'reiserfsck --check' on all disks and /dev/md10 came back with corruption issues. Smart report looks fine on the disk, so I'm letting a 'reisersck --rebuild-tree' run overnight as suggested by the output of the check function. This would have been a candidate disk for the mover to place things on in this case, so that very well could have been the issue. Now I'm just hoping the recovery works with little loss. Any ideas how this might have happened? First time I've seen it after years of use, but it makes me a little concerned because it's not something parity can correct.

I have an ASrock C2750D4I server running 6.1.8 that seems to have encountered a fault at 3:40am, when the mover started up. The GUI and CLI are still accessible, but I'm hitting errors accessing the array via SMB, and when I go to the GUI to shutdown the array, I can't because it says that 'Mover is running'. This happened about a week ago as well and I had to do a restart of the server via IPMI, which led to a dirty shutdown and parity check. Anyone else seen this happen or have an idea what to check? I'll go down the path of upgrading BIOS/unRaid/etc shortly but is there a way I can terminate the mover and have the array cleanly shutdown? Relevant snippet from syslog below. I don't see anything obvious otherwise, but can provide more if needed. Apr 8 03:40:01 Tower kernel: general protection fault: 0000 [#1] PREEMPT SMP Apr 8 03:40:01 Tower kernel: Modules linked in: cdc_acm xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables kvm_intel kvm vhost_net vhost macvtap macvlan tun 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 i2c_algo_bit i2c_i801 ptp pps_core ahci libahci mvsas libsas scsi_transport_sas ipmi_si acpi_cpufreq Apr 8 03:40:01 Tower kernel: CPU: 1 PID: 2272 Comm: shfs Not tainted 4.1.17-unRAID #1 Apr 8 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 Apr 8 03:40:01 Tower kernel: task: ffff8804694a90c0 ti: ffff880453518000 task.ti: ffff880453518000 Apr 8 03:40:01 Tower kernel: RIP: 0010:[<ffffffff81153948>] [<ffffffff81153948>] __discard_prealloc+0x98/0xb3 Apr 8 03:40:01 Tower kernel: RSP: 0018:ffff88045351bb68 EFLAGS: 00010246 Apr 8 03:40:01 Tower kernel: RAX: ffff88011699f9e8 RBX: ffff88011699f9c0 RCX: bd64cb7ef318fc19 Apr 8 03:40:01 Tower kernel: RDX: f52578f4ad8d3960 RSI: ffff88011699f9c0 RDI: ffff88045351bcb0 Apr 8 03:40:01 Tower kernel: RBP: ffff88045351bb98 R08: 00000000000005da R09: 0000000000012548 Apr 8 03:40:01 Tower kernel: R10: 00000000ffffffff R11: ffff880463739d20 R12: ffff88045351bcb0 Apr 8 03:40:01 Tower kernel: R13: ffff88011699fa60 R14: ffff88045351bcb0 R15: 0000000033c6363c Apr 8 03:40:01 Tower kernel: FS: 00002b39177af700(0000) GS:ffff88047fc40000(0000) knlGS:0000000000000000 Apr 8 03:40:01 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 8 03:40:01 Tower kernel: CR2: 00002ab0ad452000 CR3: 0000000455cde000 CR4: 00000000001006e0 Apr 8 03:40:01 Tower kernel: Stack: Apr 8 03:40:01 Tower kernel: ffff880463739c00 ffff88045351bcb0 ffffc900034b1000 ffffc900034d11e8 Apr 8 03:40:01 Tower kernel: ffff88045351bcb0 ffff8800761f5000 ffff88045351bbc8 ffffffff811539c7 Apr 8 03:40:01 Tower kernel: ffff88045351bcb0 ffff8804694a90c0 ffffc900034b1000 ffffc900034b1000 Apr 8 03:40:01 Tower kernel: Call Trace: Apr 8 03:40:01 Tower kernel: [<ffffffff811539c7>] reiserfs_discard_all_prealloc+0x44/0x4e Apr 8 03:40:01 Tower kernel: [<ffffffff81170240>] do_journal_end+0x4e7/0xc78 Apr 8 03:40:01 Tower kernel: [<ffffffff81170f30>] journal_end+0xae/0xb6 Apr 8 03:40:01 Tower kernel: [<ffffffff8116161e>] reiserfs_dirty_inode+0x6c/0x7c Apr 8 03:40:01 Tower kernel: [<ffffffff8104d340>] ? ns_capable+0x3a/0x4f Apr 8 03:40:01 Tower kernel: [<ffffffff8111ce45>] __mark_inode_dirty+0x2f/0x265 Apr 8 03:40:01 Tower kernel: [<ffffffff8115d373>] reiserfs_setattr+0x262/0x297 Apr 8 03:40:01 Tower kernel: [<ffffffff810ff608>] ? __sb_start_write+0x9a/0xce Apr 8 03:40:01 Tower kernel: [<ffffffff811099f2>] ? putname+0x46/0x4b Apr 8 03:40:01 Tower kernel: [<ffffffff8111399a>] notify_change+0x1db/0x2dc Apr 8 03:40:01 Tower kernel: [<ffffffff811167f8>] ? __mnt_want_write+0x4a/0x61 Apr 8 03:40:01 Tower kernel: [<ffffffff81121010>] utimes_common+0x114/0x18b Apr 8 03:40:01 Tower kernel: [<ffffffff81121172>] do_utimes+0xeb/0x125 Apr 8 03:40:01 Tower kernel: [<ffffffff811212fb>] SyS_futimesat+0x7f/0x9a Apr 8 03:40:01 Tower kernel: [<ffffffff8112132a>] SyS_utimes+0x14/0x16 Apr 8 03:40:01 Tower kernel: [<ffffffff815f74ee>] system_call_fastpath+0x12/0x71 Apr 8 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 be 6e 00 00 48 8b 4b 28 44 89 7b 1c 48 8d 43 28 48 8b 53 30 <48> 89 51 08 48 89 0a 48 89 43 28 48 89 43 30 58 5b 41 5c 41 5d Apr 8 03:40:01 Tower kernel: RIP [<ffffffff81153948>] __discard_prealloc+0x98/0xb3 Apr 8 03:40:01 Tower kernel: RSP <ffff88045351bb68> Apr 8 03:40:01 Tower kernel: ---[ end trace ea9896d35b985763 ]---

I'm a longtime XBMC user, and one of the nicest things about it is the ability to customize the keymappings and remote mappings to do exactly what you want simply by editing an XML file or two. As far as hardware goes, I picked up a cheap MCE remote, but just for the USB -> IR receiver, and I use a Logitech Harmony 880 remote with it and everything else in my home theater rack. The Harmony website already has mappings in their database for a bunch of MCE remotes, so getting it to work is simple. For anything requiring a mouse or keyboard, I've been using an integrated keyboard/remote from Lenovo: http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/integration.workflow:ProductDisplayItem?GroupID=38&Code=57Y6336 ...which isn't something I'd want to write a novel with, but for adding something minor does the trick.

I recently moved from a WHS rig (HP MediaSmart EX470 plus 4-bay eSATA array) because of a few reasons. The first was the RAID-1 aspect of it, where I was losing half of my space to duplication, rather than the parity drive idea that unraid uses. The second was an issue of scale, where the system seemed to be struggling with 8 disks and would periodically check out for no obvious reason. Finally, I had a disk that was showing SMART errors that i was monitoring and knew the drive was failing, but WHS remained blissfully ignorant of that fact right up to the day it died. That's inexcusable in a storage array of any sort. Since moving to unraid, I have more space, it's easy to manage, and completely stable. Anyone want to buy a HP MediaSmart?

4GB of memory, so I doubt it's an out of mem issue, though I can run an overnight memtest again if that looks suspicious. And Joe - thanks - will send an email shortly.

Running 4.5.3 on a Supermicro X7SPA-HF with AOC-SASLP-MV8 card. Last night I decided to try to add two new drives (1TB WD EADS) at the same time. I'm just using the built-in clearing, not preclearing. Shut down the array, powered down gracefully, added the two drives (disk 6 and disk 7), powered back up, stopped the auto-started array, assigned the two new drives, and started the array. Drives start clearing, I go to bed. This morning I check in, and find that none of the shares are up, and when I check the web interface, it shows all drives in a state of Mounting. Refresh does nothing. Upon reboot, the drives show up as new again. Checking the syslog, I see a kernel page error followed by a dump. Any ideas? Syslog snippet below: May 6 23:21:24 Tower kernel: md: import disk0: [8,48] (sdd) WDC WD20EARS-00S WD-WCAVY2845005 offset: 63 size: 1953514552 May 6 23:21:24 Tower kernel: md: import disk1: [8,80] (sdf) WDC WD20EARS-00S WD-WCAVY2744880 offset: 63 size: 1953514552 May 6 23:21:24 Tower kernel: md: import disk2: [8,64] (sde) WDC WD20EADS-32R WD-WCAVY3272016 offset: 63 size: 1953514552 May 6 23:21:24 Tower kernel: md: import disk3: [8,128] (sdi) WDC WD20EADS-00R WD-WCAVY1712376 offset: 63 size: 1953514552 May 6 23:21:24 Tower kernel: md: import disk4: [8,112] (sdh) WDC WD20EADS-00S WD-WCAVY1300784 offset: 63 size: 1953514552 May 6 23:21:24 Tower kernel: md: import disk5: [8,96] (sdg) WDC WD10EACS-00D WD-WCAU40691353 offset: 63 size: 976762552 May 6 23:21:24 Tower kernel: md: import disk6: [8,32] (sdc) WDC WD10EACS-22D WD-WCAU42559937 offset: 63 size: 976762552 May 6 23:21:24 Tower kernel: md: disk6 new disk May 6 23:21:24 Tower kernel: md: import disk7: [8,16] (sdb) WDC WD10EACS-22D WD-WCAU42662693 offset: 63 size: 976762552 May 6 23:21:24 Tower kernel: md: disk7 new disk May 6 23:21:24 Tower kernel: mdcmd (2): set md_num_stripes 1280 May 6 23:21:24 Tower kernel: mdcmd (3): set md_write_limit 768 May 6 23:21:24 Tower kernel: mdcmd (4): set md_sync_window 288 May 6 23:21:24 Tower kernel: mdcmd (5): set spinup_group 0 4 May 6 23:21:24 Tower kernel: mdcmd (6): set spinup_group 1 32 May 6 23:21:24 Tower kernel: mdcmd (7): set spinup_group 2 1 May 6 23:21:24 Tower kernel: mdcmd (: set spinup_group 3 0 May 6 23:21:24 Tower kernel: mdcmd (9): set spinup_group 4 0 May 6 23:21:24 Tower kernel: mdcmd (10): set spinup_group 5 2 May 6 23:21:24 Tower kernel: mdcmd (11): set spinup_group 6 128 May 6 23:21:24 Tower kernel: mdcmd (12): set spinup_group 7 64 May 6 23:21:41 Tower emhttp: shcmd (52): /usr/local/sbin/set_ncq sdd 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (53): /usr/local/sbin/set_ncq sdf 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (54): /usr/local/sbin/set_ncq sde 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (55): /usr/local/sbin/set_ncq sdi 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (56): /usr/local/sbin/set_ncq sdh 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (57): /usr/local/sbin/set_ncq sdg 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (58): /usr/local/sbin/set_ncq sdc 1 >/dev/null May 6 23:21:41 Tower emhttp: shcmd (59): /usr/local/sbin/set_ncq sdb 1 >/dev/null May 6 23:21:41 Tower emhttp: writing mbr on disk 6 (/dev/sdc) May 6 23:21:41 Tower emhttp: re-reading /dev/sdc partition table May 6 23:21:41 Tower kernel: sdc: sdc1 May 6 23:21:41 Tower ata_id[1948]: HDIO_GET_IDENTITY failed for '/dev/block/8:32' May 6 23:21:42 Tower ata_id[1963]: HDIO_GET_IDENTITY failed for '/dev/block/8:32' May 6 23:21:42 Tower emhttp: writing mbr on disk 7 (/dev/sdb) May 6 23:21:42 Tower emhttp: re-reading /dev/sdb partition table May 6 23:21:42 Tower kernel: sdb: sdb1 May 6 23:21:43 Tower emhttp: clearing disk6 disk7 ... May 6 23:23:45 Tower emhttp: ... clearing 1% complete May 6 23:25:48 Tower emhttp: ... clearing 2% complete May 6 23:27:46 Tower emhttp: ... clearing 3% complete May 6 23:29:47 Tower emhttp: ... clearing 4% complete May 6 23:31:46 Tower emhttp: ... clearing 5% complete May 6 23:33:47 Tower emhttp: ... clearing 6% complete May 6 23:35:55 Tower emhttp: ... clearing 7% complete May 6 23:37:56 Tower emhttp: ... clearing 8% complete May 6 23:39:56 Tower emhttp: ... clearing 9% complete May 6 23:41:57 Tower emhttp: ... clearing 10% complete May 6 23:43:57 Tower emhttp: ... clearing 11% complete May 6 23:45:57 Tower emhttp: ... clearing 12% complete May 6 23:47:58 Tower emhttp: ... clearing 13% complete May 6 23:50:07 Tower emhttp: ... clearing 14% complete May 6 23:52:09 Tower emhttp: ... clearing 15% complete May 6 23:54:11 Tower emhttp: ... clearing 16% complete May 6 23:56:12 Tower emhttp: ... clearing 17% complete May 6 23:58:14 Tower emhttp: ... clearing 18% complete May 7 00:00:17 Tower emhttp: ... clearing 19% complete May 7 00:02:19 Tower emhttp: ... clearing 20% complete May 7 00:04:27 Tower emhttp: ... clearing 21% complete May 7 00:06:30 Tower emhttp: ... clearing 22% complete May 7 00:08:32 Tower emhttp: ... clearing 23% complete May 7 00:10:32 Tower emhttp: ... clearing 24% complete May 7 00:12:33 Tower emhttp: ... clearing 25% complete May 7 00:14:37 Tower emhttp: ... clearing 26% complete May 7 00:16:42 Tower emhttp: ... clearing 27% complete May 7 00:18:42 Tower emhttp: ... clearing 28% complete May 7 00:20:46 Tower emhttp: ... clearing 29% complete May 7 00:22:47 Tower emhttp: ... clearing 30% complete May 7 00:24:49 Tower emhttp: ... clearing 31% complete May 7 00:26:51 Tower emhttp: ... clearing 32% complete May 7 00:28:53 Tower emhttp: ... clearing 33% complete May 7 00:30:57 Tower emhttp: ... clearing 34% complete May 7 00:33:01 Tower emhttp: ... clearing 35% complete May 7 00:35:14 Tower emhttp: ... clearing 36% complete May 7 00:37:17 Tower emhttp: ... clearing 37% complete May 7 00:39:21 Tower emhttp: ... clearing 38% complete May 7 00:41:25 Tower emhttp: ... clearing 39% complete May 7 00:43:30 Tower emhttp: ... clearing 40% complete May 7 00:45:33 Tower emhttp: ... clearing 41% complete May 7 00:47:46 Tower emhttp: ... clearing 42% complete May 7 00:49:51 Tower emhttp: ... clearing 43% complete May 7 00:51:59 Tower emhttp: ... clearing 44% complete May 7 00:54:06 Tower emhttp: ... clearing 45% complete May 7 00:56:14 Tower emhttp: ... clearing 46% complete May 7 00:58:21 Tower emhttp: ... clearing 47% complete May 7 01:00:29 Tower emhttp: ... clearing 48% complete May 7 01:02:41 Tower emhttp: ... clearing 49% complete May 7 01:04:50 Tower emhttp: ... clearing 50% complete May 7 01:06:59 Tower emhttp: ... clearing 51% complete May 7 01:09:08 Tower emhttp: ... clearing 52% complete May 7 01:11:17 Tower emhttp: ... clearing 53% complete May 7 01:13:27 Tower emhttp: ... clearing 54% complete May 7 01:15:42 Tower emhttp: ... clearing 55% complete May 7 01:17:54 Tower emhttp: ... clearing 56% complete May 7 01:20:07 Tower emhttp: ... clearing 57% complete May 7 01:22:20 Tower emhttp: ... clearing 58% complete May 7 01:24:34 Tower emhttp: ... clearing 59% complete May 7 01:26:47 Tower emhttp: ... clearing 60% complete May 7 01:29:04 Tower emhttp: ... clearing 61% complete May 7 01:31:21 Tower emhttp: ... clearing 62% complete May 7 01:33:38 Tower emhttp: ... clearing 63% complete May 7 01:35:56 Tower emhttp: ... clearing 64% complete May 7 01:38:18 Tower emhttp: ... clearing 65% complete May 7 01:40:39 Tower emhttp: ... clearing 66% complete May 7 01:43:01 Tower emhttp: ... clearing 67% complete May 7 01:45:33 Tower emhttp: ... clearing 68% complete May 7 01:47:56 Tower emhttp: ... clearing 69% complete May 7 01:50:19 Tower emhttp: ... clearing 70% complete May 7 01:52:59 Tower emhttp: ... clearing 71% complete May 7 01:55:27 Tower emhttp: ... clearing 72% complete May 7 01:57:58 Tower emhttp: ... clearing 73% complete May 7 02:00:28 Tower emhttp: ... clearing 74% complete May 7 02:02:59 Tower emhttp: ... clearing 75% complete May 7 02:05:34 Tower emhttp: ... clearing 76% complete May 7 02:08:09 Tower emhttp: ... clearing 77% complete May 7 02:10:50 Tower emhttp: ... clearing 78% complete May 7 02:13:27 Tower emhttp: ... clearing 79% complete May 7 02:16:09 Tower emhttp: ... clearing 80% complete May 7 02:18:56 Tower emhttp: ... clearing 81% complete May 7 02:21:52 Tower emhttp: ... clearing 82% complete May 7 02:24:49 Tower emhttp: ... clearing 83% complete May 7 02:27:47 Tower emhttp: ... clearing 84% complete May 7 02:30:42 Tower emhttp: ... clearing 85% complete May 7 02:33:41 Tower emhttp: ... clearing 86% complete May 7 02:36:48 Tower emhttp: ... clearing 87% complete May 7 02:39:49 Tower emhttp: ... clearing 88% complete May 7 02:43:00 Tower emhttp: ... clearing 89% complete May 7 02:46:01 Tower emhttp: ... clearing 90% complete May 7 02:49:08 Tower emhttp: ... clearing 91% complete May 7 02:52:18 Tower emhttp: ... clearing 92% complete May 7 02:55:30 Tower emhttp: ... clearing 93% complete May 7 02:58:50 Tower emhttp: ... clearing 94% complete May 7 03:02:10 Tower emhttp: ... clearing 95% complete May 7 03:05:40 Tower emhttp: ... clearing 96% complete May 7 03:09:13 Tower emhttp: ... clearing 97% complete May 7 03:12:59 Tower emhttp: ... clearing 98% complete May 7 03:16:50 Tower emhttp: ... clearing 99% complete May 7 03:20:43 Tower emhttp: ... clearing 100% complete May 7 03:20:43 Tower emhttp: ... syncing May 7 03:20:45 Tower kernel: mdcmd (24): start PROTECTED_EXPANSION May 7 03:20:45 Tower kernel: unraid: allocating 43820K for 1280 stripes (8 disks) May 7 03:20:45 Tower kernel: md1: running, size: 1953514552 blocks May 7 03:20:45 Tower kernel: md2: running, size: 1953514552 blocks May 7 03:20:45 Tower kernel: md3: running, size: 1953514552 blocks May 7 03:20:45 Tower kernel: md4: running, size: 1953514552 blocks May 7 03:20:45 Tower kernel: md5: running, size: 976762552 blocks May 7 03:20:45 Tower kernel: md6: running, size: 976762552 blocks May 7 03:20:45 Tower kernel: md7: running, size: 976762552 blocks May 7 03:20:45 Tower kernel: mdcmd (26): spindown 0 May 7 03:20:46 Tower kernel: mdcmd (27): spindown 1 May 7 03:20:47 Tower kernel: mdcmd (28): spindown 2 May 7 03:20:48 Tower kernel: mdcmd (30): spindown 3 May 7 03:20:48 Tower kernel: BUG: unable to handle kernel paging request at f8ac8000 May 7 03:20:48 Tower kernel: IP: [<f8abe8c4>] md_cmd_proc_read+0x41/0x54 [md_mod] May 7 03:20:48 Tower kernel: *pdpt = 0000000001443001 *pde = 00000000039fe067 *pte = 0000000000000000 May 7 03:20:48 Tower kernel: Oops: 0000 [#1] SMP May 7 03:20:48 Tower kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1f.5/host5/target5:0:0/5:0:0:0/block/sdi/stat May 7 03:20:48 Tower kernel: Modules linked in: md_mod xor ata_piix e1000e mvsas libsas scst scsi_transport_sas [last unloaded: md_mod] May 7 03:20:48 Tower kernel: May 7 03:20:48 Tower kernel: Pid: 1920, comm: emhttp Not tainted (2.6.32.9-unRAID #1) X7SPA-HF May 7 03:20:48 Tower kernel: EIP: 0060:[<f8abe8c4>] EFLAGS: 00210203 CPU: 1 May 7 03:20:48 Tower kernel: EIP is at md_cmd_proc_read+0x41/0x54 [md_mod] May 7 03:20:48 Tower kernel: EAX: c3979f38 EBX: fffff24a ECX: 3fffef6f EDX: fffff24a May 7 03:20:48 Tower kernel: ESI: f8ac7ffe EDI: f727948c EBP: c3979f04 ESP: c3979ef4 May 7 03:20:48 Tower kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 May 7 03:20:48 Tower kernel: Process emhttp (pid: 1920, ti=c3978000 task=f6ca0000 task.ti=c3978000) May 7 03:20:48 Tower kernel: Stack: May 7 03:20:48 Tower kernel: c3979f38 f8abe883 00000000 f7276000 c3979f4c c109d56d 00000400 c3979f3c May 7 03:20:48 Tower kernel: <0> 00000000 00000400 00000000 00000400 b78c7000 f6dab9c0 00000000 f6dab9c0 May 7 03:20:48 Tower kernel: <0> 00000400 f7276000 00000001 f6dab9c0 c109d462 fffffffb c3979f70 c1099eea May 7 03:20:48 Tower kernel: Call Trace: May 7 03:20:48 Tower kernel: [<f8abe883>] ? md_cmd_proc_read+0x0/0x54 [md_mod] May 7 03:20:48 Tower kernel: [<c109d56d>] ? proc_file_read+0x10b/0x22d May 7 03:20:48 Tower kernel: [<c109d462>] ? proc_file_read+0x0/0x22d May 7 03:20:48 Tower kernel: [<c1099eea>] ? proc_reg_read+0x56/0x6a May 7 03:20:48 Tower kernel: [<c1099e94>] ? proc_reg_read+0x0/0x6a May 7 03:20:48 Tower kernel: [<c106cb60>] ? vfs_read+0x8a/0x114 May 7 03:20:48 Tower kernel: [<c106cef7>] ? sys_read+0x3b/0x60 May 7 03:20:48 Tower kernel: [<c1002935>] ? syscall_call+0x7/0xb May 7 03:20:48 Tower kernel: Code: 55 f0 e8 da 47 67 c8 8d 50 01 29 f2 39 d3 7c 0b 8b 45 0c 89 d3 c7 00 01 00 00 00 8b 45 f0 89 d9 81 c6 a0 3d ac f8 c1 e9 02 89 38 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5a 89 d8 5b 5e 5f 5d c3 55 89 May 7 03:20:48 Tower kernel: EIP: [<f8abe8c4>] md_cmd_proc_read+0x41/0x54 [md_mod] SS:ESP 0068:c3979ef4 May 7 03:20:48 Tower kernel: CR2: 00000000f8ac8000 May 7 03:20:48 Tower kernel: ---[ end trace 21bf876656a0f23e ]--- May 7 03:20:49 Tower kernel: mdcmd (31): spindown 4 May 7 03:20:49 Tower kernel: mdcmd (32): spindown 5 May 7 03:20:50 Tower kernel: mdcmd (33): spindown 6 May 7 03:20:51 Tower kernel: mdcmd (34): spindown 7