GroxyPod

Nov 20 13:29:36 Tower kernel: mce: [Hardware Error]: Machine check events logged Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: CPU 0: Machine Check Event: 0 Bank 11: 8c00004a000800c2 Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: TSC 7cc2532c5a4c6 Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: ADDR 44721c000 Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: MISC 90840080008148c Nov 20 13:29:36 Tower kernel: EDAC sbridge MC1: PROCESSOR 0:406f1 TIME 1574278176 SOCKET 0 APIC 0 Nov 20 13:29:36 Tower kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#2_DIMM#0 (channel:2 slot:0 page:0x44721c offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0008:00c2 socket:0 ha:0 channel_mask:4 rank:1) Looks like you've got a memory module that might be starting to fail. I would look into running memtest86, find out which one it is and replace it if you start getting more frequent errors or have system instability.

I am not having data corruption issues running a single cache drive using /mnt/cache/appdata for all dockers. All SQLite DBs are on the cache drive. Specs are in my signature as follows: unRAID Server Pro v6.7.2 | Array: 112TB | Parity: 10TBx2 | Cache: Samsung 970 EVO Plus 500GB NVMe | Flash Drive: SanDisk Cruzer Fit 16GB Case: Norco-4220 | MB: ASRock EP2C602-4L/D16 | PSU: Corsair RM1000i | RAM: IBM RDIMM 256GB (16GBx16) DDR3 1.5v Controllers: ASUS HYPER M.2 X16 | LSI 9201-16i | LSI 9210-8i Docker Containers: Guacamole | Jackett | Lidarr | Let's Encrypt | NetData | NZBGet | Ombi | Plex | Radarr | rTorrentVPN | Sonarr | Tautulli | Unifi Controller Plugins: Dynamix System Statistics | CA Auto Update Applications | Community Applications | Dev Tools | Dynamix SSD TRIM | Dynamix System Information | Fix Common Problems | Nerd Tools | Preclear Disks | rclone | Recycle Bin | Tips and Tweaks | Unassigned Devices | unBALANCE | User Scripts

Anyone else having an issue with all torrents showing timed out on trackers with the latest update (assuming 1.1.r42.g37c9d4b-1-04)? Just backed down to 1.1.r42.g37c9d4b-1-03 and my torrents no longer show time out.

Thanks johnnie.black!

Recently replaced my cache drive and noticed the BTRFS Filesystem DF reporting the wrong size. I ran btrfs fi usage /mnt/cache and noticed that my cache drive has a large unallocated spot which is likely what is causing my issue. btrfs fi usage /mnt/cache Overall: Device size: 465.76GiB Device allocated: 171.03GiB Device unallocated: 294.73GiB Device missing: 0.00B Used: 167.42GiB Free (estimated): 297.08GiB (min: 297.08GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 260.03MiB (used: 0.00B) Data,single: Size:168.00GiB, Used:165.65GiB /dev/nvme0n1p1 168.00GiB Metadata,single: Size:3.00GiB, Used:1.76GiB /dev/nvme0n1p1 3.00GiB System,single: Size:32.00MiB, Used:48.00KiB /dev/nvme0n1p1 32.00MiB Unallocated: /dev/nvme0n1p1 294.73GiB I looked on the googles and found that there is a btrfs filesystem resize max command that looks like it could correct the issue, but I would like to know if are any requirements to do this since it would be expanding the volume. I'm assuming the best practice would be to stop the array, backup the data, then do the command: btrfs filesystem resize max /mnt/cache and then bobs your uncle. Just wanted some clarification in case I need to format the cache drive instead. Thanks in advance! smalls-diagnostics-20190731-2102.zip

I believe this is functioning as designed. They don't want your unraid.net address accessible outside of your own network. As far as disabling SSL, you should be able to change the Use SSL/TLS option to no within the Identification setting.

I don't mean to send someone down a rabbit hole that doesn't need to be gone down; but after reading this thread, one question jumped out at me. Does anyone who is experiencing this corruption have a setup involving raid cards (LSI or other)? From what I'm seeing (with the limited listing of hardware specs provided thus far), it seems to be impacting people who directly connect drives to their motherboard. Not sure if this actually matters or not but just a thought.

So I upgraded my memory from 128GB to 256GB and now the reported 'max memory' is up to 256GB. Looks like it can be pushed to the full 512GB On my way! lol

Ah that makes sense. I have dual E5-2670s in place right now. The max showing on ARK is 384GB per CPU. Guess I'll just have to try

Thanks!

Can you upload your diagnostics? That will help speed up the process for those who can assist

Forgive me if this has been asked/answered but my searching-fu of google, reddit, and this forum has failed me if that is the case. I noticed on the unRAID dashboard, it has the following: installed: 128 GB Multi-bit ECC max. installable capacity 192 GB The manual for the motherboard reports the following: Capacity- 16x 240-pin DDR3 DIMM slots - Support up to 512GB DDR3 R/LR DIMM ; 128GB ECC/non-ECC unbuffered UDIMM I'm looking to max out the memory with RDIMMS potentially and wanted to make sure there wasn't some limitation for this in unRAID. Thanks in advance!

Awesome, thank you!

Thanks johnnie.black!

Thanks for looking into this Benson, I appreciate it! I figured that was the culprit. I went ahead and swapped the SATAIII port from SATAIII_0 to SATAIII_1 to see if that improves anything. Keeping an eye on it for possible bad port or cable. Booting up UnRAID did not produce the issue that was occurring above so we shall see. Fantastic. I'd prefer to just use PCIe power if that's the case anyway. Less cables to run across the board. Gotcha. So it sounds like I'd be stuck with a 3 card setup regardless. My last parity run (06/01/2019) was: Duration: 23 hours, 59 minutes, 35 seconds. Average speed: 115.8 MB/sec. When Parity starts, its usually in the 160 MB/sec range until it reaches the edge of one of the disks. I've got a mixture of 4TB/6TB/8TB disks in the array at the moment. As far as bottlenecks go, I'm not necessarily experiencing any other than an issue with slow DB messages on the Plex docker. Given that the cache drive was the subject to that error, it could of been related. I will continue to monitor and work on updating my disk tunables if that turns out not to resolve the issue.

Hey everyone, Running through my syslogs, I came across this line multiple times (example pulled from syslog.2.txt): Apr 8 23:53:22 Smalls kernel: ata1.00: Enabling discard_zeroes_data Apr 8 23:53:22 Smalls kernel: sd 2:0:0:0: [sdj] Attached SCSI disk Apr 8 23:53:22 Smalls kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 8 23:53:22 Smalls kernel: ata14.00: ATAPI: MARVELL VIRTUALL, , 1.09, max UDMA/66 So my concern is 2 parts: 1) Does that mean sdj is the device that is only pulling the 1.5Gbps link? If so, that is my cache drive 2) It mentions MARVELL below it (hisssssss), does that mean it is on the MARVELL sata port? I double checked it compared to the board and the cache drive is plugged in to SATAIII_0 which should be the Intel SATAIII port. Potential Improvements: Currently I'm running LSI 9210-8i x3 cards (IT Mode) in PCIE5/PCIE4/PCIE3. I was looking in to getting a RAID expander card and saw an ebay posting for: (E91267 E91267-202 E91267-203 INTEL RAID EXPANDER STORAGE CONTROLLER). So, a couple questions came from that: 1) Does the version of the card matter for unraid? E91267 vs -202 vs -203 2) Does anything extra need to be done to the card to get it to work with unraid, like something similar to IT Mode or a specific firmware? ^ - Unfortunately I have never used a RAID EXPANDER card before, so that drives additional questions: 1) Does a card like this require an additional power connector? 2) Does the card work like this: I plug in my 5 bays in to 5 of the connectors on the card, then the 6th connector goes to the LSI 9210-8i via mini-sas to mini-sas cable? If that is the case, does the cable location matter on the expander card? Thanks in advance for your time! Diagnostics attached smalls-diagnostics-20190604-1904.zip

Will do, thanks johnnie.black, as always

Hey everyone, Just looking for a sanity check here. I have ECC memory and got a memory related error yesterday. Based on the syslog, it looks to be only one occurrence so far. There hasn't been any system changes or power related events that have happened recently. Should I be looking to replace this ram stick in bank 9 right now, or is there a certain threshold I should be on the lookout for in terms of the number/occurrence of these events before I should start to worry? Thanks in advance! Dec 14 21:02:45 Smalls kernel: mce: [Hardware Error]: Machine check events logged Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: CPU 8: Machine Check Event: 0 Bank 9: 8c00004c000800c1 Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: TSC 69ab1d2d08ae7e Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: ADDR 18f3717000 Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: MISC 90860002000188c Dec 14 21:02:45 Smalls kernel: EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1544850165 SOCKET 1 APIC 20 Dec 14 21:02:45 Smalls kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x18f3717 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:1 rank:1) smalls-diagnostics-20181215-0523.zip

Your MainDir needs to be /data instead of ${AppDir}/downloads Mine is setup to have a container path of /downloads so I set mine up accordingly.

Sounds good. If I run into issues I will do the 5-10 percent method. Thanks again! Sent from my iPhone using Tapatalk Pro

