Your message dated Thu, 24 May 2007 21:16:50 +
with message-id [EMAIL PROTECTED]
and subject line Bug#404148: fixed in linux-2.6 2.6.18.dfsg.1-13
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Your message dated Thu, 24 May 2007 21:27:01 +
with message-id [EMAIL PROTECTED]
and subject line Bug#404148: fixed in linux-2.6 2.6.18.dfsg.1-13lenny1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
On Mon, May 07, 2007 at 05:02:15PM +0200, ?ukasz Buczy?ski / Gadu-Gadu S.A.
wrote:
Hi.
i'v been following discussion and you reply with etch repo on this address:
deb http://kernel-archive.buildserver.net/debian-kernel etch main
i saw that there is .deb files for other architecture not for
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
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:
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
+ /* Forcibly disabling nvidia HW iommu,
+ per Debian bug #404148. */
+ if ((end_pfn MAX_DMA32_PFN ||
+force_iommu)
+ !iommu_aperture_allowed
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
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
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
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
-
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
* Steve Langasek ([EMAIL PROTECTED]) [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
On Sat, Mar 31, 2007 at 03:11:09PM +0200, Andreas Barth wrote:
* Steve Langasek ([EMAIL PROTECTED]) [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
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
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
* Sven Luther ([EMAIL PROTECTED]) [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
On Sat, Mar 31, 2007 at 08:18:26PM +0200, Andreas Barth wrote:
* Sven Luther ([EMAIL PROTECTED]) [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
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
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
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
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,
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
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.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email
-22 00:54:33.0 -0700
+++ b/arch/x86_64/kernel/io_apic.c 2007-03-22 01:13:06.0 -0700
@@ -344,6 +344,22 @@
timer override.\n);
}
#endif
+#ifdef CONFIG_IOMMU
+ /* Forcibly disabling nvidia HW iommu,
+ per Debian bug #404148. */
+ if ((end_pfn
Processing commands for [EMAIL PROTECTED]:
tags 404148 patch
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives //
memory hole mapping related bug?!
There were no tags set.
Tags added: patch
thanks
Stopping processing here.
Please contact me if you need assistance
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
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
On Tue, Mar 13, 2007 at 09:01:03PM +, 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
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
Processing commands for [EMAIL PROTECTED]:
forwarded 404148 http://bugzilla.kernel.org/show_bug.cgi?id=7768
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives //
memory hole mapping related bug?!
Noted your statement that Bug has been forwarded to
http
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
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
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
34 matches
Mail list logo
