Re: [linux-pm] 2.6.21-rc1: known regressions (part 2)
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. > > However, I noticed that, after resume, when the system is presumably > functional, > if I try to suspend to ram again, this second suspend hangs, displaying > the following on screen: > > [ 17.17] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> > IRQ 20 > [ 17.17] PCI: Setting latency timer of device :02:00.0 to 64 > [ 17.25] e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width > x1) 00:16:41:5 > 4:6c:47 > [ 17.33] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > the crescent LED starts blinking and does not seem to stop for at lest 10 min, > I've run out of patience after that. It could be that it's just very slow > again. > > Pavel, did you try suspend to RAM after a successfull resume from > RAM? Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] 2.6.21-rc1: known regressions (part 2)
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. However, I noticed that, after resume, when the system is presumably functional, if I try to suspend to ram again, this second suspend hangs, displaying the following on screen: [ 17.17] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 20 [ 17.17] PCI: Setting latency timer of device :02:00.0 to 64 [ 17.25] e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5 4:6c:47 [ 17.33] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection the crescent LED starts blinking and does not seem to stop for at lest 10 min, I've run out of patience after that. It could be that it's just very slow again. Pavel, did you try suspend to RAM after a successfull resume from RAM? Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 CONFIG_CC_OPTIMIZE_FOR_SIZE, at least that is my current guess looking at the config options I still need to test whether they make a difference. Either that, or the vmsplit option got broken again. I'm attaching my x60 config that works for me. -- Jens Axboe .config Description: application/config
Re: 2.6.21-rc1: known regressions (part 2)
* 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 bit further in bisecting the other
breakage, by using the following method:
manully apply the patch below to 81450b73dde and retest. It will most
likely work. Then FIRST unapply the patch and mark the tree via
'git-bisect good' and continue the bisection. Then try to apply the
patch again. If it's already included - ignore the rejected patch.
Whenever git-bisect offers you a new commit, just try to apply the
patch. Ok? This way you'll be able to avoid the known ACPI breakage, and
zoom in on the unknown breakage.
Ingo
>
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
Author: Alexey Starikovskiy <[EMAIL PROTECTED]>
Date: Tue Feb 13 02:35:50 2007 -0500
ACPI: Disable wake GPEs only once.
fixes Suspend/Resume regressions due to recent ACPICA update.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index dfac3ec..635ba44 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -636,17 +636,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info
*gpe_event_info, u32 gpe_number)
}
}
- if (!acpi_gbl_system_awake_and_running) {
- /*
-* We just woke up because of a wake GPE. Disable any further
GPEs
-* until we are fully up and running (Only wake GPEs should be
enabled
-* at this time, but we just brute-force disable them all.)
-* 1) We must disable this particular wake GPE so it won't fire
again
-* 2) We want to disable all wake GPEs, since we are now awake
-*/
- (void)acpi_hw_disable_all_gpes();
- }
-
/*
* Dispatch the GPE to either an installed handler, or the control
method
* associated with this GPE (_Lxx or _Exx). If a handler exists, we
invoke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
> 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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
> 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 with the first known-good commit, and thus eliminating > > it from the bisection space. > > this got me quite a bit further: > > git-bisect start > git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d > git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 > git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7 > git-bisect bad d43a338e395371733a80ec473b40baac5f74d768 > git-bisect bad 255f0385c8e0d6b9005c0e09fffb5bd852f3b506 > git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d > git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658 > git-bisect bad 81450b73dde07f473a4a7208b209b4c8b7251d90 > git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab > git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf > git-bisect good 5c95d3f5783ab184f64b7848f0a871352c35c3cf > git-bisect good ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45 > git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a I just confirmed that 0539771d7236b425f285652f6f297cc7939c8f9a is good for me, too. > 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit Going to test that now. -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
> 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, and > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt > to bisect this. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too. -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
> 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, and > > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt > > to bisect this. > > Strange; on my x60, suspend to ram works okay. > > (Resume is very slow, because disks are not spinned up properly; and > there's something wrong with timers; console beeps take way too long). > > dmesg attached. > > That's with > > commit 7b965e0884cee430ffe5dc81cdb117b9316b0549 > tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1 > parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f > author Trond Myklebust <[EMAIL PROTECTED]> Wed, 28 Feb 2007 > 20:13:55 -0800 > committer Linus Torvalds <[EMAIL PROTECTED]> Thu, 01 > Mar 2007 14:53:39 -0800 > > [PATCH] VM: invalidate_inode_pages2_range() should not exit early > > Fix invalidate_inode_pages2_range() so that it does not > immediately exit > just because a single page in the specified range could not be > removed. > > Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> 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. However, I noticed that, after resume, when the system is presumably functional, if I try to suspend to ram again, this second suspend hangs, displaying the following on screen: [ 17.17] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 17.17] PCI: Setting latency timer of device :02:00.0 to 64 [ 17.25] e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5 4:6c:47 [ 17.33] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection the crescent LED starts blinking and does not seem to stop for at lest 10 min, I've run out of patience after that. It could be that it's just very slow again. Pavel, did you try suspend to RAM after a successfull resume from RAM? Under 2.6.20, the system suspends/resumes to memory within about 20 sec any number of times. -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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, and 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt to bisect this. Strange; on my x60, suspend to ram works okay. (Resume is very slow, because disks are not spinned up properly; and there's something wrong with timers; console beeps take way too long). dmesg attached. That's with commit 7b965e0884cee430ffe5dc81cdb117b9316b0549 tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1 parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f author Trond Myklebust [EMAIL PROTECTED] Wed, 28 Feb 2007 20:13:55 -0800 committer Linus Torvalds [EMAIL PROTECTED] Thu, 01 Mar 2007 14:53:39 -0800 [PATCH] VM: invalidate_inode_pages2_range() should not exit early Fix invalidate_inode_pages2_range() so that it does not immediately exit just because a single page in the specified range could not be removed. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] 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. However, I noticed that, after resume, when the system is presumably functional, if I try to suspend to ram again, this second suspend hangs, displaying the following on screen: [ 17.17] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 20 [ 17.17] PCI: Setting latency timer of device :02:00.0 to 64 [ 17.25] e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5 4:6c:47 [ 17.33] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection the crescent LED starts blinking and does not seem to stop for at lest 10 min, I've run out of patience after that. It could be that it's just very slow again. Pavel, did you try suspend to RAM after a successfull resume from RAM? Under 2.6.20, the system suspends/resumes to memory within about 20 sec any number of times. -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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, and 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt to bisect this. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too. -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 with the first known-good commit, and thus eliminating it from the bisection space. this got me quite a bit further: git-bisect start git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7 git-bisect bad d43a338e395371733a80ec473b40baac5f74d768 git-bisect bad 255f0385c8e0d6b9005c0e09fffb5bd852f3b506 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658 git-bisect bad 81450b73dde07f473a4a7208b209b4c8b7251d90 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf git-bisect good 5c95d3f5783ab184f64b7848f0a871352c35c3cf git-bisect good ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45 git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a I just confirmed that 0539771d7236b425f285652f6f297cc7939c8f9a is good for me, too. 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit Going to test that now. -- MST - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 bit further in bisecting the other
breakage, by using the following method:
manully apply the patch below to 81450b73dde and retest. It will most
likely work. Then FIRST unapply the patch and mark the tree via
'git-bisect good' and continue the bisection. Then try to apply the
patch again. If it's already included - ignore the rejected patch.
Whenever git-bisect offers you a new commit, just try to apply the
patch. Ok? This way you'll be able to avoid the known ACPI breakage, and
zoom in on the unknown breakage.
Ingo
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
Author: Alexey Starikovskiy [EMAIL PROTECTED]
Date: Tue Feb 13 02:35:50 2007 -0500
ACPI: Disable wake GPEs only once.
fixes Suspend/Resume regressions due to recent ACPICA update.
Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index dfac3ec..635ba44 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -636,17 +636,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info
*gpe_event_info, u32 gpe_number)
}
}
- if (!acpi_gbl_system_awake_and_running) {
- /*
-* We just woke up because of a wake GPE. Disable any further
GPEs
-* until we are fully up and running (Only wake GPEs should be
enabled
-* at this time, but we just brute-force disable them all.)
-* 1) We must disable this particular wake GPE so it won't fire
again
-* 2) We want to disable all wake GPEs, since we are now awake
-*/
- (void)acpi_hw_disable_all_gpes();
- }
-
/*
* Dispatch the GPE to either an installed handler, or the control
method
* associated with this GPE (_Lxx or _Exx). If a handler exists, we
invoke
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 CONFIG_CC_OPTIMIZE_FOR_SIZE, at least that is my current guess looking at the config options I still need to test whether they make a difference. Either that, or the vmsplit option got broken again. I'm attaching my x60 config that works for me. -- Jens Axboe .config Description: application/config
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, and > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt > to bisect this. Strange; on my x60, suspend to ram works okay. (Resume is very slow, because disks are not spinned up properly; and there's something wrong with timers; console beeps take way too long). dmesg attached. That's with commit 7b965e0884cee430ffe5dc81cdb117b9316b0549 tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1 parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f author Trond Myklebust <[EMAIL PROTECTED]> Wed, 28 Feb 2007 20:13:55 -0800 committer Linus Torvalds <[EMAIL PROTECTED]> Thu, 01 Mar 2007 14:53:39 -0800 [PATCH] VM: invalidate_inode_pages2_range() should not exit early Fix invalidate_inode_pages2_range() so that it does not immediately exit just because a single page in the specified range could not be removed. Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: Binary data delme_config.gz Description: Binary data
Re: 2.6.21-rc1: known regressions (part 2)
* 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 git-bisect which really depends on only having a binary > space to search for. ] this method pointed out the real bug that we are interested in: | 774c47f1d78e373a6bd2964f4e278d1ce26c21cb is first bad commit | commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb | Author: Avi Kivity <[EMAIL PROTECTED]> | Date: Mon Feb 12 00:54:47 2007 -0800 | [PATCH] KVM: cpu hotplug support undoing the 774c47f1 patch from HEAD gave me a working resume. I'll send a fix for this KVM breakage in a separate mail. here's how the bisection went: bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 +good: [bcdb81ae29091f6a66369aabfd8324e4a53d05dc] knfsd: SUNRPC: add a bad: [920841d8d1d61bc12b43f95a579a5374f6d98f81] Merge branch 'for-linus' +bad: [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the sysctl +bad: [719c91ccadd3ed26570dbb29d54166914832eee9] [POWERPC] Use udbg_early +bad: [ebaf0c6032f525ddb0158fb59848d41899dce8cd] Merge branch 'for-linus' +good: [8cd133073f9b5cd335c0b2e4740aceb025d50ca9] kvm: Fix mismatch between +bad: [5b8e8ee6c65a34d8aafaeb8e2eaa97e496c2567c] ps3: add shutdown to +bad: [a524d946bdced73c5fbe60170fb33611491c4211] tgafb: sync-on-green +bad: [a268422de8bf1b4c0cb97987b6c329c9f6a3da4b] fbdev driver for S3 +good: [8d0be2b3bf4a55606967d7d84e56c52521e94333] KVM: VMX: add vcpu_clear() +bad: [59ae6c6b87711ceb2d1ea5f9e08bb13aee947a29] KVM: Host suspend/resume +bad: [774c47f1d78e373a6bd2964f4e278d1ce26c21cb] KVM: cpu hotplug support the commits prefixed with '+' were the ones where i had to hand-merge the f3ccb06f commit to. Near the end of the bisection it nicely honed in on the group of KVM changes that included the bad commit. but the conclusion is clear: if multiple bugs are present in the search area then it gets quite difficult to sort it out via git-bisect - but it's not impossible either. The following git-bisect enhancement could have made things easier for me: git-bisect mark-must-have which would mark as a must-have fix and would attempt to merge it to whatever bisection point it ends up with - if that bisection point does not have included already. (Maybe not even the full tree but only one particular commit ID.) In this particular case that merge, when it had to be done, was always 'clean'. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 with the first known-good commit, and thus eliminating > it from the bisection space. this got me quite a bit further: git-bisect start git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7 git-bisect bad d43a338e395371733a80ec473b40baac5f74d768 git-bisect bad 255f0385c8e0d6b9005c0e09fffb5bd852f3b506 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658 git-bisect bad 81450b73dde07f473a4a7208b209b4c8b7251d90 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf git-bisect good 5c95d3f5783ab184f64b7848f0a871352c35c3cf git-bisect good ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45 git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit [ note: by having the "git-bisect must-have-bugfix f3ccb06f" functionality i mentioned in the previous mail git-bisect could have eliminated the fake-good steps. ] it's not a resolution of this regression yet, because this commit is a merge with upstream: | commit 81450b73dde07f473a4a7208b209b4c8b7251d90 | Merge: 8a03d9a... 0539771... | Author: Len Brown <[EMAIL PROTECTED]> | Date: Fri Feb 16 18:52:41 2007 -0500 | | Pull misc-for-upstream into release branch which means that the fix in Len's tree got broken by merging with upstream. Note: this 'upstream' in isolation is broken too, due to not having that essential fix from Len's tree! So we quite likely have /two/ bugs, any of which breaks resume (which breakage looks the same, so no way to isolate them via testing). 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 git-bisect which really depends on only having a binary space to search for. ] Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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, and 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt to bisect this. Strange; on my x60, suspend to ram works okay. (Resume is very slow, because disks are not spinned up properly; and there's something wrong with timers; console beeps take way too long). dmesg attached. That's with commit 7b965e0884cee430ffe5dc81cdb117b9316b0549 tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1 parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f author Trond Myklebust [EMAIL PROTECTED] Wed, 28 Feb 2007 20:13:55 -0800 committer Linus Torvalds [EMAIL PROTECTED] Thu, 01 Mar 2007 14:53:39 -0800 [PATCH] VM: invalidate_inode_pages2_range() should not exit early Fix invalidate_inode_pages2_range() so that it does not immediately exit just because a single page in the specified range could not be removed. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: Binary data delme_config.gz Description: Binary data
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 with the first known-good commit, and thus eliminating it from the bisection space. this got me quite a bit further: git-bisect start git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7 git-bisect bad d43a338e395371733a80ec473b40baac5f74d768 git-bisect bad 255f0385c8e0d6b9005c0e09fffb5bd852f3b506 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658 git-bisect bad 81450b73dde07f473a4a7208b209b4c8b7251d90 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf git-bisect good 5c95d3f5783ab184f64b7848f0a871352c35c3cf git-bisect good ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45 git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit [ note: by having the git-bisect must-have-bugfix f3ccb06f functionality i mentioned in the previous mail git-bisect could have eliminated the fake-good steps. ] it's not a resolution of this regression yet, because this commit is a merge with upstream: | commit 81450b73dde07f473a4a7208b209b4c8b7251d90 | Merge: 8a03d9a... 0539771... | Author: Len Brown [EMAIL PROTECTED] | Date: Fri Feb 16 18:52:41 2007 -0500 | | Pull misc-for-upstream into release branch which means that the fix in Len's tree got broken by merging with upstream. Note: this 'upstream' in isolation is broken too, due to not having that essential fix from Len's tree! So we quite likely have /two/ bugs, any of which breaks resume (which breakage looks the same, so no way to isolate them via testing). 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 git-bisect which really depends on only having a binary space to search for. ] Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 git-bisect which really depends on only having a binary space to search for. ] this method pointed out the real bug that we are interested in: | 774c47f1d78e373a6bd2964f4e278d1ce26c21cb is first bad commit | commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb | Author: Avi Kivity [EMAIL PROTECTED] | Date: Mon Feb 12 00:54:47 2007 -0800 | [PATCH] KVM: cpu hotplug support undoing the 774c47f1 patch from HEAD gave me a working resume. I'll send a fix for this KVM breakage in a separate mail. here's how the bisection went: bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 +good: [bcdb81ae29091f6a66369aabfd8324e4a53d05dc] knfsd: SUNRPC: add a bad: [920841d8d1d61bc12b43f95a579a5374f6d98f81] Merge branch 'for-linus' +bad: [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the sysctl +bad: [719c91ccadd3ed26570dbb29d54166914832eee9] [POWERPC] Use udbg_early +bad: [ebaf0c6032f525ddb0158fb59848d41899dce8cd] Merge branch 'for-linus' +good: [8cd133073f9b5cd335c0b2e4740aceb025d50ca9] kvm: Fix mismatch between +bad: [5b8e8ee6c65a34d8aafaeb8e2eaa97e496c2567c] ps3: add shutdown to +bad: [a524d946bdced73c5fbe60170fb33611491c4211] tgafb: sync-on-green +bad: [a268422de8bf1b4c0cb97987b6c329c9f6a3da4b] fbdev driver for S3 +good: [8d0be2b3bf4a55606967d7d84e56c52521e94333] KVM: VMX: add vcpu_clear() +bad: [59ae6c6b87711ceb2d1ea5f9e08bb13aee947a29] KVM: Host suspend/resume +bad: [774c47f1d78e373a6bd2964f4e278d1ce26c21cb] KVM: cpu hotplug support the commits prefixed with '+' were the ones where i had to hand-merge the f3ccb06f commit to. Near the end of the bisection it nicely honed in on the group of KVM changes that included the bad commit. but the conclusion is clear: if multiple bugs are present in the search area then it gets quite difficult to sort it out via git-bisect - but it's not impossible either. The following git-bisect enhancement could have made things easier for me: git-bisect mark-must-have tree which would mark tree as a must-have fix and would attempt to merge it to whatever bisection point it ends up with - if that bisection point does not have tree included already. (Maybe not even the full tree but only one particular commit ID.) In this particular case that merge, when it had to be done, was always 'clean'. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 as 'good'. I never met such a multiple-bugs scenario
before and forgot that git-bisect could easily pick a tree without this
essential bugfix and would not be able to make a distinction between the
two types of badness.
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.
(but it might also be useful to have a "git-bisect must-include" kind of
command that would allow this to be automated: mark a particular tree as
an essential component of the search space.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 did not appear to find anything useful: 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is first bad commit And via that method i found a couple of more 'good' points - which git-bisect never picked up by itself. (and i did 3-4 separate git-bisect sessions, one of them was a "git-bisect start drivers/acpi/" - which is the main area of suspicion). I looked at git-bisect visualize more than once, and i've attached one of the bisection logs below. i also think i know what happens. Firstly, my testing is reliable, as i mentioned it in the other mail i frequently re-visited commits to make sure that none of my bad/good decisions is spurios - but no, the test results are extremely reproducable: either the laptop resumes properly after flashing its disk light or it does not. the problem i think is that i simply took git-bisect's behavior for granted (i used it many times already) but forgot about a very basic precondition: git-bisect will find only a /single/ good->bad transition. If there is a bad->good transition combined with a good->bad transition then git-bisect will think it's the same 'badness', while it's a /former/ badness that it is honing in on - totally sending the bisection off into la-la-land. so as i mentioned it in the first mail: i /know/ that this commit is a bad->good transition point: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 /and i only want to test commits that include this commit/ - because i know that without this commit git-bisect confuses the /other/ breakage with the new breakage. In the bisection log below, this choice of git-bisect: ee404566f97f9254433399fbbcfa05390c7c55f7 is 'bad' according to testing, but that's 'another' badness - and i missed it. Now, having slept on it, the solution is very simple: whenever git-bisect picks a commit for which the following command comes up empty: git-log | grep f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 then i'll mark it "git-bisect good" - artificially marking the older badness as a 'good' area. That way git-bisect will find the right good->bad transition point. btw., that's why i tried to pick up commits by hand, making sure that commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 is always included - but got lost in the maze of the commit graph, and didnt realize that there is a simple solution. Nevertheless i wanted to dump the information i already gathered. Those commits were totally out of order, etc. - they were picked by a poor human who is much worse at walking graphs than git-bisect ;-) Ingo git-bisect start # bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: Move update_cr16_clocksource later in boot git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d # good: [f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38] ACPI: Disable wake GPEs only once. git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 # bad: [ee404566f97f9254433399fbbcfa05390c7c55f7] sysctl: mips/au1000: remove sys_sysctl support git-bisect bad ee404566f97f9254433399fbbcfa05390c7c55f7 # bad: [c827ba4cb49a30ce581201fd0ba2be77cde412c7] Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 git-bisect bad c827ba4cb49a30ce581201fd0ba2be77cde412c7 # bad: [68a696a01f482859a9fe937249e8b3d44252b610] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-tc git-bisect bad 68a696a01f482859a9fe937249e8b3d44252b610 # bad: [1c433fbda4896a6455d97b66a4f2646cbdd52a8c] [ALSA] soc - 0.13 ASoC headers git-bisect bad 1c433fbda4896a6455d97b66a4f2646cbdd52a8c # bad: [048b945077bdc7e8dff5d5810ff2a0ced3590ca9] [ALSA] echoaudio, add TLV support git-bisect bad 048b945077bdc7e8dff5d5810ff2a0ced3590ca9 # bad: [c07584c83287ae5a13cc836f69a1d824ad068c66] [ALSA] hda-codec - Add support for Medion laptops git-bisect bad c07584c83287ae5a13cc836f69a1d824ad068c66 # bad: [dbc6b6ad767c86907db373e85139b0e975ba7599] [ALSA] ASoC codecs: generic AC97 support git-bisect bad dbc6b6ad767c86907db373e85139b0e975ba7599 # bad: [b66b3cfe6c2f6560f351278883a325b6ebc478f5] [ALSA] hda_intel: increase maximum DMA buffer size to 1024MB git-bisect bad b66b3cfe6c2f6560f351278883a325b6ebc478f5 # bad: [12b131c4cf3eb1dc8a60082a434b7b100774c2e7] [ALSA] allow registering an alsa device with struct device pointer git-bisect bad 12b131c4cf3eb1dc8a60082a434b7b100774c2e7 # bad: [e4f8e656d8c152c08cd44d0e3c21f009fab09952] [ALSA] usb-audio: allow pausing git-bisect bad e4f8e656d8c152c08cd44d0e3c21f009fab09952 # bad: [1700f3080d98323e91864d67cb9f6d46f818ccf0] [ALSA] usb-audio: merge playback/capture hardware information structs git-bisect bad 1700f3080d98323e91864d67cb9f6d46f818ccf0 # bad: [9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff] [ALSA]
Re: 2.6.21-rc1: known regressions (part 2)
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, >but what you now need to do is that at each bisection step, you look at >whether the bisection point has the known bug, and if so, you apply the >known fix for that known bug, and thus you can test the kernel >*without* the interaction of the bug you already found. > > This makes bisection a lot less automated (you have to apply the "fix" for > the other bug at each step) Side note: it's still usually fairly easy. Especially if you have a known fix for the other bug, you can usually just do the equivalent of git cherry-pick at each point during this bisect (or just have a known patch that you keep applying and un-applying), and you're largely done. Of course, if the area with the fix keeps changing, or if the fix is really intrusive and nasty, this gets hairy, but at least in this case the patch is fairly trivial and it shouldn't cause any trouble at all to do this. The only real down-side is just the mindless extra work, and the possible added confusion you get from modifying the history at the points you're testing. "git bisect" is not necessarily happy about auto-picking a new bisection point with a dirty tree, for example, so before you mark something "good" or "bad", you should generally try to do so with a clean git tree (ie if you apply a patch at each stage, do "git reset --hard" to remove the patch before you do the "git bisect bad/good" stage). Similarly, especially at the end of the bisection run, if you actually use "git cherry-pick" to *add* a commit, the bisection will now take that added commit into account when trying to pick the next commit to check, which is not what you really want. It probably doesn't matter that much during the early stages (when bisection is really jumping around wildly anyway, and one commit more or less doesn't really matter), but again, it might be a good idea to make a habit of undoing the cherry-pick, the same way you'd undo a patch (eg "git reset --hard HEAD^" would do it, if you have exactly one cherry-pick that you tested). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 commits between your first known-bad and known-good
commits, which means that you usually end up having to check "log2(n)+1"
kernels, ie I'd have expected you to have to do 12-13 bisection attempts
to cut it down to one.
You seem to have done 14 (you list 16 commits, two of which are the
starting points), which is right in that range. The reason you sometimes
get more is:
- you "help" git bisect by choosing other commits than the optimal ones.
- with bad luck, it can be hard to get really close to "half the commits"
in the reachability analysis, especially if you have lots of merges
(and *especially* if you have octopus merges that merge more than two
branches of development). For example, say that you have something like
a
|
+---+---+---+---+
| | | | |
b c d e f
where you have six commits - you can't test any "combinations" at all,
since they are all independent, so "git bisect" cannot test them three
and three to cut down the time, so if you don't know which one is bad,
you'll basically end up testing them all.
The bad luck case never really happens to that extreme in practice, and
even when it does you can sometimes be lucky and just hit on the bug early
(so "bad luck" may end up being "good luck" after all), but it explains
why you can get more - or less - than log2(n)+1 attempts. More commonly
one more.
A much *bigger* problem is if you mark something good or bad that isn't
really. Ie if the bug comes and goes (it might be timing-dependent, for
example), the problem will be that you'll always narrow things down
(that's what bisection does), but you may not narrow it down to the right
thing!
We've had that happen several times. If the bug (for example) means that
suspend *often* breaks, but sometimes works just by luck, you might mark a
kernel "good" when it really wasn't and then "git bisect" will *really* go
out in the weeds, and won't even try to test the commits that may have
introduced the bug, because you told it that those commits resulted in a
good kernel..
> commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
> commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
> commit c24e912b61b1ab2301c59777134194066b06465c: good
> commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
> commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
> commit fc955f670c0a66aca965605dae797e747b2bef7d: good
> commit 70c0846e430881967776582e13aefb81407919f1: good
> commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
> commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
> commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
> commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
> commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
> commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
> commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
> commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad
Looks like it's claiming that 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is
the bad commit. Which is extremely unlikely, since it only seems to affect
the emu10k sound driver, which I don't think even exists on any ThinkPad
laptops (correct me if I'm wrong).
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. That's totally bogus. Please use the git bisection log (see
.git/BISECT_LOG), and don't think that you know some "better" order. You
really don't.
> the results are totally reproducible (i re-tried a few of both the good
> and the bad commits), i.e. it's not a sporadic condition. Also, a number
> of the 'bad' commits have no dynticks stuff in them at all, so i'd
> exclude dynticks.
>
> could someone suggest a sane way to go with this? Perhaps suggest
> specific commit IDs to test?
You claim that 9f4bd5dd is bad, but you indirectly claim that its direct
parent (5986a2ec) is good by saying that f3ccb06f is good. This is why
"git bisect" will claim that 9f4bd5dd must be the bad commit.
I would suggest testing commit 5986a2ec explicitly. If that one is good,
then, since you claim that 9f4bd5dd is bad, then yes, 9f4bd5dd *is* the
bad commit (because 5986a2ec is its direct parent).
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").
What happens is that you've chased them *both*, and you cannot bisect that
kind of behaviour totally automatically and mindlessly, simply because
when you say "git
Re: 2.6.21-rc1: known regressions (part 2)
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 here. Here are the commits i
> tested, in git-log order:
>
> #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
Use "git bisect visualize" to see what bisect ends up doing.
> if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2
> - that's OK. But when i tell it that #2 is bad, it offers #4 - which is
> out of order!
No it's not. "git bisect" does exactly the right thing. There is no simple
ordering in a complex branch-merge schenario, you can't just put the
commits in some "ordering" and test things in time order. That would be
totally broken, and idiotic. It doesn't give the right results.
What git bisect does is to find the commit that most closely *bisects* the
history of commits, so that if it is marked good/bad, it will leave you
with about 50% of the commits left. But if you are looking at date order,
you're entirely confused.
For example, let's take a really simple case
a <- bad
/ \
b c
| |
d e
| |
f g
\ /
h
|
* <-good
and if you are looking to find something "in the middle", you might thing
that "d" or "e" are the best choices, since time-wise, they are in the
middle.
But that's not true AT ALL.
If you actually want to bisect that kind of history, you need to choose
"b" or "c", even though they may both be *much* more "recent" than the
others. Why? Because if you pick "d", you're really only testing three
commits ('d' 'f' and 'h') out of the 8 commits you have to test.
In contrast, if you pick 'b', you are testing the effects of *four*
commits ('b', 'd', 'f' and 'h') and you have thus neatly bisected the
commits into two equal groups for testing (one group _with_ those four
commits, and one group _without_) instead of having partitioned them as 3
commits vs 5 commits.
So please realize that non-linear history very much means that you MUST
NOT think that you just pick a commit "in the middle". No, git bisect is a
LOT smarter than that - it picks a commit that *reaches* about half the
commits you have left to test.
> The bisection goes off into la-la land after that and
> never gets back to a commit that is /after/ the good commit. How is this
> possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt
> some git bug that's already fixed.)
It's possible because git knows what it is doing, and you didn't think
things through.
The commits that "git bisect" picked out are the right ones. Quite often,
there may be two or more "equally good" commits (in my example above, you
can choose either "b" or "c", and it will bisect the set of untested
commits equally well - in two groups of four, but two *different* groups
of four commits), and yes, it's possible that git has a bug that makes it
pick the wrong ones, but quite frankly, I seriously doubt it. "git bisect"
has been very successful indeed, and is generally a *lot* better at
picking a commit "in the middle" than people are, exactly because it's
quite hard to see which commit "reaches" half the commits if you have lots
of merges and branches.
Try out
git bisect visualize
and it will literally show you what it is doing.
What can be confusing is that if the "good" and "bad" markers are ON
DIFFERENT BRANCHES OF DEVELOPMENT, you may not even *see* the "good"
marker, because you may well have something like this:
a <- bad
|
b * <- good
| |
c d
\ /
e
|
f
|
...
and what do you think "git bisect visualize" will actually show you?
Since 'd', 'e' and 'f' are all in the "good" set (they both exist as
commits in something leading up to a commit that has already been deemed
fine), they aren't *interesting* - they can't be introducing the bug,
since if that was the case, the good commit wouldn't have been good. So as
far as bisection is concerned, the tree actually looks like
a <- bad
|
b
|
c
|
...
and you have just three commits that are potentially interesting: 'a', 'b'
and 'c'.
Now, with three commits, you cannot test them half-and-half, so you have
to test it in groups of 1 vs 2 commits, so it's arbitrary whether you
choose 'b' or 'c' to test, but you'd test one of them. Say that you choose
'b', and it turns out to be good. If so, you're done: 'a' is bad and 'b'
is good, so the bug was
Re: 2.6.21-rc1: known regressions (part 2)
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 ee404566f97f9254433399fbbcfa05390c7c55f7 bad > > #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good > > #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad > > > > if i tell git-bisect that #1 is bad and #3 is good, then it offers me > > #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - > > which is out of order! The bisection goes off into la-la land after > > that and never gets back to a commit that is /after/ the good commit. > > How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure > > this isnt some git bug that's already fixed.) > > > > i'll try to straighten this out manually, perhaps #3 is in some merge > > branch that confuses bisection. Or maybe i misunderstood how > > git-bisect works. > > git-bisect gets royally confused on those ACPI merge branches around > commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test > results so far: > > commit 01363220f5d23ef68276db8974e46a502e43d01d: bad > commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad > commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad > commit c24e912b61b1ab2301c59777134194066b06465c: good > commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad > commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad > commit fc955f670c0a66aca965605dae797e747b2bef7d: good > commit 70c0846e430881967776582e13aefb81407919f1: good > commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad > commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good > commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad > commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad > commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad > commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad > commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad > commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad > > the results are totally reproducible (i re-tried a few of both the good > and the bad commits), i.e. it's not a sporadic condition. Also, a number > of the 'bad' commits have no dynticks stuff in them at all, so i'd > exclude dynticks. > > could someone suggest a sane way to go with this? Perhaps suggest > specific commit IDs to test? Hm, does 2.6.20-mm2 work? If not, you can bisect the broken-out sereis with quilt. Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good > #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad > > if i tell git-bisect that #1 is bad and #3 is good, then it offers me > #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - > which is out of order! The bisection goes off into la-la land after > that and never gets back to a commit that is /after/ the good commit. > How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure > this isnt some git bug that's already fixed.) > > i'll try to straighten this out manually, perhaps #3 is in some merge > branch that confuses bisection. Or maybe i misunderstood how > git-bisect works. git-bisect gets royally confused on those ACPI merge branches around commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test results so far: commit 01363220f5d23ef68276db8974e46a502e43d01d: bad commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad commit c24e912b61b1ab2301c59777134194066b06465c: good commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad commit fc955f670c0a66aca965605dae797e747b2bef7d: good commit 70c0846e430881967776582e13aefb81407919f1: good commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad the results are totally reproducible (i re-tried a few of both the good and the bad commits), i.e. it's not a sporadic condition. Also, a number of the 'bad' commits have no dynticks stuff in them at all, so i'd exclude dynticks. could someone suggest a sane way to go with this? Perhaps suggest specific commit IDs to test? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 order: #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - which is out of order! The bisection goes off into la-la land after that and never gets back to a commit that is /after/ the good commit. How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt some git bug that's already fixed.) i'll try to straighten this out manually, perhaps #3 is in some merge branch that confuses bisection. Or maybe i misunderstood how git-bisect works. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 order: #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - which is out of order! The bisection goes off into la-la land after that and never gets back to a commit that is /after/ the good commit. How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt some git bug that's already fixed.) i'll try to straighten this out manually, perhaps #3 is in some merge branch that confuses bisection. Or maybe i misunderstood how git-bisect works. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - which is out of order! The bisection goes off into la-la land after that and never gets back to a commit that is /after/ the good commit. How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt some git bug that's already fixed.) i'll try to straighten this out manually, perhaps #3 is in some merge branch that confuses bisection. Or maybe i misunderstood how git-bisect works. git-bisect gets royally confused on those ACPI merge branches around commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test results so far: commit 01363220f5d23ef68276db8974e46a502e43d01d: bad commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad commit c24e912b61b1ab2301c59777134194066b06465c: good commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad commit fc955f670c0a66aca965605dae797e747b2bef7d: good commit 70c0846e430881967776582e13aefb81407919f1: good commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad the results are totally reproducible (i re-tried a few of both the good and the bad commits), i.e. it's not a sporadic condition. Also, a number of the 'bad' commits have no dynticks stuff in them at all, so i'd exclude dynticks. could someone suggest a sane way to go with this? Perhaps suggest specific commit IDs to test? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 ee404566f97f9254433399fbbcfa05390c7c55f7 bad #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - which is out of order! The bisection goes off into la-la land after that and never gets back to a commit that is /after/ the good commit. How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt some git bug that's already fixed.) i'll try to straighten this out manually, perhaps #3 is in some merge branch that confuses bisection. Or maybe i misunderstood how git-bisect works. git-bisect gets royally confused on those ACPI merge branches around commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test results so far: commit 01363220f5d23ef68276db8974e46a502e43d01d: bad commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad commit c24e912b61b1ab2301c59777134194066b06465c: good commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad commit fc955f670c0a66aca965605dae797e747b2bef7d: good commit 70c0846e430881967776582e13aefb81407919f1: good commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad the results are totally reproducible (i re-tried a few of both the good and the bad commits), i.e. it's not a sporadic condition. Also, a number of the 'bad' commits have no dynticks stuff in them at all, so i'd exclude dynticks. could someone suggest a sane way to go with this? Perhaps suggest specific commit IDs to test? Hm, does 2.6.20-mm2 work? If not, you can bisect the broken-out sereis with quilt. Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 here. Here are the commits i
tested, in git-log order:
#1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
#2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
#3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
#4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
Use git bisect visualize to see what bisect ends up doing.
if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2
- that's OK. But when i tell it that #2 is bad, it offers #4 - which is
out of order!
No it's not. git bisect does exactly the right thing. There is no simple
ordering in a complex branch-merge schenario, you can't just put the
commits in some ordering and test things in time order. That would be
totally broken, and idiotic. It doesn't give the right results.
What git bisect does is to find the commit that most closely *bisects* the
history of commits, so that if it is marked good/bad, it will leave you
with about 50% of the commits left. But if you are looking at date order,
you're entirely confused.
For example, let's take a really simple case
a - bad
/ \
b c
| |
d e
| |
f g
\ /
h
|
* -good
and if you are looking to find something in the middle, you might thing
that d or e are the best choices, since time-wise, they are in the
middle.
But that's not true AT ALL.
If you actually want to bisect that kind of history, you need to choose
b or c, even though they may both be *much* more recent than the
others. Why? Because if you pick d, you're really only testing three
commits ('d' 'f' and 'h') out of the 8 commits you have to test.
In contrast, if you pick 'b', you are testing the effects of *four*
commits ('b', 'd', 'f' and 'h') and you have thus neatly bisected the
commits into two equal groups for testing (one group _with_ those four
commits, and one group _without_) instead of having partitioned them as 3
commits vs 5 commits.
So please realize that non-linear history very much means that you MUST
NOT think that you just pick a commit in the middle. No, git bisect is a
LOT smarter than that - it picks a commit that *reaches* about half the
commits you have left to test.
The bisection goes off into la-la land after that and
never gets back to a commit that is /after/ the good commit. How is this
possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt
some git bug that's already fixed.)
It's possible because git knows what it is doing, and you didn't think
things through.
The commits that git bisect picked out are the right ones. Quite often,
there may be two or more equally good commits (in my example above, you
can choose either b or c, and it will bisect the set of untested
commits equally well - in two groups of four, but two *different* groups
of four commits), and yes, it's possible that git has a bug that makes it
pick the wrong ones, but quite frankly, I seriously doubt it. git bisect
has been very successful indeed, and is generally a *lot* better at
picking a commit in the middle than people are, exactly because it's
quite hard to see which commit reaches half the commits if you have lots
of merges and branches.
Try out
git bisect visualize
and it will literally show you what it is doing.
What can be confusing is that if the good and bad markers are ON
DIFFERENT BRANCHES OF DEVELOPMENT, you may not even *see* the good
marker, because you may well have something like this:
a - bad
|
b * - good
| |
c d
\ /
e
|
f
|
...
and what do you think git bisect visualize will actually show you?
Since 'd', 'e' and 'f' are all in the good set (they both exist as
commits in something leading up to a commit that has already been deemed
fine), they aren't *interesting* - they can't be introducing the bug,
since if that was the case, the good commit wouldn't have been good. So as
far as bisection is concerned, the tree actually looks like
a - bad
|
b
|
c
|
...
and you have just three commits that are potentially interesting: 'a', 'b'
and 'c'.
Now, with three commits, you cannot test them half-and-half, so you have
to test it in groups of 1 vs 2 commits, so it's arbitrary whether you
choose 'b' or 'c' to test, but you'd test one of them. Say that you choose
'b', and it turns out to be good. If so, you're done: 'a' is bad and 'b'
is good, so the bug was introduced in 'a'. But if it turns out to be bad,
you'll still have to test 'c'
Re: 2.6.21-rc1: known regressions (part 2)
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 commits between your first known-bad and known-good commits, which means that you usually end up having to check log2(n)+1 kernels, ie I'd have expected you to have to do 12-13 bisection attempts to cut it down to one. You seem to have done 14 (you list 16 commits, two of which are the starting points), which is right in that range. The reason you sometimes get more is: - you help git bisect by choosing other commits than the optimal ones. - with bad luck, it can be hard to get really close to half the commits in the reachability analysis, especially if you have lots of merges (and *especially* if you have octopus merges that merge more than two branches of development). For example, say that you have something like a | +---+---+---+---+ | | | | | b c d e f where you have six commits - you can't test any combinations at all, since they are all independent, so git bisect cannot test them three and three to cut down the time, so if you don't know which one is bad, you'll basically end up testing them all. The bad luck case never really happens to that extreme in practice, and even when it does you can sometimes be lucky and just hit on the bug early (so bad luck may end up being good luck after all), but it explains why you can get more - or less - than log2(n)+1 attempts. More commonly one more. A much *bigger* problem is if you mark something good or bad that isn't really. Ie if the bug comes and goes (it might be timing-dependent, for example), the problem will be that you'll always narrow things down (that's what bisection does), but you may not narrow it down to the right thing! We've had that happen several times. If the bug (for example) means that suspend *often* breaks, but sometimes works just by luck, you might mark a kernel good when it really wasn't and then git bisect will *really* go out in the weeds, and won't even try to test the commits that may have introduced the bug, because you told it that those commits resulted in a good kernel.. commit 01363220f5d23ef68276db8974e46a502e43d01d: bad commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad commit c24e912b61b1ab2301c59777134194066b06465c: good commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad commit fc955f670c0a66aca965605dae797e747b2bef7d: good commit 70c0846e430881967776582e13aefb81407919f1: good commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad Looks like it's claiming that 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is the bad commit. Which is extremely unlikely, since it only seems to affect the emu10k sound driver, which I don't think even exists on any ThinkPad laptops (correct me if I'm wrong). 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. That's totally bogus. Please use the git bisection log (see .git/BISECT_LOG), and don't think that you know some better order. You really don't. the results are totally reproducible (i re-tried a few of both the good and the bad commits), i.e. it's not a sporadic condition. Also, a number of the 'bad' commits have no dynticks stuff in them at all, so i'd exclude dynticks. could someone suggest a sane way to go with this? Perhaps suggest specific commit IDs to test? You claim that 9f4bd5dd is bad, but you indirectly claim that its direct parent (5986a2ec) is good by saying that f3ccb06f is good. This is why git bisect will claim that 9f4bd5dd must be the bad commit. I would suggest testing commit 5986a2ec explicitly. If that one is good, then, since you claim that 9f4bd5dd is bad, then yes, 9f4bd5dd *is* the bad commit (because 5986a2ec is its direct parent). 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). What happens is that you've chased them *both*, and you cannot bisect that kind of behaviour totally automatically and mindlessly, simply because when you say git bisect bad, that means that *one* of the bugs is active,
Re: 2.6.21-rc1: known regressions (part 2)
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, but what you now need to do is that at each bisection step, you look at whether the bisection point has the known bug, and if so, you apply the known fix for that known bug, and thus you can test the kernel *without* the interaction of the bug you already found. This makes bisection a lot less automated (you have to apply the fix for the other bug at each step) Side note: it's still usually fairly easy. Especially if you have a known fix for the other bug, you can usually just do the equivalent of git cherry-pick fixcommit at each point during this bisect (or just have a known patch that you keep applying and un-applying), and you're largely done. Of course, if the area with the fix keeps changing, or if the fix is really intrusive and nasty, this gets hairy, but at least in this case the patch is fairly trivial and it shouldn't cause any trouble at all to do this. The only real down-side is just the mindless extra work, and the possible added confusion you get from modifying the history at the points you're testing. git bisect is not necessarily happy about auto-picking a new bisection point with a dirty tree, for example, so before you mark something good or bad, you should generally try to do so with a clean git tree (ie if you apply a patch at each stage, do git reset --hard to remove the patch before you do the git bisect bad/good stage). Similarly, especially at the end of the bisection run, if you actually use git cherry-pick to *add* a commit, the bisection will now take that added commit into account when trying to pick the next commit to check, which is not what you really want. It probably doesn't matter that much during the early stages (when bisection is really jumping around wildly anyway, and one commit more or less doesn't really matter), but again, it might be a good idea to make a habit of undoing the cherry-pick, the same way you'd undo a patch (eg git reset --hard HEAD^ would do it, if you have exactly one cherry-pick that you tested). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 did not appear to find anything useful: 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is first bad commit And via that method i found a couple of more 'good' points - which git-bisect never picked up by itself. (and i did 3-4 separate git-bisect sessions, one of them was a git-bisect start drivers/acpi/ - which is the main area of suspicion). I looked at git-bisect visualize more than once, and i've attached one of the bisection logs below. i also think i know what happens. Firstly, my testing is reliable, as i mentioned it in the other mail i frequently re-visited commits to make sure that none of my bad/good decisions is spurios - but no, the test results are extremely reproducable: either the laptop resumes properly after flashing its disk light or it does not. the problem i think is that i simply took git-bisect's behavior for granted (i used it many times already) but forgot about a very basic precondition: git-bisect will find only a /single/ good-bad transition. If there is a bad-good transition combined with a good-bad transition then git-bisect will think it's the same 'badness', while it's a /former/ badness that it is honing in on - totally sending the bisection off into la-la-land. so as i mentioned it in the first mail: i /know/ that this commit is a bad-good transition point: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 /and i only want to test commits that include this commit/ - because i know that without this commit git-bisect confuses the /other/ breakage with the new breakage. In the bisection log below, this choice of git-bisect: ee404566f97f9254433399fbbcfa05390c7c55f7 is 'bad' according to testing, but that's 'another' badness - and i missed it. Now, having slept on it, the solution is very simple: whenever git-bisect picks a commit for which the following command comes up empty: git-log | grep f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 then i'll mark it git-bisect good - artificially marking the older badness as a 'good' area. That way git-bisect will find the right good-bad transition point. btw., that's why i tried to pick up commits by hand, making sure that commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 is always included - but got lost in the maze of the commit graph, and didnt realize that there is a simple solution. Nevertheless i wanted to dump the information i already gathered. Those commits were totally out of order, etc. - they were picked by a poor human who is much worse at walking graphs than git-bisect ;-) Ingo git-bisect start # bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: Move update_cr16_clocksource later in boot git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d # good: [f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38] ACPI: Disable wake GPEs only once. git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 # bad: [ee404566f97f9254433399fbbcfa05390c7c55f7] sysctl: mips/au1000: remove sys_sysctl support git-bisect bad ee404566f97f9254433399fbbcfa05390c7c55f7 # bad: [c827ba4cb49a30ce581201fd0ba2be77cde412c7] Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 git-bisect bad c827ba4cb49a30ce581201fd0ba2be77cde412c7 # bad: [68a696a01f482859a9fe937249e8b3d44252b610] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-tc git-bisect bad 68a696a01f482859a9fe937249e8b3d44252b610 # bad: [1c433fbda4896a6455d97b66a4f2646cbdd52a8c] [ALSA] soc - 0.13 ASoC headers git-bisect bad 1c433fbda4896a6455d97b66a4f2646cbdd52a8c # bad: [048b945077bdc7e8dff5d5810ff2a0ced3590ca9] [ALSA] echoaudio, add TLV support git-bisect bad 048b945077bdc7e8dff5d5810ff2a0ced3590ca9 # bad: [c07584c83287ae5a13cc836f69a1d824ad068c66] [ALSA] hda-codec - Add support for Medion laptops git-bisect bad c07584c83287ae5a13cc836f69a1d824ad068c66 # bad: [dbc6b6ad767c86907db373e85139b0e975ba7599] [ALSA] ASoC codecs: generic AC97 support git-bisect bad dbc6b6ad767c86907db373e85139b0e975ba7599 # bad: [b66b3cfe6c2f6560f351278883a325b6ebc478f5] [ALSA] hda_intel: increase maximum DMA buffer size to 1024MB git-bisect bad b66b3cfe6c2f6560f351278883a325b6ebc478f5 # bad: [12b131c4cf3eb1dc8a60082a434b7b100774c2e7] [ALSA] allow registering an alsa device with struct device pointer git-bisect bad 12b131c4cf3eb1dc8a60082a434b7b100774c2e7 # bad: [e4f8e656d8c152c08cd44d0e3c21f009fab09952] [ALSA] usb-audio: allow pausing git-bisect bad e4f8e656d8c152c08cd44d0e3c21f009fab09952 # bad: [1700f3080d98323e91864d67cb9f6d46f818ccf0] [ALSA] usb-audio: merge playback/capture hardware information structs git-bisect bad 1700f3080d98323e91864d67cb9f6d46f818ccf0 # bad: [9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff] [ALSA] snd-emu10k1: Added
Re: 2.6.21-rc1: known regressions (part 2)
* 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 as 'good'. I never met such a multiple-bugs scenario before and forgot that git-bisect could easily pick a tree without this essential bugfix and would not be able to make a distinction between the two types of badness. 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. (but it might also be useful to have a git-bisect must-include kind of command that would allow this to be automated: mark a particular tree as an essential component of the search space.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 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 considering you in any other way possibly > > > involved with one or more of these issues. > > > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > > > > > > > > Subject: ThinkPad T60: system doesn't come out of suspend to RAM > > > (CONFIG_NO_HZ) > > > References : http://lkml.org/lkml/2007/2/22/391 > > > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > > > Thomas Gleixner <[EMAIL PROTECTED]> > > > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > > > Status : unknown > > > > 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. > > Is this > > Subject: ThinkPad T60: no screen after suspend to RAM > References : http://lkml.org/lkml/2007/2/22/391 > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown > > or doesn't it resume at all? It doesn't resume at all. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 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 considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown 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. Is this Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown or doesn't it resume at all? It doesn't resume at all. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 the bugs, maintainer of an affectected subsystem or driver, a patch > > of you caused a breakage or I'm considering you in any other way possibly > > involved with one or more of these issues. > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > > > > > Subject: ThinkPad T60: system doesn't come out of suspend to RAM > > (CONFIG_NO_HZ) > > References : http://lkml.org/lkml/2007/2/22/391 > > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > > Thomas Gleixner <[EMAIL PROTECTED]> > > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > > Status : unknown > > 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. Is this Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Status : unknown or doesn't it resume at all? > Jens Axboe cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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. > > > > > > > > > > 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 back to 2.6.20 makes it work > > > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change > > > > broke resume, but that got fixed. Some other change later snuck in > > > > that broke it AGAIN for me, sigh. > > > > > > > > I don't use bluetooth nor suspend to disk. > > > > > > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works > > > fine? Do you know a commit ID that works for sure? I'd like to bisect > > > > Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked > > until some acpi change broke it, the below patch fixed that for me. That > > got merged in a later 2.6.20-gitY, but then some other patch broke it > > again so that 2.6.21-rc1 is broken. Not much luck there :-) > > > > So it looks like: > > > > - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git > > - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. > > - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it > > again. > > > > > this, but this way i might just find that ACPI change that got already > > > fixed later on (and then got re-broken). > > > > Yeah, it gets trickier. I'll try > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then > > bisect to 2.6.21-rc1 to find the other offender. I hope the other > > offender didn't get added before > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect. Which got me nowhere, after bisecting down from 1213 revisions to nothing. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 certainly works, just verified again. Trying only acpi related changes now... -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 not play with bluetooth and > > > > suspend to disk... > > > > > > It locks solid here on resume, going back to 2.6.20 makes it work > > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change > > > broke resume, but that got fixed. Some other change later snuck in > > > that broke it AGAIN for me, sigh. > > > > > > I don't use bluetooth nor suspend to disk. > > > > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works > > fine? Do you know a commit ID that works for sure? I'd like to bisect > > Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked > until some acpi change broke it, the below patch fixed that for me. That > got merged in a later 2.6.20-gitY, but then some other patch broke it > again so that 2.6.21-rc1 is broken. Not much luck there :-) > > So it looks like: > > - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git > - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. > - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it > again. > > > this, but this way i might just find that ACPI change that got already > > fixed later on (and then got re-broken). > > Yeah, it gets trickier. I'll try > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then > bisect to 2.6.21-rc1 to find the other offender. I hope the other > offender didn't get added before > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 disk... > > > > It locks solid here on resume, going back to 2.6.20 makes it work > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change > > broke resume, but that got fixed. Some other change later snuck in > > that broke it AGAIN for me, sigh. > > > > I don't use bluetooth nor suspend to disk. > > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works > fine? Do you know a commit ID that works for sure? I'd like to bisect Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked until some acpi change broke it, the below patch fixed that for me. That got merged in a later 2.6.20-gitY, but then some other patch broke it again so that 2.6.21-rc1 is broken. Not much luck there :-) So it looks like: - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it again. > this, but this way i might just find that ACPI change that got already > fixed later on (and then got re-broken). Yeah, it gets trickier. I'll try f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then bisect to 2.6.21-rc1 to find the other offender. I hope the other offender didn't get added before f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 back to 2.6.20 makes it work > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change > broke resume, but that got fixed. Some other change later snuck in > that broke it AGAIN for me, sigh. > > I don't use bluetooth nor suspend to disk. resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 subsystem or driver, a patch > > > of you caused a breakage or I'm considering you in any other way possibly > > > involved with one or more of these issues. > > > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > > > > > > > > Subject: ThinkPad T60: system doesn't come out of suspend to RAM > > > (CONFIG_NO_HZ) > > > References : http://lkml.org/lkml/2007/2/22/391 > > > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > > > Thomas Gleixner <[EMAIL PROTECTED]> > > > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > > > Status : unknown > > > > 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 back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 or I'm considering you in any other way possibly > > involved with one or more of these issues. > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > > > > > Subject: ThinkPad T60: system doesn't come out of suspend to RAM > > (CONFIG_NO_HZ) > > References : http://lkml.org/lkml/2007/2/22/391 > > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > > Thomas Gleixner <[EMAIL PROTECTED]> > > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > > Status : unknown > > 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... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 patch > of you caused a breakage or I'm considering you in any other way possibly > involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. > > > Subject: ThinkPad T60: system doesn't come out of suspend to RAM > (CONFIG_NO_HZ) > References : http://lkml.org/lkml/2007/2/22/391 > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > Thomas Gleixner <[EMAIL PROTECTED]> > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown 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. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown 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. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown 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... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown 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 back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
* 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 back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 disk... It locks solid here on resume, going back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked until some acpi change broke it, the below patch fixed that for me. That got merged in a later 2.6.20-gitY, but then some other patch broke it again so that 2.6.21-rc1 is broken. Not much luck there :-) So it looks like: - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it again. this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Yeah, it gets trickier. I'll try f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then bisect to 2.6.21-rc1 to find the other offender. I hope the other offender didn't get added before f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 not play with bluetooth and suspend to disk... It locks solid here on resume, going back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked until some acpi change broke it, the below patch fixed that for me. That got merged in a later 2.6.20-gitY, but then some other patch broke it again so that 2.6.21-rc1 is broken. Not much luck there :-) So it looks like: - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it again. this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Yeah, it gets trickier. I'll try f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then bisect to 2.6.21-rc1 to find the other offender. I hope the other offender didn't get added before f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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. 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 back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked until some acpi change broke it, the below patch fixed that for me. That got merged in a later 2.6.20-gitY, but then some other patch broke it again so that 2.6.21-rc1 is broken. Not much luck there :-) So it looks like: - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it again. this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Yeah, it gets trickier. I'll try f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then bisect to 2.6.21-rc1 to find the other offender. I hope the other offender didn't get added before f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect. Which got me nowhere, after bisecting down from 1213 revisions to nothing. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 certainly works, just verified again. Trying only acpi related changes now... -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: known regressions (part 2)
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 the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown 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. Is this Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown or doesn't it resume at all? Jens Axboe cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc1: known regressions (part 2)
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 considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Thomas Gleixner <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Status : unknown Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Status : problem is being debugged Subject: BUG: soft lockup detected on CPU#0 NOHZ: local_softirq_pending 20 References : http://lkml.org/lkml/2007/2/20/257 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Ingo Molnar <[EMAIL PROTECTED]> Status : problem is being debugged Subject: i386: no boot with nmi_watchdog=1 (clockevents) References : http://lkml.org/lkml/2007/2/21/208 Submitter : Daniel Walker <[EMAIL PROTECTED]> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> commit e9e2cdb412412326c4827fc78ba27f410d837e6e Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc1: known regressions (part 2)
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 considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Subject: BUG: soft lockup detected on CPU#0 NOHZ: local_softirq_pending 20 References : http://lkml.org/lkml/2007/2/20/257 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : problem is being debugged Subject: i386: no boot with nmi_watchdog=1 (clockevents) References : http://lkml.org/lkml/2007/2/21/208 Submitter : Daniel Walker [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit e9e2cdb412412326c4827fc78ba27f410d837e6e Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
