Messages in this thread | | | Date | Thu, 13 Aug 2009 16:11:46 +0800 | Subject | Re: [RFC patch] init default dma_ops to prepare intel_iommu_init failure | From | Luming Yu <> |
| |
On Thu, Aug 13, 2009 at 4:03 PM, FUJITA Tomonori<fujita.tomonori@lab.ntt.co.jp> wrote: > On Thu, 13 Aug 2009 15:37:54 +0800 > Luming Yu <luming.yu@gmail.com> wrote: > >> On Thu, Aug 13, 2009 at 3:14 PM, FUJITA >> Tomonori<fujita.tomonori@lab.ntt.co.jp> wrote: >> > On Thu, 13 Aug 2009 15:03:20 +0800 >> > Luming Yu <luming.yu@gmail.com> wrote: >> > >> >> Thanks for another workaround, we should be working on deleting wrong >> >> assumption of"iommu_deteced == iommu working", Not just workaround. My >> >> patch could break something.. but it is just a start towards right >> >> goal.. >> > >> > As I explained, your patch doesn't go toward the right goal. >> >> The goal is to decouple dma_ops init and iommu_detect. >> In that sense, my patch is right. > > No, your patch is a workaround too. > > If you want swiotlb the default dma_ops for IA64, pci_swiotlb_init() > is the wrong place for swiotlb_init() because sba needs swiotlb too > for the same reason. Probably, we should always set platform_dma_init > to swiotlb_dma_init(). > > > You want to fix this problem for 2.6.31? Or you think about 2.6.32 (or > later)? >
I treat this as -32 or -33 stuff, because I don't see a real system is blocking on the problem. I found this problem when I was trying to disable some drhd for debugging a real iommu issue...that one has priority.
| |