On Wed, 25 May 2005, Martin Diehl wrote: > On Tue, 24 May 2005, Alan Stern wrote: > > > On x86 it won't make any difference, but for other architectures it's an > > important distinction. The host controller might try to access locations > > not present or not mapped to physical RAM, which would cause the sort of > > errors you saw. > > Well, IMHO one doesn't need an iommu-arch to run into trouble with > invalid busmastering buffer, it's just less "silent" there ;-)
Very true... > FWIW, it did happen for me (long ago around 2.4.20) on i86 with UHCI > hardware - probably the Intel PIIX4 one, but might have been Via as well. > And I'm not sure whether it was usb-uhci or uhci(JE) or both. Exactly this > "HC halted, very bad" error triggered by a static buffer: reproducible - > and it disappeared after switching to kmalloc. > > IIRC the stack is not guaranteed to be mapped from physically continous > pages, even on i86 (strictly speaking, it might be with 2.6 and 4KSTACKS). > Not sure about bss/data sections. I'm not sure how that sort of thing could cause this type of problem. So long as the DMA address passed to the controller for the data buffer (as opposed to the TD) corresponds to actual physical memory accessible to a PCI busmaster, it doesn't really matter what data is stored in those memory locations. If part of the buffer was at the end of a stack page and the rest belonged to some random page that happened to be physically adjacent, things wouldn't work right but the controller wouldn't halt. On x86 the DMA address is the same as the physical address. So stack-based and static buffers should still give rise to valid DMA addresses. That's why these errors are so hard to catch when using regular Intel PCs. > And unless I missed something, the > coherency provision on i86 arch wouldn't help if a mapped buffer shared a > cacheline with memory accessed by the cpu. If both were writing to the > same place, snooping is not enough - it would need merging with > sub-cacheline resolution. Again, that shouldn't matter. The controller would read or write incorrect data, but it wouldn't halt with an exception. > Btw, do you know whether the "HC halted" thing is caused by a signaled PCI > error (like target abort) or due to the HC succesfully fetching (according > to the PCI transaction) an invalid TD? Either one can cause it, according to the spec. However, if the HCD is working correctly then the TD will always be valid and properly allocated, even though the DMA address it contains for the data buffer might be wrong. TDs are stored in a DMA-consistent memory pool. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
