Re: [PATCH] usb: storage: add quirks for VIA VL817 USB3-SATA bridge

[Tobias Jakobi <tjakobi@xxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > >    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@xxxxxxxxxxxxxxxxxxxxx> */
> > > > +UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999,
> > > > +		"VIA",
> > > > +		"VL817",
> > > > +		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> > > > +		US_FL_IGNORE_UAS),
> > > > +
> > > >    /* Reported-by: Icenowy Zheng <icenowy@xxxxxxx> */
> > > >    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