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