dwc_otg: driver does not handle data toggle errors on SPLIT transactions

[P33M]

Hello (again)

A culmination of a number of threads/random crashes reported by users all have a constant undercurrent:
#195

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=16280
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=8010&hilit=serial+toggle

There are two main themes here -

1. a broken USB device (FT232BM/BL / FT8U232 / various other wierd and wonderful ones) consistently causes the Pi to lock up if the device is accessed
2. sporadic crashes are reported after days or weeks of use with otherwise functional devices

The constant factor with both of these is that the devices are full-speed plugged into a high-speed hub, be it the model B ports or a downstream hub. The crash is caused by a data toggle error condition existing either due to the broken USB device sending one with the wrong PID, or due to genuine variations in the aether causing a device to drop a packet.

I have a FT232BL device and the Pi locks up as a result of a usb_control_msg which is sent on opening the serial port in any garden variety terminal emulator. It works perfectly well if the speed is either forced to Full via command line parameter or via being plugged into a model A directly.

If a data toggle error occurs when the device is behind a transaction translator, it appears that the HC gets halted with the datatglerr interrupt bit set. The driver currently does not handle this at all well and goes into an infinite loop. The relevant interrupt handler is not called from handle_hc_chhltd_intr_dma.

The data toggle error interrupt handler as it currently exists is basically a stub, and does nothing but disable the interrupt. For a split transaction, I think the correct recovery is to restart the split and flip the expected data toggle bit in the HC's register.

[ghollingworth]

Might be best to leave this to me since I'm changing split transactions so
significantly

Gordon

On Saturday, 2 March 2013, P33M wrote:

Hello (again)

A culmination of a number of threads/random crashes reported by users all
have a constant undercurrent:

#195 #195
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=16280

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=8010&hilit=serial+toggle

There are two main themes here -

1. a broken USB device (FT232BM/BL / FT8U232 / various other wierd and
   wonderful ones) consistently causes the Pi to lock up if the device is
   accessed
2. sporadic crashes are reported after days or weeks of use with otherwise
   functional devices

The constant factor with both of these is that the devices are full-speed
plugged into a high-speed hub, be it the model B ports or a downstream hub.
The crash is caused by a data toggle error condition existing either due to
the broken USB device sending one with the wrong PID, or due to genuine
variations in the aether causing a device to drop a packet.

I have a FT232BL device and the Pi locks up as a result of a
usb_control_msg which is sent on opening the serial port in any garden
variety terminal emulator. It works perfectly well if the speed is either
forced to Full via command line parameter or via being plugged into a model
A directly.

If a data toggle error occurs when the device is behind a transaction
translator, it appears that the HC gets halted with the datatglerr
interrupt bit set. The driver currently does not handle this at all well
and goes into an infinite loop. The relevant interrupt handler is not
called from handle_hc_chhltd_intr_dma.

The data toggle error interrupt handler as it currently exists is
basically a stub, and does nothing but disable the interrupt. For a split
transaction, I think the correct recovery is to restart the split and flip
the expected data toggle bit in the HC's register.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/241
.

[P33M]

Well I have done a basic fix - add the requisite interrupt handling in handle_chhltd_intr_dma and perform steps equivalent to a xacterr channel halt - it will serve as a retry mechanism for up to 3 transfer attempts, which is enough for both control and bulk transfers to sort themselves out.

Note that the data toggle "error" is also used to reset the QTD error count for non-split IN transfers as per previous investigation into #217 - patch leaves this functionality unaltered.

With this patch, my FT232BL now works! This device evidently powers on with its data PID counters in the wrong state - on the first access I get a toggle error for both control and bulk IN endpoints but subsequently all other transfers complete fine.

[ghollingworth]

Excellent,

I've recently got most of my FIQ code scheduling the split transactions,
which depending upon how long the tail of random interactions between
differrent ports / hubs is means we should be close to getting a proper
solution...

Gordon

On 3 March 2013 15:02, P33M notifications@github.com wrote:

Well I have done a basic fix - add the requisite interrupt handling in
handle_chhltd_intr_dma and perform steps equivalent to a xacterr channel
halt - it will serve as a retry mechanism for up to 3 transfer attempts,
which is enough for both control and bulk transfers to sort themselves out.

Note that the data toggle "error" is also used to reset the QTD error
count for non-split IN transfers as per previous investigation into #217https://github.com/raspberrypi/linux/issues/217\- patch leaves this functionality unaltered.

With this patch, my FT232BL now works! This device evidently powers on
with its data PID counters in the wrong state - on the first access I get a
toggle error for both control and bulk IN endpoints but subsequently all
other transfers complete fine.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/241#issuecomment-14348104
.

[P33M]

Closing issue: positive noises on the forum about the patch.