From: Mathias Nyman > Sent: 11 October 2017 15:41 .. > If possible I'd like to try and find some other solution before chopping the Segment > size to smaller than 256. > I think that your first proposal of adding the guard page to the segment pool could be an option. Would be a waste of a page - which could be used for a lot of extra TRB. IIRC the rings used to have 16 TRB - that caused some serious problems, but I can't quite remember all of them. I don't remember anything that made 256 'good' - except that it was a 4k page. Did you add something to copy badly fragmented buffers to get around the problem with misaligned LINKs. ISTR my original fix didn't work for requests for very long disk transfers. > other things that could be checked: > - check if we can avoid prefetching over segment by altering the link TRB chain or ioc bits. > - check if we prefetch only over mid-ring link TRBs or also over last link TRB with cycle change. > If only mid ring then we could try to allocate two consecutive pages for the segments. > - check if prefething over segment is related to manually setting the TR dequeue command. > Set TR deq ponter command fushes xHC chached TRBs and might be the cause for the prefetch. I'd guess that it is reading multiple TRB and can't know one is a LINK. > - does VIA VL805 have some odd xhci page size (xhci PAGEZISE register), does it affect anything. It is 'funny' that this device will try to prefetch TRB across 64k boundaries but data buffers aren't allowed to cross them. David -- 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
