Please keep the list in the cc: On Sun, Apr 15, 2018 at 5:55 PM, Alexander Zapatka <alexzapa...@gmail.com> wrote: > output: > > $ sudo smartctl -l scterc /dev/sdc > smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.13.0-38-generic] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org > > SCT Error Recovery Control command not supported
OK you'll need to increase the scsi command timer to something like 120. Hopefully that works. This needs to be done for each device. # echo value > /sys/block/device-name/device/timeout https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/scsi-command-timer-device-status > after the last reboot i haven't done anything to restart the scrub or > remove the device... i have a syslog from the last crash, you can > see it here https://paste.ee/p/R2Pt7. if is not enough, i will > certainly start a scrub and let it crash. >Apr 13 23:53:41 kodbox kernel: [225349.101299] usb 1-1.4.2: reset high-speed >USB device number 7 using xhci_hcd Hmmm, could be there's a power issue. Not sure if it's related to the problem or not. I see this when I direct connect laptop drives in USB powered enclosures (no external power) directly to a my Intel NUC, but then the problem goes away when the drive is connected to a suitably powered USB hub, which is then connected to the computer. But it's worth a shot to change the scsi command timer as described resolves the problem first. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
