Messages in this thread | | | Date | Wed, 13 Dec 2006 20:18:21 +0100 | From | Christoph Anton Mitterer <> | Subject | Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?! |
| |
Karsten Weiss wrote: > Last week we did some more testing with the following result: > > We could not reproduce the data corruption anymore if we boot the machines > with the kernel parameter "iommu=soft" i.e. if we use software bounce > buffering instead of the hw-iommu. (As mentioned before, booting with > mem=2g works fine, too, because this disables the iommu altogether.) > I can confirm this,... booting with mem=2G => works fine,...
(all of the following tests were made with memory hole mapping=hardware in the BIOS,.. so I could access my full ram): booting with iommu=soft => works fine booting with iommu=noagp => DOESN'T solve the error booting with iommu=off => the system doesn't even boot and panics
When I set IOMMU to disabled in the BIOS the error is not solved- I tried to set bigger space for the IOMMU in the BIOS (256MB instead of 64MB),.. but it does not solve the problem.
Any ideas why iommu=disabled in the bios does not solve the issue?
> I.e. on these systems the data corruption only happens if the hw-iommu > (PCI-GART) of the Opteron CPUs is in use. > 1) And does this now mean that there's an error in the hardware (chipset or CPU/memcontroller)?
> Christoph, Erik, Chris: I would appreciate if you would test and hopefully > confirm this workaround, too. > Yes I can absolutely confirm this... Do my additional tests help you?
Do you have any ideas why the issue doesn't occur (even with memhole mapping=hardware in the bios and no iommu=soft at kernel command line) when dma is disabled for the disks (or a slower dma mode is used)?
Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:calestyo@scientia.net x-mozilla-html:TRUE version:2.1 end:vcard
| |