On Wed, 2011-11-09 at 14:43 -0700, Tim Gardner wrote:
> Per discussion at UDS the kernel team is proposing to drop the non-PAE
> i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> Those CPUs that do not have i686 and PAE support will be orphaned. To
> the best of my knowledge, these include Intel CPUs prior to Pentium II,
> 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> laptop or desktop class CPUs being produced that do not meet these
> minimum requirements.

The Geode LX AFAIK is certainly still in use. I know when I was looking
to buy an embedded system earlier this year, I came across quite a few
of these in new systems.

What about simply demoting the binary packages for this flavor, but
still build it? We wouldn't have to explicitly test it for SRUs/security
updates or deal with it with LTS backorts, but it would presumably still
be in ok shape since we would be actively testing the i686 pae kernel.
It could also provide a (albeit manual) fallback for people where the
pae kernel doesn't work on their system.

--
Jamie Strandboge | http://www.canonical.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Hi,

On Mon, Nov 14, 2011 at 12:24:22PM -0600, Jamie Strandboge wrote:
> On Wed, 2011-11-09 at 14:43 -0700, Tim Gardner wrote:
> > Per discussion at UDS the kernel team is proposing to drop the non-PAE
> > i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
> > Those CPUs that do not have i686 and PAE support will be orphaned. To
> > the best of my knowledge, these include Intel CPUs prior to Pentium II,
> > 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
> > laptop or desktop class CPUs being produced that do not meet these
> > minimum requirements.
>
> The Geode LX AFAIK is certainly still in use. I know when I was looking
> to buy an embedded system earlier this year, I came across quite a few
> of these in new systems.
>
> What about simply demoting the binary packages for this flavor, but
> still build it? We wouldn't have to explicitly test it for SRUs/security
> updates or deal with it with LTS backorts, but it would presumably still
> be in ok shape since we would be actively testing the i686 pae kernel.
> It could also provide a (albeit manual) fallback for people where the
> pae kernel doesn't work on their system.

I would really appreciate this approach. I think these CPUs are primarily used
in thin clients, appliances, embedded, etc. I suspect having the kernel
available in the repos is sufficient in most of those cases.

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Hi Tim,

On Wed, Nov 09, 2011 at 02:43:28PM -0700, Tim Gardner wrote:
> Per discussion at UDS the kernel team is proposing to drop the
> non-PAE i386 flavour. The upgrade path for non-PAE users will be the
> PAE kernel. Those CPUs that do not have i686 and PAE support will be
> orphaned. To the best of my knowledge, these include Intel CPUs
> prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far
> as I know, there are no laptop or desktop class CPUs being produced
> that do not meet these minimum requirements.

> Before I do something that is difficult to revert, I would like to
> hear from the development community why we should continue to
> maintain a kernel flavour that is (in my opinion) getting
> increasingly low utilization. It is my feeling that an extremely
> high percentage of users of the non-PAE kernel have a CPU that is
> PAE capable.

> If there is sufficient community demand (and support), I would be
> willing to sponsor the first non-PAE kernel upload to Universe.

As I mentioned to you at UDS, I think this is the wrong way to go about
keeping the non-PAE kernel. *IF* we are going to keep it, it's much more
efficient to build this as an additional, universe-only flavor from the main
source package. Yes, this would occasionally mean additional work on the
part of the kernel team to keep the config up to date; but the alternative
is that a lot more work would have to be done to manually keep the non-PAE
kernel flavor in sync (syncing git trees, uploading multiple source
packages, archive processing of separate uploads for security updates).

If we're going to do this, let's please do it the right way, from a single
source package that only needs to be updated once.

If continuing to build this from the linux package is a significant
maintenance burden for the kernel team, that's certainly a factor to
consider in deciding whether to drop the package; but I don't understand how
that should be as the delta between the pae and non-pae packages should be
minimal, stable, and require no ongoing manual effort. If maintaining this
flavor is actively consuming kernel team time, that seems like a fixable
bug.


I certainly agree that we should be delivering PAE to i386 users by default
these days, and I think it's fine to not provide support for installing on
non-PAE systems (which is implied by putting the non-PAE kernel to universe
and making PAE the default kernel in the installer images). And I certainly
would not expect anyone to spend time supporting a PAE flavor for LTS
backported kernels, given that the purpose of LTS backports is enablement of
*new* hardware. But unless people are just plain mistaken about what
hardware supports PAE or not, I think this thread is evidence that non-PAE
hardware is still relevant over the 12.04 support timeframe to a number of
our users and we should consider continuing this flavor for 12.04.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On 11/09/2011 02:43 PM, Tim Gardner wrote:

