Debian Bug report logs - #404148
kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

version graph

Package: linux-2.6; Maintainer for linux-2.6 is Debian Kernel Team <debian-kernel@lists.debian.org>;

Reported by: Christoph Anton Mitterer <calestyo@scientia.net>

Date: Fri, 22 Dec 2006 01:33:08 UTC

Severity: critical

Tags: etch-ignore, fixed-upstream, patch

Fixed in versions linux-2.6/2.6.18.dfsg.1-13, linux-2.6/2.6.18.dfsg.1-13lenny1

Done: dann frazier <dannf@debian.org>

Bug is archived. No further changes may be made.

Forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=7768

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package kernel. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
New Bug report received and forwarded. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: submit@bugs.debian.org
Subject: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Date: Fri, 22 Dec 2006 02:24:59 +0100
[Message part 1 (text/plain, inline)]
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)


[calestyo.vcf (text/x-vcard, attachment)]

Bug reassigned from package `kernel' to `linux-2.6'. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Noted your statement that Bug has been forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=7768. Request was from Filipus Klutiero <cheal@hotpop.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #14 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 404148@bugs.debian.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Date: Mon, 12 Mar 2007 23:25:13 -0700
So regrettably, this bug went more or less unnoticed on the 'kernel'
pseudopackage until now, and it does appear (based on the upstream
discussion) to affect the etch kernels.  And in addition to it being noticed
after the upload of 2.6.18.dfsg.1-11, there also doesn't seem to be a real
upstream fix available for the problem yet.

There does seem to be a workaround available though, which is iommu=soft.
At the moment, I'm doubtful that we could change the kernel to force this
setting on only the nvidia chipsets in time for etch.  Should we instead tag
this bug etch-ignore, and refer the iommu=soft workaround to the release
notes?

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to sven@powerlinux.fr (Sven Luther):
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #19 received at 404148@bugs.debian.org (full text, mbox):

From: sven@powerlinux.fr (Sven Luther)
To: Steve Langasek <vorlon@debian.org>, 404148@bugs.debian.org
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Date: Tue, 13 Mar 2007 07:40:05 +0100
On Mon, Mar 12, 2007 at 11:25:13PM -0700, Steve Langasek wrote:
> So regrettably, this bug went more or less unnoticed on the 'kernel'
> pseudopackage until now, and it does appear (based on the upstream
> discussion) to affect the etch kernels.  And in addition to it being noticed
> after the upload of 2.6.18.dfsg.1-11, there also doesn't seem to be a real
> upstream fix available for the problem yet.
> 
> There does seem to be a workaround available though, which is iommu=soft.
> At the moment, I'm doubtful that we could change the kernel to force this
> setting on only the nvidia chipsets in time for etch.  Should we instead tag
> this bug etch-ignore, and refer the iommu=soft workaround to the release
> notes?

Could this also be related to my #414580 problems ? Will try the iommu=soft
option now. Mmm, ...

No, iommu=soft doesn't seem to help there.

Friendly,

Sven Luther



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Peter Green <Peter.Green@student.manchester.ac.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #24 received at 404148@bugs.debian.org (full text, mbox):

From: Peter Green <Peter.Green@student.manchester.ac.uk>
To: 404148@bugs.debian.org
Cc: calestyo@scientia.net
Subject: i'm not convinced release notes are enough
Date: Tue, 13 Mar 2007 21:01:03 +0000
despite the best intentions of debian i am convinced that most users will
not read the release notes and over the lifetime of the etch release
having large ammounts (just how much is needed to trigger this bug btw) of
memory will become more and more common.

what does the sarge kernel do when placed on a machine like this? does it
use the hardware iommu? does it use the software one? does it not use one
at all (and hence lose some memory). In other words is the current
situation a regression from sarge?

what is the performance impact of using the safe option on all hardware
even that not affected by this bug? would using that option by default
result in a noticable performance degrdation?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #29 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Peter Green <Peter.Green@student.manchester.ac.uk>, 404148@bugs.debian.org
Cc: calestyo@scientia.net
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Tue, 13 Mar 2007 16:38:08 -0700
On Tue, Mar 13, 2007 at 09:01:03PM +0000, Peter Green wrote:
> despite the best intentions of debian i am convinced that most users will
> not read the release notes and over the lifetime of the etch release
> having large ammounts (just how much is needed to trigger this bug btw) of
> memory will become more and more common.

AIUI the bug triggers on systems with memory in excess of 5GB.  Limited to
server-class hardware.  I hope server admins are aware of the contents of
release notes.

> what is the performance impact of using the safe option on all hardware
> even that not affected by this bug? would using that option by default
> result in a noticable performance degrdation?

It's unknown to me whether all other currently-supported systems even *work*
if iommu=soft is set.  This is not the time to gamble with the kernel.

If a targetted patch is available that sets iommu=soft for the chipset in
question, that would be a good candidate for the next kernel upload, which
may or may not make it into r0.  But if no one has a good fix to offer, I
think we need to settle for documenting it as errata given that upstream
doesn't have a proper fix for this yet.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #34 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Steve Langasek <vorlon@debian.org>
Cc: Peter Green <Peter.Green@student.manchester.ac.uk>, 404148@bugs.debian.org
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Wed, 14 Mar 2007 01:24:30 +0100
[Message part 1 (text/plain, inline)]
Hi.

Sorry that I've ignored the last answers to the bug but I somehow missed
the mail.

First of all,.. there is still no other solution than iommu=soft (at
least as of my knowledge) and we had even someone on the bugreport at
bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not
BIOS memhole mapping = disabled.

> AIUI the bug triggers on systems with memory in excess of 5GB.  Limited to
> server-class hardware.  I hope server admins are aware of the contents of
> release notes.
>   
I don't think that you can rely on this. And even if so. Some could
probably just ignore it because their "small" tests don't show an
corruption and people might think they're on the safe side.


>> what is the performance impact of using the safe option on all hardware
>> even that not affected by this bug? would using that option by default
>> result in a noticable performance degrdation?
>>     
> It's unknown to me whether all other currently-supported systems even *work*
> if iommu=soft is set.
As far as I know,.. everything should. For example Intel CPUs don't have
an IOMMU at all,... Windows uses always a kind of software iommu (even
on AMD CPUs).

> This is not the time to gamble with the kernel.
>   
In all doing respect, I think that it's a much greater risk to not use
iommu=soft per default than doing so. Even if we imagine that there
would by systems that don't work with the sw-iommu.... it's likely that
they simply break (at boot time). And then the affected user at least
knows that something is happening to him, while with no iommu=soft he
would probably never realize that he has problems.


> If a targetted patch is available that sets iommu=soft for the chipset in
> question,
I think this will never happen. The problem is simply: Kernel developers
cannot tell which chipsets are affected, or which chipset/CPU combinations.
We even don't know yet where the error comes from (CPU or nvidia
chipset). According to Andi Kleen this is still being investiagted by
nvidia and AMD.

So such a patch would have to whitelist systems that are known to work,
instead of blacklist the others.



> that would be a good candidate for the next kernel upload, which
> may or may not make it into r0.  But if no one has a good fix to offer, I
> think we need to settle for documenting it as errata given that upstream
> doesn't have a proper fix for this yet
Let me qoute Andi Kleen:
"Unless a good workaround comes around soon I'll probably default to
iommu=soft on Nvidia."

You see that even he thinks about using iommu=soft as default (on
nvidia). And until such a patch is available I think the saftest would
be to use it as a general default on amd64. Perhaps Debians kernel team
could even maintain their own patch that would activate iommu=soft only
on nvidia chipsets.


Best wishes,
Chris.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #39 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>, 404148@bugs.debian.org
Cc: Peter Green <Peter.Green@student.manchester.ac.uk>
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Thu, 22 Mar 2007 01:15:31 -0700
[Message part 1 (text/plain, inline)]
tags 404148 patch
thanks

On Wed, Mar 14, 2007 at 01:24:30AM +0100, Christoph Anton Mitterer wrote:
> First of all,.. there is still no other solution than iommu=soft (at
> least as of my knowledge) and we had even someone on the bugreport at
> bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not
> BIOS memhole mapping = disabled.

