On 8.12.2020 19.24, Ross Zwisler wrote: > On Fri, Dec 04, 2020 at 08:07:30PM +0200, Mathias Nyman wrote: > <> > > Here are some logs when running with that commit: > > https://gist.github.com/rzwisler/17923c9dedf2b914254eadd1cd294a4c > > I think we only consistently get the clean failure case with the dequeue > pointer being 0 if CONFIG_INTEL_IOMMU_DEFAULT_ON=y. > > If that option is set to 'n', we get the same failure where the xHCI > controller totally dies (log "CONFIG_INTEL_IOMMU_DEFAULT_ON=n" in the gist). > > With CONFIG_INTEL_IOMMU_DEFAULT_ON=y we do seem to live through multiple > errors, but as soon as I try to use the device normally afterwards it seems to > spin forever with these messages: > > xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fff0a330 trb-start 00000000f8884000 trb-end 0000000000000000 seg-start 00000000f8884000 seg-end 00000000f8884ff0 > > Are you able to reproduce this with Andrzej's bulk-cancel script? I think you > probably just need a device which accepts bulk transfer commands? In my most > recent reproductions my servo hardware wasn't even attached to a device, so I > don't really think it's doing anything except sitting there and receiving > BULK_IN commands. I'm doing this to two devices simultaneously. > I was testing with Andrzej's script against a g_zero gadget. I could trigger many similar issues as those he reported, but not this dequeue issue you see. The rewrite resolved all issues I saw. Script was running without issues over night. (tested against both USB2 and USB3). I haven't tried with two devices simultaneously, I could try that. Could you share more details about the system you have, what xhci controller do you have? Thanks -Mathias
