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:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
