On Fri, 12 Aug 2011, Andiry Xu wrote: > Hi Sarah, > > I'm debugging a Missed Service Error event related these days. It's > cause by some buggy HW behavior, which falsely return a overrun event > following a MSE event, while the ep ring is actually not empty. > > Currently xhci driver handles MSE event in the following ways: > > 1. When encounter a MSE event, set ep->skip flag, update event ring > dequeue pointer and return. > > 2. When encounter the next event on this ep, the driver will run the > do-while loop, fetch td from ep's td_list to find the td corresponding > to this event. All tds missed are marked as short transfer(-EXDEV). > > The do-while loop will end in two ways: > 1. If the td pointed by the event trb is found; > 2. If the ep ring's td_list is empty. > > If the next event is a overrun event, the driver will never find the td, > and it will loop until the td_list is empty. > > Unfortunately, the spinlock is dropped when give back a urb in the > do-while loop. During the spinlock released period, there are urbs > submitted and tds added to the td_list. This causes disaster, since the > td_list will never be empty and the loop never ends, and the system > hangs. > > There is workaround for this, only run the loop if the event points to a > valid td, so there is guarantee the loop will end at some point. > However, this is not acceptable. If there is only several TDs left > on the ring, and a MSE event occurs and the HW just skip all the TDs. > There is no valid event following the MSE event, only a overrun/underrun > event occurs. In this case driver must process all the tds. This issue > is caused by wrong HW behavior, but I don't want an infinite loop and > system hang in this case. > > Do you have any suggestions on MSE event handling? Count the number of TDs on the ring when the MSE event occurs. When skipping, don't skip more than that number. Alan Stern -- 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
