* [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge
@ 2021-09-21 10:17 Tobias Jakobi
2021-09-21 15:13 ` Alan Stern
0 siblings, 1 reply; 8+ messages in thread
From: Tobias Jakobi @ 2021-09-21 10:17 UTC (permalink / raw)
To: stern; +Cc: gregkh, linux-usb, Tobias Jakobi
The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure
is advertised as having UASP support, but appears to have problems with 4Kn
drives (test was done with two Seagate Exos X, 12TB).
Disable UAS for the VL817 as it behaves highly unstable:
[Aug14 16:31] usb 2-1.2: USB disconnect, device number 4
[ +0.007701] sd 4:0:0:0: [sdb] tag#4 uas_zap_pending 0 uas-tag 1 inflight: CMD
[ +0.000004] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00
[ +0.000022] sd 4:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=19s
[ +0.000001] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00
[ +0.000001] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
[ +0.000028] blk_update_request: I/O error, dev sdb, sector 29041360 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
[ +0.000000] blk_update_request: I/O error, dev sdb, sector 16 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.000005] md: super_written gets error=-5
[ +0.000002] md/raid1:md126: Disk failure on sdb, disabling device.
md/raid1:md126: Operation continuing on 1 devices.
[ +0.000024] blk_update_request: I/O error, dev sdb, sector 29042384 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
[ +0.000222] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[ +0.078154] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.000025] blk_update_request: I/O error, dev sdb, sector 29040344 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.007520] blk_update_request: I/O error, dev sdb, sector 29040352 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.000021] blk_update_request: I/O error, dev sdb, sector 29040360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.000015] blk_update_request: I/O error, dev sdb, sector 29040368 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.000009] blk_update_request: I/O error, dev sdb, sector 29040376 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[ +0.023299] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
[ +1.893439] usb 2-1.2: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd
[ +0.024064] scsi host7: uas
[ +16.365880] scsi 7:0:0:0: Direct-Access ST12000N M001G-2MV103 SB2D PQ: 0 ANSI: 6
[ +0.001192] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ +0.000940] sd 7:0:0:0: [sde] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB)
[ +0.000130] sd 7:0:0:0: [sde] Write Protect is off
[ +0.000001] sd 7:0:0:0: [sde] Mode Sense: 2f 00 00 00
[ +0.000265] sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ +0.000399] sd 7:0:0:0: [sde] Optimal transfer size 268431360 bytes
[ +0.120240] sd 7:0:0:0: [sde] Attached SCSI disk
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
---
drivers/usb/storage/unusual_uas.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index bda0f2cdf093..7d83ecf835c6 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -125,6 +125,13 @@ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_ATA_1X),
+/* Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> */
+UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999,
+ "VIA",
+ "VL817",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_IGNORE_UAS),
+
/* Reported-by: Icenowy Zheng <icenowy@aosc.io> */
UNUSUAL_DEV(0x2537, 0x1068, 0x0000, 0x9999,
"Norelsys",
--
2.32.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-21 10:17 [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge Tobias Jakobi @ 2021-09-21 15:13 ` Alan Stern 2021-09-21 16:06 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Alan Stern @ 2021-09-21 15:13 UTC (permalink / raw) To: Tobias Jakobi; +Cc: gregkh, linux-usb, Tobias Jakobi On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: > The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure > is advertised as having UASP support, but appears to have problems with 4Kn > drives (test was done with two Seagate Exos X, 12TB). > > Disable UAS for the VL817 as it behaves highly unstable: > > [Aug14 16:31] usb 2-1.2: USB disconnect, device number 4 So first the drive was unplugged or disconnected... > [ +0.007701] sd 4:0:0:0: [sdb] tag#4 uas_zap_pending 0 uas-tag 1 inflight: CMD > [ +0.000004] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 > [ +0.000022] sd 4:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=19s > [ +0.000001] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 > [ +0.000001] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > [ +0.000028] blk_update_request: I/O error, dev sdb, sector 29041360 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > [ +0.000000] blk_update_request: I/O error, dev sdb, sector 16 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.000005] md: super_written gets error=-5 > [ +0.000002] md/raid1:md126: Disk failure on sdb, disabling device. > md/raid1:md126: Operation continuing on 1 devices. > [ +0.000024] blk_update_request: I/O error, dev sdb, sector 29042384 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > [ +0.000222] sd 4:0:0:0: [sdb] Synchronizing SCSI cache > [ +0.078154] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.000025] blk_update_request: I/O error, dev sdb, sector 29040344 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.007520] blk_update_request: I/O error, dev sdb, sector 29040352 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.000021] blk_update_request: I/O error, dev sdb, sector 29040360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.000015] blk_update_request: I/O error, dev sdb, sector 29040368 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.000009] blk_update_request: I/O error, dev sdb, sector 29040376 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > [ +0.023299] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00 Then there was a bunch of errors, which is to be expected when a drive is suddenly disconnected... > [ +1.893439] usb 2-1.2: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd > [ +0.024064] scsi host7: uas > [ +16.365880] scsi 7:0:0:0: Direct-Access ST12000N M001G-2MV103 SB2D PQ: 0 ANSI: 6 > [ +0.001192] sd 7:0:0:0: Attached scsi generic sg1 type 0 > [ +0.000940] sd 7:0:0:0: [sde] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB) > [ +0.000130] sd 7:0:0:0: [sde] Write Protect is off > [ +0.000001] sd 7:0:0:0: [sde] Mode Sense: 2f 00 00 00 > [ +0.000265] sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > [ +0.000399] sd 7:0:0:0: [sde] Optimal transfer size 268431360 bytes > [ +0.120240] sd 7:0:0:0: [sde] Attached SCSI disk And then the drive reconnected, this time successfully. How does this show that UAS was the reason for the problem? Indeed, how does this show there was any problem at all? > Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> > --- > drivers/usb/storage/unusual_uas.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h > index bda0f2cdf093..7d83ecf835c6 100644 > --- a/drivers/usb/storage/unusual_uas.h > +++ b/drivers/usb/storage/unusual_uas.h > @@ -125,6 +125,13 @@ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_NO_ATA_1X), > > +/* Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> */ > +UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999, > + "VIA", > + "VL817", > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > + US_FL_IGNORE_UAS), > + > /* Reported-by: Icenowy Zheng <icenowy@aosc.io> */ > UNUSUAL_DEV(0x2537, 0x1068, 0x0000, 0x9999, > "Norelsys", Instead of IGNORE_UAS, have you tried the NO_ATA_1X flag, which seems to help in the preceding entry (a different device from the same vendor)? Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-21 15:13 ` Alan Stern @ 2021-09-21 16:06 ` Tobias Jakobi 2021-09-21 16:42 ` Alan Stern 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2021-09-21 16:06 UTC (permalink / raw) To: Alan Stern, Tobias Jakobi; +Cc: gregkh, linux-usb Hi Alan, sorry but your analysis of the log is wrong. Nothing was disconnected or unplugged when the device behaves this way. The enclosure is connected to the power the entire time, and the same applies to the physical USB connection to my system. To make things very clear: This happens in under five minutes after having powered up the enclosure and starting a file transfer to the installed RAID. After blacklisting UASP the enclosure works perfectly fine for hours. I hope this clears things up. With best wishes, Tobias On 9/21/21 5:13 PM, Alan Stern wrote: > On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: >> The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure >> is advertised as having UASP support, but appears to have problems with 4Kn >> drives (test was done with two Seagate Exos X, 12TB). >> >> Disable UAS for the VL817 as it behaves highly unstable: >> >> [Aug14 16:31] usb 2-1.2: USB disconnect, device number 4 > So first the drive was unplugged or disconnected... > >> [ +0.007701] sd 4:0:0:0: [sdb] tag#4 uas_zap_pending 0 uas-tag 1 inflight: CMD >> [ +0.000004] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 >> [ +0.000022] sd 4:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=19s >> [ +0.000001] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 >> [ +0.000001] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >> [ +0.000028] blk_update_request: I/O error, dev sdb, sector 29041360 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >> [ +0.000000] blk_update_request: I/O error, dev sdb, sector 16 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.000005] md: super_written gets error=-5 >> [ +0.000002] md/raid1:md126: Disk failure on sdb, disabling device. >> md/raid1:md126: Operation continuing on 1 devices. >> [ +0.000024] blk_update_request: I/O error, dev sdb, sector 29042384 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >> [ +0.000222] sd 4:0:0:0: [sdb] Synchronizing SCSI cache >> [ +0.078154] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.000025] blk_update_request: I/O error, dev sdb, sector 29040344 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.007520] blk_update_request: I/O error, dev sdb, sector 29040352 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.000021] blk_update_request: I/O error, dev sdb, sector 29040360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.000015] blk_update_request: I/O error, dev sdb, sector 29040368 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.000009] blk_update_request: I/O error, dev sdb, sector 29040376 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >> [ +0.023299] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00 > Then there was a bunch of errors, which is to be expected when a drive > is suddenly disconnected... > >> [ +1.893439] usb 2-1.2: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd >> [ +0.024064] scsi host7: uas >> [ +16.365880] scsi 7:0:0:0: Direct-Access ST12000N M001G-2MV103 SB2D PQ: 0 ANSI: 6 >> [ +0.001192] sd 7:0:0:0: Attached scsi generic sg1 type 0 >> [ +0.000940] sd 7:0:0:0: [sde] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB) >> [ +0.000130] sd 7:0:0:0: [sde] Write Protect is off >> [ +0.000001] sd 7:0:0:0: [sde] Mode Sense: 2f 00 00 00 >> [ +0.000265] sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >> [ +0.000399] sd 7:0:0:0: [sde] Optimal transfer size 268431360 bytes >> [ +0.120240] sd 7:0:0:0: [sde] Attached SCSI disk > And then the drive reconnected, this time successfully. How does this > show that UAS was the reason for the problem? Indeed, how does this > show there was any problem at all? > >> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> >> --- >> drivers/usb/storage/unusual_uas.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h >> index bda0f2cdf093..7d83ecf835c6 100644 >> --- a/drivers/usb/storage/unusual_uas.h >> +++ b/drivers/usb/storage/unusual_uas.h >> @@ -125,6 +125,13 @@ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999, >> USB_SC_DEVICE, USB_PR_DEVICE, NULL, >> US_FL_NO_ATA_1X), >> >> +/* Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> */ >> +UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999, >> + "VIA", >> + "VL817", >> + USB_SC_DEVICE, USB_PR_DEVICE, NULL, >> + US_FL_IGNORE_UAS), >> + >> /* Reported-by: Icenowy Zheng <icenowy@aosc.io> */ >> UNUSUAL_DEV(0x2537, 0x1068, 0x0000, 0x9999, >> "Norelsys", > Instead of IGNORE_UAS, have you tried the NO_ATA_1X flag, which seems to > help in the preceding entry (a different device from the same vendor)? > > Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-21 16:06 ` Tobias Jakobi @ 2021-09-21 16:42 ` Alan Stern 2021-09-26 18:14 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Alan Stern @ 2021-09-21 16:42 UTC (permalink / raw) To: Tobias Jakobi; +Cc: Tobias Jakobi, gregkh, linux-usb On Tue, Sep 21, 2021 at 06:06:45PM +0200, Tobias Jakobi wrote: > Hi Alan, > > sorry but your analysis of the log is wrong. Nothing was disconnected or > unplugged when the device behaves this way. The enclosure is connected to > the power the entire time, and the same applies to the physical USB > connection to my system. That may be so, but if it is then the log extract you included with the patch is very misleading. For instance, you didn't include any part of the log before and leading up to the line saying "usb 2-1.2: USB disconnect, device number 4". Thus there is no way for the reader to tell what caused this event, whether it was a physical unplug or not. > To make things very clear: This happens in under five minutes after having > powered up the enclosure and starting a file transfer to the installed RAID. > After blacklisting UASP the enclosure works perfectly fine for hours. I hope > this clears things up. You didn't answer my question about using NO_ATA_1X instead of IGNORE_UAS. This is a perfect example of one of the dangers of top-posting -- it makes it far too easy for people to miss important points in the email they are replying to. (Hint: Don't top-post!) Alan Stern > With best wishes, > Tobias > > On 9/21/21 5:13 PM, Alan Stern wrote: > > On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: > > > The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure > > > is advertised as having UASP support, but appears to have problems with 4Kn > > > drives (test was done with two Seagate Exos X, 12TB). > > > > > > Disable UAS for the VL817 as it behaves highly unstable: > > > > > > [Aug14 16:31] usb 2-1.2: USB disconnect, device number 4 > > So first the drive was unplugged or disconnected... > > > > > [ +0.007701] sd 4:0:0:0: [sdb] tag#4 uas_zap_pending 0 uas-tag 1 inflight: CMD > > > [ +0.000004] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 > > > [ +0.000022] sd 4:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=19s > > > [ +0.000001] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 > > > [ +0.000001] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > > > [ +0.000028] blk_update_request: I/O error, dev sdb, sector 29041360 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > > > [ +0.000000] blk_update_request: I/O error, dev sdb, sector 16 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.000005] md: super_written gets error=-5 > > > [ +0.000002] md/raid1:md126: Disk failure on sdb, disabling device. > > > md/raid1:md126: Operation continuing on 1 devices. > > > [ +0.000024] blk_update_request: I/O error, dev sdb, sector 29042384 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 > > > [ +0.000222] sd 4:0:0:0: [sdb] Synchronizing SCSI cache > > > [ +0.078154] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.000025] blk_update_request: I/O error, dev sdb, sector 29040344 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.007520] blk_update_request: I/O error, dev sdb, sector 29040352 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.000021] blk_update_request: I/O error, dev sdb, sector 29040360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.000015] blk_update_request: I/O error, dev sdb, sector 29040368 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.000009] blk_update_request: I/O error, dev sdb, sector 29040376 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 > > > [ +0.023299] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00 > > Then there was a bunch of errors, which is to be expected when a drive > > is suddenly disconnected... > > > > > [ +1.893439] usb 2-1.2: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd > > > [ +0.024064] scsi host7: uas > > > [ +16.365880] scsi 7:0:0:0: Direct-Access ST12000N M001G-2MV103 SB2D PQ: 0 ANSI: 6 > > > [ +0.001192] sd 7:0:0:0: Attached scsi generic sg1 type 0 > > > [ +0.000940] sd 7:0:0:0: [sde] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB) > > > [ +0.000130] sd 7:0:0:0: [sde] Write Protect is off > > > [ +0.000001] sd 7:0:0:0: [sde] Mode Sense: 2f 00 00 00 > > > [ +0.000265] sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > > > [ +0.000399] sd 7:0:0:0: [sde] Optimal transfer size 268431360 bytes > > > [ +0.120240] sd 7:0:0:0: [sde] Attached SCSI disk > > And then the drive reconnected, this time successfully. How does this > > show that UAS was the reason for the problem? Indeed, how does this > > show there was any problem at all? > > > > > Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> > > > --- > > > drivers/usb/storage/unusual_uas.h | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h > > > index bda0f2cdf093..7d83ecf835c6 100644 > > > --- a/drivers/usb/storage/unusual_uas.h > > > +++ b/drivers/usb/storage/unusual_uas.h > > > @@ -125,6 +125,13 @@ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999, > > > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > > > US_FL_NO_ATA_1X), > > > +/* Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> */ > > > +UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999, > > > + "VIA", > > > + "VL817", > > > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > > > + US_FL_IGNORE_UAS), > > > + > > > /* Reported-by: Icenowy Zheng <icenowy@aosc.io> */ > > > UNUSUAL_DEV(0x2537, 0x1068, 0x0000, 0x9999, > > > "Norelsys", > > Instead of IGNORE_UAS, have you tried the NO_ATA_1X flag, which seems to > > help in the preceding entry (a different device from the same vendor)? > > > > Alan Stern > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-21 16:42 ` Alan Stern @ 2021-09-26 18:14 ` Tobias Jakobi 2021-09-27 15:04 ` Alan Stern 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2021-09-26 18:14 UTC (permalink / raw) To: Alan Stern; +Cc: Tobias Jakobi, gregkh, linux-usb Hello Alan, On 9/21/21 6:42 PM, Alan Stern wrote: > On Tue, Sep 21, 2021 at 06:06:45PM +0200, Tobias Jakobi wrote: >> Hi Alan, >> >> sorry but your analysis of the log is wrong. Nothing was disconnected or >> unplugged when the device behaves this way. The enclosure is connected to >> the power the entire time, and the same applies to the physical USB >> connection to my system. > That may be so, but if it is then the log extract you included with the > patch is very misleading. For instance, you didn't include any part of > the log before and leading up to the line saying "usb 2-1.2: USB > disconnect, device number 4". Thus there is no way for the reader to > tell what caused this event, whether it was a physical unplug or not. I included the part of the kernel log which shows how the issue manifests itself. Do you think I'm so stupid as to believe I could prevent a physical unplug of the enclosure by blacklisting UAS? Really, this is getting ridiculous... >> To make things very clear: This happens in under five minutes after having >> powered up the enclosure and starting a file transfer to the installed RAID. >> After blacklisting UASP the enclosure works perfectly fine for hours. I hope >> this clears things up. > You didn't answer my question about using NO_ATA_1X instead of > IGNORE_UAS. This is a perfect example of one of the dangers of > top-posting -- it makes it far too easy for people to miss important > points in the email they are replying to. (Hint: Don't top-post!) I did not answer this question, because I didn't have the answer to it yet. I have tested your suggestion today, but sadly I'm running into the same type of problem with NO_ATA_1X. You can find the complete kernel log here: https://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg_VL817.log The RAID1 is broken after such an event. With best wishes, Tobias > > Alan Stern > >> With best wishes, >> Tobias >> >> On 9/21/21 5:13 PM, Alan Stern wrote: >>> On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: >>>> The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure >>>> is advertised as having UASP support, but appears to have problems with 4Kn >>>> drives (test was done with two Seagate Exos X, 12TB). >>>> >>>> Disable UAS for the VL817 as it behaves highly unstable: >>>> >>>> [Aug14 16:31] usb 2-1.2: USB disconnect, device number 4 >>> So first the drive was unplugged or disconnected... >>> >>>> [ +0.007701] sd 4:0:0:0: [sdb] tag#4 uas_zap_pending 0 uas-tag 1 inflight: CMD >>>> [ +0.000004] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 >>>> [ +0.000022] sd 4:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=19s >>>> [ +0.000001] sd 4:0:0:0: [sdb] tag#4 CDB: opcode=0x2a 2a 00 00 37 63 da 00 00 80 00 >>>> [ +0.000001] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >>>> [ +0.000028] blk_update_request: I/O error, dev sdb, sector 29041360 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >>>> [ +0.000000] blk_update_request: I/O error, dev sdb, sector 16 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.000005] md: super_written gets error=-5 >>>> [ +0.000002] md/raid1:md126: Disk failure on sdb, disabling device. >>>> md/raid1:md126: Operation continuing on 1 devices. >>>> [ +0.000024] blk_update_request: I/O error, dev sdb, sector 29042384 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 >>>> [ +0.000222] sd 4:0:0:0: [sdb] Synchronizing SCSI cache >>>> [ +0.078154] blk_update_request: I/O error, dev sdb, sector 29040336 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.000025] blk_update_request: I/O error, dev sdb, sector 29040344 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.007520] blk_update_request: I/O error, dev sdb, sector 29040352 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.000021] blk_update_request: I/O error, dev sdb, sector 29040360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.000015] blk_update_request: I/O error, dev sdb, sector 29040368 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.000009] blk_update_request: I/O error, dev sdb, sector 29040376 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 >>>> [ +0.023299] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00 >>> Then there was a bunch of errors, which is to be expected when a drive >>> is suddenly disconnected... >>> >>>> [ +1.893439] usb 2-1.2: new SuperSpeed Plus Gen 2x1 USB device number 7 using xhci_hcd >>>> [ +0.024064] scsi host7: uas >>>> [ +16.365880] scsi 7:0:0:0: Direct-Access ST12000N M001G-2MV103 SB2D PQ: 0 ANSI: 6 >>>> [ +0.001192] sd 7:0:0:0: Attached scsi generic sg1 type 0 >>>> [ +0.000940] sd 7:0:0:0: [sde] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB) >>>> [ +0.000130] sd 7:0:0:0: [sde] Write Protect is off >>>> [ +0.000001] sd 7:0:0:0: [sde] Mode Sense: 2f 00 00 00 >>>> [ +0.000265] sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >>>> [ +0.000399] sd 7:0:0:0: [sde] Optimal transfer size 268431360 bytes >>>> [ +0.120240] sd 7:0:0:0: [sde] Attached SCSI disk >>> And then the drive reconnected, this time successfully. How does this >>> show that UAS was the reason for the problem? Indeed, how does this >>> show there was any problem at all? >>> >>>> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> >>>> --- >>>> drivers/usb/storage/unusual_uas.h | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h >>>> index bda0f2cdf093..7d83ecf835c6 100644 >>>> --- a/drivers/usb/storage/unusual_uas.h >>>> +++ b/drivers/usb/storage/unusual_uas.h >>>> @@ -125,6 +125,13 @@ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999, >>>> USB_SC_DEVICE, USB_PR_DEVICE, NULL, >>>> US_FL_NO_ATA_1X), >>>> +/* Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> */ >>>> +UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999, >>>> + "VIA", >>>> + "VL817", >>>> + USB_SC_DEVICE, USB_PR_DEVICE, NULL, >>>> + US_FL_IGNORE_UAS), >>>> + >>>> /* Reported-by: Icenowy Zheng <icenowy@aosc.io> */ >>>> UNUSUAL_DEV(0x2537, 0x1068, 0x0000, 0x9999, >>>> "Norelsys", >>> Instead of IGNORE_UAS, have you tried the NO_ATA_1X flag, which seems to >>> help in the preceding entry (a different device from the same vendor)? >>> >>> Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-26 18:14 ` Tobias Jakobi @ 2021-09-27 15:04 ` Alan Stern 2021-10-01 20:36 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Alan Stern @ 2021-09-27 15:04 UTC (permalink / raw) To: Tobias Jakobi; +Cc: Tobias Jakobi, gregkh, linux-usb On Sun, Sep 26, 2021 at 08:14:46PM +0200, Tobias Jakobi wrote: > Hello Alan, > > On 9/21/21 6:42 PM, Alan Stern wrote: > > On Tue, Sep 21, 2021 at 06:06:45PM +0200, Tobias Jakobi wrote: > > > Hi Alan, > > > > > > sorry but your analysis of the log is wrong. Nothing was disconnected or > > > unplugged when the device behaves this way. The enclosure is connected to > > > the power the entire time, and the same applies to the physical USB > > > connection to my system. > > That may be so, but if it is then the log extract you included with the > > patch is very misleading. For instance, you didn't include any part of > > the log before and leading up to the line saying "usb 2-1.2: USB > > disconnect, device number 4". Thus there is no way for the reader to > > tell what caused this event, whether it was a physical unplug or not. > > I included the part of the kernel log which shows how the issue manifests > itself. Do you think I'm so stupid as to believe I could prevent a physical > unplug of the enclosure by blacklisting UAS? Really, this is getting > ridiculous... No, I don't believe that. However, I do believe you are so stupid as to post a patch with a description that does not justify it and includes a lot of irrelevant details. (Hey, you brought up the issue of how stupid you are! :-) > > > To make things very clear: This happens in under five minutes after having > > > powered up the enclosure and starting a file transfer to the installed RAID. > > > After blacklisting UASP the enclosure works perfectly fine for hours. I hope > > > this clears things up. > > You didn't answer my question about using NO_ATA_1X instead of > > IGNORE_UAS. This is a perfect example of one of the dangers of > > top-posting -- it makes it far too easy for people to miss important > > points in the email they are replying to. (Hint: Don't top-post!) > > I did not answer this question, because I didn't have the answer to it yet. > I have tested your suggestion today, but sadly I'm running into the same > type of problem with NO_ATA_1X. You can find the complete kernel log here: > https://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg_VL817.log Good, thank you. Unfortunately the log doesn't include any smoking guns pointing to an underlying cause. > The RAID1 is broken after such an event. > > With best wishes, > Tobias > > > > > > Alan Stern > > > > > With best wishes, > > > Tobias > > > > > > On 9/21/21 5:13 PM, Alan Stern wrote: > > > > On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: > > > > > The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure > > > > > is advertised as having UASP support, but appears to have problems with 4Kn > > > > > drives (test was done with two Seagate Exos X, 12TB). > > > > > > > > > > Disable UAS for the VL817 as it behaves highly unstable: I still have to wonder if the enclosure works okay with other types of disk drive. And if it doesn't, why don't these errors show up on Windows systems? Or on other VIA enclosures? That's why I'm cautious about accepting this patch. I don't want to slow down unnecessarily a bunch of USB disks that could work just fine at the higher UAS transfer rates. By the way, does the enclosure have its own power source, or does it rely entirely on power provided over the USB cable? Note that UAS can use more power than the older mass-storage protocols, because it queues more operations in rapid succession (which is also why it runs faster). Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-09-27 15:04 ` Alan Stern @ 2021-10-01 20:36 ` Tobias Jakobi 2021-10-02 14:54 ` Alan Stern 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2021-10-01 20:36 UTC (permalink / raw) To: Alan Stern; +Cc: Tobias Jakobi, gregkh, linux-usb On 9/27/21 5:04 PM, Alan Stern wrote: > On Sun, Sep 26, 2021 at 08:14:46PM +0200, Tobias Jakobi wrote: >> Hello Alan, >> >> On 9/21/21 6:42 PM, Alan Stern wrote: >>> On Tue, Sep 21, 2021 at 06:06:45PM +0200, Tobias Jakobi wrote: >>>> Hi Alan, >>>> >>>> sorry but your analysis of the log is wrong. Nothing was disconnected or >>>> unplugged when the device behaves this way. The enclosure is connected to >>>> the power the entire time, and the same applies to the physical USB >>>> connection to my system. >>> That may be so, but if it is then the log extract you included with the >>> patch is very misleading. For instance, you didn't include any part of >>> the log before and leading up to the line saying "usb 2-1.2: USB >>> disconnect, device number 4". Thus there is no way for the reader to >>> tell what caused this event, whether it was a physical unplug or not. >> I included the part of the kernel log which shows how the issue manifests >> itself. Do you think I'm so stupid as to believe I could prevent a physical >> unplug of the enclosure by blacklisting UAS? Really, this is getting >> ridiculous... > No, I don't believe that. However, I do believe you are so stupid as > to post a patch with a description that does not justify it and > includes a lot of irrelevant details. (Hey, you brought up the issue > of how stupid you are! :-) > >>>> To make things very clear: This happens in under five minutes after having >>>> powered up the enclosure and starting a file transfer to the installed RAID. >>>> After blacklisting UASP the enclosure works perfectly fine for hours. I hope >>>> this clears things up. >>> You didn't answer my question about using NO_ATA_1X instead of >>> IGNORE_UAS. This is a perfect example of one of the dangers of >>> top-posting -- it makes it far too easy for people to miss important >>> points in the email they are replying to. (Hint: Don't top-post!) >> I did not answer this question, because I didn't have the answer to it yet. >> I have tested your suggestion today, but sadly I'm running into the same >> type of problem with NO_ATA_1X. You can find the complete kernel log here: >> https://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg_VL817.log > Good, thank you. Unfortunately the log doesn't include any smoking > guns pointing to an underlying cause. I'm open to suggestions regarding identifying the cause. As you might guess, I'm also not happy that I had to disable UAS for the enclosure -- in particular since I selected this particular product because it was advertised with having support. > >> The RAID1 is broken after such an event. >> >> With best wishes, >> Tobias >> >> >>> Alan Stern >>> >>>> With best wishes, >>>> Tobias >>>> >>>> On 9/21/21 5:13 PM, Alan Stern wrote: >>>>> On Tue, Sep 21, 2021 at 12:17:52PM +0200, Tobias Jakobi wrote: >>>>>> The VL817 is used in the RaidSonic Icy Box IB-3740-C31 enclosure. The enclosure >>>>>> is advertised as having UASP support, but appears to have problems with 4Kn >>>>>> drives (test was done with two Seagate Exos X, 12TB). >>>>>> >>>>>> Disable UAS for the VL817 as it behaves highly unstable: > I still have to wonder if the enclosure works okay with other types of > disk drive. And if it doesn't, why don't these errors show up on > Windows systems? Or on other VIA enclosures? I only experienced this after installing the two 4Kn drives, never with the two 512e drives that were installed first. My guess is that 4Kn drives are still rare and if they're used, then natively attached to a SATA port. I don't have any Windows system here to test this, and even if, I wouldn't know how to assemble the RAID1 there anyway. > That's why I'm cautious about accepting this patch. I don't want to > slow down unnecessarily a bunch of USB disks that could work just fine > at the higher UAS transfer rates. I understand. If that's the case, I'm just going to continue to keep the patch in my local kernel tree. > > By the way, does the enclosure have its own power source, or does it > rely entirely on power provided over the USB cable? Note that UAS can > use more power than the older mass-storage protocols, because it queues > more operations in rapid succession (which is also why it runs faster). This is the enclosure: https://icybox.de/product.php?id=155 It has a external power supply (quite a bulky one) and it does not work without it. So it doesn't draw anything (significant) from the USB cable. I first also suspected this to be a power supply related problem, but I discarded that idea since the whole thing works as MSC. I can't imagine the power draw to be so much different for UAS, but maybe I'm just naive there. With best wishes, Tobias > > Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge 2021-10-01 20:36 ` Tobias Jakobi @ 2021-10-02 14:54 ` Alan Stern 0 siblings, 0 replies; 8+ messages in thread From: Alan Stern @ 2021-10-02 14:54 UTC (permalink / raw) To: Tobias Jakobi; +Cc: Tobias Jakobi, gregkh, linux-usb On Fri, Oct 01, 2021 at 10:36:59PM +0200, Tobias Jakobi wrote: > On 9/27/21 5:04 PM, Alan Stern wrote: > > > Good, thank you. Unfortunately the log doesn't include any smoking > > guns pointing to an underlying cause. > > I'm open to suggestions regarding identifying the cause. As you might > guess, I'm also not happy that I had to disable UAS for the enclosure -- in > particular since I selected this particular product because it was > advertised with having support. One thing you might try is to capture a usbmon trace showing what happens, starting from when the USB cable is attached up to the point when the failure occurs. However, I'm doubtful that the trace will show anything useful, since the kernel log indicated that the first failed command was an ordinary write. > > I still have to wonder if the enclosure works okay with other types of > > disk drive. And if it doesn't, why don't these errors show up on > > Windows systems? Or on other VIA enclosures? > > I only experienced this after installing the two 4Kn drives, never with the > two 512e drives that were installed first. My guess is that 4Kn drives are > still rare and if they're used, then natively attached to a SATA port. I > don't have any Windows system here to test this, and even if, I wouldn't > know how to assemble the RAID1 there anyway. It's entirely possible that this failure has nothing to do with the use of RAID. > > That's why I'm cautious about accepting this patch. I don't want to > > slow down unnecessarily a bunch of USB disks that could work just fine > > at the higher UAS transfer rates. > > I understand. If that's the case, I'm just going to continue to keep the > patch in my local kernel tree. You don't even need a patch; you can accomplish the same effect simply by specifying a module parameter for usb-storage: quirks=2109:0715:u (You might have to rebuild your initramfs image, if you need the quirk to take effect during the early stages of boot-up.) > > By the way, does the enclosure have its own power source, or does it > > rely entirely on power provided over the USB cable? Note that UAS can > > use more power than the older mass-storage protocols, because it queues > > more operations in rapid succession (which is also why it runs faster). > > This is the enclosure: > https://icybox.de/product.php?id=155 > > It has a external power supply (quite a bulky one) and it does not work > without it. So it doesn't draw anything (significant) from the USB cable. I > first also suspected this to be a power supply related problem, but I > discarded that idea since the whole thing works as MSC. I can't imagine the > power draw to be so much different for UAS, but maybe I'm just naive there. Yeah, you might be surprised. There have been other instances of people submitting patches to disable UAS for their drives, when it seemed quite likely that lack of power was the underlying cause. Although to be fair, these occurred in very power-constrained situations, such as running a bus-powered drive attached to a Raspberry Pi. Not like your case. Still, you see why I had to ask. Alan Stern ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-02 14:54 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-21 10:17 [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge Tobias Jakobi 2021-09-21 15:13 ` Alan Stern 2021-09-21 16:06 ` Tobias Jakobi 2021-09-21 16:42 ` Alan Stern 2021-09-26 18:14 ` Tobias Jakobi 2021-09-27 15:04 ` Alan Stern 2021-10-01 20:36 ` Tobias Jakobi 2021-10-02 14:54 ` Alan Stern
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.