On Tue, Jan 22, 2013 at 7:15 PM, Mihai Moldovan <ionic at ionic.de> wrote: > * On 21.01.2013 07:11 PM, Mihai Moldovan wrote: >> I'm also currently testing a kernel without the Intel IOMMU feature >> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least >> not seeing USB and PCI(e) issues. I'll leave the box running for some >> more [time] [...] > > No freezes for >22h, seems to be fine. > > >> [...] and will afterwards disable IOMMU as a whole to see if I hit >> USB and PCI(e) issues again with that combination. > > The systems seems to run stable with CONFIG_IOMMU_SUPPORT=n set, too. This is > expected. > However: unlike during earlier tests when I disabled IOMMU and Intel IOMMU via > kernel/boot parameters, I am not seeing any DMA mapping errors. > > There seems to be a difference between disabling IOMMU/Intel IOMMU statically in > the kernel compared to disabling it via kernel parameter. Is this another bug? Behaviour should be the same for the actual dma access at the hw layer, but if you disable things at compile-time at least drm/i915 selects different paths. We've recently killed those though since it's not worth the complexity at all. But dunno why you still get dma errors, that shouldn't be possible. Maybe David has an idea. > I've attached both kernel ring buffer logs (minus the timings for easier diffing.) > > [*] kern-new-iommu_off.log.bz2 disables IOMMU and Intel IOMMU via boot parameter > [*] kern-iommu_static_off.log.bz2 has CONFIG_IOMMU_SUPPORT=n set and any IOMMU > support statically disabled (also consequently DMAR) In any case I'll ping David about my 2nd quirk patch and whether that's something which makes sense and could be merged. Thanks a lot for all the testing you've done. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
