Package: kernel
Severity: critical
Justification: causes serious data loss
Hi everybody.
I'm currently (together with others) investigating in a severe data
corruption problem that at least many users might suffer from.
A short description, when you validate lots of GBs over and over with
md5sums (or another hash) there are errors found.
We do not yet know the real reson for the problems but it might relate
to Opteron (and perhaps Athlon) CPUs and/or Nvidia chipsets (mainboard).
So it might be a hardware design error (but even a kernel error could be
possible).
This is definitely not a single hardware issue of my system as many
other users on lkml reported the problem (and we all did very extensive
hardware tests).
The error occurs only if on has so much memory that the system uses
memory mapping (and the hardware iommu).
At lkml we currently found two "solutions" (I consider them more
workarounds, as we don't know exactly why they're solving the problem):
1) Disabling memory hole mapping in the system BIOS. The downside is
that there is no memory hole mapping at all, and the users looses much
of his main memory (in my case 1,5 GB)
2) Setting iommu=soft. The users keeps it full memory, and in all our
tests (at least as far as I am informed), and we do very much tests as I
and someone else administer some big linux clusters,... the error did
_not_ occur.
Windows users do generally not suffer from this corruption, as Windows
(at least until Vista) was not able to make use of the hardware iommu,
and always uses the software iommu.
The Intel CPUs with EMT64/Intel64 don't suffer from that problem either,
as they don't have an hwiommu, too (at least as far as I know).
We are not yet sure if this is a large scale problem or affects only
some special hardware combinations. We do however think that the issue
occurs only with PCI-DMA accesses. (Tests showed, that when disabling
dma or at least using slower dma modes on the disks, the issue disappeared).
The problem is vendors (at least Nvidia) does not help very much, they
even didn't answer my mails.
And most "normal" users won't recognise this problem, as they don't have
enought main memory and even it they have the error occurs very rarely
(perhaps some 100 bytes every 30 GB <- only a very imprecise scale).
What I suggest know:
As this is a very grave I suggest
- to configure all the default kernels for etch that may be affected (as
far as I know that are the amd64-k8 and amd64-generic kernels. Perhaps
the i386 packages too, have a look at lkml for this) to use iommu=soft.
- to update all packages in sarge and woody (as far as they might be
affected)
- put some warnings in the packages where users might configure their
own kernel and the boot-loaders.
Have a look at this thread at lkml
http://marc.theaimsgroup.com/?t=11650212181&r=1&w=2 for in-depth
information.
It also contains links to some previous threads. There are also some
posts to lkml about this topics in separate threads (e.g. "amd64 iommu
causing corruption? (was Re: data corruption with nvidia chipsets and
IDE/SATA drives // memory hole mapping related bug?!)").
Best wishes,
Chris.
btw: please CC me as I'm off-list at the moment.
PS: I'll also write this the debian-kernel mailinglist.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