> >> what is the performance impact of using the safe option on all hardware
> >> even that not affected by this bug? would using that option by default
> >> result in a noticable performance degrdation?

> > It's unknown to me whether all other currently-supported systems even *work*
> > if iommu=soft is set.
> As far as I know,.. everything should. For example Intel CPUs don't have
> an IOMMU at all,... Windows uses always a kind of software iommu (even
> on AMD CPUs).

> > This is not the time to gamble with the kernel.

> In all doing respect, I think that it's a much greater risk to not use
> iommu=soft per default than doing so. Even if we imagine that there
> would by systems that don't work with the sw-iommu.... it's likely that
> they simply break (at boot time). And then the affected user at least
> knows that something is happening to him, while with no iommu=soft he
> would probably never realize that he has problems.

That doesn't address how to set iommu=soft as a default, though.  The only
practical way that I see to accomplish this is in the kernel package itself,
and there was doubt that there would be an opportunity to update the kernel
again before release.

Now, it's pretty clear that we will have a kernel update before etch is
released, so we should proceed accordingly.

> > If a targetted patch is available that sets iommu=soft for the chipset in
> > question,
> I think this will never happen. The problem is simply: Kernel developers
> cannot tell which chipsets are affected, or which chipset/CPU combinations.
> We even don't know yet where the error comes from (CPU or nvidia
> chipset). According to Andi Kleen this is still being investiagted by
> nvidia and AMD.

> So such a patch would have to whitelist systems that are known to work,
> instead of blacklist the others.

But AIUI the problem has so far only been reported on systems using an
nvidia chipset, right?  I'm not going to hold up as release-critical a
bugfix for other systems where the problem hasn't been reported yet.  If
more information becomes available showing that the bug exists on non-nvidia
systems, we should of course revisit it at that point.

In the meantime, I don't see any reason why we shouldn't patch the kernel to
disable hw iommu on nvidia systems only.  I believe the attached patch
should do this.  Are you in a position to confirm that this does disable hw
iommu for you?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
[amd64-no-nvidia-hw-iommu.patch (text/x-diff, attachment)]

Tags added: patch Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Thu, 22 Mar 2007 08:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #46 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Steve Langasek <vorlon@debian.org>
Cc: 404148@bugs.debian.org, Peter Green <Peter.Green@student.manchester.ac.uk>
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Thu, 22 Mar 2007 13:15:37 +0100
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
>> In all doing respect, I think that it's a much greater risk to not use
>> iommu=soft per default than doing so. Even if we imagine that there
>> would by systems that don't work with the sw-iommu.... it's likely that
>> they simply break (at boot time). And then the affected user at least
>> knows that something is happening to him, while with no iommu=soft he
>> would probably never realize that he has problems.
>>     
> That doesn't address how to set iommu=soft as a default, though.  The only
> practical way that I see to accomplish this is in the kernel package itself,
> and there was doubt that there would be an opportunity to update the kernel
> again before release.
>   
One possibility would be too add it per default to the grub and lilo
configs, perhaps with a pointer to this bug.
This way every users could simply decide wheter to remove this or not.


>> So such a patch would have to whitelist systems that are known to work,
>> instead of blacklist the others.
>>     
> But AIUI the problem has so far only been reported on systems using an
> nvidia chipset, right?
Yes (and perhaps no).
First of all there were some people who had and Opteron and an Nvidia
chipset and that much main memory etc etc. (I mean a system
configuration where "we" would have supposed that they would suffer from
the error).... but they at least claimed to not suffer from it.
Perhaps some BIOSes might somewho workaround (not solve) it.

Another issue is the following: Just today someone added to the
bugzilla.kernel.org bug that he probably has the same error but his
system doesn't have an Nvidia chipset (see
http://bugzilla.kernel.org/show_bug.cgi?id=7768).
Anyway I don't believe that this is actually the same error.


> I'm not going to hold up as release-critical a
> bugfix for other systems where the problem hasn't been reported yet.  If
> more information becomes available showing that the bug exists on non-nvidia
> systems, we should of course revisit it at that point.
>   
see above


> In the meantime, I don't see any reason why we shouldn't patch the kernel to
> disable hw iommu on nvidia systems only.  I believe the attached patch
> should do this.  Are you in a position to confirm that this does disable hw
> iommu for you?
>   
Unfortunately I'm not currently able to validate it, but I will forward
it to the thread at lkml and to the bug at kernel.org.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #51 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 404148@bugs.debian.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Date: Tue, 27 Mar 2007 03:49:16 -0700
clone 404148 -1
reassign -1 release-notes
tags 404148 etch-ignore
tags -1 -patch
thanks

Since no one was able to test the provided patch, linux-2.6 2.6.18.dfsg.1-12
has been uploaded to unstable without it, which means fixing this has missed
the last kernel upload for etch r0.

That leaves this as a documentation issue for the release notes.  Here is a
proposed description:

  Some amd64 systems which have nvidia chipsets and more than 3GB of RAM
  seem to have an issue with 32-bit PCI access that may result in sporadic
  data corruption when accessing disks.  Because this problem was still
  under investigation by the Linux kernel developers at the time of release,
  it was not possible to include a fix for this problem in the etch kernel
  packages.  As a workaround, users running etch on such a system are
  recommended to add 'iommu=soft' to their kernel boot options.  See Debian
  bug #404148 for full details.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Bug 404148 cloned as bug 416374. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Tue, 27 Mar 2007 10:54:13 GMT) Full text and rfc822 format available.

Tags added: etch-ignore Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Tue, 27 Mar 2007 10:54:17 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 404148@bugs.debian.org
Cc: vorlon@debian.org, aba@not.so.argh.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 01:29:04 +0200
[Message part 1 (text/plain, inline)]
Hi Steve.

As I've told you in my email before I just tested your patch with the
following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
testing, of course on an amd64 system):

- The patch applies without problems
- The kernel compiles with it without problems (at least with my config)
- It boots correctly
- and it automatically disables the hardware iommu (look at my dmesg below):

Bootdata ok (command line is root=/dev/sda1 ro snd-ice1724.index=0
snd-intel8x0.index=1 )
Linux version 2.6.18debtest (Version:) (calestyo@euler) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Sat Mar 31
00:42:51 CEST 2007
BIOS-provided physical RAM map:
....
....
  Normal zone: 387840 pages, LIFO batch:31
Nvidia board detected. Ignoring ACPI timer override.
Looks like an nvidia chipset. Disabling HW IOMMU. Override with
"iommu=allowed"
ACPI: PM-Timer IO Port: 0x8008
....
....
CPU 0: aperture @ ac000000 size 64 MB
CPU 1: aperture @ ac000000 size 64 MB
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing software IO TLB between 0x1650000 - 0x5650000
Memory: 4036552k/5767168k available (3007k kernel code, 156324k
reserved, 1245k data, 216k init)
Calibrating delay using timer specific routine.. 4422.28 BogoMIPS
(lpj=2211140)
Security Framework v1.0.0 initialized
....
....

So you see later on the kernel correctly reports to use the swiotlb.

I would say (although I'm by any means not kernel expert) that your
patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
You're the release manager,... so you should get managed this :-)

But I would say that you should add some notes to the release notes.

btw: I've CC'ed the mail to Andy so if you don't have time to do this he
might... uh and for Andy: have you already signed the etch release key
and did you have found some time to sign my personal key I gave you on
the last Stammtisch?!

Best wishes,
Chris.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 404148@bugs.debian.org, aba@not.so.argh.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 03:58:49 -0700
On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:

> As I've told you in my email before I just tested your patch with the
> following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> testing, of course on an amd64 system):

> - The patch applies without problems
> - The kernel compiles with it without problems (at least with my config)
> - It boots correctly
> - and it automatically disables the hardware iommu (look at my dmesg below):

Thanks, that's great to hear.

