From bpeck at redhat.com Wed Mar 21 18:12:51 2007 From: bpeck at redhat.com (Bill Peck) Date: Wed, 21 Mar 2007 14:12:51 -0400 Subject: 2.6.20-1.2999.fc7 and suspend Message-ID: <460175A3.2060008@redhat.com> Suspend to ram does not work with 2.6.20-1.2999.fc7 on an Asus Pundit P3-PH5, Dual core Intel. I know desktops aren't specifically supported but suspend/resume does work on this with 2.6.20-1.2925.fc6. I'll open a proper BZ if this is expected to work at this time. From lwang at redhat.com Wed Mar 21 18:23:36 2007 From: lwang at redhat.com (Linda Wang) Date: Wed, 21 Mar 2007 14:23:36 -0400 Subject: 2.6.20-1.2999.fc7 and suspend In-Reply-To: <460175A3.2060008@redhat.com> References: <460175A3.2060008@redhat.com> Message-ID: <46017828.1060501@redhat.com> Bill Peck wrote: > > Suspend to ram does not work with 2.6.20-1.2999.fc7 on an Asus Pundit > P3-PH5, Dual core Intel. > > I know desktops aren't specifically supported but suspend/resume does > work on this with 2.6.20-1.2925.fc6. > > I'll open a proper BZ if this is expected to work at this time. So if you do, can you please cc ncunning at redhat.com on the bug(s)? thanks. From cebbert at redhat.com Wed Mar 21 19:01:24 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 21 Mar 2007 15:01:24 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? Message-ID: <46018104.4020406@redhat.com> I get the feeling that some of the bugs we are seeing is because we have enabled CONFIG_PREEMPT_BKL. I remember looking at the code when it came out and thinking it was too scary to enable, so I never did in my own vanilla kernels. From jcm at redhat.com Wed Mar 21 19:04:02 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 21 Mar 2007 15:04:02 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <46018104.4020406@redhat.com> References: <46018104.4020406@redhat.com> Message-ID: <1174503842.21399.33.camel@jcm.boston.redhat.com> On Wed, 2007-03-21 at 15:01 -0400, Chuck Ebbert wrote: > I get the feeling that some of the bugs we are seeing is because > we have enabled CONFIG_PREEMPT_BKL. I remember looking at the > code when it came out and thinking it was too scary to enable, > so I never did in my own vanilla kernels. Well, it's likely to remain around upstream so surely it's better to fix bugs and feed them back upstream than ignore this, it'll just be painful later on IMO :-) Jon. From davej at redhat.com Wed Mar 21 19:09:03 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 15:09:03 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <1174503842.21399.33.camel@jcm.boston.redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> Message-ID: <20070321190903.GC18614@redhat.com> On Wed, Mar 21, 2007 at 03:04:02PM -0400, Jon Masters wrote: > On Wed, 2007-03-21 at 15:01 -0400, Chuck Ebbert wrote: > > I get the feeling that some of the bugs we are seeing is because > > we have enabled CONFIG_PREEMPT_BKL. I remember looking at the > > code when it came out and thinking it was too scary to enable, > > so I never did in my own vanilla kernels. > > Well, it's likely to remain around upstream so surely it's better to fix > bugs and feed them back upstream than ignore this, it'll just be painful > later on IMO :-) A few times, I've disabled an option like this in an update as an experiment just to see if "weirdo" bugs 'go away' or not. And then see if it comes back when I reenable it in a further update. It can be useful to pinpoint problems this way, but yes, the bug wants fixing ultimately. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Wed Mar 21 19:10:32 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 21 Mar 2007 15:10:32 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <1174503842.21399.33.camel@jcm.boston.redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> Message-ID: <46018328.7010602@redhat.com> Jon Masters wrote: > On Wed, 2007-03-21 at 15:01 -0400, Chuck Ebbert wrote: >> I get the feeling that some of the bugs we are seeing is because >> we have enabled CONFIG_PREEMPT_BKL. I remember looking at the >> code when it came out and thinking it was too scary to enable, >> so I never did in my own vanilla kernels. > > Well, it's likely to remain around upstream so surely it's better to fix > bugs and feed them back upstream than ignore this, it'll just be painful > later on IMO :-) > Well yeah, but it's optional. We don't enable CONFIG_PREEMPT and that's been there for a long time... From davej at redhat.com Wed Mar 21 19:13:42 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 15:13:42 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <46018328.7010602@redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> <46018328.7010602@redhat.com> Message-ID: <20070321191342.GD18614@redhat.com> On Wed, Mar 21, 2007 at 03:10:32PM -0400, Chuck Ebbert wrote: > Jon Masters wrote: > > On Wed, 2007-03-21 at 15:01 -0400, Chuck Ebbert wrote: > >> I get the feeling that some of the bugs we are seeing is because > >> we have enabled CONFIG_PREEMPT_BKL. I remember looking at the > >> code when it came out and thinking it was too scary to enable, > >> so I never did in my own vanilla kernels. > > > > Well, it's likely to remain around upstream so surely it's better to fix > > bugs and feed them back upstream than ignore this, it'll just be painful > > later on IMO :-) > > > > Well yeah, but it's optional. We don't enable CONFIG_PREEMPT and that's > been there for a long time... Which bugs in particular were you thinking might be caused by this? There's not that much generic code left under BKL these days anyway is there? And as for drivers.. just ioctls ? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Wed Mar 21 19:27:17 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Mar 2007 12:27:17 -0700 (PDT) Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: Chuck Ebbert's message of Wednesday, 21 March 2007 15:10:32 -0400 <46018328.7010602@redhat.com> Message-ID: <20070321192717.C320318004F@magilla.sf.frob.com> FWIW, I have taken to CONFIG_PREEMPT=y in my hacking kernels because it exposed on my clunky test machines bugs that were otherwise reproduced only on big honking machines with lots of parallelism. I haven't experienced a bug that wasn't there at all with CONFIG_PREEMPT=n, only ones that were hard to reproduce in hacker's conditions but more likely in production load conditions. So, out of sight, out of mind, sure. But out of sight, lurking to bite you in the ass later when you really aren't in the mood, also damn likely. Roland From davej at redhat.com Wed Mar 21 19:36:59 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 15:36:59 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321192717.C320318004F@magilla.sf.frob.com> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> Message-ID: <20070321193659.GF18614@redhat.com> On Wed, Mar 21, 2007 at 12:27:17PM -0700, Roland McGrath wrote: > FWIW, I have taken to CONFIG_PREEMPT=y in my hacking kernels because it > exposed on my clunky test machines bugs that were otherwise reproduced only > on big honking machines with lots of parallelism. I haven't experienced a > bug that wasn't there at all with CONFIG_PREEMPT=n, only ones that were > hard to reproduce in hacker's conditions but more likely in production load > conditions. So, out of sight, out of mind, sure. But out of sight, > lurking to bite you in the ass later when you really aren't in the mood, > also damn likely. It's crossed my mind to turn it on occasionally in rawhide just to shake out those hard to find bugs. The thing that's put me off has been that well, we've got enough bugs already without needing to find more right now. Dave -- http://www.codemonkey.org.uk From jcm at redhat.com Wed Mar 21 19:38:55 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 21 Mar 2007 15:38:55 -0400 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <46018328.7010602@redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> <46018328.7010602@redhat.com> Message-ID: <1174505935.21399.37.camel@jcm.boston.redhat.com> On Wed, 2007-03-21 at 15:10 -0400, Chuck Ebbert wrote: > Jon Masters wrote: > > On Wed, 2007-03-21 at 15:01 -0400, Chuck Ebbert wrote: > >> I get the feeling that some of the bugs we are seeing is because > >> we have enabled CONFIG_PREEMPT_BKL. I remember looking at the > >> code when it came out and thinking it was too scary to enable, > >> so I never did in my own vanilla kernels. > > > > Well, it's likely to remain around upstream so surely it's better to fix > > bugs and feed them back upstream than ignore this, it'll just be painful > > later on IMO :-) > > > > Well yeah, but it's optional. We don't enable CONFIG_PREEMPT and that's > been there for a long time... I'd enable CONFIG_PREEMPT myself...but that's me :-) Jon. From mingo at elte.hu Wed Mar 21 19:40:35 2007 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 21 Mar 2007 20:40:35 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <46018104.4020406@redhat.com> References: <46018104.4020406@redhat.com> Message-ID: <20070321194035.GA28626@elte.hu> * Chuck Ebbert wrote: > I get the feeling that some of the bugs we are seeing is because we > have enabled CONFIG_PREEMPT_BKL. I remember looking at the code when > it came out and thinking it was too scary to enable, so I never did in > my own vanilla kernels. yes, we should keep it enabled - it's the default upstream and we havent had PREEMPT_BKL related bugs for a really long time. in fact i had more !PREEMPT_BKL bugs than PREEMPT_BKL bugs. (BKL spinlock recursion for example) Ingo From mingo at elte.hu Wed Mar 21 19:43:22 2007 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 21 Mar 2007 20:43:22 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <46018328.7010602@redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> <46018328.7010602@redhat.com> Message-ID: <20070321194322.GB28626@elte.hu> * Chuck Ebbert wrote: > > Well, it's likely to remain around upstream so surely it's better to > > fix bugs and feed them back upstream than ignore this, it'll just be > > painful later on IMO :-) > > Well yeah, but it's optional. We don't enable CONFIG_PREEMPT and > that's been there for a long time... but CONFIG_PREEMPT has nontrivial overhead and impact. PREEMPT_BKL on the other hand has no overhead - in fact it helps on SMP, quite a bit at times. Ingo From zaitcev at redhat.com Wed Mar 21 20:35:04 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 21 Mar 2007 13:35:04 -0700 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321191342.GD18614@redhat.com> References: <46018104.4020406@redhat.com> <1174503842.21399.33.camel@jcm.boston.redhat.com> <46018328.7010602@redhat.com> <20070321191342.GD18614@redhat.com> Message-ID: <20070321133504.da5b905e.zaitcev@redhat.com> On Wed, 21 Mar 2007 15:13:42 -0400, Dave Jones wrote: > Which bugs in particular were you thinking might be caused by this? > There's not that much generic code left under BKL these days anyway is there? > And as for drivers.. just ioctls ? Last time I looked there was a ton of code in fs/* which required BKL. Drivers were written not to assume BKL for years, but due to general ineptitude of driver writers this wasn't really enforced. -- Pete From zaitcev at redhat.com Wed Mar 21 20:41:42 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 21 Mar 2007 13:41:42 -0700 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321192717.C320318004F@magilla.sf.frob.com> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> Message-ID: <20070321134142.0cfa7f97.zaitcev@redhat.com> On Wed, 21 Mar 2007 12:27:17 -0700 (PDT), Roland McGrath wrote: > FWIW, I have taken to CONFIG_PREEMPT=y in my hacking kernels because it > exposed on my clunky test machines bugs that were otherwise reproduced only > on big honking machines with lots of parallelism. [...] It helps with that, but I just don't trust it to work at all times. It's a really kludgy code from MontaVista, developed with embedded devices in mind. It's a certified miracle that it boots on SMP at all. That said, I love to hoist it onto others. It really helps to flush mb() from drivers. Before, it always was a hassle to persuade driver writers that they must not do it; not worth the trouble. Now you just turn the preempt on and voila, the box crashes. Heck, I had preempt find a bug in ub once (guess what... used mb() there too -- nobody is perfect). But running it on a production box is pure madness, IMHO. -- Pete From mingo at elte.hu Wed Mar 21 19:43:18 2007 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 21 Mar 2007 20:43:18 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321194035.GA28626@elte.hu> References: <46018104.4020406@redhat.com> <20070321194035.GA28626@elte.hu> Message-ID: <20070321194318.GA29070@elte.hu> * Ingo Molnar wrote: > > I get the feeling that some of the bugs we are seeing is because we > > have enabled CONFIG_PREEMPT_BKL. I remember looking at the code when > > it came out and thinking it was too scary to enable, so I never did > > in my own vanilla kernels. > > yes, we should keep it enabled - it's the default upstream and we > havent had PREEMPT_BKL related bugs for a really long time. > > in fact i had more !PREEMPT_BKL bugs than PREEMPT_BKL bugs. (BKL > spinlock recursion for example) well, PREEMPT_BKL is not the default - my points remain nevertheless. Ingo From cebbert at redhat.com Wed Mar 21 21:55:09 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 21 Mar 2007 17:55:09 -0400 Subject: What use is the kernel-debuginfo package? Message-ID: <4601A9BD.5050106@redhat.com> I can't get a combined source/disassembly listing from objdump using the kernel-debuginfo package: 1) objdump has no clue how to use the separate debug info: http://sourceware.org/bugzilla/show_bug.cgi?id=4030 No activity, bug is unassigned. 2) The path to the debug info is wrong anyway. In fact, there _is_ no path info in the .gnu_debuglink section of the kernel modules: $ objdump -j .gnu_debuglink -D ahci.ko ahci.ko: file format elf32-i386 Disassembly of section .gnu_debuglink: 00000000 <.gnu_debuglink>: 0: 61 popa 1: 68 63 69 2e 6b push $0x6b2e6963 6: 6f outsl %ds:(%esi),(%dx) 7: 2e 64 65 62 75 67 bound %esi,%cs:%fs:%gs:0x67(%ebp) d: 00 00 add %al,(%eax) f: 00 21 add %ah,(%ecx) 11: 25 .byte 0x25 12: 80 .byte 0x80 13: c9 leave This decodes to "ahci.ko.debug" plus a checksum, but it should read "/usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug" So my question is, who uses this debug info and how do they use it??? From mingo at elte.hu Wed Mar 21 19:48:28 2007 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 21 Mar 2007 20:48:28 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321194318.GA29070@elte.hu> References: <46018104.4020406@redhat.com> <20070321194035.GA28626@elte.hu> <20070321194318.GA29070@elte.hu> Message-ID: <20070321194828.GA29899@elte.hu> * Ingo Molnar wrote: > > yes, we should keep it enabled - it's the default upstream and we > > havent had PREEMPT_BKL related bugs for a really long time. > > > > in fact i had more !PREEMPT_BKL bugs than PREEMPT_BKL bugs. (BKL > > spinlock recursion for example) > > well, PREEMPT_BKL is not the default - my points remain nevertheless. let me double-correct myself: PREEMPT_BKL is indeed default enabled on SMP: config PREEMPT_BKL bool "Preempt The Big Kernel Lock" depends on SMP || PREEMPT default y help so basically everyone who tests SMP kernels has it. Ingo From roland at redhat.com Wed Mar 21 22:08:30 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Mar 2007 15:08:30 -0700 (PDT) Subject: What use is the kernel-debuginfo package? In-Reply-To: Chuck Ebbert's message of Wednesday, 21 March 2007 17:55:09 -0400 <4601A9BD.5050106@redhat.com> Message-ID: <20070321220830.4CF3718004F@magilla.sf.frob.com> > 2) The path to the debug info is wrong anyway. In fact, there _is_ > no path info in the .gnu_debuglink section of the kernel modules: They're not supposed to have directory names. Try elfutils tools, or gdb. They handle separate debuginfo well. e.g. eu-addr2line -k 0x... is nice. We don't yet have disassembly tools in elfutils, unfortunately. gdb will deal well with a .ko and find its debug info, and has disassembly and source info. It doesn't have an interleaved output format AFAIK, though. I've considered writing an "unstrip" to paste stripped and .debug file back together so you can use them with dumber tools. From mingo at elte.hu Wed Mar 21 19:47:07 2007 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 21 Mar 2007 20:47:07 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321193659.GF18614@redhat.com> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> <20070321193659.GF18614@redhat.com> Message-ID: <20070321194707.GC28626@elte.hu> * Dave Jones wrote: > It's crossed my mind to turn it on occasionally in rawhide just to > shake out those hard to find bugs. The thing that's put me off has > been that well, we've got enough bugs already without needing to find > more right now. it's on by default in -rt and i havent had a bug triggered by it for quite a long time. We had many SMP races triggered by PREEMPT_RT. part of the reason of PREEMPT_BKL's reliability is because when i did it i also wrote debugging infrastructure to catch bugs that would only trigger on PREEMPT_BKL=y: the smp_processor_id() debugging code of CONFIG_DEBUG_PREEMPT. (and that infrastructure, like lockdep, catches bugs before they actually happen, by flagging buggy codepath the first time it ever executes) Ingo From cebbert at redhat.com Wed Mar 21 22:41:06 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 21 Mar 2007 18:41:06 -0400 Subject: What use is the kernel-debuginfo package? In-Reply-To: <20070321220830.4CF3718004F@magilla.sf.frob.com> References: <20070321220830.4CF3718004F@magilla.sf.frob.com> Message-ID: <4601B482.4020801@redhat.com> Roland McGrath wrote: >> 2) The path to the debug info is wrong anyway. In fact, there _is_ >> no path info in the .gnu_debuglink section of the kernel modules: > > They're not supposed to have directory names. Try elfutils tools, or gdb. > They handle separate debuginfo well. e.g. eu-addr2line -k 0x... is nice. > We don't yet have disassembly tools in elfutils, unfortunately. Well, addr2line works because you point it directly to the .ko.debug file: $ eu-addr2line -e ahci.ko.debug 0x0 drivers/ata/ahci.c:479 > > gdb will deal well with a .ko and find its debug info, and has disassembly > and source info. It doesn't have an interleaved output format AFAIK, though. > But how could gdb put the two separate files together when there is no connection between them? How could it possibly know to go from: /lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko to /usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug without the full path name in the .gnu_debuglink section of the module? The debug info file does have the full (and correct) pathname of the source: comp_dir "/usr/src/debug/kernel-2.6.20/linux-2.6.20.i686" This still isn't quite right; it should really be: "/usr/src/debug/kernel-2.6.20/linux-2.6.20-1.2925.i686" But that is really where the installer puts the files, so it's just a minor packaging problem. (You can only have one 2.6.20 kernel source tree installed for debugging using the current naming convention.) > I've considered writing an "unstrip" to paste stripped and .debug file back > together so you can use them with dumber tools. > Yeah, that would be nice. From roland at redhat.com Wed Mar 21 23:02:39 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Mar 2007 16:02:39 -0700 (PDT) Subject: What use is the kernel-debuginfo package? In-Reply-To: Chuck Ebbert's message of Wednesday, 21 March 2007 18:41:06 -0400 <4601B482.4020801@redhat.com> Message-ID: <20070321230239.923BE18004F@magilla.sf.frob.com> > Well, addr2line works because you point it directly to the .ko.debug file: > > $ eu-addr2line -e ahci.ko.debug 0x0 > drivers/ata/ahci.c:479 That does not necessarily work, because it may not be able to do enough relocation. -e /installed/stripped/file, -k, -K, -p PID work, and they find the debuginfo file for you. (For ET_REL files you need to add 0x10000 to the address you use if using elfutils < 0.126.) > But how could gdb put the two separate files together when there is no > connection between them? How could it possibly know to go from: > > /lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko > > to > > /usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug Lo and behold, it does work. Really, truly. Embedding directory names is Not The Way. (Try "help set debug-file-directory" in gdb. The elfutils tools and their --debuginfo-path option are similar.) From jcm at redhat.com Thu Mar 22 06:15:17 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 02:15:17 -0400 Subject: sparse checking In-Reply-To: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> Message-ID: <46021EF5.4050107@redhat.com> Red Hat Buildsystem wrote: > Package: kernel-2.6.20-1.3010.fc7 > Tag: dist-fc7 > Status: failed > Built by: davej > ID: 58684 > Started: Thu, 22 Mar 2007 01:48:43 EDT > Finished: Thu, 22 Mar 2007 02:11:24 EDT > Changelog: > * Thu Mar 22 2007 Dave Jones > - Check source with sparse during build. Very cool. Jon. From davej at redhat.com Thu Mar 22 06:18:16 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 02:18:16 -0400 Subject: sparse checking In-Reply-To: <46021EF5.4050107@redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> Message-ID: <20070322061816.GB15364@redhat.com> On Thu, Mar 22, 2007 at 02:15:17AM -0400, Jon Masters wrote: > Red Hat Buildsystem wrote: > > > Package: kernel-2.6.20-1.3010.fc7 > > Tag: dist-fc7 > > Status: failed > > Built by: davej > > ID: 58684 > > Started: Thu, 22 Mar 2007 01:48:43 EDT > > Finished: Thu, 22 Mar 2007 02:11:24 EDT > > Changelog: > > * Thu Mar 22 2007 Dave Jones > > - Check source with sparse during build. > > Very cool. Still fighting it. As luck would have it, it's shaking out bugs in sparse. Seems to blow up horribly on ppc64. Dave -- http://www.codemonkey.org.uk From jcm at redhat.com Thu Mar 22 06:20:03 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 02:20:03 -0400 Subject: sparse checking In-Reply-To: <20070322061816.GB15364@redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> Message-ID: <46022013.2030705@redhat.com> Dave Jones wrote: > Still fighting it. As luck would have it, it's shaking out > bugs in sparse. Seems to blow up horribly on ppc64. Why am I not surprised? :-) Maybe I'll finally get around to posting some kABI build fixes too (one of the guys on an internal list is looking at this and has promised to send fixes, so I haven't yet) and in the process take a look at this. I don't use sparse enough. Jon. From fedora at leemhuis.info Thu Mar 22 06:24:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 07:24:54 +0100 Subject: sparse checking In-Reply-To: <20070322061816.GB15364@redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> Message-ID: <46022136.3040405@leemhuis.info> On 22.03.2007 07:18, Dave Jones wrote: > On Thu, Mar 22, 2007 at 02:15:17AM -0400, Jon Masters wrote: > > Red Hat Buildsystem wrote: > > > > > Package: kernel-2.6.20-1.3010.fc7 > > > Tag: dist-fc7 > > > Status: failed > > > Built by: davej > > > ID: 58684 > > > Started: Thu, 22 Mar 2007 01:48:43 EDT > > > Finished: Thu, 22 Mar 2007 02:11:24 EDT > > > Changelog: > > > * Thu Mar 22 2007 Dave Jones > > > - Check source with sparse during build. > > > > Very cool. > > Still fighting it. As luck would have it, it's shaking out > bugs in sparse. Seems to blow up horribly on ppc64. Just wondering -- why are you downloading sparse in the spec file? Isn't there a better way to use it? http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=markup [...] # Download and unpack sparse. %define sparsever 0.2 curl -O http://www.kernel.org/pub/software/devel/sparse/dist/sparse-%{sparsever}.tar.bz2 tar jxf sparse-%{sparsever}.tar.bz2 [...] CU th? From davej at redhat.com Thu Mar 22 06:26:24 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 02:26:24 -0400 Subject: sparse checking In-Reply-To: <46022136.3040405@leemhuis.info> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> <46022136.3040405@leemhuis.info> Message-ID: <20070322062624.GC15364@redhat.com> On Thu, Mar 22, 2007 at 07:24:54AM +0100, Thorsten Leemhuis wrote: > Just wondering -- why are you downloading sparse in the spec file? Isn't > there a better way to use it? fixed in a later commit. After the core+extras merge, it'll just be a builddep. For now, as extras packages can't be builddeps in core packages, I've included sparse-0.2 in the lookaside cache, just like all the other tarballs. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Mar 22 06:31:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 07:31:10 +0100 Subject: sparse checking In-Reply-To: <20070322062624.GC15364@redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> <46022136.3040405@leemhuis.info> <20070322062624.GC15364@redhat.com> Message-ID: <460222AE.9080300@leemhuis.info> On 22.03.2007 07:26, Dave Jones wrote: > On Thu, Mar 22, 2007 at 07:24:54AM +0100, Thorsten Leemhuis wrote: > > > Just wondering -- why are you downloading sparse in the spec file? Isn't > > there a better way to use it? > fixed in a later commit. Sorry -- I actually looked at the external CVS to make sure it's still there before posting, but it seems it lags a bit behind the real cvs server. CU thl From jcm at redhat.com Thu Mar 22 06:35:27 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 02:35:27 -0400 Subject: sparse checking In-Reply-To: <460222AE.9080300@leemhuis.info> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> <46022136.3040405@leemhuis.info> <20070322062624.GC15364@redhat.com> <460222AE.9080300@leemhuis.info> Message-ID: <460223AF.8070008@redhat.com> Thorsten Leemhuis wrote: > > On 22.03.2007 07:26, Dave Jones wrote: >> On Thu, Mar 22, 2007 at 07:24:54AM +0100, Thorsten Leemhuis wrote: >> >> > Just wondering -- why are you downloading sparse in the spec file? Isn't >> > there a better way to use it? >> fixed in a later commit. > > Sorry -- I actually looked at the external CVS to make sure it's still > there before posting, but it seems it lags a bit behind the real cvs server. Yeah, it's currently (I think) a 1 hour cycle or something on syncing. Jon. From davej at redhat.com Thu Mar 22 06:37:07 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 02:37:07 -0400 Subject: sparse checking In-Reply-To: <460222AE.9080300@leemhuis.info> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> <46022136.3040405@leemhuis.info> <20070322062624.GC15364@redhat.com> <460222AE.9080300@leemhuis.info> Message-ID: <20070322063707.GE15364@redhat.com> On Thu, Mar 22, 2007 at 07:31:10AM +0100, Thorsten Leemhuis wrote: > > > On 22.03.2007 07:26, Dave Jones wrote: > > On Thu, Mar 22, 2007 at 07:24:54AM +0100, Thorsten Leemhuis wrote: > > > > > Just wondering -- why are you downloading sparse in the spec file? Isn't > > > there a better way to use it? > > fixed in a later commit. > > Sorry -- I actually looked at the external CVS to make sure it's still > there before posting, but it seems it lags a bit behind the real cvs server. Yeah, sometimes it's near instant, other times it seems to take forever to mirror out. One more reason to look forward to a new SCM :) Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Thu Mar 22 10:54:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Mar 2007 05:54:42 -0500 Subject: sparse checking In-Reply-To: <20070322061816.GB15364@redhat.com> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> Message-ID: <1174560883.2977.82.camel@vader.jdub.homelinux.org> On Thu, 2007-03-22 at 02:18 -0400, Dave Jones wrote: > On Thu, Mar 22, 2007 at 02:15:17AM -0400, Jon Masters wrote: > > Red Hat Buildsystem wrote: > > > > > Package: kernel-2.6.20-1.3010.fc7 > > > Tag: dist-fc7 > > > Status: failed > > > Built by: davej > > > ID: 58684 > > > Started: Thu, 22 Mar 2007 01:48:43 EDT > > > Finished: Thu, 22 Mar 2007 02:11:24 EDT > > > Changelog: > > > * Thu Mar 22 2007 Dave Jones > > > - Check source with sparse during build. > > > > Very cool. > > Still fighting it. As luck would have it, it's shaking out > bugs in sparse. Seems to blow up horribly on ppc64. Are these logs put anywhere the public can see them? Sounds like it would be handy to pass on to the kernel janitors, etc. josh From Daniel.Kirsten at gmx.net Thu Mar 22 11:28:54 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Thu, 22 Mar 2007 12:28:54 +0100 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys Message-ID: <200703221228.54424.Daniel.Kirsten@gmx.net> Hallo, my compiled 2.6.20-1.2925 kernel does not boot. It hangs after unmounting the old proc and sys filesystems. However, I can still use Ctrl+Alt+Del to reboot. Maybe, the problem is related to Selinux. My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 worked fine, and I did not change the kernel configuration. The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and 2.6.20-1.2925 also work. Best regards, Daniel From constantine.gavrilov at gmail.com Thu Mar 22 10:11:25 2007 From: constantine.gavrilov at gmail.com (Constantine Gavrilov) Date: Thu, 22 Mar 2007 12:11:25 +0200 Subject: 2.6 kernel, switch/case statement and stack usage Message-ID: <4602564D.1090208@gmail.com> Hello: I have run into an annoying problem writing some kernel code in AS 4 update 4 environment. I was seeing stack overflows and found the problem. Some not very long case/switch cases (15-25 statements) are compiled by gcc compiler to use between 500 and 2000 bytes of stack space. This even for using enums that run from 0 to N without holes (in which case gcc optimizer is supposed to generate a table). Kbuild is used to build all code, I do not use stack variables at all (except for 2 or 3 ints and function args), and some of the code is even as simple as calling a separate function for each case statement. Re-writing the code to use a call function table for consecutive enums solved the problem in that specific code -- nearly 0 stack usage. But there is also code that uses kernel non-consecutive enums and does not necessarily call functions for case entries (these are also most problematic places where compiler "eats" up to 2 KB of stack). Writing my own hash implementation and jump table instead of switch/case statement seems an annoying ugly hack to me even though I can do it. Is it a known gcc/kernel 4K stack limitation (i.e. switch/case is a problem in 2.6 with 4K stack)? Is there an option to tell gcc "stack is small, do not over-use it" ? My concern is that there is core kernel code affected by this. I do not think the problem is specific to AS 4, but will show up in Fedora as well. I am sure there is no mistake, and the problem is switch/case construct and not what is under case (this has been verified). BTW, using if/else if/else if generates nearly identical code and does not solve the stack usage problem. Comments? -- ---------------------------------------- Constantine Gavrilov Kernel Developer Qlusters Software Ltd 1 Azrieli Center, Tel-Aviv Phone: +972-3-6081977 Fax: +972-3-6081841 ---------------------------------------- From cebbert at redhat.com Thu Mar 22 13:56:55 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 09:56:55 -0400 Subject: What use is the kernel-debuginfo package? In-Reply-To: <20070321230239.923BE18004F@magilla.sf.frob.com> References: <20070321230239.923BE18004F@magilla.sf.frob.com> Message-ID: <46028B27.9090006@redhat.com> Roland McGrath wrote: > (Try "help set debug-file-directory" in gdb. The elfutils > tools and their --debuginfo-path option are similar.) > That's the missing piece. Thanks. But still, I have to do a --debuginfo-path that's different for each module. e.g. for ata modules it's <...>/drivers/ata/ and for crypto it's <...>/crypto/. Shouldn't the final part of the path be in the .gnu_debuginfo? From jwboyer at jdub.homelinux.org Thu Mar 22 14:24:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Mar 2007 09:24:59 -0500 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200703221228.54424.Daniel.Kirsten@gmx.net> References: <200703221228.54424.Daniel.Kirsten@gmx.net> Message-ID: <1174573499.15518.0.camel@zod.rchland.ibm.com> On Thu, 2007-03-22 at 12:28 +0100, Daniel Kirsten wrote: > Hallo, > > my compiled 2.6.20-1.2925 kernel does not boot. > It hangs after unmounting the old proc and > sys filesystems. However, I can still use > Ctrl+Alt+Del to reboot. That kernel is quite old now. Try using the latest from rawhide. josh From snecklifter at gmail.com Thu Mar 22 14:57:28 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 22 Mar 2007 14:57:28 +0000 Subject: /dev/dvb device nodes not being created? Message-ID: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> Thanks for the invite Chuck. Great to read about your appointment working with Dave by the way. I can confirm that this rocks. To the matter at hand folks: See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416 for dirty debugging output but essentially: I'm running MythTV and the cx88-dvb driver that loaded with all the 2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads the drivers fine. In the not too distant past there used to be a problem with the blackbird drivers grabbing control of the card(s) before the correct driver did so. I therefore blacklisted the blackbird driver and the correct driver loaded, the clouds cleared and the sun shone once more on green fields. Now it looks like something similar has returned and I can only force the driver to load by adding it to /etc/rc.modules Any ideas? Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Thu Mar 22 15:15:32 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 11:15:32 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> Message-ID: <46029D94.5070804@redhat.com> Chris Brown wrote: > Thanks for the invite Chuck. Great to read about your appointment working > with Dave by the way. I can confirm that this rocks. > > To the matter at hand folks: > > See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416 > > for dirty debugging output but essentially: > > I'm running MythTV and the cx88-dvb driver that loaded with all the > 2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads > the > drivers fine. In the not too distant past there used to be a problem with > the blackbird drivers grabbing control of the card(s) before the correct > driver did so. I therefore blacklisted the blackbird driver and the correct > driver loaded, the clouds cleared and the sun shone once more on green > fields. Now it looks like something similar has returned and I can only > force the driver to load by adding it to /etc/rc.modules > What are we supposed to do when this kind of thing happens? It appears that multiple drivers claim to support the same hardware. From drago01 at gmail.com Thu Mar 22 15:31:40 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 22 Mar 2007 16:31:40 +0100 Subject: /dev/dvb device nodes not being created? In-Reply-To: <46029D94.5070804@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> Message-ID: <4602A15C.3080701@gmail.com> Chuck Ebbert wrote: > > What are we supposed to do when this kind of thing happens? It appears that > multiple drivers claim to support the same hardware. > > dunno, but this needs a solution the same happens with tifm_sd/tifm_7xx1 and sdhci a workaround is to blacklist one of this modules. (if you know which one works better for you / which one do you want to use) From davej at redhat.com Thu Mar 22 15:56:17 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 11:56:17 -0400 Subject: sparse checking In-Reply-To: <1174560883.2977.82.camel@vader.jdub.homelinux.org> References: <200703220611.l2M6BWqW010599@int-mx1.corp.redhat.com> <46021EF5.4050107@redhat.com> <20070322061816.GB15364@redhat.com> <1174560883.2977.82.camel@vader.jdub.homelinux.org> Message-ID: <20070322155617.GF15364@redhat.com> On Thu, Mar 22, 2007 at 05:54:42AM -0500, Josh Boyer wrote: > > Still fighting it. As luck would have it, it's shaking out > > bugs in sparse. Seems to blow up horribly on ppc64. > > Are these logs put anywhere the public can see them? Sounds like it > would be handy to pass on to the kernel janitors, etc. That's the second part of the plan. Eventually, I want to get these logs hooked up to Al Viro's remapper, so that it only reports 'new' warnings too. Pre-brew, I used to rsync the build logs to me people.redhat.com page in a cronjob. Brew moved where files are stored, and I never got around to fixing it up. I'll get it hooked up again after I've got this in order. After the extras/core merge, and we use an external buildsys, it's possible they'll have to go somewhere else, but we'll deal with that hurdle when we come to it. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Mar 22 16:19:38 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 12:19:38 -0400 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200703221228.54424.Daniel.Kirsten@gmx.net> References: <200703221228.54424.Daniel.Kirsten@gmx.net> Message-ID: <20070322161938.GI15364@redhat.com> On Thu, Mar 22, 2007 at 12:28:54PM +0100, Daniel Kirsten wrote: > Hallo, > > my compiled 2.6.20-1.2925 kernel does not boot. > It hangs after unmounting the old proc and > sys filesystems. However, I can still use > Ctrl+Alt+Del to reboot. > > Maybe, the problem is related to Selinux. do a setenforce 0 before installing the kernel, there's a problem (still) with selinux policy preventing mkinitrd from doing the right thing. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Mar 22 16:31:27 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 12:31:27 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <46029D94.5070804@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> Message-ID: <20070322163127.GJ15364@redhat.com> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote: > Chris Brown wrote: > > Thanks for the invite Chuck. Great to read about your appointment working > > with Dave by the way. I can confirm that this rocks. > > > > To the matter at hand folks: > > > > See: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233416 > > > > for dirty debugging output but essentially: > > > > I'm running MythTV and the cx88-dvb driver that loaded with all the > > 2.6.18-2.6.19 kernels fails to do so with 2.6.20. Running modprobe loads > > the > > drivers fine. In the not too distant past there used to be a problem with > > the blackbird drivers grabbing control of the card(s) before the correct > > driver did so. I therefore blacklisted the blackbird driver and the correct > > driver loaded, the clouds cleared and the sun shone once more on green > > fields. Now it looks like something similar has returned and I can only > > force the driver to load by adding it to /etc/rc.modules > > > > What are we supposed to do when this kind of thing happens? It appears that > multiple drivers claim to support the same hardware. Grr, this happens far too often. We have the same with for eg, orinoco and hostap right now. The usual deal is that we either just build the 'best' driver for that hardware, or if there's a case where both drivers support the same hardware _and_ some hardware unique to them, we nobble the pci table so that the crappier driver doesn't load on that hardware. As to which is the best one in this case.. I really don't know. Or maybe this is a situation where it's valid to have both drivers loaded? We don't actually support that right now, but patches went to linux-pci list last week that should be showing up in GregKHs tree adding an alternative method for drivers to bind to a device in situations where it's possible for two drivers to drive different parts of the same chip. (This case has been showing up more and more recently too.. agp vs edac, matroxfb vs lm_sensors,..) Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Thu Mar 22 16:54:41 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 12:54:41 -0400 Subject: Problems with kernel updates needing non-kernel changes Message-ID: <4602B4D1.1080705@redhat.com> So far we seem to hit a few different problems when upgrading kernels. 1) mkinitrd may need changing, e.g. the raid4, raid5 and raid6 modules were combined into raid456 a while ago, breaking mkinitrd completely on raid machines. 2) some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options. 3) like (2) but options may need to be removed. suddenly drivers that worked refuse to load becuase they no longer recognize options that used to be valid. I'm especially concerned about (2) and (3) because there doesn't seem to be a system in place to update driver options after the system is installed. We can collect the needed changes but the logic to do all of this is in anaconda, and can only be applied during system install, as far as I can tell. From katzj at redhat.com Thu Mar 22 17:05:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Mar 2007 13:05:56 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <4602B4D1.1080705@redhat.com> References: <4602B4D1.1080705@redhat.com> Message-ID: <1174583156.24506.8.camel@erebor.boston.redhat.com> On Thu, 2007-03-22 at 12:54 -0400, Chuck Ebbert wrote: > 1) mkinitrd may need changing, e.g. the raid4, raid5 and raid6 > modules were combined into raid456 a while ago, breaking > mkinitrd completely on raid machines. There are a pile of other userspace packages that also commonly need updates. alsa stuff, pcmcia, kudzu, udev/hal (less these days), ... > 2) some modules may now work that were broken, but they need > new options, like snd-hda-intel which now works on my acer > notebook if "probe_mask=1" is added to the module options. This is just a case of broken drivers. Having to manually (modprobe.conf counts :) specify a module option to make a driver work means that the driver is broken -- these things _have_ to be auto-detected. Punting it to the user just isn't practical or reasonable. > 3) like (2) but options may need to be removed. suddenly drivers > that worked refuse to load becuase they no longer recognize > options that used to be valid. And this is really a breakage of the "interface" exposed to userspace and really should be beaten down as driver breakage. Trying to handle things like this is a losing battle. Jeremy From snecklifter at gmail.com Thu Mar 22 17:03:55 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 22 Mar 2007 17:03:55 +0000 Subject: /dev/dvb device nodes not being created? In-Reply-To: <20070322163127.GJ15364@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> Message-ID: <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> On 22/03/07, Dave Jones wrote: > > On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote: > > > What are we supposed to do when this kind of thing happens? It appears > that > > multiple drivers claim to support the same hardware. > > Grr, this happens far too often. We have the same with for eg, > orinoco and hostap right now. The usual deal is that we either > just build the 'best' driver for that hardware, or if there's a case > where both drivers support the same hardware _and_ some hardware unique > to them, we nobble the pci table so that the crappier driver > doesn't load on that hardware. > > As to which is the best one in this case.. I really don't know. > > Or maybe this is a situation where it's valid to have both drivers loaded? > We don't actually support that right now, but patches went to linux-pci > list > last week that should be showing up in GregKHs tree adding an alternative > method for drivers to bind to a device in situations where it's possible > for two drivers to drive different parts of the same chip. > (This case has been showing up more and more recently too.. > agp vs edac, matroxfb vs lm_sensors,..) Taking a look at: http://lwn.net/Articles/212535/ which may be able to shed some light on the changes. Even with the blackbird driver blacklisted, the v4l2 loads but the dvb driver does not. It should be noted that the two co-exist peacefully when loaded but something is preventing the latter from loading - perhaps because the kernel "sees" the driver requirements as being satisfied by the v4l2 module? In any case, in this instance it is just that the cx88-dvb driver is failing to load as opposed to anything more sinister. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcm at redhat.com Thu Mar 22 17:13:22 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 13:13:22 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174583156.24506.8.camel@erebor.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> Message-ID: <1174583602.28930.26.camel@jcm.boston.redhat.com> On Thu, 2007-03-22 at 13:05 -0400, Jeremy Katz wrote: > On Thu, 2007-03-22 at 12:54 -0400, Chuck Ebbert wrote: > > 1) mkinitrd may need changing, e.g. the raid4, raid5 and raid6 > > modules were combined into raid456 a while ago, breaking > > mkinitrd completely on raid machines. > > There are a pile of other userspace packages that also commonly need > updates. alsa stuff, pcmcia, kudzu, udev/hal (less these days), ... Oh don't count on that, I've got some plans to make udev/hal break a bit more often...joke. > > 2) some modules may now work that were broken, but they need > > new options, like snd-hda-intel which now works on my acer > > notebook if "probe_mask=1" is added to the module options. > > This is just a case of broken drivers. Having to manually > (modprobe.conf counts :) specify a module option to make a driver work > means that the driver is broken -- these things _have_ to be > auto-detected. Punting it to the user just isn't practical or > reasonable. Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches. Jon. From cebbert at redhat.com Thu Mar 22 18:21:03 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 14:21:03 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174583602.28930.26.camel@jcm.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <1174583602.28930.26.camel@jcm.boston.redhat.com> Message-ID: <4602C90F.4000605@redhat.com> Jon Masters wrote: > > Indeed. And options that are removed *must* be supported for a while. We > can't have modules that loaded previously now failing just because the > maintainer decided to remove a previously valid option without warning. > This needs strong upstream coercion on the part of those taking patches. We can always put the option back in the module just to make it load, but I really don't want to be doing that all the time. Maybe I could write patches that put the options back and just make them print a warning saying the option is no longer valid, then send them upstream. Maybe after a few iterations of that people will get the point? From cebbert at redhat.com Thu Mar 22 18:22:31 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 14:22:31 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174583156.24506.8.camel@erebor.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> Message-ID: <4602C967.2050906@redhat.com> Jeremy Katz wrote: > >> 2) some modules may now work that were broken, but they need >> new options, like snd-hda-intel which now works on my acer >> notebook if "probe_mask=1" is added to the module options. > > This is just a case of broken drivers. Having to manually > (modprobe.conf counts :) specify a module option to make a driver work > means that the driver is broken -- these things _have_ to be > auto-detected. Punting it to the user just isn't practical or > reasonable. > But don't we do that now? Doesn't Anaconda know about options needed for certain hardware and put them in modprobe.conf at install time? From katzj at redhat.com Thu Mar 22 18:22:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Mar 2007 14:22:35 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <4602C90F.4000605@redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <1174583602.28930.26.camel@jcm.boston.redhat.com> <4602C90F.4000605@redhat.com> Message-ID: <1174587756.24506.21.camel@erebor.boston.redhat.com> On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote: > Jon Masters wrote: > > Indeed. And options that are removed *must* be supported for a while. We > > can't have modules that loaded previously now failing just because the > > maintainer decided to remove a previously valid option without warning. > > This needs strong upstream coercion on the part of those taking patches. > > We can always put the option back in the module just to make it load, > but I really don't want to be doing that all the time. Maybe I could > write patches that put the options back and just make them print a > warning saying the option is no longer valid, then send them upstream. > Maybe after a few iterations of that people will get the point? Sounds like exactly the right answer to me! Jeremy From katzj at redhat.com Thu Mar 22 18:25:59 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Mar 2007 14:25:59 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <4602C967.2050906@redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> Message-ID: <1174587959.24506.23.camel@erebor.boston.redhat.com> On Thu, 2007-03-22 at 14:22 -0400, Chuck Ebbert wrote: > Jeremy Katz wrote: > >> 2) some modules may now work that were broken, but they need > >> new options, like snd-hda-intel which now works on my acer > >> notebook if "probe_mask=1" is added to the module options. > > > > This is just a case of broken drivers. Having to manually > > (modprobe.conf counts :) specify a module option to make a driver work > > means that the driver is broken -- these things _have_ to be > > auto-detected. Punting it to the user just isn't practical or > > reasonable. > > > But don't we do that now? Doesn't Anaconda know about options needed > for certain hardware and put them in modprobe.conf at install time? Nope! We list the module name and that's in. Any module options that end up there were specified manually (and through an excruciatingly painful UI) by the user Jeremy From jcm at redhat.com Thu Mar 22 18:26:08 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 14:26:08 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <4602C90F.4000605@redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <1174583602.28930.26.camel@jcm.boston.redhat.com> <4602C90F.4000605@redhat.com> Message-ID: <1174587968.28930.42.camel@jcm.boston.redhat.com> On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote: > Jon Masters wrote: > > > > Indeed. And options that are removed *must* be supported for a while. We > > can't have modules that loaded previously now failing just because the > > maintainer decided to remove a previously valid option without warning. > > This needs strong upstream coercion on the part of those taking patches. > > We can always put the option back in the module just to make it load, > but I really don't want to be doing that all the time. Maybe I could > write patches that put the options back and just make them print a > warning saying the option is no longer valid, then send them upstream. > Maybe after a few iterations of that people will get the point? That's what I was thinking...I just didn't want to think too loudly in case you said "Hey Jon, wanna help?" :P Jon. From katzj at redhat.com Thu Mar 22 18:29:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Mar 2007 14:29:48 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174587968.28930.42.camel@jcm.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <1174583602.28930.26.camel@jcm.boston.redhat.com> <4602C90F.4000605@redhat.com> <1174587968.28930.42.camel@jcm.boston.redhat.com> Message-ID: <1174588188.24506.25.camel@erebor.boston.redhat.com> On Thu, 2007-03-22 at 14:26 -0400, Jon Masters wrote: > On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote: > > Jon Masters wrote: > > > > > > Indeed. And options that are removed *must* be supported for a while. We > > > can't have modules that loaded previously now failing just because the > > > maintainer decided to remove a previously valid option without warning. > > > This needs strong upstream coercion on the part of those taking patches. > > > > We can always put the option back in the module just to make it load, > > but I really don't want to be doing that all the time. Maybe I could > > write patches that put the options back and just make them print a > > warning saying the option is no longer valid, then send them upstream. > > Maybe after a few iterations of that people will get the point? > > That's what I was thinking...I just didn't want to think too loudly in > case you said "Hey Jon, wanna help?" :P Thanks for volunteering ;-) Jeremy From cebbert at redhat.com Thu Mar 22 18:31:02 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 22 Mar 2007 14:31:02 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174587959.24506.23.camel@erebor.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> <1174587959.24506.23.camel@erebor.boston.redhat.com> Message-ID: <4602CB66.2080905@redhat.com> Jeremy Katz wrote: >>> >> But don't we do that now? Doesn't Anaconda know about options needed >> for certain hardware and put them in modprobe.conf at install time? > > Nope! We list the module name and that's in. Any module options that > end up there were specified manually (and through an excruciatingly > painful UI) by the user > They were? I have this in modprobe.conf and I know I didn't put it there: options snd-hda-intel index=0 From katzj at redhat.com Thu Mar 22 19:00:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Mar 2007 15:00:48 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <4602CB66.2080905@redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> <1174587959.24506.23.camel@erebor.boston.redhat.com> <4602CB66.2080905@redhat.com> Message-ID: <1174590048.24506.29.camel@erebor.boston.redhat.com> On Thu, 2007-03-22 at 14:31 -0400, Chuck Ebbert wrote: > Jeremy Katz wrote: > >> But don't we do that now? Doesn't Anaconda know about options needed > >> for certain hardware and put them in modprobe.conf at install time? > > > > Nope! We list the module name and that's in. Any module options that > > end up there were specified manually (and through an excruciatingly > > painful UI) by the user > > They were? I have this in modprobe.conf and I know I didn't put it > there: > > options snd-hda-intel index=0 Ugh... system-config-soundcard seems to be doing so. And it really really shouldn't be doing that as it's ultimately way too fragile to do :-/ Jeremy From jcm at redhat.com Thu Mar 22 19:02:10 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Mar 2007 15:02:10 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174590048.24506.29.camel@erebor.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> <1174587959.24506.23.camel@erebor.boston.redhat.com> <4602CB66.2080905@redhat.com> <1174590048.24506.29.camel@erebor.boston.redhat.com> Message-ID: <1174590130.28930.52.camel@jcm.boston.redhat.com> On Thu, 2007-03-22 at 15:00 -0400, Jeremy Katz wrote: > Ugh... system-config-soundcard seems to be doing so. And it really > really shouldn't be doing that as it's ultimately way too fragile to > do :-/ I get a bunch of those on all my Fedora/RHEL5 systems too. Jon. From Daniel.Kirsten at gmx.net Thu Mar 22 19:47:32 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Thu, 22 Mar 2007 20:47:32 +0100 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070322161938.GI15364@redhat.com> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <20070322161938.GI15364@redhat.com> Message-ID: <200703222047.32068.Daniel.Kirsten@gmx.net> On Thursday March 22 2007, you wrote: > > do a setenforce 0 before installing the kernel, > there's a problem (still) with selinux policy preventing > mkinitrd from doing the right thing. It did not work. SELinux is turned off. When I boot the self compiled 2.6.20-1.2925, the last message is "unmounting old /sys", then the system hangs. When I boot the standard fedora kernels, SELinux is started after the message "unmounting old /sys". Hence, I conjectured the problem is SELinux related. When I boot my the self compiled 2.6.19-1.2911, I see unmounting old /sys Init version 2.86 ... Best regards, Daniel From davej at redhat.com Thu Mar 22 19:55:18 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 15:55:18 -0400 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200703222047.32068.Daniel.Kirsten@gmx.net> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <20070322161938.GI15364@redhat.com> <200703222047.32068.Daniel.Kirsten@gmx.net> Message-ID: <20070322195518.GC15147@redhat.com> On Thu, Mar 22, 2007 at 08:47:32PM +0100, Daniel Kirsten wrote: > On Thursday March 22 2007, you wrote: > > > > do a setenforce 0 before installing the kernel, > > there's a problem (still) with selinux policy preventing > > mkinitrd from doing the right thing. > > It did not work. SELinux is turned off. > > When I boot the self compiled 2.6.20-1.2925, the last message > is "unmounting old /sys", then the system hangs. > > When I boot the standard fedora kernels, SELinux is started > after the message "unmounting old /sys". Hence, I conjectured > the problem is SELinux related. > > When I boot my the self compiled 2.6.19-1.2911, I see > > unmounting old /sys > Init version 2.86 ... Something broken in the initrd. How did you install it ? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Mar 22 20:59:21 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 22 Mar 2007 13:59:21 -0700 (PDT) Subject: What use is the kernel-debuginfo package? In-Reply-To: Chuck Ebbert's message of Thursday, 22 March 2007 09:56:55 -0400 <46028B27.9090006@redhat.com> Message-ID: <20070322205921.3B883180063@magilla.sf.frob.com> > Roland McGrath wrote: > > (Try "help set debug-file-directory" in gdb. The elfutils > > tools and their --debuginfo-path option are similar.) > > That's the missing piece. Thanks. > > But still, I have to do a --debuginfo-path that's different for > each module. e.g. for ata modules it's <...>/drivers/ata/ and > for crypto it's <...>/crypto/. Shouldn't the final part of the > path be in the .gnu_debuginfo? No. Sorry, I was unclear on the exact meaning. From a libdwfl.h comment: If the first character of the string is + or - that says to check or to ignore (respectively) the CRC32 checksum from the .gnu_debuglink section. The default is to check it. The remainder of the string is composed of elements separated by colons. Each element can start with + or - to override the global checksum behavior. If the remainder of the element is empty, the directory containing the main file is tried; if it's an absolute path name, the absolute directory path containing the main file is taken as a subdirectory of this path; a relative path name is taken as a subdirectory of the directory containing the main file. Hence for /bin/ls, string ":.debug:/usr/lib/debug" says to look in /bin, then /bin/.debug, then /usr/lib/debug/bin, for the file name in the .gnu_debuglink section (or "ls.debug" if none was found). */ From Daniel.Kirsten at gmx.net Thu Mar 22 21:16:22 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Thu, 22 Mar 2007 22:16:22 +0100 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070322195518.GC15147@redhat.com> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <200703222047.32068.Daniel.Kirsten@gmx.net> <20070322195518.GC15147@redhat.com> Message-ID: <200703222216.22562.Daniel.Kirsten@gmx.net> > > When I boot my the self compiled 2.6.19-1.2911, I see > > > > unmounting old /sys > > Init version 2.86 ... > > Something broken in the initrd. How did you install it ? as usual make clean make bzImage make modules make modules_install make install Daniel From davej at redhat.com Thu Mar 22 22:26:50 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 18:26:50 -0400 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200703222216.22562.Daniel.Kirsten@gmx.net> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <200703222047.32068.Daniel.Kirsten@gmx.net> <20070322195518.GC15147@redhat.com> <200703222216.22562.Daniel.Kirsten@gmx.net> Message-ID: <20070322222650.GB17882@redhat.com> On Thu, Mar 22, 2007 at 10:16:22PM +0100, Daniel Kirsten wrote: > > > When I boot my the self compiled 2.6.19-1.2911, I see > > > > > > unmounting old /sys > > > Init version 2.86 ... > > > > Something broken in the initrd. How did you install it ? > > as usual > > make clean > make bzImage > make modules > make modules_install > make install hmm, should work. First thoughts would be to pull apart the initrd, and compare what's in lib/ with what's in a working one. Probably something is missing. Dave -- http://www.codemonkey.org.uk From zaitcev at redhat.com Fri Mar 23 00:29:58 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 22 Mar 2007 17:29:58 -0700 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200703222216.22562.Daniel.Kirsten@gmx.net> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <200703222047.32068.Daniel.Kirsten@gmx.net> <20070322195518.GC15147@redhat.com> <200703222216.22562.Daniel.Kirsten@gmx.net> Message-ID: <20070322172958.a2404c57.zaitcev@redhat.com> On Thu, 22 Mar 2007 22:16:22 +0100, Daniel Kirsten wrote: > > Something broken in the initrd. How did you install it ? > > as usual > > make clean > make bzImage > make modules > make modules_install > make install You forgot this: mkinitrd /boot/initrd-your-version.img your-version And please change the EXTRAVERSION. Never install across a conflicting kernel version-release combo, or you'll regret it one day. -- Pete From davej at redhat.com Fri Mar 23 01:11:30 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 21:11:30 -0400 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070322172958.a2404c57.zaitcev@redhat.com> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <200703222047.32068.Daniel.Kirsten@gmx.net> <20070322195518.GC15147@redhat.com> <200703222216.22562.Daniel.Kirsten@gmx.net> <20070322172958.a2404c57.zaitcev@redhat.com> Message-ID: <20070323011130.GA1367@redhat.com> On Thu, Mar 22, 2007 at 05:29:58PM -0700, Pete Zaitcev wrote: > On Thu, 22 Mar 2007 22:16:22 +0100, Daniel Kirsten wrote: > > > > Something broken in the initrd. How did you install it ? > > > > as usual > > > > make clean > > make bzImage > > make modules > > make modules_install > > make install > > You forgot this: > mkinitrd /boot/initrd-your-version.img your-version make install does that for you. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Fri Mar 23 04:18:37 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 23 Mar 2007 00:18:37 -0400 Subject: 2.6 kernel, switch/case statement and stack usage In-Reply-To: <4602564D.1090208@gmail.com> References: <4602564D.1090208@gmail.com> Message-ID: <20070323041837.GA15461@redhat.com> On Thu, Mar 22, 2007 at 12:11:25PM +0200, Constantine Gavrilov wrote: > Hello: > > I have run into an annoying problem writing some kernel code in AS 4 > update 4 environment. I was seeing stack overflows and found the problem. You seem to be lost. This list is for the Fedora kernel. Also, without seeing your code, it's unlikely that anyone can guess what might be wrong. Dave -- http://www.codemonkey.org.uk From Daniel.Kirsten at gmx.net Fri Mar 23 12:20:38 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Fri, 23 Mar 2007 13:20:38 +0100 Subject: 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070322172958.a2404c57.zaitcev@redhat.com> References: <200703221228.54424.Daniel.Kirsten@gmx.net> <200703222216.22562.Daniel.Kirsten@gmx.net> <20070322172958.a2404c57.zaitcev@redhat.com> Message-ID: <200703231320.38865.Daniel.Kirsten@gmx.net> > > And please change the EXTRAVERSION. Never install across a conflicting > kernel version-release combo, or you'll regret it one day. I changed the EXTRAVERSION when I installed the kernel source. Daniel From jwilson at redhat.com Fri Mar 23 13:37:39 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 23 Mar 2007 09:37:39 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> Message-ID: <4603D823.2090802@redhat.com> Chris Brown wrote: > > > On 22/03/07, *Dave Jones* > > wrote: > > On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote: > > > What are we supposed to do when this kind of thing happens? It > appears that > > multiple drivers claim to support the same hardware. > > Grr, this happens far too often. We have the same with for eg, > orinoco and hostap right now. The usual deal is that we either > just build the 'best' driver for that hardware, or if there's a case > where both drivers support the same hardware _and_ some hardware unique > to them, we nobble the pci table so that the crappier driver > doesn't load on that hardware. > > As to which is the best one in this case.. I really don't know. > > Or maybe this is a situation where it's valid to have both drivers > loaded? > We don't actually support that right now, but patches went to > linux-pci list > last week that should be showing up in GregKHs tree adding an > alternative > method for drivers to bind to a device in situations where it's > possible > for two drivers to drive different parts of the same chip. > (This case has been showing up more and more recently too.. > agp vs edac, matroxfb vs lm_sensors,..) > > > Taking a look at: > > http://lwn.net/Articles/212535/ > > which may be able to shed some light on the changes. Yep. > Even with the > blackbird driver blacklisted, the v4l2 loads but the dvb driver does > not. It should be noted that the two co-exist peacefully when loaded but > something is preventing the latter from loading - perhaps because the > kernel "sees" the driver requirements as being satisfied by the v4l2 module? > > In any case, in this instance it is just that the cx88-dvb driver is > failing to load as opposed to anything more sinister. Interestingly enough, I was talking to one of the vl4-dvb maintainers (Michael Krufky) on irc about this very driver two days ago. The cx88-dvb driver is *supposed* to auto-load via a request_module() call in cx8802. Similar for cx88-blackbird. Things broke when support for the Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from 20070302 snapshot cx88-dvb/cx8802 drivers. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Fri Mar 23 14:06:29 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 23 Mar 2007 10:06:29 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <4603D823.2090802@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> <4603D823.2090802@redhat.com> Message-ID: <4603DEE5.2020205@redhat.com> Jarod Wilson wrote: > Chris Brown wrote: >> >> On 22/03/07, *Dave Jones* > >> wrote: >> >> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote: >> >> > What are we supposed to do when this kind of thing happens? It >> appears that >> > multiple drivers claim to support the same hardware. >> >> Grr, this happens far too often. We have the same with for eg, >> orinoco and hostap right now. The usual deal is that we either >> just build the 'best' driver for that hardware, or if there's a case >> where both drivers support the same hardware _and_ some hardware unique >> to them, we nobble the pci table so that the crappier driver >> doesn't load on that hardware. >> >> As to which is the best one in this case.. I really don't know. >> >> Or maybe this is a situation where it's valid to have both drivers >> loaded? >> We don't actually support that right now, but patches went to >> linux-pci list >> last week that should be showing up in GregKHs tree adding an >> alternative >> method for drivers to bind to a device in situations where it's >> possible >> for two drivers to drive different parts of the same chip. >> (This case has been showing up more and more recently too.. >> agp vs edac, matroxfb vs lm_sensors,..) >> >> >> Taking a look at: >> >> http://lwn.net/Articles/212535/ >> >> which may be able to shed some light on the changes. > > Yep. > >> Even with the >> blackbird driver blacklisted, the v4l2 loads but the dvb driver does >> not. It should be noted that the two co-exist peacefully when loaded but >> something is preventing the latter from loading - perhaps because the >> kernel "sees" the driver requirements as being satisfied by the v4l2 module? >> >> In any case, in this instance it is just that the cx88-dvb driver is >> failing to load as opposed to anything more sinister. > > Interestingly enough, I was talking to one of the vl4-dvb maintainers > (Michael Krufky) on irc about this very driver two days ago. The > cx88-dvb driver is *supposed* to auto-load via a request_module() call > in cx8802. Similar for cx88-blackbird. Things broke when support for the > Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb > and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from > 20070302 snapshot cx88-dvb/cx8802 drivers. So can they send a patch for -stable to fix it in 2.6.20? From mingo at elte.hu Sat Mar 24 16:56:17 2007 From: mingo at elte.hu (Ingo Molnar) Date: Sat, 24 Mar 2007 17:56:17 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070321134142.0cfa7f97.zaitcev@redhat.com> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> <20070321134142.0cfa7f97.zaitcev@redhat.com> Message-ID: <20070324165617.GA28949@elte.hu> * Pete Zaitcev wrote: > > FWIW, I have taken to CONFIG_PREEMPT=y in my hacking kernels because > > it exposed on my clunky test machines bugs that were otherwise > > reproduced only on big honking machines with lots of parallelism. > > [...] > > It helps with that, but I just don't trust it to work at all times. > It's a really kludgy code from MontaVista, developed with embedded > devices in mind. It's a certified miracle that it boots on SMP at all. actually, the current code works pretty well - and has been brought to the extreme via PREEMPT_RT. It boots fine on SMP and elsewhere, and it finds us tons of bugs in every kernel release. Ingo From zaitcev at redhat.com Sat Mar 24 18:23:10 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 24 Mar 2007 11:23:10 -0700 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070324165617.GA28949@elte.hu> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> <20070321134142.0cfa7f97.zaitcev@redhat.com> <20070324165617.GA28949@elte.hu> Message-ID: <20070324112310.341f1f54.zaitcev@redhat.com> On Sat, 24 Mar 2007 17:56:17 +0100, Ingo Molnar wrote: > > > FWIW, I have taken to CONFIG_PREEMPT=y in my hacking kernels because > > > it exposed on my clunky test machines bugs that were otherwise > > > reproduced only on big honking machines with lots of parallelism. > > > [...] > > > > It helps with that, but I just don't trust it to work at all times. > > It's a really kludgy code from MontaVista, developed with embedded > > devices in mind. It's a certified miracle that it boots on SMP at all. > > actually, the current code works pretty well - and has been brought to > the extreme via PREEMPT_RT. It boots fine on SMP and elsewhere, and it > finds us tons of bugs in every kernel release. If you say so, I take it back. -- Pete From jwilson at redhat.com Sat Mar 24 18:49:18 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 24 Mar 2007 14:49:18 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <4603DEE5.2020205@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> <4603D823.2090802@redhat.com> <4603DEE5.2020205@redhat.com> Message-ID: <460572AE.80708@redhat.com> Chuck Ebbert wrote: > Jarod Wilson wrote: >> Chris Brown wrote: >>> On 22/03/07, *Dave Jones* > >>> wrote: >>> >>> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote: >>> >>> > What are we supposed to do when this kind of thing happens? It >>> appears that >>> > multiple drivers claim to support the same hardware. >>> >>> Grr, this happens far too often. We have the same with for eg, >>> orinoco and hostap right now. The usual deal is that we either >>> just build the 'best' driver for that hardware, or if there's a case >>> where both drivers support the same hardware _and_ some hardware unique >>> to them, we nobble the pci table so that the crappier driver >>> doesn't load on that hardware. >>> >>> As to which is the best one in this case.. I really don't know. >>> >>> Or maybe this is a situation where it's valid to have both drivers >>> loaded? >>> We don't actually support that right now, but patches went to >>> linux-pci list >>> last week that should be showing up in GregKHs tree adding an >>> alternative >>> method for drivers to bind to a device in situations where it's >>> possible >>> for two drivers to drive different parts of the same chip. >>> (This case has been showing up more and more recently too.. >>> agp vs edac, matroxfb vs lm_sensors,..) >>> >>> >>> Taking a look at: >>> >>> http://lwn.net/Articles/212535/ >>> >>> which may be able to shed some light on the changes. >> Yep. >> >>> Even with the >>> blackbird driver blacklisted, the v4l2 loads but the dvb driver does >>> not. It should be noted that the two co-exist peacefully when loaded but >>> something is preventing the latter from loading - perhaps because the >>> kernel "sees" the driver requirements as being satisfied by the v4l2 module? >>> >>> In any case, in this instance it is just that the cx88-dvb driver is >>> failing to load as opposed to anything more sinister. >> Interestingly enough, I was talking to one of the vl4-dvb maintainers >> (Michael Krufky) on irc about this very driver two days ago. The >> cx88-dvb driver is *supposed* to auto-load via a request_module() call >> in cx8802. Similar for cx88-blackbird. Things broke when support for the >> Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb >> and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from >> 20070302 snapshot cx88-dvb/cx8802 drivers. > > So can they send a patch for -stable to fix it in 2.6.20? Okay, patches are good to go for both cx88-dvb and dvb-bt8xx autoload support. The cx88-dvb patch is a roll-up of three patches from upstream v4l-dvb. I've successfully tested this patch atop 2.6.20 with a pcHDTV HD-3000 card. http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch The dvb-bt8xx patch is a newly-created patch by myself (with pointers from Michael) that is essentially a clone of the cx88-dvb autoload bits. It works flawlessly in my testing with a pcHDTV HD-2000 card. Its in Michael's hands now, and he says he'll get it committed to the v4l-dvb tree this afternoon. http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch Semi-related to these patches is another cx88-dvb fix that we could optionally add to fix some buffer issues on nxt200x-based cx88-dvb cards: http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-nxt200x-buffer.patch All three apply cleanly to the current FC6 2.6.20 kernel tree, as Patch30-32. Lemme know if I can provide any further info! -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Sat Mar 24 18:51:13 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 24 Mar 2007 14:51:13 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <460572AE.80708@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> <4603D823.2090802@redhat.com> <4603DEE5.2020205@redhat.com> <460572AE.80708@redhat.com> Message-ID: <46057321.8060307@redhat.com> Jarod Wilson wrote: > The dvb-bt8xx patch is a newly-created patch by myself (with pointers > from Michael) that is essentially a clone of the cx88-dvb autoload bits. > It works flawlessly in my testing with a pcHDTV HD-2000 card. Its in > Michael's hands now, and he says he'll get it committed to the v4l-dvb > tree this afternoon. > > http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch D'oh, this one should be: http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-dvb-bt8xx-autoload.patch -- Jarod Wilson jwilson at redhat.com From mingo at elte.hu Sat Mar 24 21:48:48 2007 From: mingo at elte.hu (Ingo Molnar) Date: Sat, 24 Mar 2007 22:48:48 +0100 Subject: Should we be using CONFIG_PREEMPT_BKL in the Fedora kernel? In-Reply-To: <20070324112310.341f1f54.zaitcev@redhat.com> References: <46018328.7010602@redhat.com> <20070321192717.C320318004F@magilla.sf.frob.com> <20070321134142.0cfa7f97.zaitcev@redhat.com> <20070324165617.GA28949@elte.hu> <20070324112310.341f1f54.zaitcev@redhat.com> Message-ID: <20070324214848.GA22601@elte.hu> * Pete Zaitcev wrote: > > actually, the current code works pretty well - and has been brought > > to the extreme via PREEMPT_RT. It boots fine on SMP and elsewhere, > > and it finds us tons of bugs in every kernel release. > > If you say so, I take it back. CONFIG_PREEMPT alone is probably not worth having: it doesnt bring enough to the table, has overhead and doesnt satisfy the low-latency users. PREEMPT_RT is much nicer - but quite a bit more intrusive =B-) Ingo From notting at redhat.com Mon Mar 26 00:25:58 2007 From: notting at redhat.com (Bill Nottingham) Date: Sun, 25 Mar 2007 20:25:58 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <1174590048.24506.29.camel@erebor.boston.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> <1174587959.24506.23.camel@erebor.boston.redhat.com> <4602CB66.2080905@redhat.com> <1174590048.24506.29.camel@erebor.boston.redhat.com> Message-ID: <20070326002558.GA17531@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > options snd-hda-intel index=0 > > Ugh... system-config-soundcard seems to be doing so. And it really > really shouldn't be doing that as it's ultimately way too fragile to > do :-/ It's the only way to get persistent device ordering for sound cards. Yay crappy APIs. Bill From davidz at redhat.com Mon Mar 26 01:59:50 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 25 Mar 2007 21:59:50 -0400 Subject: Problems with kernel updates needing non-kernel changes In-Reply-To: <20070326002558.GA17531@nostromo.devel.redhat.com> References: <4602B4D1.1080705@redhat.com> <1174583156.24506.8.camel@erebor.boston.redhat.com> <4602C967.2050906@redhat.com> <1174587959.24506.23.camel@erebor.boston.redhat.com> <4602CB66.2080905@redhat.com> <1174590048.24506.29.camel@erebor.boston.redhat.com> <20070326002558.GA17531@nostromo.devel.redhat.com> Message-ID: <1174874390.5164.7.camel@zelda.fubar.dk> On Sun, 2007-03-25 at 20:25 -0400, Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: > > > options snd-hda-intel index=0 > > > > Ugh... system-config-soundcard seems to be doing so. And it really > > really shouldn't be doing that as it's ultimately way too fragile to > > do :-/ > > It's the only way to get persistent device ordering for sound cards. Yay > crappy APIs. Crap like that can hopefully go the way of the Dodo once we start using PulseAudio by default; won't happen for Fedora 7 though... David From jwilson at redhat.com Mon Mar 26 16:50:47 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 26 Mar 2007 12:50:47 -0400 Subject: /dev/dvb device nodes not being created? In-Reply-To: <46057321.8060307@redhat.com> References: <364d303b0703220757h25152a6w7776daddf34e0bf3@mail.gmail.com> <46029D94.5070804@redhat.com> <20070322163127.GJ15364@redhat.com> <364d303b0703221003o6595390fw96fef3877df2510@mail.gmail.com> <4603D823.2090802@redhat.com> <4603DEE5.2020205@redhat.com> <460572AE.80708@redhat.com> <46057321.8060307@redhat.com> Message-ID: <4607F9E7.5010100@redhat.com> Jarod Wilson wrote: > Jarod Wilson wrote: >> The dvb-bt8xx patch is a newly-created patch by myself (with pointers >> from Michael) that is essentially a clone of the cx88-dvb autoload >> bits. It works flawlessly in my testing with a pcHDTV HD-2000 card. >> Its in Michael's hands now, and he says he'll get it committed to the >> v4l-dvb tree this afternoon. >> >> http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch > > > D'oh, this one should be: > > http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-dvb-bt8xx-autoload.patch And of course, I managed to put the upstream version of the patch there, rather than the 2.6.20-based version. Here's the right one: http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-20.5t-dvb-bt8xx-autoload.patch The upstream commit can be seen here: http://linuxtv.org/hg/~mkrufky/bt8xx?cmd=changeset;node=328d9710a012;style=gitweb -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Mon Mar 26 22:14:41 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 26 Mar 2007 18:14:41 -0400 Subject: Something is changing the firmware loading timeout Message-ID: <460845D1.1080705@redhat.com> Firmware default loading timeout is set to 60 seconds by a Fedora patch (it's 10 seconds in the stock kernel.) Somehow, by the time I've finished booting it's back to 10 seconds. Does anyone have an idea why? I came up with this patch to make the minimum 60 seconds, still allowing 0 for "no timeout." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6-fedora_firmware_timout_limit.patch URL: From cebbert at redhat.com Mon Mar 26 22:19:06 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 26 Mar 2007 18:19:06 -0400 Subject: Something is changing the firmware loading timeout In-Reply-To: <460845D1.1080705@redhat.com> References: <460845D1.1080705@redhat.com> Message-ID: <460846DA.90702@redhat.com> Chuck Ebbert wrote: > --- linux-2.6.20.noarch/drivers/base/firmware_class.c.orig 2007-03-26 14:20:38.000000000 -0400 > +++ linux-2.6.20.noarch/drivers/base/firmware_class.c 2007-03-26 18:10:09.000000000 -0400 > @@ -81,8 +81,15 @@ > firmware_timeout_store(struct class *class, const char *buf, size_t count) > { > loading_timeout = simple_strtol(buf, NULL, 10); > - if (loading_timeout < 0) > + if (loading_timeout <= 0) > loading_timeout = 0; > + else if (loading_timeout < 60) { > + if (printk_ratelimit) + if (printk_ratelimit()) > + printk(KERN_INFO > + "firmware_class: attempt to set timeout to %d\n", > + loading_timeout); > + loading_timeout = 60; > + } > return count; > } From cebbert at redhat.com Tue Mar 27 15:03:15 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 27 Mar 2007 11:03:15 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries Message-ID: <46093233.9010205@redhat.com> It looks like we need to enable this option. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232742 So we need to set this: CONFIG_NF_CONNTRACK_PROC_COMPAT=y From jwboyer at jdub.homelinux.org Tue Mar 27 15:23:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Mar 2007 10:23:07 -0500 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <46093233.9010205@redhat.com> References: <46093233.9010205@redhat.com> Message-ID: <1175008987.7553.29.camel@zod.rchland.ibm.com> On Tue, 2007-03-27 at 11:03 -0400, Chuck Ebbert wrote: > It looks like we need to enable this option. See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232742 > > So we need to set this: > > CONFIG_NF_CONNTRACK_PROC_COMPAT=y For how long? I'm wondering why the application can't be fixed instead... josh From cebbert at redhat.com Tue Mar 27 16:52:13 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 27 Mar 2007 12:52:13 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <1175008987.7553.29.camel@zod.rchland.ibm.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> Message-ID: <46094BBD.2000902@redhat.com> Josh Boyer wrote: > On Tue, 2007-03-27 at 11:03 -0400, Chuck Ebbert wrote: >> It looks like we need to enable this option. See: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232742 >> >> So we need to set this: >> >> CONFIG_NF_CONNTRACK_PROC_COMPAT=y > > For how long? I'm wondering why the application can't be fixed > instead... Users also have firewall configuration scripts that rely on these entries. Some are broken by the module renaming but I'm not sure how we can fix that. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234174 From jwboyer at jdub.homelinux.org Tue Mar 27 18:55:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Mar 2007 13:55:36 -0500 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <46094BBD.2000902@redhat.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> <46094BBD.2000902@redhat.com> Message-ID: <1175021736.7553.34.camel@zod.rchland.ibm.com> On Tue, 2007-03-27 at 12:52 -0400, Chuck Ebbert wrote: > Josh Boyer wrote: > > On Tue, 2007-03-27 at 11:03 -0400, Chuck Ebbert wrote: > >> It looks like we need to enable this option. See: > >> > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232742 > >> > >> So we need to set this: > >> > >> CONFIG_NF_CONNTRACK_PROC_COMPAT=y > > > > For how long? I'm wondering why the application can't be fixed > > instead... > > Users also have firewall configuration scripts that rely on these > entries. Damn. That does suck. So how long does upstream intend to keep CONFIG_NF_CONNTRACK_PROC_COMPAT around? josh From cebbert at redhat.com Tue Mar 27 19:13:22 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 27 Mar 2007 15:13:22 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <1175021736.7553.34.camel@zod.rchland.ibm.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> <46094BBD.2000902@redhat.com> <1175021736.7553.34.camel@zod.rchland.ibm.com> Message-ID: <46096CD2.3040508@redhat.com> Josh Boyer wrote: >> Users also have firewall configuration scripts that rely on these >> entries. > > Damn. That does suck. > > So how long does upstream intend to keep CONFIG_NF_CONNTRACK_PROC_COMPAT > around? Until FC-6 dies, hopefully... :) A new comment in bz 234174 is interesting: | Or, ideally, the kernel rpm should look into obvious places (e.g. | /etc/sysconfig/iptables-config, /etc/sysctl.conf) and do some perl -pie magic. From davej at redhat.com Tue Mar 27 21:34:48 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 27 Mar 2007 17:34:48 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <46096CD2.3040508@redhat.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> <46094BBD.2000902@redhat.com> <1175021736.7553.34.camel@zod.rchland.ibm.com> <46096CD2.3040508@redhat.com> Message-ID: <20070327213448.GE13117@redhat.com> On Tue, Mar 27, 2007 at 03:13:22PM -0400, Chuck Ebbert wrote: > Josh Boyer wrote: > >> Users also have firewall configuration scripts that rely on these > >> entries. > > > > Damn. That does suck. > > > > So how long does upstream intend to keep CONFIG_NF_CONNTRACK_PROC_COMPAT > > around? > > Until FC-6 dies, hopefully... :) > > A new comment in bz 234174 is interesting: > > | Or, ideally, the kernel rpm should look into obvious places (e.g. > | /etc/sysconfig/iptables-config, /etc/sysctl.conf) and do some perl -pie magic. This would break booting back into the earlier kernel (which used to work until we munged these files). I think enabling the compat stuff for FC6's lifetime should be safe. Hopefully upstream won't rip them out too soon. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Tue Mar 27 21:48:40 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 27 Mar 2007 17:48:40 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <20070327213448.GE13117@redhat.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> <46094BBD.2000902@redhat.com> <1175021736.7553.34.camel@zod.rchland.ibm.com> <46096CD2.3040508@redhat.com> <20070327213448.GE13117@redhat.com> Message-ID: <46099138.2020705@redhat.com> Dave Jones wrote: > On Tue, Mar 27, 2007 at 03:13:22PM -0400, Chuck Ebbert wrote: > > Josh Boyer wrote: > > >> Users also have firewall configuration scripts that rely on these > > >> entries. > > > > > > Damn. That does suck. > > > > > > So how long does upstream intend to keep CONFIG_NF_CONNTRACK_PROC_COMPAT > > > around? > > > > Until FC-6 dies, hopefully... :) > > > > A new comment in bz 234174 is interesting: > > > > | Or, ideally, the kernel rpm should look into obvious places (e.g. > > | /etc/sysconfig/iptables-config, /etc/sysctl.conf) and do some perl -pie magic. > > This would break booting back into the earlier kernel (which used to work > until we munged these files). > Maybe we could create symlinks in the new kernel directory so the old module names would work? > I think enabling the compat stuff for FC6's lifetime should be safe. > Hopefully upstream won't rip them out too soon. We'll just leave FC 6 on 2.6.20 until 2.6.21 is stable, i.e. forever. :) From davej at redhat.com Tue Mar 27 21:51:34 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 27 Mar 2007 17:51:34 -0400 Subject: Backwards-compatible /proc and sysctl conntrack entries In-Reply-To: <46099138.2020705@redhat.com> References: <46093233.9010205@redhat.com> <1175008987.7553.29.camel@zod.rchland.ibm.com> <46094BBD.2000902@redhat.com> <1175021736.7553.34.camel@zod.rchland.ibm.com> <46096CD2.3040508@redhat.com> <20070327213448.GE13117@redhat.com> <46099138.2020705@redhat.com> Message-ID: <20070327215134.GH13117@redhat.com> On Tue, Mar 27, 2007 at 05:48:40PM -0400, Chuck Ebbert wrote: > Dave Jones wrote: > > On Tue, Mar 27, 2007 at 03:13:22PM -0400, Chuck Ebbert wrote: > > > Josh Boyer wrote: > > > >> Users also have firewall configuration scripts that rely on these > > > >> entries. > > > > > > > > Damn. That does suck. > > > > > > > > So how long does upstream intend to keep CONFIG_NF_CONNTRACK_PROC_COMPAT > > > > around? > > > > > > Until FC-6 dies, hopefully... :) > > > > > > A new comment in bz 234174 is interesting: > > > > > > | Or, ideally, the kernel rpm should look into obvious places (e.g. > > > | /etc/sysconfig/iptables-config, /etc/sysctl.conf) and do some perl -pie magic. > > > > This would break booting back into the earlier kernel (which used to work > > until we munged these files). > > > > Maybe we could create symlinks in the new kernel directory so the old module > names would work? maybe. if the contents are the same, then it should work. Makes me wonder why that isn't what CONFIG_NF_CONNTRACK_PROC_COMPAT would do. But then, I'm trying not to think too hard today. Vacationing is hard. > > I think enabling the compat stuff for FC6's lifetime should be safe. > > Hopefully upstream won't rip them out too soon. > > We'll just leave FC 6 on 2.6.20 until 2.6.21 is stable, i.e. forever. :) Forever the optimist eh? :) Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Wed Mar 28 00:41:53 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Mar 2007 19:41:53 -0500 Subject: Longing for git-bisect Message-ID: <1175042513.2977.90.camel@vader.jdub.homelinux.org> Has anyone played with keeping the Fedora kernel in a git tree somewhere? Current rawhide makes my T60p weep on a regular basis in the form of nice hard lockups with no oops output or anything. I'd love to be able to do a bisect on the kernel and see where things started going south. I just have no idea how to do that with the tree the way it currently is. Of course, I can see where tracking the Fedora kernel in git would be pretty painful at times too. So if anyone has a better suggestion, I'm all ears. josh From davej at redhat.com Wed Mar 28 00:52:02 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 27 Mar 2007 20:52:02 -0400 Subject: Longing for git-bisect In-Reply-To: <1175042513.2977.90.camel@vader.jdub.homelinux.org> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> Message-ID: <20070328005202.GA11618@redhat.com> On Tue, Mar 27, 2007 at 07:41:53PM -0500, Josh Boyer wrote: > Has anyone played with keeping the Fedora kernel in a git tree > somewhere? I looked at using it as a primary SCM last month just after FUDcon. The idea didn't work out so well as it's really painful to pull out invasive changesets from a git tree. The only alternative I came up with was a script that would generate a 'build' tree from a zillion branches. Even this didn't work out due to excessive rejects that needed fixing up when I dropped/readded a branch. It also meant that bisect was useless as it threw away the history each time it was generateed. Zaitcev had something that tracked the Fedora tree, but I never found time to look at what he did. > Current rawhide makes my T60p weep on a regular basis in the > form of nice hard lockups with no oops output or anything. I'd love to > be able to do a bisect on the kernel and see where things started going > south. I just have no idea how to do that with the tree the way it > currently is. I bet it's the E1000 driver. I've seen similar things happen on an X60, as have others on Fedora list. Intel people are poking at it without much luck so far. I even tried turning off tickless again, on a hunch that it might be that. No joy. Dave -- http://www.codemonkey.org.uk From sct at redhat.com Wed Mar 28 10:43:29 2007 From: sct at redhat.com (Stephen C. Tweedie) Date: Wed, 28 Mar 2007 11:43:29 +0100 Subject: Longing for git-bisect In-Reply-To: <1175042513.2977.90.camel@vader.jdub.homelinux.org> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> Message-ID: <1175078609.7854.2.camel@sisko.scot.redhat.com> Hi, On Tue, 2007-03-27 at 19:41 -0500, Josh Boyer wrote: > Has anyone played with keeping the Fedora kernel in a git tree > somewhere? Current rawhide makes my T60p weep on a regular basis in the > form of nice hard lockups with no oops output or anything. I'd love to > be able to do a bisect on the kernel and see where things started going > south. I've got a script which takes one of our kernel CVS trees and unpacks it incrementally into a git repo. I use it privately in order to get git trees for RHEL-4,5, rawhide etc. as a baseline for my own kernel working trees. In theory we should be able to use something like that for a proper CVS- to-git mirror at the exploded-tree (not CVS pristine+patches) level, which would be perfect for git bisecting. We'd just need to wrap it in a script which looks for new tags on the CVS trunk and pulls those in order into the git tree. But I'm not aware of anything that does that right now. --Stephen From jwboyer at jdub.homelinux.org Wed Mar 28 10:57:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 05:57:03 -0500 Subject: Longing for git-bisect In-Reply-To: <1175078609.7854.2.camel@sisko.scot.redhat.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> Message-ID: <1175079423.32658.3.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 11:43 +0100, Stephen C. Tweedie wrote: > Hi, > > On Tue, 2007-03-27 at 19:41 -0500, Josh Boyer wrote: > > Has anyone played with keeping the Fedora kernel in a git tree > > somewhere? Current rawhide makes my T60p weep on a regular basis in the > > form of nice hard lockups with no oops output or anything. I'd love to > > be able to do a bisect on the kernel and see where things started going > > south. > > I've got a script which takes one of our kernel CVS trees and unpacks it > incrementally into a git repo. I use it privately in order to get git > trees for RHEL-4,5, rawhide etc. as a baseline for my own kernel working > trees. > > In theory we should be able to use something like that for a proper CVS- > to-git mirror at the exploded-tree (not CVS pristine+patches) level, > which would be perfect for git bisecting. We'd just need to wrap it in > a script which looks for new tags on the CVS trunk and pulls those in > order into the git tree. Hm... but that isn't going to be very finely grained if I'm understanding you correctly. Basically you'd have a single commit for the -rc patches, etc. For git bisect, you'd almost want the opposite of that. So take the git tree upstream, and only commit the patches in CVS that aren't in that. Then when bisecting you still get the nice granularity and can figure out which upstream commit broke things. Right? josh From sct at redhat.com Wed Mar 28 11:20:05 2007 From: sct at redhat.com (Stephen C. Tweedie) Date: Wed, 28 Mar 2007 12:20:05 +0100 Subject: Longing for git-bisect In-Reply-To: <1175079423.32658.3.camel@vader.jdub.homelinux.org> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> Message-ID: <1175080805.7854.16.camel@sisko.scot.redhat.com> Hi, On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: > Hm... but that isn't going to be very finely grained if I'm > understanding you correctly. Basically you'd have a single commit for > the -rc patches, etc. There's a tag for every single brew build at the very least. It's a reasonable granularity, much finer than just once per RC. --Stephen From jonathan.underwood at gmail.com Wed Mar 28 15:22:48 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 28 Mar 2007 16:22:48 +0100 Subject: Debugging Soft Lockups in FC kernels Message-ID: <645d17210703280822t2a80a962j6152501bc0879496@mail.gmail.com> Hi, With FC-6 I have been seeing a lot of soft lockups with all shipped kernels on my Dell x86_64 SMP machines. For example, inserting a USB key triggers a soft lockup, as does the VMWare bridged interface. I realize the latter taints the kernel, but the former happens with untainted FC-6 kernels (i.e. the vmware stuff not installed let alone loaded). Anyway, I have reported bugs, detailing the stack trace that pops up in dmesg, but I get the feeling this isn't that helpful for debugging. So, my general question is this: What extra things could I do to provide more information about soft lockups? Best wishes, Jonathan From cebbert at redhat.com Wed Mar 28 15:49:09 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 28 Mar 2007 11:49:09 -0400 Subject: Debugging Soft Lockups in FC kernels In-Reply-To: <645d17210703280822t2a80a962j6152501bc0879496@mail.gmail.com> References: <645d17210703280822t2a80a962j6152501bc0879496@mail.gmail.com> Message-ID: <460A8E75.3000005@redhat.com> Jonathan Underwood wrote: > Hi, > > With FC-6 I have been seeing a lot of soft lockups with all shipped > kernels on my Dell x86_64 SMP machines. For example, inserting a USB > key triggers a soft lockup, as does the VMWare bridged interface. I > realize the latter taints the kernel, but the former happens with > untainted FC-6 kernels (i.e. the vmware stuff not installed let alone > loaded). Anyway, I have reported bugs, detailing the stack trace that > pops up in dmesg, but I get the feeling this isn't that helpful for > debugging. > > So, my general question is this: What extra things could I do to provide > more > information about soft lockups? This is bug 234009: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234009 Everything needed is there, I had only looked at the call traces. Try removing the SanDisk "value-added" DRM crap. See the latest bugzilla entry for details. From zaitcev at redhat.com Wed Mar 28 18:53:08 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 28 Mar 2007 11:53:08 -0700 Subject: Debugging Soft Lockups in FC kernels In-Reply-To: <645d17210703280822t2a80a962j6152501bc0879496@mail.gmail.com> References: <645d17210703280822t2a80a962j6152501bc0879496@mail.gmail.com> Message-ID: <20070328115308.26c8c293.zaitcev@redhat.com> On Wed, 28 Mar 2007 16:22:48 +0100, "Jonathan Underwood" wrote: > Anyway, I have reported bugs, detailing the stack trace that > pops up in dmesg, but I get the feeling this isn't that helpful for > debugging. > > So, my general question is this: What extra things could I do to provide more > information about soft lockups? Hmm. Actually you've done well, it just needs looking at the code which I haven't done due to... oh, look, something shiny! It's the RHEL-3 U9 and a monkey with Avocet Hi-Speed USB dongle! -- Pete From jwboyer at jdub.homelinux.org Wed Mar 28 19:14:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 14:14:51 -0500 Subject: Longing for git-bisect In-Reply-To: <1175080805.7854.16.camel@sisko.scot.redhat.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> <1175080805.7854.16.camel@sisko.scot.redhat.com> Message-ID: <1175109291.7553.83.camel@zod.rchland.ibm.com> On Wed, 2007-03-28 at 12:20 +0100, Stephen C. Tweedie wrote: > Hi, > > On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: > > > Hm... but that isn't going to be very finely grained if I'm > > understanding you correctly. Basically you'd have a single commit for > > the -rc patches, etc. > > There's a tag for every single brew build at the very least. It's a > reasonable granularity, much finer than just once per RC. I didn't mean Fedora RCs. I mean the 2.6.x-rcN patches. Since those get applied from CVS as wholesale patches rather than a series of individual commits, the granularity for rawhide kernels and git bisect would be pretty low compared to using the actually upstream git tree. E.g. bisecting a Fedora CVS -> git tree could result in showing that the addition of patch-2.6.21-rc5 broke things. Bisecting the upstream git tree would allow you to bisect down to which change within that patch broke things. I guess I'm trying to have my cake and eat it too. Pain either way. josh From davej at redhat.com Wed Mar 28 22:09:31 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Mar 2007 18:09:31 -0400 Subject: Longing for git-bisect In-Reply-To: <1175109291.7553.83.camel@zod.rchland.ibm.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> <1175080805.7854.16.camel@sisko.scot.redhat.com> <1175109291.7553.83.camel@zod.rchland.ibm.com> Message-ID: <20070328220931.GA14737@redhat.com> On Wed, Mar 28, 2007 at 02:14:51PM -0500, Josh Boyer wrote: > On Wed, 2007-03-28 at 12:20 +0100, Stephen C. Tweedie wrote: > > Hi, > > > > On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: > > > > > Hm... but that isn't going to be very finely grained if I'm > > > understanding you correctly. Basically you'd have a single commit for > > > the -rc patches, etc. > > > > There's a tag for every single brew build at the very least. It's a > > reasonable granularity, much finer than just once per RC. > > I didn't mean Fedora RCs. I mean the 2.6.x-rcN patches. Since those > get applied from CVS as wholesale patches rather than a series of > individual commits, the granularity for rawhide kernels and git bisect > would be pretty low compared to using the actually upstream git tree. But there's a build for each of for eg.. 2.6.21-rc4 2.6.21-rc4-git1 .. 2.6.21-rc4-git12 2.6.21-rc5 So the delta between git12 and rc5 is tiny. We don't hop from one -rc to another directly, but track upstream daily. (or almost daily). Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Wed Mar 28 22:52:11 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 17:52:11 -0500 Subject: Longing for git-bisect In-Reply-To: <20070328220931.GA14737@redhat.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> <1175080805.7854.16.camel@sisko.scot.redhat.com> <1175109291.7553.83.camel@zod.rchland.ibm.com> <20070328220931.GA14737@redhat.com> Message-ID: <1175122331.32658.10.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 18:09 -0400, Dave Jones wrote: > On Wed, Mar 28, 2007 at 02:14:51PM -0500, Josh Boyer wrote: > > On Wed, 2007-03-28 at 12:20 +0100, Stephen C. Tweedie wrote: > > > Hi, > > > > > > On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: > > > > > > > Hm... but that isn't going to be very finely grained if I'm > > > > understanding you correctly. Basically you'd have a single commit for > > > > the -rc patches, etc. > > > > > > There's a tag for every single brew build at the very least. It's a > > > reasonable granularity, much finer than just once per RC. > > > > I didn't mean Fedora RCs. I mean the 2.6.x-rcN patches. Since those > > get applied from CVS as wholesale patches rather than a series of > > individual commits, the granularity for rawhide kernels and git bisect > > would be pretty low compared to using the actually upstream git tree. > > But there's a build for each of for eg.. > > 2.6.21-rc4 > 2.6.21-rc4-git1 > .. > 2.6.21-rc4-git12 > 2.6.21-rc5 > > So the delta between git12 and rc5 is tiny. > > We don't hop from one -rc to another directly, but track upstream daily. > (or almost daily). Oh, duh. Yes, sorry for the noise. Stephen, where is your script? If you could provide it somewhere I'd be happy to play with it. josh From dwmw2 at infradead.org Wed Mar 28 23:26:25 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 29 Mar 2007 00:26:25 +0100 Subject: Longing for git-bisect In-Reply-To: <1175079423.32658.3.camel@vader.jdub.homelinux.org> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> Message-ID: <1175124385.3277.199.camel@pmac.infradead.org> On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: > For git bisect, you'd almost want the opposite of that. So take the git > tree upstream, and only commit the patches in CVS that aren't in that. > Then when bisecting you still get the nice granularity and can figure > out which upstream commit broke things. Normally if I'm tracking a problem in rawhide, the first thing I do is reproduce it on a 'clean' kernel. And then git-bisect isn't really a problem. It's just another way in which staying close to mainline makes it easier to debug our kernel. -- dwmw2 From fedora at leemhuis.info Thu Mar 29 04:48:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Mar 2007 06:48:50 +0200 Subject: Longing for git-bisect In-Reply-To: <1175124385.3277.199.camel@pmac.infradead.org> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <1175078609.7854.2.camel@sisko.scot.redhat.com> <1175079423.32658.3.camel@vader.jdub.homelinux.org> <1175124385.3277.199.camel@pmac.infradead.org> Message-ID: <460B4532.5040600@leemhuis.info> On 29.03.2007 01:26, David Woodhouse wrote: > On Wed, 2007-03-28 at 05:57 -0500, Josh Boyer wrote: >> For git bisect, you'd almost want the opposite of that. So take the git >> tree upstream, and only commit the patches in CVS that aren't in that. >> Then when bisecting you still get the nice granularity and can figure >> out which upstream commit broke things. > > Normally if I'm tracking a problem in rawhide, the first thing I do is > reproduce it on a 'clean' kernel. [...] That why we IMHO should provide a "clean" kernel as RPM somewhere, so "ordinary users" can install them easily to check if the error they are seeing is present there too. And if it is we can shove them to bug upstream about it (if we want). CU thl From roland at redhat.com Thu Mar 29 04:54:02 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 28 Mar 2007 21:54:02 -0700 (PDT) Subject: Longing for git-bisect In-Reply-To: Thorsten Leemhuis's message of Thursday, 29 March 2007 06:48:50 +0200 <460B4532.5040600@leemhuis.info> Message-ID: <20070329045402.895AB1801C4@magilla.sf.frob.com> I used to have some spec file hacks for conditionally building vanilla upstream, or upstream + another git branch, kernels in Fedora rpms. (I made vanilla and vanilla+utrace rpms like this for a while.) davej never wanted the conditional spec bits in cvs, so I let it wither after a while. From davej at redhat.com Thu Mar 29 06:55:32 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 02:55:32 -0400 Subject: Longing for git-bisect In-Reply-To: <20070329045402.895AB1801C4@magilla.sf.frob.com> References: <460B4532.5040600@leemhuis.info> <20070329045402.895AB1801C4@magilla.sf.frob.com> Message-ID: <20070329065532.GA23306@redhat.com> On Wed, Mar 28, 2007 at 09:54:02PM -0700, Roland McGrath wrote: > I used to have some spec file hacks for conditionally building vanilla > upstream, or upstream + another git branch, kernels in Fedora rpms. > (I made vanilla and vanilla+utrace rpms like this for a while.) > davej never wanted the conditional spec bits in cvs, so I let it wither > after a while. I toyed with the idea a few times. It might actually make sense to do something like this. There's probably always a handful of patches that you'll want from the Fedora kernel (things like the make nonintoldconfig thing for eg) but it could be worthwhile. I've chatted with Andrew Morton a number of times, and he's also wondered why we don't do it, and I don't really have a good answer. Meh, lets do it. If we can hook it somehow so that when I do a 'make build' for the rawhide kernel, a vanilla also pops out, all the better. (Though build times for the kernel are getting _crazy_) Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Mar 29 07:21:42 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 29 Mar 2007 00:21:42 -0700 (PDT) Subject: Longing for git-bisect In-Reply-To: Dave Jones's message of Thursday, 29 March 2007 02:55:32 -0400 <20070329065532.GA23306@redhat.com> Message-ID: <20070329072142.E20981801C4@magilla.sf.frob.com> > I toyed with the idea a few times. It might actually make sense to do > something like this. There's probably always a handful of patches that > you'll want from the Fedora kernel (things like the make nonintoldconfig > thing for eg) but it could be worthwhile. Yeah, I had that. > Meh, lets do it. If we can hook it somehow so that when I do > a 'make build' for the rawhide kernel, a vanilla also pops out, > all the better. (Though build times for the kernel are getting _crazy_) I'll poke at my old stuff a little. From roland at redhat.com Thu Mar 29 10:24:22 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 29 Mar 2007 03:24:22 -0700 (PDT) Subject: kernel build hacks for vanilla builds Message-ID: <20070329102422.B49881801C4@magilla.sf.frob.com> This is enough for "make vanilla-scratch-build" to work (or vanilla-i686, vanilla-compile, etc). It might even be enough for "make vanilla-tag vanilla-build", but I'd have to check it in to test that kludge. Attached below is my linux-2.6.17-nonintconfig.patch, my old replacement for linux-2.6-build-nonintconfig.patch (that didn't even need any rediffing). It adds a second option "make loose_nonintconfig". IIRC, this is necessary when upstream adds config options not yet in our config-* files, so you get defconfig answers for new things instead of errors. This probably doesn't come up with rawhide vanilla builds since those are only "downgrades", but it can come up when trying builds from GIT branches for experimental new things, and I found it much nicer to have defconfig win for this instead of hand-tweak config-foo in my otherwise pristine checkout. For doing builds from GIT branches, there's some more makefile magic and a little script to be dusted off. If you like this stuff, I'll check it in and then fiddle some more for the GIT variant. Thanks, Roland Index: Makefile =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/Makefile,v retrieving revision 1.45 diff -u -r1.45 Makefile --- Makefile 19 Mar 2007 21:32:30 -0000 1.45 +++ Makefile 29 Mar 2007 10:03:08 -0000 @@ -68,3 +68,25 @@ # since i386 isn't a target... compile compile-short: DIST_DEFINES += --target $(shell uname -m) + + +vanilla-%: $(SPECFILE:.spec=-vanilla.spec) + @$(MAKE) $* SPECFILE=$< + +$(SPECFILE:.spec=-vanilla.spec): $(SPECFILE) + @rm -f $@ + (echo %define nopatches 1; cat $<) > $@ + +scratch-build: test-srpm + $(BUILD_CLIENT) $(BUILD_FLAGS) --scratch $(COLLECTION) \ + $(SRCRPMDIR)/$(NAME)-$(VERSION)-$(RELEASE).src.rpm + +ifdef BEEHIVE_SRPM_BUILD +export CHECKOUT_TAG ?= $(shell sed s/^.// CVS/Tag) +tag-pattern = $(TAG_NAME)-$(TAG_VERSION)-0_%_$(TAG_RELEASE) +ifeq (,$(filter-out $(tag-pattern),$(CHECKOUT_TAG))) +variant := $(patsubst $(tag-pattern),%,$(CHECKOUT_TAG)) +srpm: SPECFILE := $(SPECFILE:.spec=-$(variant).spec) +srpm beehive-sprm: RELEASE := 0.$(variant).$(RELEASE) +endif +endif Index: kernel-2.6.spec =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3025 diff -u -r1.3025 kernel-2.6.spec --- kernel-2.6.spec 29 Mar 2007 00:00:55 -0000 1.3025 +++ kernel-2.6.spec 29 Mar 2007 10:03:09 -0000 @@ -32,7 +32,8 @@ %define sublevel 20 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define release %(R="$Revision: 1.3025 $"; RR="${R##: }"; echo ${RR%%?})%{?dist} +%define specrelease %(R="$Revision: 1.3025 $"; RR="${R##: }"; echo ${RR%%?})%{?dist} +%define release %{specrelease} %define make_target bzImage %define kernel_image x86 @@ -45,6 +46,28 @@ %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE} %define hdrarch %_target_cpu +%if 0%{!?nopatches:1} +%define nopatches 0 +%endif + +%if %{nopatches} +%define includexen 0 +%else +%define relsuffix .fedora +%endif + +%define using_upstream_branch 0 +%if 0%{?upstream_branch:1} +%define using_upstream_branch 1 +%define release 0.%{upstream_branch}%{?relsuffix}.%{specrelease} +%define buildxen 0 +%define buildxenPAE 0 +%else +%if %{nopatches} +%define release 0.vanilla.%{specrelease} +%endif +%endif + # groups of related archs #OLPC stuff %if 0%{?olpc} @@ -169,6 +192,15 @@ %define xen_image vmlinux.gz %endif +%if %{nopatches} +%define signmodules 0 +# Ignore unknown options in our config-* files. +# Some options go with patches we're not applying. +%define oldconfig_target loose_nonint_oldconfig +%else +%define oldconfig_target nonint_oldconfig +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -304,9 +336,17 @@ # # Patches 0 through 100 are meant for core subsystem upgrades # + +%if %{using_upstream_branch} +### BRANCH PATCH ### +%else Patch1: patch-2.6.21-rc5.bz2 +%endif + Patch3: git-geode.patch +%if !%{nopatches} + # Patches 10 through 99 are for things that are going upstream really soon. Patch10: linux-2.6-utrace.patch Patch11: nouveau-drm.patch @@ -360,7 +400,9 @@ # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # -Patch800: linux-2.6-build-nonintconfig.patch +%endif +Patch800: linux-2.6.17-nonintconfig.patch +%if !%{nopatches} # Exec-shield. Patch810: linux-2.6-execshield.patch @@ -495,6 +537,7 @@ Patch20002: xen-dom0-reboot.patch # END OF PATCH DEFINITIONS +%endif BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu} @@ -867,9 +910,16 @@ cd linux-%{kversion}.%{_target_cpu} +%if %{using_upstream_branch} +### BRANCH APPLY ### +%else + # Update to latest upstream. %patch1 -p1 +%endif +%if !%{nopatches} + # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. @@ -945,13 +995,14 @@ # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # - +%endif # This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). %patch800 -p1 +%if !%{nopatches} # Exec shield %patch810 -p1 @@ -1171,6 +1222,7 @@ %patch10001 -p1 # END OF PATCH APPLICATIONS +%endif cp %{SOURCE10} Documentation/ @@ -1201,7 +1253,7 @@ do mv $i .config Arch=`head -1 .config | cut -b 3-` - make ARCH=$Arch nonint_oldconfig > /dev/null + make ARCH=$Arch %{oldconfig_target} > /dev/null echo "# $Arch" > configs/$i cat .config >> configs/$i done @@ -1295,7 +1347,7 @@ KernelImage=arch/$Arch/boot/bzImage fi - make -s ARCH=$Arch nonint_oldconfig > /dev/null + make -s ARCH=$Arch %{oldconfig_target} > /dev/null make -s ARCH=$Arch %{?_smp_mflags} $MakeTarget %{?sparse_mflags} make -s ARCH=$Arch %{?_smp_mflags} modules %{?sparse_mflags} || exit 1 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6.17-nonintconfig.patch URL: From samfw at redhat.com Thu Mar 29 13:24:07 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Thu, 29 Mar 2007 09:24:07 -0400 Subject: [OT] please review new kernel build doc on fedora wiki Message-ID: <20070329132406.GB11824@unplugged.rdu.redhat.com> Hi, I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a while back that we remove the building instructions from the release notes and put those in a separate doc devoted to more detailed instructions on building the kernel RPM (including applying patches and configuring options). I've got a draft doc now. I come to this from a support perspective - building kernels with patches I get from Engineering to pass on for testing. I'd like to get the point of view of some kernel developers as well. - Is what's here correct? - Is there more that should be here? - Does the info here conform to best practices? Any feedback appreciated. I am happy to make edits myself if you reply, or of course any one can make edits on their own. http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel Thanks, Sam -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA From prarit at redhat.com Thu Mar 29 15:29:21 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 29 Mar 2007 11:29:21 -0400 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild Message-ID: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> Currently, rpmbuild -bp kernel-2.6.spec does /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/sparse-0.2.tar.bz2 tar -xvvf - which displays the directory of what has been untarred: drwxrwxrwx git/git 0 2006-12-05 06:22:44 sparse-0.2/ (snip 123 lines) I'm not sure if the full directory listing of sparse is needed. If it isn't, then let's clean it up. Resolves BZ 234473. Signed-off-by: Prarit Bhargava --- kernel-2.6.spec.orig 2007-03-29 06:04:13.000000000 -0400 +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 @@ -1219,7 +1219,7 @@ # unpack sparse. if [ ! -d sparse-%{sparsever} ] ; then -%setup -T -D -a 3 -q +%setup -D -T -q -a3 fi # Unpack the Xen tarball. From eparis at redhat.com Thu Mar 29 16:21:08 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 29 Mar 2007 12:21:08 -0400 Subject: Enable SECURITY_NETWORK_XFRM Message-ID: <1175185268.16700.43.camel@localhost.localdomain> Right before FC6 we turned off CONFIG_SECURITY_NETWORK_XFRM since there was a lot of development still going on in that areas especially concerning secid reconciliation between that and secmark. The reconciliation work was killed upstream and XFRM labeling has been worked on upstream and has been tested by the LSPP group for quite some time now with success. I'd like to get both of them turned back on so Fedora users can make use of xfrm labeled networking. -Eric From eparis at redhat.com Thu Mar 29 16:27:00 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 29 Mar 2007 12:27:00 -0400 Subject: Enable SECURITY_NETWORK_XFRM In-Reply-To: <1175185268.16700.43.camel@localhost.localdomain> References: <1175185268.16700.43.camel@localhost.localdomain> Message-ID: <1175185620.16700.44.camel@localhost.localdomain> On Thu, 2007-03-29 at 12:21 -0400, Eric Paris wrote: > Right before FC6 we turned off CONFIG_SECURITY_NETWORK_XFRM since there > was a lot of development still going on in that areas especially > concerning secid reconciliation between that and secmark. The > reconciliation work was killed upstream and XFRM labeling has been > worked on upstream and has been tested by the LSPP group for quite some > time now with success. > > I'd like to get both of them turned back on so Fedora users can make use > of xfrm labeled networking. s/both of them/CONFIG_SECURITY_NETWORK_XFRM/ From cebbert at redhat.com Thu Mar 29 17:08:30 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 13:08:30 -0400 Subject: Enable SECURITY_NETWORK_XFRM In-Reply-To: <1175185268.16700.43.camel@localhost.localdomain> References: <1175185268.16700.43.camel@localhost.localdomain> Message-ID: <460BF28E.8050709@redhat.com> Eric Paris wrote: > Right before FC6 we turned off CONFIG_SECURITY_NETWORK_XFRM since there > was a lot of development still going on in that areas especially > concerning secid reconciliation between that and secmark. The > reconciliation work was killed upstream and XFRM labeling has been > worked on upstream and has been tested by the LSPP group for quite some > time now with success. > > I'd like to get both of them turned back on so Fedora users can make use > of xfrm labeled networking. Did you want that on in FC6 as well as FC7/devel? From zaitcev at redhat.com Thu Mar 29 17:25:02 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 29 Mar 2007 10:25:02 -0700 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> Message-ID: <20070329102502.2943b922.zaitcev@redhat.com> On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 > @@ -1219,7 +1219,7 @@ > > # unpack sparse. > if [ ! -d sparse-%{sparsever} ] ; then > -%setup -T -D -a 3 -q > +%setup -D -T -q -a3 > fi This looks nice and to the point. However, it would be great if someone just added the sparse package to Fedora and the we'd have BuildRequires instead of monkeying with it on every build. It already takes several hours on my 3GHz Pentium D. -- Pete From j.w.r.degoede at hhs.nl Thu Mar 29 17:50:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Mar 2007 19:50:55 +0200 Subject: Crazy idea Message-ID: <460BFC7F.10908@hhs.nl> Hi all, Reading the thread about adding support to the kernel spec file to build a vanilla kernel, I had this crazy (really crazy) idea: Wouldn't it be great to share one kernel package or atleast one kernel source (as in pristine source + patches) between different distro's? The kernel is a _very_ important and complicated piece of software, which requires many many eyes, I'm sure that many kernel bugs are hitting more then one distro, and some are fixed with distro specific patches in one distro, but not in the next. So in an ideal word all distro's would have one kernel with a team made of the current maintainers from all distros working on it. I know this is impossible taking the different rate of changes between distro's but maybe ubuntu + suse? + Fedora could use a common kernel source? I know this is a really long shot, but if we could pull it off it would be really great. As said a really crazy (as in probably undoable) idea. So if not this, then what can be done to work better together on the kernel side of distro's, maybe a distro-kernel-maintainers-list at kernel.org? And maybe also a common bugzilla? Call me crazy but I think a lot could be gained here. Regards, Hans From jwilson at redhat.com Thu Mar 29 17:35:46 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 13:35:46 -0400 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <20070329102502.2943b922.zaitcev@redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> <20070329102502.2943b922.zaitcev@redhat.com> Message-ID: <460BF8F2.60005@redhat.com> Pete Zaitcev wrote: > On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > >> +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 >> @@ -1219,7 +1219,7 @@ >> >> # unpack sparse. >> if [ ! -d sparse-%{sparsever} ] ; then >> -%setup -T -D -a 3 -q >> +%setup -D -T -q -a3 >> fi > > This looks nice and to the point. > > However, it would be great if someone just added the sparse package > to Fedora and the we'd have BuildRequires instead of monkeying with > it on every build. It already takes several hours on my 3GHz Pentium D. I can't recall if I heard what (if any) roadblocks there were to it being packaged in fedora, but if so desired, I'd be happy to take a crack at packaging it up. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Thu Mar 29 17:53:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Mar 2007 19:53:00 +0200 Subject: Chance of dynamic loading of alternate AML code getting in? Message-ID: <460BFCFC.7040103@hhs.nl> Hi all, AFAIK ubuntu includes a patch to allow dynamic loading of alternate AML code dumps, to work around bios ACPI bugs. I know BIOS's and the kernel ACPI code are getting betterm but for some laptops this is needed, any chance this could be included into the Fedora kernel? Also any chance of getting this included upstream? Regards, Hans From jcm at redhat.com Thu Mar 29 17:37:13 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 29 Mar 2007 13:37:13 -0400 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <20070329102502.2943b922.zaitcev@redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> <20070329102502.2943b922.zaitcev@redhat.com> Message-ID: <460BF949.8040100@redhat.com> Pete Zaitcev wrote: > On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > >> +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 >> @@ -1219,7 +1219,7 @@ >> >> # unpack sparse. >> if [ ! -d sparse-%{sparsever} ] ; then >> -%setup -T -D -a 3 -q >> +%setup -D -T -q -a3 >> fi > > This looks nice and to the point. > > However, it would be great if someone just added the sparse package > to Fedora and the we'd have BuildRequires instead of monkeying with > it on every build. It already takes several hours on my 3GHz Pentium D. Pete, I think Dave already mentioned that it *is* planned to add this to Fedora but he's just waiting on the merge status, I think? Jon. From cebbert at redhat.com Thu Mar 29 17:41:45 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 13:41:45 -0400 Subject: Needed: An easier way to build a subset of kernel packages Message-ID: <460BFA59.2030702@redhat.com> I was thinking about adding something like this to the .spec file at the beginning: %define allowup 1 %define allowsmp 1 %define allowpae 1 %define allowxen 1 %define allowdoc 1 %define allowdump 1 %define allowheaders 1 %define allowdebug 1 Then, after all the automatic enable/disable of various options is done, turn off everything that's not allowed. This would make it much easier to change what gets built. From davej at redhat.com Thu Mar 29 17:42:21 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 13:42:21 -0400 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <460BF949.8040100@redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> <20070329102502.2943b922.zaitcev@redhat.com> <460BF949.8040100@redhat.com> Message-ID: <20070329174221.GC32707@redhat.com> On Thu, Mar 29, 2007 at 01:37:13PM -0400, Jon Masters wrote: > Pete Zaitcev wrote: > > On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > > > >> +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 > >> @@ -1219,7 +1219,7 @@ > >> > >> # unpack sparse. > >> if [ ! -d sparse-%{sparsever} ] ; then > >> -%setup -T -D -a 3 -q > >> +%setup -D -T -q -a3 > >> fi > > > > This looks nice and to the point. > > > > However, it would be great if someone just added the sparse package > > to Fedora and the we'd have BuildRequires instead of monkeying with > > it on every build. It already takes several hours on my 3GHz Pentium D. > > Pete, > > I think Dave already mentioned that it *is* planned to add this to > Fedora but he's just waiting on the merge status, I think? Right. iirc, Matt Domsch has it packaged for extras already. But core packages right now can't depend on extras packages to build. Once the core/extras merge is complete, all this stuff goes away, and just becomes another BuildRequires: Dave -- http://www.codemonkey.org.uk From jcm at redhat.com Thu Mar 29 17:46:44 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 29 Mar 2007 13:46:44 -0400 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <20070329174221.GC32707@redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> <20070329102502.2943b922.zaitcev@redhat.com> <460BF949.8040100@redhat.com> <20070329174221.GC32707@redhat.com> Message-ID: <460BFB84.7000706@redhat.com> Dave Jones wrote: > On Thu, Mar 29, 2007 at 01:37:13PM -0400, Jon Masters wrote: > > Pete Zaitcev wrote: > > > On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > > > > > >> +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 > > >> @@ -1219,7 +1219,7 @@ > > >> > > >> # unpack sparse. > > >> if [ ! -d sparse-%{sparsever} ] ; then > > >> -%setup -T -D -a 3 -q > > >> +%setup -D -T -q -a3 > > >> fi > > > > > > This looks nice and to the point. > > > > > > However, it would be great if someone just added the sparse package > > > to Fedora and the we'd have BuildRequires instead of monkeying with > > > it on every build. It already takes several hours on my 3GHz Pentium D. > > > > Pete, > > > > I think Dave already mentioned that it *is* planned to add this to > > Fedora but he's just waiting on the merge status, I think? > > Right. iirc, Matt Domsch has it packaged for extras already. > But core packages right now can't depend on extras packages to build. > Once the core/extras merge is complete, all this stuff goes > away, and just becomes another BuildRequires: And on that blissful day...we're drinking pints! :-) Jon. From davej at redhat.com Thu Mar 29 17:48:27 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 13:48:27 -0400 Subject: Crazy idea In-Reply-To: <460BFC7F.10908@hhs.nl> References: <460BFC7F.10908@hhs.nl> Message-ID: <20070329174827.GD32707@redhat.com> On Thu, Mar 29, 2007 at 07:50:55PM +0200, Hans de Goede wrote: > Hi all, > > Reading the thread about adding support to the kernel spec file to build a > vanilla kernel, I had this crazy (really crazy) idea: > > Wouldn't it be great to share one kernel package or atleast one kernel source > (as in pristine source + patches) between different distro's? > > The kernel is a _very_ important and complicated piece of software, which > requires many many eyes, I'm sure that many kernel bugs are hitting more then > one distro, and some are fixed with distro specific patches in one distro, but > not in the next. > > So in an ideal word all distro's would have one kernel with a team made of the > current maintainers from all distros working on it. I know this is impossible > taking the different rate of changes between distro's but maybe ubuntu + suse? > + Fedora could use a common kernel source? Not completely infeasible. Though there are differences in the choice of CONFIG_ options between distros too. Eg, Ubuntu are the only people loopy enough to enable CONFIG_PREEMPT. Other distros might need to enable some backward compatibility options because their userspace isn't up to date, etc, etc. The actual patches we carry are rarely the cause the problems that get reported. It's fairly uncommon for us to change drivers other than perhaps the occasional compile fix which usually goes upstream quickly. Yet that's by far where most of the bugs that get reported are against. Pretty much every time someone who files a Fedora kernel bug who then builds their own vanilla kernel and it 'works', it's because they chose different CONFIG options rather than the fact that it's vanilla. > As said a really crazy (as in probably undoable) idea. So if not this, then > what can be done to work better together on the kernel side of distro's, maybe > a distro-kernel-maintainers-list at kernel.org? There is actually a kernel-packagers@ list already there, but it's really low traffic. > And maybe also a common bugzilla? http://bugme.osdl.org :-) Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Mar 29 17:50:16 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 13:50:16 -0400 Subject: Chance of dynamic loading of alternate AML code getting in? In-Reply-To: <460BFCFC.7040103@hhs.nl> References: <460BFCFC.7040103@hhs.nl> Message-ID: <20070329175016.GE32707@redhat.com> On Thu, Mar 29, 2007 at 07:53:00PM +0200, Hans de Goede wrote: > Hi all, > > AFAIK ubuntu includes a patch to allow dynamic loading of alternate AML code > dumps, to work around bios ACPI bugs. I know BIOS's and the kernel ACPI code > are getting betterm but for some laptops this is needed, any chance this could > be included into the Fedora kernel? > > Also any chance of getting this included upstream? The Intel ACPI maintainers are really against including that patch, and express dismay that other vendors that do include it. >From conversation I've had with LenB, he's pretty happy that we don't include it. Keeping the upstream maintainers happy so that they're interested in looking at our bugs is far more useful in the long run imo. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Thu Mar 29 17:51:20 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 13:51:20 -0400 Subject: Crazy idea In-Reply-To: <20070329174827.GD32707@redhat.com> References: <460BFC7F.10908@hhs.nl> <20070329174827.GD32707@redhat.com> Message-ID: <460BFC98.6010405@redhat.com> Dave Jones wrote: > > The actual patches we carry are rarely the cause the problems that get reported. > It's fairly uncommon for us to change drivers other than perhaps the > occasional compile fix which usually goes upstream quickly. Yet that's > by far where most of the bugs that get reported are against. > > Pretty much every time someone who files a Fedora kernel bug who then > builds their own vanilla kernel and it 'works', it's because they > chose different CONFIG options rather than the fact that it's vanilla. > I think the best solution short-term is to try and get as much into the -stable kernel as possible. That way most distro kernels automatically become more similar. From davej at redhat.com Thu Mar 29 17:51:48 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 13:51:48 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460BFA59.2030702@redhat.com> References: <460BFA59.2030702@redhat.com> Message-ID: <20070329175148.GF32707@redhat.com> On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: > I was thinking about adding something like this to the .spec file > at the beginning: > > %define allowup 1 > %define allowsmp 1 > %define allowpae 1 > %define allowxen 1 > %define allowdoc 1 > %define allowdump 1 > %define allowheaders 1 > %define allowdebug 1 > > Then, after all the automatic enable/disable of various options is done, > turn off everything that's not allowed. > > This would make it much easier to change what gets built. The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read. Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :) Dave -- http://www.codemonkey.org.uk From jmorris at redhat.com Thu Mar 29 16:35:05 2007 From: jmorris at redhat.com (James Morris) Date: Thu, 29 Mar 2007 12:35:05 -0400 (EDT) Subject: Enable SECURITY_NETWORK_XFRM In-Reply-To: <1175185268.16700.43.camel@localhost.localdomain> Message-ID: On Thu, 29 Mar 2007, Eric Paris wrote: > Right before FC6 we turned off CONFIG_SECURITY_NETWORK_XFRM since there > was a lot of development still going on in that areas especially > concerning secid reconciliation between that and secmark. The > reconciliation work was killed upstream and XFRM labeling has been > worked on upstream and has been tested by the LSPP group for quite some > time now with success. > > I'd like to get both of them turned back on so Fedora users can make use > of xfrm labeled networking. I definitely think it needs to be enabled, and I don't think it should impact any normal users (you need to specially configure ipsec for anything to happen). Do we have the userland patches for racoon etc. in Fedora ? - James -- James Morris From jwilson at redhat.com Thu Mar 29 18:06:58 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 14:06:58 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <20070329175148.GF32707@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> Message-ID: <460C0042.80507@redhat.com> Dave Jones wrote: > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: > > I was thinking about adding something like this to the .spec file > > at the beginning: > > > > %define allowup 1 > > %define allowsmp 1 > > %define allowpae 1 > > %define allowxen 1 > > %define allowdoc 1 > > %define allowdump 1 > > %define allowheaders 1 > > %define allowdebug 1 > > > > Then, after all the automatic enable/disable of various options is done, > > turn off everything that's not allowed. > > > > This would make it much easier to change what gets built. > > The amount of %define's we've grown recently does seem to be > getting out of hand. I'm not sure it's a good/bad thing, but it > does make the spec a little harder to read. > > Not sure about your proposal tbh. I'll think about it more > when I'm back from vacation :) I like it, at least in theory. Invariably, I'll do a test build, and to speed the process, I twiddle bits at the top of the spec to disable certain builds. In the i686 case, I almost always forget to hunt down lower to turn off pae. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwboyer at jdub.homelinux.org Thu Mar 29 18:11:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 29 Mar 2007 13:11:56 -0500 Subject: [Fedora PATCH]: BZ 234473 Remove sparse directory listing from kernel rpmbuild In-Reply-To: <460BFB84.7000706@redhat.com> References: <20070329152921.18742.35965.sendpatchset@prarit.boston.redhat.com> <20070329102502.2943b922.zaitcev@redhat.com> <460BF949.8040100@redhat.com> <20070329174221.GC32707@redhat.com> <460BFB84.7000706@redhat.com> Message-ID: <1175191916.7553.131.camel@zod.rchland.ibm.com> On Thu, 2007-03-29 at 13:46 -0400, Jon Masters wrote: > Dave Jones wrote: > > On Thu, Mar 29, 2007 at 01:37:13PM -0400, Jon Masters wrote: > > > Pete Zaitcev wrote: > > > > On Thu, 29 Mar 2007 11:29:21 -0400, Prarit Bhargava wrote: > > > > > > > >> +++ kernel-2.6.spec 2007-03-29 06:04:16.000000000 -0400 > > > >> @@ -1219,7 +1219,7 @@ > > > >> > > > >> # unpack sparse. > > > >> if [ ! -d sparse-%{sparsever} ] ; then > > > >> -%setup -T -D -a 3 -q > > > >> +%setup -D -T -q -a3 > > > >> fi > > > > > > > > This looks nice and to the point. > > > > > > > > However, it would be great if someone just added the sparse package > > > > to Fedora and the we'd have BuildRequires instead of monkeying with > > > > it on every build. It already takes several hours on my 3GHz Pentium D. > > > > > > Pete, > > > > > > I think Dave already mentioned that it *is* planned to add this to > > > Fedora but he's just waiting on the merge status, I think? > > > > Right. iirc, Matt Domsch has it packaged for extras already. > > But core packages right now can't depend on extras packages to build. > > Once the core/extras merge is complete, all this stuff goes > > away, and just becomes another BuildRequires: > > And on that blissful day...we're drinking pints! :-) Which kind? I vote for GB pints. They're bigger then our piddly 16oz US pints. josh From davej at redhat.com Thu Mar 29 18:14:33 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 14:14:33 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C0042.80507@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> Message-ID: <20070329181433.GJ32707@redhat.com> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote: > Dave Jones wrote: > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: > > > I was thinking about adding something like this to the .spec file > > > at the beginning: > > > > > > %define allowup 1 > > > %define allowsmp 1 > > > %define allowpae 1 > > > %define allowxen 1 > > > %define allowdoc 1 > > > %define allowdump 1 > > > %define allowheaders 1 > > > %define allowdebug 1 > > > > > > Then, after all the automatic enable/disable of various options is done, > > > turn off everything that's not allowed. > > > > > > This would make it much easier to change what gets built. > > > > The amount of %define's we've grown recently does seem to be > > getting out of hand. I'm not sure it's a good/bad thing, but it > > does make the spec a little harder to read. > > > > Not sure about your proposal tbh. I'll think about it more > > when I'm back from vacation :) > > I like it, at least in theory. Invariably, I'll do a test build, and to > speed the process, I twiddle bits at the top of the spec to disable > certain builds. In the i686 case, I almost always forget to hunt down > lower to turn off pae. I probably don't really notice, because my workflow for test builds is usually make prep cd kernel-2.6.20/linux-2.6.20.noarch cp configs/$whateverconfigIwant .config make oldconfig bzImage modules sudo make modules_install install But I've not objection to making it easier for people who don't follow my workflow and do things differently. Dave -- http://www.codemonkey.org.uk From j.w.r.degoede at hhs.nl Thu Mar 29 18:36:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Mar 2007 20:36:47 +0200 Subject: Crazy idea In-Reply-To: <20070329174827.GD32707@redhat.com> References: <460BFC7F.10908@hhs.nl> <20070329174827.GD32707@redhat.com> Message-ID: <460C073F.9080501@hhs.nl> Dave Jones wrote: > On Thu, Mar 29, 2007 at 07:50:55PM +0200, Hans de Goede wrote: > > > And maybe also a common bugzilla? > > http://bugme.osdl.org :-) > Would it be an idea to automaticly (cron job, whatever) forward kernel bugs there and to add tracking of the upstream bug to the Fedora bug? I know there are some pretty talented bugzilla xml-rpc hackers in FE, maybe they can script this up? Regards, Hans From davej at redhat.com Thu Mar 29 18:24:00 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 14:24:00 -0400 Subject: Crazy idea In-Reply-To: <460C073F.9080501@hhs.nl> References: <460BFC7F.10908@hhs.nl> <20070329174827.GD32707@redhat.com> <460C073F.9080501@hhs.nl> Message-ID: <20070329182400.GK32707@redhat.com> On Thu, Mar 29, 2007 at 08:36:47PM +0200, Hans de Goede wrote: > Dave Jones wrote: > > On Thu, Mar 29, 2007 at 07:50:55PM +0200, Hans de Goede wrote: > > > > > And maybe also a common bugzilla? > > > > http://bugme.osdl.org :-) > > > > Would it be an idea to automaticly (cron job, whatever) forward kernel bugs > there and to add tracking of the upstream bug to the Fedora bug? > > I know there are some pretty talented bugzilla xml-rpc hackers in FE, maybe > they can script this up? I'd love to have a tool which would slurp bugdata out of our bz and allow me to edit it if necessary, and then push a submit upstream button. The differences in schema between the two db's mean that either a thunking layer would be needed, or in some cases, manual intervention (which is why I'd want to be able to edit the submission). Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Mar 29 18:25:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Mar 2007 20:25:20 +0200 Subject: Chance of dynamic loading of alternate AML code getting in? In-Reply-To: <20070329175016.GE32707@redhat.com> References: <460BFCFC.7040103@hhs.nl> <20070329175016.GE32707@redhat.com> Message-ID: <460C0490.5090607@leemhuis.info> Dave Jones schrieb: > On Thu, Mar 29, 2007 at 07:53:00PM +0200, Hans de Goede wrote: > > Hi all, > > > > AFAIK ubuntu includes a patch to allow dynamic loading of alternate AML code > > dumps, to work around bios ACPI bugs. I know BIOS's and the kernel ACPI code > > are getting betterm but for some laptops this is needed, any chance this could > > be included into the Fedora kernel? > > > > Also any chance of getting this included upstream? > > The Intel ACPI maintainers are really against including that patch, > and express dismay that other vendors that do include it. > From conversation I've had with LenB, he's pretty happy that we don't > include it. Keeping the upstream maintainers happy so that they're > interested in looking at our bugs is far more useful in the long run imo. Agreed. I'd also got the impression from my testing that the ACPI interpreter *and/or* the ACPI tables in modern hardware is a lot better these days, so the need to include the patch is not that pressing anymore IMHO. But it might be nice to make it a bit more easy for people to somehow include a modified DST with the in-kernel-mechanism when they recompile the kernel srpm... Currently it's quite hard to do that afaics CU thl From jwboyer at jdub.homelinux.org Thu Mar 29 18:25:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 29 Mar 2007 13:25:39 -0500 Subject: Crazy idea In-Reply-To: <460C073F.9080501@hhs.nl> References: <460BFC7F.10908@hhs.nl> <20070329174827.GD32707@redhat.com> <460C073F.9080501@hhs.nl> Message-ID: <1175192739.7553.134.camel@zod.rchland.ibm.com> On Thu, 2007-03-29 at 20:36 +0200, Hans de Goede wrote: > Dave Jones wrote: > > On Thu, Mar 29, 2007 at 07:50:55PM +0200, Hans de Goede wrote: > > > > > And maybe also a common bugzilla? > > > > http://bugme.osdl.org :-) > > > > Would it be an idea to automaticly (cron job, whatever) forward kernel bugs > there and to add tracking of the upstream bug to the Fedora bug? Automatically, no. If there was a button or lever to muck with in bugzilla to do it once the bug had been found to actually be valid that might be worthwhile. Automatically mirroring bugs to kernel.org that turned out to be caused by someone using binary drivers would not be a good thing :). josh From zaitcev at redhat.com Thu Mar 29 18:32:11 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 29 Mar 2007 11:32:11 -0700 Subject: Longing for git-bisect In-Reply-To: <20070328005202.GA11618@redhat.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <20070328005202.GA11618@redhat.com> Message-ID: <20070329113211.0fbd7f94.zaitcev@redhat.com> On Tue, 27 Mar 2007 20:52:02 -0400, Dave Jones wrote: > Zaitcev had something that tracked the Fedora tree, but I never > found time to look at what he did. You mean this? http://git.fedoraproject.org/?p=kernel/zaitcev/linux-2.6-volk.git;a=summary I still have it, but the automation is defective, so it's pretty much a weekly snapshot rather than daily or by-commit. And since the Fedora's own history is not merged, it's useless anyway. Might as well download RPMs from /mnt/redhat/brewroot and bisect with them. Saves time on building too. If I solve the problem of history and get it running hands-off, maybe then... -- Pete From jwilson at redhat.com Thu Mar 29 18:36:22 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 14:36:22 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <20070329181433.GJ32707@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> Message-ID: <460C0726.6050908@redhat.com> Dave Jones wrote: > On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote: > > Dave Jones wrote: > > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: > > > > I was thinking about adding something like this to the .spec file > > > > at the beginning: > > > > > > > > %define allowup 1 > > > > %define allowsmp 1 > > > > %define allowpae 1 > > > > %define allowxen 1 > > > > %define allowdoc 1 > > > > %define allowdump 1 > > > > %define allowheaders 1 > > > > %define allowdebug 1 > > > > > > > > Then, after all the automatic enable/disable of various options is done, > > > > turn off everything that's not allowed. > > > > > > > > This would make it much easier to change what gets built. > > > > > > The amount of %define's we've grown recently does seem to be > > > getting out of hand. I'm not sure it's a good/bad thing, but it > > > does make the spec a little harder to read. > > > > > > Not sure about your proposal tbh. I'll think about it more > > > when I'm back from vacation :) > > > > I like it, at least in theory. Invariably, I'll do a test build, and to > > speed the process, I twiddle bits at the top of the spec to disable > > certain builds. In the i686 case, I almost always forget to hunt down > > lower to turn off pae. > > I probably don't really notice, because my workflow for test builds is usually > make prep > cd kernel-2.6.20/linux-2.6.20.noarch > cp configs/$whateverconfigIwant .config > make oldconfig bzImage modules > sudo make modules_install install > > But I've not objection to making it easier for people who don't follow > my workflow and do things differently. Rather than wasting Chuck's time implementing this, what say a lower-level grunt like myself try to implement something along these lines? :) I've got a few ideas on how to do it using either %bcond or %with{,out}... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Thu Mar 29 18:52:50 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 14:52:50 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C0726.6050908@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> Message-ID: <460C0B02.2050507@redhat.com> Jarod Wilson wrote: > Dave Jones wrote: >> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote: >> > Dave Jones wrote: >> > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: >> > > > I was thinking about adding something like this to the .spec file >> > > > at the beginning: >> > > > >> > > > %define allowup 1 >> > > > %define allowsmp 1 >> > > > %define allowpae 1 >> > > > %define allowxen 1 >> > > > %define allowdoc 1 >> > > > %define allowdump 1 >> > > > %define allowheaders 1 >> > > > %define allowdebug 1 >> > > > >> > > > Then, after all the automatic enable/disable of various options is done, >> > > > turn off everything that's not allowed. >> > > > >> > > > This would make it much easier to change what gets built. >> > > >> > > The amount of %define's we've grown recently does seem to be >> > > getting out of hand. I'm not sure it's a good/bad thing, but it >> > > does make the spec a little harder to read. >> > > >> > > Not sure about your proposal tbh. I'll think about it more >> > > when I'm back from vacation :) >> > >> > I like it, at least in theory. Invariably, I'll do a test build, and to >> > speed the process, I twiddle bits at the top of the spec to disable >> > certain builds. In the i686 case, I almost always forget to hunt down >> > lower to turn off pae. >> >> >> But I've not objection to making it easier for people who don't follow >> my workflow and do things differently. > > Rather than wasting Chuck's time implementing this, what say a > lower-level grunt like myself try to implement something along these > lines? :) I've got a few ideas on how to do it using either %bcond or > %with{,out}... > You understand rpm better than I do, so go for it. I'd use Dave's method but an RPM is so much more convenient... From jwilson at redhat.com Thu Mar 29 18:56:55 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 14:56:55 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C0B02.2050507@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> Message-ID: <460C0BF7.2000801@redhat.com> Chuck Ebbert wrote: > Jarod Wilson wrote: >> Dave Jones wrote: >>> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote: >>> > Dave Jones wrote: >>> > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: >>> > > > I was thinking about adding something like this to the .spec file >>> > > > at the beginning: >>> > > > >>> > > > %define allowup 1 >>> > > > %define allowsmp 1 >>> > > > %define allowpae 1 >>> > > > %define allowxen 1 >>> > > > %define allowdoc 1 >>> > > > %define allowdump 1 >>> > > > %define allowheaders 1 >>> > > > %define allowdebug 1 >>> > > > >>> > > > Then, after all the automatic enable/disable of various options is done, >>> > > > turn off everything that's not allowed. >>> > > > >>> > > > This would make it much easier to change what gets built. [...] >>> But I've not objection to making it easier for people who don't follow >>> my workflow and do things differently. >> >> Rather than wasting Chuck's time implementing this, what say a >> lower-level grunt like myself try to implement something along these >> lines? :) I've got a few ideas on how to do it using either %bcond or >> %with{,out}... > > You understand rpm better than I do, so go for it. I'd use Dave's method > but an RPM is so much more convenient... Cool, I'm on it... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From eparis at redhat.com Thu Mar 29 19:18:47 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 29 Mar 2007 15:18:47 -0400 Subject: Enable SECURITY_NETWORK_XFRM In-Reply-To: References: Message-ID: <1175195927.16700.58.camel@localhost.localdomain> On Thu, 2007-03-29 at 12:35 -0400, James Morris wrote: > On Thu, 29 Mar 2007, Eric Paris wrote: > > > Right before FC6 we turned off CONFIG_SECURITY_NETWORK_XFRM since there > > was a lot of development still going on in that areas especially > > concerning secid reconciliation between that and secmark. The > > reconciliation work was killed upstream and XFRM labeling has been > > worked on upstream and has been tested by the LSPP group for quite some > > time now with success. > > > > I'd like to get both of them turned back on so Fedora users can make use > > of xfrm labeled networking. > > I definitely think it needs to be enabled, and I don't think it should > impact any normal users (you need to specially configure ipsec for > anything to happen). > > Do we have the userland patches for racoon etc. in Fedora ? I just checked and the rawhide ipsec tools appear to have all of the patches the could be needed for labeled net to work. I see no reason this couldn't be turned on in both FC6 and devel. -Eric From jwilson at redhat.com Thu Mar 29 19:21:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 15:21:32 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C0BF7.2000801@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> Message-ID: <460C11BC.6020100@redhat.com> Jarod Wilson wrote: > Chuck Ebbert wrote: >> Jarod Wilson wrote: >>> Dave Jones wrote: >>>> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote: >>>> > Dave Jones wrote: >>>> > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote: >>>> > > > I was thinking about adding something like this to the .spec file >>>> > > > at the beginning: >>>> > > > >>>> > > > %define allowup 1 >>>> > > > %define allowsmp 1 >>>> > > > %define allowpae 1 >>>> > > > %define allowxen 1 >>>> > > > %define allowdoc 1 >>>> > > > %define allowdump 1 >>>> > > > %define allowheaders 1 >>>> > > > %define allowdebug 1 >>>> > > > >>>> > > > Then, after all the automatic enable/disable of various options is done, >>>> > > > turn off everything that's not allowed. >>>> > > > >>>> > > > This would make it much easier to change what gets built. > [...] >>>> But I've not objection to making it easier for people who don't follow >>>> my workflow and do things differently. >>> Rather than wasting Chuck's time implementing this, what say a >>> lower-level grunt like myself try to implement something along these >>> lines? :) I've got a few ideas on how to do it using either %bcond or >>> %with{,out}... >> You understand rpm better than I do, so go for it. I'd use Dave's method >> but an RPM is so much more convenient... > > Cool, I'm on it... There are a few ways to approach this... The minimalist approach that comes to mind is to make all the %define build* bits all set to 1/enabled by default, and only flip them to disabled where appropriate, so they'd be equivalent to your allow* idea, in that if you disable them at the top of the spec, they'd stay disabled. The all-out approach is to implement support for --with/--without on the rpmbuild line. Nice to have, but adds complexity/legibility issues to the spec (not that this isn't already a very hard to read spec...), and I'm not sure if I'd actually use it or not. Any strong preference for one route or the other? (Or yet another) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Thu Mar 29 19:28:26 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 15:28:26 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C11BC.6020100@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> Message-ID: <460C135A.6090401@redhat.com> Jarod Wilson wrote: > > The minimalist approach that comes to mind is to make all the %define > build* bits all set to 1/enabled by default, and only flip them to > disabled where appropriate, so they'd be equivalent to your allow* idea, > in that if you disable them at the top of the spec, they'd stay disabled. > I like this; right now there are surprises there for the unwary who think they can disable things that way. From eparis at redhat.com Thu Mar 29 19:28:46 2007 From: eparis at redhat.com (Eric Paris) Date: Thu, 29 Mar 2007 15:28:46 -0400 Subject: turn CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT on Message-ID: <1175196526.16700.65.camel@localhost.localdomain> So after a little discussion with the SELinux folks it looks like we want to turn this option on in FC7 as well. This should not be changed for old fedora releases. This option will enable secmark by default instead of the legacy network hooks for selinux. It should reduce the selinux overhead on network traffic drastically. Few if any people actually use the old network checks, but if someone is using them they are still available (though a /selinux tunable called 'compat_net') I believe the necessary bits to make use of secmark exist in the iptables packages shipped in rawhide. RHEL 5 shipped with this enabled and since most people don't use it anyway (even people who leave selinux on) all this will do is drop their overhead. -Eric From cebbert at redhat.com Thu Mar 29 20:16:26 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 16:16:26 -0400 Subject: Qlogic firmware isn't in the FC7 kernel Message-ID: <460C1E9A.1060603@redhat.com> Apparently the qlogic drivers don't have any firmware included in FC7, so nobody can actually use a qlogic adapter. Should we be patching the kernel like in FC6 or do we need a separate package? Or maybe the firmware goes in the kernel package? Peter says the support for Anaconda / mkinitrd to load the firmware is already written, so we could do it either way. From roland at redhat.com Thu Mar 29 20:24:44 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 29 Mar 2007 13:24:44 -0700 (PDT) Subject: Crazy idea In-Reply-To: Dave Jones's message of Thursday, 29 March 2007 14:24:00 -0400 <20070329182400.GK32707@redhat.com> Message-ID: <20070329202444.3D3A71801C4@magilla.sf.frob.com> > I'd love to have a tool which would slurp bugdata out of our bz and > allow me to edit it if necessary, and then push a submit upstream button. dkl is long on notice of how snazzy this would be, for sourceware bugzilla, gnome bugzilla, etc, etc. It was always "after bugzilla infrastructure upgrades, blah, blah, far in the future" before. Maybe the future is sooner now. From jwboyer at jdub.homelinux.org Thu Mar 29 20:46:29 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 29 Mar 2007 15:46:29 -0500 Subject: Qlogic firmware isn't in the FC7 kernel In-Reply-To: <460C1E9A.1060603@redhat.com> References: <460C1E9A.1060603@redhat.com> Message-ID: <1175201190.7553.145.camel@zod.rchland.ibm.com> On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote: > Apparently the qlogic drivers don't have any firmware included in FC7, > so nobody can actually use a qlogic adapter. Should we be patching the > kernel like in FC6 or do we need a separate package? Or maybe the > firmware goes in the kernel package? > > Peter says the support for Anaconda / mkinitrd to load the firmware > is already written, so we could do it either way. If it fits these guidelines: http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware We should probably do it in a separate package as described here: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html so qlogic-firmware or some such. josh From jcm at redhat.com Thu Mar 29 21:04:52 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 29 Mar 2007 17:04:52 -0400 Subject: Qlogic firmware isn't in the FC7 kernel In-Reply-To: <460C1E9A.1060603@redhat.com> References: <460C1E9A.1060603@redhat.com> Message-ID: <460C29F4.8020400@redhat.com> Chuck Ebbert wrote: > Apparently the qlogic drivers don't have any firmware included in FC7, > so nobody can actually use a qlogic adapter. Should we be patching the > kernel like in FC6 or do we need a separate package? Or maybe the > firmware goes in the kernel package? I personally prefer for it to go into an external package that we ask Andrew Vasquez at Qlogic to maintain post-merge, but for now I think it belongs in the kernel package proper. Dave? > Peter says the support for Anaconda / mkinitrd to load the firmware > is already written, so we could do it either way. Yeah. I've been a complete ass and misunderstood how some of the firmware loading implementation works - just went and looked at this code too, can see it's all already in there actually (in nash). Jon. From jcm at redhat.com Thu Mar 29 21:06:38 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 29 Mar 2007 17:06:38 -0400 Subject: Qlogic firmware isn't in the FC7 kernel In-Reply-To: <1175201190.7553.145.camel@zod.rchland.ibm.com> References: <460C1E9A.1060603@redhat.com> <1175201190.7553.145.camel@zod.rchland.ibm.com> Message-ID: <460C2A5E.2060803@redhat.com> Josh Boyer wrote: > On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote: >> Apparently the qlogic drivers don't have any firmware included in FC7, >> so nobody can actually use a qlogic adapter. Should we be patching the >> kernel like in FC6 or do we need a separate package? Or maybe the >> firmware goes in the kernel package? >> >> Peter says the support for Anaconda / mkinitrd to load the firmware >> is already written, so we could do it either way. > > If it fits these guidelines: > http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware Yeah. I saw those. But the problem is that this might be needed in the bootpath. We /probably/ don't want the kernel package depending on a billion of these other packages for the moment - do we? Wouldn't it just be easier to have the firmware in that package for now, since it used to be in the kernel anyway? Eventually we need to fix this differently. Jon. From clintonlee.taylor at gmail.com Thu Mar 29 21:24:13 2007 From: clintonlee.taylor at gmail.com (Clinton Lee Taylor) Date: Thu, 29 Mar 2007 23:24:13 +0200 Subject: rpms for vanilla kernel builds ... Message-ID: Greetings ... I for one would like to vote for rpms of vanilla kernel build! I have an Adaptec ASR-3410S, which is an i2o device, but since 2.6.18-1.2869.fc6, I can't use it and the i2o maintaner suggests I try a vanilla kernel build to see if it's an FC kernel problem or a general problem, but I don't have the skill to build a bootable kernel, let alone give good debug info. Thanks Mailed Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Thu Mar 29 21:28:57 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 29 Mar 2007 17:28:57 -0400 Subject: rpms for vanilla kernel builds ... In-Reply-To: References: Message-ID: <460C2F99.1080503@redhat.com> Clinton Lee Taylor wrote: > Greetings ... > > I for one would like to vote for rpms of vanilla kernel build! > > I have an Adaptec ASR-3410S, which is an i2o device, but since > 2.6.18-1.2869.fc6, I can't use it and the i2o maintaner suggests I try a > vanilla kernel build to see if it's an FC kernel problem or a general > problem, but I don't have the skill to build a bootable kernel, let alone > give good debug info. That problem is fixed by this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d1985ad1da28eac507d855af8099f6010c51b167 And the fix will be in the next update. From clintonlee.taylor at gmail.com Thu Mar 29 21:34:26 2007 From: clintonlee.taylor at gmail.com (Clinton Lee Taylor) Date: Thu, 29 Mar 2007 23:34:26 +0200 Subject: rpms for vanilla kernel builds ... In-Reply-To: <460C2F99.1080503@redhat.com> References: <460C2F99.1080503@redhat.com> Message-ID: On 29/03/07, Chuck Ebbert wrote: > > Clinton Lee Taylor wrote: > > Greetings ... > > > > I for one would like to vote for rpms of vanilla kernel build! > > > > I have an Adaptec ASR-3410S, which is an i2o device, but since > > 2.6.18-1.2869.fc6, I can't use it and the i2o maintaner suggests I try a > > vanilla kernel build to see if it's an FC kernel problem or a general > > problem, but I don't have the skill to build a bootable kernel, let > alone > > give good debug info. > > That problem is fixed by this: > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d1985ad1da28eac507d855af8099f6010c51b167 > > And the fix will be in the next update. Most excellent, thanks. Will be looking at for this ... BZ 231250 should be able to be closed now ... I was just in there looking for the BZ to add my two cents. Thanks again Mailed Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Fri Mar 30 02:46:11 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Mar 2007 22:46:11 -0400 Subject: Crazy idea In-Reply-To: <20070329202444.3D3A71801C4@magilla.sf.frob.com> References: <20070329182400.GK32707@redhat.com> <20070329202444.3D3A71801C4@magilla.sf.frob.com> Message-ID: <20070330024611.GA29653@redhat.com> On Thu, Mar 29, 2007 at 01:24:44PM -0700, Roland McGrath wrote: > > I'd love to have a tool which would slurp bugdata out of our bz and > > allow me to edit it if necessary, and then push a submit upstream button. > > dkl is long on notice of how snazzy this would be, for sourceware bugzilla, > gnome bugzilla, etc, etc. It was always "after bugzilla infrastructure > upgrades, blah, blah, far in the future" before. Maybe the future is > sooner now. Also, I miss bugzuki. That thing had promise. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Fri Mar 30 05:26:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 30 Mar 2007 01:26:48 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C135A.6090401@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> Message-ID: <460C9F98.4000707@redhat.com> Chuck Ebbert wrote: > Jarod Wilson wrote: > >> The minimalist approach that comes to mind is to make all the %define >> build* bits all set to 1/enabled by default, and only flip them to >> disabled where appropriate, so they'd be equivalent to your allow* idea, >> in that if you disable them at the top of the spec, they'd stay disabled. >> >> > > I like this; right now there are surprises there for the unwary who > think they can disable things that way. > I've implemented enabling/disabling certain builds at the very top of the spec file, and anything you set to not build at the top will NOT be turned back on later by an ifarch/ifnarch/etc -- all those have been modified such that they only disable things compared with the defaults set at the top. Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec: $ rpmbuild -bb --without xen --without kdump --without debug kernel-2.6.spec [...] Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498 + umask 022 + cd /data/buildroot/BUILD + cd kernel-2.6.20 + rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root + exit 0 Results are exactly as expected/desired. Similar results have been observed on an i686 build. Here's another thought... Would be simple enough to add one more flag, along the lines of "--without flavo{,u}rs" that automagically flipped off everything but the base kernel build (+debuginfo, devel and headers). That's actually likely to be the thing folks would most commonly want to do. Worth adding? Still touching up a few things, but should have this completely presentable before lunch tomorrow... -- Jarod Wilson jwilson at redhat.com From jeff at ocjtech.us Fri Mar 30 06:18:02 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 30 Mar 2007 01:18:02 -0500 Subject: Longing for git-bisect In-Reply-To: <20070329113211.0fbd7f94.zaitcev@redhat.com> References: <1175042513.2977.90.camel@vader.jdub.homelinux.org> <20070328005202.GA11618@redhat.com> <20070329113211.0fbd7f94.zaitcev@redhat.com> Message-ID: <1175235483.5608.21.camel@lt21223.campus.dmacc.edu> On Thu, 2007-03-29 at 11:32 -0700, Pete Zaitcev wrote: > On Tue, 27 Mar 2007 20:52:02 -0400, Dave Jones wrote: > > > Zaitcev had something that tracked the Fedora tree, but I never > > found time to look at what he did. > > You mean this? > http://git.fedoraproject.org/?p=kernel/zaitcev/linux-2.6-volk.git;a=summary > > I still have it, but the automation is defective, so it's pretty > much a weekly snapshot rather than daily or by-commit. And since > the Fedora's own history is not merged, it's useless anyway. > Might as well download RPMs from /mnt/redhat/brewroot and > bisect with them. Saves time on building too. > > If I solve the problem of history and get it running hands-off, > maybe then... Although it's probably not what either of you wanted, I have a Git repository with the devel branch of the kernel rpm from CVS imported into it here: http://git.ocjtech.us/fedora-kernel-cvs.git Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cebbert at redhat.com Fri Mar 30 13:59:06 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 09:59:06 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C9F98.4000707@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> Message-ID: <460D17AA.3030109@redhat.com> Jarod Wilson wrote: > Chuck Ebbert wrote: >> Jarod Wilson wrote: >> >>> The minimalist approach that comes to mind is to make all the %define >>> build* bits all set to 1/enabled by default, and only flip them to >>> disabled where appropriate, so they'd be equivalent to your allow* idea, >>> in that if you disable them at the top of the spec, they'd stay >>> disabled. >>> >>> >> >> I like this; right now there are surprises there for the unwary who >> think they can disable things that way. >> > > I've implemented enabling/disabling certain builds at the very top of > the spec file, and anything you set to not build at the top will NOT be > turned back on later by an ifarch/ifnarch/etc -- all those have been > modified such that they only disable things compared with the defaults > set at the top. > > Turns out the complexity of adding --with/--without support only > resulted in the on/off lines at the top of the spec being slightly > longer, so one can now additionally pass in, say, --without xen, on the > rpmbuild line to disable building a xen kernel. For example, here's the > results of a test build using the modified spec: > > $ rpmbuild -bb --without xen --without kdump --without debug > kernel-2.6.spec > [...] > Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm > Wrote: > /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm > Wrote: > /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm > > Wrote: > /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm > Wrote: > /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm > Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498 > + umask 022 > + cd /data/buildroot/BUILD > + cd kernel-2.6.20 > + rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root > + exit 0 > > Results are exactly as expected/desired. Similar results have been > observed on an i686 build. > > Here's another thought... Would be simple enough to add one more flag, > along the lines of "--without flavo{,u}rs" that automagically flipped > off everything but the base kernel build (+debuginfo, devel and > headers). That's actually likely to be the thing folks would most > commonly want to do. Worth adding? An option to do --with=up or --with=smp would be a nice addition if it's not too much added complexity. (That would build only 'up' or 'smp'.) From cebbert at redhat.com Fri Mar 30 15:00:12 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 11:00:12 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? Message-ID: <460D25FC.3030305@redhat.com> It seems like more and more problems with PCI MSI are turning up in the 2.6.20 kernel. Discussion upstream concluded that maybe it should have been off by default in 2.6.20, so maybe we should just do that in Fedora and make people who want it use "pci=msi" to enable it? It's probably not going to be really stable until 2.6.22... From jcm at redhat.com Fri Mar 30 15:17:40 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 30 Mar 2007 11:17:40 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D25FC.3030305@redhat.com> References: <460D25FC.3030305@redhat.com> Message-ID: <460D2A14.3070706@redhat.com> Chuck Ebbert wrote: > It seems like more and more problems with PCI MSI are turning up > in the 2.6.20 kernel. Discussion upstream concluded that maybe > it should have been off by default in 2.6.20, so maybe we should > just do that in Fedora and make people who want it use "pci=msi" > to enable it? It's probably not going to be really stable until > 2.6.22... Was "upstream discussion" Willy? Interesting. Jon. From jcliburn at gmail.com Fri Mar 30 15:18:18 2007 From: jcliburn at gmail.com (Jay Cliburn) Date: Fri, 30 Mar 2007 10:18:18 -0500 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D25FC.3030305@redhat.com> References: <460D25FC.3030305@redhat.com> Message-ID: <460D2A3A.2080402@gmail.com> Chuck Ebbert wrote: > It seems like more and more problems with PCI MSI are turning up > in the 2.6.20 kernel. Discussion upstream concluded that maybe > it should have been off by default in 2.6.20, so maybe we should > just do that in Fedora and make people who want it use "pci=msi" > to enable it? It's probably not going to be really stable until > 2.6.22... I vote yes: turn it off by default. We just ran into an MSI issue on a particular Via motherboard (Asus M2V) that runs the network driver (atl1) I help maintain. The kernel blows up when we start the network unless we turn off MSI. From jwilson at redhat.com Fri Mar 30 15:27:30 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 30 Mar 2007 11:27:30 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460D17AA.3030109@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> <460D17AA.3030109@redhat.com> Message-ID: <460D2C62.5040901@redhat.com> Chuck Ebbert wrote: > Jarod Wilson wrote: >> Chuck Ebbert wrote: >>> Jarod Wilson wrote: >>> >>>> The minimalist approach that comes to mind is to make all the %define >>>> build* bits all set to 1/enabled by default, and only flip them to >>>> disabled where appropriate, so they'd be equivalent to your allow* idea, >>>> in that if you disable them at the top of the spec, they'd stay >>>> disabled. >>>> >>>> >>> I like this; right now there are surprises there for the unwary who >>> think they can disable things that way. >>> >> I've implemented enabling/disabling certain builds at the very top of >> the spec file, and anything you set to not build at the top will NOT be >> turned back on later by an ifarch/ifnarch/etc -- all those have been >> modified such that they only disable things compared with the defaults >> set at the top. >> >> Turns out the complexity of adding --with/--without support only >> resulted in the on/off lines at the top of the spec being slightly >> longer, so one can now additionally pass in, say, --without xen, on the >> rpmbuild line to disable building a xen kernel. For example, here's the >> results of a test build using the modified spec: >> >> $ rpmbuild -bb --without xen --without kdump --without debug >> kernel-2.6.spec >> [...] >> Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm >> Wrote: >> /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm >> Wrote: >> /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm >> >> Wrote: >> /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm >> Wrote: >> /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm >> Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498 >> + umask 022 >> + cd /data/buildroot/BUILD >> + cd kernel-2.6.20 >> + rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root >> + exit 0 >> >> Results are exactly as expected/desired. Similar results have been >> observed on an i686 build. >> >> Here's another thought... Would be simple enough to add one more flag, >> along the lines of "--without flavo{,u}rs" that automagically flipped >> off everything but the base kernel build (+debuginfo, devel and >> headers). That's actually likely to be the thing folks would most >> commonly want to do. Worth adding? > > An option to do --with=up or --with=smp would be a nice addition if it's > not too much added complexity. (That would build only 'up' or 'smp'.) Done. All changes have been committed to the FC-6 kernel tree, as of build 1.2939. Next up, devel... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Fri Mar 30 17:15:28 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 13:15:28 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D2A3A.2080402@gmail.com> References: <460D25FC.3030305@redhat.com> <460D2A3A.2080402@gmail.com> Message-ID: <460D45B0.1090503@redhat.com> Jay Cliburn wrote: > Chuck Ebbert wrote: >> It seems like more and more problems with PCI MSI are turning up >> in the 2.6.20 kernel. Discussion upstream concluded that maybe >> it should have been off by default in 2.6.20, so maybe we should >> just do that in Fedora and make people who want it use "pci=msi" >> to enable it? It's probably not going to be really stable until >> 2.6.22... > > I vote yes: turn it off by default. We just ran into an MSI issue on a > particular Via motherboard (Asus M2V) that runs the network driver > (atl1) I help maintain. The kernel blows up when we start the network > unless we turn off MSI. One of our bug reporters points to a unbuntu thread where they mention they have just turned of msi by default. https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/74830 From cebbert at redhat.com Fri Mar 30 17:15:48 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 13:15:48 -0400 Subject: Qlogic firmware isn't in the FC7 kernel In-Reply-To: <460C2A5E.2060803@redhat.com> References: <460C1E9A.1060603@redhat.com> <1175201190.7553.145.camel@zod.rchland.ibm.com> <460C2A5E.2060803@redhat.com> Message-ID: <460D45C4.3090303@redhat.com> Jon Masters wrote: > Josh Boyer wrote: >> On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote: >>> Apparently the qlogic drivers don't have any firmware included in FC7, >>> so nobody can actually use a qlogic adapter. Should we be patching the >>> kernel like in FC6 or do we need a separate package? Or maybe the >>> firmware goes in the kernel package? >>> >>> Peter says the support for Anaconda / mkinitrd to load the firmware >>> is already written, so we could do it either way. >> >> If it fits these guidelines: >> http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > Yeah. I saw those. But the problem is that this might be needed in the > bootpath. We /probably/ don't want the kernel package depending on a > billion of these other packages for the moment - do we? Wouldn't it just > be easier to have the firmware in that package for now, since it used to > be in the kernel anyway? Eventually we need to fix this differently. Hey, mkinitrd is required too and it's not part of the kernel package. After thinking about it, I vote for a separate package if it doesn't cause too much pain. From katzj at redhat.com Fri Mar 30 17:41:12 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Mar 2007 13:41:12 -0400 Subject: Qlogic firmware isn't in the FC7 kernel In-Reply-To: <460D45C4.3090303@redhat.com> References: <460C1E9A.1060603@redhat.com> <1175201190.7553.145.camel@zod.rchland.ibm.com> <460C2A5E.2060803@redhat.com> <460D45C4.3090303@redhat.com> Message-ID: <1175276472.12248.9.camel@erebor.boston.redhat.com> On Fri, 2007-03-30 at 13:15 -0400, Chuck Ebbert wrote: > Jon Masters wrote: > > Josh Boyer wrote: > >> On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote: > >>> Apparently the qlogic drivers don't have any firmware included in FC7, > >>> so nobody can actually use a qlogic adapter. Should we be patching the > >>> kernel like in FC6 or do we need a separate package? Or maybe the > >>> firmware goes in the kernel package? > >>> > >>> Peter says the support for Anaconda / mkinitrd to load the firmware > >>> is already written, so we could do it either way. > >> > >> If it fits these guidelines: > >> http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > > Yeah. I saw those. But the problem is that this might be needed in the > > bootpath. We /probably/ don't want the kernel package depending on a > > billion of these other packages for the moment - do we? Wouldn't it just > > be easier to have the firmware in that package for now, since it used to > > be in the kernel anyway? Eventually we need to fix this differently. > > Hey, mkinitrd is required too and it's not part of the kernel package. > After thinking about it, I vote for a separate package if it doesn't cause > too much pain. For fresh installs, it's not a big deal. We can stick the firmware package in the hardware support group which is installed by default and so people will usually be fine[1]. For upgrades, though, we have no indicator to tell yum/anaconda that this new package is needed for the hardware to be functional. Which means that people do an upgrade, the new package doesn't get installed and people are left with a non-functional system. Any answer for this kind of sucks as it's either something like a requires in the kernel package or a one-off hack :/ Jeremy [1] Eventually we probably need to do something to help ensure that you don't deselect it, but for the purposes of Fedora 7 we can probably get away with saying "don't do that" From zaitcev at redhat.com Fri Mar 30 17:49:53 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Mar 2007 10:49:53 -0700 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D25FC.3030305@redhat.com> References: <460D25FC.3030305@redhat.com> Message-ID: <20070330104953.4b7ce52a.zaitcev@redhat.com> On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert wrote: > It seems like more and more problems with PCI MSI are turning up > in the 2.6.20 kernel. Discussion upstream concluded that maybe > it should have been off by default in 2.6.20, so maybe we should > just do that in Fedora and make people who want it use "pci=msi" > to enable it? It's probably not going to be really stable until > 2.6.22... I have a laptop (Dell 1501) where hard drive does not work unless MSI is off. It's not hard to add pci=nomsi, and Grubby copies it to new kernel's command line, but the downside is, it took me a day to figure out what was wrong. It completely looked like a garden variety SATA failure. Maybe we want to keep it on in Rawhide and publicise "look at /proc/interrupts, check if count is zero"? -- Pete From cebbert at redhat.com Fri Mar 30 18:03:23 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 14:03:23 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <20070330104953.4b7ce52a.zaitcev@redhat.com> References: <460D25FC.3030305@redhat.com> <20070330104953.4b7ce52a.zaitcev@redhat.com> Message-ID: <460D50EB.5090209@redhat.com> Pete Zaitcev wrote: > On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert wrote: > >> It seems like more and more problems with PCI MSI are turning up >> in the 2.6.20 kernel. Discussion upstream concluded that maybe >> it should have been off by default in 2.6.20, so maybe we should >> just do that in Fedora and make people who want it use "pci=msi" >> to enable it? It's probably not going to be really stable until >> 2.6.22... > > I have a laptop (Dell 1501) where hard drive does not work unless MSI > is off. It's not hard to add pci=nomsi, and Grubby copies it to new > kernel's command line, but the downside is, it took me a day to figure > out what was wrong. It completely looked like a garden variety SATA > failure. Maybe we want to keep it on in Rawhide and publicise "look > at /proc/interrupts, check if count is zero"? I was thinking more about FC6 where people are upgrading to 2.6.20 and finding systems don't work that used to work. For FC7 it's debatable since MSI is mostly fixed in 2.6.21, but I think I will switch it off in FC6. From davej at redhat.com Fri Mar 30 18:21:22 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 30 Mar 2007 14:21:22 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D50EB.5090209@redhat.com> References: <460D25FC.3030305@redhat.com> <20070330104953.4b7ce52a.zaitcev@redhat.com> <460D50EB.5090209@redhat.com> Message-ID: <20070330182122.GC18649@redhat.com> On Fri, Mar 30, 2007 at 02:03:23PM -0400, Chuck Ebbert wrote: > Pete Zaitcev wrote: > > On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert wrote: > > > >> It seems like more and more problems with PCI MSI are turning up > >> in the 2.6.20 kernel. Discussion upstream concluded that maybe > >> it should have been off by default in 2.6.20, so maybe we should > >> just do that in Fedora and make people who want it use "pci=msi" > >> to enable it? It's probably not going to be really stable until > >> 2.6.22... > > > > I have a laptop (Dell 1501) where hard drive does not work unless MSI > > is off. It's not hard to add pci=nomsi, and Grubby copies it to new > > kernel's command line, but the downside is, it took me a day to figure > > out what was wrong. It completely looked like a garden variety SATA > > failure. Maybe we want to keep it on in Rawhide and publicise "look > > at /proc/interrupts, check if count is zero"? > > I was thinking more about FC6 where people are upgrading to 2.6.20 > and finding systems don't work that used to work. For FC7 it's > debatable since MSI is mostly fixed in 2.6.21, but I think I will > switch it off in FC6. Gets my vote too. I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times now for FC5/FC6, because each time it starts to look more promising, it seems to find new ways to regress. I might do a build next week in rawhide with it off again too, to see if any oddball bugs fall out. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Fri Mar 30 18:30:41 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 14:30:41 -0400 Subject: Something is changing the firmware loading timeout In-Reply-To: <460846DA.90702@redhat.com> References: <460845D1.1080705@redhat.com> <460846DA.90702@redhat.com> Message-ID: <460D5751.5010404@redhat.com> Chuck Ebbert wrote: > >> + printk(KERN_INFO >> + "firmware_class: attempt to set timeout to %d\n", >> + loading_timeout); This message triggered during boot, so something /was/ screwing with the timeout. Now it stays at 60 seconds like it should... From jwilson at redhat.com Fri Mar 30 18:46:31 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 30 Mar 2007 14:46:31 -0400 Subject: Spinning kernel-vanilla packages via standard spec Message-ID: <460D5B07.1030608@redhat.com> A little follow-on to the "Longing for git-bisect" thread, in a newly-created/subjected thread... So, I've been poking around in the kernel spec file extensively the past few days already... Any objections to my attempting to implement the building of a kernel-vanilla package as well? Roland, not sure if you were already planning to do this in conjunction with digging up your old patches, or if you were just throwing the patches out there, but either way, I'm happy to take on the task, but I'll defer to anyone else that really wants to do it. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Fri Mar 30 18:47:28 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 14:47:28 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <20070330182122.GC18649@redhat.com> References: <460D25FC.3030305@redhat.com> <20070330104953.4b7ce52a.zaitcev@redhat.com> <460D50EB.5090209@redhat.com> <20070330182122.GC18649@redhat.com> Message-ID: <460D5B40.5030003@redhat.com> Dave Jones wrote: > > Gets my vote too. > I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times > now for FC5/FC6, because each time it starts to look more promising, > it seems to find new ways to regress. > > I might do a build next week in rawhide with it off again too, > to see if any oddball bugs fall out. I was thinking of leaving MSI enabled and applying this patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6-pci_no_msi.patch URL: From davej at redhat.com Fri Mar 30 18:50:05 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 30 Mar 2007 14:50:05 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D5B40.5030003@redhat.com> References: <460D25FC.3030305@redhat.com> <20070330104953.4b7ce52a.zaitcev@redhat.com> <460D50EB.5090209@redhat.com> <20070330182122.GC18649@redhat.com> <460D5B40.5030003@redhat.com> Message-ID: <20070330185005.GA23978@redhat.com> On Fri, Mar 30, 2007 at 02:47:28PM -0400, Chuck Ebbert wrote: > Dave Jones wrote: > > > > Gets my vote too. > > I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times > > now for FC5/FC6, because each time it starts to look more promising, > > it seems to find new ways to regress. > > > > I might do a build next week in rawhide with it off again too, > > to see if any oddball bugs fall out. > > I was thinking of leaving MSI enabled and applying this patch. looks good to me Dave -- http://www.codemonkey.org.uk From kyle at ubuntu.com Fri Mar 30 19:04:39 2007 From: kyle at ubuntu.com (Kyle McMartin) Date: Fri, 30 Mar 2007 15:04:39 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D45B0.1090503@redhat.com> References: <460D25FC.3030305@redhat.com> <460D2A3A.2080402@gmail.com> <460D45B0.1090503@redhat.com> Message-ID: <20070330190439.GD20147@athena.road.mcmartin.ca> On Fri, Mar 30, 2007 at 01:15:28PM -0400, Chuck Ebbert wrote: > Jay Cliburn wrote: > > Chuck Ebbert wrote: > >> It seems like more and more problems with PCI MSI are turning up > >> in the 2.6.20 kernel. Discussion upstream concluded that maybe > >> it should have been off by default in 2.6.20, so maybe we should > >> just do that in Fedora and make people who want it use "pci=msi" > >> to enable it? It's probably not going to be really stable until > >> 2.6.22... > > > > I vote yes: turn it off by default. We just ran into an MSI issue on a > > particular Via motherboard (Asus M2V) that runs the network driver > > (atl1) I help maintain. The kernel blows up when we start the network > > unless we turn off MSI. > > One of our bug reporters points to a unbuntu thread where they mention > they have just turned of msi by default. > Yeah, we've also turned off MMCONFIG by default. We've seen way too many bugs that go away when they're disabled. Cheers, Kyle From cebbert at redhat.com Fri Mar 30 19:07:06 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 15:07:06 -0400 Subject: Backwards compatible module symlinks Message-ID: <460D5FDA.7060506@redhat.com> At first glance it doesn't seem very hard to do something like this on kernel install: ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid6.ko We could have left mkinitrd alone if the %post script for the kernel that combined those three modules into one had done this. From cebbert at redhat.com Fri Mar 30 19:08:37 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 15:08:37 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <20070330190439.GD20147@athena.road.mcmartin.ca> References: <460D25FC.3030305@redhat.com> <460D2A3A.2080402@gmail.com> <460D45B0.1090503@redhat.com> <20070330190439.GD20147@athena.road.mcmartin.ca> Message-ID: <460D6035.7030709@redhat.com> Kyle McMartin wrote: >> > > Yeah, we've also turned off MMCONFIG by default. We've seen way too many > bugs that go away when they're disabled. > Now that you mention it, that looks like a good idea too. From davej at redhat.com Fri Mar 30 19:09:08 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 30 Mar 2007 15:09:08 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <20070330190439.GD20147@athena.road.mcmartin.ca> References: <460D25FC.3030305@redhat.com> <460D2A3A.2080402@gmail.com> <460D45B0.1090503@redhat.com> <20070330190439.GD20147@athena.road.mcmartin.ca> Message-ID: <20070330190908.GA25818@redhat.com> On Fri, Mar 30, 2007 at 03:04:39PM -0400, Kyle McMartin wrote: > On Fri, Mar 30, 2007 at 01:15:28PM -0400, Chuck Ebbert wrote: > > Jay Cliburn wrote: > > > Chuck Ebbert wrote: > > >> It seems like more and more problems with PCI MSI are turning up > > >> in the 2.6.20 kernel. Discussion upstream concluded that maybe > > >> it should have been off by default in 2.6.20, so maybe we should > > >> just do that in Fedora and make people who want it use "pci=msi" > > >> to enable it? It's probably not going to be really stable until > > >> 2.6.22... > > > > > > I vote yes: turn it off by default. We just ran into an MSI issue on a > > > particular Via motherboard (Asus M2V) that runs the network driver > > > (atl1) I help maintain. The kernel blows up when we start the network > > > unless we turn off MSI. > > > > One of our bug reporters points to a unbuntu thread where they mention > > they have just turned of msi by default. > > > > Yeah, we've also turned off MMCONFIG by default. We've seen way too many > bugs that go away when they're disabled. Isn't that needed though to access higher config space on PCIE ? Or do we not have any drivers that use that yet, making it a nonissue? Dave -- http://www.codemonkey.org.uk From kyle at ubuntu.com Fri Mar 30 19:20:13 2007 From: kyle at ubuntu.com (Kyle McMartin) Date: Fri, 30 Mar 2007 15:20:13 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <20070330190908.GA25818@redhat.com> References: <460D25FC.3030305@redhat.com> <460D2A3A.2080402@gmail.com> <460D45B0.1090503@redhat.com> <20070330190439.GD20147@athena.road.mcmartin.ca> <20070330190908.GA25818@redhat.com> Message-ID: <20070330192013.GF20147@athena.road.mcmartin.ca> On Fri, Mar 30, 2007 at 03:09:08PM -0400, Dave Jones wrote: > Isn't that needed though to access higher config space on PCIE ? > Or do we not have any drivers that use that yet, making it a nonissue? > Yeah, you need it to access Extended config space on PCI-Express, but the only people who need it right now are Infinibarf, and I just provided pci=mmconf to turn it back on. http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=d613cff3d5968d3e93bad197480b90733c71b984 From jcm at redhat.com Fri Mar 30 19:22:54 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 30 Mar 2007 15:22:54 -0400 Subject: Backwards compatible module symlinks In-Reply-To: <460D5FDA.7060506@redhat.com> References: <460D5FDA.7060506@redhat.com> Message-ID: <460D638E.3030103@redhat.com> Chuck Ebbert wrote: > At first glance it doesn't seem very hard to do something like this > on kernel install: > > ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko > ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko > ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid6.ko > > We could have left mkinitrd alone if the %post script for the kernel that > combined those three modules into one had done this. Problem is that then, you're stuck doing that :-) Jon. From cebbert at redhat.com Fri Mar 30 19:28:48 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 30 Mar 2007 15:28:48 -0400 Subject: Backwards compatible module symlinks In-Reply-To: <460D638E.3030103@redhat.com> References: <460D5FDA.7060506@redhat.com> <460D638E.3030103@redhat.com> Message-ID: <460D64F0.6090300@redhat.com> Jon Masters wrote: > Chuck Ebbert wrote: >> At first glance it doesn't seem very hard to do something like this >> on kernel install: >> >> ln -s raid456.ko >> /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko >> ln -s raid456.ko >> /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko >> ln -s raid456.ko >> /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid6.ko >> >> We could have left mkinitrd alone if the %post script for the kernel that >> combined those three modules into one had done this. > > Problem is that then, you're stuck doing that :-) I figured after a few rounds of that you'd vacuum out the crud and put it in mkinitrd where it belongs. :) This would just allow some slack so the two didn't have to be released in lockstep. From roland at redhat.com Fri Mar 30 20:00:06 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 30 Mar 2007 13:00:06 -0700 (PDT) Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: Jarod Wilson's message of Friday, 30 March 2007 14:46:31 -0400 <460D5B07.1030608@redhat.com> Message-ID: <20070330200006.82FC61801C4@magilla.sf.frob.com> I already got it working and posted the spec and Makefile patch here. (I've also got my stuff for building from git branches working now.) Nobody answered about whether they wanted it committed. I didn't do it in a way intended to produce different variant rpms called kernel-vanilla-V-R, if that's what you had in mind. That requires basically duplicating all the innards of the spec file. I don't think that should be attempted without a complete cleanup of the spec file to become sane. What I've done is sufficient for making a vanilla build like this one: http://porkchop.devel.redhat.com/brewroot/scratch/roland/task_700227/ Thanks, Roland From jwilson at redhat.com Fri Mar 30 21:28:10 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 30 Mar 2007 17:28:10 -0400 Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: <20070330200006.82FC61801C4@magilla.sf.frob.com> References: <20070330200006.82FC61801C4@magilla.sf.frob.com> Message-ID: <460D80EA.3040608@redhat.com> Roland McGrath wrote: > I already got it working and posted the spec and Makefile patch here. Gah, sorry, I saw the patch, but missed that the spec mods were included in it too. > (I've also got my stuff for building from git branches working now.) > Nobody answered about whether they wanted it committed. > > I didn't do it in a way intended to produce different variant rpms called > kernel-vanilla-V-R, if that's what you had in mind. It is. And I was under the impression that's what Dave was thinking too, but I'll let him speak for himself. > That requires > basically duplicating all the innards of the spec file. I don't think that > should be attempted without a complete cleanup of the spec file to become > sane. More specifically, what I had in mind was to add just one more variant, so you'd have kernel, kernel-xen, kernel-kdump, kernel-PAE, etc., plus now a kernel-vanilla, which would be analogous to kernel minus patches -- i.e., don't bother with kernel-vanilla-xen, kernel-vanilla-kudmp, etc. Not to say that a spec file sanitization/sane-itization wouldn't be good to do as well (which I'm also perfectly willing to take on -- a few steps in this direction were taken earlier today). > What I've done is sufficient for making a vanilla build like this one: > http://porkchop.devel.redhat.com/brewroot/scratch/roland/task_700227/ Cool, I'll read your patch more carefully now. :) -- Jarod Wilson jwilson at redhat.com From roland at redhat.com Fri Mar 30 22:11:39 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 30 Mar 2007 15:11:39 -0700 (PDT) Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: Jarod Wilson's message of Friday, 30 March 2007 17:28:10 -0400 <460D80EA.3040608@redhat.com> Message-ID: <20070330221139.B11DB1801C4@magilla.sf.frob.com> > It is. And I was under the impression that's what Dave was thinking too, > but I'll let him speak for himself. Well, do we want it in the package set? I figured we were talking about "informal" builds that might be put up for ftp, but not be an integrated part of the Fedora world. If one rpmbuild from the spec kicks out -vanilla packages along with other variants, and we turn that on only for rawhide, still it winds up "in the system", people install it as "normal" and wind up with upgrade issues and all that. Eventually we have clueless Fedora users saying "you use -PAE? well -vanilla is the Fedora kernel I like best!" and reporting in bugs "why this fix isn't in -vanilla too?" It's easy to tweak my changes to put "vanilla" into %name instead of %release. I went with "kernel" and a long, funky %release because that's the tradition I've experienced for one-off and test builds people distribute. From my own experience juggling a dozen installations on two or three test boxes with many hack kernels installed each in an utterly disorganized fashion, it seems more likely to get resolved usefully when doing upgrades and such than an rpm named "kernel-foobar". That is, yum and rpm will get in your face all the time in the way that people are used to for juggling kernel rpms. (Also, I always shudder in superstitious fear that yum or who knows what will assume things about the kernel rpm being the way it always has been.) With whatever name, separate vanilla builds could easily be made usable as their own little yum repository. What is more work, and I think is more dubious, is having it be the same srpm that produces both fedora and vanilla builds. What will -bp do, make two source trees patched differently? > > That requires > > basically duplicating all the innards of the spec file. I don't think that > > should be attempted without a complete cleanup of the spec file to become > > sane. > > More specifically, what I had in mind was to add just one more variant, > so you'd have kernel, kernel-xen, kernel-kdump, kernel-PAE, etc., plus > now a kernel-vanilla, which would be analogous to kernel minus patches > -- i.e., don't bother with kernel-vanilla-xen, kernel-vanilla-kudmp, etc. That's no fun! Seriously, I think we need the full suite of variants (modulo xen until that's uptsream, etc.) for it really to be useful. Plenty of people are using -PAE and the point is to compare the foo you're using to foo-vanilla on a one-to-one basis, i.e. different source, same .config settings. And you want -debuginfo for all of those too. > Not to say that a spec file sanitization/sane-itization wouldn't be good > to do as well (which I'm also perfectly willing to take on -- a few > steps in this direction were taken earlier today). I despise how much duplication there is in there. The debuginfo stuff I originally did with rpm macros got hand-expanded because older rpmbuild couldn't cope with it. Maybe nowadays there is nothing with an rpmbuild older than FC-5 we are trying to work with, so we could use more macros for new stuff. (I think brew got fixed to use the buildroot's rpmbuild, so anything that's fine for the target systems sharing the kernel spec source should be fine.) rpm macros are a hairy mess, but cleaning things up with clean new macros is a better bet than anything else, IMHO. > Cool, I'll read your patch more carefully now. :) Here's the current version of it. You still need the nonintconfig patch variant I posted last time to go with this. I also attached below the shell script used by the GIT-using hacks that are in this version. http://porkchop.devel.redhat.com/brewroot/scratch/roland/task_703101/ shows what "make git/roland/scratch-build" does (the build magic works for "make git/roland-fedora/..." too, but the fedora patches don't apply to current upstream so it didn't build). This (the non-fedora flavor) is similar to the vanilla build, but automagically prepends: %changelog * Thu Mar 29 2007 Roland McGrath - Experimental build from git sources (no Fedora patches) - git tag: v2.6.21-rc5 6fb04ccf5c5e054c4107090bed6e866489f1089f - git branch: upstream 28defbea64622f69d65a6079bf800cedb9915a5f - git branch: roland 0ca00c859e7ac4d9d053abd06376233cb4f3bf84 and includes: Patch1: patch-2.6.21-rc5.bz2 Patch2: linux-2.6.21-rc5-upstream.patch Patch3: linux-2.6.21-rc5-roland.patch Thanks, Roland Index: Makefile =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/Makefile,v retrieving revision 1.45 diff -u -B -p -r1.45 Makefile --- Makefile 19 Mar 2007 21:32:30 -0000 1.45 +++ Makefile 30 Mar 2007 21:45:57 -0000 @@ -68,3 +68,119 @@ reconfig: # since i386 isn't a target... compile compile-short: DIST_DEFINES += --target $(shell uname -m) + +# +# Hacks for building vanilla (unpatched) kernel rpms. +# Use "make vanilla-TARGET" like "make TARGET" (make vanilla-scratch-build). +# +vanilla-%: $(SPECFILE:.spec=-vanilla.spec) + @$(MAKE) $* SPECFILE=$< + +$(SPECFILE:.spec=-vanilla.spec): $(SPECFILE) + @rm -f $@ + (echo %define nopatches 1; cat $<) > $@ + +scratch-build: test-srpm + $(BUILD_CLIENT) $(BUILD_FLAGS) --scratch $(COLLECTION) \ + $(SRCRPMDIR)/$(NAME)-$(VERSION)-$(RELEASE).src.rpm + +# Dismal kludge for building via brew from cvs after "make vanilla-tag". +ifdef BEEHIVE_SRPM_BUILD +export CHECKOUT_TAG ?= $(shell sed s/^.// CVS/Tag) +tag-pattern = $(TAG_NAME)-$(TAG_VERSION)-0_%_$(TAG_RELEASE) +ifeq (,$(filter-out $(tag-pattern),$(CHECKOUT_TAG))) +variant := $(patsubst $(tag-pattern),%,$(CHECKOUT_TAG)) +srpm: SPECFILE := $(wildcard $(SPECFILE:.spec=-$(variant).spec) \ + $(SPECFILE:.spec=-t.$(variant).spec)) +srpm beehive-sprm: RELEASE := 0.$(variant).$(RELEASE) +endif +endif + + +# +# Hacks for building kernel rpms from upstream code plus local GIT branches. +# Use "make git/BRANCH/TARGET" like "make TARGET". +# Use "make git/BRANCH-fedora/TARGET" to include Fedora patches on top. +# +ifndef GIT_SPEC +git/%: + @$(MAKE) GIT_SPEC=$(subst /,-,$(*D)) git-$(*F) +else +git-%: $(SPECFILE:.spec=-t.$(GIT_SPEC).spec) + @$(MAKE) GIT_SPEC= $* SPECFILE=$< +endif + +# +# Your git-branches.mk file can define GIT_DIR, e.g.: +# GIT_DIR = ${HOME}/kernel/.git +# Make sure GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL are also set +# or your rpm changelogs will look like crap. +# +# For each branch it can define a variable branch-BRANCH or tag-BRANCH +# giving the parent of BRANCH to diff against in a separate patch. If +# the parent is unknown, it will use $(branch-upstream) defaulting to +# "upstream". +# +# Defining tag-BRANCH means the tag corresponds to an upstream patch in +# the sources file, so that is used instead of generating a patch with +# git. If there is no tag-upstream defined, it will figure out a vNNN +# tag or vNNN-gitN pseudo-tag from the last patch in the sources file. +# For example: +# tag-some-hacks = v2.6.21-rc5 +# branch-more-hacks = first-hacks +# Leads to patches: +# git diff v2.6.21-rc5..more-hacks > linux-2.6.21-rc5-some-hacks.patch +# git diff some-hacks..more-hacks > linux-2.6.21-rc5-more-hacks.patch +# Whereas having no git-branches.mk at all but doing +# "make GIT_DIR=... git/mybranch/test-srpm" does: +# id=`cat patch-2.6.21-rc5-git4.id` # auto-fetched via upstream file +# git diff $id..upstream > linux-2.6.21-rc5-git4-upstream.patch +# git diff upstream..mybranch > linux-2.6.21-rc5-git4-mybranch.patch +# If the upstream patch (or any branch patch) is empty it's left out. +# +git-branches.mk:; +-include git-branches.mk + +branch-upstream ?= upstream + +ifdef GIT_DIR +export GIT_DIR +export GIT_AUTHOR_NAME +export GIT_AUTHOR_EMAIL +gen-patches ?= gen-patches + +ifndef havespec +$(SPECFILE:.spec=-t.%-fedora.spec): $(SPECFILE) $(gen-patches) FORCE + ./$(gen-patches) --fedora < $< > $@ $(gen-patches-args) +$(SPECFILE:.spec=-t.%.spec): $(SPECFILE) $(gen-patches) FORCE + ./$(gen-patches) < $< > $@ $(gen-patches-args) +.PRECIOUS: $(SPECFILE:.spec=-t.%.spec) $(SPECFILE:.spec=-t.%-fedora.spec) +endif + +spec-%: $(SPECFILE:.spec=-t.%.spec) ; +$(SPECFILE):; +FORCE:; + +gen-patches-args = ${srcdir} v$(VERSION) $(call heads,$*) +define heads +$(if $(tag-$1),$(filter-out v$(VERSION),$(tag-$1)),\ + $(call heads,$(firstword $(branch-$1) $(branch-upstream)))) $1 +endef + +files-%-fedora: + @echo $(SPECFILE:.spec=-t.$*-fedora.spec) + @$(call list-patches,$*) +files-%: + @echo $(SPECFILE:.spec=-t.$*.spec) + @$(call list-patches,$*) +define list-patches +$(if $(tag-$1),version=$(patsubst v%,%,$(tag-$1)),\ + $(call list-patches,$(firstword $(branch-$1) $(branch-upstream)))); \ +echo linux-$${version}-$1.patch +endef + +ifndef tag-$(branch-upstream) +tag-$(branch-upstream) := $(shell \ + sed -n 's/^.* *//;s/\.bz2$$//;s/patch-/v/p' sources) +endif +endif Index: kernel-2.6.spec =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3025 diff -u -B -p -r1.3025 kernel-2.6.spec --- kernel-2.6.spec 29 Mar 2007 00:00:55 -0000 1.3025 +++ kernel-2.6.spec 30 Mar 2007 21:45:57 -0000 @@ -32,7 +32,8 @@ Summary: The Linux kernel (the core of t %define sublevel 20 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define release %(R="$Revision: 1.3025 $"; RR="${R##: }"; echo ${RR%%?})%{?dist} +%define specrelease %(R="$Revision: 1.3025 $"; RR="${R##: }"; echo ${RR%%?})%{?dist} +%define release %{specrelease} %define make_target bzImage %define kernel_image x86 @@ -45,6 +46,28 @@ Summary: The Linux kernel (the core of t %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE} %define hdrarch %_target_cpu +%if 0%{!?nopatches:1} +%define nopatches 0 +%endif + +%if %{nopatches} +%define includexen 0 +%else +%define relsuffix .fedora +%endif + +%define using_upstream_branch 0 +%if 0%{?upstream_branch:1} +%define using_upstream_branch 1 +%define release 0.%{upstream_branch}%{?relsuffix}.%{specrelease} +%define buildxen 0 +%define buildxenPAE 0 +%else +%if %{nopatches} +%define release 0.vanilla.%{specrelease} +%endif +%endif + # groups of related archs #OLPC stuff %if 0%{?olpc} @@ -169,6 +192,15 @@ Summary: The Linux kernel (the core of t %define xen_image vmlinux.gz %endif +%if %{nopatches} +%define signmodules 0 +# Ignore unknown options in our config-* files. +# Some options go with patches we're not applying. +%define oldconfig_target loose_nonint_oldconfig +%else +%define oldconfig_target nonint_oldconfig +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -304,7 +336,15 @@ Source82: config-olpc-generic # # Patches 0 through 100 are meant for core subsystem upgrades # + +%if %{using_upstream_branch} +### BRANCH PATCH ### +%else +# Here should be only the patches up to the upstream canonical Linus tree. Patch1: patch-2.6.21-rc5.bz2 +%endif + +%if !%{nopatches} Patch3: git-geode.patch # Patches 10 through 99 are for things that are going upstream really soon. @@ -360,7 +400,9 @@ Patch341: linux-2.6-mpc52xx-fec.patch # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # -Patch800: linux-2.6-build-nonintconfig.patch +%endif +Patch800: linux-2.6.17-nonintconfig.patch +%if !%{nopatches} # Exec-shield. Patch810: linux-2.6-execshield.patch @@ -495,6 +537,7 @@ Patch20001: xen-11668-hvm_disable_fix.pa Patch20002: xen-dom0-reboot.patch # END OF PATCH DEFINITIONS +%endif BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu} @@ -867,9 +910,16 @@ cp -rl vanilla linux-%{kversion}.%{_targ cd linux-%{kversion}.%{_target_cpu} +%if %{using_upstream_branch} +### BRANCH APPLY ### +%else + # Update to latest upstream. %patch1 -p1 +%endif +%if !%{nopatches} + # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. @@ -945,13 +995,14 @@ cd linux-%{kversion}.%{_target_cpu} # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # - +%endif # This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). %patch800 -p1 +%if !%{nopatches} # Exec shield %patch810 -p1 @@ -1171,6 +1222,7 @@ mv drivers/xen/blktap/blktap.c drivers/x %patch10001 -p1 # END OF PATCH APPLICATIONS +%endif cp %{SOURCE10} Documentation/ @@ -1201,7 +1253,7 @@ for i in *.config do mv $i .config Arch=`head -1 .config | cut -b 3-` - make ARCH=$Arch nonint_oldconfig > /dev/null + make ARCH=$Arch %{oldconfig_target} > /dev/null echo "# $Arch" > configs/$i cat .config >> configs/$i done @@ -1295,7 +1347,7 @@ BuildKernel() { KernelImage=arch/$Arch/boot/bzImage fi - make -s ARCH=$Arch nonint_oldconfig > /dev/null + make -s ARCH=$Arch %{oldconfig_target} > /dev/null make -s ARCH=$Arch %{?_smp_mflags} $MakeTarget %{?sparse_mflags} make -s ARCH=$Arch %{?_smp_mflags} modules %{?sparse_mflags} || exit 1 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gen-patches URL: From dwmw2 at infradead.org Fri Mar 30 23:14:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 31 Mar 2007 00:14:31 +0100 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460C9F98.4000707@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> Message-ID: <1175296471.3122.192.camel@pmac.infradead.org> On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote: > Turns out the complexity of adding --with/--without support only > resulted in the on/off lines at the top of the spec being slightly > longer, so one can now additionally pass in, say, --without xen, on the > rpmbuild line to disable building a xen kernel. For example, here's the > results of a test build using the modified spec: Cute. That reduces the chances that I commit the local change that's usually in my tree which turns off kdump on ppc64, and smp on ppc32. How do I get it to work with the Makefile? This doesn't... $ make RPM_DEFINES="--without kdump" ppc64 -- dwmw2 From jwilson at redhat.com Sat Mar 31 01:20:20 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 30 Mar 2007 21:20:20 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <1175296471.3122.192.camel@pmac.infradead.org> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> <1175296471.3122.192.camel@pmac.infradead.org> Message-ID: <460DB754.8000600@redhat.com> David Woodhouse wrote: > On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote: >> Turns out the complexity of adding --with/--without support only >> resulted in the on/off lines at the top of the spec being slightly >> longer, so one can now additionally pass in, say, --without xen, on the >> rpmbuild line to disable building a xen kernel. For example, here's the >> results of a test build using the modified spec: > > Cute. That reduces the chances that I commit the local change that's > usually in my tree which turns off kdump on ppc64, and smp on ppc32. > > How do I get it to work with the Makefile? This doesn't... > $ make RPM_DEFINES="--without kdump" ppc64 Hrm, not sure why that doesn't pass the option through, but I hadn't even thought to look at the Makefile to see how these flags would work at that level. Out of curiosity, does the following work?: $ make RPM_DEFINES="--define 'with_kdump 0'" I suppose I ought to poke at that some myself... Adding to my todo list. -- Jarod Wilson jwilson at redhat.com From dwmw2 at infradead.org Sat Mar 31 01:26:36 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 31 Mar 2007 02:26:36 +0100 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <460DB754.8000600@redhat.com> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> <1175296471.3122.192.camel@pmac.infradead.org> <460DB754.8000600@redhat.com> Message-ID: <1175304396.3122.206.camel@pmac.infradead.org> On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote: > Hrm, not sure why that doesn't pass the option through, but I hadn't > even thought to look at the Makefile to see how these flags would work > at that level. Out of curiosity, does the following work?: > > $ make RPM_DEFINES="--define 'with_kdump 0'" > > I suppose I ought to poke at that some myself... Adding to my todo list. I used the trick I learned from the end of the existing Makefile... [root at ps3 devel]# tail -4 Makefile compile compile-short: DIST_DEFINES += --target $(shell uname -m) ppc64: DIST_DEFINES += --without kdump ppc: DIST_DEFINES += --without smp Now I just have to remember never to commit the Makefile :) -- dwmw2 From jwilson at redhat.com Sat Mar 31 04:02:14 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 31 Mar 2007 00:02:14 -0400 Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: <20070330221139.B11DB1801C4@magilla.sf.frob.com> References: <20070330221139.B11DB1801C4@magilla.sf.frob.com> Message-ID: <460DDD46.2050201@redhat.com> Roland McGrath wrote: >> It is. And I was under the impression that's what Dave was thinking too, >> but I'll let him speak for himself. > > Well, do we want it in the package set? I figured we were talking about > "informal" builds that might be put up for ftp, but not be an integrated > part of the Fedora world. This would appear to be question #1 we need to get answered. :) > If one rpmbuild from the spec kicks out -vanilla > packages along with other variants, and we turn that on only for rawhide, > still it winds up "in the system", people install it as "normal" and wind > up with upgrade issues and all that. Eventually we have clueless Fedora > users saying "you use -PAE? well -vanilla is the Fedora kernel I like best!" > and reporting in bugs "why this fix isn't in -vanilla too?" I don't think that's too big a concern, we could be 100% firm that we don't apply any patches whatsoever (outside of nonintconfig), its pure upstream. The main benefit I see is that it would be really nice to spin them off the exact same rpmbuild, since that would mean the only possible variance is the set of patches applied. However, yeah, it being "in the system" could indeed be annoying. And it could be a bit of unnecessary overhead, resulting in an identical kernel if from one kernel build to another, all that changes is the patches we add. So perhaps, building "unofficial" builds, of all varieties, does make more sense, and then we just point folks at them when they have issues with our normal kernels and want to compare w/an upstream build. > It's easy to tweak my changes to put "vanilla" into %name instead of > %release. I went with "kernel" and a long, funky %release because that's > the tradition I've experienced for one-off and test builds people > distribute. From my own experience juggling a dozen installations on two > or three test boxes with many hack kernels installed each in an utterly > disorganized fashion, it seems more likely to get resolved usefully when > doing upgrades and such than an rpm named "kernel-foobar". That is, yum > and rpm will get in your face all the time in the way that people are used > to for juggling kernel rpms. (Also, I always shudder in superstitious fear > that yum or who knows what will assume things about the kernel rpm being > the way it always has been.) I kinda like it in %name whichever route we go here. Along the same lines as Ingo's kernel-rt packages, it makes it easier to install them in parallel with normal kernels for testing. Otherwise, a vanilla build we only wanted someone to install for testing would trigger one of the user's two other installed kernels being un-installed with our current default yum setup. > With whatever name, separate vanilla builds could easily be made usable as > their own little yum repository. Okay, I think that's what I'm leaning toward now. :) > What is more work, and I think is more dubious, is having it be the same > srpm that produces both fedora and vanilla builds. What will -bp do, make > two source trees patched differently? Good question... >>> That requires >>> basically duplicating all the innards of the spec file. I don't think that >>> should be attempted without a complete cleanup of the spec file to become >>> sane. >> More specifically, what I had in mind was to add just one more variant, >> so you'd have kernel, kernel-xen, kernel-kdump, kernel-PAE, etc., plus >> now a kernel-vanilla, which would be analogous to kernel minus patches >> -- i.e., don't bother with kernel-vanilla-xen, kernel-vanilla-kudmp, etc. > > That's no fun! Seriously, I think we need the full suite of variants > (modulo xen until that's uptsream, etc.) for it really to be useful. > Plenty of people are using -PAE and the point is to compare the foo you're > using to foo-vanilla on a one-to-one basis, i.e. different source, same > .config settings. And you want -debuginfo for all of those too. I'd have had vanilla-debuginfo built off the main spec too (plus vanilla-devel and vanilla-headers). But I'm persuaded to go all-out. >> Not to say that a spec file sanitization/sane-itization wouldn't be good >> to do as well (which I'm also perfectly willing to take on -- a few >> steps in this direction were taken earlier today). > > I despise how much duplication there is in there. The debuginfo stuff I > originally did with rpm macros got hand-expanded because older rpmbuild > couldn't cope with it. Maybe nowadays there is nothing with an rpmbuild > older than FC-5 we are trying to work with And we only have to care about FC-5 for another month or so, in which case I wouldn't bother worrying about anything but FC-6 and later. > so we could use more macros for > new stuff. (I think brew got fixed to use the buildroot's rpmbuild, so > anything that's fine for the target systems sharing the kernel spec source > should be fine.) Correct, the buildroot should be using the target system's rpmbuild. > rpm macros are a hairy mess, but cleaning things up with > clean new macros is a better bet than anything else, IMHO. Absolutely. >> Cool, I'll read your patch more carefully now. :) > > Here's the current version of it. You still need the nonintconfig patch > variant I posted last time to go with this. I also attached below the > shell script used by the GIT-using hacks that are in this version. > http://porkchop.devel.redhat.com/brewroot/scratch/roland/task_703101/ shows > what "make git/roland/scratch-build" does (the build magic works for "make > git/roland-fedora/..." too, but the fedora patches don't apply to current > upstream so it didn't build). This (the non-fedora flavor) is similar to > the vanilla build, but automagically prepends: > > %changelog > * Thu Mar 29 2007 Roland McGrath > - Experimental build from git sources (no Fedora patches) > - git tag: v2.6.21-rc5 6fb04ccf5c5e054c4107090bed6e866489f1089f > - git branch: upstream 28defbea64622f69d65a6079bf800cedb9915a5f > - git branch: roland 0ca00c859e7ac4d9d053abd06376233cb4f3bf84 > > and includes: > > Patch1: patch-2.6.21-rc5.bz2 > Patch2: linux-2.6.21-rc5-upstream.patch > Patch3: linux-2.6.21-rc5-roland.patch Thanks much, I'll try to digest all this over the weekend, and/or early Monday... Still interested to hear what approach others think we should take to providing some "vanilla" kernels, but it would seem I'm now on board for your idea, but with "vanilla" (or "upstream" or "whatever") moved from %release to %name. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Sat Mar 31 04:22:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 31 Mar 2007 00:22:32 -0400 Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: <1175304396.3122.206.camel@pmac.infradead.org> References: <460BFA59.2030702@redhat.com> <20070329175148.GF32707@redhat.com> <460C0042.80507@redhat.com> <20070329181433.GJ32707@redhat.com> <460C0726.6050908@redhat.com> <460C0B02.2050507@redhat.com> <460C0BF7.2000801@redhat.com> <460C11BC.6020100@redhat.com> <460C135A.6090401@redhat.com> <460C9F98.4000707@redhat.com> <1175296471.3122.192.camel@pmac.infradead.org> <460DB754.8000600@redhat.com> <1175304396.3122.206.camel@pmac.infradead.org> Message-ID: <460DE208.2000901@redhat.com> David Woodhouse wrote: > On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote: >> Hrm, not sure why that doesn't pass the option through, but I hadn't >> even thought to look at the Makefile to see how these flags would work >> at that level. Out of curiosity, does the following work?: >> >> $ make RPM_DEFINES="--define 'with_kdump 0'" >> >> I suppose I ought to poke at that some myself... Adding to my todo list. > > I used the trick I learned from the end of the existing Makefile... > > [root at ps3 devel]# tail -4 Makefile > compile compile-short: DIST_DEFINES += --target $(shell uname -m) > > ppc64: DIST_DEFINES += --without kdump > ppc: DIST_DEFINES += --without smp > > > Now I just have to remember never to commit the Makefile :) Ooh, I like it... Along those lines, what if we had Makefile include a Makefile.local if it existed, which was .cvsignore'd? Then you could tweak your local default build prefs to your hearts content without having to worry about accidentally committing them... /me still needs to actually *read* the Makefile at this point... ;) -- Jarod Wilson jwilson at redhat.com From roland at redhat.com Sat Mar 31 07:06:17 2007 From: roland at redhat.com (Roland McGrath) Date: Sat, 31 Mar 2007 00:06:17 -0700 (PDT) Subject: Needed: An easier way to build a subset of kernel packages In-Reply-To: Jarod Wilson's message of Saturday, 31 March 2007 00:22:32 -0400 <460DE208.2000901@redhat.com> Message-ID: <20070331070617.D09AA1801C4@magilla.sf.frob.com> > Ooh, I like it... Along those lines, what if we had Makefile include a > Makefile.local if it existed, which was .cvsignore'd? Then you could > tweak your local default build prefs to your hearts content without > having to worry about accidentally committing them... Actually you can write your own that does "include Makefile" and either use "make -f Makefile.local" or just call it GNUmakefile and it will be used in preference to Makefile by default. From roland at redhat.com Sat Mar 31 07:47:41 2007 From: roland at redhat.com (Roland McGrath) Date: Sat, 31 Mar 2007 00:47:41 -0700 (PDT) Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: Jarod Wilson's message of Saturday, 31 March 2007 00:02:14 -0400 <460DDD46.2050201@redhat.com> Message-ID: <20070331074741.2BC081801C4@magilla.sf.frob.com> > I kinda like it in %name whichever route we go here. Along the same > lines as Ingo's kernel-rt packages, it makes it easier to install them > in parallel with normal kernels for testing. I was just remembering about Ingo's -rt builds. I hadn't looked. What he uses is nearly identical to what I wind up with. It should be easy to use a unified spec file for his -rt patch version too. I've tweaked my hacks slightly to use name: kernel-vanilla and kernel-branch for the git stuff. For git builds, it now produces e.g. kernel-upstream-2.6.20-2.6.21.rc5.97.1.3025 or kernel-roland-fedora-PAE-2.6.20-2.6.18.rc6.256.1.3025 using the tag and "commit number" from git (1.5) describe, so upgrades for the same branch package should work right without the ginormous date string release numbers I had before. (Those changes are small but I don't have intermediate diffs on hand since I didn't commit the old version. I can send you the new files if you want.) Thanks, Roland