Per discussion at UDS the kernel team is proposing to drop the non-PAE
i386 flavour. The upgrade path for non-PAE users will be the PAE kernel.
Those CPUs that do not have i686 and PAE support will be orphaned. To
the best of my knowledge, these include Intel CPUs prior to Pentium II,
400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no
laptop or desktop class CPUs being produced that do not meet these
minimum requirements.

Before I do something that is difficult to revert, I would like to hear
from the development community why we should continue to maintain a
kernel flavour that is (in my opinion) getting increasingly low
utilization. It is my feeling that an extremely high percentage of users
of the non-PAE kernel have a CPU that is PAE capable.

If there is sufficient community demand (and support), I would be
willing to sponsor the first non-PAE kernel upload to Universe.

https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview

We'll be conducting a similar survey for powerpc.

rtg

P.S. For those of you that are totally confused by this email, PAE
(Physical Address Extension) was an addition to 32 bit x86 CPUs that
allowed them to address more then 4GB physical memory.

http://en.wikipedia.org/wiki/Physical_Address_Extension


Thank you to everyone who responded to this thread.

To summarize, no compelling hard evidence has been presented to change
my original decision. I am opposed to supporting non-PAE CPUs for
another 5 years.


Colin King has developed power and performance profiling data that
indicate the differences between PAE and non-PAE are negligible. I've
also discussed this with OEM regarding possible future LTSP projects and
have concluded it will have no detrimental impact.


Every flavour maintained by the kernel team has an incremental impact,
especially when it comes to test builds and the full packaging cycle.
Every flavour must also be tracked by meta packages. Every flavour has
its unique class of bugs; non-pae has a ginormous and ugly NX emulation
patch that has consumed substantial maintenance resources in the past,
not to mention all of the bugs complaining about memory holes and the
4Gb limit.


The kernel team has limited resources. Obviously I want to apply what
resources we have to the problems that affect the most important
platforms. Furthermore, I anticipate new ARM flavours in the coming
months which will take up any slack afforded by the loss of non-PAE.


It is my recommendation that folks running PAE incapable CPUs stay on
Lucid (10.04), a release for which they'll still receive more then 3
years of official support.


If you feel passionately that I've made an incorrect decision, then I
suggest contacting the Ubuntu technical board.


https://wiki.ubuntu.com/TechnicalBoard

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Nov 28, 2011 at 11:40 AM, Tim Gardner <tim.gardner@canonical.com> wrote:
> It is my recommendation that folks running PAE incapable CPUs stay on Lucid
> (10.04), a release for which they'll still receive more then 3 years of
> official support.

No longer matters for the 5 year old computer in my family (switching
back to Windows), but...

wouldn't that be one more year (-ish) of official support? The desktop
is only supported 3 years.

--
Mackenzie Morgan

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote:
> non-pae has a ginormous and ugly NX emulation patch

This is about dropping non-PAE support, not dropping non-NX support. The NX
emulation patch must remain in the kernel since a large number of systems
have PAE but not NX.

You can see this in the table here:
https://wiki.ubuntu.com/Security/Features#nx
Dropping non-PAE just eliminates the top line in that table. NX-emu will
still be needed.

> that has consumed substantial maintenance resources in the past,

I'm also curious about this claim, as you've expressed to me in the past
that carrying it has been surprisingly trivial. In fact, since I'm the one
maintaining it these days, it's actually going to require 0 resources from
Canonical.

http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu

> The kernel team has limited resources. Obviously I want to apply
> what resources we have to the problems that affect the most
> important platforms. Furthermore, I anticipate new ARM flavours in
> the coming months which will take up any slack afforded by the loss
> of non-PAE.

I'm curious why pushing non-PAE to universe and leaving it in the main
linux source package is a burden? Then people using non-PAE get automatic
security updates without any hassle on anyone's part. This is what the
Ubuntu Security Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html
as well as the Ubuntu Platform Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html

I'm not convinced there's enough evidence to say that dropping it from the
main linux source package will actually save any time at all.

-Kees

--
Kees Cook

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On 11/28/2011 11:44 AM, Kees Cook wrote:

On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote:

non-pae has a ginormous and ugly NX emulation patch


This is about dropping non-PAE support, not dropping non-NX support. The NX
emulation patch must remain in the kernel since a large number of systems
have PAE but not NX.

You can see this in the table here:
https://wiki.ubuntu.com/Security/Features#nx
Dropping non-PAE just eliminates the top line in that table. NX-emu will
still be needed.



I guess you are correct. I naively assumed that execute-disable was
introduced with PAE in the Pentium Pro series. However, it did not
appear in Intel CPUs until Pentium 4 (approx Q1 2005). AMD had it from
the beginning in the Athlon series.



that has consumed substantial maintenance resources in the past,


I'm also curious about this claim, as you've expressed to me in the past
that carrying it has been surprisingly trivial. In fact, since I'm the one
maintaining it these days, it's actually going to require 0 resources from
Canonical.

http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu



I did say "in the past". I remember encountering several issues with the
early implementation, as well as maintenance hassles while 32 and 64 bit
arch support was converging. I would characterize the NX emulation patch
as deeply intrusive, arguably one of the more complex patches against
the core of Linux that we carry.


Its a moot point given the model gap between PAE and NX introduction.


The kernel team has limited resources. Obviously I want to apply
what resources we have to the problems that affect the most
important platforms. Furthermore, I anticipate new ARM flavours in
the coming months which will take up any slack afforded by the loss
of non-PAE.


I'm curious why pushing non-PAE to universe and leaving it in the main
linux source package is a burden? Then people using non-PAE get automatic
security updates without any hassle on anyone's part. This is what the
Ubuntu Security Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html
as well as the Ubuntu Platform Team manager wants:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html

I'm not convinced there's enough evidence to say that dropping it from the
main linux source package will actually save any time at all.



Dropping this flavour saves 5 minutes per build on a 4-way 80 thread
server, which for some of the team can add up to quite a bit of time
over the course of a day. Its one less variant that needs to be tested
in Q/A, and its one less flavour we have to mess with in our meta and
LBM packages.


rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

I hate to revive this, but I just wanted to share that the 1.4GHz Pentium M in my Dell Latitude D505 from 2004 does not support the PAE kernel in Precise. Found that out just now when testing a Lubuntu Precise daily livecd for the first time.

Just thought everyone should know that non-pae doesn't mean 16 years ago -- it means 8 years ago, at least for me, on a perfectly good 512MB RAM system that I use as my main production machine.

-Stenten

On Mon, Nov 28, 2011 at 4:48 PM, Tim Gardner <tim.gardner@canonical.com> wrote:

On 11/28/2011 11:44 AM, Kees Cook wrote:


On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote:


non-pae has a ginormous and ugly NX emulation patch




This is about dropping non-PAE support, not dropping non-NX support. The NX

emulation patch must remain in the kernel since a large number of systems

have PAE but not NX.



You can see this in the table here:

https://wiki.ubuntu.com/Security/Features#nx

Dropping non-PAE just eliminates the top line in that table. NX-emu will

still be needed.






I guess you are correct. I naively assumed that execute-disable was introduced with PAE in the Pentium Pro series. However, it did not appear in Intel CPUs until Pentium 4 (approx Q1 2005). AMD had it from the beginning in the Athlon series.





that has consumed substantial maintenance resources in the past,




I'm also curious about this claim, as you've expressed to me in the past

that carrying it has been surprisingly trivial. In fact, since I'm the one

maintaining it these days, it's actually going to require 0 resources from

Canonical.



http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu







I did say "in the past". I remember encountering several issues with the early implementation, as well as maintenance hassles while 32 and 64 bit arch support was converging. I would characterize the NX emulation patch as deeply intrusive, arguably one of the more complex patches against the core of Linux that we carry.




Its a moot point given the model gap between PAE and NX introduction.




The kernel team has limited resources. Obviously I want to apply

what resources we have to the problems that affect the most

important platforms. Furthermore, I anticipate new ARM flavours in

the coming months which will take up any slack afforded by the loss

of non-PAE.




I'm curious why pushing non-PAE to universe and leaving it in the main

linux source package is a burden? Then people using non-PAE get automatic

security updates without any hassle on anyone's part. This is what the

Ubuntu Security Team manager wants:

https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html

as well as the Ubuntu Platform Team manager wants:

https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html



I'm not convinced there's enough evidence to say that dropping it from the

main linux source package will actually save any time at all.






Dropping this flavour saves 5 minutes per build on a 4-way 80 thread server, which for some of the team can add up to quite a bit of time over the course of a day. Its one less variant that needs to be tested in Q/A, and its one less flavour we have to mess with in our meta and LBM packages.




rtg

--

Tim Gardner tim.gardner@canonical.com



--

kernel-team mailing list

kernel-team@lists.ubuntu.com

https://lists.ubuntu.com/mailman/listinfo/kernel-team



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team