Re: How should anaconda check for PAE? (was Re: arch fun.)
Thorsten Leemhuis wrote: On 25.02.2009 13:27, Chris Lalancette wrote: Gerd Hoffmann wrote: We can also simply do this: - Install PAE kernel if the CPU supports PAE. i.e. make PAE the default kernel. Yes, I really think we should just do this. It's simple, it means we get the logic right for Xen as well as bare-metal (without any special cases), and the performance hit for those who have PAE and 4GB isn't that bad, I don't think (although numbers one way or the other would be interesting to see). What about compatibility problems? My old laptop had a PAE capable CPU but could not boot a PAE kernel -- I noticed when I was trying a PAE kernel for some tests two or three years ago. I asked a kernel-developer back then if it was worth reporting and I got told that such problems are not unusual and often BIOS or hardware problems. Those likely didn't vanish magically is that statement is correct. Hm, it's an interesting point, and not one that I've heard about or seen before. Xen in Fedora required PAE for quite some time, and despite plenty of other problems (mostly having to do with people wanting to run Xen on non-PAE platforms), we didn't hear about any of this specific problem. Doesn't mean it doesn't exist, though :). Do you have pointers to specific problems? A quick google didn't turn up anything, but I didn't try all that hard. -- Chris Lalancette ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
On Wed, 25 Feb 2009 14:15:37 +0100 Thorsten Leemhuis fed...@leemhuis.info wrote: On 25.02.2009 13:27, Chris Lalancette wrote: Gerd Hoffmann wrote: We can also simply do this: - Install PAE kernel if the CPU supports PAE. i.e. make PAE the default kernel. Yes, I really think we should just do this. It's simple, it means we get the logic right for Xen as well as bare-metal (without any special cases), and the performance hit for those who have PAE and 4GB isn't that bad, I don't think (although numbers one way or the other would be interesting to see). What about compatibility problems? My old laptop had a PAE capable CPU but could not boot a PAE kernel -- I noticed when I was trying a PAE kernel for some tests two or three years ago. I asked a kernel-developer back then if it was worth reporting and I got told that such problems are not unusual and often BIOS or hardware problems. Those likely didn't vanish magically is that statement is correct. The algorithm I posted should handle that. If you support NX or you have 4GB of memory then it's pretty much impossible for you to have one of those old CPUs. And all SVM/VMX capable machines support NX so we'd always have the right kernel for them too. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
How should anaconda check for PAE? (was Re: arch fun.)
On Fri, 2009-02-06 at 10:19 -0500, Bill Nottingham wrote: Chris Lalancette (clala...@redhat.com) said: Do we know if anaconda is going to change to choose kernel-PAE for any machine with the PAE flag, regardless of the amount of memory? That's the plan - the patch should be pretty trivial. I haven't seen this patch yet. As far as I can tell, current anaconda installs the PAE kernel by default if isPaeAvailable() returns true[1]. isPaeAvailable() uses the (somewhat odd) test of checking to see if /proc/iomem has a line where the start address is more than 32 bits long[2] - AFAICT it ignores the cpu flags entirely. In a discussion on IRC earlier today, cebbert mentioned that we might want a check more like: (PAE_flag and =4GB RAM) or (PAE_flag and vmx_flag and =1GB RAM) where vmx_flag is the flag for hardware virt stuff. Is this a good test? Some further questions: - Is a PAE kernel required for proper virt support? - Should we be using the PAE kernel *regardless* of memory size (as implied above) or do we want some memory requirements? -w [1] http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=blob;f=yuminstall.py;hb=HEAD#l1259 [2] http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=blob;f=isys/isys.py#l1038 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
- Should we be using the PAE kernel *regardless* of memory size (as implied above) or do we want some memory requirements? It's always preferable on hardware (where pae actually works) that also has the nx cpu feature. True PROT_EXEC enforcement (NX) is only available in PAE mode. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
On Tue, 24 Feb 2009 15:38:42 -0800 (PST) Roland McGrath rol...@redhat.com wrote: If we have NX (which anything made in the last few years will) it's a performance win to use the hardware NX instead of the segment limit hack we implemented in execshield. It's more than performance. The segment limit hack is a hack, and does not actually do full enforcement in all cases (though we have already bent over backward to ensure that these cases do not come up by default). Hardware NX is 100% reliable. We also need to look for lm to see if we can install a 64-bit kernel. So something like: if (lm) install 64-bit else if (!pae) || (!nx memory 4GB) install i586 else install PAE ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, 2009-02-06 at 21:08 +0100, Thorsten Leemhuis wrote: On 06.02.2009 20:55, Kyle McMartin wrote: On Fri, Feb 06, 2009 at 08:47:41PM +0100, Thorsten Leemhuis wrote: Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). And it would make documentation a whole lot easier, making Fedora easier to use. But whatever. You guys on IRC made clearly indicated you option reg. kmod so I don't think it's worth arguing further. This doesn't make Fedora easier to use. It makes fedora + random external packages easier to use. Tough. Sure, I'm well aware of that as you can see from a earlier mail in this thread. But most people and even a lot of print and online magazine don't differentiate like that afaics. Besides, there's no reason to go out of the way not to care about things everyday users want to do...whether we happen to like it or not. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On 06.02.2009 12:07, Prarit Bhargava wrote: Dave Jones wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. I was thinking about this for a little while. [...] I'm probably missing something obvious Yes -- all that have kernel.i686 installed now would get the new kernel.i686 later (the one with PAE). But the latter will not boot on all machines where the curret kernel.i686 works. If there is no kernel.i686 (because it is named kernel-PAE.i686), then yum/anaconda will automatically install kernel.i586, which is what should happen to make sure all system still boot after updating. But maybe some yum/anaconda plugin/magic could automatically select the best kernel on update. Not sure, but something like that might be needed for Live-CD-Installs anyway CU knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Thorsten Leemhuis (fed...@leemhuis.info) said: Yes -- all that have kernel.i686 installed now would get the new kernel.i686 later (the one with PAE). But the latter will not boot on all machines where the curret kernel.i686 works. If there is no kernel.i686 (because it is named kernel-PAE.i686), then yum/anaconda will automatically install kernel.i586, which is what should happen to make sure all system still boot after updating. But maybe some yum/anaconda plugin/magic could automatically select the best kernel on update. Not sure, but something like that might be needed for Live-CD-Installs anyway We could invent a new rpm arch. This may not be practical, though. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Dave Jones wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Hi Dave, I was thinking about this for a little while. Can't we do this instead: 1. move kernel-PAE.686 config options to kernel.686 (I'm going to refer to this as the new kernel.686) 2. kill kernel-PAE.686 3. modify the spec file for the new kernel.686 to obsolete kernel-PAE.686 ? I'm probably missing something obvious but having PAE in there seems strange to me. P. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 06:07:13AM -0500, Prarit Bhargava wrote: Dave Jones wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Hi Dave, I was thinking about this for a little while. Can't we do this instead: 1. move kernel-PAE.686 config options to kernel.686 (I'm going to refer to this as the new kernel.686) 2. kill kernel-PAE.686 3. modify the spec file for the new kernel.686 to obsolete kernel-PAE.686 ? I'm probably missing something obvious but having PAE in there seems strange to me. It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, 2009-02-06 at 11:39 -0500, Dave Jones wrote: It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. I'm missing something... Is there really that much additional work that we can't keep the UP/SMP kernel around for the time being? If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12, I think you could get away with just renaming the kernel - after all, other kernel features do change over time that break older systems. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:23:51PM -0500, Jon Masters wrote: On Fri, 2009-02-06 at 11:39 -0500, Dave Jones wrote: It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. I'm missing something... Is there really that much additional work that we can't keep the UP/SMP kernel around for the time being? ?? We haven't shipped a UP x86 kernel in about 3 years. If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12 Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. Right -- and that's a good point to keep in mind. IMO we shouldn't break *any* systems when we do this change. Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? Why not wait for the dynamic PAE stuff to settle upstream and then make the change? Then we can properly (IMO) drop kernel-PAE.686 and stick with kernel.686. What happens if we postpone this until F12? P. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 6, 2009 at 6:34 PM, Prarit Bhargava pra...@redhat.com wrote: Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. Right -- and that's a good point to keep in mind. IMO we shouldn't break *any* systems when we do this change. Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? Why not wait for the dynamic PAE stuff to settle upstream and then make the change? Then we can properly (IMO) drop kernel-PAE.686 and stick with kernel.686. dynamic PAE ? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:34:04PM -0500, Prarit Bhargava wrote: Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? it's vaporware. Why not wait for the dynamic PAE stuff to settle upstream and then make the change? no-one seems to actually be doing anything. Then we can properly (IMO) drop kernel-PAE.686 and stick with kernel.686. What happens if we postpone this until F12? I bet nothing will have changed. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 12:38:56PM -0500, Prarit Bhargava wrote: dynamic PAE ? Uh -- I can see how that is confusing :) Sorry, let me make another attempt at that. What I should have said was that there are patches floating around to make PAE dynamically selectable -- I think the example that was referenced was the smp alternatives code. The idea has been floated, but no patches ever happened afaik. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Dave Jones wrote: On Fri, Feb 06, 2009 at 12:34:04PM -0500, Prarit Bhargava wrote: Given the other information coming through (about dynamic kernel PAE enable), should we really being doing this right now? it's vaporware. Why not wait for the dynamic PAE stuff to settle upstream and then make the change? no-one seems to actually be doing anything. ... grr... /me hates it when that happens P. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, 2009-02-06 at 12:29 -0500, Dave Jones wrote: On Fri, Feb 06, 2009 at 12:23:51PM -0500, Jon Masters wrote: On Fri, 2009-02-06 at 11:39 -0500, Dave Jones wrote: It's still the same upgrade problem. Someone will be going from 'kernel' with no PAE to 'kernel' with PAE, and on a CPU without PAE, that means they can't boot any more. In that situation they need to go 'kernel'(i686) to 'kernel'(i586) which aparently the tools already handle. I'm missing something... Is there really that much additional work that we can't keep the UP/SMP kernel around for the time being? ?? We haven't shipped a UP x86 kernel in about 3 years. Er...smp alternatives counts to me as UP. Shame there's no equiv. for PAE. If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12 Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. If kernel must die, isn't there some way to make the i586 kernel replace it? I think that's what notting was getting at - kind of how we have i686 on i386 for the kernel now anyway...but I guess it gets more involved if the flavo[u]rs are not on the same arch - was that your complaint Bill? Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, 2009-02-06 at 12:58 -0500, Dave Jones wrote: On Fri, Feb 06, 2009 at 12:44:28PM -0500, Jon Masters wrote: ?? We haven't shipped a UP x86 kernel in about 3 years. Er...smp alternatives counts to me as UP. Shame there's no equiv. for PAE. oh I see what you were saying. you meant the non-pae kernel. gotcha. It's ok. I was just talking to Prarit on other IRC about dynamic PAE. I think he won't like it when he looks more at what's involved - you'll need to rewalk all the kernel page tables on transition and lots more ugly shit. If PAE were default installed in F11 for everyone and it were publicly announced that support for non-PAE was dying in F12 Part of the problem with that idea is that the Pentium M laptops without PAE aren't that old. This might upset quite a few people. If kernel must die, isn't there some way to make the i586 kernel replace it? That's what we've done. And I'm told yum handles the transition automatically. Not quite though from what I hear (trying to reconcile what Thorsten said). But perhaps he was solely complaining that most people would run PAE and thus have to type kmod-crud-PAE. I still stand by what I just said to Prarit that I'd kill off the PAE kernel and find out who complains about having a 32GB i686 non-x86_64 system around...but that's just my Friday sense of humo[u]r. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 01:01:43PM -0500, Jon Masters wrote: Not quite though from what I hear (trying to reconcile what Thorsten said). But perhaps he was solely complaining that most people would run PAE and thus have to type kmod-crud-PAE. The kmod thing is a non-argument afaics. If you currently use kernel-686, you'll be running kernel-586 in F11, so you have 'kmod-foo' to go with it. If you currently use kernel-686-PAE, you'll be running the _same_ thing in F11. The only possible change, is that with anaconda recognising PAE and installing the PAE kernel by default, more people will be running it. So it's just exposing it to more people. I don't see how this is a problem. said to Prarit that I'd kill off the PAE kernel and find out who complains about having a 32GB i686 non-x86_64 system around...but that's just my Friday sense of humo[u]r. PAE also gets you NX support, so it's not just a 4G thing. (Which means you won't need to run the nasty execshield segment limit hacks -- One more nail in execshields coffin) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 10:19:17AM -0500, Bill Nottingham wrote: Thorsten Leemhuis (fed...@leemhuis.info) said: Yes -- all that have kernel.i686 installed now would get the new kernel.i686 later (the one with PAE). But the latter will not boot on all machines where the curret kernel.i686 works. If there is no kernel.i686 (because it is named kernel-PAE.i686), then yum/anaconda will automatically install kernel.i586, which is what should happen to make sure all system still boot after updating. But maybe some yum/anaconda plugin/magic could automatically select the best kernel on update. Not sure, but something like that might be needed for Live-CD-Installs anyway We could invent a new rpm arch. This may not be practical, though. x86_pae would be good. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Bill Nottingham wrote: Chris Lalancette (clala...@redhat.com) said: Do we know if anaconda is going to change to choose kernel-PAE for any machine with the PAE flag, regardless of the amount of memory? That's the plan - the patch should be pretty trivial. Yep, I expect it to be. I just wanted to check that this is actually what was going to happen. OK, that's great; that should fix the Xen bug quite nicely. Thanks! -- Chris Lalancette ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 08:47:41PM +0100, Thorsten Leemhuis wrote: Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). And it would make documentation a whole lot easier, making Fedora easier to use. But whatever. You guys on IRC made clearly indicated you option reg. kmod so I don't think it's worth arguing further. This doesn't make Fedora easier to use. It makes fedora + random external packages easier to use. Tough. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On 06.02.2009 20:55, Kyle McMartin wrote: On Fri, Feb 06, 2009 at 08:47:41PM +0100, Thorsten Leemhuis wrote: Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). And it would make documentation a whole lot easier, making Fedora easier to use. But whatever. You guys on IRC made clearly indicated you option reg. kmod so I don't think it's worth arguing further. This doesn't make Fedora easier to use. It makes fedora + random external packages easier to use. Tough. Sure, I'm well aware of that as you can see from a earlier mail in this thread. But most people and even a lot of print and online magazine don't differentiate like that afaics. CU knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Thorsten Leemhuis (fed...@leemhuis.info) said: I don't see how this is a problem. Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). Well, the problem is that you'd have to define a way that the now PAE-ful kernel.i686 is not installed on some i686 boxes. That gets a lot more complicated. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Fri, Feb 06, 2009 at 03:11:37PM -0500, Bill Nottingham wrote: Thorsten Leemhuis (fed...@leemhuis.info) said: I don't see how this is a problem. Getting rid of the suffix -PAE afaics would solve exactly the problem that now is just exposed to more people (or might make solving it a lot easier afaics). Well, the problem is that you'd have to define a way that the now PAE-ful kernel.i686 is not installed on some i686 boxes. That gets a lot more complicated. yum-appropriate-kernel-plugin.py that grovels /proc/cpuinfo? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
arch fun.
As per the discussion in #fedora-meeting today,
we're killing off kernel-i686, and just shipping..
* kernel.i586
* kernel-PAE.686
Patch below seems to dtrt.. comments?
Looking at the generated config files, the biggest difference
seems to be that kernel-PAE enables Xen and all it's related
dependancies.
Dave
Index: Makefile.config
===
RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.config
--- Makefile.config 26 Jan 2009 07:19:13 - 1.69
+++ Makefile.config 5 Feb 2009 20:09:20 -
@@ -6,7 +6,7 @@ CFG = kernel-$(VERSION)
CONFIGFILES= \
$(CFG)-i586.config \
- $(CFG)-i686.config $(CFG)-i686-PAE.config \
+ $(CFG)-i686-PAE.config \
$(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \
$(CFG)-x86_64.config $(CFG)-x86_64-debug.config \
$(CFG)-s390x.config $(CFG)-arm.config \
@@ -63,9 +63,6 @@ temp-s390-generic: config-s390x temp-gen
temp-ia64-generic: config-ia64-generic temp-generic
perl merge.pl $^ $@
-kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic
- perl merge.pl $^ i386 $@
-
kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic
perl merge.pl $^ i386 $@
Index: config-i586
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-i586,v
retrieving revision 1.5
diff -u -p -r1.5 config-i586
--- config-i586 14 Feb 2008 19:56:06 - 1.5
+++ config-i586 5 Feb 2009 20:09:20 -
@@ -6,4 +6,3 @@ CONFIG_HIGHMEM4G=y
CONFIG_X86_POWERNOW_K6=m
-# CONFIG_KVM is not set
Index: config-i686
===
RCS file: config-i686
diff -N config-i686
--- config-i686 12 Jul 2007 19:15:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,8 +0,0 @@
-CONFIG_M686=y
-# CONFIG_NOHIGHMEM is not set
-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
-
-CONFIG_CRYPTO_DEV_PADLOCK=m
-CONFIG_CRYPTO_DEV_PADLOCK_AES=m
-CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
Index: config-x86-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86-generic,v
retrieving revision 1.63
diff -u -p -r1.63 config-x86-generic
--- config-x86-generic 30 Jan 2009 00:08:01 - 1.63
+++ config-x86-generic 5 Feb 2009 20:09:20 -
@@ -205,9 +205,9 @@ CONFIG_NVRAM=y
CONFIG_IBM_ASM=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_TWOFISH_586=m
-# CONFIG_CRYPTO_DEV_PADLOCK is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
+CONFIG_CRYPTO_DEV_PADLOCK=m
+CONFIG_CRYPTO_DEV_PADLOCK_AES=m
+CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_GENERIC_ISA_DMA=y
CONFIG_SCHED_SMT=y
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1263
diff -u -p -r1.1263 kernel.spec
--- kernel.spec 5 Feb 2009 18:55:52 - 1.1263
+++ kernel.spec 5 Feb 2009 20:09:20 -
@@ -241,6 +241,11 @@ Summary: The Linux kernel
%define with_kdump 0
#endif
+# We only build -PAE for 686 as of Fedora 11.
+%ifarch i686
+%define with_up 0
+%endif
+
# don't do debug builds on anything but i686 and x86_64
%ifnarch i686 x86_64
%define with_debug 0
@@ -522,8 +527,7 @@ Source24: config-rhel-generic
Source30: config-x86-generic
Source31: config-i586
-Source32: config-i686
-Source33: config-i686-PAE
+Source32: config-i686-PAE
Source40: config-x86_64-generic
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Dave Jones wrote: As per the discussion in #fedora-meeting today, we're killing off kernel-i686, and just shipping.. * kernel.i586 * kernel-PAE.686 Patch below seems to dtrt.. comments? Two quick questions Dave. 1. This is for F11? 2. Will we eventually rename kernel-PAE.686 to kernel.686? P. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
Why not %if !%{with_up} here?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:11:40PM -0500, Dave Jones wrote: As per the discussion in #fedora-meeting today, we're killing off kernel-i686, and just shipping.. * kernel.i586 * kernel-PAE.686 Patch below seems to dtrt.. comments? Looking at the generated config files, the biggest difference seems to be that kernel-PAE enables Xen and all it's related dependancies. Better version of the Makefile.config with changes Josh pointed out.. Dave Index: Makefile.config === RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v retrieving revision 1.69 diff -u -p -r1.69 Makefile.config --- Makefile.config 26 Jan 2009 07:19:13 - 1.69 +++ Makefile.config 5 Feb 2009 20:27:40 - @@ -5,9 +5,8 @@ CFG= kernel-$(VERSION) CONFIGFILES= \ - $(CFG)-i586.config \ - $(CFG)-i686.config $(CFG)-i686-PAE.config \ - $(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \ + $(CFG)-i586.config $(CFG)-i586-debug.config \ + $(CFG)-i686-PAE.config $(CFG)-i686-PAEdebug.config \ $(CFG)-x86_64.config $(CFG)-x86_64-debug.config \ $(CFG)-s390x.config $(CFG)-arm.config \ $(CFG)-ppc.config $(CFG)-ppc-smp.config \ @@ -63,12 +62,6 @@ temp-s390-generic: config-s390x temp-gen temp-ia64-generic: config-ia64-generic temp-generic perl merge.pl $^ $@ -kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic - perl merge.pl $^ i386 $@ - -kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic - perl merge.pl $^ i386 $@ - kernel-$(VERSION)-i686-PAE.config: config-i686-PAE temp-x86-generic perl merge.pl $^ i386 $@ @@ -78,6 +71,9 @@ kernel-$(VERSION)-i686-PAEdebug.config: kernel-$(VERSION)-i586.config: config-i586 temp-x86-generic perl merge.pl $^ i386 $@ +kernel-$(VERSION)-i586-debug.config: config-i586 temp-x86-debug-generic + perl merge.pl $^ i386 $@ + kernel-$(VERSION)-x86_64.config: /dev/null temp-x86_64-generic perl merge.pl $^ x86_64 $@ -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 03:22:55PM -0500, Prarit Bhargava wrote: Two quick questions Dave. 1. This is for F11? yes 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, Feb 05, 2009 at 12:23:07PM -0800, Roland McGrath wrote:
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
Why not %if !%{with_up} here?
that works too.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On Thu, 2009-02-05 at 15:11 -0500, Dave Jones wrote:
As per the discussion in #fedora-meeting today,
we're killing off kernel-i686, and just shipping..
* kernel.i586
* kernel-PAE.686
Patch below seems to dtrt.. comments?
This should prove interesting for GEM, as Intel still haven't resolved
GEM on PAE.
However I'm quite happy for this change to happen, Arjan want to try and
fix this or no GEM/KMS for F11.
Dave.
Looking at the generated config files, the biggest difference
seems to be that kernel-PAE enables Xen and all it's related
dependancies.
Dave
Index: Makefile.config
===
RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.config
--- Makefile.config 26 Jan 2009 07:19:13 - 1.69
+++ Makefile.config 5 Feb 2009 20:09:20 -
@@ -6,7 +6,7 @@ CFG = kernel-$(VERSION)
CONFIGFILES = \
$(CFG)-i586.config \
- $(CFG)-i686.config $(CFG)-i686-PAE.config \
+ $(CFG)-i686-PAE.config \
$(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \
$(CFG)-x86_64.config $(CFG)-x86_64-debug.config \
$(CFG)-s390x.config $(CFG)-arm.config \
@@ -63,9 +63,6 @@ temp-s390-generic: config-s390x temp-gen
temp-ia64-generic: config-ia64-generic temp-generic
perl merge.pl $^ $@
-kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic
- perl merge.pl $^ i386 $@
-
kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic
perl merge.pl $^ i386 $@
Index: config-i586
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-i586,v
retrieving revision 1.5
diff -u -p -r1.5 config-i586
--- config-i586 14 Feb 2008 19:56:06 - 1.5
+++ config-i586 5 Feb 2009 20:09:20 -
@@ -6,4 +6,3 @@ CONFIG_HIGHMEM4G=y
CONFIG_X86_POWERNOW_K6=m
-# CONFIG_KVM is not set
Index: config-i686
===
RCS file: config-i686
diff -N config-i686
--- config-i686 12 Jul 2007 19:15:37 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,8 +0,0 @@
-CONFIG_M686=y
-# CONFIG_NOHIGHMEM is not set
-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
-
-CONFIG_CRYPTO_DEV_PADLOCK=m
-CONFIG_CRYPTO_DEV_PADLOCK_AES=m
-CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
Index: config-x86-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86-generic,v
retrieving revision 1.63
diff -u -p -r1.63 config-x86-generic
--- config-x86-generic30 Jan 2009 00:08:01 - 1.63
+++ config-x86-generic5 Feb 2009 20:09:20 -
@@ -205,9 +205,9 @@ CONFIG_NVRAM=y
CONFIG_IBM_ASM=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_TWOFISH_586=m
-# CONFIG_CRYPTO_DEV_PADLOCK is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
-# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
+CONFIG_CRYPTO_DEV_PADLOCK=m
+CONFIG_CRYPTO_DEV_PADLOCK_AES=m
+CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_GENERIC_ISA_DMA=y
CONFIG_SCHED_SMT=y
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1263
diff -u -p -r1.1263 kernel.spec
--- kernel.spec 5 Feb 2009 18:55:52 - 1.1263
+++ kernel.spec 5 Feb 2009 20:09:20 -
@@ -241,6 +241,11 @@ Summary: The Linux kernel
%define with_kdump 0
#endif
+# We only build -PAE for 686 as of Fedora 11.
+%ifarch i686
+%define with_up 0
+%endif
+
# don't do debug builds on anything but i686 and x86_64
%ifnarch i686 x86_64
%define with_debug 0
@@ -522,8 +527,7 @@ Source24: config-rhel-generic
Source30: config-x86-generic
Source31: config-i586
-Source32: config-i686
-Source33: config-i686-PAE
+Source32: config-i686-PAE
Source40: config-x86_64-generic
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image PAEdebug
%endif
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
On 05.02.2009 21:29, Dave Jones wrote: On Thu, Feb 05, 2009 at 03:22:55PM -0500, Prarit Bhargava wrote: 2. Will we eventually rename kernel-PAE.686 to kernel.686? I don't think we can, It'd be nice to get a definite answer from the anaconda/yum crowd. otherwise someone with non-PAE 686's who does an update will suddenly find themselves unable to boot. Well, that -PAE at the things for users of RPM Fusion a lot harder, because they are used to yum install kmod-foo to get the kernel-module foo installed; in the future they have to either use kmod-foo or kmod-foo-PAE depending on what kernel they use. Sure, that's not directly a Fedora problem. But it makes things more complicated for Fedora users. Which imho not only is the wrong direction -- it's wrose for the fame of Fedora, as people don't really differentiate between Fedora and add-on repos. That's why I'd be glad if we could get rid of the -PAE... CU knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
