On Tue, 20 Nov 2007, Tejun Heo wrote:
> Andi Kleen wrote:
> >
> >> The AHCI code falls back to 32bit DMA in that case. Which in turn
> >> causes the problem seen by Srihari. There is not much printk sticking
> >> necessary, the code is simply not handling this.
> >
> > What code is not handling what?
> >
> > IOMMU merging should be always safe. If it is not the driver should
> > not submit things in a single SG list.
>
> Yeap, a sg merged by IOMMU should be safe. It's just another contiguous
> memory area from the POV of the controller anyway. I wonder what went
> wrong here. What has exactly changed with iommu_merge patch?
Not much:
-int iommu_merge __read_mostly = 0;
+int iommu_merge __read_mostly = 1;
EXPORT_SYMBOL(iommu_merge);
Which in turn enables the iommu_merge functionality in gart_map_sg().
for_each_sg(sg, s, nents, i) {
dma_addr_t addr = sg_phys(s);
s->dma_address = addr;
BUG_ON(s->length == 0);
nextneed = need_iommu(dev, addr, s->length);
/* Handle the previous not yet processed entries */
if (i > start) {
/* Can only merge when the last chunk ends on a page
boundary and the new one doesn't have an offset. */
if (!iommu_merge || !nextneed || !need || s->offset ||
(ps->offset + ps->length) % PAGE_SIZE) {
if (dma_map_cont(start_sg, i - start, sgmap,
pages, need) < 0)
goto error;
out++;
sgmap = sg_next(sgmap);
pages = 0;
start = i;
start_sg = s;
}
}
need = nextneed;
pages += to_pages(s->offset, s->length);
ps = s;
}
if (dma_map_cont(start_sg, i - start, sgmap, pages, need) < 0)
goto error;
So with iommu_merge off we map for each entry in the sg
list. iommu_merge concatenates into larger segments.
This requires propably working 64bit DMA, which is not possible with
the SB600 controller.
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
