linux-kernel - Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Dec 2006 20:18:21 +0100
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	Karsten Weiss <K.Weiss@...ence-computing.de>
CC:	linux-kernel@...r.kernel.org,
	Erik Andersen <andersen@...epoet.org>,
	Chris Wedgwood <cw@...f.org>, Andi Kleen <ak@...e.de>
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.

View attachment "calestyo.vcf" of type "text/x-vcard" (156 bytes)