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
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
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
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
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
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
16 matches
Mail list logo
