Re: Oops with dwc3 in device mode and functionfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 6 Jan 2017 15:21:17 +0000, Vincent Pelletier
<plr.vincent@xxxxxxxxx> wrote:
> The next issue is that often (>9 times out of 10) the dwc3 fails to
> respond to the SET_CONFIGURATION standard request. As a result, only
> EP0 works.

I captured a successful enumeration, there are also corrupted pids:

002:03.271'422"583n SETUP   @054.00 DATA0     8B ACK
                    000 80 06 03 03 09 04 ff 00                          ........
002:03.271'425"200n IN      @054.00 NAK
002:03.271'446"233n IN      @054.00 NAK
002:03.271'478"233n IN      @054.00 NAK
002:03.271'499"233n IN      @054.00 DATA1    34B ACK
                    000 22 03 46 00 5a 00 45 00  44 00 34 00 34 00 33 00 ..F.Z.E.D.4.4.3.
                    010 44 00 30 00 31 00 54 00  34 00 32 00 35 00 30 00 D.0.1.T.4.2.5.0.
                    020 31 00                                            1.
002:03.271'502"133n OUT     @054.00 DATA1     0B NAK
002:03.271'523"216n PING    @054.00 NAK
002:03.271'556"233n PING    @054.00 NAK
002:03.271'581"666n PING    @054.00 ACK
002:03.271'583"050n OUT     @054.00 DATA1     0B ACK
002:03.272'345"833n SETUP   @054.00 DATA0     8B ACK
                    000 00 09 01 00 00 00 00 00                          ........
002:03.272'348"350n IN      @054.00 NAK
002:03.272'369"350n IN      @054.00 NAK
[...]
002:03.273'082"100n IN      @054.00 NAK
002:03.273'119"633n (bad pid) 0xf0 0x3e 0x88
002:03.273'103"450n IN      @054.00 NAK     (incomplete transaction)
002:03.273'123"333n (bad pid) 0xf0 0x3e 0x88
002:03.273'127"033n (bad pid) 0xf0 0x3e 0x88
002:03.273'145"450n IN      @054.00 NAK
002:03.273'166"466n IN      @054.00 NAK
[...]
002:03.278'582"600n IN      @054.00 NAK
002:03.278'604"200n IN      @054.00 DATA1     0B ACK

There are 285 NAKs between SETUP and the final ACK.

A note about "incomplete transaction": this is a bug in my trace
parser, the NAK transaction is complete, it is the next token (the bad
pid) which confuses the state tracker, which also causes the
timestamp non-monotonicity in parser's output too. There is one bad-CRC
DATA0 packet after each bad pid.

> There seems to be another issue (or is it just a consequence of this
> one ?) where it may become completely silent, unable to join the bus
> when udc identifier is written to UDC file.

>From what I can reproduce, it always happens in 3 stages:
- first enumeration (whether SET_CONFIGURATION succeeds or not seems
  irrelevant)
- second enumeration, which SET_CONFIGURATION always times-out in my
  experience (but given the low success rate, having two consecutive
  successes would be hard anyway)
- 3rd enumeration attempt fails, no event on the bus.
-- 
Vincent Pelletier
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux