On Fri, 27 May 2005, Alan Stern wrote: > > 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.
Agreed. > 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. FWIW, I've just tried to printk virtual and busmapped addresses of different memory locations. It looks like memory on the stack is mapped similarly to kmalloc, i.e. the PAGE_OFFSET conversion still holds. However static bss/data memory is mapped like vmalloc() on top of the physical memory mapping in virtual address space - i.e. some "static char buf[100]" (file scope) appears at virtual address above PAGE_OFFSET + physical_memory_size! This means trying to dma_map such an address is *guaranteed* to point to nonexistent physical memory. My conclusion is, an (invalid) dma buffer on the stack will probably work on i86 anyway as you said. However, static buffers do trigger the HC to issue function-to-memory cycles targeting beyond physical memory - thus probably leading to pci errors and thus the HC-halted thing. > On x86 the DMA address is the same as the physical address. So Yep. > 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. See above. > > 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. Ok, for data buffer yes. I was thinking about TDs, but as you say they are in consistent memory, beyond driver (non-HCD) author mistakes ;-) > > 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. Ok, Thanks. > 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. Ok, you are right, the TD/QHs are in consistent memory. So we are talking about the data buffer only. Let's see if fixing them solves the OP's problem. It's clear, static or stack memory locations are invalid regardless. I was just trying to understand why it did trigger the HC-halted error once when I made this mistake... Martin ------------------------------------------------------- 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
