urbanracer34

So right now, I have 3 6TB WD Reds and a 1TB NVME SSD in my server, and since I'm having some problems with my SATA cables, as I was told in a previous support thread, I figured I would add more capacity while I'm replacing the SATA cables. Sadly, my local vendor doesn't have 6TB WD Reds and they are on backorder with their supplier, I would like to add at least 1 6TB Barracuda, which ARE locally available. Are their any risks to switching and mixing brands like this? Yes, I intend to pre-clear the new drives first before they enter service.

Ok. I currently have a lot on my head at the moment (don't want to get into it,) so I might not get to it for a while.

Cables appear to be secure. Can a SATA cable really go bad all of a sudden? I did another move operation this morning (a much smaller one,) with no errors in the log.

I don't have Turbo write enabled right now. I'l enable it after the copy. But I'm getting these errors in the system log now: Mar 8 11:31:22 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330) Mar 8 11:31:22 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514) Mar 8 11:31:22 GIBSON kernel: ata4.00: configured for UDMA/133 Mar 8 11:31:22 GIBSON kernel: ata4: EH complete Mar 8 11:33:21 GIBSON kernel: ata4.00: exception Emask 0x10 SAct 0x1f0 SErr 0x400100 action 0x6 frozen Mar 8 11:33:21 GIBSON kernel: ata4.00: irq_stat 0x08000000, interface fatal error Mar 8 11:33:21 GIBSON kernel: ata4: SError: { UnrecovData Handshk } Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:20:88:ef:9d/05:00:b4:01:00/40 tag 4 ncq dma 688128 out Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error) Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY } Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:28:c8:f4:9d/05:00:b4:01:00/40 tag 5 ncq dma 688128 out Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error) Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY } Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:30:08:fa:9d/05:00:b4:01:00/40 tag 6 ncq dma 688128 out Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error) Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY } Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:38:48:ff:9d/05:00:b4:01:00/40 tag 7 ncq dma 688128 out Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error) Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY } Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/08:40:88:04:9e/00:00:b4:01:00/40 tag 8 ncq dma 4096 out Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error) Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY } Mar 8 11:33:21 GIBSON kernel: ata4: hard resetting link Mar 8 11:33:21 GIBSON kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Mar 8 11:33:21 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330) Mar 8 11:33:21 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514) Mar 8 11:33:21 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330) Mar 8 11:33:21 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514) Mar 8 11:33:21 GIBSON kernel: ata4.00: configured for UDMA/133 Mar 8 11:33:21 GIBSON kernel: ata4: EH complete Mar 8 11:33:29 GIBSON webGUI: Successful login user root from 192.168.1.158 BIOS IS ACTUALLY UP TO DATE! Tried flashing, have same revision.

Currently at 34 days, 15 hours, 23 minutes uptime on 6.8.2.

Updated (mostly) without issue. When I restarted from unraid, the UEFI hung and wouldn't process the USB stick. I did a force restart, it found the USB right away and booted without any more trouble. And I had JUST reached a month of uptime today. DERP!

Like most currently: ease of use Want in future: native iOS management app or mobile optimized version of web interface

This is tenatively solved. Will check on this coming Saturday to see if the error comes up again. edi: SOLVED on RC6, issue hasn't come up on RC7.

Changed Status to Solved

There was a newer version, so I updated the BIOS. Now to see if this issue will come back. (I HOPE NOT!)

As soon as I made a wired connection, the problem went away and it is copying faster than ever. I'm sorry to have wasted people's time. Consider this closed.

Changed Status to Solved

I filed a bug report about this:

No. No pihole here. I am not having any connection issues here AFAIK. Connection has been stable.

It's fixed! Thanks a ton!

How to revert back to last version?! I see no option to do so.

Can confirm this fixes it.

I'm getting an error in rutorrent (the web gui) in the log since the latest update to the container image. [07.04.2019 12:10:09] WebUI started. [07.04.2019 12:10:09] cloudflare: Cant load cfscrape, python [04/07/2019 12:10:10] Python Not Found Can you help me? Thanks, urbanracer34

Hi. I can't seem to modify any of my settings in my Rutorrent instance, with none of them persisting after container restart or update. I tried to modify the downloads directory from "/downloads/incoming" to JUST "/downloads/" and to keep the port as one specific port and not a random one. Whenever I restart the container, the modified settings NEVER take effect. Is this a problem for anyone else? Thanks, urbanracer34

Well there goes nearly a month of continuous uptime. Updating now... EDIT1: Updated. Nothing seeming out of sorts yet.

DOH! Thanks for this. Never would have seen it otherwise. Limetech, you can now close this with whatever reason code you want.