[openib-general] problem with 2.6.19?
Steve Wise
swise at opengridcomputing.com
Fri Oct 27 08:53:08 PDT 2006
And I do have CONFIG_SWIOTLB set:
CONFIG_SWIOTLB=y
On Fri, 2006-10-27 at 10:48 -0500, Steve Wise wrote:
> Also, if I drop the memory down to 1G (via mem=1G on the boot line),
> then things work. But I think I'm just disabling the IOMMU. Note that
> __pa() and dma_map_single() return the same thing:
>
>
> c2_alloc_mqsp_chunk mqsp_chunk va ffff81003c4d2000 dma_addr 3c4d2000 __pa 3c4d2000
> c2_alloc_mqsp addr ffff81003c4d201a dma_addr 3c4d201a
> c2_alloc_mqsp addr ffff81003c4d201c dma_addr 3c4d201c
> c2_alloc_mqsp addr ffff81003c4d201e dma_addr 3c4d201e
> c2_alloc_mqsp addr ffff81003c4d2020 dma_addr 3c4d2020
> c2_rnic_init rep_vq va ffff81003cb08000 dma 3cb08000 __pa 3cb08000
> c2_rnic_init aeq va ffff81003d4e0000 dma 3d4e0000 __pa 3d4e0000
>
>
>
> On Fri, 2006-10-27 at 09:43 -0500, Steve Wise wrote:
> > On Thu, 2006-10-26 at 15:26 -0700, Roland Dreier wrote:
> > > Steve> The adapter seems to be dma'ing into the wrong memory. The
> > > Steve> patch below backs the usage of dma_map_single() back to
> > > Steve> using __pa() for converting kernel virtual addresses (from
> > > Steve> kmalloc) into bus addresses, and things work ok.
> > >
> > > Hmm. It might be interesting to hack the driver to print the result
> > > of both dma_map_single() and __pa() and see if they're different.
> > >
> >
> > Here's a dump. They are different. The __pa()'s are what I expect. I
> > dunno if the dma_addr's returned from dma_map_single() look good or not
> > (they certainly don't work :)
> >
> > c2_alloc_mqsp_chunk mqsp_chunk va ffff810148b1b000 dma_addr 3a56000 __pa 148b1b000
> > c2_alloc_mqsp addr ffff810148b1b01a dma_addr 3a5601a
> > c2_alloc_mqsp addr ffff810148b1b01c dma_addr 3a5601c
> > c2_alloc_mqsp addr ffff810148b1b01e dma_addr 3a5601e
> > c2_alloc_mqsp addr ffff810148b1b020 dma_addr 3a56020
> > c2_rnic_init rep_vq va ffff810147e78000 dma 3a57000 __pa 147e78000
> > c2_rnic_init aeq va ffff810147d48000 dma 3a5f000 __pa 147d48000
> >
> > > Are you running on a 32-bit (i386) or 64-bit (x86_64) kernel? How
> > > much RAM do you have?
> >
> > 64b/X86_64. 4GB RAM. The CPUs are Dempsey class XEONs - Dual CPU, Dual
> > core. So with HT on linux sees 8 CPUs.
> >
> > > Is the kernel using swiotlb? If so then you
> > > need to make sure your DMA_{TO,FROM} directions and dma_unmap calls
> > > are right, since otherwise the DMAed data won't be copied to/from the
> > > bounce buffer at the right time.
> >
> > All these mappings are for the device to DMA into the host memory, and
> > I'm using DMA_FROM_DEVICE in my calls to dma_map_single().
> >
> > How do I know if the kernel is using swiotlb?
> >
> >
> > > Another thing to do if you're patient would be to use git-bisect and
> > > figure out exactly which patch made amso1100 stop working.
> > >
> >
> > I added these calls as part of the review for submission into the
> > kernel, and I originally tested them on dual CPU opteron systems with
> > 1GB of memory. But maybe they weren't using the IOMMU? Dunno.
> >
> >
> >
> >
> > _______________________________________________
> > openib-general mailing list
> > openib-general at openib.org
> > http://openib.org/mailman/listinfo/openib-general
> >
> > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> >
>
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
More information about the general
mailing list