> I would say (although I'm by any means not kernel expert) that your
> patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> You're the release manager,... so you should get managed this :-)

It wouldn't be appropriate for me to push this without the consent of the
rest of the kernel team just because I'm the release manager; I'm not even
an amd64 porter, this should be signed off on by the folks who are actually
responsible for the amd64 kernel first.  But regardless, there are no plans
for another kernel update before etch r0, and including one is likely to
delay the release.  I'm of the opinion that this bug does not justify a
delay at this point.

With the consent of the kernel team and the stable release managers, I'm
happy to commit this patch to the queue for the next kernel update though,
so it can be included in etch r1.

> But I would say that you should add some notes to the release notes.

Yes, that's now bug #416374, which includes a suggested text.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Steve Langasek <vorlon@debian.org>
Cc: 404148@bugs.debian.org, aba@not.so.argh.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 15:02:35 +0200
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> But regardless, there are no plans
> for another kernel update before etch r0, and including one is likely to
> delay the release.  I'm of the opinion that this bug does not justify a
> delay at this point.
>   
Uhm,.... sad to hear this...

> With the consent of the kernel team and the stable release managers, I'm
> happy to commit this patch to the queue for the next kernel update though,
> so it can be included in etch r1.
>   
k,... perhaps we will have a real solution in the meantime. It seems
like AMD makes some progress.


>> But I would say that you should add some notes to the release notes.
>>     
> Yes, that's now bug #416374, which includes a suggested text.
k,.. at least something ;-)


Best wishes,
Chris.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 404148@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: Steve Langasek <vorlon@debian.org>
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, 404148@bugs.debian.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 15:11:09 +0200
* Steve Langasek (vorlon@debian.org) [070331 12:59]:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > I would say (although I'm by any means not kernel expert) that your
> > patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> > You're the release manager,... so you should get managed this :-)
> 
> It wouldn't be appropriate for me to push this without the consent of the
> rest of the kernel team just because I'm the release manager; I'm not even
> an amd64 porter, this should be signed off on by the folks who are actually
> responsible for the amd64 kernel first.  But regardless, there are no plans
> for another kernel update before etch r0, and including one is likely to
> delay the release.  I'm of the opinion that this bug does not justify a
> delay at this point.
> 
> With the consent of the kernel team and the stable release managers, I'm
> happy to commit this patch to the queue for the next kernel update though,
> so it can be included in etch r1.


BTW, we intended to have frequent kernel uploads to proposed-updates,
and frankly speaking, I personally don't mind to already have a newer
kernel in proposed-updates during the release, but that's something I
want to have signed-off by Martin.


Cheers,
Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Sven Luther <luther@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 404148@bugs.debian.org (full text, mbox):

From: Sven Luther <luther@debian.org>
To: Andreas Barth <aba@not.so.argh.org>, 404148@bugs.debian.org
Cc: Steve Langasek <vorlon@debian.org>, Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 15:45:27 +0200
On Sat, Mar 31, 2007 at 03:11:09PM +0200, Andreas Barth wrote:
> * Steve Langasek (vorlon@debian.org) [070331 12:59]:
> > On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > > I would say (although I'm by any means not kernel expert) that your
> > > patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> > > You're the release manager,... so you should get managed this :-)
> > 
> > It wouldn't be appropriate for me to push this without the consent of the
> > rest of the kernel team just because I'm the release manager; I'm not even
> > an amd64 porter, this should be signed off on by the folks who are actually
> > responsible for the amd64 kernel first.  But regardless, there are no plans
> > for another kernel update before etch r0, and including one is likely to
> > delay the release.  I'm of the opinion that this bug does not justify a
> > delay at this point.
> > 
> > With the consent of the kernel team and the stable release managers, I'm
> > happy to commit this patch to the queue for the next kernel update though,
> > so it can be included in etch r1.
> 
> 
> BTW, we intended to have frequent kernel uploads to proposed-updates,
> and frankly speaking, I personally don't mind to already have a newer
> kernel in proposed-updates during the release, but that's something I
> want to have signed-off by Martin.

The ideal would have been a framework where we could build new kernels and
have it integrated within a few days only. I gave a speach about this at
FOSDEM, of how we could use the initramfs incremental nature, to separate
fully the kernel module .udebs from the rest of d-i, and have actual d-i
images which are daily built, and usable independently of the kernel used.

This is already the second release where such problems happen, so let's hope
that people get more reasonable about trying to solve this through the
available technical solution for lenny.

Because *IT IS POSSIBLE* :)

Friendly,

Sven Luther



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 404148@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Steve Langasek <vorlon@debian.org>, 404148@bugs.debian.org
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, Peter Green <Peter.Green@student.manchester.ac.uk>
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Sat, 31 Mar 2007 16:05:33 +0200
[Message part 1 (text/plain, inline)]
On Thu, Mar 22, 2007 at 01:15:31AM -0700, Steve Langasek wrote:
> In the meantime, I don't see any reason why we shouldn't patch the kernel to
> disable hw iommu on nvidia systems only.  I believe the attached patch
> should do this.  Are you in a position to confirm that this does disable hw
> iommu for you?

The kernel already includes similar code for VIA chipsets. Why is this
snippet slightly different to the original one?

Upstream head uses
| static void __init via_bugs(void)
| {
| #ifdef CONFIG_IOMMU
|         if ((end_pfn > MAX_DMA32_PFN ||  force_iommu) &&
|             !iommu_aperture_allowed) {
|                 printk(KERN_INFO
|   "Looks like a VIA chipset. Disabling IOMMU. Override with iommu=allowed\n");
|                 iommu_aperture_disabled = 1;
|         }
| #endif
| }

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Andreas Barth <aba@not.so.argh.org>, Steve Langasek <vorlon@debian.org>
Cc: 404148@bugs.debian.org
Subject: Re: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 19:59:44 +0200
[Message part 1 (text/plain, inline)]
Andreas Barth wrote:
> BTW, we intended to have frequent kernel uploads to proposed-updates,
> and frankly speaking, I personally don't mind to already have a newer
> kernel in proposed-updates during the release, but that's something I
> want to have signed-off by Martin.
The main problem with the whole release-notes-only-issue is,... that
data corruption might already occur during installation. So even if the
user reads the release notes (I assume this happens mostly (if at all)
after installation) he might already have some corruptions.

Chris.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 404148@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: Sven Luther <luther@debian.org>
Cc: 404148@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 20:18:26 +0200
* Sven Luther (luther@debian.org) [070331 16:03]:
> The ideal would have been a framework where we could build new kernels and
> have it integrated within a few days only. I gave a speach about this at
> FOSDEM, of how we could use the initramfs incremental nature, to separate
> fully the kernel module .udebs from the rest of d-i, and have actual d-i
> images which are daily built, and usable independently of the kernel used.

Sven, sorry but this doesn't have anything to do with the installer now.
But that we refrain from making new uploads of the kernel less than a
week prior to release - for the simple reason the kernel *is* a central
component.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Sven Luther <luther@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 404148@bugs.debian.org (full text, mbox):

From: Sven Luther <luther@debian.org>
To: Andreas Barth <aba@not.so.argh.org>, 404148@bugs.debian.org
Cc: Sven Luther <luther@debian.org>, Steve Langasek <vorlon@debian.org>, Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 21:47:29 +0200
On Sat, Mar 31, 2007 at 08:18:26PM +0200, Andreas Barth wrote:
> * Sven Luther (luther@debian.org) [070331 16:03]:
> > The ideal would have been a framework where we could build new kernels and
> > have it integrated within a few days only. I gave a speach about this at
> > FOSDEM, of how we could use the initramfs incremental nature, to separate
> > fully the kernel module .udebs from the rest of d-i, and have actual d-i
> > images which are daily built, and usable independently of the kernel used.
> 
> Sven, sorry but this doesn't have anything to do with the installer now.
> But that we refrain from making new uploads of the kernel less than a
> week prior to release - for the simple reason the kernel *is* a central
> component.

So what ? The reality is that all progress in this direction was stoped cold
one year ago, with the consequences that we know, and that we face again the
exact same situation we had for sarge, which wwas released with a known
security hole.

Hurt,

Sven Luther



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 404148@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: Steve Langasek <vorlon@debian.org>, 404148@bugs.debian.org
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, aba@not.so.argh.org
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 14:32:12 -0600
On Sat, Mar 31, 2007 at 03:58:49AM -0700, Steve Langasek wrote:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> 
> > As I've told you in my email before I just tested your patch with the
> > following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> > testing, of course on an amd64 system):
> 
> > - The patch applies without problems
> > - The kernel compiles with it without problems (at least with my config)
> > - It boots correctly
> > - and it automatically disables the hardware iommu (look at my dmesg below):
> 
> Thanks, that's great to hear.