Thanks for the reply johnnie.black, as always! Aside from the sluggish parity check, the only other issues I ran into were Plex buffering (both internal and external). I did have CPU Pinning enabled, and have since disabled it for testing purposes. Would the tunables test script still apply for v6.6.1, or is there a different method to use?

I was taking a look at my syslog when I noticed a call trace inside it. Can anyone tell me if this call trace is something to worry about? Logs attached. System is still up in case anything else needs to be looked at / pulled. This call trace happened during a parity check: Last check completed on Tue 02 Oct 2018 12:23:27 AM PDT (today), finding 0 errors. Duration: 1 day, 23 minutes, 26 seconds. Average speed: 91.1 MB/sec Oct 1 14:16:45 Smalls kernel: Call Trace: Oct 1 14:16:45 Smalls kernel: <IRQ> Oct 1 14:16:45 Smalls kernel: dump_stack+0x5d/0x79 Oct 1 14:16:45 Smalls kernel: nmi_cpu_backtrace+0x71/0x83 Oct 1 14:16:45 Smalls kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Oct 1 14:16:45 Smalls kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Oct 1 14:16:45 Smalls kernel: rcu_dump_cpu_stacks+0x91/0xbb Oct 1 14:16:45 Smalls kernel: rcu_check_callbacks+0x23f/0x5ca Oct 1 14:16:45 Smalls kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Oct 1 14:16:45 Smalls kernel: update_process_times+0x23/0x45 Oct 1 14:16:45 Smalls kernel: tick_sched_timer+0x36/0x64 Oct 1 14:16:45 Smalls kernel: __hrtimer_run_queues+0xb1/0x105 Oct 1 14:16:45 Smalls kernel: hrtimer_interrupt+0xf4/0x20d Oct 1 14:16:45 Smalls kernel: smp_apic_timer_interrupt+0x79/0x89 Oct 1 14:16:45 Smalls kernel: apic_timer_interrupt+0xf/0x20 Oct 1 14:16:45 Smalls kernel: </IRQ> Oct 1 14:16:45 Smalls kernel: RIP: 0010:memcmp+0xb/0x1d Oct 1 14:16:45 Smalls kernel: Code: 3c c1 48 85 ff 74 10 4c 89 d6 e8 74 ff ff ff 84 c0 75 09 ff c1 eb df b9 ea ff ff ff 89 c8 c3 31 c9 48 39 d1 74 13 0f b6 04 0f <44> 0f b6 04 0e 48 ff c1 44 29 c0 74 ea eb 02 31 c0 c3 48 01 fa 48 Oct 1 14:16:45 Smalls kernel: RSP: 0018:ffffc900078e3cb0 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13 Oct 1 14:16:45 Smalls kernel: RAX: 00000000000000d2 RBX: ffff88101add6ac0 RCX: 0000000000000000 Oct 1 14:16:45 Smalls kernel: RDX: 0000000000001000 RSI: ffff881038527000 RDI: ffff88101ae4a000 Oct 1 14:16:45 Smalls kernel: RBP: ffff881016b57800 R08: 0000000000000065 R09: ffff88101ae49000 Oct 1 14:16:45 Smalls kernel: R10: 0000000000000fd0 R11: 0000000000000ff0 R12: 0000000000000001 Oct 1 14:16:45 Smalls kernel: R13: ffff88101ae4a000 R14: ffff88101ae49000 R15: 0000000000000012 Oct 1 14:16:45 Smalls kernel: check_parity+0x2a7/0x349 [md_mod] Oct 1 14:16:45 Smalls kernel: ? autoremove_wake_function+0x9/0x2a Oct 1 14:16:45 Smalls kernel: ? __wake_up_common+0xa5/0x121 Oct 1 14:16:45 Smalls kernel: handle_stripe+0xe8a/0x1226 [md_mod] Oct 1 14:16:45 Smalls kernel: unraidd+0xbc/0x123 [md_mod] Oct 1 14:16:45 Smalls kernel: ? md_open+0x2c/0x2c [md_mod] Oct 1 14:16:45 Smalls kernel: md_thread+0xcc/0xf1 [md_mod] Oct 1 14:16:45 Smalls kernel: ? wait_woken+0x68/0x68 Oct 1 14:16:45 Smalls kernel: kthread+0x10b/0x113 Oct 1 14:16:45 Smalls kernel: ? kthread_flush_work_fn+0x9/0x9 Oct 1 14:16:45 Smalls kernel: ret_from_fork+0x35/0x40 smalls-diagnostics-20181001-2011.zip

Can you provide a mock-up of what your password looks like, including those 3 characters you're using?

Awesome! Let us know if you have any other issues.

I see you have test enabled in your advanced.yaml file, what happens when you set it to disable?