Re: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK

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

 



Hi Andreas,

Kasberger Andreas wrote:
> XHCI Host Controller on Intel Panther Point with CDC/ACM dead after
> massive NAK
> PCH 82HM76 (PantherPoint) chipset connect with  a Renesas RX621
> How to reproduce :
> No Reader on device /dev/ttyACM0 connected
> Writer will send in endless loop always same command
> : echo "readhik">/dev/ttyACM0
> 
> Function: Renesas RX621 will receive command, put into a internal
> queue and it is waiting for reader. As long reader is comming it
> will stored in the queue. If command has reached time out the
> command will removed from queue. If queue is full every command
> will be answered with NAK
> 
> The response will be nearly always with NAK because nobody will
> read from /dev/ttyACM0
> 
> After some time ( between seconds and several hours ) the host
> controller will not send anything to the device connected on
> Renesas RX621. 
> We proven this with a analyzer directly on the bus. Other devices
> connect to host controller are still alive and working.

I'm sorry, but this protocol design is rather broken use of USB.

That said, the HC must certainly be more robust in dealing with it.


On the protocol design:

First, using CDC-ACM means sacrificing all structured communication
offered by the USB packet bus and settling for such primitive use of
USB is not a decision that should be made lightly. Almost all
applications can benefit quite significantly both in end-user
usability and in ease of implementation from an application-specific
protocol which takes advantage of what USB offers.

Application-specific or vendor-specific are often frowned upon in
other contexts but if the protocol is documented publically then it
is a great way to take advantage of all that USB offers, and it is
explicitly supported by the specification. Use bDeviceClass or
bInterfaceClass 0xff.


But more importantly, regardless of the application protocol, with
USB it is the absolute and complete responsibility of the host-side
software to communicate with the device only *exactly* in the way
that the device supports.

You mention device-side buffering and that the device at some point
can't accept anything more from the host. With USB this means that
you must ensure that the host will know when it must not send more.

The USB way to do this, were you using an application-specific
protocol instead of serial port simulation, would be to stall the
endpoint. Unfortunately CDC-ACM doesn't allow doing that.

So you have to include some kind of in-band signalling for this. :\

This is just one reason why ACM is a poor choice for when you need
structured communication.


//Peter
--
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