in dwc_otg_hcd_handle_hc_fsm() the FIQ_NP_SPLIT_LS_ABORTED case calls BUG() when only hcint.b.chhltd is set

[bogardusj]

Under similar conditions to those that sometimes produce the problem in #830, I sometimes encounter another oops. Sometimes dwc_otg_hcd_handle_hc_fsm() gets into the FIQ_NP_SPLIT_LS_ABORTED case with only hcint.b.chhltd set. That condition isn't handled, so all the if()s fail and it hits the BUG(). Based on the printk()s I've added, the FIQ_NP_SPLIT_LS_ABORTED case usually has both the "chhltd" and "stall" fields set, which results in the hcint.b.stall condition being met. I don't know why only chhltd is being set sometimes or what the appropriate way to handle it is.

I have encountered it on kernels 4.1.19-v7+ and 4.4.11-v7+ (built from git; with some extra printks). I have encountered it with various combinations of USB devices, but for me it seems to require 2 USB cameras (tried with multiple UVC and Playstation Eye cameras) and a custom pic24 based full-speed USB device. Throwing in continuous reads of an old, full-speed USB flash drive seems to help it occur more quickly.

lsusb.txt

[P33M]

This is probably one of the cases where the core's actual behaviour doesn't correspond to the documented behaviour.

If a DMA-enabled channel is halted, then the coincident bit should also be set stating the reason for the halt. There are some exceptions that I've found where this "sometimes" doesn't occur - namely if the root port is disabled or suspended then all channels get a halt which may or may not have another bit set.

I would note that you're probably pushing the OTG core far in excess of what it's generally advisable to do - multiple split-transaction endpoints can cause issues due to the oddball way that periodic and non-periodic transfers are scheduled by the hardware. You could be getting into a state where a non-periodic split transfer gets no bandwidth due to earlier scheduling of periodic split transfers. This case isn't documented in the databook (so I assume it doesn't play well).

[P33M]

Fixed in #2010

[popcornmix]

rpi-update firmware contains latest kernel fixes. Please update and test.