The number of bugs reported against the FC6 kernel is now dropping.
Should we move to kernel 2.6.21 and risk a whole new wave of bug reports, or leave it on 2.6.20 and live with the fact that some things can't/won't be fixed right, like support for PCI message signaled interrupts?
I'd say let F7 testing iron out 2.6.21 for a while before deciding about FC6. We should be in the part of freeze where serious Fedora weenies are doing a lot of testing.
On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote:
I'd say let F7 testing iron out 2.6.21 for a while before deciding about FC6. We should be in the part of freeze where serious Fedora weenies are doing a lot of testing.
Getting 2.6.21 into FC6 does also have the additional advantage that it's an extra round of testing for what will become the F7 kernel.
It'd be a good idea to nail some of the known outstanding regressions first though I think.
Dave
On 18.04.2007 23:23, Dave Jones wrote:
On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote:
I'd say let F7 testing iron out 2.6.21 for a while before deciding about FC6. We should be in the part of freeze where serious Fedora weenies are doing a lot of testing.
Getting 2.6.21 into FC6 does also have the additional advantage that it's an extra round of testing for what will become the F7 kernel.
+1 -- putting in in updates-testing quite soon might be a start.
CU thl
On Wed, 2007-04-18 at 17:23 -0400, Dave Jones wrote:
On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote:
I'd say let F7 testing iron out 2.6.21 for a while before deciding about FC6. We should be in the part of freeze where serious Fedora weenies are doing a lot of testing.
Getting 2.6.21 into FC6 does also have the additional advantage that it's an extra round of testing for what will become the F7 kernel.
It'd be a good idea to nail some of the known outstanding regressions first though I think.
Please also test that FC6 user space works with this new kernel. Thanks.
David
2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing?
On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote:
2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing?
We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates.
Most of the scary stuff (new libata pata drivers etc), we'd keep off, so things shouldn't be too bad. The timer changes for tickless are probably the only remaining scary thing. For that we have a few choices. - Leave NO_HZ off. Feature parity with FC6, though the code has still changed, and may still find regressions. Probably the safest option. - Turn NO_HZ on. Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) - Turn NO_HZ on, but do the same as we did for MSI (enable the config, but only if you boot with a command line option). Might find us even more regressions, that aren't even relevant upstream.
Chuck?
Dave
On Sun, 29 Apr 2007 14:57:49 -0400 Dave Jones davej@redhat.com wrote:
We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates.
Most of the scary stuff (new libata pata drivers etc), we'd keep off, so things shouldn't be too bad. The timer changes for tickless are probably the only remaining scary thing. For that we have a few choices.
- Leave NO_HZ off. Feature parity with FC6, though the code has still changed, and may still find regressions. Probably the safest option.
- Turn NO_HZ on. Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though)
- Turn NO_HZ on, but do the same as we did for MSI (enable the config, but only if you boot with a command line option). Might find us even more regressions, that aren't even relevant
upstream.
What about MSI? On or off?
On Sun, Apr 29, 2007 at 04:55:15PM -0500, Jay Cliburn wrote:
Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though)
- Turn NO_HZ on, but do the same as we did for MSI (enable the config, but only if you boot with a command line option). Might find us even more regressions, that aren't even relevant
upstream.
What about MSI? On or off?
As mentioned above, the config option is on, but you need a boot-time argument to enable it.
Dave
On Sun, 29 Apr 2007 16:55:15 -0500, Jay Cliburn jacliburn@bellsouth.net wrote:
What about MSI? On or off?
Off for FC6, on for Rawhide, or at least this is how I understood DaveJ's preference. Considering how unstable it is, makes sense, I guess. I have a laptop (Dell 1501), where MSI is DOA. Very fresh unit, PCIe all around, and still...
-- Pete
On Sun, Apr 29, 2007 at 08:30:02PM -0700, Pete Zaitcev wrote:
On Sun, 29 Apr 2007 16:55:15 -0500, Jay Cliburn jacliburn@bellsouth.net wrote:
What about MSI? On or off?
Off for FC6, on for Rawhide, or at least this is how I understood DaveJ's preference.
I did the same thing in rawhide for now too (in the run-up to F7, I wanted it to get some testing before we ship, as that's how we'll end up shipping probably). After F7 is out, I'll disable that patch again in rawhide, run with MSI on by default for a week or so, and see if its any better. I'll also keep an eye on upstream discussion in this area as people are working on improving the heuristic to decide if its supported/useful/necessary.
Considering how unstable it is, makes sense, I guess. I have a laptop (Dell 1501), where MSI is DOA. Very fresh unit, PCIe all around, and still...
Aparently some of the newer Apple hardware _needs_ it enabled too. For every case to do something one way, there's always one to do the opposite it seems.
Dave
Dave Jones wrote:
On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote:
2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing?
We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates.
ok
Most of the scary stuff (new libata pata drivers etc), we'd keep off, so things shouldn't be too bad. The timer changes for tickless are probably the only remaining scary thing. For that we have a few choices.
- Leave NO_HZ off. Feature parity with FC6, though the code has still changed, and may still find regressions. Probably the safest option.
- Turn NO_HZ on. Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though)
what kind of bugs would this trigger? crashes? or "only" some weird timer/clock issues? if this is done does this also mean that we can backport x86_64 tickless for F7 when its ready?
On Mon, Apr 30, 2007 at 12:04:28PM +0200, dragoran wrote:
Most of the scary stuff (new libata pata drivers etc), we'd keep off, so things shouldn't be too bad. The timer changes for tickless are probably the only remaining scary thing. For that we have a few choices.
- Leave NO_HZ off. Feature parity with FC6, though the code has still changed, and may still find regressions. Probably the safest option.
- Turn NO_HZ on. Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though)
what kind of bugs would this trigger? crashes? or "only" some weird timer/clock issues?
all sorts of things rely on timers, so it could manifest itself in any number of ways.
if this is done does this also mean that we can backport x86_64 tickless for F7 when its ready?
Given its still not upstream, it'll likely be a while before it lands in FC6. It'll get backported to F7 first after GA, but first it needs to land in Linus' tree.
Dave
Dave Jones wrote:
On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote:
2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing?
We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates.
This doesn't make me very confident:
http://kernelnewbies.org/known_regressions
I'd like to see some kind of stability in FC6 while FC7 continues shaking out 2.6.21 bugs.
Chuck Ebbert schrieb:
Dave Jones wrote:
On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote:
2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing?
We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates.
This doesn't make me very confident: http://kernelnewbies.org/known_regressions
Well, didn't we have such bugs in the past, too? We just had no compiled list of them afaik...
I'd like to see some kind of stability in FC6 while FC7 continues shaking out 2.6.21 bugs.
Well, getting a quite stable and working-on-lots-of-machines kernel on the install media of F7 is also quite important imho.
/me votes for what davej suggested: "do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates."
Add a "send a announcement 'want do help getting the kernel of F7 tested? Then use "yum --enablerepo=updates-testing update kernel*" and report any bugs'" to it. Well, something like that, I don't know if kernel* really works...
CU thl
Thorsten Leemhuis wrote:
Well, getting a quite stable and working-on-lots-of-machines kernel on the install media of F7 is also quite important imho.
/me votes for what davej suggested: "do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates."
There is another 2.6.20-stable release in the works and I think we should release that for FC5/FC6. The work is already done.
In the meantime I've started collecting fixes for 2.6.21 and I think it will be at least decent after a 40-patch or so update (not just a small two patch update like 2.6.21.1.)
Chuck Ebbert wrote:
release that for FC5/FC6. The work is already done.
In the meantime I've started collecting fixes for 2.6.21 and I think it will be at least decent after a 40-patch or so update (not just a small two patch update like 2.6.21.1.)
ok than push a 2.6.20.X based one and wait a bit until 2.6.21.X gets more stable.
kernel@lists.fedoraproject.org