Jeff Mahoney writes:

Greg KH wrote:

...

As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.

Any thoughts?

Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.

Jeff, could you rename also kernel-bigsmp to "kernel-pae", please? Thanks, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Jan Engelhardt writes:

On Oct 12 2007 17:09, Andreas Jaeger wrote:

...

...

Greg KH wrote:

...

As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.

Any thoughts?

Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.

Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?

It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.

I do know exactly this. We want to install this kernel by default on i386 since it allows us to use non-executable stack etc (a PAE feature). We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel. And therefore my suggestion to change it, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Fri, 12 Oct 2007, Jan Engelhardt wrote:

...

We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.

...

And therefore my suggestion to change it,

So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).

well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ? - drivers not available for bigsmp/pae - software not working with it (AFAIR vmware has been fixed) - functionality not working: suspend as most important feature Note, I'm not saying any of these don't work, I'm rather asking if they all do ? And wasn't there the story that bigsmp also uses a different memory layout (kernel/userspace split). Are there any drawbacks to that setup ? -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Ruediger Oertel writes:

On Fri, 12 Oct 2007, Jan Engelhardt wrote:

...

...

We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.

...

And therefore my suggestion to change it,

So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).

well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ? - drivers not available for bigsmp/pae

That were the first complains - and we fixed all of these.

- software not working with it (AFAIR vmware has been fixed)

There were some reports that were rather obscure but I'm not aware of it.

- functionality not working: suspend as most important feature

This has been fixed for 10.3.

Note, I'm not saying any of these don't work, I'm rather asking if they all do ?

And wasn't there the story that bigsmp also uses a different memory layout (kernel/userspace split). Are there any drawbacks to that setup ?

Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Jan Engelhardt writes:

So the name change is because they complained they got a bigsmp? (That's how I read it.)

They complained since they just read "bigsmp" and had a Laptop.

I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).

They were not aware of PAE... Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Fri, Oct 12, 2007 at 05:27:58PM +0200, Jan Engelhardt wrote:

On Oct 12 2007 17:09, Andreas Jaeger wrote:

...

...

Greg KH wrote:

...

As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.

Any thoughts?

Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.

Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?

It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.

We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements). So we would really like a neutral name here. We are open for other suggestions ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:

On Oct 12 2007 17:43, Marcus Meissner wrote:

...

We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).

So we would really like a neutral name here. We are open for other suggestions ;)

If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already.

Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]

bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time.

kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae Hmmmmmmmmmmmmmmmmmmmmmmmm Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:

On Fri, Oct 12, 2007 at 06:10:32PM +0200, Marcus Meissner wrote:

...

On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:

...

...

We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).

So we would really like a neutral name here. We are open for other suggestions ;) If you want to make bigsmp the default because of NX,

On Oct 12 2007 17:43, Marcus Meissner wrote: then just /make/ it the default (read: kernel-default.i586.rpm) already.

Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]

bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time. kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae

Hmmmmmmmmmmmmmmmmmmmmmmmm

How about bigsmp -> default and there not being anymore "non pae" kernel? Becides the memory size hit, what kinds of problems would that cause? What machines still need the "nonpae" kernel?

I don't know the exact models, but there were enough bug reports indicating that the bigsmp kernel didn't boot on various machines. There are definitely machines out there. I'm all for renaming kernel-bigsmp to kernel-default. kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHD6X9LPWxlyuTD7IRAtjuAJ0eXCrXufHhxl8mYFeBDeEp48ceFQCbBLKB Rs3Lij3zwhJfyC7fa88vpzg= =0BJe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Oct 12, 2007 at 10:05:20AM -0700, Greg KH wrote:

On Fri, Oct 12, 2007 at 12:51:09PM -0400, Jeff Mahoney wrote:

...

I'm all for renaming kernel-bigsmp to kernel-default.

No objection from me either.

...

kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.

kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)

Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call. What about Virtual Machines? Do they all expose the PAE flag? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Oct 12, 2007 at 07:15:15PM +0200, Jan Engelhardt wrote:

On Oct 12 2007 19:10, Marcus Meissner wrote:

...

...

...

kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.

kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)

I bet there's at least someone out there who will manage to mix up nvidia-legacy-gfx with kernel-legacy...

...

Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call.

So how many non-Novells actually use bigsmp over default?

Good question.

And do all machines that support PAE actually support NX?

I have no good idea here. The older ones (>4 years) might not yet. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