Agreed - good work on the patch Steve, and thanks for testing Christoph.

> > I would say (although I'm by any means not kernel expert) that your
> > patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> > You're the release manager,... so you should get managed this :-)
> 
> It wouldn't be appropriate for me to push this without the consent of the
> rest of the kernel team just because I'm the release manager; I'm not even
> an amd64 porter, this should be signed off on by the folks who are actually
> responsible for the amd64 kernel first.

I see no reason not to include it in r1, at least until upstream finds
something better. Does anyone disagree?

-- 
dann frazier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Bastian Blank <waldi@debian.org>, 404148@bugs.debian.org
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, Peter Green <Peter.Green@student.manchester.ac.uk>
Subject: Re: Bug#404148: i'm not convinced release notes are enough
Date: Sat, 31 Mar 2007 13:37:56 -0700
Hi Bastian,

On Sat, Mar 31, 2007 at 04:05:33PM +0200, Bastian Blank wrote:
> On Thu, Mar 22, 2007 at 01:15:31AM -0700, Steve Langasek wrote:
> > In the meantime, I don't see any reason why we shouldn't patch the kernel to
> > disable hw iommu on nvidia systems only.  I believe the attached patch
> > should do this.  Are you in a position to confirm that this does disable hw
> > iommu for you?

> The kernel already includes similar code for VIA chipsets. Why is this
> snippet slightly different to the original one?

> Upstream head uses
> | static void __init via_bugs(void)
> | {
> | #ifdef CONFIG_IOMMU
> |         if ((end_pfn > MAX_DMA32_PFN ||  force_iommu) &&
> |             !iommu_aperture_allowed) {
> |                 printk(KERN_INFO
> |   "Looks like a VIA chipset. Disabling IOMMU. Override with iommu=allowed\n");
> |                 iommu_aperture_disabled = 1;
> |         }
> | #endif
> | }

It's my understanding that this code for VIA is disabling *all* use of an
IOMMU aperture for DMA, whereas what we want for NVidia chips is only to
disable use of *hardware* IOMMU, hence the difference.

If I've misunderstood, I'll be happy to correct.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>, 404148@bugs.debian.org
Cc: Andreas Barth <aba@not.so.argh.org>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 14:20:23 -0700
On Sat, Mar 31, 2007 at 07:59:44PM +0200, Christoph Anton Mitterer wrote:
> Andreas Barth wrote:
> > BTW, we intended to have frequent kernel uploads to proposed-updates,
> > and frankly speaking, I personally don't mind to already have a newer
> > kernel in proposed-updates during the release, but that's something I
> > want to have signed-off by Martin.
> The main problem with the whole release-notes-only-issue is,... that
> data corruption might already occur during installation. So even if the
> user reads the release notes (I assume this happens mostly (if at all)
> after installation) he might already have some corruptions.

Well, there's no reason that someone can't use iommu=soft when booting the
installer, as well.  So perhaps it would be best to clone that bug and
include this information in the installation guide or errata?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 404148@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Steve Langasek <vorlon@debian.org>
Cc: 404148@bugs.debian.org, Andreas Barth <aba@not.so.argh.org>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Sat, 31 Mar 2007 23:29:23 +0200
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> Well, there's no reason that someone can't use iommu=soft when booting the
> installer, as well.  So perhaps it would be best to clone that bug and
> include this information in the installation guide or errata?
>   
Yes that's a good idea.

I assume it would be also a problem, too just set the installer to
iomm=soft (e.g. via the bootloader)?

One last thing perhaps. I'd include a link to the kernel.org bug report
in your release notes text and maybe some information that systems might
already have some data corruption (as this bug is not new).

btw: Is the kernel team now aware of your patch and will it use it in
following linux-* packages? i.e. in unstable?

Best wishes,
Chris.
[calestyo.vcf (text/x-vcard, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 404148@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: ak@suse.de
Cc: 404148@bugs.debian.org
Subject: disabling hw iommu on nvidia
Date: Mon, 2 Apr 2007 16:29:16 -0600
hey Andi,
 Debian is looking at patching our kernel to disable the hw iommu on
nvidia chipsets for the data corruption bug that's been discussed on
lkml[1]. As far as I can tell there isn't an upstream solution yet, but
Steve Langasek has proposed the following patch which seems to work
for one of our users. Would you mind taking a look at it and see if
you can pick out any obvious problems?

The full text of this discussion can be found at:
 http://bugs.debian.org/404148

[1] http://marc.info/?l=linux-kernel&m=116898325616149&w=2

--- a/arch/x86_64/kernel/io_apic.c	2007-03-22 00:54:33.000000000 -0700
+++ b/arch/x86_64/kernel/io_apic.c	2007-03-22 01:13:06.000000000 -0700
@@ -344,6 +344,22 @@
 						    "timer override.\n");
 					}
 #endif
+#ifdef CONFIG_IOMMU
+					/* Forcibly disabling nvidia HW iommu,
+					   per Debian bug #404148. */
+					if ((end_pfn > MAX_DMA32_PFN ||
+					     force_iommu) &&
+					    !iommu_aperture_allowed) {
+						printk(KERN_INFO
+    "Looks like an nvidia chipset. Disabling HW IOMMU. Override with \"iommu=allowed\"\n");
+#ifdef CONFIG_SWIOTLB
+						swiotlb = 1;
+#else
+						no_iommu = 1;
+#endif
+					}
+#endif
+
 					/* RED-PEN skip them on mptables too? */
 					return;
 
-- 
dann frazier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Andi Kleen <ak@suse.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #130 received at 404148@bugs.debian.org (full text, mbox):

From: Andi Kleen <ak@suse.de>
To: dann frazier <dannf@debian.org>
Cc: 404148@bugs.debian.org
Subject: Re: disabling hw iommu on nvidia
Date: Tue, 3 Apr 2007 00:37:09 +0200
On Tuesday 03 April 2007 00:29:16 dann frazier wrote:
> hey Andi,
>  Debian is looking at patching our kernel to disable the hw iommu on
> nvidia chipsets for the data corruption bug that's been discussed on
> lkml[1]. 

It would be better if you waited until the official solution. The
hardware debugging people are working on it. You'll likely get more
problems out of swiotlb because the defaults are too small for high
loads.

> As far as I can tell there isn't an upstream solution yet, but 
> Steve Langasek has proposed the following patch which seems to work
> for one of our users. Would you mind taking a look at it and see if
> you can pick out any obvious problems?

You got at least one off by one bug. And SWIOTLB cannot be undefined
with CONFIG_IOMMU so the nested ifdef is useless.

-Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #135 received at 404148@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: Andi Kleen <ak@suse.de>
Cc: 404148@bugs.debian.org
Subject: Re: Bug#404148: disabling hw iommu on nvidia
Date: Mon, 2 Apr 2007 16:48:24 -0600
On Tue, Apr 03, 2007 at 12:37:09AM +0200, Andi Kleen wrote:
> On Tuesday 03 April 2007 00:29:16 dann frazier wrote:
> > hey Andi,
> >  Debian is looking at patching our kernel to disable the hw iommu on
> > nvidia chipsets for the data corruption bug that's been discussed on
> > lkml[1]. 
> 
> It would be better if you waited until the official solution. The
> hardware debugging people are working on it. You'll likely get more
> problems out of swiotlb because the defaults are too small for high
> loads.
>
> > As far as I can tell there isn't an upstream solution yet, but 
> > Steve Langasek has proposed the following patch which seems to work
> > for one of our users. Would you mind taking a look at it and see if
> > you can pick out any obvious problems?
> 
> You got at least one off by one bug. And SWIOTLB cannot be undefined
> with CONFIG_IOMMU so the nested ifdef is useless.

Because of where we are in the release cycle we will have to wait a
little while anyway before we can do an update - hopefully the hw guys
will have had some success by then.

Thanks for the quick review!

-- 
dann frazier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #140 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Andi Kleen <ak@suse.de>, 404148@bugs.debian.org
Cc: dann frazier <dannf@debian.org>
Subject: Re: Bug#404148: disabling hw iommu on nvidia
Date: Mon, 2 Apr 2007 17:55:05 -0700
Hi Andi,

On Tue, Apr 03, 2007 at 12:37:09AM +0200, Andi Kleen wrote:
> On Tuesday 03 April 2007 00:29:16 dann frazier wrote:
> > hey Andi,
> >  Debian is looking at patching our kernel to disable the hw iommu on
> > nvidia chipsets for the data corruption bug that's been discussed on
> > lkml[1]. 

> It would be better if you waited until the official solution. The
> hardware debugging people are working on it. You'll likely get more
> problems out of swiotlb because the defaults are too small for high
> loads.

Are those problems going to be comparable in severity to the data corruption
currently reported?  As Dann notes, there's no immediate rush on this for us
since it won't go anywhere until the first point release of etch, but
nothing I've seen so far suggests there's any sort of ETA for an upstream
fix and I wouldn't want the point release to come and go without a
workaround while waiting for a proper fix.

> > As far as I can tell there isn't an upstream solution yet, but 
> > Steve Langasek has proposed the following patch which seems to work
> > for one of our users. Would you mind taking a look at it and see if
> > you can pick out any obvious problems?

> You got at least one off by one bug. And SWIOTLB cannot be undefined
> with CONFIG_IOMMU so the nested ifdef is useless.

Thanks for the feedback.  FWIW, I can only assume the off-by-one bug here is 

+                                       if ((end_pfn > MAX_DMA32_PFN ||

which means that there's already an off-by-one bug in the pristine version
of this file, since I copied that from the VIA handling up above. :)

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #145 received at 404148@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 404148@bugs.debian.org, Andreas Barth <aba@not.so.argh.org>
Subject: Re: Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Date: Wed, 4 Apr 2007 19:03:37 -0700
On Sat, Mar 31, 2007 at 11:29:23PM +0200, Christoph Anton Mitterer wrote:
> Steve Langasek wrote:
> > Well, there's no reason that someone can't use iommu=soft when booting the
> > installer, as well.  So perhaps it would be best to clone that bug and
> > include this information in the installation guide or errata?

> Yes that's a good idea.

> I assume it would be also a problem, too just set the installer to
> iomm=soft (e.g. via the bootloader)?

Yes, it is a problem; there is no window of opportunity for making such a
change before release (there was even less of one than for the kernel), and
the fix properly belongs in the kernel package, not in the installer or
bootloaders.

> One last thing perhaps. I'd include a link to the kernel.org bug report
> in your release notes text and maybe some information that systems might
> already have some data corruption (as this bug is not new).

Link to kernel.org is included; "systems might already have some data
corruption" is not relevant to the release notes that I can see, the release
notes are about upgrades from sarge which did not have this problem (because
it didn't support hw iommu at all).

> btw: Is the kernel team now aware of your patch and will it use it in
> following linux-* packages? i.e. in unstable?

The kernel team is aware of it, but no decision has been made yet to include
it in the kernel packages, since the verdict is still out upstream.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to gozdal@gozdal.com (Marcin Gozdalik):
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #150 received at 404148@bugs.debian.org (full text, mbox):

From: gozdal@gozdal.com (Marcin Gozdalik)
To: 404148@bugs.debian.org
Subject: Upstream patch by nVidia
Date: Fri, 4 May 2007 22:34:39 +0200
Hi

I've been following this discussion as this problem hits many of my
servers as well.

Recently an upstream patch has appeared:
http://groups.google.pl/group/linux.kernel/browse_thread/thread/4783711fa3d7592/dd12faec9a78f874

Is it possible to fix this problem in etch?

Best regards,
Marcin Gozdalik



Tags added: pending Request was from Dann Frazier <dannf@alioth.debian.org> to control@bugs.debian.org. (Fri, 04 May 2007 21:30:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#404148; Package linux-2.6. Full text and rfc822 format available.

Acknowledgement sent to dann frazier <dannf@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #157 received at 404148@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: Marcin Gozdalik <gozdal@gozdal.com>, 404148@bugs.debian.org, 404148-submitter@bugs.debian.org
Subject: Re: Bug#404148: Upstream patch by nVidia
Date: Fri, 4 May 2007 15:45:41 -0600
On Fri, May 04, 2007 at 10:34:39PM +0200, Marcin Gozdalik wrote:
> Hi
> 
> I've been following this discussion as this problem hits many of my
> servers as well.
> 
> Recently an upstream patch has appeared:
> http://groups.google.pl/group/linux.kernel/browse_thread/thread/4783711fa3d7592/dd12faec9a78f874
> 
> Is it possible to fix this problem in etch?

You bet! I've committed this to our repository, I'd appreciate it if
people with this hardware could test snapshot builds and reply to this
bug report to confirm that it does (or doesn't) fix the issue on your
system.

Snapshot builds are available here:
  deb http://kernel-archive.buildserver.net/debian-kernel etch main

Please try a version >= 2.6.18.dfsg.1-13~snapshot.8564 (should be
available within 24 hours).

-- 
dann frazier




Message sent on to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug#404148. Full text and rfc822 format available.

Tags added: fixed-upstream Request was from bts-link-upstream@lists.alioth.debian.org to control@bugs.debian.org. (Mon, 21 May 2007 12:39:02 GMT) Full text and rfc822 format available.

Reply sent to dann frazier <dannf@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #167 received at 404148-close@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: 404148-close@bugs.debian.org
Subject: Bug#404148: fixed in linux-2.6 2.6.18.dfsg.1-13
Date: Thu, 24 May 2007 21:16:50 +0000
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-13

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-13.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.diff.gz
linux-2.6_2.6.18.dfsg.1-13.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-source-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-support-2.6.18-5_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.18-5_2.6.18.dfsg.1-13_all.deb
linux-tree-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.18_2.6.18.dfsg.1-13_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 404148@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <dannf@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 21 May 2007 14:45:13 -0600
Source: linux-2.6
Binary: linux-image-2.6.18-5-s3c2410 linux-headers-2.6.18-5-all-s390 linux-headers-2.6.18-5-all-m68k linux-headers-2.6.18-5-xen-amd64 linux-image-2.6.18-5-iop32x linux-headers-2.6.18-5-all-alpha linux-image-2.6.18-5-r5k-cobalt linux-image-2.6.18-5-r5k-ip32 linux-headers-2.6.18-5-vserver-686 linux-headers-2.6.18-5-xen-vserver xen-linux-system-2.6.18-5-xen-686 linux-image-2.6.18-5-xen-amd64 linux-image-2.6.18-5-powerpc xen-linux-system-2.6.18-5-xen-vserver-686 linux-image-2.6.18-5-atari linux-headers-2.6.18-5-r3k-kn02 linux-headers-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-xen-vserver-686 linux-image-2.6.18-5-rpc linux-image-2.6.18-5-xen-686 linux-headers-2.6.18-5-vserver-s390x linux-image-2.6.18-5-parisc64-smp linux-headers-2.6.18-5-parisc64 linux-image-2.6.18-5-r4k-ip22 linux-headers-2.6.18-5 linux-headers-2.6.18-5-r5k-ip32 linux-headers-2.6.18-5-r5k-cobalt linux-headers-2.6.18-5-all-mipsel linux-headers-2.6.18-5-486 linux-headers-2.6.18-5-footbridge linux-image-2.6.18-5-vserver-powerpc64 linux-manual-2.6.18 linux-image-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-vserver-sparc64 linux-headers-2.6.18-5-vserver-k7 linux-headers-2.6.18-5-mckinley linux-headers-2.6.18-5-alpha-legacy linux-image-2.6.18-5-parisc-smp linux-headers-2.6.18-5-vserver linux-headers-2.6.18-5-xen linux-headers-2.6.18-5-rpc linux-modules-2.6.18-5-xen-686 linux-headers-2.6.18-5-k7 linux-image-2.6.18-5-r3k-kn02 linux-headers-2.6.18-5-qemu linux-headers-2.6.18-5-vserver-powerpc linux-headers-2.6.18-5-all-sparc linux-headers-2.6.18-5-alpha-smp linux-image-2.6.18-5-vserver-s390x linux-image-2.6.18-5-vserver-alpha linux-image-2.6.18-5-vserver-amd64 linux-headers-2.6.18-5-all-powerpc linux-headers-2.6.18-5-iop32x linux-image-2.6.18-5-footbridge linux-image-2.6.18-5-prep linux-headers-2.6.18-5-all-amd64 linux-image-2.6.18-5-powerpc64 linux-image-2.6.18-5-sb1a-bcm91480b linux-image-2.6.18-5-powerpc-smp linux-headers-2.6.18-5-all-arm linux-headers-2.6.18-5-itanium linux-headers-2.6.18-5-amd64 linux-image-2.6.18-5-powerpc-miboot xen-linux-system-2.6.18-5-xen-vserver-amd64 linux-headers-2.6.18-5-686-bigmem linux-headers-2.6.18-5-prep linux-headers-2.6.18-5-parisc-smp linux-headers-2.6.18-5-powerpc-miboot linux-headers-2.6.18-5-powerpc64 linux-image-2.6.18-5-vserver-k7 linux-headers-2.6.18-5-vserver-powerpc64 linux-image-2.6.18-5-alpha-smp linux-image-2.6.18-5-486 linux-headers-2.6.18-5-s390x linux-image-2.6.18-5-itanium linux-image-2.6.18-5-686-bigmem linux-headers-2.6.18-5-s390 linux-headers-2.6.18-5-mac linux-headers-2.6.18-5-xen-vserver-686 linux-doc-2.6.18 linux-headers-2.6.18-5-sparc64 linux-image-2.6.18-5-parisc64 linux-headers-2.6.18-5-all-i386 linux-headers-2.6.18-5-powerpc-smp linux-image-2.6.18-5-s390 linux-image-2.6.18-5-s390-tape linux-image-2.6.18-5-vserver-powerpc linux-headers-2.6.18-5-parisc linux-headers-2.6.18-5-xen-686 linux-headers-2.6.18-5-sparc64-smp linux-headers-2.6.18-5-686 linux-source-2.6.18 linux-headers-2.6.18-5-vserver-alpha linux-image-2.6.18-5-alpha-legacy linux-headers-2.6.18-5-sb1-bcm91250a linux-headers-2.6.18-5-ixp4xx linux-image-2.6.18-5-amiga linux-image-2.6.18-5-alpha-generic linux-modules-2.6.18-5-xen-vserver-686 linux-modules-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-r4k-kn04 linux-image-2.6.18-5-amd64 linux-headers-2.6.18-5-parisc64-smp linux-headers-2.6.18-5-powerpc linux-image-2.6.18-5-ixp4xx linux-image-2.6.18-5-parisc linux-support-2.6.18-5 linux-image-2.6.18-5-sparc64 linux-image-2.6.18-5-mac linux-headers-2.6.18-5-sparc32 linux-image-2.6.18-5-sparc64-smp linux-image-2.6.18-5-686 linux-headers-2.6.18-5-alpha-generic linux-headers-2.6.18-5-sb1a-bcm91480b linux-image-2.6.18-5-sb1-bcm91250a linux-headers-2.6.18-5-r4k-ip22 linux-image-2.6.18-5-s390x linux-patch-debian-2.6.18 xen-linux-system-2.6.18-5-xen-amd64 linux-headers-2.6.18-5-all-ia64 linux-headers-2.6.18-5-vserver-amd64 linux-headers-2.6.18-5-atari linux-image-2.6.18-5-vserver-686 linux-tree-2.6.18 linux-headers-2.6.18-5-amiga linux-image-2.6.18-5-sparc32 linux-headers-2.6.18-5-all-hppa linux-headers-2.6.18-5-s3c2410 linux-image-2.6.18-5-qemu linux-headers-2.6.18-5-r4k-kn04 linux-image-2.6.18-5-k7 linux-image-2.6.18-5-mckinley linux-headers-2.6.18-5-all linux-headers-2.6.18-5-all-mips linux-headers-2.6.18-5-vserver-sparc64 linux-modules-2.6.18-5-xen-amd64
Architecture: source sparc all
Version: 2.6.18.dfsg.1-13
Distribution: stable
Urgency: high
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: dann frazier <dannf@debian.org>
Description: 
 linux-doc-2.6.18 - Linux kernel specific documentation for version 2.6.18
 linux-headers-2.6.18-5 - Common header files for Linux 2.6.18
 linux-headers-2.6.18-5-all - All header files for Linux 2.6.18
 linux-headers-2.6.18-5-all-sparc - All header files for Linux 2.6.18
 linux-headers-2.6.18-5-sparc32 - Header files for Linux 2.6.18 on uniprocessor sparc32 (sun4m)
 linux-headers-2.6.18-5-sparc64 - Header files for Linux 2.6.18 on uniprocessor 64-bit UltraSPARC
 linux-headers-2.6.18-5-sparc64-smp - Header files for Linux 2.6.18 on multiprocessor 64-bit UltraSPARC
 linux-headers-2.6.18-5-vserver - Common header files for Linux 2.6.18
 linux-headers-2.6.18-5-vserver-sparc64 - Header files for Linux 2.6.18 on uniprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-sparc32 - Linux 2.6.18 image on uniprocessor sparc32 (sun4m)
 linux-image-2.6.18-5-sparc64 - Linux 2.6.18 image on uniprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-sparc64-smp - Linux 2.6.18 image on multiprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-vserver-sparc64 - Linux 2.6.18 image on uniprocessor 64-bit UltraSPARC
 linux-manual-2.6.18 - Linux kernel API manual pages for version 2.6.18
 linux-patch-debian-2.6.18 - Debian patches to version 2.6.18 of the Linux kernel
 linux-source-2.6.18 - Linux kernel source for version 2.6.18 with Debian patches
 linux-support-2.6.18-5 - Support files for Linux 2.6.18
 linux-tree-2.6.18 - Linux kernel source tree for building Debian kernel images
Closes: 404148 406111 412092 412132 412957 417629 417631 418076 418344 421281 421283
Changes: 
 linux-2.6 (2.6.18.dfsg.1-13) stable; urgency=high
 .
   [ Bastian Blank ]
   * [vserver] Fix overflow in network accounting. (closes: #412132)
   * [vserver] Fix lock accounting. (closes: #417631)
   * Bump ABI to 5.
   * Make modules packages binnmuable.
   * [sparc] Enable Qlogic QLA SCSI support. (closes: #417629)
 .
   [ dann frazier ]
   * bugfix/listxattr-mem-corruption.patch
     [SECURITY] Fix userspace corruption vulnerability caused by
     incorrectly promoted return values in bad_inode_ops
     This patch changes the kernel ABI.
     See CVE-2006-5753
   * bugfix/all/vserver/net-mount-fix.patch
     Fix mounting of network filesystems with VX_BINARY_MOUNT caps
     (closes: #418076)
   * Disable broken CONFIG_IP_ROUTE_MULTIPATH_CACHED setting. (closes: #418344)
   * bugfix/ipv6-disallow-RH0-by-default.patch
     [SECURITY] Avoid a remote DoS (network amplification between two routers)
     by disabling type0 IPv6 route headers by default. Can be re-enabled via
     a sysctl interface. Thanks to Vlad Yasevich for porting help.
     This patch changes the kernel ABI.
     See CVE-2007-2242
   * Fix an oops which potentially results in data corruption in the gdth driver.
     (closes: #412092)
   * bugfix/amd64-make-gart-ptes-uncacheable.patch
     Fix silent data corruption using GART iommu (closes: #404148)
 .
   [ maximilian attems ]
   * Backport support for i965 to agp too. (closes: #406111)
   * Compile fix for UML CONFIG_MODE_TT=y. (closes: #412957)
   * Fix ide-generic jmicron device conflict. (closes: #421281)
 .
   [ Martin Michlmayr ]
   * Fix wrong checksum for split TCP packets on 64-bit MIPS. (closes: #421283)
Files: 
 bace339ea7b8ed7ebabfed5461700f0f 5662 devel optional linux-2.6_2.6.18.dfsg.1-13.dsc
 f87cdba57dbd2fbbdbd2c818d8ecf0ad 5340463 devel optional linux-2.6_2.6.18.dfsg.1-13.diff.gz
 10876bd3f3217b213c5bb42384300773 3585346 doc optional linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
 ce5c380eed7833b6adbb38da2a086b08 1077592 doc optional linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
 ef07084ee13d812a37317bab6a52101d 1463436 devel optional linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
 af7a7c93b556879b4bb4a91045910032 41418284 devel optional linux-source-2.6.18_2.6.18.dfsg.1-13_all.deb
 4c1f3a1c6f499a0fe5ee9b23f5356239 3778070 devel optional linux-support-2.6.18-5_2.6.18.dfsg.1-13_all.deb
 40bf6574840570f5f505dabc14e3a676 50596 devel optional linux-tree-2.6.18_2.6.18.dfsg.1-13_all.deb
 21b8e6b3cef5f7251cb86f25d7729c6f 50156 devel optional linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
 1c88897eef382c74675db7a121a7a533 50178 devel optional linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
 737f695dc20acb18931c56bcd36839e0 3164004 devel optional linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
 ddb8850e99a1a82c8bce9c935dbf4052 6405780 admin optional linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
 9463625de5329fa62b000e1d38dba5a2 161410 devel optional linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
 779baff1bd7871c66bbd75deb9a5a5b8 10350008 admin optional linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
 72918c0468a4042aa9dbd23a492719f0 190640 devel optional linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
 d8fa404ae02cf9915d2efc5b262d11a0 10610286 admin optional linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
 a993b8698acf372781a7704101551f1c 191342 devel optional linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
 95d8e55cc3affd99dabc5372f9498715 3186368 devel optional linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
 fc344edcbfc6cfdb3d21a15aca40abab 10656040 admin optional linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
 92926d78fa4bed7a1b4f29d504f39775 191774 devel optional linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGU6oahuANDBmkLRkRAtkTAJ9XkEkwaoVsvcB5UIqXnytJkzZsIgCdHpYV
az5T87l0ws9BGxLre1iPsck=
=7tsc
-----END PGP SIGNATURE-----




Reply sent to dann frazier <dannf@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #172 received at 404148-close@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: 404148-close@bugs.debian.org
Subject: Bug#404148: fixed in linux-2.6 2.6.18.dfsg.1-13lenny1
Date: Thu, 24 May 2007 21:27:01 +0000
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-13lenny1

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-13lenny1.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13lenny1.diff.gz
linux-2.6_2.6.18.dfsg.1-13lenny1.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13lenny1.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-manual-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
linux-source-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
linux-support-2.6.18-5_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.18-5_2.6.18.dfsg.1-13lenny1_all.deb
linux-tree-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 404148@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <dannf@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 21 May 2007 14:45:13 -0600
Source: linux-2.6
Binary: linux-image-2.6.18-5-s3c2410 linux-headers-2.6.18-5-all-s390 linux-headers-2.6.18-5-all-m68k linux-headers-2.6.18-5-xen-amd64 linux-image-2.6.18-5-iop32x linux-headers-2.6.18-5-all-alpha linux-image-2.6.18-5-r5k-cobalt linux-image-2.6.18-5-r5k-ip32 linux-headers-2.6.18-5-vserver-686 linux-headers-2.6.18-5-xen-vserver xen-linux-system-2.6.18-5-xen-686 linux-image-2.6.18-5-xen-amd64 linux-image-2.6.18-5-powerpc xen-linux-system-2.6.18-5-xen-vserver-686 linux-image-2.6.18-5-atari linux-headers-2.6.18-5-r3k-kn02 linux-headers-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-xen-vserver-686 linux-image-2.6.18-5-rpc linux-image-2.6.18-5-xen-686 linux-headers-2.6.18-5-vserver-s390x linux-image-2.6.18-5-parisc64-smp linux-headers-2.6.18-5-parisc64 linux-image-2.6.18-5-r4k-ip22 linux-headers-2.6.18-5 linux-headers-2.6.18-5-r5k-ip32 linux-headers-2.6.18-5-r5k-cobalt linux-headers-2.6.18-5-all-mipsel linux-headers-2.6.18-5-486 linux-headers-2.6.18-5-footbridge linux-image-2.6.18-5-vserver-powerpc64 linux-manual-2.6.18 linux-image-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-vserver-sparc64 linux-headers-2.6.18-5-vserver-k7 linux-headers-2.6.18-5-mckinley linux-headers-2.6.18-5-alpha-legacy linux-image-2.6.18-5-parisc-smp linux-headers-2.6.18-5-vserver linux-headers-2.6.18-5-xen linux-headers-2.6.18-5-rpc linux-modules-2.6.18-5-xen-686 linux-headers-2.6.18-5-k7 linux-image-2.6.18-5-r3k-kn02 linux-headers-2.6.18-5-qemu linux-headers-2.6.18-5-vserver-powerpc linux-headers-2.6.18-5-all-sparc linux-headers-2.6.18-5-alpha-smp linux-image-2.6.18-5-vserver-s390x linux-image-2.6.18-5-vserver-alpha linux-image-2.6.18-5-vserver-amd64 linux-headers-2.6.18-5-all-powerpc linux-headers-2.6.18-5-iop32x linux-image-2.6.18-5-footbridge linux-image-2.6.18-5-prep linux-headers-2.6.18-5-all-amd64 linux-image-2.6.18-5-powerpc64 linux-image-2.6.18-5-sb1a-bcm91480b linux-image-2.6.18-5-powerpc-smp linux-headers-2.6.18-5-all-arm linux-headers-2.6.18-5-itanium linux-headers-2.6.18-5-amd64 linux-image-2.6.18-5-powerpc-miboot xen-linux-system-2.6.18-5-xen-vserver-amd64 linux-headers-2.6.18-5-686-bigmem linux-headers-2.6.18-5-prep linux-headers-2.6.18-5-parisc-smp linux-headers-2.6.18-5-powerpc-miboot linux-headers-2.6.18-5-powerpc64 linux-image-2.6.18-5-vserver-k7 linux-headers-2.6.18-5-vserver-powerpc64 linux-image-2.6.18-5-alpha-smp linux-image-2.6.18-5-486 linux-headers-2.6.18-5-s390x linux-image-2.6.18-5-itanium linux-image-2.6.18-5-686-bigmem linux-headers-2.6.18-5-s390 linux-headers-2.6.18-5-mac linux-headers-2.6.18-5-xen-vserver-686 linux-doc-2.6.18 linux-headers-2.6.18-5-sparc64 linux-image-2.6.18-5-parisc64 linux-headers-2.6.18-5-all-i386 linux-headers-2.6.18-5-powerpc-smp linux-image-2.6.18-5-s390 linux-image-2.6.18-5-s390-tape linux-image-2.6.18-5-vserver-powerpc linux-headers-2.6.18-5-parisc linux-headers-2.6.18-5-xen-686 linux-headers-2.6.18-5-sparc64-smp linux-headers-2.6.18-5-686 linux-source-2.6.18 linux-headers-2.6.18-5-vserver-alpha linux-image-2.6.18-5-alpha-legacy linux-headers-2.6.18-5-sb1-bcm91250a linux-headers-2.6.18-5-ixp4xx linux-image-2.6.18-5-amiga linux-image-2.6.18-5-alpha-generic linux-modules-2.6.18-5-xen-vserver-686 linux-modules-2.6.18-5-xen-vserver-amd64 linux-image-2.6.18-5-r4k-kn04 linux-image-2.6.18-5-amd64 linux-headers-2.6.18-5-parisc64-smp linux-headers-2.6.18-5-powerpc linux-image-2.6.18-5-ixp4xx linux-image-2.6.18-5-parisc linux-support-2.6.18-5 linux-image-2.6.18-5-sparc64 linux-image-2.6.18-5-mac linux-headers-2.6.18-5-sparc32 linux-image-2.6.18-5-sparc64-smp linux-image-2.6.18-5-686 linux-headers-2.6.18-5-alpha-generic linux-headers-2.6.18-5-sb1a-bcm91480b linux-image-2.6.18-5-sb1-bcm91250a linux-headers-2.6.18-5-r4k-ip22 linux-image-2.6.18-5-s390x linux-patch-debian-2.6.18 xen-linux-system-2.6.18-5-xen-amd64 linux-headers-2.6.18-5-all-ia64 linux-headers-2.6.18-5-vserver-amd64 linux-headers-2.6.18-5-atari linux-image-2.6.18-5-vserver-686 linux-tree-2.6.18 linux-headers-2.6.18-5-amiga linux-image-2.6.18-5-sparc32 linux-headers-2.6.18-5-all-hppa linux-headers-2.6.18-5-s3c2410 linux-image-2.6.18-5-qemu linux-headers-2.6.18-5-r4k-kn04 linux-image-2.6.18-5-k7 linux-image-2.6.18-5-mckinley linux-headers-2.6.18-5-all linux-headers-2.6.18-5-all-mips linux-headers-2.6.18-5-vserver-sparc64 linux-modules-2.6.18-5-xen-amd64
Architecture: source sparc all
Version: 2.6.18.dfsg.1-13lenny1
Distribution: testing
Urgency: high
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: dann frazier <dannf@debian.org>
Description: 
 linux-doc-2.6.18 - Linux kernel specific documentation for version 2.6.18
 linux-headers-2.6.18-5 - Common header files for Linux 2.6.18
 linux-headers-2.6.18-5-all - All header files for Linux 2.6.18
 linux-headers-2.6.18-5-all-sparc - All header files for Linux 2.6.18
 linux-headers-2.6.18-5-sparc32 - Header files for Linux 2.6.18 on uniprocessor sparc32 (sun4m)
 linux-headers-2.6.18-5-sparc64 - Header files for Linux 2.6.18 on uniprocessor 64-bit UltraSPARC
 linux-headers-2.6.18-5-sparc64-smp - Header files for Linux 2.6.18 on multiprocessor 64-bit UltraSPARC
 linux-headers-2.6.18-5-vserver - Common header files for Linux 2.6.18
 linux-headers-2.6.18-5-vserver-sparc64 - Header files for Linux 2.6.18 on uniprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-sparc32 - Linux 2.6.18 image on uniprocessor sparc32 (sun4m)
 linux-image-2.6.18-5-sparc64 - Linux 2.6.18 image on uniprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-sparc64-smp - Linux 2.6.18 image on multiprocessor 64-bit UltraSPARC
 linux-image-2.6.18-5-vserver-sparc64 - Linux 2.6.18 image on uniprocessor 64-bit UltraSPARC
 linux-manual-2.6.18 - Linux kernel API manual pages for version 2.6.18
 linux-patch-debian-2.6.18 - Debian patches to version 2.6.18 of the Linux kernel
 linux-source-2.6.18 - Linux kernel source for version 2.6.18 with Debian patches
 linux-support-2.6.18-5 - Support files for Linux 2.6.18
 linux-tree-2.6.18 - Linux kernel source tree for building Debian kernel images
Closes: 404148 406111 412092 412132 412957 417629 417631 418076 418344 421281 421283
Changes: 
 linux-2.6 (2.6.18.dfsg.1-13lenny1) testing; urgency=high
 .
   [ Bastian Blank ]
   * [vserver] Fix overflow in network accounting. (closes: #412132)
   * [vserver] Fix lock accounting. (closes: #417631)
   * Bump ABI to 5.
   * Make modules packages binnmuable.
   * [sparc] Enable Qlogic QLA SCSI support. (closes: #417629)
 .
   [ dann frazier ]
   * bugfix/listxattr-mem-corruption.patch
     [SECURITY] Fix userspace corruption vulnerability caused by
     incorrectly promoted return values in bad_inode_ops
     This patch changes the kernel ABI.
     See CVE-2006-5753
   * bugfix/all/vserver/net-mount-fix.patch
     Fix mounting of network filesystems with VX_BINARY_MOUNT caps
     (closes: #418076)
   * Disable broken CONFIG_IP_ROUTE_MULTIPATH_CACHED setting. (closes: #418344)
   * bugfix/ipv6-disallow-RH0-by-default.patch
     [SECURITY] Avoid a remote DoS (network amplification between two routers)
     by disabling type0 IPv6 route headers by default. Can be re-enabled via
     a sysctl interface. Thanks to Vlad Yasevich for porting help.
     This patch changes the kernel ABI.
     See CVE-2007-2242
   * Fix an oops which potentially results in data corruption in the gdth driver.
     (closes: #412092)
   * bugfix/amd64-make-gart-ptes-uncacheable.patch
     Fix silent data corruption using GART iommu (closes: #404148)
 .
   [ maximilian attems ]
   * Backport support for i965 to agp too. (closes: #406111)
   * Compile fix for UML CONFIG_MODE_TT=y. (closes: #412957)
   * Fix ide-generic jmicron device conflict. (closes: #421281)
 .
   [ Martin Michlmayr ]
   * Fix wrong checksum for split TCP packets on 64-bit MIPS. (closes: #421283)
Files: 
 75b3eedcb9d253cb14ee6e22415a85d2 5674 devel optional linux-2.6_2.6.18.dfsg.1-13lenny1.dsc
 50f9fc5a75b90e1e0194c14787b26ab8 5340591 devel optional linux-2.6_2.6.18.dfsg.1-13lenny1.diff.gz
 40287b4620d6656dec80f556942dbd7d 3607830 doc optional linux-doc-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
 9ceb3cf71ac8911f1538ee798ffd00d4 1074954 doc optional linux-manual-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
 7b7e7688ce2abcda7bbb9f2b7543b9c3 1463480 devel optional linux-patch-debian-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
 facab9e65a6b0697a423e8d7ea9a0b88 41417006 devel optional linux-source-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
 c0f46792d9ac92fb29090750c9219813 3778224 devel optional linux-support-2.6.18-5_2.6.18.dfsg.1-13lenny1_all.deb
 c44840bb6e73f5c9ddd22e3c1260cf5d 50604 devel optional linux-tree-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
 e69bc01913512b12c394e250a2886b09 50158 devel optional linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13lenny1_sparc.deb
 405fba716c6668c1c270e3927b368d49 50184 devel optional linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13lenny1_sparc.deb
 0335b2e1f02717173615c404643557a0 3163976 devel optional linux-headers-2.6.18-5_2.6.18.dfsg.1-13lenny1_sparc.deb
 57dbdfef212c4615f25899619d677009 6405798 admin optional linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
 488f882e0f5fa2a6f2c48729b6940a0f 161350 devel optional linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
 8908e58175418d49878e124867f295f0 10349990 admin optional linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
 2c9ac125555eb765e9ac375c42837df3 190578 devel optional linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
 fc18cd6f7d253abc261c2dae3ed4ca69 10610136 admin optional linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
 9db2ee3fd2255dff61e678a13c618542 191332 devel optional linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
 867dba2493174c01845d3cdb3cd72d08 3186426 devel optional linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13lenny1_sparc.deb
 28fcbe57e864862729eac4f2a0f1073d 10656456 admin optional linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
 5b6ef42a31830a8629bcd1902be494d3 191748 devel optional linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGVKF/huANDBmkLRkRArIfAJ9fqjosutZ4/1wMHF7i3ryC5ylJagCfVYgm
da1GVhG5unx1JV5h0WovvBs=
=S1AY
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 11 Jul 2007 07:51:28 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 13:57:19 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.