From nicolas.mailhot at laposte.net Fri Jun 1 10:01:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 1 Jun 2007 12:01:52 +0200 (CEST) Subject: [Suspend-devel] willing to contribute - so laptops suspend better - but how? In-Reply-To: <465F254B.8000903@fedoraproject.org> References: <64b14b300705240119w768f23f1h40c312432818c385@mail.gmail.com> <200705242225.50298.rjw@sisk.pl> <64b14b300705300627g47c1868due57f449aaf528901@mail.gmail.com> <200705302212.12042.rjw@sisk.pl> <64b14b300705310121q1ad9430ek64e848d02a4dfcb5@mail.gmail.com> <47300.192.54.193.51.1180600598.squirrel@rousalka.dyndns.org> <465F254B.8000903@fedoraproject.org> Message-ID: <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> Le Jeu 31 mai 2007 21:43, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: >> Le Jeu 31 mai 2007 10:21, Valent Turkovic a ?crit : >> >>> How much time does it take to configure vanilla kernel to run with >>> fedora? Can you give me some guide or some general info. >> >> It would be *very* nice to have an official simplified spec file >> where >> one would just dump vanilla source & patch references and test the >> result. The Fedora kernel spec is so complex it can't really be >> reused >> standalone > > Already planned. See fedora-kernel list archives. Not really what I had in mind What's planned if I understand it correctly is some automation to have koji spill vanilla kernels in addition to fedora-patched ones What I'd like to see is a spec template where you can just list the upstream patches & config options you need, and mock-build locally a kernel package that integrates nicely in Fedora (all the debuginfo, devel, etc subpackage stuff) ie kill the multi-arch multi-flavour automation, just build a simple single version for the user system The use case is when you hit a bug, open an issue in upstream's bugzilla/mail LKML, and people ask you to try vanilla kernel X with patch Y and config option Z on. -- Nicolas Mailhot From valent.turkovic at gmail.com Fri Jun 1 14:13:10 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 1 Jun 2007 16:13:10 +0200 Subject: [Suspend-devel] willing to contribute - so laptops suspend better - but how? In-Reply-To: <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> References: <64b14b300705240119w768f23f1h40c312432818c385@mail.gmail.com> <200705242225.50298.rjw@sisk.pl> <64b14b300705300627g47c1868due57f449aaf528901@mail.gmail.com> <200705302212.12042.rjw@sisk.pl> <64b14b300705310121q1ad9430ek64e848d02a4dfcb5@mail.gmail.com> <47300.192.54.193.51.1180600598.squirrel@rousalka.dyndns.org> <465F254B.8000903@fedoraproject.org> <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> Message-ID: <64b14b300706010713l5b88e25t2093646eb62fec70@mail.gmail.com> On 6/1/07, Nicolas Mailhot wrote: > > Le Jeu 31 mai 2007 21:43, Rahul Sundaram a ?crit : If I understood you correctly this feature would enable fodorans with not so great kernel knowledge to contribute to faster bug tracking... I hail this endeavor, please make this work if it is possible... if you lover the bar for us, users of fedora, to contribute you will get much more help. Regards Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From drago01 at gmail.com Sun Jun 3 13:27:45 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 03 Jun 2007 15:27:45 +0200 Subject: cfs test kernels for FC6/7 Message-ID: <4662C1D1.9020203@gmail.com> Hello, I was testing the new cfs scheduler [1] in the past few weeks and has found this site: http://linux-dev.qc.ec.gc.ca/ there are prebuilt kernels for FC6/F7 (F7 kernels should also work on rawhide) with the cfs scheduler patched in. If anyone wants to play with new stuff he can go ahead and test them and share the results. CFS should make it into mainline in 2.6.23. Your system should fell more responsive under load when using this kernels. 1: http://lkml.org/lkml/2007/4/13/180 From drago01 at gmail.com Sun Jun 3 13:40:06 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 03 Jun 2007 15:40:06 +0200 Subject: cfs test kernels for FC6/7 Message-ID: <4662C4B6.6000305@gmail.com> Hello, I was testing the new cfs scheduler [1] in the past few weeks and has found this site: http://linux-dev.qc.ec.gc.ca/ there are prebuilt kernels for FC6/F7 (F7 kernels should also work on rawhide) with the cfs scheduler patched in. If anyone wants to play with new stuff he can go ahead and test them and share the results. CFS should make it into mainline in 2.6.23. Your system should fell more responsive under load when using this kernels. 1: http://lkml.org/lkml/2007/4/13/180 From spring7 at cnspringlighting.com Tue Jun 5 08:16:51 2007 From: spring7 at cnspringlighting.com (=?GB2312?Q?Jack(SPRING_LIGHTING)?=) Date: Tue, 5 Jun 2007 16:16:51 +0800 Subject: I''m Jack from SPRING LIGHTING Message-ID: <20070605081632.BF93A50D6A@mail.gmail167.cn4e.com> this is a html format email,your mail system is nonsuport showed at the moment.
Dear Friend,         I am Jack From Yongkang Spring Lighting in China. Our company is a professional enterprise specializing in the  manufacture of  lighting. We manufacture a full range of lighting  fixtures and electric components to meet different customers' demands and provide good after-sales service. Any comments by return wil be much appreicated. It will be our big pleasure if we have opportunities to be on service of you in near future. Waiting for your soonest reply,  I  think you will  be  interest in  our  products. Best regards, Jack Pan(Sales Manager)   YONGKANG SPRING LIGHTING CO.,LTD Add: Lieqiao Industrial Zone, Yongkang City,Zhejiang Province, China Tel: 86-579-87276059 Fax:  86-579-87277799 E-mail:spring7 at cnspringlighting.com MSN messenger: sbnspring7 at hotmail.com Http://www.cnspringlighting.com    -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Jun 7 19:17:37 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 7 Jun 2007 15:17:37 -0400 Subject: F7 redux, and the road to F8. Message-ID: <20070607191737.GA6054@redhat.com> I've been doing some thinking about "what went right/wrong" about F7 from the kernel standpoint, and how we can improve for F8. Wrt 'what went right', I don't have much to say. Not because nothing went right, but mostly because there was nothing really positive that stood out over earlier releases. The new firewire stuff was probably the only thing that went really well. Kristian jumped on bugs quickly when they were found, we got updated kernels out quickly, and best of all, it's now upstream. The 'what went wrong' category gives me a bunch of ideas of areas where we can improve however. libata. ~~~~~~~ Looking at the incoming bugs, this seems to be the biggest area where we have problems. No surprise really given the switchover to new pata drivers. Though there are quite a few SATA bugs too. I'm not sure what more we can do here other than keep pointing Jeff & Alan at them, and hoping for the best. We knew this was going to be bumpy first time around, so hopefully for F8 we'll have most of the kinks worked out here, and won't have introduced (m)any new problems. Wireless. ~~~~~~~~~ Well, we got dscape and a bunch of new drivers in. They don't seem to work too well though. For this to improve, we really need more bodies. This was pretty much all linville. How can we get more interaction from the various upstreams? ipw3945 seemed to be busted for weeks on end, with very little motion from Intel. How can we get them more involved? Nouveau. ~~~~~~~~ This was pretty much a 'dump in the tree and forget' activity. It really needs someone with the time to babysit it and make sure it actually progresses. Ideally, we'd have someone involved in improving the driver driving this along. Again, we lack bodies. I doubt this is going to change much in the F8 timeframe. Suspend/Resume. ~~~~~~~~~~~~~~~ We need a more focused testing effort here. (And an even more 'fixing' effort when problems are found). I fixed up 2-3 laptops in the last few weeks before release, but pretty much every review I've read of F7 so far has dinged us for this not working out the box. On common laptops like thinkpads too. In part, this was us moving to new suspend infrastructure, so I'm hoping a lot of the 'black screen' bugs will just go away in a future hal-data/pm-utils update. But we can definitly do better here. Work is ongoing to get better debugging tools for resume failures too, more about that as it happens. Xen. ~~~~ This might get interesting to watch for F8 if XenU gets upstream (Which akpm seems to suggest it might). Given we've decoupled kernel/kernel-xen, we might want to just disable the upstream variant until F9, and wait until we have both the dom0 and the domU stuff coming from the same pieces. Will need more discussion with the virtualisation team when that lands in Linus' tree. Last minute breakage. ~~~~~~~~~~~~~~~~~~~~~ The number one lesson I think to be learned was that just because upstream -stable is called -stable, it isn't necessarily so. The last minute rebase to 2.6.21.2 brought in the regression that broke a lot of Dell laptops, and wasn't understood & fixed in time for release. For F8 onwards, I propose that we don't jump to the latest upstream stable release as a last minute thing. Maybe hold off for the last week (maybe 2 weeks?) allowing only *really critical* changes. Where really critical == - Fixes a "machine won't boot" bug. - Fixes a "ethernet doesn't work" bug (thus preventing updates being downloaded) - Fixes a data corruption bug. - Fixes a _critical_ security bug. (Lower impact things like information leakage can wait until update 1 on the day of release). - Anything else? The thing is, we nearly always do an update just after the release anyway, so not-so-critical stuff that doesn't fall into the above category can go out as an update. It'll be a bit more work to do more backporting, but I think the overall risk will be lower if we cherry pick. On the subject of backporting, due to us only having 5 months for F8, and a lot of that time being 'conference season', I expect upstream to slow down a little, so we're probably looking at 2.6.23 for F8. I'm guessing .24 will begin way too late in our cycle, so we'll have quite a bit of backporting to be doing for the final month or so before release. comments? Dave -- http://www.codemonkey.org.uk From katzj at redhat.com Thu Jun 7 19:38:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jun 2007 15:38:05 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607191737.GA6054@redhat.com> References: <20070607191737.GA6054@redhat.com> Message-ID: <1181245085.26928.55.camel@erebor.boston.redhat.com> On Thu, 2007-06-07 at 15:17 -0400, Dave Jones wrote: > Wireless. > ~~~~~~~~~ > Well, we got dscape and a bunch of new drivers in. > They don't seem to work too well though. For this to improve, > we really need more bodies. This was pretty much all linville. > How can we get more interaction from the various upstreams? > ipw3945 seemed to be busted for weeks on end, with very little > motion from Intel. How can we get them more involved? Not sure of a good answer here. Hopefully with mac80211 upstream in .22, we'll start to see some of the drivers filter that way for .23 and that will help a bit. iwlwifi being in that category is going to probably take some heavy lifting and someone diving in to just patchbomb them :-/ > Suspend/Resume. > ~~~~~~~~~~~~~~~ > We need a more focused testing effort here. > (And an even more 'fixing' effort when problems are found). > I fixed up 2-3 laptops in the last few weeks before release, > but pretty much every review I've read of F7 so far has dinged > us for this not working out the box. On common laptops like thinkpads > too. In part, this was us moving to new suspend infrastructure, > so I'm hoping a lot of the 'black screen' bugs will just go away > in a future hal-data/pm-utils update. But we can definitly do > better here. Work is ongoing to get better debugging tools > for resume failures too, more about that as it happens. I think that more of the problems here really are with the way quirks work changing and not being fully understood. eg, the quirks are only used when you suspend via hal but not if you just invoke pm-suspend(!). At least, I didn't realize that until pretty close to release time and thus was very confused when suspend via the menu didn't work but running pm-suspend did :-) More concerted effort on testing this out is probably the only thing that can really help. Maybe try to organize a bug day with Will and couple it with a live image being available for people to test with? > Xen. > ~~~~ > This might get interesting to watch for F8 if XenU gets upstream > (Which akpm seems to suggest it might). Given we've decoupled > kernel/kernel-xen, we might want to just disable the upstream variant > until F9, and wait until we have both the dom0 and the domU stuff > coming from the same pieces. Will need more discussion with > the virtualisation team when that lands in Linus' tree. And there's also the kvm-xen stuff that could serve as a replacement for the dom0 bits :-) Even if not, it's probably worth getting the domU bits into the regular kernel because then we can simplify some of the installer stuff quite a bit. More generally, I think we want to look at enabling pvops and seeing what kind of hit it has. If it's not too bad, it'd be good to have it on since more and more is going to be using it... there's already the VMWare implementation and the KVM pvops discussion is taking off again. > Last minute breakage. > ~~~~~~~~~~~~~~~~~~~~~ > For F8 onwards, I propose that we don't jump to the latest upstream > stable release as a last minute thing. Maybe hold off for the last > week (maybe 2 weeks?) allowing only *really critical* changes. Sounds like a good plan to me. Jeremy From notting at redhat.com Thu Jun 7 19:39:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 15:39:00 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607191737.GA6054@redhat.com> References: <20070607191737.GA6054@redhat.com> Message-ID: <20070607193900.GB28551@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > libata. > ~~~~~~~ > Looking at the incoming bugs, this seems to be the biggest area > where we have problems. No surprise really given the switchover > to new pata drivers. Though there are quite a few SATA bugs too. > I'm not sure what more we can do here other than keep pointing > Jeff & Alan at them, and hoping for the best. > We knew this was going to be bumpy first time around, so hopefully > for F8 we'll have most of the kinks worked out here, and won't > have introduced (m)any new problems. How much of this is "devices changed names" issues, versus "new code doesn't quite work"? > Wireless. > ~~~~~~~~~ > Well, we got dscape and a bunch of new drivers in. > They don't seem to work too well though. For this to improve, > we really need more bodies. This was pretty much all linville. > How can we get more interaction from the various upstreams? > ipw3945 seemed to be busted for weeks on end, with very little > motion from Intel. How can we get them more involved? Make it get upstream. No, I don't know how 'make it' works. > Nouveau. > ~~~~~~~~ > This was pretty much a 'dump in the tree and forget' activity. > It really needs someone with the time to babysit it and make sure > it actually progresses. Ideally, we'd have someone involved > in improving the driver driving this along. Again, we lack bodies. > I doubt this is going to change much in the F8 timeframe. Upstream doesn't seem to be moving with any real quickness, which is somewhat sad. > Xen. > ~~~~ > This might get interesting to watch for F8 if XenU gets upstream > (Which akpm seems to suggest it might). Given we've decoupled > kernel/kernel-xen, we might want to just disable the upstream variant > until F9, and wait until we have both the dom0 and the domU stuff > coming from the same pieces. Will need more discussion with > the virtualisation team when that lands in Linus' tree. As it's decoupled, exactly how much pain are we running into with various fixes (PATA/SATA, suspend, etc., etc.) not being consistent? > Last minute breakage. > ~~~~~~~~~~~~~~~~~~~~~ > The number one lesson I think to be learned was that just because > upstream -stable is called -stable, it isn't necessarily so. > The last minute rebase to 2.6.21.2 brought in the regression that > broke a lot of Dell laptops, and wasn't understood & fixed in time > for release. > > For F8 onwards, I propose that we don't jump to the latest upstream > stable release as a last minute thing. Maybe hold off for the last > week (maybe 2 weeks?) allowing only *really critical* changes. > Where really critical == > > - Fixes a "machine won't boot" bug. > - Fixes a "ethernet doesn't work" bug (thus preventing updates being downloaded) > - Fixes a data corruption bug. > - Fixes a _critical_ security bug. > (Lower impact things like information leakage can wait until update 1 on > the day of release). > - Anything else? I'd say somewhere between 1-2 weeks, definitely. Enough time to do real regression testing on a variety of hardware. Bill From davej at redhat.com Thu Jun 7 19:54:53 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 7 Jun 2007 15:54:53 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607193900.GB28551@nostromo.devel.redhat.com> References: <20070607191737.GA6054@redhat.com> <20070607193900.GB28551@nostromo.devel.redhat.com> Message-ID: <20070607195453.GD6054@redhat.com> On Thu, Jun 07, 2007 at 03:39:00PM -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > libata. > How much of this is "devices changed names" issues, versus "new > code doesn't quite work"? Looking at the bz's, it looks like its all 'just doesnt work on this chipset' bugs. > > Nouveau. > Upstream doesn't seem to be moving with any real quickness, which > is somewhat sad. The project seems to have lots of 'hangers on' but very few people capable of actually doing the work, which is indeed, unfortunate. > > Xen. > As it's decoupled, exactly how much pain are we running into with > various fixes (PATA/SATA, suspend, etc., etc.) not being consistent? I've not seen any of the Xen bug reports yet. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Jun 7 20:08:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 22:08:53 +0200 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607191737.GA6054@redhat.com> References: <20070607191737.GA6054@redhat.com> Message-ID: <466865D5.2000109@leemhuis.info> On 07.06.2007 21:17, Dave Jones wrote: > [...] > libata. > ~~~~~~~ > Looking at the incoming bugs, this seems to be the biggest area > where we have problems. No surprise really given the switchover > to new pata drivers. Though there are quite a few SATA bugs too. > I'm not sure what more we can do here other than keep pointing > Jeff & Alan at them, and hoping for the best. > We knew this was going to be bumpy first time around, so hopefully > for F8 we'll have most of the kinks worked out here, and won't > have introduced (m)any new problems. My 2 cent on this one: it might be a good idea to have test kernels for stuff like this that people can install on "Fedora (current)"; I for one would install them on some of my machines for testing purposes; I normally switch to rawhide only at test2 or test3. But well, maybe I'm and rare exotic kind or user, so maybe it's not worth the trouble. BTW, I have a proposal (written months ago but not yet send out) for a kind of testing rpeo in the scope of the fedora-project where we could do something like that. I'm actually willing to help once EPEL works. > [...] > Last minute breakage. > ~~~~~~~~~~~~~~~~~~~~~ > The number one lesson I think to be learned was that just because > upstream -stable is called -stable, it isn't necessarily so. > The last minute rebase to 2.6.21.2 brought in the regression that > broke a lot of Dell laptops, and wasn't understood & fixed in time > for release. > > For F8 onwards, I propose that we don't jump to the latest upstream > stable release as a last minute thing. Maybe hold off for the last > week (maybe 2 weeks?) allowing only *really critical* changes. > [...] +1 for one week before iso-creation > [...] > comments? HTH BTW, there is a lot of talk about the RHEL5 and the RL-kernel. See http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/ I suppose we are waiting for the bits to go upstream? CU thl From cebbert at redhat.com Thu Jun 7 20:11:18 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 07 Jun 2007 16:11:18 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607193900.GB28551@nostromo.devel.redhat.com> References: <20070607191737.GA6054@redhat.com> <20070607193900.GB28551@nostromo.devel.redhat.com> Message-ID: <46686666.2000404@redhat.com> On 06/07/2007 03:39 PM, Bill Nottingham wrote: > >> Xen. >> ~~~~ >> This might get interesting to watch for F8 if XenU gets upstream >> (Which akpm seems to suggest it might). Given we've decoupled >> kernel/kernel-xen, we might want to just disable the upstream variant >> until F9, and wait until we have both the dom0 and the domU stuff >> coming from the same pieces. Will need more discussion with >> the virtualisation team when that lands in Linus' tree. > > As it's decoupled, exactly how much pain are we running into with > various fixes (PATA/SATA, suspend, etc., etc.) not being consistent? > Xen is on kernel 2.6.20, which means they need to track the FC6 updates. Apparently they're not -- AFAICT from a quick look at CVS, they shipped kernel 2.6.20.3, while current FC6 is 2.6.20.11 plus additional patches. From davej at redhat.com Thu Jun 7 20:30:33 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 7 Jun 2007 16:30:33 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <1181245085.26928.55.camel@erebor.boston.redhat.com> References: <20070607191737.GA6054@redhat.com> <1181245085.26928.55.camel@erebor.boston.redhat.com> Message-ID: <20070607203033.GA27332@redhat.com> On Thu, Jun 07, 2007 at 03:38:05PM -0400, Jeremy Katz wrote: > > Xen. > > ~~~~ > > This might get interesting to watch for F8 if XenU gets upstream > > (Which akpm seems to suggest it might). Given we've decoupled > > kernel/kernel-xen, we might want to just disable the upstream variant > > until F9, and wait until we have both the dom0 and the domU stuff > > coming from the same pieces. Will need more discussion with > > the virtualisation team when that lands in Linus' tree. > > And there's also the kvm-xen stuff that could serve as a replacement for > the dom0 bits :-) Even if not, it's probably worth getting the domU > bits into the regular kernel because then we can simplify some of the > installer stuff quite a bit. With dom0 coming from one place and domU from another, I get the creeps about ABI differences when they're on different versions. > More generally, I think we want to look at enabling pvops and seeing > what kind of hit it has. If it's not too bad, it'd be good to have it > on since more and more is going to be using it... there's already the > VMWare implementation and the KVM pvops discussion is taking off again. Yeah, thanks for reminding me about that. Some investigation there is definitly needed. /me adds to todo Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Jun 7 20:35:11 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 7 Jun 2007 16:35:11 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <466865D5.2000109@leemhuis.info> References: <20070607191737.GA6054@redhat.com> <466865D5.2000109@leemhuis.info> Message-ID: <20070607203511.GB27332@redhat.com> On Thu, Jun 07, 2007 at 10:08:53PM +0200, Thorsten Leemhuis wrote: > On 07.06.2007 21:17, Dave Jones wrote: > > [...] > > libata. > > ~~~~~~~ > > Looking at the incoming bugs, this seems to be the biggest area > > where we have problems. No surprise really given the switchover > > to new pata drivers. Though there are quite a few SATA bugs too. > > I'm not sure what more we can do here other than keep pointing > > Jeff & Alan at them, and hoping for the best. > > We knew this was going to be bumpy first time around, so hopefully > > for F8 we'll have most of the kinks worked out here, and won't > > have introduced (m)any new problems. > > My 2 cent on this one: it might be a good idea to have test kernels for > stuff like this that people can install on "Fedora (current)"; I for one > would install them on some of my machines for testing purposes; I > normally switch to rawhide only at test2 or test3. You mean something like "F7 kernel for F6" ? The problem with that is the slew of userspace updates that would have been necessary. The initrd changes alone were pretty extensive. I *still* get the creeps about changing /dev/hda -> /dev/sda in a yum update. It works for most people, but I've been burnt by it, and I know some users have. For massive changes like that, it wouldn't really have helped much. Booting the livecd and having a "yes, I can see my hard disks" report from users would have had more value I think than reports from hybrid FC6 w/F7 bits systems. > BTW, there is a lot of talk about the RHEL5 and the RL-kernel. See > http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/ > I suppose we are waiting for the bits to go upstream? Yes. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Jun 7 20:53:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 22:53:38 +0200 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607203511.GB27332@redhat.com> References: <20070607191737.GA6054@redhat.com> <466865D5.2000109@leemhuis.info> <20070607203511.GB27332@redhat.com> Message-ID: <46687052.3040606@leemhuis.info> On 07.06.2007 22:35, Dave Jones wrote: > On Thu, Jun 07, 2007 at 10:08:53PM +0200, Thorsten Leemhuis wrote: > > On 07.06.2007 21:17, Dave Jones wrote: > > > [...] > > > libata. > > > ~~~~~~~ > > > Looking at the incoming bugs, this seems to be the biggest area > > > where we have problems. No surprise really given the switchover > > > to new pata drivers. Though there are quite a few SATA bugs too. > > > I'm not sure what more we can do here other than keep pointing > > > Jeff & Alan at them, and hoping for the best. > > > We knew this was going to be bumpy first time around, so hopefully > > > for F8 we'll have most of the kinks worked out here, and won't > > > have introduced (m)any new problems. > > > > My 2 cent on this one: it might be a good idea to have test kernels for > > stuff like this that people can install on "Fedora (current)"; I for one > > would install them on some of my machines for testing purposes; I > > normally switch to rawhide only at test2 or test3. > You mean something like "F7 kernel for F6" ? Yes. > The problem with that is the slew of userspace updates that would > have been necessary. Could be shipped in the same repo. Sure, one could just enable devel; but suppose you need to build a module and you are out of luck if rawhide gcc != Fedora (current()) gcc > The initrd changes alone were pretty extensive. > I *still* get the creeps about changing /dev/hda -> /dev/sda in > a yum update. It works for most people, but I've been burnt by it, > and I know some users have. For massive changes like that, it > wouldn't really have helped much. Booting the livecd and having > a "yes, I can see my hard disks" report from users would have had > more value I think than reports from hybrid FC6 w/F7 bits systems. In this case: maybe; in other cases it might be something else. > > BTW, there is a lot of talk about the RHEL5 and the RL-kernel. See > > http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/ > > I suppose we are waiting for the bits to go upstream? > Yes. k, was just wondering. BTW, thanks for your work davej; much appreciated. Cu thl From davej at redhat.com Thu Jun 7 21:01:46 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 7 Jun 2007 17:01:46 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <46687052.3040606@leemhuis.info> References: <20070607191737.GA6054@redhat.com> <466865D5.2000109@leemhuis.info> <20070607203511.GB27332@redhat.com> <46687052.3040606@leemhuis.info> Message-ID: <20070607210146.GG27332@redhat.com> On Thu, Jun 07, 2007 at 10:53:38PM +0200, Thorsten Leemhuis wrote: > > The problem with that is the slew of userspace updates that would > > have been necessary. > > Could be shipped in the same repo. comes down a resources issue. Peter was swamped during F7. (To use just one example, we'd likely have need changes to other parts of the OS too). Dave -- http://www.codemonkey.org.uk From ncunning at redhat.com Thu Jun 7 23:35:11 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Fri, 08 Jun 2007 09:35:11 +1000 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607191737.GA6054@redhat.com> References: <20070607191737.GA6054@redhat.com> Message-ID: <1181259311.31918.100.camel@nigel.suspend2.net> Hi. On Thu, 2007-06-07 at 15:17 -0400, Dave Jones wrote: > Suspend/Resume. > ~~~~~~~~~~~~~~~ > We need a more focused testing effort here. > (And an even more 'fixing' effort when problems are found). > I fixed up 2-3 laptops in the last few weeks before release, > but pretty much every review I've read of F7 so far has dinged > us for this not working out the box. On common laptops like thinkpads > too. In part, this was us moving to new suspend infrastructure, > so I'm hoping a lot of the 'black screen' bugs will just go away > in a future hal-data/pm-utils update. But we can definitly do > better here. Work is ongoing to get better debugging tools > for resume failures too, more about that as it happens. I've finally gotten a bit more up to speed in the last week - I'm now tracking both the new kernel cvs tree and rawhide, so hopefully I'll be more useful. I'm also working to make my one-day-a-week less theoretical :). The main hindrance I have in working on suspend bugs is access to hardware. I realise that shipping laptops to Victoria, Australia probably isn't the best option. Can we somehow set up good remote acesss that could let me be more useful here? We also have Hughsie (quirks expert!) on board at the moment as an intern or such like. I'd love to see us snap him up on a more permanent basis. It seems like just about all the power management guys end up at Suse. Regards, Nigel From olecom at flower.upol.cz Fri Jun 8 03:32:45 2007 From: olecom at flower.upol.cz (Oleg Verych) Date: Fri, 8 Jun 2007 03:32:45 +0000 (UTC) Subject: Sunifdef References: <645d17210705230529h115ca168qd7531911eac172ef@mail.gmail.com> <1180020765.8303.107.camel@shinybook.infradead.org> Message-ID: * From: David Woodhouse * Date: Thu, 24 May 2007 11:32:45 -0400 > > On Wed, 2007-05-23 at 13:29 +0100, Jonathan Underwood wrote: >> Dear Kernel list, >> >> I've noticed in the past that unifdef is used in kernel package >> building. I wonder if you're aware of a maintained and more >> featureful program, Sunifdef, which has evolved from unifdef (which >> seems mostly unmaintained). It's packaged for Fedora, and has a >> website here. > > The kernel no longer uses an external unifdef -- it has its own in > scripts/unifdef.c. If you want to work with the upstream kernel to > change that to sunifdef, go ahead. > > Can 'sunifdef -U__KERNEL__' fix up stuff like... > > #if defined(__KERNEL__) && defined(__FOO__) > and > #if defined(__KERNEL__) || defined(__BAR__) > > ... by treating them as '#if 0' (and eliding completely) and by > rewriting to just #ifdef __BAR__, respectively? If so, changing the > upstream kernel seems like it would be useful. If, what you've wrote would be policy (with watchdog script in the git), i think, simple (sed) scripts can be written to unifdef __KERNEL__ for userspace headers, with further sed'ing them(compiler.h), without any need of external or internal *programs*. Linux coding standards got rid of many C obfustications, happily. -*- olecom at flower:/tmp$ grep -e __KERNEL /usr/include/linux/soundcard.h | grep '!' #if (!defined(__KERNEL__) && !defined(KERNEL) && !defined(INKERNEL) && !defined(_KERNEL)) || defined(USE_SEQ_MACROS) olecom at flower:/tmp$ -*- Even this one is simple regex, but anyway, policy would be good. > -- > dwmw2 ____ From drago01 at gmail.com Fri Jun 8 15:50:50 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 08 Jun 2007 17:50:50 +0200 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607191737.GA6054@redhat.com> References: <20070607191737.GA6054@redhat.com> Message-ID: <46697ADA.1090809@gmail.com> Dave Jones wrote: > On the subject of backporting, due to us only having 5 months > for F8, and a lot of that time being 'conference season', I expect > upstream to slow down a little, so we're probably looking at > 2.6.23 for F8. I'm guessing .24 will begin way too late in our cycle, > so we'll have quite a bit of backporting to be doing for the final > month or so before release. > > comments? > > this would mean that we will might end up having cfs as the scheduler and tickless x86_64. I mostly using x86_64 ... where there any major problems (exept the dell one) related to tickless kernels in the F7 cycle? From davej at redhat.com Fri Jun 8 17:24:05 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 8 Jun 2007 13:24:05 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <46697ADA.1090809@gmail.com> References: <20070607191737.GA6054@redhat.com> <46697ADA.1090809@gmail.com> Message-ID: <20070608172405.GO27332@redhat.com> On Fri, Jun 08, 2007 at 05:50:50PM +0200, dragoran wrote: > this would mean that we will might end up having cfs as the scheduler > and tickless x86_64. > I mostly using x86_64 ... where there any major problems (exept the dell > one) related to tickless kernels in the F7 cycle? Too early to say really. There were a number of oddball bugs that still aren't really understood that could be related, but on the whole it hasn't been /that/ bad considering the amount of code that changed. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Fri Jun 8 18:56:34 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 08 Jun 2007 14:56:34 -0400 Subject: where to get KDB debugger for FC6 In-Reply-To: References: Message-ID: <4669A662.1000400@redhat.com> On 05/29/2007 02:06 PM, kathy pu wrote: > Hello Everybody: > > Just wondering if FC6 supports KDB. If not, would like to know the > current status andhow to get it and port it? > > My great appreciation. > I think Keith Owens keeps it updated: ftp://oss.sgi.com/www/projects/kdb/download/v4.4 From Axel.Thimm at ATrpms.net Fri Jun 8 19:41:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 21:41:09 +0200 Subject: atop? Message-ID: <20070608194109.GA4263@neu.nirvana> Would it make sense to add these patches to Fedora's kernel? http://www.atcomputing.nl/Tools/atop This could help in the area of extending laptop battery life by detecting unneccessary disk access. The first step is to have some disk I/O to process mapping. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Jun 8 19:43:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 8 Jun 2007 15:43:32 -0400 Subject: atop? In-Reply-To: <20070608194109.GA4263@neu.nirvana> References: <20070608194109.GA4263@neu.nirvana> Message-ID: <20070608194332.GD12358@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > Would it make sense to add these patches to Fedora's kernel? > > http://www.atcomputing.nl/Tools/atop > > This could help in the area of extending laptop battery life by > detecting unneccessary disk access. The first step is to have some > disk I/O to process mapping. These patches: a) aren't upstream b) change the format of /proc/stat c) change process accounting in an incompatible way So... no. Bill From Axel.Thimm at ATrpms.net Fri Jun 8 19:48:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 21:48:28 +0200 Subject: atop? In-Reply-To: <20070608194332.GD12358@nostromo.devel.redhat.com> References: <20070608194109.GA4263@neu.nirvana> <20070608194332.GD12358@nostromo.devel.redhat.com> Message-ID: <20070608194828.GB4263@neu.nirvana> On Fri, Jun 08, 2007 at 03:43:32PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Would it make sense to add these patches to Fedora's kernel? > > > > http://www.atcomputing.nl/Tools/atop > > > > This could help in the area of extending laptop battery life by > > detecting unneccessary disk access. The first step is to have some > > disk I/O to process mapping. > > These patches: > > a) aren't upstream > b) change the format of /proc/stat > c) change process accounting in an incompatible way > > So... no. OK, fair enough (I wasn't aware of b) and c)). Any other way then to achive the stated goals? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Jun 8 19:47:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 8 Jun 2007 15:47:34 -0400 Subject: atop? In-Reply-To: <20070608194828.GB4263@neu.nirvana> References: <20070608194109.GA4263@neu.nirvana> <20070608194332.GD12358@nostromo.devel.redhat.com> <20070608194828.GB4263@neu.nirvana> Message-ID: <20070608194734.GE12358@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > These patches: > > > > a) aren't upstream > > b) change the format of /proc/stat > > c) change process accounting in an incompatible way > > > > So... no. > > OK, fair enough (I wasn't aware of b) and c)). > > Any other way then to achive the stated goals? I haven't tried, but blktrace? Bill From roland at frob.com Fri Jun 8 19:59:26 2007 From: roland at frob.com (Roland McGrath) Date: Fri, 8 Jun 2007 12:59:26 -0700 (PDT) Subject: spec hacks for vanilla and git-based kernel rpm builds Message-ID: <20070608195926.9A5134D059C@magilla.localdomain> Here I am again with those hacks to do alternate builds from the kernel spec file. Can I commit at least the spec parts to rawhide now? The diff is only this: --- kernel-2.6.spec 08 Jun 2007 12:55:12 -0700 1.3213 +++ kernel-2.6.spec 08 Jun 2007 12:55:05 -0700 @@ -63,7 +63,8 @@ Summary: The Linux kernel (the core of t %define sublevel 21 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define release %(R="$Revision: 1.3213 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define specrelease %(R="$Revision: 1.3213 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define release %{specrelease} %define make_target bzImage %define kernel_image x86 @@ -76,6 +77,24 @@ 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 +%define variant -vanilla +%else +%define variant_fedora -fedora +%endif + +%define using_upstream_branch 0 +%if 0%{?upstream_branch:1} +%define using_upstream_branch 1 +%define variant -%{upstream_branch}%{?variant_fedora} +%define release %{upstream_branch_release}.%{specrelease} +%endif + # if requested, only build base kernel %if %{with_baseonly} %define with_smp 0 @@ -248,6 +267,15 @@ Summary: The Linux kernel (the core of t %define kernel_image vmlinux %endif +%if %{nopatches} +%define with_modsign 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 @@ -297,7 +325,7 @@ Summary: The Linux kernel (the core of t # %define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1 -Name: kernel +Name: kernel%{?variant} Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} @@ -332,7 +360,9 @@ BuildPreReq: bzip2, findutils, gzip, m4, BuildPreReq: gnupg %endif BuildRequires: gcc >= 3.4.2, binutils >= 2.12, redhat-rpm-config +%if %{usesparse} BuildRequires: sparse >= 0.3 +%endif BuildConflicts: rhbuildsys(DiskFree) < 500Mb @@ -380,7 +410,16 @@ Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic +%if %{using_upstream_branch} +### BRANCH PATCH ### +%else +# Here should be only the patches up to the upstream canonical Linus tree. Patch00: patch-2.6.22-rc4.bz2 +%endif + +%if !%{nopatches} + +# Patches 10 through 99 are for things that are going upstream really soon. Patch10: linux-2.6-utrace.patch Patch20: nouveau-drm.patch Patch30: linux-2.6-sysrq-c.patch @@ -849,10 +888,16 @@ ApplyPatch() patch -p1 -F1 -s < $RPM_SOURCE_DIR/$1 } +%if %{using_upstream_branch} +### BRANCH APPLY ### +%else # Update to latest upstream. bzcat $RPM_SOURCE_DIR/patch-2.6.22-rc4.bz2 | patch -p1 -F1 -s +%endif +%if !%{nopatches} + # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. @@ -895,12 +940,14 @@ ApplyPatch linux-2.6-pmac-zilog.patch # # 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). -ApplyPatch linux-2.6-build-nonintconfig.patch +ApplyPatch linux-2.6.17-build-nonintconfig.patch +%if !%{nopatches} # Exec shield ApplyPatch linux-2.6-execshield.patch @@ -1076,6 +1123,7 @@ ApplyPatch linux-2.6-warnings-emptymacro ApplyPatch linux-2.6-warnings-register.patch # END OF PATCH APPLICATIONS +%endif cp %{SOURCE10} Documentation/ @@ -1098,7 +1146,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 @@ -1184,7 +1232,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 From davej at redhat.com Fri Jun 8 20:03:51 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 8 Jun 2007 16:03:51 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070608195926.9A5134D059C@magilla.localdomain> References: <20070608195926.9A5134D059C@magilla.localdomain> Message-ID: <20070608200351.GB7114@redhat.com> On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote: > Here I am again with those hacks to do alternate builds from the kernel > spec file. Can I commit at least the spec parts to rawhide now? > > The diff is only this: > > # 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). > -ApplyPatch linux-2.6-build-nonintconfig.patch > +ApplyPatch linux-2.6.17-build-nonintconfig.patch This bit looks odd. No other objections though. (Don't forget to add a changelog entry) Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Fri Jun 8 20:05:41 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 15:05:41 -0500 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070608200351.GB7114@redhat.com> References: <20070608195926.9A5134D059C@magilla.localdomain> <20070608200351.GB7114@redhat.com> Message-ID: <1181333141.17463.23.camel@vader.jdub.homelinux.org> On Fri, 2007-06-08 at 16:03 -0400, Dave Jones wrote: > On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote: > > Here I am again with those hacks to do alternate builds from the kernel > > spec file. Can I commit at least the spec parts to rawhide now? > > > > The diff is only this: > > > > # 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). > > -ApplyPatch linux-2.6-build-nonintconfig.patch > > +ApplyPatch linux-2.6.17-build-nonintconfig.patch > > This bit looks odd. > > No other objections though. (Don't forget to add a changelog entry) Just wondering about the usesparse macro. Any reason to conditionalize running sparse on it? josh From roland at redhat.com Fri Jun 8 20:20:29 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 8 Jun 2007 13:20:29 -0700 (PDT) Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: Josh Boyer's message of Friday, 8 June 2007 15:05:41 -0500 <1181333141.17463.23.camel@vader.jdub.homelinux.org> Message-ID: <20070608202029.DB4014D059D@magilla.localdomain> > Just wondering about the usesparse macro. Any reason to conditionalize > running sparse on it? The only change in my diff is not to buildrequire sparse when not using it. The reasons to conditionalize are unrelated to this change. (They are some arch problems in sparse, and sparse not in repos for buildrequire in fc<7, in case this spec is copied for later fc[56] updates.) Thanks, Roland From roland at redhat.com Fri Jun 8 20:30:29 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 8 Jun 2007 13:30:29 -0700 (PDT) Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: Dave Jones's message of Friday, 8 June 2007 16:03:51 -0400 <20070608200351.GB7114@redhat.com> Message-ID: <20070608203029.A466C4D05A0@magilla.localdomain> > On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote: > > Here I am again with those hacks to do alternate builds from the kernel > > spec file. Can I commit at least the spec parts to rawhide now? > > > > The diff is only this: > > > > # 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). > > -ApplyPatch linux-2.6-build-nonintconfig.patch > > +ApplyPatch linux-2.6.17-build-nonintconfig.patch > > This bit looks odd. Oh, yeah, that bit will not be there. Instead I'll replace linux-2.6-build-nonintconfig.patch with my version (posted here before), which adds loose_nonint_oldconfig. I committed it. A little more tweaking was actually necessary, since something changed since last time I used this. Ironically, the kernel-vanilla build works now though the normal build doesn't because of configs lag. I also took the liberty of enabling usesparse for F>=7 since I noticed it was always off now. I'll follow up shortly with the makefile bits. Thanks, Roland From roland at redhat.com Fri Jun 8 20:37:30 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 8 Jun 2007 13:37:30 -0700 (PDT) Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: Dave Jones's message of Friday, 8 June 2007 16:03:51 -0400 <20070608200351.GB7114@redhat.com> Message-ID: <20070608203730.BF4E84D05A0@magilla.localdomain> Oops, I accidentally checked in my Makefile too. So I guess I'll just assume you thought its changes were good. ;-) This one copies some extras-style boilerplate that is necessary if you have a whole-tree checkout of /cvs/pkgs/rpms. It does not give you individual foobar/common/ checkouts like it will if you do "cvs co foobar", and the old extras style was for everything to use your single common/ checkout at the top. This is now the standard boilerplate apparently, which every formerly Core package needs to work with whole-tree checkouts. The rest (cvs diff -r 1.49 -r 1.50 Makefile) is all additions at the end. You can use "make vanilla-x86_64" or "make vanilla-prep" or whatnot, and various git/blah targets. The details were previously discussed here, and are in comments in the makefile additions. @@ -14,7 +14,22 @@ UPSTREAM_CHECKS = sign # local targets we need to carry around in addition to the default sources TARGETS = configs download -include ../common/Makefile.common +define find-makefile-common +for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done +endef + +MAKEFILE_COMMON := $(shell $(find-makefile-common)) + +ifeq ($(MAKEFILE_COMMON),) +# attept a checkout +define checkout-makefile-common +test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo "common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to checkout the 'common' module." ; exit -1 ; } >&2 +endef + +MAKEFILE_COMMON := $(shell $(checkout-makefile-common)) +endif + +include $(MAKEFILE_COMMON) include Makefile.config debug: Thanks, Roland From brugolsky at telemetry-investments.com Fri Jun 8 20:40:01 2007 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 8 Jun 2007 16:40:01 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070608172405.GO27332@redhat.com> References: <20070607191737.GA6054@redhat.com> <46697ADA.1090809@gmail.com> <20070608172405.GO27332@redhat.com> Message-ID: <20070608204001.GD31247@ti88.telemetry-investments.com> On Fri, Jun 08, 2007 at 01:24:05PM -0400, Dave Jones wrote: > On Fri, Jun 08, 2007 at 05:50:50PM +0200, dragoran wrote: > > > this would mean that we will might end up having cfs as the scheduler > > and tickless x86_64. > > I mostly using x86_64 ... where there any major problems (exept the dell > > one) related to tickless kernels in the F7 cycle? > > Too early to say really. There were a number of oddball bugs > that still aren't really understood that could be related, > but on the whole it hasn't been /that/ bad considering the > amount of code that changed. I've generally been including Thomas's (pre-dynticks) hrtimers patch in my custom kernels since 2.6.15, but after upgrading lots of boxes to FC6, we've been running stock Fedora kernels (FC6 and FC7t*) on lots of boxes. While there have been minor problems on x86, on x86_64 we experienced severe NTP timekeeping regressions (including losing sync) due mostly to various hardware latency problems (SATA chipsets problems, SMI, etc.). The x86_64 hrtimers patchset works around the problem, and everything keep times to within a millisecond. So I hope to see the x86_64 tickless patches upstream ASAP. Regards, Bill From Axel.Thimm at ATrpms.net Fri Jun 8 20:08:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 22:08:12 +0200 Subject: atop? In-Reply-To: <20070608194734.GE12358@nostromo.devel.redhat.com> References: <20070608194109.GA4263@neu.nirvana> <20070608194332.GD12358@nostromo.devel.redhat.com> <20070608194828.GB4263@neu.nirvana> <20070608194734.GE12358@nostromo.devel.redhat.com> Message-ID: <20070608200812.GC4263@neu.nirvana> On Fri, Jun 08, 2007 at 03:47:34PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > These patches: > > > > > > a) aren't upstream > > > b) change the format of /proc/stat > > > c) change process accounting in an incompatible way > > > > > > So... no. > > > > OK, fair enough (I wasn't aware of b) and c)). > > > > Any other way then to achive the stated goals? > > I haven't tried, but blktrace? Very nice! One does get process -> I/O bandwidth. No filesystem info, though, but I shouldn't be greedy ;) If I find a minute I'll submit a package for this. Thanks for pushing me to the right track! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Fri Jun 8 22:11:15 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Jun 2007 23:11:15 +0100 Subject: iwl3945 Message-ID: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> Hi, I have a laptop with an ipw3945 wireless adapter and with F7 installed, things are quite.... flakey. Looking at forums and mailing lists I see I'm not suffering alone. So, I was wondering what would be useful information to help debug this, beyond "it doesn't work very well". TIA Jonathan. From tibbs at math.uh.edu Sat Jun 9 00:41:03 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jun 2007 19:41:03 -0500 Subject: iwl3945 In-Reply-To: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> References: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> So, I was wondering what would be useful information to help debug JU> this, beyond "it doesn't work very well". Well, the latest F8 kernels have a newer version of the iwlwifi drivers; some folks have reported that it works much better for them. It still doesn't work for me, but maybe you'll get lucky. - J< From snecklifter at gmail.com Sat Jun 9 12:58:59 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sat, 9 Jun 2007 13:58:59 +0100 Subject: iwl3945 In-Reply-To: References: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> Message-ID: <364d303b0706090558i7971f0fete54a99a24d7daa3a@mail.gmail.com> On 08 Jun 2007 19:41:03 -0500, Jason L Tibbitts III wrote: > > >>>>> "JU" == Jonathan Underwood writes: > > JU> So, I was wondering what would be useful information to help debug > JU> this, beyond "it doesn't work very well". > > Well, the latest F8 kernels have a newer version of the iwlwifi > drivers; some folks have reported that it works much better for them. > It still doesn't work for me, but maybe you'll get lucky. You can both try the latest test kernels for F7 at http://people.redhat.com/davej/kernels/Fedora/fc7/ Feedback is good as this is a big sticking point for people at the moment. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Sun Jun 10 20:19:56 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 10 Jun 2007 22:19:56 +0200 Subject: kernel modules not stripped? Message-ID: <466C5CEC.40602@gmail.com> I have read a thread on lkml about stripped and not stripped modules... so I checked if they are in fedora (2.6.21-1.3194.fc7) and it seems that they aren't. so I tested how much it would gain (size) so I picked some random module (sata_nv.ko) copied it to my home folder and did the test: original size: 40512 stripped size: 26912 so it seems that we are wasting ~50% of space by not doing this. reason for this? note: this was on x86_64 From roland at redhat.com Sun Jun 10 20:58:38 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 10 Jun 2007 13:58:38 -0700 (PDT) Subject: kernel modules not stripped? In-Reply-To: dragoran's message of Sunday, 10 June 2007 22:19:56 +0200 <466C5CEC.40602@gmail.com> Message-ID: <20070610205838.A32D74D05B4@magilla.localdomain> Kernel modules have their debuginfo stripped out (into kernel*debuginfo). They cannot be stripped more than that without breaking intermodule symbol resolution. From dhollis at davehollis.com Mon Jun 11 14:43:22 2007 From: dhollis at davehollis.com (David Hollis) Date: Mon, 11 Jun 2007 10:43:22 -0400 Subject: iwl3945 In-Reply-To: <364d303b0706090558i7971f0fete54a99a24d7daa3a@mail.gmail.com> References: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> <364d303b0706090558i7971f0fete54a99a24d7daa3a@mail.gmail.com> Message-ID: <1181573002.3480.7.camel@dhollis-lnx.sunera.com> On Sat, 2007-06-09 at 13:58 +0100, Chris Brown wrote: > On 08 Jun 2007 19:41:03 -0500, Jason L Tibbitts III > wrote: > > You can both try the latest test kernels for F7 at > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > Feedback is good as this is a big sticking point for people at the > moment. I bumped up to 3219 late last week and that actually made iwl3945 work for me, which it never really did before. It seemed to flake out after some period (maybe 10-12 hours) where it wouldn't seem to send packets any longer, I could rejoin the network and get an IP, but couldn't ping anything. A reboot seemed to make it a bit better. So it seems like it's getting there, but isn't 100% ready just yet. -- David Hollis From williams at redhat.com Mon Jun 11 18:28:10 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 11 Jun 2007 13:28:10 -0500 Subject: iwl3945 In-Reply-To: <1181573002.3480.7.camel@dhollis-lnx.sunera.com> References: <645d17210706081511q60d59368sb3bbcff039911290@mail.gmail.com> <364d303b0706090558i7971f0fete54a99a24d7daa3a@mail.gmail.com> <1181573002.3480.7.camel@dhollis-lnx.sunera.com> Message-ID: <466D943A.2020102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Hollis wrote: > On Sat, 2007-06-09 at 13:58 +0100, Chris Brown wrote: >> On 08 Jun 2007 19:41:03 -0500, Jason L Tibbitts III >> wrote: > >> You can both try the latest test kernels for F7 at >> >> http://people.redhat.com/davej/kernels/Fedora/fc7/ >> >> Feedback is good as this is a big sticking point for people at the >> moment. > > I bumped up to 3219 late last week and that actually made iwl3945 work for me, which it never really did before. It seemed to flake out after some period (maybe 10-12 hours) where it wouldn't seem to send packets any longer, I could rejoin the network and get an IP, but couldn't ping anything. A reboot seemed to make it a bit better. So it seems like it's getting there, but isn't 100% ready just yet. > It's been getting progressively better for me. (T60+rawhide+NM) The 3218 kernel works for a while, then flakes and I have to reload the module and restart NM before it works again. Haven't tried 3219 yet. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGbZQ6Hyuj/+TTEp0RAgeuAKCskHZhBdyWYfAMPOUoTOhAbokAcACgvOr0 fQZeB8PXpBK77sOYlG3yQMw= =xD26 -----END PGP SIGNATURE----- From roland at redhat.com Mon Jun 11 20:46:44 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Jun 2007 13:46:44 -0700 (PDT) Subject: fedora kernel utrace updates Message-ID: <20070611204644.CA8284D05A4@magilla.localdomain> I've started using quilt to maintain backport versions of my utrace patches. http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and 2.6.20.11 (for FC-6). Done this way it is easy for me to plop in the new utrace/ptrace code from the bleeding edge version when I have fixes, without repeating the backport work, which is confined to the earlier patches in the series. Since quilt doesn't have a handy feature for generating a single patch, and I know better than to trust combinediff, I'd like to switch the Fedora update kernels to using the broken out patches separately in the spec file. If one were actually trying to keep track, this also makes it a little easier to follow the changed patches in cvs, since there will be less flutter around parts that aren't actually changing. Any problem with that? Whoever is maintaining each update stream can tell me how they'd prefer to handle updates. You can snarf from my people page at will, or I can just commit changed patches when I have a significant fix, or whatever. For rawhide, it doesn't really matter to me one way or the other about using the one patch or the series. The "trunk" patchset is generated from GIT, not quilt, and I already have scripts that generate the one patch we use now. If there is no reason not to, I'd probably switch it to using the series just for consistency. The F-7 spec change looks like this. I renumbered some nearby patches to give utrace the 10-30 range. Thanks, Roland Index: kernel-2.6.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/F-7/kernel-2.6.spec,v retrieving revision 1.3226 diff -u -b -p -r1.3226 kernel-2.6.spec --- kernel-2.6.spec 10 Jun 2007 01:28:50 -0000 1.3226 +++ kernel-2.6.spec 11 Jun 2007 20:40:07 -0000 @@ -397,20 +397,37 @@ Patch2: patch-2.6.21.5-rc2.bz2 Patch3: stable-reverts.patch # Patches 10 through 99 are for things that are going upstream really soon. -Patch10: linux-2.6-utrace.patch -Patch11: nouveau-drm.patch -Patch12: linux-2.6-fix-pmops-1.patch -Patch13: linux-2.6-fix-pmops-2.patch -Patch14: linux-2.6-fix-pmops-3.patch -Patch15: linux-2.6-fix-pmops-4.patch +Patch10: linux-2.6-sig_kernel-macros.patch +Patch11: linux-2.6-recalc_sigpending_and_wake.patch +Patch12: linux-2.6-utrace-tracehook.patch +Patch13: linux-2.6-utrace-tracehook-ia64.patch +Patch14: linux-2.6-utrace-tracehook-sparc64.patch +Patch15: linux-2.6-utrace-tracehook-s390.patch +Patch16: linux-2.6-utrace-tracehook-um.patch +Patch17: linux-2.6-utrace-regset.patch +Patch18: linux-2.6-utrace-regset-ia64.patch +Patch19: linux-2.6-utrace-regset-sparc64.patch +Patch20: linux-2.6-utrace-regset-s390.patch +Patch21: linux-2.6-utrace-core.patch +Patch22: linux-2.6-utrace-ptrace-compat.patch +Patch23: linux-2.6-utrace-ptrace-compat-ia64.patch +Patch24: linux-2.6-utrace-ptrace-compat-sparc64.patch +Patch25: linux-2.6-utrace-ptrace-compat-s390.patch + +Patch30: nouveau-drm.patch + +Patch42: linux-2.6-fix-pmops-1.patch +Patch43: linux-2.6-fix-pmops-2.patch +Patch44: linux-2.6-fix-pmops-3.patch +Patch45: linux-2.6-fix-pmops-4.patch # enable sysrq-c on all kernels, not only kexec # FIXME: upstream soon? When? It's been here for ages. -Patch16: linux-2.6-sysrq-c.patch +Patch46: linux-2.6-sysrq-c.patch # DRM bits for 965 -Patch17: linux-2.6-i965gm-support.patch +Patch47: linux-2.6-i965gm-support.patch # Patches 100 through 500 are meant for architecture patches @@ -1050,25 +1067,42 @@ cd linux-%{kversion}.%{_target_cpu} # Update to latest upstream. %patch1 -p1 %patch2 -p1 -%patch3 -p1 -R +%%patch3 -p1 -R # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. %patch10 -p1 %patch11 -p1 - -# Power management fixes %patch12 -p1 %patch13 -p1 %patch14 -p1 %patch15 -p1 +%patch16 -p1 +%patch17 -p1 +%patch18 -p1 +%patch19 -p1 +%patch20 -p1 +%patch21 -p1 +%patch22 -p1 +%patch23 -p1 +%patch24 -p1 +%patch25 -p1 + +# nouveau-drm +%patch30 -p1 + +# Power management fixes +%patch42 -p1 +%patch43 -p1 +%patch44 -p1 +%patch45 -p1 # sysrq works always -%patch16 -p1 +%patch46 -p1 # DRM support for 965GM -%patch17 -p1 +%patch47 -p1 # Architecture patches From roland at redhat.com Mon Jun 11 20:48:48 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Jun 2007 13:48:48 -0700 (PDT) Subject: quilt-import script Message-ID: <20070611204848.976944D05A4@magilla.localdomain> Btw, I wrote this script that is scripts/import-series in my tree. For the utrace series I used: scripts/import-series ~/redhat/people/utrace/2.6.21 10 linux-2.6- Thanks, Roland --- #!/bin/sh if [ $# -ne 2 -a $# -ne 3 ]; then echo >&2 "Usage: $0 QUILT-PATCHES-DIR FIRST-PATCHN [PREFIX]" exit 1 fi dir="$1" first="$2" prefix="$3" n=$first QUILT_PATCHES="$dir" quilt series | { while read patch; do cp "$dir/$patch" "$prefix$patch" echo "Patch$n: $prefix$patch" n=$[$n + 1] done echo i=$first while (( i < n )); do echo "%patch$i -p1" i=$[$i + 1] done } From cebbert at redhat.com Mon Jun 11 21:22:10 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 11 Jun 2007 17:22:10 -0400 Subject: fedora kernel utrace updates In-Reply-To: <20070611204644.CA8284D05A4@magilla.localdomain> References: <20070611204644.CA8284D05A4@magilla.localdomain> Message-ID: <466DBD02.8070104@redhat.com> On 06/11/2007 04:46 PM, Roland McGrath wrote: > I've started using quilt to maintain backport versions of my utrace patches. > http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and > 2.6.20.11 (for FC-6). Done this way it is easy for me to plop in the new > utrace/ptrace code from the bleeding edge version when I have fixes, without > repeating the backport work, which is confined to the earlier patches in the > series. > > Since quilt doesn't have a handy feature for generating a single patch, and > I know better than to trust combinediff, I'd like to switch the Fedora > update kernels to using the broken out patches separately in the spec file. > If one were actually trying to keep track, this also makes it a little > easier to follow the changed patches in cvs, since there will be less > flutter around parts that aren't actually changing. > 'quilt snapshot' can be used to make combined patches, but I prefer the separate patches anyway. For FC6 I'd prefer to do the commits; if you'd notify us when you make a change that would help. From davej at redhat.com Mon Jun 11 21:30:29 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Jun 2007 17:30:29 -0400 Subject: fedora kernel utrace updates In-Reply-To: <466DBD02.8070104@redhat.com> References: <20070611204644.CA8284D05A4@magilla.localdomain> <466DBD02.8070104@redhat.com> Message-ID: <20070611213029.GD27634@redhat.com> On Mon, Jun 11, 2007 at 05:22:10PM -0400, Chuck Ebbert wrote: > On 06/11/2007 04:46 PM, Roland McGrath wrote: > > I've started using quilt to maintain backport versions of my utrace patches. > > http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and > > 2.6.20.11 (for FC-6). Done this way it is easy for me to plop in the new > > utrace/ptrace code from the bleeding edge version when I have fixes, without > > repeating the backport work, which is confined to the earlier patches in the > > series. > > > > Since quilt doesn't have a handy feature for generating a single patch, and > > I know better than to trust combinediff, I'd like to switch the Fedora > > update kernels to using the broken out patches separately in the spec file. > > If one were actually trying to keep track, this also makes it a little > > easier to follow the changed patches in cvs, since there will be less > > flutter around parts that aren't actually changing. > > > > 'quilt snapshot' can be used to make combined patches, but I prefer > the separate patches anyway. For FC6 I'd prefer to do the commits; > if you'd notify us when you make a change that would help. Same goes for F-7 I guess. For devel however, it's a bit of a pain to have to disable a dozen ApplyPatch's during the (brief) window when I rebase, and you haven't rediffed utrace yet (if its trivial, I've done it myself in the past, but it isn't always the case..) In more recent times, I actually as part of my daily -git rebasing have this tied into my scripts.. rm -f linux-2.6-utrace.patch wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch So roll-up patches are still kinda handy for making that sort of thing a breeze. Better yet of course would be upstream integration, making this whole problem go away. But then, you knew that :) Dave -- http://www.codemonkey.org.uk From davej at redhat.com Mon Jun 11 21:31:06 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Jun 2007 17:31:06 -0400 Subject: fedora kernel utrace updates In-Reply-To: <20070611204644.CA8284D05A4@magilla.localdomain> References: <20070611204644.CA8284D05A4@magilla.localdomain> Message-ID: <20070611213106.GE27634@redhat.com> On Mon, Jun 11, 2007 at 01:46:44PM -0700, Roland McGrath wrote: > -%patch3 -p1 -R > +%%patch3 -p1 -R What happened there ? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Mon Jun 11 21:34:06 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Jun 2007 14:34:06 -0700 (PDT) Subject: fedora kernel utrace updates In-Reply-To: Dave Jones's message of Monday, 11 June 2007 17:31:06 -0400 <20070611213106.GE27634@redhat.com> Message-ID: <20070611213406.E07524D05A4@magilla.localdomain> > On Mon, Jun 11, 2007 at 01:46:44PM -0700, Roland McGrath wrote: > > -%patch3 -p1 -R > > +%%patch3 -p1 -R > > What happened there ? Oops, sorry just a typo from a few days ago when I had to comment that out. From roland at redhat.com Mon Jun 11 21:40:50 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Jun 2007 14:40:50 -0700 (PDT) Subject: fedora kernel utrace updates In-Reply-To: Chuck Ebbert's message of Monday, 11 June 2007 17:22:10 -0400 <466DBD02.8070104@redhat.com> Message-ID: <20070611214050.1D5C74D05A4@magilla.localdomain> > 'quilt snapshot' can be used to make combined patches, but I prefer Ah, you mean "quilt pop -a && quilt snapshot && quilt push -a" and then "quilt diff --snapshot". I hadn't noticed that. > the separate patches anyway. For FC6 I'd prefer to do the commits; > if you'd notify us when you make a change that would help. Right now the backport series have some fixes not in update kernels. I haven't done very exhaustive testing after the fresh backport work, so there might be some regression there and I wouldn't push those before I get some folks to do more testing. If you aren't pushing an update real soon anyway, now would be a good time to commit and do some unreleased builds I can have people test. I am still working on some known bugs, and so there will be more updates some time soon. I'll let you know when all the pending issues are settled, but if you do updates before then the current code is probably better than status quo already. Thanks, Roland From roland at redhat.com Mon Jun 11 21:44:04 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Jun 2007 14:44:04 -0700 (PDT) Subject: fedora kernel utrace updates In-Reply-To: Dave Jones's message of Monday, 11 June 2007 17:30:29 -0400 <20070611213029.GD27634@redhat.com> Message-ID: <20070611214404.48AFC4D05A4@magilla.localdomain> > Same goes for F-7 I guess. For devel however, it's a bit of a pain to > have to disable a dozen ApplyPatch's during the (brief) window Really? Inserting "true || {" before and "}" after seems not much worse than commenting out a line or two. > when I rebase, and you haven't rediffed utrace yet (if its trivial, > I've done it myself in the past, but it isn't always the case..) Anyway, most of the time now I'm rebasing every day, lately more often than rawhide. > In more recent times, I actually as part of my daily -git rebasing > have this tied into my scripts.. > rm -f linux-2.6-utrace.patch > wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch Both forms will continue to be available there, so whatever works for you. > Better yet of course would be upstream integration, making this > whole problem go away. But then, you knew that :) Yes, well. 2.6.23 is sort of plausible I guess. Thanks, Roland From davej at redhat.com Mon Jun 11 22:05:31 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Jun 2007 18:05:31 -0400 Subject: fedora kernel utrace updates In-Reply-To: <20070611214404.48AFC4D05A4@magilla.localdomain> References: <20070611213029.GD27634@redhat.com> <20070611214404.48AFC4D05A4@magilla.localdomain> Message-ID: <20070611220531.GG27634@redhat.com> On Mon, Jun 11, 2007 at 02:44:04PM -0700, Roland McGrath wrote: > > Same goes for F-7 I guess. For devel however, it's a bit of a pain to > > have to disable a dozen ApplyPatch's during the (brief) window > > Really? Inserting "true || {" before and "}" after seems not much worse than > commenting out a line or two. yeah, could do it like that I suppose. > > In more recent times, I actually as part of my daily -git rebasing > > have this tied into my scripts.. > > rm -f linux-2.6-utrace.patch > > wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch > > Both forms will continue to be available there, so whatever works for you. cool. > > Better yet of course would be upstream integration, making this > > whole problem go away. But then, you knew that :) > > Yes, well. 2.6.23 is sort of plausible I guess. That would tie in nicely for F8. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Tue Jun 12 22:19:21 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 12 Jun 2007 18:19:21 -0400 Subject: fedora kernel utrace updates In-Reply-To: <20070611214050.1D5C74D05A4@magilla.localdomain> References: <20070611214050.1D5C74D05A4@magilla.localdomain> Message-ID: <466F1BE9.3020207@redhat.com> On 06/11/2007 05:40 PM, Roland McGrath wrote: > Right now the backport series have some fixes not in update kernels. I > haven't done very exhaustive testing after the fresh backport work, so > there might be some regression there and I wouldn't push those before I get > some folks to do more testing. If you aren't pushing an update real soon > anyway, now would be a good time to commit and do some unreleased builds I > can have people test. > In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel out but really want to get this update in. If it's broken I can revert. From fedora at leemhuis.info Wed Jun 13 14:29:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 16:29:46 +0200 Subject: mkinitrd. dep (was: Re: rpms/kernel/F-7 kernel-2.6.spec, 1.3226, 1.3227) In-Reply-To: <200706121823.l5CINsa2030483@cvs-int.fedora.redhat.com> References: <200706121823.l5CINsa2030483@cvs-int.fedora.redhat.com> Message-ID: <466FFF5A.70706@leemhuis.info> Hi! On 12.06.2007 20:23, Dave Jones (davej) wrote: > Author: davej > > Update of /cvs/pkgs/rpms/kernel/F-7 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30425 > > Modified Files: > kernel-2.6.spec > Log Message: > * Tue Jun 12 2007 Dave Jones > - Require at least version 6.0.9-7.1 of mkinitrd. > [...] > -%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1 > +%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-7.1 > [...] > > %changelog > +* Tue Jun 12 2007 Dave Jones > +- Require at least version 6.0.9-7.1 of > + Dave, could you do me a small favor and in situations like this (and more important: in the devel tree) please mention why a new mkinitrd is needed (if possible without much hassle)? tia! It's not that important, but would be nice to know now and then -- especially in situations I often run into: downloaded a new kernel on machine foo, put it on a USB stick, go with it to computer bar, try to install it with rpm directly because the old kernel has no network support for that machine and fail because I need a new mkinitrd... if I knew that a new mkinitrd is just needed for some obscure bug I then might just use "--nodeps" instead of going back to machine foo to download the the new mkinitrd . CU thl From davej at redhat.com Wed Jun 13 16:02:46 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Jun 2007 12:02:46 -0400 Subject: mkinitrd. dep (was: Re: rpms/kernel/F-7 kernel-2.6.spec, 1.3226, 1.3227) In-Reply-To: <466FFF5A.70706@leemhuis.info> References: <200706121823.l5CINsa2030483@cvs-int.fedora.redhat.com> <466FFF5A.70706@leemhuis.info> Message-ID: <20070613160246.GD3875@redhat.com> On Wed, Jun 13, 2007 at 04:29:46PM +0200, Thorsten Leemhuis wrote: > Hi! > > On 12.06.2007 20:23, Dave Jones (davej) wrote: > > Author: davej > > > > Update of /cvs/pkgs/rpms/kernel/F-7 > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30425 > > > > Modified Files: > > kernel-2.6.spec > > Log Message: > > * Tue Jun 12 2007 Dave Jones > > - Require at least version 6.0.9-7.1 of mkinitrd. > > [...] > > -%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1 > > +%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-7.1 > > [...] > > > > %changelog > > +* Tue Jun 12 2007 Dave Jones > > +- Require at least version 6.0.9-7.1 of > > + > > Dave, could you do me a small favor and in situations like this (and > more important: in the devel tree) please mention why a new mkinitrd is > needed (if possible without much hassle)? tia! > > It's not that important, but would be nice to know now and then -- > especially in situations I often run into: downloaded a new kernel on > machine foo, put it on a USB stick, go with it to computer bar, try to > install it with rpm directly because the old kernel has no network > support for that machine and fail because I need a new mkinitrd... if I > knew that a new mkinitrd is just needed for some obscure bug I then > might just use "--nodeps" instead of going back to machine foo to > download the the new mkinitrd . It was in the changelog, which was also in the announcement. Where else should I put it ? Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Wed Jun 13 16:23:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 18:23:10 +0200 Subject: mkinitrd. dep In-Reply-To: <20070613160246.GD3875@redhat.com> References: <200706121823.l5CINsa2030483@cvs-int.fedora.redhat.com> <466FFF5A.70706@leemhuis.info> <20070613160246.GD3875@redhat.com> Message-ID: <467019EE.6080403@leemhuis.info> On 13.06.2007 18:02, Dave Jones wrote: > On Wed, Jun 13, 2007 at 04:29:46PM +0200, Thorsten Leemhuis wrote: > > Hi! > > > > On 12.06.2007 20:23, Dave Jones (davej) wrote: > > > Author: davej > > > > > > Update of /cvs/pkgs/rpms/kernel/F-7 > > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30425 > > > > > > Modified Files: > > > kernel-2.6.spec > > > Log Message: > > > * Tue Jun 12 2007 Dave Jones > > > - Require at least version 6.0.9-7.1 of mkinitrd. > > > [...] > > > -%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1 > > > +%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-7.1 > > > [...] > > > > > > %changelog > > > +* Tue Jun 12 2007 Dave Jones > > > +- Require at least version 6.0.9-7.1 of > > > + > > > > Dave, could you do me a small favor and in situations like this (and > > more important: in the devel tree) please mention why a new mkinitrd is ^^^ > > needed (if possible without much hassle)? tia! > > > > It's not that important, but would be nice to know now and then -- > > especially in situations I often run into: downloaded a new kernel on > > machine foo, put it on a USB stick, go with it to computer bar, try to > > install it with rpm directly because the old kernel has no network > > support for that machine and fail because I need a new mkinitrd... if I > > knew that a new mkinitrd is just needed for some obscure bug I then > > might just use "--nodeps" instead of going back to machine foo to > > download the the new mkinitrd . > > It was in the changelog, which was also in the announcement. > Where else should I put it ? It? Either I'm blind or my E-Mail was misleading. I only see "Require at least version 6.0.9-7.1 of mkinitrd.", but I don't know *why* I need at least that version; that's what I'd like to know. CU thl From davej at redhat.com Wed Jun 13 16:37:37 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Jun 2007 12:37:37 -0400 Subject: mkinitrd. dep In-Reply-To: <467019EE.6080403@leemhuis.info> References: <200706121823.l5CINsa2030483@cvs-int.fedora.redhat.com> <466FFF5A.70706@leemhuis.info> <20070613160246.GD3875@redhat.com> <467019EE.6080403@leemhuis.info> Message-ID: <20070613163737.GA12648@redhat.com> On Wed, Jun 13, 2007 at 06:23:10PM +0200, Thorsten Leemhuis wrote: > > It was in the changelog, which was also in the announcement. > > Where else should I put it ? > > It? Either I'm blind or my E-Mail was misleading. > > I only see "Require at least version 6.0.9-7.1 of mkinitrd.", but I > don't know *why* I need at least that version; that's what I'd like to know. Ah, I missed the 'why' part somehow. Pretty boring really.. we pushed a broken mkinitrd out to updates-testing, followed by a fixed one. To guarantee that people wouldn't install the new kernel with the bad mkinitrd installed, I bumped the req. Dave -- http://www.codemonkey.org.uk From riel at redhat.com Wed Jun 13 20:11:40 2007 From: riel at redhat.com (Rik van Riel) Date: Wed, 13 Jun 2007 16:11:40 -0400 Subject: F7 redux, and the road to F8. In-Reply-To: <20070607203033.GA27332@redhat.com> References: <20070607191737.GA6054@redhat.com> <1181245085.26928.55.camel@erebor.boston.redhat.com> <20070607203033.GA27332@redhat.com> Message-ID: <46704F7C.9080102@redhat.com> Dave Jones wrote: > On Thu, Jun 07, 2007 at 03:38:05PM -0400, Jeremy Katz wrote: > > > > Xen. > > > ~~~~ > > > This might get interesting to watch for F8 if XenU gets upstream > > > (Which akpm seems to suggest it might). Given we've decoupled > > > kernel/kernel-xen, we might want to just disable the upstream variant > > > until F9, and wait until we have both the dom0 and the domU stuff > > > coming from the same pieces. Will need more discussion with > > > the virtualisation team when that lands in Linus' tree. > > > > And there's also the kvm-xen stuff that could serve as a replacement for > > the dom0 bits :-) Even if not, it's probably worth getting the domU > > bits into the regular kernel because then we can simplify some of the > > installer stuff quite a bit. > > With dom0 coming from one place and domU from another, I get the creeps > about ABI differences when they're on different versions. No worries there. RHEL5 GA Xen kernels run on the latest Xen hypervisor, without any patches applied. This is the dom0 kernel, even ... The guest interface is even more stable. -- All Rights Reversed From roland at redhat.com Thu Jun 14 10:19:10 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 14 Jun 2007 03:19:10 -0700 (PDT) Subject: fedora kernel utrace updates In-Reply-To: Chuck Ebbert's message of Tuesday, 12 June 2007 18:19:21 -0400 <466F1BE9.3020207@redhat.com> Message-ID: <20070614101910.DB5894D059F@magilla.localdomain> > In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel > out but really want to get this update in. If it's broken I can revert. I haven't gotten folks to test that build yet, but already I have a few more fixes (242694, 244162). The updated patches are on the web (all versions). Brew task 820195 is a scratch build of 1.2960.fc6 using a newer utrace patch. Hopefully I'll get some testing done on that when it finishes. Thanks, Roland From davidz at redhat.com Fri Jun 15 13:24:09 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 15 Jun 2007 09:24:09 -0400 Subject: uevent order fix Message-ID: <1181913849.2727.4.camel@zelda.fubar.dk> Dave, Please take a look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c7afd125cc482dbdf6b0a169c42337e7e76cda5 Can we include this simple patch in Fedora 7 and Rawhide please? Without this, events arrive in the wrong order meaning that udev and hal may get confused. Thanks. David From davej at redhat.com Fri Jun 15 19:29:25 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 15 Jun 2007 15:29:25 -0400 Subject: uevent order fix In-Reply-To: <1181935330.2727.33.camel@zelda.fubar.dk> References: <1181913849.2727.4.camel@zelda.fubar.dk> <20070615185910.GC23417@redhat.com> <1181935330.2727.33.camel@zelda.fubar.dk> Message-ID: <20070615192925.GD23417@redhat.com> On Fri, Jun 15, 2007 at 03:22:10PM -0400, David Zeuthen wrote: > On Fri, 2007-06-15 at 14:59 -0400, Dave Jones wrote: > > On Fri, Jun 15, 2007 at 09:24:09AM -0400, David Zeuthen wrote: > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c7afd125cc482dbdf6b0a169c42337e7e76cda5 > > > > > > Can we include this simple patch in Fedora 7 and Rawhide please? Without > > > this, events arrive in the wrong order meaning that udev and hal may get > > > confused. Thanks. > > > > Are you sure this is the diff you want? The changelog comment doesn't > > really imply anything regarding ordering. > > Yea, I'm 100% positive - the problem is that uevents for "struct > class_device" don't include the PHYSDEV* variables. This makes it > impossible for udev to reorder the events, e.g. wait for the device that > PHYSDEVPATH that the class device specifies. As a result you sometimes > get to process the event for an input device *before* the physical > device (e.g. USB interface) have been processed. SCSI generic devices > are affected in a similar way. ok, kernel-2_6_21-1_3222_fc8 is building which should have it tomorrow. I've no objection to including it (as long as it doesn't have additional dependancies). Chuck? anyone else? Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Fri Jun 15 19:22:10 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 15 Jun 2007 15:22:10 -0400 Subject: uevent order fix In-Reply-To: <20070615185910.GC23417@redhat.com> References: <1181913849.2727.4.camel@zelda.fubar.dk> <20070615185910.GC23417@redhat.com> Message-ID: <1181935330.2727.33.camel@zelda.fubar.dk> On Fri, 2007-06-15 at 14:59 -0400, Dave Jones wrote: > On Fri, Jun 15, 2007 at 09:24:09AM -0400, David Zeuthen wrote: > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c7afd125cc482dbdf6b0a169c42337e7e76cda5 > > > > Can we include this simple patch in Fedora 7 and Rawhide please? Without > > this, events arrive in the wrong order meaning that udev and hal may get > > confused. Thanks. > > Are you sure this is the diff you want? The changelog comment doesn't > really imply anything regarding ordering. Yea, I'm 100% positive - the problem is that uevents for "struct class_device" don't include the PHYSDEV* variables. This makes it impossible for udev to reorder the events, e.g. wait for the device that PHYSDEVPATH that the class device specifies. As a result you sometimes get to process the event for an input device *before* the physical device (e.g. USB interface) have been processed. SCSI generic devices are affected in a similar way. David From davej at redhat.com Fri Jun 15 18:59:10 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 15 Jun 2007 14:59:10 -0400 Subject: uevent order fix In-Reply-To: <1181913849.2727.4.camel@zelda.fubar.dk> References: <1181913849.2727.4.camel@zelda.fubar.dk> Message-ID: <20070615185910.GC23417@redhat.com> On Fri, Jun 15, 2007 at 09:24:09AM -0400, David Zeuthen wrote: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c7afd125cc482dbdf6b0a169c42337e7e76cda5 > > Can we include this simple patch in Fedora 7 and Rawhide please? Without > this, events arrive in the wrong order meaning that udev and hal may get > confused. Thanks. Are you sure this is the diff you want? The changelog comment doesn't really imply anything regarding ordering. rawhide is a no-brainer, it'll get picked up on a rebase soon. Dave -- http://www.codemonkey.org.uk From snecklifter at gmail.com Sat Jun 16 14:13:56 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sat, 16 Jun 2007 15:13:56 +0100 Subject: kqemu inclusion in kernel Message-ID: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> Hi folks, I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel). Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa. Regards Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Sat Jun 16 14:21:45 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 16 Jun 2007 10:21:45 -0400 Subject: kqemu inclusion in kernel In-Reply-To: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> Message-ID: <20070616142145.GJ23417@redhat.com> On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > I've started playing around with virtualization at work and the first thing > I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was > GPL'd in February and although I realise Axel is packaging kmdl/kmods it > would be good to know if this is being queued up for mainline. not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity. > If not then can it be backported for Fedora kernels. It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest. Dave -- http://www.codemonkey.org.uk From Axel.Thimm at ATrpms.net Sat Jun 16 14:31:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Jun 2007 16:31:31 +0200 Subject: kqemu inclusion in kernel In-Reply-To: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> Message-ID: <20070616143131.GG32080@neu.nirvana> On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > Hi folks, > > I've started playing around with virtualization at work and the > first thing I'd like to query is kqemu's lack of inclusion in the > Fedora kernel. It was GPL'd in February and although I realise Axel > is packaging kmdl/kmods kmods? Heaven forbid, no. ;) > it would be good to know if this is being queued up for mainline. If > not then can it be backported for Fedora kernels. If that is not > possible then can it be moved into the default repos to save users > (me) bolting on another repo (no offence Axel). No offense taken. Last summer I tried to get the kmdl mechanism into Fedora proper but the usual suspects didn't let it happen. If we had nice working kmdls in Fedora it would be a matter of a day to get it in there. But replicating a kmod pair out of the kmdl would just make it more difficult to "bolt on another repo". I also know that the main kernel packagers don't really like the idea of any added kernel modules outside the kernel (partly for good reasons, they can't really make a proper QA/bug diagnosis if they don't know how many and which kmdls you have installed in addition to what they packaged into the kernel rpm, although until now it was never really a significant issue in practice). > Please forgive dual list posting but I know DJ reads the kernel list and > might want to comment whereas I'm not sure AT does. And vice versa. We're both everywhere. Trimming to the kernel list. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cebbert at redhat.com Tue Jun 19 19:52:35 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 19 Jun 2007 15:52:35 -0400 Subject: CONFIG_USB_SUSPEND Message-ID: <46783403.6050608@redhat.com> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] (In reply to comment #5) > We can do two things > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > changing anything else, see if that helps, and I think we need this anyway. There are devices that require quirks to work with it enabled, and we'll be forever chasing those if we leave it that way. From zaitcev at redhat.com Tue Jun 19 19:58:56 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 19 Jun 2007 12:58:56 -0700 Subject: CONFIG_USB_SUSPEND In-Reply-To: <46783403.6050608@redhat.com> References: <46783403.6050608@redhat.com> Message-ID: <20070619125856.ad1a2fdb.zaitcev@redhat.com> On Tue, 19 Jun 2007 15:52:35 -0400, Chuck Ebbert wrote: > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > (In reply to comment #5) > > We can do two things > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > changing anything else, see if that helps, and > > I think we need this anyway. There are devices that require quirks > to work with it enabled, and we'll be forever chasing those if we > leave it that way. Yeah, but that's just for testing. In his case it may be feasible to add a quirk for the fingerprint reader, if it turns out to be a suspend and not something else. The reason I didn't ask for usbmon trace only is that I'm always slow with parsing them and acting upon them. -- Pete From jwboyer at jdub.homelinux.org Tue Jun 19 20:01:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 15:01:07 -0500 Subject: kmods poll Message-ID: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> I'd like to just do a brief poll here just to see how many are yay or nay for kmods. And I'm not talking about their current implementation or the other various ways that the idea can be accomplished, but rather on the idea of having kernel modules as separate packages in general. If you're against the general idea and want to follow up with reasons why that's fine. I just want to avoid implementation discussions at the moment if possible. josh From jwilson at redhat.com Tue Jun 19 20:07:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 19 Jun 2007 16:07:32 -0400 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <46783784.3060500@redhat.com> Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. > > If you're against the general idea and want to follow up with reasons > why that's fine. I just want to avoid implementation discussions at the > moment if possible. Yay. They're a source of great pain and suffering, but a necessary evil in some cases to make a few applications (such as a certain open-source {p,d}vr) more accessible to the masses. -- Jarod Wilson jwilson at redhat.com From cebbert at redhat.com Tue Jun 19 20:21:15 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 19 Jun 2007 16:21:15 -0400 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <46783ABB.4010204@redhat.com> On 06/19/2007 04:01 PM, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. > > If you're against the general idea and want to follow up with reasons > why that's fine. I just want to avoid implementation discussions at the > moment if possible. > Necessary evil. From katzj at redhat.com Tue Jun 19 20:27:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Jun 2007 16:27:04 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <46783403.6050608@redhat.com> References: <46783403.6050608@redhat.com> Message-ID: <1182284824.16660.1.camel@erebor.boston.redhat.com> On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > (In reply to comment #5) > > We can do two things > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > changing anything else, see if that helps, and > > I think we need this anyway. There are devices that require quirks > to work with it enabled, and we'll be forever chasing those if we > leave it that way. For F7, maybe. But we really should be looking at having it enabled for F8 and getting the devices quirked that need to be so. Otherwise, we're going to continue to bleed battery life off. Jeremy From katzj at redhat.com Tue Jun 19 20:29:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Jun 2007 16:29:45 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <1182284824.16660.1.camel@erebor.boston.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> Message-ID: <1182284986.16660.4.camel@erebor.boston.redhat.com> On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we'll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we're > going to continue to bleed battery life off. Oh, and people can opt into disabling it completely by adding usbcore.autosuspend=0 to the kernel command line iirc. I think there's also a per-device way to do it once booted, but that's not coming to my feeble memory at the moment Jeremy From j.w.r.degoede at hhs.nl Tue Jun 19 20:44:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 19 Jun 2007 22:44:38 +0200 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <46784036.1080003@hhs.nl> Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. > > If you're against the general idea and want to follow up with reasons > why that's fine. I just want to avoid implementation discussions at the > moment if possible. > I'm not sure where I stand, on one hand I would love to see something like the UVC driver to be in a kmod until merged upstream, to add support for recent webcams. OTOH, maintaining kmods and especially keeping the repo depsolving 100% with them may be a pain. I think that atleast we need a rule that if it isn't heading upstream, there need to be real good reasons to have it in Fedora, if it is heading upstream I think providing a kmod for a while as a service might be a good idea. Does anyone know for example why the lirc kernel module has never gone upstream? Regards, Hans From snecklifter at gmail.com Tue Jun 19 21:13:14 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 19 Jun 2007 22:13:14 +0100 Subject: kmods poll In-Reply-To: <46784036.1080003@hhs.nl> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <46784036.1080003@hhs.nl> Message-ID: <364d303b0706191413m10d721a3idbdb81805c020c5@mail.gmail.com> > > Josh Boyer wrote: > > I'd like to just do a brief poll here just to see how many are yay or > > nay for kmods. And I'm not talking about their current implementation > > or the other various ways that the idea can be accomplished, but rather > > on the idea of having kernel modules as separate packages in general. > > > > If you're against the general idea and want to follow up with reasons > > why that's fine. I just want to avoid implementation discussions at the > > moment if possible. > > Yay, mainly due to my recent issue with kqemu. There are many useful kernel modules that are not in mainline for any number of reasons. Barring the usual license issues and guidelines, I don't think there has to be a reason kmods are not in Fedora if they are not headed upstream. I think the goal should be kernel inclusion of course and my concern would be that projects get lazy - "Don't worry about clearing the code with akpm, Fedora/we will just create a kmod for it". The technical arguments may of course weigh heavily against it - I'm all to aware of dep issues as I already use kmods from an external repo. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Tue Jun 19 21:14:05 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 19 Jun 2007 17:14:05 -0400 Subject: kmods poll In-Reply-To: <46784036.1080003@hhs.nl> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <46784036.1080003@hhs.nl> Message-ID: <4678471D.6050303@redhat.com> Hans de Goede wrote: > Josh Boyer wrote: >> I'd like to just do a brief poll here just to see how many are yay or >> nay for kmods. And I'm not talking about their current implementation >> or the other various ways that the idea can be accomplished, but rather >> on the idea of having kernel modules as separate packages in general. >> >> If you're against the general idea and want to follow up with reasons >> why that's fine. I just want to avoid implementation discussions at the >> moment if possible. >> > > I'm not sure where I stand, on one hand I would love to see something > like the UVC driver to be in a kmod until merged upstream, to add > support for recent webcams. > > OTOH, maintaining kmods and especially keeping the repo depsolving 100% > with them may be a pain. > > I think that atleast we need a rule that if it isn't heading upstream, > there need to be real good reasons to have it in Fedora, if it is > heading upstream I think providing a kmod for a while as a service might > be a good idea. > > Does anyone know for example why the lirc kernel module Modules. There are a TON of 'em. > has never gone upstream? Christoph Bartelmus seemed to have very little interest in getting things upstream, but *just* posted a "Help Wanted" email to the lirc mailing list on the 16th. Excerpted from that: ----8<---- 3. kernel module clean-up: the final goal should be a kernel integration, but there a several fine-grain steps inbetween, like correct usage of __init, __exit, remove all compile time dependancies, enable support for more than one serial port at a time in lirc_serial, remove 2.4 compatibility code, etc. ----8<---- -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Tue Jun 19 21:21:59 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 19 Jun 2007 17:21:59 -0400 Subject: kmods poll In-Reply-To: <4678471D.6050303@redhat.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <46784036.1080003@hhs.nl> <4678471D.6050303@redhat.com> Message-ID: <467848F7.7080303@redhat.com> Jarod Wilson wrote: > Hans de Goede wrote: >> Josh Boyer wrote: >>> I'd like to just do a brief poll here just to see how many are yay or >>> nay for kmods. And I'm not talking about their current implementation >>> or the other various ways that the idea can be accomplished, but rather >>> on the idea of having kernel modules as separate packages in general. >>> >>> If you're against the general idea and want to follow up with reasons >>> why that's fine. I just want to avoid implementation discussions at the >>> moment if possible. >>> >> >> I'm not sure where I stand, on one hand I would love to see something >> like the UVC driver to be in a kmod until merged upstream, to add >> support for recent webcams. >> >> OTOH, maintaining kmods and especially keeping the repo depsolving >> 100% with them may be a pain. >> >> I think that atleast we need a rule that if it isn't heading upstream, >> there need to be real good reasons to have it in Fedora, if it is >> heading upstream I think providing a kmod for a while as a service >> might be a good idea. >> >> Does anyone know for example why the lirc kernel module > > Modules. There are a TON of 'em. > >> has never gone upstream? > > Christoph Bartelmus seemed to have very little interest in getting > things upstream, but *just* posted a "Help Wanted" email to the lirc > mailing list on the 16th. Excerpted from that: > > ----8<---- > 3. kernel module clean-up: the final goal should be a kernel > integration, but there a several fine-grain steps inbetween, like > correct usage of __init, __exit, remove all compile time dependancies, > enable support for more than one serial port at a time in lirc_serial, > remove 2.4 compatibility code, etc. > ----8<---- Minor correction: Christoph said a few years back he had no problem if someone wanted to work on integrating the drivers into the kernel, but didn't have the time to tackle it himself. Hm... So I may have just found a(nother) pet project... -- Jarod Wilson jwilson at redhat.com From ncunning at redhat.com Tue Jun 19 22:45:19 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Wed, 20 Jun 2007 08:45:19 +1000 Subject: CONFIG_USB_SUSPEND In-Reply-To: <1182284824.16660.1.camel@erebor.boston.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> Message-ID: <200706200845.20223.ncunning@redhat.com> Hi. On Wednesday 20 June 2007 06:27:04 Jeremy Katz wrote: > On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we'll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we're > going to continue to bleed battery life off. I'd like to see this enabled too. USB related suspend and resume problems have gone away since around 2.6.18, and I'm pretty sure that at least part of the reason is this new support. Regards, Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zaitcev at redhat.com Tue Jun 19 23:36:42 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 19 Jun 2007 16:36:42 -0700 Subject: CONFIG_USB_SUSPEND In-Reply-To: <200706200845.20223.ncunning@redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <200706200845.20223.ncunning@redhat.com> Message-ID: <20070619163642.0947820d.zaitcev@redhat.com> On Wed, 20 Jun 2007 08:45:19 +1000, Nigel Cunningham wrote: > I'd like to see this enabled too. USB related suspend and resume problems have > gone away since around 2.6.18, and I'm pretty sure that at least part of the > reason is this new support. The autosuspend has little to share with normal suspend/resume. Although I suppose you can encounter a case when autosuspend helps, because the port was suspended by the time real suspend happens. On resume though, they never intersect. -- Pete From jcm at redhat.com Wed Jun 20 03:08:00 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 19 Jun 2007 23:08:00 -0400 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <1182308880.13106.161.camel@jcmlaptop> On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. What's the alternative? There is no practical, real alternative. Jon. From jcm at redhat.com Wed Jun 20 03:10:32 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 19 Jun 2007 23:10:32 -0400 Subject: kmods poll In-Reply-To: <467848F7.7080303@redhat.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <46784036.1080003@hhs.nl> <4678471D.6050303@redhat.com> <467848F7.7080303@redhat.com> Message-ID: <1182309032.13106.163.camel@jcmlaptop> On Tue, 2007-06-19 at 17:21 -0400, Jarod Wilson wrote: > Minor correction: Christoph said a few years back he had no problem if > someone wanted to work on integrating the drivers into the kernel, but > didn't have the time to tackle it himself. > > Hm... So I may have just found a(nother) pet project... I'm happy to help work on this too. Jon. From jonathan.underwood at gmail.com Wed Jun 20 10:04:42 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 20 Jun 2007 11:04:42 +0100 Subject: Rethinking the Ralink wireless driver situation Message-ID: <645d17210706200304s4815c94ewe054a14261bc2d46@mail.gmail.com> Hi, In F-7 a decision was made to bundle in the rt2x00 wireless drivers for Ralink cards. I contend this was a poor decision because, simply put, they do not work. Not for any ralink chipset device I have tried (and I've tried several). Upstream rt2x00 developers have also gone on a 3 month development hiatus. See: http://rt2x00.serialmonkey.com/ But, upstream also maintains what they refer to as enhanced legacy drivers - basically the open source drivers provided by Ralink but polished to be more consistent with general use (eg. ripping out the odd /etc/Wireless configuration tree, and placing firmware in /lib/firmware). This work *really* well on all devices I have tried for which rtx00 does not work. It's a hassle for an end user to install them though, as it involves blacklisting the broken rtx00 modules. Not a big deal, but it wrecks the "out of the box" experience. So, please please consider bundling the rt2400, rt2500, rt2470, rt61 and rt73 drivers for F-8 and ditching rt2x00 until they make it into the upstream kernel. Jonathan. From jwboyer at jdub.homelinux.org Wed Jun 20 13:04:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 08:04:24 -0500 Subject: kmods poll In-Reply-To: <1182308880.13106.161.camel@jcmlaptop> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182308880.13106.161.camel@jcmlaptop> Message-ID: <1182344664.14977.8.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 23:08 -0400, Jon Masters wrote: > On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote: > > > I'd like to just do a brief poll here just to see how many are yay or > > nay for kmods. And I'm not talking about their current implementation > > or the other various ways that the idea can be accomplished, but rather > > on the idea of having kernel modules as separate packages in general. > > What's the alternative? There is no practical, real alternative. Depends. Using a 3rd party repository is an alternative, and is fairly practical. That is already done for some of the binary-only modules. But anyway, my original question was pertaining to Fedora proper so I'll stick with that for now. In Fedora, we currently only have 2 kmods. That's it. Other's have been requested but have either been denied for one reason or another, or have been superseded by newer kernels (ala some of the wireless drivers that got pulled in with the wirless-dev tree). It is not beyond reason that those two kmods could be added as patches to the kernel package itself and simply built with it. This, of course, does not scale to large numbers of external drivers but I don't really see us actually _getting_ large numbers of external drivers that are actually approved. It might have some pain in rawhide, but the current kmod maintainers are pretty responsive from what I've seen. I'm mostly just rambling. In the past, there has been some vocal dissent for having kmods period, so I wanted to know the opinions from people on a more targeted list than fedora-devel. josh From jcm at redhat.com Wed Jun 20 13:21:39 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 20 Jun 2007 09:21:39 -0400 Subject: kmods poll In-Reply-To: <1182344664.14977.8.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182308880.13106.161.camel@jcmlaptop> <1182344664.14977.8.camel@weaponx.rchland.ibm.com> Message-ID: <1182345699.13106.188.camel@jcmlaptop> On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote: > I'm mostly just rambling. In the past, there has been some vocal > dissent for having kmods period, so I wanted to know the opinions from > people on a more targeted list than fedora-devel. Officially, there may only be two, but obviously third parties will supply others - so we need the infrastructure. In fact, I'm working on a project to allow automatic, online driver updates via kmods - I'll have more to say in due course on that. Jon. From jwboyer at jdub.homelinux.org Wed Jun 20 13:46:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 08:46:58 -0500 Subject: kmods poll In-Reply-To: <1182345699.13106.188.camel@jcmlaptop> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182308880.13106.161.camel@jcmlaptop> <1182344664.14977.8.camel@weaponx.rchland.ibm.com> <1182345699.13106.188.camel@jcmlaptop> Message-ID: <1182347218.14977.16.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 09:21 -0400, Jon Masters wrote: > On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote: > > > I'm mostly just rambling. In the past, there has been some vocal > > dissent for having kmods period, so I wanted to know the opinions from > > people on a more targeted list than fedora-devel. > > Officially, there may only be two, but obviously third parties will > supply others - so we need the infrastructure. > > In fact, I'm working on a project to allow automatic, online driver > updates via kmods - I'll have more to say in due course on that. Is that why there are the "updates" and "weak-updates" directories in /lib/modules/`uname -r`/ today? I've been wondering about those. And what would they be used for? E.g. updating e1000 when there's a bugfix that doesn't really require the whole kernel to be spun again? josh From katzj at redhat.com Wed Jun 20 14:29:08 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 10:29:08 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <1182284824.16660.1.camel@erebor.boston.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> Message-ID: <1182349748.30259.2.camel@erebor.boston.redhat.com> On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we'll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we're > going to continue to bleed battery life off. Of course, upstream doesn't seem all that inclined[1] to make it so that devices can actually work. *sigh* Jeremy [1] http://thread.gmane.org/gmane.linux.usb.devel/55192 From dwmw2 at infradead.org Wed Jun 20 14:55:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Jun 2007 22:55:43 +0800 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <1182351343.3016.207.camel@shinybook.infradead.org> On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but > rather on the idea of having kernel modules as separate packages in > general. Absolutely not, ever. > If you're against the general idea and want to follow up with reasons > why that's fine. If it's good enough for Fedora to ship and support, we can put it in the main kernel package. Besides; if it's good enough for Fedora to ship and support, then it should be upstream already anyway and thus should get into our main kernel package by _default_. And if it isn't good enough for upstream to ship and support, why in $DEITY's name would we want to ship it, again? -- dwmw2 From pjones at redhat.com Wed Jun 20 15:12:40 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 11:12:40 -0400 Subject: kmods poll In-Reply-To: <1182351343.3016.207.camel@shinybook.infradead.org> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> Message-ID: <467943E8.3090909@redhat.com> David Woodhouse wrote: > And if it isn't good enough for upstream to ship and support, why in > $DEITY's name would we want to ship it, again? From http://fedoraproject.org/wiki/Objectives : * To be on the leading edge of free and open source technology, by adopting and helping develop new features and version upgrades. TBF, there are several other bullet items there that support your other points. -- Peter From jwboyer at jdub.homelinux.org Wed Jun 20 15:12:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 10:12:24 -0500 Subject: kmods poll In-Reply-To: <1182351343.3016.207.camel@shinybook.infradead.org> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> Message-ID: <1182352344.14977.32.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 22:55 +0800, David Woodhouse wrote: > On Tue, 2007-06-19 at 15:01 -0500, Josh Boyer wrote: > > I'd like to just do a brief poll here just to see how many are yay or > > nay for kmods. And I'm not talking about their current implementation > > or the other various ways that the idea can be accomplished, but > > rather on the idea of having kernel modules as separate packages in > > general. > > Absolutely not, ever. > > > If you're against the general idea and want to follow up with reasons > > why that's fine. > > If it's good enough for Fedora to ship and support, we can put it in the > main kernel package. Besides; if it's good enough for Fedora to ship and Which is something I suggested later in this thread. > And if it isn't good enough for upstream to ship and support, why in > $DEITY's name would we want to ship it, again? *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen *cough* Ok, out of those really only squashfs and xen aren't immediately headed towards some kind of upstream inclusion. josh From cebbert at redhat.com Wed Jun 20 15:15:50 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 20 Jun 2007 11:15:50 -0400 Subject: kmods poll In-Reply-To: <1182352344.14977.32.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> <1182352344.14977.32.camel@weaponx.rchland.ibm.com> Message-ID: <467944A6.3080902@redhat.com> On 06/20/2007 11:12 AM, Josh Boyer wrote: > >> And if it isn't good enough for upstream to ship and support, why in >> $DEITY's name would we want to ship it, again? > > *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen > *cough* > ... exec-shield From jwboyer at jdub.homelinux.org Wed Jun 20 15:16:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 10:16:48 -0500 Subject: kmods poll In-Reply-To: <467944A6.3080902@redhat.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> <1182352344.14977.32.camel@weaponx.rchland.ibm.com> <467944A6.3080902@redhat.com> Message-ID: <1182352608.14977.34.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 11:15 -0400, Chuck Ebbert wrote: > On 06/20/2007 11:12 AM, Josh Boyer wrote: > > > >> And if it isn't good enough for upstream to ship and support, why in > >> $DEITY's name would we want to ship it, again? > > > > *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen > > *cough* > > > > ... exec-shield Ooh, forgot about that one. And of course, utrace at the moment. But I didn't want to mention them because I don't want to piss Roland off ;) josh From dwmw2 at infradead.org Wed Jun 20 15:39:10 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Jun 2007 23:39:10 +0800 Subject: kmods poll In-Reply-To: <1182352344.14977.32.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> <1182352344.14977.32.camel@weaponx.rchland.ibm.com> Message-ID: <1182353951.3016.221.camel@shinybook.infradead.org> On Wed, 2007-06-20 at 10:12 -0500, Josh Boyer wrote: > > If it's good enough for Fedora to ship and support, we can put it in the > > main kernel package. Besides; if it's good enough for Fedora to ship and > > Which is something I suggested later in this thread. > > > And if it isn't good enough for upstream to ship and support, why in > > $DEITY's name would we want to ship it, again? > > *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen > *cough* And a bunch of drivers too. I remember the USB DSL drivers around FC4 timeframe, because the complexity of setting that crap up in FC3 offended me so much. PlayStation 3 support in F7. There's _plenty_ of stuff we've shipped in our main kernel package because it's _almost_ upstream and it's (almost) good enough. There's no need to package them separately? -- either we're willing to ship and support them, or we aren't. > Ok, out of those really only squashfs and xen aren't immediately headed > towards some kind of upstream inclusion. Is squashfs not headed upstream? Obviously Xen was and is a massive fscking abortion, but I don't think anyone's holding that up as a shining example of how we should do stuff -- quite the opposite, in fact. -- dwmw2 ? Except for the illegal crap like nVidia and ATI drivers, but those aren't relevant to this particular discussion anyway. From katzj at redhat.com Wed Jun 20 15:45:23 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 11:45:23 -0400 Subject: kmods poll In-Reply-To: <1182353951.3016.221.camel@shinybook.infradead.org> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> <1182352344.14977.32.camel@weaponx.rchland.ibm.com> <1182353951.3016.221.camel@shinybook.infradead.org> Message-ID: <1182354324.3486.1.camel@erebor.boston.redhat.com> On Wed, 2007-06-20 at 23:39 +0800, David Woodhouse wrote: > > Ok, out of those really only squashfs and xen aren't immediately headed > > towards some kind of upstream inclusion. > > Is squashfs not headed upstream? squashfs gets posted every few months, people come back with complaints, the maintainer disappears for four to six months and then comes back with things fixed and goes at it again. That's been the treadmill with squashfs for over a year now :-/ Someone just asked again recently on the squashfs list about upstream, so that's usually enough to kick off another go at it... Jeremy From jwboyer at jdub.homelinux.org Wed Jun 20 15:46:02 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 10:46:02 -0500 Subject: kmods poll In-Reply-To: <1182353951.3016.221.camel@shinybook.infradead.org> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182351343.3016.207.camel@shinybook.infradead.org> <1182352344.14977.32.camel@weaponx.rchland.ibm.com> <1182353951.3016.221.camel@shinybook.infradead.org> Message-ID: <1182354362.14977.38.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 23:39 +0800, David Woodhouse wrote: > On Wed, 2007-06-20 at 10:12 -0500, Josh Boyer wrote: > > > If it's good enough for Fedora to ship and support, we can put it in the > > > main kernel package. Besides; if it's good enough for Fedora to ship and > > > > Which is something I suggested later in this thread. > > > > > And if it isn't good enough for upstream to ship and support, why in > > > $DEITY's name would we want to ship it, again? > > > > *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen > > *cough* > > And a bunch of drivers too. I remember the USB DSL drivers around FC4 > timeframe, because the complexity of setting that crap up in FC3 > offended me so much. PlayStation 3 support in F7. There's _plenty_ of > stuff we've shipped in our main kernel package because it's _almost_ > upstream and it's (almost) good enough. There's no need to package them > separately? -- either we're willing to ship and support them, or we > aren't. > > > Ok, out of those really only squashfs and xen aren't immediately headed > > towards some kind of upstream inclusion. > > Is squashfs not headed upstream? Obviously Xen was and is a massive I think it's been tried twice now. The first time, there were legitimate review issues. The second time was mostly people whining about pointless crap. I think Philip lost interest after that. josh From jwilson at redhat.com Wed Jun 20 17:21:58 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 20 Jun 2007 13:21:58 -0400 Subject: kmods poll In-Reply-To: <1182347218.14977.16.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> <1182308880.13106.161.camel@jcmlaptop> <1182344664.14977.8.camel@weaponx.rchland.ibm.com> <1182345699.13106.188.camel@jcmlaptop> <1182347218.14977.16.camel@weaponx.rchland.ibm.com> Message-ID: <46796236.3030302@redhat.com> Josh Boyer wrote: > On Wed, 2007-06-20 at 09:21 -0400, Jon Masters wrote: >> On Wed, 2007-06-20 at 08:04 -0500, Josh Boyer wrote: >> >>> I'm mostly just rambling. In the past, there has been some vocal >>> dissent for having kmods period, so I wanted to know the opinions from >>> people on a more targeted list than fedora-devel. >> Officially, there may only be two, but obviously third parties will >> supply others - so we need the infrastructure. >> >> In fact, I'm working on a project to allow automatic, online driver >> updates via kmods - I'll have more to say in due course on that. > > Is that why there are the "updates" and "weak-updates" directories > in /lib/modules/`uname -r`/ today? > > I've been wondering about those. And what would they be used for? E.g. > updating e1000 when there's a bugfix that doesn't really require the > whole kernel to be spun again? Yes, an updated e1000 driver could land in updates (though kmod tends to use 'extra' instead of 'updates', but other repos kernel module packages use updates). The weak-updates is only used by RHEL at the moment, as far as I recall. Basically, you install kmod-foo for kernel 2.6.18-8.el5, and when you install kernel 2.6.18-8.0.3.el5, a symlink back into the -8.el5 module tree for that kmod-foo gets created in -8.0.3.el5's weak-updates folder. A kernel-provided driver will take precedence, but if none is provided, the one in weak-updates will get used instead. Because of the stable kabi, drivers from an earlier kernel *should* work just fine with a newer one. Or something more or less like that... -- 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 davej at redhat.com Wed Jun 20 17:22:33 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 13:22:33 -0400 Subject: Rethinking the Ralink wireless driver situation In-Reply-To: <645d17210706200304s4815c94ewe054a14261bc2d46@mail.gmail.com> References: <645d17210706200304s4815c94ewe054a14261bc2d46@mail.gmail.com> Message-ID: <20070620172233.GA23569@redhat.com> On Wed, Jun 20, 2007 at 11:04:42AM +0100, Jonathan Underwood wrote: > Hi, > > In F-7 a decision was made to bundle in the rt2x00 wireless drivers > for Ralink cards. I contend this was a poor decision because, simply > put, they do not work. Not for any ralink chipset device I have tried > (and I've tried several). Upstream rt2x00 developers have also gone on > a 3 month development hiatus. See: http://rt2x00.serialmonkey.com/ > > But, upstream also maintains what they refer to as enhanced legacy > drivers - basically the open source drivers provided by Ralink but > polished to be more consistent with general use (eg. ripping out the > odd /etc/Wireless configuration tree, and placing firmware in > /lib/firmware). This work *really* well on all devices I have tried > for which rtx00 does not work. It's a hassle for an end user to > install them though, as it involves blacklisting the broken rtx00 > modules. Not a big deal, but it wrecks the "out of the box" > experience. > > So, please please consider bundling the rt2400, rt2500, rt2470, rt61 > and rt73 drivers for F-8 and ditching rt2x00 until they make it into > the upstream kernel. Fixing the broken drivers sounds like a better answer rather than shipping something that will never get upstream. Yes, wireless sucks right now, but running away from the problem isn't going to make it any better. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jun 20 17:30:03 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 13:30:03 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <1182349748.30259.2.camel@erebor.boston.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182349748.30259.2.camel@erebor.boston.redhat.com> Message-ID: <20070620173003.GD23569@redhat.com> On Wed, Jun 20, 2007 at 10:29:08AM -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote: > > On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > > > (In reply to comment #5) > > > > We can do two things > > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > > changing anything else, see if that helps, and > > > > > > I think we need this anyway. There are devices that require quirks > > > to work with it enabled, and we'll be forever chasing those if we > > > leave it that way. > > > > For F7, maybe. But we really should be looking at having it enabled for > > F8 and getting the devices quirked that need to be so. Otherwise, we're > > going to continue to bleed battery life off. > > Of course, upstream doesn't seem all that inclined[1] to make it so that > devices can actually work. *sigh* > > Jeremy > > [1] http://thread.gmane.org/gmane.linux.usb.devel/55192 Adding udev callouts as he suggests shouldn't be difficult though should it? Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Jun 20 17:39:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Jun 2007 13:39:47 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <20070620173003.GD23569@redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182349748.30259.2.camel@erebor.boston.redhat.com> <20070620173003.GD23569@redhat.com> Message-ID: <20070620173947.GA13839@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > > Of course, upstream doesn't seem all that inclined[1] to make it so that > > devices can actually work. *sigh* > > Adding udev callouts as he suggests shouldn't be difficult though should it? You don't want udev callouts that simply. You want udev callouts that disable autosuspend when it's charging, monitor the battery for fully charged state, and then enable it again. Wheeeeee. Bill From katzj at redhat.com Wed Jun 20 17:42:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 13:42:05 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <20070620173947.GA13839@nostromo.devel.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182349748.30259.2.camel@erebor.boston.redhat.com> <20070620173003.GD23569@redhat.com> <20070620173947.GA13839@nostromo.devel.redhat.com> Message-ID: <1182361325.3486.9.camel@erebor.boston.redhat.com> On Wed, 2007-06-20 at 13:39 -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > > Of course, upstream doesn't seem all that inclined[1] to make it so that > > > devices can actually work. *sigh* > > > > Adding udev callouts as he suggests shouldn't be difficult though should it? > > You don't want udev callouts that simply. You want udev callouts that > disable autosuspend when it's charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee. There's no real way to tell if the device is fully charged or not for most devices AFAIK Jeremy From pjones at redhat.com Wed Jun 20 17:44:18 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 13:44:18 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <20070620173947.GA13839@nostromo.devel.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182349748.30259.2.camel@erebor.boston.redhat.com> <20070620173003.GD23569@redhat.com> <20070620173947.GA13839@nostromo.devel.redhat.com> Message-ID: <46796772.5090503@redhat.com> Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: >> > Of course, upstream doesn't seem all that inclined[1] to make it so that >> > devices can actually work. *sigh* >> >> Adding udev callouts as he suggests shouldn't be difficult though should it? > > You don't want udev callouts that simply. You want udev callouts that > disable autosuspend when it's charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee. You also want the user to be able to go clicky-clicky when he doesn't want it to charge right now. Some of this sort of device do more than just charge via usb, so there are other reasons to plug them in, but I don't necessarily want to charge them while my laptop isn't plugged in, either. -- Peter From davej at redhat.com Wed Jun 20 18:12:10 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 14:12:10 -0400 Subject: CONFIG_USB_SUSPEND In-Reply-To: <20070620173947.GA13839@nostromo.devel.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182349748.30259.2.camel@erebor.boston.redhat.com> <20070620173003.GD23569@redhat.com> <20070620173947.GA13839@nostromo.devel.redhat.com> Message-ID: <20070620181210.GF23569@redhat.com> On Wed, Jun 20, 2007 at 01:39:47PM -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > > Of course, upstream doesn't seem all that inclined[1] to make it so that > > > devices can actually work. *sigh* > > > > Adding udev callouts as he suggests shouldn't be difficult though should it? > > You don't want udev callouts that simply. You want udev callouts that > disable autosuspend when it's charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee. Sure, that's a nice end-goal, but a good first-pass that just disables suspend when inserted, and reenables it when the device is unplugged would be better than nothing no? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Jun 21 03:02:37 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 20 Jun 2007 20:02:37 -0700 (PDT) Subject: eu-unstrip Message-ID: <20070621030237.A1F29D0002@magilla.localdomain> There was some complaining here about problems dealing with separate debuginfo files. In elfutils-0.128, in an f6 and fc7 update near you, there is now eu-strip. This doesn't improve any non-elfutils tools you were using that weren't handling separate debuginfo well, but it makes it easy to recover a unified unstripped file to use them on. For a good time, try "mkdir foo; eu-unstrip -d foo -a -k". It is either more or less fun with -m, according to taste. For other uses you might want -K2.6.21-1.678.fc9 or -K/some/where, or other options available (see --help). I hope this is useful on occasion. Thanks, Roland From roland at redhat.com Fri Jun 22 06:56:26 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 21 Jun 2007 23:56:26 -0700 (PDT) Subject: rawhide kernel fuzz Message-ID: <20070622065626.E7D2CD0002@magilla.localdomain> Dave disabled utrace because sched-cfs has a line that conflicts. It only conflicts under -F1, and with default patching (-F2) utrace applies fine after sched-cfs. This tweak to the spec file's ApplyPatch makes it easy to make one patch use -F2 when you need it, instead of disabling a patch because of a conflict that patch resolves just fine. Thanks, Roland --- kernel-2.6.spec 21 Jun 2007 23:20:46 -0700 1.3233 +++ kernel-2.6.spec 21 Jun 2007 23:49:07 -0700 @@ -889,13 +890,15 @@ cd linux-%{kversion}.%{_target_cpu} patch_command='patch -p1 -F1 -s' ApplyPatch() { - if [ ! -f $RPM_SOURCE_DIR/$1 ]; then + local patch=$1 + shift + if [ ! -f $RPM_SOURCE_DIR/$patch ]; then exit 1; fi - case "$1" in - *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$1" | $patch_command ;; - *.gz) gunzip < "$RPM_SOURCE_DIR/$1" | $patch_command ;; - *) $patch_command < "$RPM_SOURCE_DIR/$1" ;; + case "$patch" in + *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; + *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; + *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;; esac } @@ -914,9 +917,9 @@ ApplyPatch patch-2.6.22-rc5-git4.bz2 ApplyPatch linux-2.6-sched-cfs.patch # Roland's utrace ptrace replacement. -#ApplyPatch linux-2.6-utrace.patch -# setuid /proc/self/maps fix. (dependant on utrace) -#ApplyPatch linux-2.6-proc-self-maps-fix.patch +ApplyPatch linux-2.6-utrace.patch -F2 +# setuid /proc/self/maps fix. (dependent on utrace) +ApplyPatch linux-2.6-proc-self-maps-fix.patch # Nouveau DRM #ApplyPatch nouveau-drm.patch From davej at redhat.com Fri Jun 22 19:58:31 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 22 Jun 2007 15:58:31 -0400 Subject: rawhide kernel fuzz In-Reply-To: <20070622065626.E7D2CD0002@magilla.localdomain> References: <20070622065626.E7D2CD0002@magilla.localdomain> Message-ID: <20070622195831.GB13857@redhat.com> On Thu, Jun 21, 2007 at 11:56:26PM -0700, Roland McGrath wrote: > Dave disabled utrace because sched-cfs has a line that conflicts. It only > conflicts under -F1, and with default patching (-F2) utrace applies fine > after sched-cfs. This tweak to the spec file's ApplyPatch makes it easy to > make one patch use -F2 when you need it, instead of disabling a patch > because of a conflict that patch resolves just fine. I'll give this a begruding 'ok'. With luck cfs will be going upstream soon anyway, so we can then rediff utrace against it. (And if it isn't upstream by 2.6.23, we'll need to drop it, or at least neuter it's addition of a syscall) Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Fri Jun 22 20:36:32 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 22 Jun 2007 16:36:32 -0400 Subject: Removing atomic.h from Fedora kernel headers Message-ID: <467C32D0.2050207@redhat.com> Why do we explicitly remove atomic.h from our kernel header package? >From the Fedora Core 6 kernel spec file: # glibc provides scsi headers for itself, for now rm -rf $RPM_BUILD_ROOT/usr/include/scsi rm -f $RPM_BUILD_ROOT/usr/include/asm*/atomic.h rm -f $RPM_BUILD_ROOT/usr/include/asm*/io.h rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h From notting at redhat.com Fri Jun 22 20:41:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Jun 2007 16:41:46 -0400 Subject: Removing atomic.h from Fedora kernel headers In-Reply-To: <467C32D0.2050207@redhat.com> References: <467C32D0.2050207@redhat.com> Message-ID: <20070622204146.GB9932@nostromo.devel.redhat.com> Chuck Ebbert (cebbert at redhat.com) said: > Why do we explicitly remove atomic.h from our kernel header package? IIRC, the reasoning was because the operations weren't actually atomic when used from userspace; ergo, it was a bad idea to provide them. Bill From zaitcev at redhat.com Sat Jun 23 03:54:11 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 22 Jun 2007 20:54:11 -0700 Subject: CONFIG_USB_SUSPEND In-Reply-To: <1182284986.16660.4.camel@erebor.boston.redhat.com> References: <46783403.6050608@redhat.com> <1182284824.16660.1.camel@erebor.boston.redhat.com> <1182284986.16660.4.camel@erebor.boston.redhat.com> Message-ID: <20070622205411.71150c53.zaitcev@redhat.com> On Tue, 19 Jun 2007 16:29:45 -0400, Jeremy Katz wrote: > Oh, and people can opt into disabling it completely by adding > usbcore.autosuspend=0 to the kernel command line iirc. I think there's > also a per-device way to do it once booted, but that's not coming to my > feeble memory at the moment As far as I know, there's no parameter to switch autosuspend globally as such. You can try usbcore.autosuspend_delay=-1 and that should do it, because I do not see code checking the parameter for the range. The "autosuspend" attribute is a boolean which governs it per device, but that's a pain to set, and it disappears on every replug. -- Pete From gilboad at gmail.com Sun Jun 24 11:17:50 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 24 Jun 2007 14:17:50 +0300 Subject: Removing atomic.h from Fedora kernel headers In-Reply-To: <20070622204146.GB9932@nostromo.devel.redhat.com> References: <467C32D0.2050207@redhat.com> <20070622204146.GB9932@nostromo.devel.redhat.com> Message-ID: <1182683870.16152.5.camel@gilboa-work-dev.localdomain> On Fri, 2007-06-22 at 16:41 -0400, Bill Nottingham wrote: > Chuck Ebbert (cebbert at redhat.com) said: > > Why do we explicitly remove atomic.h from our kernel header package? > > IIRC, the reasoning was because the operations weren't actually > atomic when used from userspace; ergo, it was a bad idea to provide > them. > > Bill ... Unless you define CONFIG_SMP (which in turn, defines LOCK_PREFIX) I assume that up-stream will shoot me for suggesting that... but why not just add: #ifndef __KERNEL__ #define LOCK_PREFIX "lock; " #endif ... and make atomic_xxx safe for user-land? - Gilboa From Axel.Thimm at ATrpms.net Sun Jun 24 11:47:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Jun 2007 13:47:24 +0200 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <20070624114724.GB11629@puariko.nirvana> On Tue, Jun 19, 2007 at 03:01:07PM -0500, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. > > If you're against the general idea and want to follow up with reasons > why that's fine. I'm late in the query, but definitely, yes. People come screaming at ATrpms to get kmdl updates which can't go in as afast into either the kernel sources proper or a patch into the kernel rpm. Any kernel module project will have external kernel module build setups available before being able to get into the kernel, even the ones that already have a slot there. Arguing that one should wait for the vanilla kernel to incorporate those patches while OTOh we are talking about how to evr CVS/svn/git/hg cuts of everything else is a bit hypocritical. Especially with all the patching that still happens in the Fedora kernel. > I just want to avoid implementation discussions at the moment if > possible. Unfortunately the (bad) implementations and lack of a standard (and "standard" is not always what is written in the guidelines ...) add to the problem enormously. I don't think you can really separate the discussion. If you had a nicely working scheme everybody would support, you wouldn't have that much hostility against packaging kernel modules. Heck, *some* of the patches to the Fedora kernel could be managed as external kernel modules and save the pain of upgrading the main kernel package when such a subsystem is touched. In fact many such changes that people would like to see fixed have to wait to queue up to make a kernel update worthwhile for all Fedora users. Anyway the latter is a pipe dream - unless the kernel packager group at Fedora sees truly painlessly working kernel module packages there won't be any such outsourcing. But getting an infrastructure that supports building sane kernel module packages would be a plus in any relation, even if not used by Fedora itself for more than half a dozen packages. As a fact currently several repos are looking at using koji and one blocker is whether adding kernel module support would be possible. There are also some RHEL-only related benefits to endorse external kernel module packages, but I won't dwel into that on *fedora-kernel* :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Sun Jun 24 19:25:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 24 Jun 2007 20:25:03 +0100 Subject: Removing atomic.h from Fedora kernel headers In-Reply-To: <467C32D0.2050207@redhat.com> References: <467C32D0.2050207@redhat.com> Message-ID: <1182713103.8289.11.camel@shinybook.infradead.org> On Fri, 2007-06-22 at 16:36 -0400, Chuck Ebbert wrote: > Why do we explicitly remove atomic.h from our kernel header package? No reason any more. Once upon a time, before the cleanup of the upstream kernel's exports was complete, we needed to remove this unwanted crap. These days, the kernel's standard 'make headers_install' doesn't include it anyway, so we no longer need to strip it out for ourselves. I think the same goes for io.h and irq.h. -- dwmw2 From fedora at leemhuis.info Mon Jun 25 13:34:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 25 Jun 2007 15:34:11 +0200 Subject: kmods poll In-Reply-To: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> References: <1182283267.6126.104.camel@weaponx.rchland.ibm.com> Message-ID: <467FC453.8060006@leemhuis.info> /me is late in the game -- I was on vacation in the past two weeks and tried to keep a bit away from the keyboard On 19.06.2007 22:01, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. My 2 cent these days are this: I think we should have a kind of "experimental and unsupported repository area" in the scope of the Fedora-Project where we could have - kernel-module packages for the Kernels released by Fedora - alternate kernels - stuff that replaces packages from the Distribution. No, no big repo -- just specific experimental areas like we had in the past as well ("AIGLX for FC5") Reasons for that option: there is a strong opposition against kernel module packages or heavily patches kernels (?) which afaics directly and indirectly the main reason why we only have two kernels module packages in Fedora (?). People on the other hand sometimes need kernel module packages, and we don't have the man-power to submit all of them to the kernel ourselfs (where they should be). How to move on? My plan was to wait for the new elected Board and FESCo and ask them what they want (now that we have a merged world) -- *if they want* kernel module packages directly in the Package Repository (?) make the infrastructure better (automatic build for packages after a kernel gets build for updates or updates-testing [we maybe could need something similar to solve situations like the firefox-update dilemma...]; enhance the current kernel module packaging standard in so we can do ship pre-build packages while make it possible for users to use dkms or a dkms-like solution) and tell packagers that kmods are really allowed and wanted. CU thl (?) -- no, I don't want them either (?) -- there were some in the queue, but afaics a lot of people (including me) choose to not review them/help them into the repo as many people loudly yelled "no seperate kernel modules packages in Fedora" the last time the topic was discussed (even if the Board gave a "go" (?) -- which I doubt From cebbert at redhat.com Mon Jun 25 14:17:13 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 25 Jun 2007 10:17:13 -0400 Subject: Removing atomic.h from Fedora kernel headers In-Reply-To: <1182713103.8289.11.camel@shinybook.infradead.org> References: <467C32D0.2050207@redhat.com> <1182713103.8289.11.camel@shinybook.infradead.org> Message-ID: <467FCE69.3040004@redhat.com> On 06/24/2007 03:25 PM, David Woodhouse wrote: > On Fri, 2007-06-22 at 16:36 -0400, Chuck Ebbert wrote: >> Why do we explicitly remove atomic.h from our kernel header package? > > No reason any more. Once upon a time, before the cleanup of the upstream > kernel's exports was complete, we needed to remove this unwanted crap. > > These days, the kernel's standard 'make headers_install' doesn't include > it anyway, so we no longer need to strip it out for ourselves. I dug through the makefiles to try and figure out if that was true, but gave up. Where is the list of included and/or excluded files? From dwmw2 at infradead.org Mon Jun 25 14:19:10 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 25 Jun 2007 15:19:10 +0100 Subject: Removing atomic.h from Fedora kernel headers In-Reply-To: <467FCE69.3040004@redhat.com> References: <467C32D0.2050207@redhat.com> <1182713103.8289.11.camel@shinybook.infradead.org> <467FCE69.3040004@redhat.com> Message-ID: <1182781150.12109.105.camel@pmac.infradead.org> On Mon, 2007-06-25 at 10:17 -0400, Chuck Ebbert wrote: > On 06/24/2007 03:25 PM, David Woodhouse wrote: > > On Fri, 2007-06-22 at 16:36 -0400, Chuck Ebbert wrote: > >> Why do we explicitly remove atomic.h from our kernel header package? > > > > No reason any more. Once upon a time, before the cleanup of the upstream > > kernel's exports was complete, we needed to remove this unwanted crap. > > > > These days, the kernel's standard 'make headers_install' doesn't include > > it anyway, so we no longer need to strip it out for ourselves. > > I dug through the makefiles to try and figure out if that was true, but > gave up. Where is the list of included and/or excluded files? include/**/Kbuild (but note that include/asm-*/Kbuild all include include/asm-generic/Kbuild.asm). Or just run 'make headers_install' and then look in usr/include/ :) -- dwmw2 From ncunning at redhat.com Tue Jun 26 02:10:34 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Tue, 26 Jun 2007 12:10:34 +1000 Subject: CONFIG_USB_SUSPEND In-Reply-To: <20070619163642.0947820d.zaitcev@redhat.com> References: <46783403.6050608@redhat.com> <200706200845.20223.ncunning@redhat.com> <20070619163642.0947820d.zaitcev@redhat.com> Message-ID: <200706261210.34547.ncunning@redhat.com> Hi Pete. On Wednesday 20 June 2007 09:36:42 Pete Zaitcev wrote: > On Wed, 20 Jun 2007 08:45:19 +1000, Nigel Cunningham wrote: > > > I'd like to see this enabled too. USB related suspend and resume problems have > > gone away since around 2.6.18, and I'm pretty sure that at least part of the > > reason is this new support. > > The autosuspend has little to share with normal suspend/resume. Although > I suppose you can encounter a case when autosuspend helps, because the > port was suspended by the time real suspend happens. On resume though, > they never intersect. Ah ok. Sorry for the noise! Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tdiehl at tntechs.com Fri Jun 29 01:39:18 2007 From: tdiehl at tntechs.com (Tom Diehl) Date: Thu, 28 Jun 2007 21:39:18 -0400 (EDT) Subject: Kernel panic on new f7 installation Message-ID: Hi, I just installed f7 on a new box. When I tried to boot it after install I got the following error: MP-BIOS bug: 8254 Timer not connected to IO-APIC Kernel Panic Not syncing: IO-APIC + Timer doesn't work! Try using the noapic kernel parameter. Passing nooapic to the kernel at boot lets the machine boot. There are no BIOS updates available for the box. Is this something I should put into bugzilla or is simply expected on some machines? FYI: [root at tigger2 pts0 ~]# uname -r 2.6.21-1.3228.fc7 [root at tigger2 pts0 ~]# The box is a Lenovo MTM7387-24U [root at tigger2 pts0 ~]# lspci -v 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] #00 [00fe] Capabilities: [fc] #00 [0000] 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: [40] Subsystem: Lenovo Unknown device 1017 Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev a2) (prog-if 00 [VGA]) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 Memory at d1000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at d0000000 (64-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at 30000000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel, IRQ 10 I/O ports at 3040 [size=64] I/O ports at 3000 [size=64] Capabilities: [44] Power Management version 2 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) Subsystem: Lenovo Unknown device 1017 Flags: 66MHz, fast devsel 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) (prog-if 10 [OHCI]) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 5 Memory at d2344000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 Memory at d2346000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f7aa:1017 Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 3080 [size=16] Capabilities: [44] Power Management version 2 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1) (prog-if 85 [Master SecO PriO]) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 I/O ports at 30b0 [size=8] I/O ports at 30a4 [size=4] I/O ports at c0b0 [size=8] I/O ports at c0a4 [size=4] I/O ports at 3090 [size=16] Memory at d2345000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable- Capabilities: [cc] HyperTransport: MSI Mapping 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 I/O behind bridge: 00004000-00004fff Memory behind bridge: d2000000-d20fffff Capabilities: [b8] Subsystem: nVidia Corporation Unknown device cb84 Capabilities: [8c] HyperTransport: MSI Mapping 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11 Memory at d2340000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable- Capabilities: [6c] HyperTransport: MSI Mapping 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel Capabilities: [f0] #0f [0010] 03:05.0 Communication controller: Conexant HSF 56k Data/Fax Modem Subsystem: Conexant Unknown device 2014 Flags: bus master, fast Back2Back, medium devsel, latency 64, IRQ 10 Memory at d2000000 (32-bit, non-prefetchable) [size=64K] I/O ports at 4000 [size=8] Capabilities: [40] Power Management version 2 03:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet (rev 03) Subsystem: Lenovo Unknown device 1017 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at d2010000 (32-bit, non-prefetchable) [size=64K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable- [root at tigger2 pts0 ~]# I am not sure what other info would be useful, so please ask if someone feels I should provide something else. Regards, -- Tom Diehl tdiehl at tntechs.com Spamtrap address mtd123 at tntechs.com From roland at redhat.com Fri Jun 29 02:02:41 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 28 Jun 2007 19:02:41 -0700 (PDT) Subject: linux-2.6-elf-core-sysctl.patch Message-ID: <20070629020241.6469D4D0644@magilla.localdomain> Without objection, I will throw this into rawhide. I want to get some beating on it done before I send it upstream. The related bits that make it cool may hit rawhide soonish. If an F7 update got this too but with dump_dso_headers = 0 default, that would be groovy. It is a no-op when disabled and having the option would be nice for people wanting to play with the userland tools that like this, who don't have a rawhide install. Thanks, Roland --- [PATCH] Add sysctl controls on ELF core dump segments, dump first page of DSOs This adds two sysctl items under fs.binfmt_elf for controlling how memory segments are dumped in ELF core files. The dump_whole_segments option can be set to have private file mappings dumped in their entirety. The dump_dso_headers option is the new default. This dumps the first page (only) of a read-only private file mapping if it appears to be a mapping of an ELF file. Including these pages in the core dump may give sufficient identifying information to associate the original DSO and executable file images and their debugging information with a core file in a generic way just from its contents. Signed-off-by: Roland McGrath --- fs/binfmt_elf.c | 152 ++++++++++++++++++++++++++++++++++++++++++++++--------- 1 files changed, 128 insertions(+), 24 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index fa8ea33..ae63521 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -1151,6 +1152,10 @@ out: * Modelled on fs/exec.c:aout_core_dump() * Jeremy Fitzhardinge */ + +static int dump_whole_segments = 0; +static int dump_dso_headers = 1; + /* * These are the only things you should do on a core-file: use only these * functions to write out all the necessary info. @@ -1183,31 +1188,60 @@ static int dump_seek(struct file *file, loff_t off) } /* - * Decide whether a segment is worth dumping; default is yes to be - * sure (missing info is worse than too much; etc). - * Personally I'd include everything, and use the coredump limit... - * - * I think we should skip something. But I am not sure how. H.J. + * Decide what to dump of a segment, part, all or none. */ -static int maydump(struct vm_area_struct *vma) +static unsigned long vma_dump_size(struct vm_area_struct *vma) { /* The vma can be set up to tell us the answer directly. */ if (vma->vm_flags & VM_ALWAYSDUMP) - return 1; + goto whole; /* Do not dump I/O mapped devices or special mappings */ if (vma->vm_flags & (VM_IO | VM_RESERVED)) return 0; /* Dump shared memory only if mapped from an anonymous file. */ - if (vma->vm_flags & VM_SHARED) - return vma->vm_file->f_path.dentry->d_inode->i_nlink == 0; - - /* If it hasn't been written to, don't write it out */ - if (!vma->anon_vma) + if (vma->vm_flags & VM_SHARED) { + if (vma->vm_file->f_path.dentry->d_inode->i_nlink == 0) + goto whole; return 0; + } - return 1; + /* Dump segments that have been written to. */ + if (vma->anon_vma) + goto whole; + + if (dump_whole_segments) + goto whole; + + /* + * If this looks like the beginning of a DSO or executable mapping, + * check for an ELF header. If we find one, dump the first page to + * aid in determining what was mapped here. + */ + if (dump_dso_headers && vma->vm_file != NULL && vma->vm_pgoff == 0) { + u32 __user *header = (u32 __user *) vma->vm_start; + u32 word; + /* + * Doing it this way gets the constant folded by GCC. + */ + union { + u32 cmp; + char elfmag[SELFMAG]; + } magic; + BUILD_BUG_ON(SELFMAG != sizeof word); + magic.elfmag[EI_MAG0] = ELFMAG0; + magic.elfmag[EI_MAG1] = ELFMAG1; + magic.elfmag[EI_MAG2] = ELFMAG2; + magic.elfmag[EI_MAG3] = ELFMAG3; + if (get_user(word, header) == 0 && word == magic.cmp) + return PAGE_SIZE; + } + + return 0; + +whole: + return vma->vm_end - vma->vm_start; } /* An ELF note in memory */ @@ -1642,16 +1676,13 @@ static int elf_core_dump(long signr, struct pt_regs *regs, struct file *file) for (vma = first_vma(current, gate_vma); vma != NULL; vma = next_vma(vma, gate_vma)) { struct elf_phdr phdr; - size_t sz; - - sz = vma->vm_end - vma->vm_start; phdr.p_type = PT_LOAD; phdr.p_offset = offset; phdr.p_vaddr = vma->vm_start; phdr.p_paddr = 0; - phdr.p_filesz = maydump(vma) ? sz : 0; - phdr.p_memsz = sz; + phdr.p_filesz = vma_dump_size(vma); + phdr.p_memsz = vma->vm_end - vma->vm_start; offset += phdr.p_filesz; phdr.p_flags = vma->vm_flags & VM_READ ? PF_R : 0; if (vma->vm_flags & VM_WRITE) @@ -1692,13 +1723,11 @@ static int elf_core_dump(long signr, struct pt_regs *regs, struct file *file) for (vma = first_vma(current, gate_vma); vma != NULL; vma = next_vma(vma, gate_vma)) { unsigned long addr; + unsigned long end; - if (!maydump(vma)) - continue; + end = vma->vm_start + vma_dump_size(vma); - for (addr = vma->vm_start; - addr < vma->vm_end; - addr += PAGE_SIZE) { + for (addr = vma->vm_start; addr < end; addr += PAGE_SIZE) { struct page *page; struct vm_area_struct *vma; @@ -1756,17 +1785,92 @@ cleanup: #undef NUM_NOTES } + +static ctl_table elf_core_dump_sysctls[] = { + { + .ctl_name = CTL_UNNUMBERED, + .procname = "core_dump_whole_segments", + .data = &dump_whole_segments, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = CTL_UNNUMBERED, + .procname = "core_dump_dso_headers", + .data = &dump_dso_headers, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = 0 } +}; + +static ctl_table binfmt_elf_sysctl_dir[] = { + { + .ctl_name = CTL_UNNUMBERED, + .procname = "binfmt_elf", + .mode = 0555, + .child = elf_core_dump_sysctls, + }, + { .ctl_name = 0 } +}; + +static ctl_table binfmt_elf_sysctl_root[] = { + { + .ctl_name = CTL_FS, + .procname = "fs", + .mode = 0555, + .child = binfmt_elf_sysctl_dir, + }, + { .ctl_name = 0 } +}; + +static struct ctl_table_header *core_dump_sysctl_table; + +static int register_core_dump_sysctl(void) +{ + core_dump_sysctl_table = register_sysctl_table(binfmt_elf_sysctl_root); + if (core_dump_sysctl_table == NULL) + return -ENOMEM; + return 0; +} + +static void unregister_core_dump_sysctl(void) +{ + unregister_sysctl_table(core_dump_sysctl_table); + core_dump_sysctl_table = NULL; +} + +#else + +static int register_core_dump_sysctl(void) +{ + return 0; +} + +static void unregister_core_dump_sysctl(void) +{ +} + #endif /* USE_ELF_CORE_DUMP */ static int __init init_elf_binfmt(void) { - return register_binfmt(&elf_format); + int error = register_core_dump_sysctl(); + if (!error) { + error = register_binfmt(&elf_format); + if (error) + unregister_core_dump_sysctl(); + } + return error; } static void __exit exit_elf_binfmt(void) { /* Remove the COFF and ELF loaders. */ unregister_binfmt(&elf_format); + unregister_core_dump_sysctl(); } core_initcall(init_elf_binfmt); -- 1.5.2.1 From samfw at redhat.com Fri Jun 29 11:50:45 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Fri, 29 Jun 2007 07:50:45 -0400 Subject: Kernel panic on new f7 installation In-Reply-To: References: Message-ID: <4684F215.2010600@redhat.com> Tom Diehl wrote: > Hi, > > I just installed f7 on a new box. When I tried to boot it after install > I got > the following error: > > MP-BIOS bug: 8254 Timer not connected to IO-APIC > > Kernel Panic Not syncing: IO-APIC + Timer doesn't work! Try using the > noapic > kernel parameter. > Hi, I'm not sure if this will be helpful, but with HP machines they added a BIOS option called the "Linux HPET Option" that works around this issue. It could be that Lenovo has something similar. You can read about how HP handled this here: "...these messages occur because the kernel ignores the ACPI timer override for the system timer..." http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00781084 I don't know if this is considered an OS bug per-se. -Sam > Passing nooapic to the kernel at boot lets the machine boot. > > There are no BIOS updates available for the box. > > Is this something I should put into bugzilla or is simply expected on some > machines? > > FYI: > > [root at tigger2 pts0 ~]# uname -r > 2.6.21-1.3228.fc7 > [root at tigger2 pts0 ~]# > > The box is a Lenovo MTM7387-24U > > [root at tigger2 pts0 ~]# lspci -v > 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > Capabilities: [44] HyperTransport: Slave or Primary Interface > Capabilities: [e0] HyperTransport: MSI Mapping > > 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > > 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > Capabilities: [44] #00 [00fe] > Capabilities: [fc] #00 [0000] > > 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) > (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > Capabilities: [40] Subsystem: Lenovo Unknown device 1017 > Capabilities: [48] Power Management version 2 > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/1 Enable- > Capabilities: [60] HyperTransport: MSI Mapping > Capabilities: [80] Express Root Port (Slot+) IRQ 0 > > 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce > 6100] (rev a2) (prog-if 00 [VGA]) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 > Memory at d1000000 (32-bit, non-prefetchable) [size=16M] > Memory at c0000000 (64-bit, prefetchable) [size=256M] > Memory at d0000000 (64-bit, non-prefetchable) [size=16M] > [virtual] Expansion ROM at 30000000 [disabled] [size=128K] > Capabilities: [48] Power Management version 2 > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > > 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > Capabilities: [44] HyperTransport: Slave or Primary Interface > Capabilities: [e0] HyperTransport: MSI Mapping > > 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > > 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel, IRQ 10 > I/O ports at 3040 [size=64] > I/O ports at 3000 [size=64] > Capabilities: [44] Power Management version 2 > > 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) > Subsystem: Lenovo Unknown device 1017 > Flags: 66MHz, fast devsel > > 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) > (prog-if 10 [OHCI]) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 5 > Memory at d2344000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [44] Power Management version 2 > > 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) > (prog-if 20 [EHCI]) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 > Memory at d2346000 (32-bit, non-prefetchable) [size=256] > Capabilities: [44] Debug port > Capabilities: [80] Power Management version 2 > > 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) (prog-if 8a > [Master SecP PriP]) > Subsystem: Unknown device f7aa:1017 > Flags: bus master, 66MHz, fast devsel, latency 0 > [virtual] Memory at 000001f0 (32-bit, non-prefetchable) > [disabled] [size=8] > [virtual] Memory at 000003f0 (type 3, non-prefetchable) > [disabled] [size=1] > [virtual] Memory at 00000170 (32-bit, non-prefetchable) > [disabled] [size=8] > [virtual] Memory at 00000370 (type 3, non-prefetchable) > [disabled] [size=1] > I/O ports at 3080 [size=16] > Capabilities: [44] Power Management version 2 > > 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller > (rev f1) (prog-if 85 [Master SecO PriO]) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 > I/O ports at 30b0 [size=8] > I/O ports at 30a4 [size=4] > I/O ports at c0b0 [size=8] > I/O ports at c0a4 [size=4] > I/O ports at 3090 [size=16] > Memory at d2345000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [44] Power Management version 2 > Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/2 Enable- > Capabilities: [cc] HyperTransport: MSI Mapping > > 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) > (prog-if 01 [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 0 > Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 > I/O behind bridge: 00004000-00004fff > Memory behind bridge: d2000000-d20fffff > Capabilities: [b8] Subsystem: nVidia Corporation Unknown device > cb84 > Capabilities: [8c] HyperTransport: MSI Mapping > > 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio > (rev a2) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11 > Memory at d2340000 (32-bit, non-prefetchable) [size=16K] > Capabilities: [44] Power Management version 2 > Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ > Queue=0/0 Enable- > Capabilities: [6c] HyperTransport: MSI Mapping > > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > Flags: fast devsel > Capabilities: [80] HyperTransport: Host or Secondary Interface > > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > Flags: fast devsel > > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > Flags: fast devsel > > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > Flags: fast devsel > Capabilities: [f0] #0f [0010] > > 03:05.0 Communication controller: Conexant HSF 56k Data/Fax Modem > Subsystem: Conexant Unknown device 2014 > Flags: bus master, fast Back2Back, medium devsel, latency 64, > IRQ 10 > Memory at d2000000 (32-bit, non-prefetchable) [size=64K] > I/O ports at 4000 [size=8] > Capabilities: [40] Power Management version 2 > > 03:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 > Gigabit Ethernet (rev 03) > Subsystem: Lenovo Unknown device 1017 > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 > Memory at d2010000 (32-bit, non-prefetchable) [size=64K] > Capabilities: [48] Power Management version 2 > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/3 Enable- > > [root at tigger2 pts0 ~]# > > I am not sure what other info would be useful, so please ask if someone > feels > I should provide something else. > > Regards, > From kwizart at gmail.com Sat Jun 30 07:36:28 2007 From: kwizart at gmail.com (KH KH) Date: Sat, 30 Jun 2007 09:36:28 +0200 Subject: Rethinking the Ralink wireless driver situation In-Reply-To: <645d17210706200304s4815c94ewe054a14261bc2d46@mail.gmail.com> References: <645d17210706200304s4815c94ewe054a14261bc2d46@mail.gmail.com> Message-ID: 2007/6/20, Jonathan Underwood : > Hi, > > In F-7 a decision was made to bundle in the rt2x00 wireless drivers > for Ralink cards. I contend this was a poor decision because, simply > put, they do not work. Not for any ralink chipset device I have tried > (and I've tried several). Upstream rt2x00 developers have also gone on > a 3 month development hiatus. See: http://rt2x00.serialmonkey.com/ > > But, upstream also maintains what they refer to as enhanced legacy > drivers - basically the open source drivers provided by Ralink but > polished to be more consistent with general use (eg. ripping out the > odd /etc/Wireless configuration tree, and placing firmware in > /lib/firmware). This work *really* well on all devices I have tried > for which rtx00 does not work. It's a hassle for an end user to > install them though, as it involves blacklisting the broken rtx00 > modules. Not a big deal, but it wrecks the "out of the box" > experience. > > So, please please consider bundling the rt2400, rt2500, rt2470, rt61 > and rt73 drivers for F-8 and ditching rt2x00 until they make it into > the upstream kernel. > > Jonathan. > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > Hi! Some users report them to work well with or without RutilT tool (which is currently in review). This tool was design primarily to support special function of the legacies drivers but should work with new rt2x00 version also... see here http://cbbk.free.fr/bonrom/ and here : https://bugzilla.redhat.com/202521 I probably miss the right PAM implementation so you need to lauch it as root for now: su - rutilt Nicolas (kwizart) PS Dave : Sorry for the mail, i miss the reply all...