Bug#404148: i'm not convinced release notes are enough
tags 404148 patch
thanks
On Wed, Mar 14, 2007 at 01:24:30AM +0100, Christoph Anton Mitterer wrote:
> First of all,.. there is still no other solution than iommu=soft (at
> least as of my knowledge) and we had even someone on the bugreport at
> bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not
> BIOS memhole mapping = disabled.
> >> what is the performance impact of using the safe option on all hardware
> >> even that not affected by this bug? would using that option by default
> >> result in a noticable performance degrdation?
> > It's unknown to me whether all other currently-supported systems even *work*
> > if iommu=soft is set.
> As far as I know,.. everything should. For example Intel CPUs don't have
> an IOMMU at all,... Windows uses always a kind of software iommu (even
> on AMD CPUs).
> > This is not the time to gamble with the kernel.
> In all doing respect, I think that it's a much greater risk to not use
> iommu=soft per default than doing so. Even if we imagine that there
> would by systems that don't work with the sw-iommu.... it's likely that
> they simply break (at boot time). And then the affected user at least
> knows that something is happening to him, while with no iommu=soft he
> would probably never realize that he has problems.
That doesn't address how to set iommu=soft as a default, though. The only
practical way that I see to accomplish this is in the kernel package itself,
and there was doubt that there would be an opportunity to update the kernel
again before release.
Now, it's pretty clear that we will have a kernel update before etch is
released, so we should proceed accordingly.
> > If a targetted patch is available that sets iommu=soft for the chipset in
> > question,
> I think this will never happen. The problem is simply: Kernel developers
> cannot tell which chipsets are affected, or which chipset/CPU combinations.
> We even don't know yet where the error comes from (CPU or nvidia
> chipset). According to Andi Kleen this is still being investiagted by
> nvidia and AMD.
> So such a patch would have to whitelist systems that are known to work,
> instead of blacklist the others.
But AIUI the problem has so far only been reported on systems using an
nvidia chipset, right? I'm not going to hold up as release-critical a
bugfix for other systems where the problem hasn't been reported yet. If
more information becomes available showing that the bug exists on non-nvidia
systems, we should of course revisit it at that point.
In the meantime, I don't see any reason why we shouldn't patch the kernel to
disable hw iommu on nvidia systems only. I believe the attached patch
should do this. Are you in a position to confirm that this does disable hw
iommu for you?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--- a/arch/x86_64/kernel/io_apic.c 2007-03-22 00:54:33.000000000 -0700
+++ b/arch/x86_64/kernel/io_apic.c 2007-03-22 01:13:06.000000000 -0700
@@ -344,6 +344,22 @@
"timer override.\n");
}
#endif
+#ifdef CONFIG_IOMMU
+ /* Forcibly disabling nvidia HW iommu,
+ per Debian bug #404148. */
+ if ((end_pfn > MAX_DMA32_PFN ||
+ force_iommu) &&
+ !iommu_aperture_allowed) {
+ printk(KERN_INFO
+ "Looks like an nvidia chipset. Disabling HW IOMMU. Override with \"iommu=allowed\"\n");
+#ifdef CONFIG_SWIOTLB
+ swiotlb = 1;
+#else
+ no_iommu = 1;
+#endif
+ }
+#endif
+
/* RED-PEN skip them on mptables too? */
return;
Reply to: