[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e67f96d-250a-4ee1-9f2c-ad321fa50fdc@rowland.harvard.edu>
Date: Fri, 1 Sep 2023 13:37:28 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: Andrey Konovalov <andreyknvl@...il.com>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
USB list <linux-usb@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: dwc3: unusual handling of setup requests with wLength == 0
On Fri, Sep 01, 2023 at 01:27:34AM +0000, Thinh Nguyen wrote:
> > Does Windows really work this way? Does it not send a task management
> > request? That would definitely seem to be against the intent of the
> > spec, if not against the letter.
>
> Unfortunately yes, I don't see any Task Management request aborting the
> transfer.
Is it possible that the packets are there but you don't see them because
of the filtering or data presentation done by the USB analyzer?
> Here's a snippet captured at the SCSI level from Samsung T7 device
> response to CLEAR_FEATURE(halt-ep) to IN data endpoint from host
> (Windows 10). Similar behavior is observed for OUT endpoint.
Hmmm. The SCSI level may not provide enough detail.
> _______|_______________________________________________________________________
> SCSI Op(80) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928E800) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.335 ms) Time Stamp(10 . 000 538 006) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(81) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928EC00) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.318 ms) Time Stamp(10 . 001 872 988) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(82) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928F000) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.343 ms) Time Stamp(10 . 003 191 188) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(83) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928F400) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.256 ms) Time Stamp(10 . 004 534 630) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(84) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928F800) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.178 ms) Time Stamp(10 . 005 791 128) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(85) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928FC00) Data(146432 bytes) Status(Missing)-BAD
> _______| Time( 2.681 ms) Time Stamp(10 . 006 968 662) Metrics #Xfers(2)
> _______|_______________________________________________________________________
>
>
> ## Transaction eror occurs here.
>
> Transfer(289) Left("Left") G2(x1) Control(SET) ADDR(3) ENDP(0)
> _______| bRequest(CLEAR_FEATURE) wValue(ENDPOINT_HALT) wLength(0)
> _______| Time(166.322 us) Time Stamp(10 . 009 649 516)
> _______|_______________________________________________________________________
>
> ## CLEAR_FEATURE happens here.
>
> SCSI Op(99) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09290000) RESPONSE_CODE(OVERLAPPED TAG)
> _______| Time(365.854 us) Time Stamp(10 . 009 815 838) Metrics #Xfers(2)
> _______|_______________________________________________________________________
> SCSI Op(100) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09290400) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.012 sec) Time Stamp(10 . 010 181 692) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(101) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x0928FC00) STATUS(GOOD) Data(524288 bytes)
> _______| Time(882.412 us) Time Stamp(11 . 022 469 104) Metrics #Xfers(3)
> _______|_______________________________________________________________________
>
> ## Host retries transfer here. Check logical block address.
>
> SCSI Op(102) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09290000) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.060 ms) Time Stamp(11 . 023 351 516) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(103) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09290800) STATUS(GOOD) Data(524288 bytes)
> _______| Time( 1.013 ms) Time Stamp(11 . 024 411 510) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(104) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09290C00) STATUS(GOOD) Data(524288 bytes)
> _______| Time(816.594 us) Time Stamp(11 . 025 424 600) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(105) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09291000) STATUS(GOOD) Data(524288 bytes)
> _______| Time(762.286 us) Time Stamp(11 . 026 241 194) Metrics #Xfers(3)
> _______|_______________________________________________________________________
> SCSI Op(106) ADDR(3) Tag(0x0002) SCSI CDB READ(10)
> _______| Logical Block Addr(0x09291400) STATUS(GOOD) Data(524288 bytes)
> _______| Time(768.696 us) Time Stamp(11 . 027 003 480) Metrics #Xfers(3)
> _______|_______________________________________________________________________
Is is possible to show all the data packets (not the token or
handshaking ones) for both the command and status endpoints? I'm
particularly interested in seeing what sort of status message the device
sends for the failed command, and where it occurs in relation to the
other transfers.
I wouldn't mind seeing a summary of the packets on the data-IN endpoint
as well. Not a detailed view -- multiple 500-KB transfers aren't very
interesting -- but just to see what happens in the vicinity of the
transaction error.
Alan Stern
Powered by blists - more mailing lists