[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#417853: marked as done (kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!)

Your message dated Mon, 04 May 2015 01:20:59 +0100
with message-id <1430698859.4113.122.camel@decadent.org.uk>
and subject line Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
has caused the Debian Bug report #417853,
regarding kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
417853: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417853
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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=116502121800001&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: LANG=en_DE@scientia.net, LC_CTYPE=en_DE@scientia.net (charmap=UTF-8)



begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:calestyo@scientia.net
x-mozilla-html:TRUE
version:2.1
end:vcard

--- End Message ---
--- Begin Message --- 
The kernel bug was fixed in 2.6.18.dfsg.1-13 so this doesn't need
documenting.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: