Hi!
> Pavel, I tried with your .config, and indeed the system came back to life
> after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test
Hi!
Pavel, I tried with your .config, and indeed the system came back to life
after
2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
It could be that the same takes place with my original .config - maybe
I just wasn't patient enough. I'll need to re-test that.
On Mon, Mar 05 2007, Michael S. Tsirkin wrote:
> > Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> > git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
> >
> > 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
>
> I have confirmed these two on my system.
BTW, the key here
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> > git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
> >
> > 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
>
> I have confirmed these two on my system.
you could probably
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
>
> 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
I have confirmed these two on my system.
--
MST
-
To unsubscribe from this list: send the line "unsubscribe
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
>
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > I'll try what i've described in the previous mail: mark all bisection
> > points that do not
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
>
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
>
> update: f3ccb06f3b8e0cf
> Quoting Pavel Machek <[EMAIL PROTECTED]>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
>
> Hi!
>
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> >
> > u
Quoting Pavel Machek [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
Hi!
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
* Ingo Molnar [EMAIL PROTECTED] wrote:
I'll try what i've described in the previous mail: mark all bisection
points that do not include f3ccb06f as 'good' - thus 'merging' the
known-bad area
Quoting Ingo Molnar [EMAIL PROTECTED]:
git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
I have confirmed these two on my system.
--
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Ingo Molnar [EMAIL PROTECTED]:
git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
I have confirmed these two on my system.
you could probably get quite a
On Mon, Mar 05 2007, Michael S. Tsirkin wrote:
Quoting Ingo Molnar [EMAIL PROTECTED]:
git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
I have confirmed these two on my system.
BTW, the key here seems to be
Hi!
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
>
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
> to bisect this.
Strange; on
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> I'll now try the following: i'll try to manually apply Len's fix to
> every tree that git-bisect offers me, in the hope of being able to
> isolate the /other/ bug.
>
> [ But really, i'm not expecting any miracles because this is way out of
> league
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> I'll try what i've described in the previous mail: mark all bisection
> points that do not include f3ccb06f as 'good' - thus 'merging' the
> known-bad area with the first known-good commit, and thus eliminating
> it from the bisection space.
this
Hi!
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
Strange; on my x60,
* Ingo Molnar [EMAIL PROTECTED] wrote:
I'll try what i've described in the previous mail: mark all bisection
points that do not include f3ccb06f as 'good' - thus 'merging' the
known-bad area with the first known-good commit, and thus eliminating
it from the bisection space.
this got me
* Ingo Molnar [EMAIL PROTECTED] wrote:
I'll now try the following: i'll try to manually apply Len's fix to
every tree that git-bisect offers me, in the hope of being able to
isolate the /other/ bug.
[ But really, i'm not expecting any miracles because this is way out of
league for
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But most likely, 9f4bd5dd is actually already bad, and what you are
> seeing is two *different* bugs that just have the same symptoms
> ("suspend doesn't work").
the situation is simpler than that: there is a /known/ bug, and i marked
the bugfix
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Btw, you seem to have re-ordered the commits - the above is not the
> order you did the bisection in. The known-good commit (f3ccb06..) is
> in the middle. [...]
no - i simply picked them by hand, based on looking at gittk output,
because
On Thu, 1 Mar 2007, Linus Torvalds wrote:
>
> Once you have that, you now actually have a way to "correct" for that
> known bug, and by correcting for the known bug, you now *can* separate the
> behaviour of the two bugs:
>
> - You can now re-do a totally mindless git bisection for the
On Thu, 1 Mar 2007, Ingo Molnar wrote:
>
> git-bisect gets royally confused on those ACPI merge branches around
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test
> results so far:
Looks like git bisect worked for you, and wasn't confused at all. You
started out with 2931
On Thu, 1 Mar 2007, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
> > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
> > to bisect this.
>
> hm. There's some weird
On Thursday, 1 March 2007 15:52, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm. There's some weird bisection artifact here. Here are the commits i
> > tested, in git-log order:
> >
> > #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> > #2 commit
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm. There's some weird bisection artifact here. Here are the commits i
> tested, in git-log order:
>
> #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> #3 commit
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
> to bisect this.
hm. There's some weird bisection artifact here. Here are the commits i
tested, in
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
Ingo
-
To unsubscribe
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
Ingo
-
To unsubscribe from
* Ingo Molnar [EMAIL PROTECTED] wrote:
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
hm. There's some weird bisection artifact here. Here are the commits i
tested, in git-log
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. There's some weird bisection artifact here. Here are the commits i
tested, in git-log order:
#1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
#2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
#3 commit
On Thursday, 1 March 2007 15:52, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. There's some weird bisection artifact here. Here are the commits i
tested, in git-log order:
#1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
#2 commit
On Thu, 1 Mar 2007, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
hm. There's some weird bisection artifact
On Thu, 1 Mar 2007, Ingo Molnar wrote:
git-bisect gets royally confused on those ACPI merge branches around
commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test
results so far:
Looks like git bisect worked for you, and wasn't confused at all. You
started out with 2931
On Thu, 1 Mar 2007, Linus Torvalds wrote:
Once you have that, you now actually have a way to correct for that
known bug, and by correcting for the known bug, you now *can* separate the
behaviour of the two bugs:
- You can now re-do a totally mindless git bisection for the *other* bug,
* Linus Torvalds [EMAIL PROTECTED] wrote:
Btw, you seem to have re-ordered the commits - the above is not the
order you did the bisection in. The known-good commit (f3ccb06..) is
in the middle. [...]
no - i simply picked them by hand, based on looking at gittk output,
because bisection
* Linus Torvalds [EMAIL PROTECTED] wrote:
But most likely, 9f4bd5dd is actually already bad, and what you are
seeing is two *different* bugs that just have the same symptoms
(suspend doesn't work).
the situation is simpler than that: there is a /known/ bug, and i marked
the bugfix commit
On Tue, Feb 27 2007, Adrian Bunk wrote:
> On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> > On Sun, Feb 25 2007, Adrian Bunk wrote:
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > >
> > > If you find
On Tue, Feb 27 2007, Adrian Bunk wrote:
On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
On Sun, Feb 25 2007, Adrian Bunk wrote:
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the
On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> On Sun, Feb 25 2007, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> >
> > If you find your name in the Cc header, you are either submitter of
On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Jens Axboe wrote:
> > On Tue, Feb 27 2007, Ingo Molnar wrote:
> > >
> > > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> > >
> > > > > > x60 doesn't resume from S2R either, it doesn't matter if
> > > > > > CONFIG_NO_HZ is set or not
On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Ingo Molnar wrote:
> >
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > > > x60 doesn't resume from S2R either, it doesn't matter if
> > > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > >
> > > > It somehow
On Tue, Feb 27 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > > x60 doesn't resume from S2R either, it doesn't matter if
> > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > >
> > > It somehow works for me. As long as I do not play with bluetooth and
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > x60 doesn't resume from S2R either, it doesn't matter if
> > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> >
> > It somehow works for me. As long as I do not play with bluetooth and
> > suspend to disk...
>
> It locks solid here on
On Tue, Feb 27 2007, Pavel Machek wrote:
> Hi!
>
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > >
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an
Hi!
> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused
On Sun, Feb 25 2007, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> that are not yet fixed in Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver,
On Sun, Feb 25 2007, Adrian Bunk wrote:
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a
Hi!
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage
On Tue, Feb 27 2007, Pavel Machek wrote:
Hi!
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected
* Jens Axboe [EMAIL PROTECTED] wrote:
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
It somehow works for me. As long as I do not play with bluetooth and
suspend to disk...
It locks solid here on resume, going
On Tue, Feb 27 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
It somehow works for me. As long as I do not play with bluetooth and
suspend to
On Tue, Feb 27 2007, Jens Axboe wrote:
On Tue, Feb 27 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
It somehow works for me. As long as I do
On Tue, Feb 27 2007, Jens Axboe wrote:
On Tue, Feb 27 2007, Jens Axboe wrote:
On Tue, Feb 27 2007, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
On Sun, Feb 25 2007, Adrian Bunk wrote:
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
58 matches
Mail list logo
