From kyle at infradead.org Sun Feb 1 05:43:13 2009 From: kyle at infradead.org (Kyle McMartin) Date: Sun, 1 Feb 2009 00:43:13 -0500 Subject: rpms/kernel/devel kernel.spec, 1.1254, 1.1255 linux-2.6-compile-fixes.patch, 1.188, 1.189 sata_sil-build-break-fix.patch, 1.1, NONE In-Reply-To: <20090201053631.94A357011B@cvs1.fedora.phx.redhat.com> References: <20090201053631.94A357011B@cvs1.fedora.phx.redhat.com> Message-ID: <20090201054313.GA25364@bombadil.infradead.org> On Sun, Feb 01, 2009 at 05:36:31AM +0000, Chuck Ebbert wrote: > Fold sata_sil build fix into compile-fixes.patch > Patch can be dropped, alternate fix is in -rc3-git. regards, Kyle From Axel.Thimm at ATrpms.net Sun Feb 1 09:31:10 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Feb 2009 10:31:10 +0100 Subject: Where to find old kernel-devel packages? Message-ID: <20090201093110.GA15989@teufli.physik.fu-berlin.de> Hi, there is some build regression with openafs and the latest Fedora 10 x86_64 kernel and it could be either due to the kernel or due to other changes in the build environment. Is there a way to retrieve older kernel-devel packages to test this? (Actually I think I know the answer is yes, so the question is rather "how" :) Thanks! -- Axel.Thimm at ATrpms.net From lists-fedora at wspse.de Sun Feb 1 09:44:54 2009 From: lists-fedora at wspse.de (Matthias Hensler) Date: Sun, 1 Feb 2009 10:44:54 +0100 Subject: Where to find old kernel-devel packages? In-Reply-To: <20090201093110.GA15989@teufli.physik.fu-berlin.de> References: <20090201093110.GA15989@teufli.physik.fu-berlin.de> Message-ID: <20090201094454.GA10232@kobayashi-maru.wspse.de> On Sun, Feb 01, 2009 at 10:31:10AM +0100, Axel Thimm wrote: > there is some build regression with openafs and the latest Fedora 10 > x86_64 kernel and it could be either due to the kernel or due to other > changes in the build environment. Is there a way to retrieve older > kernel-devel packages to test this? (Actually I think I know the > answer is yes, so the question is rather "how" :) As far as I see all recent (at least over 1000) kernelbuilds are available here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Regards, Matthias From Axel.Thimm at ATrpms.net Sun Feb 1 11:06:00 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Feb 2009 13:06:00 +0200 Subject: Where to find old kernel-devel packages? In-Reply-To: <20090201094454.GA10232@kobayashi-maru.wspse.de> References: <20090201093110.GA15989@teufli.physik.fu-berlin.de> <20090201094454.GA10232@kobayashi-maru.wspse.de> Message-ID: <20090201110600.GC28687@victor.nirvana> On Sun, Feb 01, 2009 at 10:44:54AM +0100, Matthias Hensler wrote: > On Sun, Feb 01, 2009 at 10:31:10AM +0100, Axel Thimm wrote: > > there is some build regression with openafs and the latest Fedora 10 > > x86_64 kernel and it could be either due to the kernel or due to other > > changes in the build environment. Is there a way to retrieve older > > kernel-devel packages to test this? (Actually I think I know the > > answer is yes, so the question is rather "how" :) > > As far as I see all recent (at least over 1000) kernelbuilds are > available here: > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Thanks! -- Axel.Thimm at ATrpms.net From cebbert at redhat.com Mon Feb 2 21:52:57 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 2 Feb 2009 16:52:57 -0500 Subject: Rawhide kernel options not enabled? Message-ID: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> I thought we were going to enable these in rawhide since the e1000 EEPROM problem was fixed: CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) CONFIG_DYNAMIC_FTRACE Also hda audio powersave is still off; we have: CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 From roland at redhat.com Mon Feb 2 22:03:00 2009 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Feb 2009 14:03:00 -0800 (PST) Subject: Rawhide kernel options not enabled? In-Reply-To: Chuck Ebbert's message of Monday, 2 February 2009 16:52:57 -0500 <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> Message-ID: <20090202220300.95470FC381@magilla.sf.frob.com> > I thought we were going to enable these in rawhide since the e1000 > EEPROM problem was fixed: > > CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) > CONFIG_DYNAMIC_FTRACE Last I knew this still uses -pg and implies -fno-omit-frame-pointer. This probably kills performance somewhat, and more importantly during a rawhide debug-kernel phase, might change the corners of compiler behavior that we're checking vs what we'd want in a production kernel. From rostedt at goodmis.org Mon Feb 2 22:34:27 2009 From: rostedt at goodmis.org (Steven Rostedt) Date: Mon, 2 Feb 2009 17:34:27 -0500 (EST) Subject: Rawhide kernel options not enabled? In-Reply-To: <20090202220300.95470FC381@magilla.sf.frob.com> References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> Message-ID: On Mon, 2 Feb 2009, Roland McGrath wrote: > > I thought we were going to enable these in rawhide since the e1000 > > EEPROM problem was fixed: > > > > CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) > > CONFIG_DYNAMIC_FTRACE > > Last I knew this still uses -pg and implies -fno-omit-frame-pointer. > This probably kills performance somewhat, and more importantly during a > rawhide debug-kernel phase, might change the corners of compiler behavior > that we're checking vs what we'd want in a production kernel. The performance hit by -fno-omit-frame-pointer depends on the which hardware you are running. I've been told by Arjan that the latest x86 hardware has negligible performance hit on this feature. But with this on, you can enable kernel function tracing at runtime. And this is a very powerful tool. This might be something to discuss, where we may sacrifice a bit of power for the ability of dynamic tracing. Benchmarks welcome ;-) -- Steve From jwboyer at gmail.com Tue Feb 3 00:55:42 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 2 Feb 2009 19:55:42 -0500 Subject: Rawhide kernel options not enabled? In-Reply-To: References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> Message-ID: <20090203005542.GA2452@yoda.jdub.homelinux.org> On Mon, Feb 02, 2009 at 05:34:27PM -0500, Steven Rostedt wrote: > >On Mon, 2 Feb 2009, Roland McGrath wrote: > >> > I thought we were going to enable these in rawhide since the e1000 >> > EEPROM problem was fixed: >> > >> > CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) >> > CONFIG_DYNAMIC_FTRACE >> >> Last I knew this still uses -pg and implies -fno-omit-frame-pointer. >> This probably kills performance somewhat, and more importantly during a >> rawhide debug-kernel phase, might change the corners of compiler behavior >> that we're checking vs what we'd want in a production kernel. > >The performance hit by -fno-omit-frame-pointer depends on the which >hardware you are running. I've been told by Arjan that the latest x86 >hardware has negligible performance hit on this feature. > >But with this on, you can enable kernel function tracing at runtime. And >this is a very powerful tool. This might be something to discuss, where we >may sacrifice a bit of power for the ability of dynamic tracing. So I'm a kernel dude. Yet I have to wonder... What good is that to a normal user? Why would they ever care about being able to enable function tracing? Are there shiny GUI tools that do it for them? Are there even release notes or wiki pages that tell them how to do it and why they need it? If it's that cool, would we ship with it enabled in stable releases? I can see the value for doing kernel debugging. Telling a user "do X and give me the output of Y" could help kernel developers, but the normal user just isn't going to care. josh From rostedt at goodmis.org Tue Feb 3 01:11:06 2009 From: rostedt at goodmis.org (Steven Rostedt) Date: Mon, 2 Feb 2009 20:11:06 -0500 (EST) Subject: Rawhide kernel options not enabled? In-Reply-To: <20090203005542.GA2452@yoda.jdub.homelinux.org> References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090203005542.GA2452@yoda.jdub.homelinux.org> Message-ID: On Mon, 2 Feb 2009, Josh Boyer wrote: > On Mon, Feb 02, 2009 at 05:34:27PM -0500, Steven Rostedt wrote: > > > >On Mon, 2 Feb 2009, Roland McGrath wrote: > > > >> > I thought we were going to enable these in rawhide since the e1000 > >> > EEPROM problem was fixed: > >> > > >> > CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) > >> > CONFIG_DYNAMIC_FTRACE > >> > >> Last I knew this still uses -pg and implies -fno-omit-frame-pointer. > >> This probably kills performance somewhat, and more importantly during a > >> rawhide debug-kernel phase, might change the corners of compiler behavior > >> that we're checking vs what we'd want in a production kernel. > > > >The performance hit by -fno-omit-frame-pointer depends on the which > >hardware you are running. I've been told by Arjan that the latest x86 > >hardware has negligible performance hit on this feature. > > > >But with this on, you can enable kernel function tracing at runtime. And > >this is a very powerful tool. This might be something to discuss, where we > >may sacrifice a bit of power for the ability of dynamic tracing. > > So I'm a kernel dude. Yet I have to wonder... > > What good is that to a normal user? > Why would they ever care about being able to enable function tracing? > Are there shiny GUI tools that do it for them? Soon, but not yet ;-) > Are there even release notes or wiki pages that tell them how to do it > and why they need it? I can write those up. Currently they just exist in Documentation/ftrace.txt > If it's that cool, would we ship with it enabled in stable releases? I would expect so. > > I can see the value for doing kernel debugging. Telling a user "do X and > give me the output of Y" could help kernel developers, but the normal user > just isn't going to care. Do not put down that debugging ability just yet. Would it not be nice to just tell a user to run a script you send him (the script would do all the command line commands) and then the user could send you back the result. The user would not need to reboot or compile another kernel. You would be able to turn on or off anything function trace you would like. Newer features coming out in 29 that are ever cooler ;-) Like the function graph tracer that gives you this output: # echo sys_open > /debug/tracing/set_graph_function # echo function_graph > /debug/tracing/current_tracer # cat /debug/tracing/trace # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) | sys_open() { 1) | do_sys_open() { 1) | getname() { 1) 3.440 us | kmem_cache_alloc(); 1) | strncpy_from_user() { 1) | __strncpy_from_user() { 1) 3.060 us | might_fault(); 1) 6.845 us | } 1) + 10.508 us | } 1) + 20.774 us | } 1) | alloc_fd() { 1) | _spin_lock() { 1) 1.708 us | get_parent_ip(); 1) 6.833 us | } 1) 2.032 us | expand_files(); 1) | _spin_unlock() { 1) 2.024 us | get_parent_ip(); 1) 7.253 us | } 1) + 24.504 us | } 1) | do_filp_open() { 1) | path_lookup_open() { 1) | get_empty_filp() { 1) 2.728 us | kmem_cache_alloc(); 1) 1.834 us | get_parent_ip(); 1) 1.914 us | get_parent_ip(); 1) | security_file_alloc() { 1) 2.284 us | cap_file_alloc_security(); 1) 6.130 us | } 1) + 24.922 us | } 1) | do_path_lookup() { 1) | _read_lock() { 1) 1.776 us | get_parent_ip(); 1) 7.278 us | } 1) 2.652 us | path_get(); 1) | _read_unlock() { 1) 2.034 us | get_parent_ip(); 1) 6.407 us | } 1) | path_walk() { [...] -- Steve From rostedt at goodmis.org Tue Feb 3 01:20:34 2009 From: rostedt at goodmis.org (Steven Rostedt) Date: Mon, 2 Feb 2009 20:20:34 -0500 (EST) Subject: Rawhide kernel options not enabled? In-Reply-To: References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090203005542.GA2452@yoda.jdub.homelinux.org> Message-ID: On Mon, 2 Feb 2009, Steven Rostedt wrote: > > Do not put down that debugging ability just yet. Would it not be nice to > just tell a user to run a script you send him (the script would do all > the command line commands) and then the user could send you back the > result. The user would not need to reboot or compile another kernel. You > would be able to turn on or off anything function trace you would like. Also note, if your user has access to serial consoles, and many enterprise users do, then you could also trace an oops. By setting "ftrace_dump_on_oops" in the kernel command line, and have them enable function tracing before they do whatever they do to cause the oops. The ftrace dump output will dump to the console. If they have serial, then it will dump to their serial console where they can record the crash. This information can be very handy for us to analyze and find the cause on an oops. -- Steve From jwboyer at gmail.com Tue Feb 3 12:29:24 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 07:29:24 -0500 Subject: Rawhide kernel options not enabled? In-Reply-To: References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090203005542.GA2452@yoda.jdub.homelinux.org> Message-ID: <20090203122924.GA2296@yoda.jdub.homelinux.org> On Mon, Feb 02, 2009 at 08:20:34PM -0500, Steven Rostedt wrote: > > >On Mon, 2 Feb 2009, Steven Rostedt wrote: >> >> Do not put down that debugging ability just yet. Would it not be nice to >> just tell a user to run a script you send him (the script would do all >> the command line commands) and then the user could send you back the >> result. The user would not need to reboot or compile another kernel. You >> would be able to turn on or off anything function trace you would like. > >Also note, if your user has access to serial consoles, and many enterprise >users do, then you could also trace an oops. By setting Because many enterprise users are using Fedora... ;) >"ftrace_dump_on_oops" in the kernel command line, and have them enable >function tracing before they do whatever they do to cause the oops. The >ftrace dump output will dump to the console. If they have serial, then it >will dump to their serial console where they can record the crash. This >information can be very handy for us to analyze and find the cause on an >oops. Sounds neat. Sadly, lots of common hardware these days lacks serial ports. Will it do the same to a monitor if those options are enabled? josh From jonathan at jonmasters.org Wed Feb 4 08:58:26 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 04 Feb 2009 03:58:26 -0500 Subject: [Fwd: module-init-tools v3.6 released] Message-ID: <1233737906.5280.59.camel@perihelion.bos.jonmasters.org> Head's up that we're going to be playing with config files for modprobe. The idea is to have just one upstream config file, and for some things that make sense to get fixed in the upstream kernel tree rather than in every distro. So if someone has a billion year old tape drive that had a hack for loading some ioctl module or whatever, and we break it, and there's a BZ involved that smells like modprobe, sent it my way please :) Jon. -------------- next part -------------- An embedded message was scrubbed... From: Jon Masters Subject: module-init-tools v3.6 released Date: Wed, 04 Feb 2009 03:47:47 -0500 Size: 1143 URL: From roland at redhat.com Wed Feb 4 23:50:52 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 4 Feb 2009 15:50:52 -0800 (PST) Subject: Rawhide kernel options not enabled? In-Reply-To: Steven Rostedt's message of Monday, 2 February 2009 17:34:27 -0500 References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> Message-ID: <20090204235052.9FD49FC381@magilla.sf.frob.com> > But with this on, you can enable kernel function tracing at runtime. And > this is a very powerful tool. This might be something to discuss, where we > may sacrifice a bit of power for the ability of dynamic tracing. Or you could take my advice of many moons ago now and find less cockamamy ways to implement this. ;-) From rostedt at goodmis.org Thu Feb 5 00:02:00 2009 From: rostedt at goodmis.org (Steven Rostedt) Date: Wed, 4 Feb 2009 19:02:00 -0500 (EST) Subject: Rawhide kernel options not enabled? In-Reply-To: <20090204235052.9FD49FC381@magilla.sf.frob.com> References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090204235052.9FD49FC381@magilla.sf.frob.com> Message-ID: On Wed, 4 Feb 2009, Roland McGrath wrote: > > But with this on, you can enable kernel function tracing at runtime. And > > this is a very powerful tool. This might be something to discuss, where we > > may sacrifice a bit of power for the ability of dynamic tracing. > > Or you could take my advice of many moons ago now and find less cockamamy > ways to implement this. ;-) By what? Rewriting gcc? -- Steve From jcm at redhat.com Thu Feb 5 00:13:23 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 04 Feb 2009 19:13:23 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> Message-ID: <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: > On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: > > > I'm considering pushing an update to F-9 since v3.5+ is so much faster > > than previous releases - and it impacts boot time, but I have to admit > > that I was more concerned about F10 and rawhide until now. > > Oh, there's a slight issue with the handling of modules.order still for > the binary tries in newer module-init-tools. This might manifest in a > switch of e.g. module used in initrd for storage devices with multiple > modaliases. So...one question... We now have binary versions of files like "modules.dep", "modules.alias" and "modules.symbols". These end in ".bin" and *augment* but do not replace the textual versions of these files. If we find the binary files, we are *much* faster at loading modules - boot overhead is e.g. under one second. But we need to be able to make changes to these binary files in order to add ordering support, and also just for the future. Our plan is to freeze the old text file format (the "last" change will be the one made recently in which modules.dep can now have relative paths to save space) and to fallback to it whenever the binary format changes and modprobe finds older binary files. This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be "slow" booting before depmod has been re-run again. I'm thinking about just doing a "depmod -a" on upgrade in such cases in the future...is there a problem with that idea? Jon. From roland at redhat.com Thu Feb 5 00:14:42 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 4 Feb 2009 16:14:42 -0800 (PST) Subject: Rawhide kernel options not enabled? In-Reply-To: Steven Rostedt's message of Wednesday, 4 February 2009 19:02:00 -0500 References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090204235052.9FD49FC381@magilla.sf.frob.com> Message-ID: <20090205001442.B675BFC381@magilla.sf.frob.com> > > Or you could take my advice of many moons ago now and find less cockamamy > > ways to implement this. ;-) > > By what? Rewriting gcc? Only a wee little bit. ;-) Seriously, -pg is eight kinds of wrong, and not even what you really want anyway. (If your probe points are at actual entry points instead of inside prologues, then you can get the function arguments directly, assuming you know which calling convention that particular function has, which you don't really but you'd probably be happy pretending you did.) You do not really need any kind of magical list of spots generated at compile time. You can just do insertion anywhere it works. (If you're willing to fall back to kprobes, it works most anywhere.) You can keep it real primitive like now and just only work where there is exactly NOP5 sitting there. Then all you're really asking for at build time is to insert a gratuitous NOP5 at entry points. A compiler tweak for that is a pretty simple kludge, not even tied in to actual code generation magic. You could probably even do it with crazy-ass asm/.o fiddling as is your wont. Thanks, Roland From jcm at redhat.com Thu Feb 5 11:49:56 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 05 Feb 2009 06:49:56 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <498AC5E0.9030607@redhat.com> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> <498AC5E0.9030607@redhat.com> Message-ID: <1233834596.4166.171.camel@perihelion.bos.jonmasters.org> On Thu, 2009-02-05 at 11:56 +0100, Phil Knirsch wrote: > Jon Masters wrote: > > This works fine, but means that, if we upgrade module-init-tools and > > there is a binary format change, then the system will be "slow" booting > > before depmod has been re-run again. I'm thinking about just doing a > > "depmod -a" on upgrade in such cases in the future...is there a problem > > with that idea? > Imho in case of an update of module-init-tools that sounds absolutely > reasonable. Users are much more likely to reboot their machines then get > updates for module-init-tools, so the little overhead introduced with > running depmod -a during an update should in general be significantly > lower than the gains in subsequent bootups. Interestingly, I was expecting a lot more "oh nos! Don't do that because it breaks some weirdly random preconceived notion" but for once, nothing. Cool. Jon. From notting at redhat.com Thu Feb 5 14:52:19 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Feb 2009 09:52:19 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> Message-ID: <20090205145218.GA6865@nostromo.devel.redhat.com> Jon Masters (jcm at redhat.com) said: > This works fine, but means that, if we upgrade module-init-tools and > there is a binary format change, then the system will be "slow" booting > before depmod has been re-run again. I'm thinking about just doing a > "depmod -a" on upgrade in such cases in the future...is there a problem > with that idea? Given the (presumable) infreqeuency of file format updates, especially compared to kernel updates, I wouldn't necessarily bother with it. Bill From jcm at redhat.com Thu Feb 5 14:58:41 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 05 Feb 2009 09:58:41 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <20090205145218.GA6865@nostromo.devel.redhat.com> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> <20090205145218.GA6865@nostromo.devel.redhat.com> Message-ID: <1233845921.2204.7.camel@perihelion.bos.jonmasters.org> On Thu, 2009-02-05 at 09:52 -0500, Bill Nottingham wrote: > Jon Masters (jcm at redhat.com) said: > > This works fine, but means that, if we upgrade module-init-tools and > > there is a binary format change, then the system will be "slow" booting > > before depmod has been re-run again. I'm thinking about just doing a > > "depmod -a" on upgrade in such cases in the future...is there a problem > > with that idea? > > Given the (presumable) infreqeuency of file format updates, especially > compared to kernel updates, I wouldn't necessarily bother with it. Neither would I, but the difference in "boot" time is fairly dramatic and people might whine ;) Jon. From pknirsch at redhat.com Thu Feb 5 10:56:32 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 05 Feb 2009 11:56:32 +0100 Subject: module-init-tools v3.6 released In-Reply-To: <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> Message-ID: <498AC5E0.9030607@redhat.com> Jon Masters wrote: > On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: >> On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: >> >>> I'm considering pushing an update to F-9 since v3.5+ is so much faster >>> than previous releases - and it impacts boot time, but I have to admit >>> that I was more concerned about F10 and rawhide until now. >> Oh, there's a slight issue with the handling of modules.order still for >> the binary tries in newer module-init-tools. This might manifest in a >> switch of e.g. module used in initrd for storage devices with multiple >> modaliases. > > So...one question... > > We now have binary versions of files like "modules.dep", "modules.alias" > and "modules.symbols". These end in ".bin" and *augment* but do not > replace the textual versions of these files. If we find the binary > files, we are *much* faster at loading modules - boot overhead is e.g. > under one second. > > But we need to be able to make changes to these binary files in order to > add ordering support, and also just for the future. Our plan is to > freeze the old text file format (the "last" change will be the one made > recently in which modules.dep can now have relative paths to save space) > and to fallback to it whenever the binary format changes and modprobe > finds older binary files. > > This works fine, but means that, if we upgrade module-init-tools and > there is a binary format change, then the system will be "slow" booting > before depmod has been re-run again. I'm thinking about just doing a > "depmod -a" on upgrade in such cases in the future...is there a problem > with that idea? > > Jon. > Imho in case of an update of module-init-tools that sounds absolutely reasonable. Users are much more likely to reboot their machines then get updates for module-init-tools, so the little overhead introduced with running depmod -a during an update should in general be significantly lower than the gains in subsequent bootups. Jusy my $0.02. Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From davej at redhat.com Thu Feb 5 20:11:40 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 5 Feb 2009 15:11:40 -0500 Subject: arch fun. Message-ID: <20090205201140.GA21993@redhat.com> 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 -0000 1.69 +++ Makefile.config 5 Feb 2009 20:09:20 -0000 @@ -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 -0000 1.5 +++ config-i586 5 Feb 2009 20:09:20 -0000 @@ -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 -0000 1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -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 -0000 1.63 +++ config-x86-generic 5 Feb 2009 20:09:20 -0000 @@ -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 -0000 1.1263 +++ kernel.spec 5 Feb 2009 20:09:20 -0000 @@ -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 From prarit at redhat.com Thu Feb 5 20:22:55 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 05 Feb 2009 15:22:55 -0500 Subject: arch fun. In-Reply-To: <20090205201140.GA21993@redhat.com> References: <20090205201140.GA21993@redhat.com> Message-ID: <498B4A9F.9060101@redhat.com> 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. From roland at redhat.com Thu Feb 5 20:23:07 2009 From: roland at redhat.com (Roland McGrath) Date: Thu, 5 Feb 2009 12:23:07 -0800 (PST) Subject: arch fun. In-Reply-To: Dave Jones's message of Thursday, 5 February 2009 15:11:40 -0500 <20090205201140.GA21993@redhat.com> References: <20090205201140.GA21993@redhat.com> Message-ID: <20090205202307.93A29FC381@magilla.sf.frob.com> > 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? From davej at redhat.com Thu Feb 5 20:28:34 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 5 Feb 2009 15:28:34 -0500 Subject: arch fun. In-Reply-To: <20090205201140.GA21993@redhat.com> References: <20090205201140.GA21993@redhat.com> Message-ID: <20090205202834.GA24263@redhat.com> 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 -0000 1.69 +++ Makefile.config 5 Feb 2009 20:27:40 -0000 @@ -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 From davej at redhat.com Thu Feb 5 20:29:51 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 5 Feb 2009 15:29:51 -0500 Subject: arch fun. In-Reply-To: <498B4A9F.9060101@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> Message-ID: <20090205202951.GA5400@redhat.com> 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 From davej at redhat.com Thu Feb 5 20:37:21 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 5 Feb 2009 15:37:21 -0500 Subject: arch fun. In-Reply-To: <20090205202307.93A29FC381@magilla.sf.frob.com> References: <20090205201140.GA21993@redhat.com> <20090205202307.93A29FC381@magilla.sf.frob.com> Message-ID: <20090205203721.GB5400@redhat.com> 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 From airlied at redhat.com Thu Feb 5 20:57:21 2009 From: airlied at redhat.com (Dave Airlie) Date: Fri, 06 Feb 2009 06:57:21 +1000 Subject: arch fun. In-Reply-To: <20090205201140.GA21993@redhat.com> References: <20090205201140.GA21993@redhat.com> Message-ID: <1233867441.2207.0.camel@optimus> 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 -0000 1.69 > +++ Makefile.config 5 Feb 2009 20:09:20 -0000 > @@ -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 -0000 1.5 > +++ config-i586 5 Feb 2009 20:09:20 -0000 > @@ -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 -0000 1.1 > +++ /dev/null 1 Jan 1970 00:00:00 -0000 > @@ -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 -0000 1.63 > +++ config-x86-generic 5 Feb 2009 20:09:20 -0000 > @@ -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 -0000 1.1263 > +++ kernel.spec 5 Feb 2009 20:09:20 -0000 > @@ -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 From rostedt at goodmis.org Thu Feb 5 23:27:09 2009 From: rostedt at goodmis.org (Steven Rostedt) Date: Thu, 5 Feb 2009 18:27:09 -0500 (EST) Subject: Rawhide kernel options not enabled? In-Reply-To: <20090205001442.B675BFC381@magilla.sf.frob.com> References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> <20090204235052.9FD49FC381@magilla.sf.frob.com> <20090205001442.B675BFC381@magilla.sf.frob.com> Message-ID: On Wed, 4 Feb 2009, Roland McGrath wrote: > > > Or you could take my advice of many moons ago now and find less cockamamy > > > ways to implement this. ;-) > > > > By what? Rewriting gcc? > > Only a wee little bit. ;-) Seriously, -pg is eight kinds of wrong, and not > even what you really want anyway. (If your probe points are at actual > entry points instead of inside prologues, then you can get the function > arguments directly, assuming you know which calling convention that > particular function has, which you don't really but you'd probably be happy > pretending you did.) kprobes are quite expensive on the tracer to trace every function. > > You do not really need any kind of magical list of spots generated at > compile time. You can just do insertion anywhere it works. (If you're > willing to fall back to kprobes, it works most anywhere.) You can keep it > real primitive like now and just only work where there is exactly NOP5 > sitting there. Then all you're really asking for at build time is to > insert a gratuitous NOP5 at entry points. A compiler tweak for that is a > pretty simple kludge, not even tied in to actual code generation magic. > You could probably even do it with crazy-ass asm/.o fiddling as is your wont. Hacking gcc is not an option. What? Are we to wait till this hack in gcc comes out to be able to do this. Not to mention, dynamic ftrace runs on x86, powerpc, arm, and I think even superH. With more archs probably to come. Each has their own crap to deal with. The gcc for each arch will need to handle the jumps needed for modules, which on other archs is no easy task. -- Steve From fche at redhat.com Thu Feb 5 23:03:45 2009 From: fche at redhat.com (Frank Ch. Eigler) Date: Thu, 05 Feb 2009 18:03:45 -0500 Subject: Rawhide kernel options not enabled? In-Reply-To: (Steven Rostedt's message of "Mon, 2 Feb 2009 17:34:27 -0500 (EST)") References: <20090202165257.60e8fee1@dhcp-100-2-144.bos.redhat.com> <20090202220300.95470FC381@magilla.sf.frob.com> Message-ID: Steven Rostedt writes: > [...] > But with this on, you can enable kernel function tracing at runtime. And > this is a very powerful tool. This might be something to discuss, where we > may sacrifice a bit of power for the ability of dynamic tracing. Right, but ... > Benchmarks welcome ;-) Who should shoulder that burden of proof? - FChE From fedora at leemhuis.info Fri Feb 6 05:37:01 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Feb 2009 06:37:01 +0100 Subject: arch fun. In-Reply-To: <20090205202951.GA5400@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> Message-ID: <498BCC7D.2060509@leemhuis.info> 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 From prarit at redhat.com Fri Feb 6 11:07:13 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 06 Feb 2009 06:07:13 -0500 Subject: arch fun. In-Reply-To: <20090205202951.GA5400@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> Message-ID: <498C19E1.4040900@redhat.com> 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. From fedora at leemhuis.info Fri Feb 6 11:20:03 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Feb 2009 12:20:03 +0100 Subject: arch fun. In-Reply-To: <498C19E1.4040900@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> Message-ID: <498C1CE3.9010509@leemhuis.info> 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 From clalance at redhat.com Fri Feb 6 12:57:49 2009 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 06 Feb 2009 13:57:49 +0100 Subject: arch fun. In-Reply-To: <20090205201140.GA21993@redhat.com> References: <20090205201140.GA21993@redhat.com> Message-ID: <498C33CD.2050009@redhat.com> 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 From drago01 at gmail.com Fri Feb 6 15:03:29 2009 From: drago01 at gmail.com (drago01) Date: Fri, 6 Feb 2009 16:03:29 +0100 Subject: [RFC] disable OSS sound support Message-ID: Currently we have: CONFIG_SOUND_OSS_CORE=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y this cause the OSS compat modules to be loaded on every system (that has sound), even thought most people do not require this (pure oss apps aren't used that often). If its really needed we have aoss and padsp to run such apps for people that really needs them, without having this modules loaded on every system running fedora. Besides apps that just open /dev/dsp are unlikely to "just work" in a default setup due to pulseaudio. So my proposal is: Disable this options in rawhide (and those F11) and add a note to the release notes that people can use padsp/aoss to make oss apps working. From hdegoede at redhat.com Fri Feb 6 15:11:10 2009 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 06 Feb 2009 16:11:10 +0100 Subject: [RFC] disable OSS sound support In-Reply-To: References: Message-ID: <498C530E.4070106@redhat.com> drago01 wrote: > Currently we have: > > CONFIG_SOUND_OSS_CORE=y > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_PCM_OSS_PLUGINS=y > CONFIG_SND_SEQUENCER_OSS=y > > this cause the OSS compat modules to be loaded on every system (that > has sound), even thought most people do not require this (pure oss > apps aren't used that often). > If its really needed we have aoss and padsp to run such apps for > people that really needs them, without having this modules loaded on > every system running fedora. > > Besides apps that just open /dev/dsp are unlikely to "just work" in a > default setup due to pulseaudio. > > So my proposal is: Disable this options in rawhide (and those F11) and > add a note to the release notes that people can use padsp/aoss to make > oss apps working. > I like it, +1, but others might disagree, I'm sure someone can dig up some old app which still needs it :) But that is going to be the exception to the rule that oss support is no longer needed. Regards, Hans From notting at redhat.com Fri Feb 6 15:19:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 Feb 2009 10:19:17 -0500 Subject: arch fun. In-Reply-To: <498C1CE3.9010509@leemhuis.info> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <498C1CE3.9010509@leemhuis.info> Message-ID: <20090206151917.GB10018@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at 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 From notting at redhat.com Fri Feb 6 15:19:51 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 Feb 2009 10:19:51 -0500 Subject: arch fun. In-Reply-To: <498C33CD.2050009@redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> Message-ID: <20090206151951.GC10018@nostromo.devel.redhat.com> Chris Lalancette (clalance at 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 From davej at redhat.com Fri Feb 6 16:39:07 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 11:39:07 -0500 Subject: arch fun. In-Reply-To: <498C19E1.4040900@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> Message-ID: <20090206163907.GA3253@redhat.com> 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 From jcm at redhat.com Fri Feb 6 17:23:51 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 12:23:51 -0500 Subject: arch fun. In-Reply-To: <20090206163907.GA3253@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> Message-ID: <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> 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. From davej at redhat.com Fri Feb 6 17:29:59 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 12:29:59 -0500 Subject: arch fun. In-Reply-To: <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> Message-ID: <20090206172959.GB17983@redhat.com> 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 From prarit at redhat.com Fri Feb 6 17:34:04 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 06 Feb 2009 12:34:04 -0500 Subject: arch fun. In-Reply-To: <20090206172959.GB17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> Message-ID: <498C748C.1080601@redhat.com> > 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 > > From drago01 at gmail.com Fri Feb 6 17:36:24 2009 From: drago01 at gmail.com (drago01) Date: Fri, 6 Feb 2009 18:36:24 +0100 Subject: arch fun. In-Reply-To: <498C748C.1080601@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> Message-ID: 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 ? From prarit at redhat.com Fri Feb 6 17:38:56 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 06 Feb 2009 12:38:56 -0500 Subject: arch fun. In-Reply-To: References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> Message-ID: <498C75B0.2050401@redhat.com> > 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. From drago01 at gmail.com Fri Feb 6 17:41:25 2009 From: drago01 at gmail.com (drago01) Date: Fri, 6 Feb 2009 18:41:25 +0100 Subject: arch fun. In-Reply-To: <498C75B0.2050401@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> <498C75B0.2050401@redhat.com> Message-ID: 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? From davej at redhat.com Fri Feb 6 17:42:24 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 12:42:24 -0500 Subject: arch fun. In-Reply-To: <498C748C.1080601@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> Message-ID: <20090206174224.GC17983@redhat.com> 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 From davej at redhat.com Fri Feb 6 17:42:51 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 12:42:51 -0500 Subject: arch fun. In-Reply-To: <498C75B0.2050401@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> <498C75B0.2050401@redhat.com> Message-ID: <20090206174251.GD17983@redhat.com> 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 From prarit at redhat.com Fri Feb 6 17:43:03 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 06 Feb 2009 12:43:03 -0500 Subject: arch fun. In-Reply-To: <20090206174224.GC17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> <20090206174224.GC17983@redhat.com> Message-ID: <498C76A7.9010300@redhat.com> 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. From jcm at redhat.com Fri Feb 6 17:44:28 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 12:44:28 -0500 Subject: arch fun. In-Reply-To: <20090206172959.GB17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> Message-ID: <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> 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. From prarit at redhat.com Fri Feb 6 17:44:41 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 06 Feb 2009 12:44:41 -0500 Subject: arch fun. In-Reply-To: <20090206174251.GD17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> <498C75B0.2050401@redhat.com> <20090206174251.GD17983@redhat.com> Message-ID: <498C7709.4010103@redhat.com> > > 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 > > From kyle at infradead.org Fri Feb 6 17:56:32 2009 From: kyle at infradead.org (Kyle McMartin) Date: Fri, 6 Feb 2009 12:56:32 -0500 Subject: arch fun. In-Reply-To: <20090206174224.GC17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <498C748C.1080601@redhat.com> <20090206174224.GC17983@redhat.com> Message-ID: <20090206175632.GA9743@bombadil.infradead.org> 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 From davej at redhat.com Fri Feb 6 17:58:06 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 12:58:06 -0500 Subject: arch fun. In-Reply-To: <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> Message-ID: <20090206175806.GE17983@redhat.com> 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 From mw_triad at users.sourceforge.net Fri Feb 6 17:53:12 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 06 Feb 2009 11:53:12 -0600 Subject: [RFC] disable OSS sound support In-Reply-To: <498C530E.4070106@redhat.com> References: <498C530E.4070106@redhat.com> Message-ID: Hans de Goede wrote: > I like it, +1, but others might disagree, I'm sure someone can dig up > some old app which still needs it :) But that is going to be the > exception to the rule that oss support is no longer needed. 'cat /dev/urandom > /dev/dsp' ;-) (which I also use as a cheap test if my sound is working). Out of curiosity, what's the overhead of /just/ /dev/dsp support? If it's low enough, it might be nice to keep just that, but it's not necessarily worth blocking removal. (Will /dev/dsp not exist when padsp isn't running?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "Let's call it an accidental feature." -- Larry Wall From jcm at redhat.com Fri Feb 6 18:01:43 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 13:01:43 -0500 Subject: arch fun. In-Reply-To: <20090206175806.GE17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> Message-ID: <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> 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. From davej at redhat.com Fri Feb 6 18:11:40 2009 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Feb 2009 13:11:40 -0500 Subject: arch fun. In-Reply-To: <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> Message-ID: <20090206181140.GF17983@redhat.com> 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 From kyle at infradead.org Fri Feb 6 18:14:54 2009 From: kyle at infradead.org (Kyle McMartin) Date: Fri, 6 Feb 2009 13:14:54 -0500 Subject: arch fun. In-Reply-To: <20090206181140.GF17983@redhat.com> References: <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> Message-ID: <20090206181454.GB9743@bombadil.infradead.org> 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 From jcm at redhat.com Fri Feb 6 18:23:49 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 13:23:49 -0500 Subject: arch fun. In-Reply-To: <20090206181140.GF17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> Message-ID: <1233944629.3936.34.camel@perihelion.bos.jonmasters.org> 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. From cra at WPI.EDU Fri Feb 6 18:41:41 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 6 Feb 2009 13:41:41 -0500 Subject: arch fun. In-Reply-To: <20090206151917.GB10018@nostromo.devel.redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <498C1CE3.9010509@leemhuis.info> <20090206151917.GB10018@nostromo.devel.redhat.com> Message-ID: <20090206184141.GO19984@angus.ind.WPI.EDU> On Fri, Feb 06, 2009 at 10:19:17AM -0500, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at 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. From bnocera at redhat.com Fri Feb 6 18:44:46 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 06 Feb 2009 18:44:46 +0000 Subject: [RFC] disable OSS sound support In-Reply-To: References: Message-ID: <1233945886.8950.14.camel@cookie.hadess.net> On Fri, 2009-02-06 at 16:03 +0100, drago01 wrote: > Currently we have: > > CONFIG_SOUND_OSS_CORE=y > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_PCM_OSS_PLUGINS=y > CONFIG_SND_SEQUENCER_OSS=y > > this cause the OSS compat modules to be loaded on every system (that > has sound), even thought most people do not require this (pure oss > apps aren't used that often). See also: https://bugzilla.redhat.com/show_bug.cgi?id=472741 And the related discussion on this list ("F11: OSS and pulseaudio conflict" in November). > If its really needed we have aoss and padsp to run such apps for > people that really needs them, without having this modules loaded on > every system running fedora. > > Besides apps that just open /dev/dsp are unlikely to "just work" in a > default setup due to pulseaudio. > > So my proposal is: Disable this options in rawhide (and those F11) and > add a note to the release notes that people can use padsp/aoss to make > oss apps working. Completely agree. From clalance at redhat.com Fri Feb 6 18:48:41 2009 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 06 Feb 2009 19:48:41 +0100 Subject: arch fun. In-Reply-To: <20090206151951.GC10018@nostromo.devel.redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> Message-ID: <498C8609.8000703@redhat.com> Bill Nottingham wrote: > Chris Lalancette (clalance at 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 From fedora at leemhuis.info Fri Feb 6 19:47:41 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Feb 2009 20:47:41 +0100 Subject: arch fun. In-Reply-To: <20090206181140.GF17983@redhat.com> References: <20090205201140.GA21993@redhat.com> <498B4A9F.9060101@redhat.com> <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> Message-ID: <498C93DD.3000006@leemhuis.info> 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 From kyle at infradead.org Fri Feb 6 19:55:43 2009 From: kyle at infradead.org (Kyle McMartin) Date: Fri, 6 Feb 2009 14:55:43 -0500 Subject: arch fun. In-Reply-To: <498C93DD.3000006@leemhuis.info> References: <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> <498C93DD.3000006@leemhuis.info> Message-ID: <20090206195543.GC9743@bombadil.infradead.org> 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. From fedora at leemhuis.info Fri Feb 6 20:08:58 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Feb 2009 21:08:58 +0100 Subject: arch fun. In-Reply-To: <20090206195543.GC9743@bombadil.infradead.org> References: <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> <498C93DD.3000006@leemhuis.info> <20090206195543.GC9743@bombadil.infradead.org> Message-ID: <498C98DA.6050807@leemhuis.info> 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 From notting at redhat.com Fri Feb 6 20:11:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 Feb 2009 15:11:37 -0500 Subject: arch fun. Message-ID: <20090206201136.GD6150@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at 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 From kyle at infradead.org Fri Feb 6 20:13:17 2009 From: kyle at infradead.org (Kyle McMartin) Date: Fri, 6 Feb 2009 15:13:17 -0500 Subject: arch fun. In-Reply-To: <20090206201136.GD6150@nostromo.devel.redhat.com> References: <20090206201136.GD6150@nostromo.devel.redhat.com> Message-ID: <20090206201317.GD9743@bombadil.infradead.org> On Fri, Feb 06, 2009 at 03:11:37PM -0500, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at 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? From jcm at redhat.com Fri Feb 6 22:28:47 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 17:28:47 -0500 Subject: [RFC] disable OSS sound support In-Reply-To: <1233945886.8950.14.camel@cookie.hadess.net> References: <1233945886.8950.14.camel@cookie.hadess.net> Message-ID: <1233959327.3936.58.camel@perihelion.bos.jonmasters.org> On Fri, 2009-02-06 at 18:44 +0000, Bastien Nocera wrote: > > So my proposal is: Disable this options in rawhide (and those F11) and > > add a note to the release notes that people can use padsp/aoss to make > > oss apps working. > > Completely agree. As I pointed out on IRC, it's just a modprobe rule loading these OSS modules, so removing them from the kernel is a heavyweight solution to your problem. You could trivially add a rule to remove them or change the existing ones. Jon. From jcm at redhat.com Fri Feb 6 22:40:21 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 06 Feb 2009 17:40:21 -0500 Subject: arch fun. In-Reply-To: <498C98DA.6050807@leemhuis.info> References: <20090205202951.GA5400@redhat.com> <498C19E1.4040900@redhat.com> <20090206163907.GA3253@redhat.com> <1233941031.3936.15.camel@perihelion.bos.jonmasters.org> <20090206172959.GB17983@redhat.com> <1233942268.3936.21.camel@perihelion.bos.jonmasters.org> <20090206175806.GE17983@redhat.com> <1233943303.3936.25.camel@perihelion.bos.jonmasters.org> <20090206181140.GF17983@redhat.com> <498C93DD.3000006@leemhuis.info> <20090206195543.GC9743@bombadil.infradead.org> <498C98DA.6050807@leemhuis.info> Message-ID: <1233960021.3936.63.camel@perihelion.bos.jonmasters.org> 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. From kyle at infradead.org Mon Feb 9 03:18:14 2009 From: kyle at infradead.org (Kyle McMartin) Date: Sun, 8 Feb 2009 22:18:14 -0500 Subject: [PATCH] drm: disable gem on i8xx Message-ID: <20090209031814.GA13529@bombadil.infradead.org> In an IRC conversation, you mentioned that GEM was not to be used on 8xx yet... But there didn't seem to be anything explicitly disabling this. Add code to turn off GEM on i8xx series chips. This didn't turn out to be the problem with X on my i830, but at least it kills the lockdep warning. Should this go upstream as well? Signed-off-by: Kyle McMartin --- diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index cc0adb4..9303063 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1108,8 +1108,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) /* don't enable GEM on PAE - needs agp + set_memory_* interface fixes */ dev_priv->has_gem = 0; #else - /* enable GEM by default */ - dev_priv->has_gem = 1; + /* enable GEM by default, except on I8xx */ + dev_priv->has_gem = !IS_I8XX(dev) ? 1 : 0; #endif i915_gem_load(dev); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a70bf77..84664fe 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -750,6 +750,9 @@ extern int i915_wait_ring(struct drm_device * dev, int n, const char *caller); #define IS_I855(dev) ((dev)->pci_device == 0x3582) #define IS_I865G(dev) ((dev)->pci_device == 0x2572) +#define IS_I8XX(dev) (IS_I830(dev) || IS_845G(dev) || IS_I85X(dev) || \ + IS_I855(dev) || IS_I865G(dev)) + #define IS_I915G(dev) ((dev)->pci_device == 0x2582 || (dev)->pci_device == 0x258a) #define IS_I915GM(dev) ((dev)->pci_device == 0x2592) #define IS_I945G(dev) ((dev)->pci_device == 0x2772) From SteveD at redhat.com Wed Feb 11 20:02:30 2009 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 11 Feb 2009 15:02:30 -0500 Subject: [PATCH 0/2] NFS: lockd fails to load causing mounts to fail. Message-ID: <49932ED6.1010607@RedHat.com> In the current rawhide kernels, when a NFS mount is done, and then an unmount and then another NFS mount, the second mount will fail with: mount.nfs: access denied by server while mounting : The problem is the kernel lockd thread, which is started on the first NFS mount and stopped on the last NFS mount, was failing to start up again on the second mount. The failure was caused by lockd doing IPV6 service registrations on the way up and then failing to unregister those services on the way down. The next time lockd tried to register those services, rpcbind failed them since they already existed... These two patches fixes this problem. Note: These patches will be in upstream very shortly.... steved. From SteveD at redhat.com Wed Feb 11 20:04:47 2009 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 11 Feb 2009 15:04:47 -0500 Subject: [PATCH 1/2] SUNRPC: Allow callers to pass rpcb_v4_register a NULL In-Reply-To: <49932ED6.1010607@RedHat.com> References: <49932ED6.1010607@RedHat.com> Message-ID: <49932F5F.6050402@RedHat.com> The user space TI-RPC library uses an empty string for the universal address when unregistering all target addresses for [program, version]. Allow the kernel's rpcb client to support the same. Here, we are switching between several registration methods based on the protocol family of the incoming address. Rename the other rpcbind v4 registration functions to make it clear that they are switched on protocol family as well. In /etc/netconfig, this is either "inet" or "inet6". The loopback protocol families are not supported in the kernel. Signed-off-by: Chuck Lever Signed-off-by: Steve Dickson --- net/sunrpc/rpcb_clnt.c | 38 ++++++++++++++++++++++++++++---------- 1 files changed, 28 insertions(+), 10 deletions(-) diff -up linux-2.6.28.x86_64/net/sunrpc/rpcb_clnt.c.orig linux-2.6.28.x86_64/net/sunrpc/rpcb_clnt.c --- linux-2.6.28.x86_64/net/sunrpc/rpcb_clnt.c.orig 2009-02-10 13:14:34.000000000 -0500 +++ linux-2.6.28.x86_64/net/sunrpc/rpcb_clnt.c 2009-02-11 14:50:47.000000000 -0500 @@ -255,8 +255,8 @@ int rpcb_register(u32 prog, u32 vers, in /* * Fill in AF_INET family-specific arguments to register */ -static int rpcb_register_netid4(struct sockaddr_in *address_to_register, - struct rpc_message *msg) +static int rpcb_register_inet4(struct sockaddr_in *address_to_register, + struct rpc_message *msg) { struct rpcbind_args *map = msg->rpc_argp; unsigned short port = ntohs(address_to_register->sin_port); @@ -283,8 +283,8 @@ static int rpcb_register_netid4(struct s /* * Fill in AF_INET6 family-specific arguments to register */ -static int rpcb_register_netid6(struct sockaddr_in6 *address_to_register, - struct rpc_message *msg) +static int rpcb_register_inet6(struct sockaddr_in6 *address_to_register, + struct rpc_message *msg) { struct rpcbind_args *map = msg->rpc_argp; unsigned short port = ntohs(address_to_register->sin6_port); @@ -312,6 +312,20 @@ static int rpcb_register_netid6(struct s return rpcb_register_call(RPCBVERS_4, msg); } +static int rpcb_unregister_all_protofamilies(struct rpc_message *msg) +{ + struct rpcbind_args *map = msg->rpc_argp; + + dprintk("RPC: unregistering [%u, %u, '%s'] with " + "local rpcbind\n", + map->r_prog, map->r_vers, map->r_netid); + + map->r_addr = ""; + msg->rpc_proc = &rpcb_procedures4[RPCBPROC_UNSET]; + + return rpcb_register_call(RPCBVERS_4, msg); +} + /** * rpcb_v4_register - set or unset a port registration with the local rpcbind * @program: RPC program number of service to (un)register @@ -329,10 +343,11 @@ static int rpcb_register_netid6(struct s * invoke this function once for each [program, version, address, * netid] tuple they wish to advertise. * - * Callers may also unregister RPC services that are no longer - * available by setting the port number in the passed-in address - * to zero. Callers pass a netid of "" to unregister all - * transport netids associated with [program, version, address]. + * Callers may also unregister RPC services that are registered at a + * specific address by setting the port number in @address to zero. + * They may unregister all registered protocol families at once for + * a service by passing a NULL @address argument. If @netid is "" + * then all netids for [program, version, address] are unregistered. * * This function uses rpcbind protocol version 4 to contact the * local rpcbind daemon. The local rpcbind daemon must support @@ -367,12 +382,15 @@ int rpcb_v4_register(const u32 program, .rpc_argp = &map, }; + if (address == NULL) + return rpcb_unregister_all_protofamilies(&msg); + switch (address->sa_family) { case AF_INET: - return rpcb_register_netid4((struct sockaddr_in *)address, + return rpcb_register_inet4((struct sockaddr_in *)address, &msg); case AF_INET6: - return rpcb_register_netid6((struct sockaddr_in6 *)address, + return rpcb_register_inet6((struct sockaddr_in6 *)address, &msg); } From SteveD at redhat.com Wed Feb 11 20:06:02 2009 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 11 Feb 2009 15:06:02 -0500 Subject: [PATCH 2/2] SUNRPC: Simplify svc_unregister() In-Reply-To: <49932ED6.1010607@RedHat.com> References: <49932ED6.1010607@RedHat.com> Message-ID: <49932FAA.9070603@RedHat.com> We now have some evidence that PMAP_UNSET clears only "inet" entries, and not "inet6" entries, in the rpcbind database. The svc_unregister() function also must work if user space doesn't support rpcbind version 4 at all. Thus we'll send an rpcbind v4 UNSET, and if that fails, we'll send a PMAP_UNSET. This simplifies the code in svc_unregister() and provides better backwards compatibility with legacy user space that does not support rpcbind version 4. This patch is part of a series that addresses http://bugzilla.kernel.org/show_bug.cgi?id=12256 Signed-off-by: Chuck Lever Signed-off-by: Steve Dickson --- net/sunrpc/svc.c | 35 ++++++++++++++--------------------- 1 files changed, 14 insertions(+), 21 deletions(-) diff -up linux-2.6.28.x86_64/net/sunrpc/svc.c.orig linux-2.6.28.x86_64/net/sunrpc/svc.c --- linux-2.6.28.x86_64/net/sunrpc/svc.c.orig 2009-02-10 13:14:34.000000000 -0500 +++ linux-2.6.28.x86_64/net/sunrpc/svc.c 2009-02-11 15:02:14.000000000 -0500 @@ -903,15 +903,25 @@ int svc_register(const struct svc_serv * } /* - * Olaf says a v2 UNSET should clear _all_ entries, including any - * registered via a v4 SET + * If user space is running rpcbind, it should take the v4 UNSET + * and clear everything for this [program, version]. If user space + * is running portmap, it will reject the v4 UNSET, but won't have + * any "inet6" entries anyway. So a PMAP_UNSET should be sufficient + * in this case to clear all existing entries for [program, version]. */ static void __svc_unregister(const u32 program, const u32 version, const char *progname) { int error; - error = rpcb_register(program, version, 0, 0); + /* + * User space didn't support rpcbind v4, so retry this + * request with the legacy rpcbind v2 protocol. + */ + error = rpcb_v4_register(program, version, NULL, ""); + if (error == -EPROTONOSUPPORT) + error = rpcb_register(program, version, 0, 0); + dprintk("svc: %s(%sv%u), error %d\n", __func__, progname, version, error); } From markmc at redhat.com Thu Feb 12 19:41:55 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 12 Feb 2009 19:41:55 +0000 Subject: Xen Dom0 kernels on branch Message-ID: <1234467715.21353.5.camel@blaa> Hey, Michael Young has been building some test kernels using Jeremy Fitzhardinge's dom0 patch set. I suggested that he use a private branch in CVS and scratch builds in Koji to make the task a bit easier. I've sponsored his FAS account and I'll help him out with getting started. Can someone approve his commit ACL for devel? https://admin.fedoraproject.org/pkgdb/packages/name/kernel Thanks, Mark. From kyle at infradead.org Thu Feb 12 21:15:01 2009 From: kyle at infradead.org (Kyle McMartin) Date: Thu, 12 Feb 2009 16:15:01 -0500 Subject: Xen Dom0 kernels on branch In-Reply-To: <1234467715.21353.5.camel@blaa> References: <1234467715.21353.5.camel@blaa> Message-ID: <20090212211501.GA31980@bombadil.infradead.org> On Thu, Feb 12, 2009 at 07:41:55PM +0000, Mark McLoughlin wrote: > Hey, > Michael Young has been building some test kernels using Jeremy > Fitzhardinge's dom0 patch set. > > I suggested that he use a private branch in CVS and scratch builds in > Koji to make the task a bit easier. I've sponsored his FAS account and > I'll help him out with getting started. > > Can someone approve his commit ACL for devel? > I've done this... please do make sure you do your work on a branch correctly so we don't have to have an icky confrontation. :P regards, Kyle From dwmw2 at infradead.org Sat Feb 14 08:23:57 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Feb 2009 08:23:57 +0000 Subject: config changes In-Reply-To: <20090113213913.GE3422@acer.localdomain> References: <20090109214511.GA32637@nostromo.devel.redhat.com> <496CFFBF.5010503@redhat.com> <20090113210902.GA13927@redhat.com> <20090113213913.GE3422@acer.localdomain> Message-ID: <1234599837.3564.46.camel@macbook.infradead.org> On Tue, 2009-01-13 at 13:39 -0800, Chris Wright wrote: > * Dave Jones (davej at redhat.com) wrote: > > On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: > > > Bill Nottingham wrote: > > > > Here's some proposed config changes. > > > > > > Jumping on the wagon ;) > > > > > > Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel > > > boxes, using VT-d. Called "DMA Remapping" in intel speak, this is where > > > the config option name comes from. Advantages: > > > > > > (1) 32bit PCI devices can DMA to memory above 4G, thus the need for > > > swiotlb (i.e. bounce buffers) is gone. > > > (2) It allows kvm to pass through PCI devices to guests securely. > > > > The last time we tried this, it blew up a lot due to broken BIOSes. > > Maybe it's been improved enough to tolerate them, so we can probably > > give it a spin in rawhide for a while to see what happens. > > Upstream was still broken as recently as Friday for bad BIOSes (x200s in > this case). Wonder if opt-in via cmdline would be helpful? This is now believed to be fixed, and I've re-enabled DMAR in rawhide. I see Chuck has applied the fix to F-10 already, and we'll look at the question of re-enabling DMAR there later. For now you still need to boot F-10 with 'intel_iommu=on'. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From kyle at mcmartin.ca Thu Feb 19 02:32:18 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 18 Feb 2009 21:32:18 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> Message-ID: <20090219023218.GI17272@bombadil.infradead.org> On Thu, Feb 19, 2009 at 02:07:27AM +0000, Kyle McMartin wrote: > Modified Files: > kernel.spec > Log Message: > go away docs. we hates you. > And here's a patch to turn them back on once per -rc. I think. My shell isn't what it used to be. The idea is we don't build docs other than on the first rebase to an -rc. Which is what the else bit accomplished. I think. Index: Makefile =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile,v retrieving revision 1.97 diff -u -p -r1.97 Makefile --- Makefile 5 Feb 2009 18:55:52 -0000 1.97 +++ Makefile 19 Feb 2009 02:28:32 -0000 @@ -114,6 +114,7 @@ release: @perl -pi -e 's/CONFIG_NR_CPUS=512/CONFIG_NR_CPUS=64/' config-x86_64-generic @perl -pi -e 's/^%define debugbuildsenabled 0/%define debugbuildsenabled 1/' kernel.spec + @perl -pi -e 's/^%define with_doc 0/#% define with_doc 0/' kernel.spec rhel: @perl -pi -e 's/# CONFIG_PPC_64K_PAGES is not set/CONFIG_PPC_64K_PAGES=y/' config-powerpc64 Index: scripts/rebase.sh =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/scripts/rebase.sh,v retrieving revision 1.24 diff -u -p -r1.24 rebase.sh --- scripts/rebase.sh 14 Jan 2009 00:55:01 -0000 1.24 +++ scripts/rebase.sh 19 Feb 2009 02:28:32 -0000 @@ -72,14 +72,24 @@ echo "NEW kernel is $NEW BASE=$NEWBASE if [ "$OLDRC" -eq 0 -a "$OLDGIT" -eq 0 -a "$OLDGIT" -ne "$NEWGIT" ]; then echo "Rebasing from a stable release to a new git snapshot" perl -p -i -e 's/^%define\ released_kernel\ 1/\%define\ released_kernel\ 0/' kernel.spec + perl -p -i -e 's/^%define\ with_doc\ 0/\#\%\ define\ with_doc\ 0/' kernel.spec # force these to zero in this case, they may not have been when we rebased to stable perl -p -i -e 's/^%define\ rcrev.*/\%define\ rcrev\ 0/' kernel.spec perl -p -i -e 's/^%define\ gitrev.*/\%define\ gitrev\ 0/' kernel.spec fi +# make sure we build docs at least once per -rc kernel, shut it off otherwise +if [ "$OLDRC" -ne 0 -a "$NEWRC" -gt "$OLDRC" ]; then + perl -p -i -e 's/^%define\ with_doc\ 0/\#\%\ define\ with_doc\ 0/' kernel.spec +else if [ "$NEWRC" -eq "$OLDRC" -a "$NEWGIT" -gt "$OLDGIT" ]; then + # common case, same -rc, new -git, make sure docs are off. + perl -p -i -e 's/^\#%\ define\ with_doc\ 0/\%define\ with_doc\ 0/' kernel.spec +endif + if [ "$NEWRC" -eq 0 -a "$NEWGIT" -eq 0 ]; then echo "Rebasing from -rc to final release." perl -p -i -e 's/^%define\ released_kernel\ 0/\%define\ released_kernel\ 1/' kernel.spec + perl -p -i -e 's/^%define\ with_doc\ 0/\#\%\ define\ with_doc\ 0/' kernel.spec export OLD_TARBALL_BASE=$(($OLDBASE-1)) perl -p -i -e 's/^%define\ base_sublevel\ $ENV{OLD_TARBALL_BASE}/%define\ base_sublevel\ $ENV{NEWBASE}/' kernel.spec perl -p -i -e 's/^%define\ rcrev.*/\%define\ rcrev\ 0/' kernel.spec From notting at redhat.com Thu Feb 19 14:53:57 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Feb 2009 09:53:57 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219023218.GI17272@bombadil.infradead.org> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> <20090219023218.GI17272@bombadil.infradead.org> Message-ID: <20090219145357.GA22217@nostromo.devel.redhat.com> Kyle McMartin (kyle at mcmartin.ca) said: > On Thu, Feb 19, 2009 at 02:07:27AM +0000, Kyle McMartin wrote: > > Modified Files: > > kernel.spec > > Log Message: > > go away docs. we hates you. > > > > And here's a patch to turn them back on once per -rc. I think. My shell > isn't what it used to be. > > The idea is we don't build docs other than on the first rebase to an > -rc. Which is what the else bit accomplished. I think. The compose process (for rawhide/updates) only pulls the latest build for each source package; ergo, this won't work as far as havong -docs always available to install. Bill From kyle at infradead.org Thu Feb 19 15:28:00 2009 From: kyle at infradead.org (Kyle McMartin) Date: Thu, 19 Feb 2009 10:28:00 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219145357.GA22217@nostromo.devel.redhat.com> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> <20090219023218.GI17272@bombadil.infradead.org> <20090219145357.GA22217@nostromo.devel.redhat.com> Message-ID: <20090219152800.GK17272@bombadil.infradead.org> On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: > The compose process (for rawhide/updates) only pulls the latest build > for each source package; ergo, this won't work as far as havong > -docs always available to install. > Well, that's broken. But honestly I suspect nobody actually cares. And if they do, I'm sure the F-10 package is still installable. From notting at redhat.com Thu Feb 19 15:30:56 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Feb 2009 10:30:56 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219152800.GK17272@bombadil.infradead.org> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> <20090219023218.GI17272@bombadil.infradead.org> <20090219145357.GA22217@nostromo.devel.redhat.com> <20090219152800.GK17272@bombadil.infradead.org> Message-ID: <20090219153056.GC22651@nostromo.devel.redhat.com> Kyle McMartin (kyle at infradead.org) said: > On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: > > The compose process (for rawhide/updates) only pulls the latest build > > for each source package; ergo, this won't work as far as havong > > -docs always available to install. > > Well, that's broken. But honestly I suspect nobody actually cares. > And if they do, I'm sure the F-10 package is still installable. Why not just make it conditional on whatver the release/non-debug/etc. switch is? Bill From kyle at infradead.org Thu Feb 19 15:33:03 2009 From: kyle at infradead.org (Kyle McMartin) Date: Thu, 19 Feb 2009 10:33:03 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219153056.GC22651@nostromo.devel.redhat.com> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> <20090219023218.GI17272@bombadil.infradead.org> <20090219145357.GA22217@nostromo.devel.redhat.com> <20090219152800.GK17272@bombadil.infradead.org> <20090219153056.GC22651@nostromo.devel.redhat.com> Message-ID: <20090219153303.GL17272@bombadil.infradead.org> On Thu, Feb 19, 2009 at 10:30:56AM -0500, Bill Nottingham wrote: > Kyle McMartin (kyle at infradead.org) said: > > On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: > > > The compose process (for rawhide/updates) only pulls the latest build > > > for each source package; ergo, this won't work as far as havong > > > -docs always available to install. > > > > Well, that's broken. But honestly I suspect nobody actually cares. > > And if they do, I'm sure the F-10 package is still installable. > > Why not just make it conditional on whatver the release/non-debug/etc. > switch is? > I don't care if it gets /composed/ the goal of building it every once and a while is to make sure it actually does build. We're pretty much the only people shipping top of tree code in a distro... Granted, special case this release since we're shipping the same thing in F-10 anyway. From cebbert at redhat.com Thu Feb 19 21:01:41 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 19 Feb 2009 16:01:41 -0500 Subject: rpms/kernel/devel kernel.spec,1.1311,1.1312 In-Reply-To: <20090219153303.GL17272@bombadil.infradead.org> References: <20090219020727.6512C700F8@cvs1.fedora.phx.redhat.com> <20090219023218.GI17272@bombadil.infradead.org> <20090219145357.GA22217@nostromo.devel.redhat.com> <20090219152800.GK17272@bombadil.infradead.org> <20090219153056.GC22651@nostromo.devel.redhat.com> <20090219153303.GL17272@bombadil.infradead.org> Message-ID: <20090219160141.73995889@dhcp-100-2-144.bos.redhat.com> On Thu, 19 Feb 2009 10:33:03 -0500 Kyle McMartin wrote: > On Thu, Feb 19, 2009 at 10:30:56AM -0500, Bill Nottingham wrote: > > Kyle McMartin (kyle at infradead.org) said: > > > On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: > > > > The compose process (for rawhide/updates) only pulls the latest build > > > > for each source package; ergo, this won't work as far as havong > > > > -docs always available to install. > > > > > > Well, that's broken. But honestly I suspect nobody actually cares. > > > And if they do, I'm sure the F-10 package is still installable. > > > > Why not just make it conditional on whatver the release/non-debug/etc. > > switch is? > > > > I don't care if it gets /composed/ the goal of building it every once > and a while is to make sure it actually does build. We're pretty much > the only people shipping top of tree code in a distro... > But once the release switch gets flipped we should always build it. From wwoods at redhat.com Tue Feb 24 23:22:00 2009 From: wwoods at redhat.com (Will Woods) Date: Tue, 24 Feb 2009 18:22:00 -0500 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <20090206151951.GC10018@nostromo.devel.redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> Message-ID: <1235517720.6470.25.camel@metroid.rdu.redhat.com> On Fri, 2009-02-06 at 10:19 -0500, Bill Nottingham wrote: > Chris Lalancette (clalance at 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 From roland at redhat.com Tue Feb 24 23:29:33 2009 From: roland at redhat.com (Roland McGrath) Date: Tue, 24 Feb 2009 15:29:33 -0800 (PST) Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: Will Woods's message of Tuesday, 24 February 2009 18:22:00 -0500 <1235517720.6470.25.camel@metroid.rdu.redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> Message-ID: <20090224232933.31C83FC380@magilla.sf.frob.com> > - 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 From davej at redhat.com Tue Feb 24 23:30:09 2009 From: davej at redhat.com (Dave Jones) Date: Tue, 24 Feb 2009 18:30:09 -0500 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <1235517720.6470.25.camel@metroid.rdu.redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> Message-ID: <20090224233009.GA7817@redhat.com> 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 (clalance at 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 From roland at redhat.com Tue Feb 24 23:38:42 2009 From: roland at redhat.com (Roland McGrath) Date: Tue, 24 Feb 2009 15:38:42 -0800 (PST) Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: Dave Jones's message of Tuesday, 24 February 2009 18:30:09 -0500 <20090224233009.GA7817@redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <20090224233009.GA7817@redhat.com> Message-ID: <20090224233842.50064FC380@magilla.sf.frob.com> > 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 From cebbert at redhat.com Wed Feb 25 00:03:40 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 24 Feb 2009 19:03:40 -0500 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <20090224233842.50064FC380@magilla.sf.frob.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <20090224233009.GA7817@redhat.com> <20090224233842.50064FC380@magilla.sf.frob.com> Message-ID: <20090224190340.643ed2f6@dhcp-100-2-144.bos.redhat.com> 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 From kraxel at redhat.com Wed Feb 25 09:24:57 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Wed, 25 Feb 2009 10:24:57 +0100 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <1235517720.6470.25.camel@metroid.rdu.redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> Message-ID: <49A50E69.8070601@redhat.com> 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 From clalance at redhat.com Wed Feb 25 12:27:35 2009 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 25 Feb 2009 13:27:35 +0100 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <49A50E69.8070601@redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <49A50E69.8070601@redhat.com> Message-ID: <49A53937.9090209@redhat.com> 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 From fedora at leemhuis.info Wed Feb 25 13:15:37 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Feb 2009 14:15:37 +0100 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <49A53937.9090209@redhat.com> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <49A50E69.8070601@redhat.com> <49A53937.9090209@redhat.com> Message-ID: <49A54479.1010104@leemhuis.info> 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 From clalance at redhat.com Wed Feb 25 14:58:42 2009 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 25 Feb 2009 15:58:42 +0100 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <49A54479.1010104@leemhuis.info> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <49A50E69.8070601@redhat.com> <49A53937.9090209@redhat.com> <49A54479.1010104@leemhuis.info> Message-ID: <49A55CA2.3050407@redhat.com> 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 From rjones at redhat.com Wed Feb 25 16:13:22 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 25 Feb 2009 16:13:22 +0000 Subject: Module request: IB700_WDT (IB700 watchdog timer) Message-ID: <20090225161322.GA9970@amd.home.annexia.org> I assume this is the right place to request drivers for the Fedora kernel? I'd like to request that the in-tree IB700 watchdog driver be enabled. The config option is IB700_WDT. My reading of the code is that it won't break anything unless users explicitly load the new module: http://lxr.linux.no/linux+v2.6.28.5/drivers/watchdog/ib700wdt.c Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From davej at redhat.com Wed Feb 25 18:19:21 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 25 Feb 2009 13:19:21 -0500 Subject: Module request: IB700_WDT (IB700 watchdog timer) In-Reply-To: <20090225161322.GA9970@amd.home.annexia.org> References: <20090225161322.GA9970@amd.home.annexia.org> Message-ID: <20090225181921.GA19611@redhat.com> On Wed, Feb 25, 2009 at 04:13:22PM +0000, Richard W.M. Jones wrote: > > I assume this is the right place to request drivers for the Fedora > kernel? > > I'd like to request that the in-tree IB700 watchdog driver be enabled. > The config option is IB700_WDT. looks like it already is ? $ grep IB700 config-* config-generic:CONFIG_IB700_WDT=m Dave -- http://www.codemonkey.org.uk From rjones at redhat.com Wed Feb 25 19:53:08 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 25 Feb 2009 19:53:08 +0000 Subject: Module request: IB700_WDT (IB700 watchdog timer) In-Reply-To: <20090225181921.GA19611@redhat.com> References: <20090225161322.GA9970@amd.home.annexia.org> <20090225181921.GA19611@redhat.com> Message-ID: <20090225195308.GB9970@amd.home.annexia.org> On Wed, Feb 25, 2009 at 01:19:21PM -0500, Dave Jones wrote: > On Wed, Feb 25, 2009 at 04:13:22PM +0000, Richard W.M. Jones wrote: > > > > I assume this is the right place to request drivers for the Fedora > > kernel? > > > > I'd like to request that the in-tree IB700 watchdog driver be enabled. > > The config option is IB700_WDT. > > looks like it already is ? > > $ grep IB700 config-* > config-generic:CONFIG_IB700_WDT=m I don't understand the way the config files get generated fully, but in current Rawhide CVS I see: $ grep IB700 config* config-generic:# CONFIG_IB700_WDT is not set config-x86-generic:CONFIG_IB700_WDT=m The driver doesn't seem to be built even on x86, eg in this build from today: http://koji.fedoraproject.org/koji/rpminfo?fileStart=1650&rpmID=1042373&fileOrder=name#filelist http://kojipkgs.fedoraproject.org/packages/kernel/2.6.29/0.153.rc6.git2.fc11/data/logs/i586/build.log Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From davej at redhat.com Wed Feb 25 20:56:05 2009 From: davej at redhat.com (Dave Jones) Date: Wed, 25 Feb 2009 15:56:05 -0500 Subject: Module request: IB700_WDT (IB700 watchdog timer) In-Reply-To: <20090225195308.GB9970@amd.home.annexia.org> References: <20090225161322.GA9970@amd.home.annexia.org> <20090225181921.GA19611@redhat.com> <20090225195308.GB9970@amd.home.annexia.org> Message-ID: <20090225205604.GA3236@redhat.com> On Wed, Feb 25, 2009 at 07:53:08PM +0000, Richard W.M. Jones wrote: > On Wed, Feb 25, 2009 at 01:19:21PM -0500, Dave Jones wrote: > > On Wed, Feb 25, 2009 at 04:13:22PM +0000, Richard W.M. Jones wrote: > > > > > > I assume this is the right place to request drivers for the Fedora > > > kernel? > > > > > > I'd like to request that the in-tree IB700 watchdog driver be enabled. > > > The config option is IB700_WDT. > > > > looks like it already is ? > > > > $ grep IB700 config-* > > config-generic:CONFIG_IB700_WDT=m > > I don't understand the way the config files get generated fully, but > in current Rawhide CVS I see: > > $ grep IB700 config* > config-generic:# CONFIG_IB700_WDT is not set > config-x86-generic:CONFIG_IB700_WDT=m I replied to your mail before I noticed another mail that showed Kyle turned it on earlier today. He added it to config-generic, which is what my grep turned up. I moved it to x86-generic, as it seems pointless turning it on on other architectures given it's for a SBC. > The driver doesn't seem to be built even on x86, eg in this build from > today: Yeah, no builds have been done today yet. It'll be in the next one that goes out. Dave -- http://www.codemonkey.org.uk From rjones at redhat.com Wed Feb 25 22:04:01 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 25 Feb 2009 22:04:01 +0000 Subject: Module request: IB700_WDT (IB700 watchdog timer) In-Reply-To: <20090225205604.GA3236@redhat.com> References: <20090225161322.GA9970@amd.home.annexia.org> <20090225181921.GA19611@redhat.com> <20090225195308.GB9970@amd.home.annexia.org> <20090225205604.GA3236@redhat.com> Message-ID: <20090225220401.GC9970@amd.home.annexia.org> On Wed, Feb 25, 2009 at 03:56:05PM -0500, Dave Jones wrote: > Yeah, no builds have been done today yet. > It'll be in the next one that goes out. Thanks! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From cebbert at redhat.com Thu Feb 26 00:28:45 2009 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 25 Feb 2009 19:28:45 -0500 Subject: How should anaconda check for PAE? (was Re: arch fun.) In-Reply-To: <49A54479.1010104@leemhuis.info> References: <20090205201140.GA21993@redhat.com> <498C33CD.2050009@redhat.com> <20090206151951.GC10018@nostromo.devel.redhat.com> <1235517720.6470.25.camel@metroid.rdu.redhat.com> <49A50E69.8070601@redhat.com> <49A53937.9090209@redhat.com> <49A54479.1010104@leemhuis.info> Message-ID: <20090225192845.39f89169@dhcp-100-2-144.bos.redhat.com> 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. From kyle at infradead.org Thu Feb 26 17:44:20 2009 From: kyle at infradead.org (Kyle McMartin) Date: Thu, 26 Feb 2009 12:44:20 -0500 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> Message-ID: <20090226174420.GO6690@bombadil.infradead.org> On Thu, Feb 26, 2009 at 09:51:14AM +0000, Fedora PackageDB wrote: > oliver has requested the commit acl on kernel (Fedora devel) > Uh, who are you again? regards, Kyle From tibbs at math.uh.edu Thu Feb 26 17:46:08 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 26 Feb 2009 11:46:08 -0600 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <20090226174420.GO6690@bombadil.infradead.org> (Kyle McMartin's message of "Thu\, 26 Feb 2009 12\:44\:20 -0500") References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> Message-ID: >>>>> "KM" == Kyle McMartin writes: KM> Uh, who are you again? Oliver Falk, works on the Alpha port if I'm not mistaken. - J< From davej at redhat.com Thu Feb 26 18:22:58 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Feb 2009 13:22:58 -0500 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> Message-ID: <20090226182258.GA6502@redhat.com> On Thu, Feb 26, 2009 at 11:46:08AM -0600, Jason L Tibbitts III wrote: > >>>>> "KM" == Kyle McMartin writes: > > KM> Uh, who are you again? > > Oliver Falk, works on the Alpha port if I'm not mistaken. I'm not averse to adding him to committers, but I'd like to see the patches go by fedora-kernel-list first. Dave -- http://www.codemonkey.org.uk From oliver at linux-kernel.at Thu Feb 26 21:37:27 2009 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 26 Feb 2009 22:37:27 +0100 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <20090226182258.GA6502@redhat.com> References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> <20090226182258.GA6502@redhat.com> Message-ID: <49A70B97.5010404@linux-kernel.at> Dave Jones schrieb: > On Thu, Feb 26, 2009 at 11:46:08AM -0600, Jason L Tibbitts III wrote: > > >>>>> "KM" == Kyle McMartin writes: > > > > KM> Uh, who are you again? Don't be afraid Kyle. I'm not a script kiddie trying to patch the kernel for Skynet compatibility... 8-) Skynet came to my mind because of Kyle Rees (Michael Biehn)... > > Oliver Falk, works on the Alpha port if I'm not mistaken. I should have stated this in my earlier mail. My fault. Yes, Jay E. and me are working on the Alpha port. Most kernel related patches come from him. He checks the kernels on his machines and I do the same on my machines. I'm not going to add patches I haven't tested myself. However, I do trust Jay of course... > I'm not averse to adding him to committers, but I'd like to > see the patches go by fedora-kernel-list first. Kernel is your sovereignty. Your rules. I'll obey. The things I plan: * Update Makefile.config to generate *alpha.config and *alpha-smp.config * Remove alphaev56 from spec, since nobody will support this subarch * Add a alpha section (%ifarch alpha), defining all the with_* macros - We/I should maybe rework this part... * Fix alpha target, and kernel_image* * Add config-alpha-generic and config-alpha-smp * And the current patches for F-9: - linux-2.6.28-alpha-exec_range.patch + Add execshield dummy functions for alpha - linux-2.6-alpha-pci_get_bus_and_slot.patch + include pci_get_bus_and_slot for alpha - linux-2.6-alpha-eepro100-cleanup.patch + cleanup extraneous "freeing mc frame" message from driver + This is obsolete (with >= 2.6.29) AFAIK, driver dropped!? + Since new driver (e100) shows the same problem, Jay E. will try to fix the new one and/or get in contact with upstream maintainer - linux-2.6.28-alpha-pci.h.patch - linux-2.6-alpha-pci.c.patch + Platform support for /proc/bus/pci/X/Y mmap()s + define HAVE_PCI_MMAP + extern int pci_mmap_page_range For F-10/devel it will be the same in blue and yellow :-) I can send patches to fedora-kernel-list tomorrow, when I'm back to office. Also a diff to the current F-9 and F-10 spec. -of From davej at redhat.com Thu Feb 26 21:44:27 2009 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Feb 2009 16:44:27 -0500 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <49A70B97.5010404@linux-kernel.at> References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> <20090226182258.GA6502@redhat.com> <49A70B97.5010404@linux-kernel.at> Message-ID: <20090226214427.GA30098@redhat.com> On Thu, Feb 26, 2009 at 10:37:27PM +0100, Oliver Falk wrote: > * Update Makefile.config to generate *alpha.config and *alpha-smp.config > * Remove alphaev56 from spec, since nobody will support this subarch > * Add a alpha section (%ifarch alpha), defining all the with_* macros > - We/I should maybe rework this part... > * Fix alpha target, and kernel_image* > * Add config-alpha-generic and config-alpha-smp ok > * And the current patches for F-9: > - linux-2.6.28-alpha-exec_range.patch > + Add execshield dummy functions for alpha just fold this into the regular execshield diff > - linux-2.6-alpha-pci_get_bus_and_slot.patch > + include pci_get_bus_and_slot for alpha upstreamable? > - linux-2.6-alpha-eepro100-cleanup.patch > + cleanup extraneous "freeing mc frame" message from driver > + This is obsolete (with >= 2.6.29) AFAIK, driver dropped!? > + Since new driver (e100) shows the same problem, Jay E. will try > to fix the new one and/or get in contact with upstream > maintainer yeah, e100 should support everything that eepro100 did now, and do a better job at it too. > - linux-2.6.28-alpha-pci.h.patch > - linux-2.6-alpha-pci.c.patch > + Platform support for /proc/bus/pci/X/Y mmap()s > + define HAVE_PCI_MMAP > + extern int pci_mmap_page_range also upstreamable? > I can send patches to fedora-kernel-list tomorrow, when I'm back to > office. Also a diff to the current F-9 and F-10 spec. cool. I'll add your acl. It'll take a while to propagate anyway. Dave -- http://www.codemonkey.org.uk From oliver at linux-kernel.at Fri Feb 27 11:13:03 2009 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 27 Feb 2009 12:13:03 +0100 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <20090226214427.GA30098@redhat.com> References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> <20090226182258.GA6502@redhat.com> <49A70B97.5010404@linux-kernel.at> <20090226214427.GA30098@redhat.com> Message-ID: <49A7CABF.9020801@linux-kernel.at> Dave Jones wrote: > On Thu, Feb 26, 2009 at 10:37:27PM +0100, Oliver Falk wrote: > > > * Update Makefile.config to generate *alpha.config and *alpha-smp.config I haven't attached this part, since it's quite clear how it will look like... > > * Remove alphaev56 from spec, since nobody will support this subarch > > * Add a alpha section (%ifarch alpha), defining all the with_* macros > > - We/I should maybe rework this part... > > * Fix alpha target, and kernel_image* See attached specfile diffs (diff -cp). Notes: * buildid change will of course not go to the cvs * The with_* defines, might be better!? Suggestions are welcome! * Source100 and Source101 for config-alpha* is OK for you? * Alpha-specific patches that are commented out will be removed before commit! * Changelog will be updated to give more information. > > * Add config-alpha-generic and config-alpha-smp > > ok Attached as config-alpha-generic-$DIST config-alpha-smp contains only the following two lines: CONFIG_SMP=y CONFIG_NR_CPUS=16 I know you're going to tell me that I have to rework the config-alpha-generic to use the config-generic. And yes, I'll do that as the next step, but for now, may I check it in as it is? > > * And the current patches for F-9: > > - linux-2.6.28-alpha-exec_range.patch > > + Add execshield dummy functions for alpha > > just fold this into the regular execshield diff No problem. Since it's a diff against alpha/include/asm/pgalloc.h, I can easily integrate this hunk into the execshield.patch. > > - linux-2.6-alpha-pci_get_bus_and_slot.patch > > + include pci_get_bus_and_slot for alpha > > upstreamable? Yes. Also one of the next steps. :-) > > - linux-2.6-alpha-eepro100-cleanup.patch > > + cleanup extraneous "freeing mc frame" message from driver > > + This is obsolete (with >= 2.6.29) AFAIK, driver dropped!? > > + Since new driver (e100) shows the same problem, Jay E. will try > > to fix the new one and/or get in contact with upstream > > maintainer > > yeah, e100 should support everything that eepro100 did now, and > do a better job at it too. Well, e100 has problems on alpha, that's why we used to patch eepro100. However. I guess we can fix this together with upstream. Jay, you volunteered!? :-) > > - linux-2.6.28-alpha-pci.h.patch > > - linux-2.6-alpha-pci.c.patch > > + Platform support for /proc/bus/pci/X/Y mmap()s > > + define HAVE_PCI_MMAP > > + extern int pci_mmap_page_range > > also upstreamable? Yes, of course! If Jay hasn't already done that, we really need to. > > I can send patches to fedora-kernel-list tomorrow, when I'm back to > > office. Also a diff to the current F-9 and F-10 spec. > > cool. I'll add your acl. It'll take a while to propagate anyway. Thx a lot Dave for your trust! I'm not going to commit anything until I have your *GO*... -of -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: F9-kernel-spec-alpha.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: F10-kernel-spec-alpha.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config-alpha-generic-F9 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config-alpha-generic-F10 URL: From lists at timj.co.uk Sat Feb 28 16:47:57 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 28 Feb 2009 16:47:57 +0000 Subject: File conflicts between alsa-firmware and kernel-firmware Message-ID: <49A96ABD.4060608@timj.co.uk> I maintain alsa-firmware and the following bug regarding file conflicts between recent versions of kernel-firmware and alsa-firmware got raised today: https://bugzilla.redhat.com/show_bug.cgi?id=487873 I'm not really familiar with the kernel package maintenance, nor who/what governs what firmware goes into kernel-firmware (and indeed how that is related to the upstream kernel). I had a cursory look at the kernel spec in CVS but that didn't appear to have any relevant recent changes that were obvious. I did a diff between the firmware in alsa-firmware and in kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although there are some overlaps, much of the audio firmware in alsa-firmware isn't in kernel-firmware. The current conflicting files are: ess/* korg/* sb16/* yamaha/ds1_ctrl.fw yamaha/ds1_dsp.fw yamaha/ds1e_ctrl.fw Things that are in alsa-firmware but NOT in the above version of kernel-firmware are: asihpi/* digiface* 3g* ea/* emu/* mixart/* multiface* pcxhr/* vx/* yamaha/yss225_registers.bin [usx2y, which does something funky so it's not in /lib/firmware] Either way, it looks like we need to work together on this. - I'm happy to just drop the conflicting files from alsa-firmware - is that the right thing to do? - Are the above audio firmware files in kernel-firmware there to stay? - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? Thanks Tim From kyle at infradead.org Sat Feb 28 19:32:02 2009 From: kyle at infradead.org (Kyle McMartin) Date: Sat, 28 Feb 2009 14:32:02 -0500 Subject: [pkgdb] kernel: oliver has requested commit In-Reply-To: <49A7CABF.9020801@linux-kernel.at> References: <20090226095127.51BEE2084D1@bastion.fedora.phx.redhat.com> <20090226174420.GO6690@bombadil.infradead.org> <20090226182258.GA6502@redhat.com> <49A70B97.5010404@linux-kernel.at> <20090226214427.GA30098@redhat.com> <49A7CABF.9020801@linux-kernel.at> Message-ID: <20090228193202.GC28503@bombadil.infradead.org> On Fri, Feb 27, 2009 at 12:13:03PM +0100, Oliver Falk wrote: > Dave Jones wrote: >> On Thu, Feb 26, 2009 at 10:37:27PM +0100, Oliver Falk wrote: >> > * Update Makefile.config to generate *alpha.config and >> *alpha-smp.config > > I haven't attached this part, since it's quite clear how it will look > like... > >> > * Remove alphaev56 from spec, since nobody will support this subarch >> > * Add a alpha section (%ifarch alpha), defining all the with_* macros >> > - We/I should maybe rework this part... >> > * Fix alpha target, and kernel_image* > > See attached specfile diffs (diff -cp). > > Notes: > * buildid change will of course not go to the cvs > * The with_* defines, might be better!? Suggestions are welcome! > * Source100 and Source101 for config-alpha* is OK for you? > * Alpha-specific patches that are commented out will be removed before > commit! > * Changelog will be updated to give more information. > >> > * Add config-alpha-generic and config-alpha-smp >> >> ok > > Attached as config-alpha-generic-$DIST > > config-alpha-smp contains only the following two lines: > CONFIG_SMP=y > CONFIG_NR_CPUS=16 > > I know you're going to tell me that I have to rework the > config-alpha-generic to use the config-generic. > > And yes, I'll do that as the next step, but for now, may I check it in > as it is? > >> > * And the current patches for F-9: >> > - linux-2.6.28-alpha-exec_range.patch >> > + Add execshield dummy functions for alpha >> >> just fold this into the regular execshield diff > > No problem. Since it's a diff against alpha/include/asm/pgalloc.h, I can > easily integrate this hunk into the execshield.patch. > >> > - linux-2.6-alpha-pci_get_bus_and_slot.patch >> > + include pci_get_bus_and_slot for alpha >> >> upstreamable? > > Yes. Also one of the next steps. :-) > >> > - linux-2.6-alpha-eepro100-cleanup.patch >> > + cleanup extraneous "freeing mc frame" message from driver >> > + This is obsolete (with >= 2.6.29) AFAIK, driver dropped!? >> > + Since new driver (e100) shows the same problem, Jay E. will try >> > to fix the new one and/or get in contact with upstream >> > maintainer >> >> yeah, e100 should support everything that eepro100 did now, and >> do a better job at it too. > > Well, e100 has problems on alpha, that's why we used to patch eepro100. > However. I guess we can fix this together with upstream. Jay, you > volunteered!? :-) > >> > - linux-2.6.28-alpha-pci.h.patch >> > - linux-2.6-alpha-pci.c.patch >> > + Platform support for /proc/bus/pci/X/Y mmap()s >> > + define HAVE_PCI_MMAP >> > + extern int pci_mmap_page_range >> >> also upstreamable? > > Yes, of course! If Jay hasn't already done that, we really need to. > >> > I can send patches to fedora-kernel-list tomorrow, when I'm back to >> > office. Also a diff to the current F-9 and F-10 spec. >> >> cool. I'll add your acl. It'll take a while to propagate anyway. > > Thx a lot Dave for your trust! > > I'm not going to commit anything until I have your *GO*... > This all looks fine to me. Sorry to have been so blunt, but I'm fairly new to Fedora, so I didn't know you were actually working on stuff, and not just someone asking for random commit access. I wouldn't worry too much about the linux-2.6- namespace for patches, I'd prefer if they were just alpha-$patch.patch. davej, thoughts? regards, Kyle