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
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
