On Sat, 28 May 2005, Martin Diehl wrote: > > 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.
Is it? I've never looked into the details of dma_map'ing, but I would have expected it to get the correct physical address from the page tables rather than assuming a constant PAGE_OFFSET mapping. We live and learn... > 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. Yes. Another danger, which I didn't mention before, is that if you're doing an IN transfer and you use an incorrect DMA address, some innocent region of memory will get clobbered. That could corrupt the kernel, but it's unlikely to affect the host controller (unless the region contains a QH or TD!). > > 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... You're almost certainly correct about the OP's problem. And it's good to discuss these things and find out about strange nooks and crannies in the kernel. 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
