logo       

Re: x86_64: 2.6.14-rc4 swiotlb broken: msg#00092

linux.ports.x86-64.general

Subject: Re: x86_64: 2.6.14-rc4 swiotlb broken

On Mon, Oct 17, 2005 at 01:04:01PM -0600, Alex Williamson wrote:
> On Mon, 2005-10-17 at 11:20 -0700, Christoph Lameter wrote:
> > On Mon, 17 Oct 2005, Ravikiran G Thirumalai wrote:
> >
> > > Maybe someone with access to ia64 NUMA boxen can check if the NODE(0)
> > > solution works (and does not break anything) on ia64? Chrisoph, can you
> > > help?
> >
> > Umm... SGI does not use the swiotlb and we do not have these issues. HP
> > does use the swiotlb on IA64. CCing John and Alex.
> ...
> > @@ -123,7 +123,7 @@
> > /*
> > * Get IO TLB memory from the low pages
> > */
> > - io_tlb_start = alloc_bootmem_low_pages(io_tlb_nslabs *
> > + io_tlb_start = alloc_bootmem_node(NODE_DATA(0), io_tlb_nslabs *
>
> HP ia64 boxes typically use a hardware I/O TLB, so this is not the
> normal case. However, the sx1000 boxes are exactly an example that will
> break because of this assumption about memory layout. These boxes can
> be configured to have various ratios of node local memory and
> interleaved memory. Node local memory starts well above 4GB.
> Interleaved memory is zero-based, and described in it's own proximity
> domain. It therefore looks like a memory-only node. I believe the
> above code change would cause us to allocate memory from the node local
> range, way too high in the address space for bounce buffers.

This memory only node has a node id? Then how about a patch which iterates over
nodes in swiotlb.c, trying to allocate DMA'ble memory from node 0 and above
until it gets proper memory for swiotlb?

Would that be accepatble? I can quickly make a patch for that if it is
acceptable..

Thanks,
Kiran


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise