Re: How should anaconda check for PAE? (was Re: arch fun.)
On Wed, 25 Feb 2009 14:15:37 +0100 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. > > 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
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 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. BTW, does anyone know when Windows XP SP2/Vista uses it PAE-still-limited-to-4gb-kernel to support NX? Maybe we should use a similar scheme to avoid running into hardware issues. CU knurd ___ 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.)
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). -- 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.)
Will Woods wrote: > (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? No. > Some further questions: > - Is a PAE kernel required for proper virt support? Xen stopped supporting non-PAE (paravirt) guest kernels recently. Even before that everything ran in PAE mode because PAE was a compile time option for Xen (i.e. mixing PAE and non-PAE guests wasn't possible). So, yes, for Xen the PAE kernel is mandatory. No, the vmx bit isn't a good test, paravirtualized xen guests don't need hardware support. For kvm it doesn't matter I think. I'd say we want in any case ... (1) Install PAE kernel if there is RAM mapped above 4G. (2) Install PAE kernel if the CPU supports NX (regardless of the installed memory). I don't see the point in checking for vmx/svm. Beside that I think there is no hardware which has virtualization hardware support but hasn't nx, so the check would be superfluous anyway. We can also simply do this: - Install PAE kernel if the CPU supports PAE. i.e. make PAE the default kernel. cheers, Gerd ___ 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 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: How should anaconda check for PAE? (was Re: arch fun.)
> 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. > Syscalls in particular should be a lot faster, as you get to > use the sysenter/sysexit instructions which are faster than using > the int 80h entrypoint. (The way the segment limits work is > incompatible with sysenter/sysexit). This is indeed quite a big hit. 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, Feb 24, 2009 at 06:22:00PM -0500, Will Woods wrote: > 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. So the current rationale is 'if we have >4G of RAM, install the PAE kernel'. It does that iomem poking because the kernel used at install time isn't capable of seeing memory past 4G. So it's the best way of saying "do we have >4G?" > 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? or (PAE_flag and NX_flag) > Some further questions: > - Is a PAE kernel required for proper virt support? Xen needs it. > - Should we be using the PAE kernel *regardless* of memory size (as > implied above) or do we want some memory requirements? 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. There is a tradeoff for using larger page table entries, but it's probably still a lot cheaper than the overhead of the seglimit hack. Syscalls in particular should be a lot faster, as you get to use the sysenter/sysexit instructions which are faster than using the int 80h entrypoint. (The way the segment limits work is incompatible with sysenter/sysexit). 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: 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
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: 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 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
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 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.
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 19:11, Dave Jones wrote: 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. Correct. If you currently use kernel-686-PAE, you'll be running the _same_ thing in F11. Correct. 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. Correct. 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). 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. CU knurd ___ 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 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.
On Fri, 2009-02-06 at 13:11 -0500, Dave Jones wrote: > 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. Right, that's what I thought. Good, indeed, non-argument. > > 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) Good point there Dave. I "regret" to remind you I'm a ppc weenie. 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:11:40PM -0500, Dave Jones wrote: > 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) > On Prescott+ at least... but conveniently that was also the generation that added long mode, so why not just use that. :) (on most of them at least.) regards, Kyle ___ 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, 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 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. > > > 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. 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:42:24PM -0500, Dave Jones 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. I've done some work on this, but the crux of the issue is... x86-64 *mandates* PAE style page tables. So as time progresses, and there's less and less people using i386, then there's less and less people who give a crap. Keep in mind too, that this is only *only* an issue for distributions. Runtime PAE will be a perf loss pretty much no matter what you do compared to compile time selection. That said, it's also quite easy, but time consuming. I wish I could say I had the time to care, but I don't and the fact that i386 is as dead as a do-do doesn't help. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
The idea has been floated, but no patches ever happened afaik. I could swear nhorman said something about patches being available. I'll ping him to see what I can find out. But if there aren't patches available then I guess I'll have to see what I can do ... 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, 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.
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, 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.
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 6, 2009 at 6:38 PM, Prarit Bhargava wrote: > >> dynamic PAE ? >> > > Uh -- I can see how that is confusing :) Sorry, let me make another attempt > at that. I know what you mean by that but I have not seen any patches like that, in fact I asked about it yesterday on IRC and was told that it should be possible but no one wrote such patches yet > 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. any pointers to those patches? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: arch fun.
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. 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 6, 2009 at 6:34 PM, Prarit Bhargava 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.
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 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.
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 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.
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. Bill ___ 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: > As per the discussion in #fedora-meeting today, > we're killing off kernel-i686, and just shipping.. > > * kernel.i586 > * kernel-PAE.686 (not strictly related to the kernel, but...) What's the expectation here with respect to which kernel anaconda is going to pick for which hardware features? I ask because we have an outstanding bug where anaconda picks the wrong kernel during a Xen install (it picks kernel.i686 which doesn't have pv_ops, when it should pick kernel-PAE.i686 which does). Currently, anaconda only choose kernel-PAE for machines that both have the PAE flag, and have memory mapped > 4GB. 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? -- 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 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.
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 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
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 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, 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 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.
> 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.
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