* Marcus Meissner [2007-10-12 19:16]:

On Fri, Oct 12, 2007 at 07:15:15PM +0200, Jan Engelhardt wrote:

...

On Oct 12 2007 19:10, Marcus Meissner wrote:

...

...

...

kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.

kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)

I bet there's at least someone out there who will manage to mix up nvidia-legacy-gfx with kernel-legacy...

...

Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call.

So how many non-Novells actually use bigsmp over default?

Good question.

bwalle@newton:~> cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 666.587 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en bogomips : 1334.63 That's not legacy, that's 1/2 year old! ;) Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Oct 13 2007 00:01, Ruediger Oertel wrote:

well, already listed in the thread: - older AMDs - transmeta I'll add: - VIA (my beloved EPIA box)

Yup, here is another one, a fanless BA-4000[1]: scn:~ # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 733.008 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en bogomips : 1468.17 clflush size : 32 [1] meh, they removed the page with the VIA CPU, but the Intel sister product is at http://www.atiosys.com/us/html/products/product.asp?cid=4&pid=101 (Runs opensuse 10.3 beta2 in only 348MB! - but needed to kill /usr/share/doc and tons of useless locales) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Bernhard Walle writes:

* Marcus Meissner [2007-10-12 18:10]:

...

kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae

I don't like this because it leads to update problem. Even if our tools handle this correctly, humans may not and if the kernel-default is unbootable on some machines ... no.

Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae And install kernel-pae by default, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

* Jan Engelhardt [2007-10-13 18:47]:

On Oct 13 2007 18:40, Andreas Jaeger wrote:

...

Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae

And install kernel-pae by default,

Oh yeah, I vote for this one. (Though kernel-default loses its meaning if it is not default anymore :-))

Well, for SLES 10 we also have kernel-default (1 processor) and kernel-smp (SMP machines). I don't have any statistics, but I really think there are more SMP servers currently than UMP servers (HyperThreading and dual core also count as SMP). Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

* Andreas Jaeger [2007-10-13 18:40]:

Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae

And install kernel-pae by default,

Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel). Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Oct 13 2007 20:11, Andreas Jaeger wrote:

...

* Andreas Jaeger [2007-10-13 18:40]:

...

Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae

And install kernel-pae by default,

Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel).

Yes, that's my suggestion,

The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Oct 14 2007 01:17, Marcus Meissner wrote:

...

The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks?

The installer runs of course without PAE.

This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference.

(Just in case you missed: would not it make sense to run the installer always in 32-bit mode?) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Sat, 13 Oct 2007, Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Jan Engelhardt wrote:

...

On Oct 14 2007 01:17, Marcus Meissner wrote:

...

...

The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks? The installer runs of course without PAE.

This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference.

(Just in case you missed: would not it make sense to run the installer always in 32-bit mode?)

No. When installing 64 bit packages, post-install scripts would want to use the installed binaries.

same for hardware configuration, there is no guarantee that the configuration uses the same drivers and/or settings for 32/64 bit. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:

On Oct 10 2007 11:33, Greg KH wrote:

...

As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.

Any thoughts?

Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)

[1] 176df2457ef6207156ca1a40991c54ca01fef567

The fix for that one is going through QA and will be released RSN. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHDTzGLPWxlyuTD7IRApPMAJ4x0WDr4U4k2DKTLEmCWYcBc5yqtACbBjcC M90O2lUAZJ76e8UzKSv11uc= =Whed -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Oct 10 2007 14:14, Greg KH wrote:

...

See this patch..

Hm, I do not think this is going to work as we generate those spec files automatically from out build process. The "raw" spec files already look like much of what you have proposed, so there isn't really anything needing to be changed here.

The raw specfiles are not yet provided. And, I think rpm specfiles should really use rpm magic where possible, and not so much s/// magic.

What is the main issue? It's just hard to generate new packages from these spec files?

At the moment somewhere between hard and just-very-time-consuming. It took me quite some time (probably half a day) to mock up kernel-source.spec so much that the -rt kernel can also have a /usr/src/linux/ source thing so you can build KMPs against it. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Oct 10, 2007 at 10:47:17PM +0200, Jan Engelhardt wrote:

On Oct 10 2007 11:33, Greg KH wrote:

...

As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.

Any thoughts?

Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)

[1] 176df2457ef6207156ca1a40991c54ca01fef567

Updated kernels were released today. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org