Messages in this thread | | | Date | Fri, 2 Mar 2012 13:17:07 -0800 | Subject | Re: [Pkg-xen-devel] ioatdma: Boot process hangs then reboots when using Xen + Linux 3.2 | From | Dan Williams <> |
| |
On Fri, Mar 2, 2012 at 12:56 PM, Bastian Blank <waldi@debian.org> wrote: > On Fri, Mar 02, 2012 at 12:16:47PM -0800, Dan Williams wrote: >> On Fri, Mar 2, 2012 at 12:08 PM, Bastian Blank <waldi@debian.org> wrote: >> > On Fri, Mar 02, 2012 at 11:31:56AM -0800, Dan Williams wrote: >> >> On Fri, Mar 2, 2012 at 9:57 AM, Bastian Blank <waldi@debian.org> wrote: >> >> > phys_complete (a 32 bit value) gets compared to struct >> >> > dma_async_tx_descriptor.phys, which is defined as dma_addr_t, a _64_ bit >> >> > value. >> >> The assumption is that the driver's control structures are not in high >> >> memory so all address values will only have 32-bits of valid data, >> > Can you back that up by some kernel documentation? There is a reason why >> > pci_alloc_pool uses dma_addr_t to store the address and _not_ unsigned >> > long. This are physical addresses, nothing the kernel can access >> > directly without a mapping. >> High memory can only be accessed with kmap(), so the assumption is >> that dma_alloc never gives a buffer address above 32-bits on a 32-bit >> build. Yes, if HIGHMEM64G is set dma_addr_t becomes 64-bit, but that >> is only to access high memory mapped application buffers via dma_map. > > All memory needs to be mapped. Linux just have a default mapping of 1GiB > of the memory handy. However this is irrelevant for the physical DMA > addresses we talk about.
I'm not sure you understand how himem works or we're talking past each other. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |