You are not logged in.

#1 2018-04-02 20:16:38

arcdmp
Member
Registered: 2018-01-16
Posts: 15

[SOLVED] Synchronizing SCSI cache failure

I've had full system freezes with linux as of recently (linux-4.15.12-1), and found some logs in dmesg I don't exactly know how to debug:

[ +10.195770] sd 7:0:0:0: [sdc] tag#2 data cmplt err -71 uas-tag 3 inflight: CMD
[  +0.000007] sd 7:0:0:0: [sdc] tag#2 CDB: opcode=0x2a 2a 00 01 d1 83 e0 00 00 28 00
[ +24.981444] sd 7:0:0:0: [sdc] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
[  +0.000008] sd 7:0:0:0: [sdc] tag#1 CDB: opcode=0x28 28 00 0a 08 85 90 00 01 00 00
[  +0.000103] sd 7:0:0:0: [sdc] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD IN
[  +0.000006] sd 7:0:0:0: [sdc] tag#8 CDB: opcode=0x28 28 00 09 f3 fe 00 00 01 00 00
[  +0.000061] sd 7:0:0:0: [sdc] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[  +0.000005] sd 7:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 09 f3 f5 d8 00 01 00 00
[  +0.000049] sd 7:0:0:0: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[  +0.000005] sd 7:0:0:0: [sdc] tag#7 CDB: opcode=0x2a 2a 00 01 d1 84 c8 00 00 08 00
[  +0.000047] sd 7:0:0:0: [sdc] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[  +0.000004] sd 7:0:0:0: [sdc] tag#6 CDB: opcode=0x2a 2a 00 01 d1 84 b8 00 00 08 00
[  +0.003514] sd 7:0:0:0: [sdc] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[  +0.000008] sd 7:0:0:0: [sdc] tag#5 CDB: opcode=0x2a 2a 00 01 d1 84 78 00 00 08 00
[  +0.003470] sd 7:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[  +0.000005] sd 7:0:0:0: [sdc] tag#4 CDB: opcode=0x2a 2a 00 01 d1 84 30 00 00 08 00
[  +0.003454] sd 7:0:0:0: [sdc] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[  +0.000006] sd 7:0:0:0: [sdc] tag#3 CDB: opcode=0x2a 2a 00 01 d1 84 20 00 00 08 00
[  +0.003478] sd 7:0:0:0: [sdc] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD
[  +0.000004] sd 7:0:0:0: [sdc] tag#2 CDB: opcode=0x2a 2a 00 01 d1 83 e0 00 00 28 00
[  +0.055769] scsi host7: uas_eh_device_reset_handler start
[  +0.150438] usb 4-3: reset SuperSpeed USB device number 3 using xhci_hcd
[  +0.032045] scsi host7: uas_eh_device_reset_handler success

When it happened, I assumed there was something wrong in the latest kernel, and downgraded first to linux-4.15.11-1, then linux-4.15.9-1, but no luck.
This total freeze takes about 30 seconds (the [ +24.981444] timestamp in dmesg), and when it started happening, it would repeat every 2-5 minutes, making it nearly impossible to debug this issue. I changed kernel to linux-lts-4.14.31-1, and it hadn't show again for a while.

Then, it just started up again. What can I do to debug this?
For context, I boot from a USB3 external hard drive (Seagate Backup Plus Slim 1TB) which works fine otherwise. I had earlier issues with USB flakiness (which may have been cable related), so I physically locked it down to a board and those issues disappeared.

As I was looking into this, I noticed another issue that might be related: my external USB3 wifi card had always been randomly disconnected, for no reason at all. I haven't got to the bottom of it, but from what I found, USB3 apparently has problems in linux.

Edit: The above error message is the most often repeated, but I found this one once:

Apr 02 15:37:16 arch kernel: usb 4-2: USB disconnect, device number 2
Apr 02 15:37:16 arch kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
Apr 02 15:37:16 arch kernel: sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
Apr 02 15:37:16 arch kernel: sd 7:0:0:0: [sdc] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN
Apr 02 15:37:16 arch kernel: sd 7:0:0:0: [sdc] tag#6 CDB: opcode=0x28 28 00 0b d5 98 00 00 00 20 00
Apr 02 15:37:16 arch kernel: scsi host7: uas_eh_device_reset_handler start
Apr 02 15:37:16 arch kernel: usb 4-3: reset SuperSpeed USB device number 3 using xhci_hcd
Apr 02 15:37:16 arch kernel: scsi host7: uas_eh_device_reset_handler success

Last edited by arcdmp (2018-04-02 22:00:31)

Offline

#2 2018-04-02 20:52:36

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: [SOLVED] Synchronizing SCSI cache failure

I would start by trying to disable UAS for that particular disk and check if it helps. The hint to do that comes from:

Apr 02 15:37:16 arch kernel: scsi host7: uas_eh_device_reset_handler start

R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#3 2018-04-02 22:00:15

arcdmp
Member
Registered: 2018-01-16
Posts: 15

Re: [SOLVED] Synchronizing SCSI cache failure

Thanks!, from your post, I found an older solution and I'm no longer getting the freezes: https://bbs.archlinux.org/viewtopic.php … 2#p1428782
How significant are the performance losses from disabling UAS? Even though I have a spinning drive, it doesn't seem noticeably different.

EDIT 07-04-2018:
Hopefully this doesn't necrobump, but after having these issues again and consistently finding my own thread from Google searches, I wanted to update anyone else who has the same problem and came across this.
The above thread didn't solve my problems at all. After spending several hours trying to fix this again, it's definitely something with the UAS module and certain Seagate drives. Unfortunately, blacklisting the UAS module, either while the system was running, through modprobe.d, or a kernel commandline had no effect; it's always ignored.
The SCSI cache Synchronization error still happens, and now it's got worse: it triggers every time on first boot, adding several minutes before I can log in. This is in addition to the random failures I had above, and the only workaround is to keep rebooting until I have a session where this doesn't happen regularly.

Last edited by arcdmp (2018-07-05 01:31:22)

Offline

#4 2018-04-03 08:47:08

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: [SOLVED] Synchronizing SCSI cache failure

I guess that if you benchmark it properly you will see some decrease in speed, in practise you will probably not notice, specially with a spinning rust disk.

That said, you might want to report this problem upstream to the kernel developers, it might be that there is something that needs to be fixed or at least some default quirk should be applied.


R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

Board footer

Powered by FluxBB