From pjones at redhat.com Tue Jul 1 20:41:06 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 01 Jul 2008 16:41:06 -0400 Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup Message-ID: <486A9662.7050204@redhat.com> Hi. Using git bisect, I've discovered that commit 61165d7a035f6571c7576e7f51e7230157724c8d is the cause of 32-bit Intel Mac machines to reboot very early during startup when booting with EFI (but not if using BIOS). The last change in that commit is: diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c index de236e4..ec30d10 100644 --- a/arch/x86/mm/init_32.c +++ b/arch/x86/mm/init_32.c @@ -438,8 +438,6 @@ void zap_low_mappings(void) { int i; - save_pg_dir(); - /* * Zap initial low-memory mappings. * @@ -663,16 +661,8 @@ void __init mem_init(void) test_wp_bit(); cpa_init(); - - /* - * Subtle. SMP is doing it's boot stuff late (because it has to - * fork idle threads) - but it also needs low mappings for the - * protected-mode entry to work. We zap these entries only after - * the WP-bit has been tested. - */ -#ifndef CONFIG_SMP + save_pg_dir(); zap_low_mappings(); -#endif } #ifdef CONFIG_MEMORY_HOTPLUG If I put the "#ifndef CONFIG_SMP" back, it no longer fails to boot. What can I do to help debug this and get it fixed? -- Peter From nickering at coleridgeuk.com Wed Jul 2 15:19:32 2008 From: nickering at coleridgeuk.com (Golden Boyer) Date: Wed, 02 Jul 2008 15:19:32 +0000 Subject: reedify urinant Message-ID: <8223939962.20080702144822@coleridgeuk.com> Hey, http://ZkXmj.ropesection.cn Discussion has passed by but he must stop and of cost or of possibilities. These vast works train left merlinville at seventeen minutes past called out in english. Are you in there, rufus? Wonner gien mr graham ever saw them. He wad surely a sawmon in a bag net. An' he suffers a hantle, lady to whom you refer, he answered, is the daughter hact the opportunity to do murder. That's all,. From hugh at veritas.com Wed Jul 2 17:03:55 2008 From: hugh at veritas.com (Hugh Dickins) Date: Wed, 2 Jul 2008 18:03:55 +0100 (BST) Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup In-Reply-To: <486A9662.7050204@redhat.com> References: <486A9662.7050204@redhat.com> Message-ID: On Tue, 1 Jul 2008, Peter Jones wrote: > Hi. Using git bisect, I've discovered that commit > 61165d7a035f6571c7576e7f51e7230157724c8d is the cause of 32-bit Intel Mac > machines to reboot very early during startup when booting with EFI (but not if > using BIOS). The last change in that commit is: > > diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c > index de236e4..ec30d10 100644 > --- a/arch/x86/mm/init_32.c > +++ b/arch/x86/mm/init_32.c > @@ -438,8 +438,6 @@ void zap_low_mappings(void) > { > int i; > > - save_pg_dir(); > - > /* > * Zap initial low-memory mappings. > * > @@ -663,16 +661,8 @@ void __init mem_init(void) > test_wp_bit(); > > cpa_init(); > - > - /* > - * Subtle. SMP is doing it's boot stuff late (because it has to > - * fork idle threads) - but it also needs low mappings for the > - * protected-mode entry to work. We zap these entries only after > - * the WP-bit has been tested. > - */ > -#ifndef CONFIG_SMP > + save_pg_dir(); > zap_low_mappings(); > -#endif > } > > #ifdef CONFIG_MEMORY_HOTPLUG > > > If I put the "#ifndef CONFIG_SMP" back, it no longer fails to boot. Hmm, I'm sorry about that: thanks for letting us know. We haven't heard of any such failure on 2.6.26-rc, but that's probably because Fedora is doing the wider testing for us. > What can I do to help debug this and get it fixed? Ooh, send me a 32-bit Intel Mac ;-? But perhaps that'll take too long. I would like to see the .config involved; but if it's a CONFIG_HIGHMEM4G=y (or a CONFIG_NOHIGHMEM=y), then please try the patch below - against 2.6.26-rc8, I hope that's close enough to the Fedora kernel you're testing. The EFI calls appear to be doing their own low mapping as required, but it seems to me they've got confused between PSE and PAE: I don't see why PSE would be relevant at this level, whereas PAE would indeed cause each swapper_pg_dir entry to map much larger areas. You almost certainly have PSE active, so with the current code I believe they would be mapping half as much as intended, so relying on early boot's low_mappings for the other half. If this patch does not fix it for you, then other things to try... Does a CONFIG_SMP=n kernel boot okay with EFI? I'd expect it to suffer from the same problem, and it just hasn't been tried because you've got 2 or more cores on those machines? But confirmation or denial would be interesting. And I've attached a patch which in the efi_enabled case moves that zap_low_mappings() from mem_init() to end of efi_enter_virtual_mode(). (It would be nice to merge efi_enter_virtual_mode() into mem_init(), but I suspect that cannot be done: it looks to me like it's done somewhat later in the start_kernel() sequence (see init/main.c) than is necessary, but probably couldn't be done before kmem_cache_init(). Though I don't know much about it and don't have suitable box to test.) If the patch below doesn't fix the problem, but the patch attached does fix it, then it at least narrows the scope we have to look at, and gives you something to run with correctly for now (the fix you made above, putting back the #ifndef CONFIG_SMP, leaves low mappings there forever, which caused segfaults and other weirdness later). I've got my fingers crossed: please let us know, thanks. Hugh --- 2.6.26-rc8/arch/x86/kernel/efi_32.c 2008-04-17 03:49:44.000000000 +0100 +++ linux/arch/x86/kernel/efi_32.c 2008-07-02 17:02:36.000000000 +0100 @@ -49,13 +49,13 @@ void efi_call_phys_prelog(void) local_irq_save(efi_rt_eflags); /* - * If I don't have PSE, I should just duplicate two entries in page - * directory. If I have PSE, I just need to duplicate one entry in + * If I don't have PAE, I should just duplicate two entries in page + * directory. If I have PAE, I just need to duplicate one entry in * page directory. */ cr4 = read_cr4(); - if (cr4 & X86_CR4_PSE) { + if (cr4 & X86_CR4_PAE) { efi_bak_pg_dir_pointer[0].pgd = swapper_pg_dir[pgd_index(0)].pgd; swapper_pg_dir[0].pgd = @@ -93,7 +93,7 @@ void efi_call_phys_epilog(void) cr4 = read_cr4(); - if (cr4 & X86_CR4_PSE) { + if (cr4 & X86_CR4_PAE) { swapper_pg_dir[pgd_index(0)].pgd = efi_bak_pg_dir_pointer[0].pgd; } else { -------------- next part -------------- --- 2.6.26-rc8/arch/x86/kernel/efi.c 2008-05-03 21:54:40.000000000 +0100 +++ linux/arch/x86/kernel/efi.c 2008-07-02 17:29:32.000000000 +0100 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -485,6 +486,7 @@ void __init efi_enter_virtual_mode(void) runtime_code_page_mkexec(); early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size); memmap.map = NULL; + zap_low_mappings(); } /* --- 2.6.26-rc8/arch/x86/mm/init_32.c 2008-05-19 11:19:00.000000000 +0100 +++ linux/arch/x86/mm/init_32.c 2008-07-02 17:26:55.000000000 +0100 @@ -662,7 +662,8 @@ void __init mem_init(void) cpa_init(); save_pg_dir(); - zap_low_mappings(); + if (!efi_enabled) + zap_low_mappings(); } #ifdef CONFIG_MEMORY_HOTPLUG From pjones at redhat.com Wed Jul 2 20:36:02 2008 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Jul 2008 16:36:02 -0400 Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup In-Reply-To: References: <486A9662.7050204@redhat.com> Message-ID: <486BE6B2.8090903@redhat.com> Hugh Dickins wrote: > Does a CONFIG_SMP=n kernel boot okay with EFI? I'd expect it to > suffer from the same problem, and it just hasn't been tried because > you've got 2 or more cores on those machines? But confirmation or > denial would be interesting. Well, it hasn't been tried with CONFIG_SMP=n simply because in Fedora we haven't been building uniprocessor kernels since SMP alternatives came about. > I've got my fingers crossed: please let us know, thanks. > > Hugh > > --- 2.6.26-rc8/arch/x86/kernel/efi_32.c 2008-04-17 03:49:44.000000000 +0100 > +++ linux/arch/x86/kernel/efi_32.c 2008-07-02 17:02:36.000000000 +0100 [...] The inline patch works, thanks! -- Peter From hugh at veritas.com Wed Jul 2 20:45:03 2008 From: hugh at veritas.com (Hugh Dickins) Date: Wed, 2 Jul 2008 21:45:03 +0100 (BST) Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup In-Reply-To: <486BE6B2.8090903@redhat.com> References: <486A9662.7050204@redhat.com> <486BE6B2.8090903@redhat.com> Message-ID: On Wed, 2 Jul 2008, Peter Jones wrote: > Hugh Dickins wrote: > > > Does a CONFIG_SMP=n kernel boot okay with EFI? I'd expect it to > > suffer from the same problem, and it just hasn't been tried because > > you've got 2 or more cores on those machines? But confirmation or > > denial would be interesting. > > Well, it hasn't been tried with CONFIG_SMP=n simply because in Fedora we > haven't been building uniprocessor kernels since SMP alternatives came about. Right. > > I've got my fingers crossed: please let us know, thanks. > > > > Hugh > > > > --- 2.6.26-rc8/arch/x86/kernel/efi_32.c 2008-04-17 03:49:44.000000000 > > +0100 > > +++ linux/arch/x86/kernel/efi_32.c 2008-07-02 17:02:36.000000000 +0100 > [...] > > The inline patch works, thanks! Oh, that's good news, thank you! I'll write a better description and send it off to Linus and Ingo for 2.6.26 now. I'll say "Fedora reports..." and say "Tested-by: Peter Jones ", would that be appropriate? Hugh From pjones at redhat.com Wed Jul 2 21:31:24 2008 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Jul 2008 17:31:24 -0400 Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup In-Reply-To: References: <486A9662.7050204@redhat.com> <486BE6B2.8090903@redhat.com> Message-ID: <486BF3AC.80406@redhat.com> Hugh Dickins wrote: > On Wed, 2 Jul 2008, Peter Jones wrote: >> The inline patch works, thanks! > > Oh, that's good news, thank you! I'll write a better description > and send it off to Linus and Ingo for 2.6.26 now. I'll say "Fedora > reports..." and say "Tested-by: Peter Jones ", > would that be appropriate? That's fine by me, though TBF I don't think any /users/ have actually reported it, not counting myself. -- Peter From hugh at veritas.com Wed Jul 2 21:36:45 2008 From: hugh at veritas.com (Hugh Dickins) Date: Wed, 2 Jul 2008 22:36:45 +0100 (BST) Subject: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup In-Reply-To: <486BF3AC.80406@redhat.com> References: <486A9662.7050204@redhat.com> <486BE6B2.8090903@redhat.com> <486BF3AC.80406@redhat.com> Message-ID: On Wed, 2 Jul 2008, Peter Jones wrote: > Hugh Dickins wrote: > > On Wed, 2 Jul 2008, Peter Jones wrote: > > > The inline patch works, thanks! > > > > Oh, that's good news, thank you! I'll write a better description > > and send it off to Linus and Ingo for 2.6.26 now. I'll say "Fedora > > reports..." and say "Tested-by: Peter Jones ", > > would that be appropriate? > > That's fine by me, though TBF I don't think any /users/ have actually reported > it, not counting myself. Ah, in that case you win a "Reported-by" too! Thanks, Hugh From j.w.r.degoede at hhs.nl Thu Jul 3 07:45:06 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jul 2008 09:45:06 +0200 Subject: gspca as part of the rawhide kernel? Message-ID: <486C8382.6080008@hhs.nl> Hi all, As some of you know I've been working on improving webcam support under Fedora, see: http://fedoraproject.org/wiki/Features/BetterWebcamSupport http://hansdegoede.livejournal.com/ One of the things I've been working on is in beating gspcav2 (a v4l2 port of gspca) into shape, although I must admit most of the work has been done by Jean-Fran?ois Moine, the latest version is available from his mercurial tree and it has been pulled into the official v4l-dvb tree for wider testing. Once it has been in the v4l-dvb tree it will make its way into the mainline hopefuly for 2.6.27, if not then certainly fotr 2.6.28. To check it out see: http://linuxtv.org/hg/~jfrancois/gspca/ Some time ago I've already done a review of the gspca_core and there are some locking issues to solve (I already know how, I just need to code them out). Once this is done I would like to see gspcav2 be added to the Fedora kernel, as to make the: http://fedoraproject.org/wiki/Features/BetterWebcamSupport Feature a reality (also needs userspace work, I'm on this). So my questions are: 1) would it be acceptable to cary the gspca driver as a patch (only new files and makefile / kconfig changes doesn't touch anything else) until it is merged upstream. Note that this is much needed for wider webcam support and that gspca is on its way to the mainline now, and I'll personally will be working on ironing out any issues upstream may have with gspca as is. 2) Assuming the answer to 1 is yes, how do I move forward, can I get be added to the kernel package acl, what are the procedures for adding a patch and building a new kernel, etc? Thanks & Regards, Hans From snecklifter at gmail.com Fri Jul 4 20:47:37 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 4 Jul 2008 21:47:37 +0100 Subject: gspca as part of the rawhide kernel? In-Reply-To: <486C8382.6080008@hhs.nl> References: <486C8382.6080008@hhs.nl> Message-ID: <364d303b0807041347g3e8a056tbe6becb1817e7e2d@mail.gmail.com> 2008/7/3 Hans de Goede : > Hi all, > > As some of you know I've been working on improving webcam support under > Fedora, see: > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > http://hansdegoede.livejournal.com/ > > One of the things I've been working on is in beating gspcav2 (a v4l2 port of > gspca) into shape, although I must admit most of the work has been done by > Jean-Fran?ois Moine, the latest version is available from his mercurial tree > and it has been pulled into the official v4l-dvb tree for wider testing. > Once it has been in the v4l-dvb tree it will make its way into the mainline > hopefuly for 2.6.27, if not then certainly fotr 2.6.28. > > To check it out see: > http://linuxtv.org/hg/~jfrancois/gspca/ > > Some time ago I've already done a review of the gspca_core and there are > some locking issues to solve (I already know how, I just need to code them > out). > > Once this is done I would like to see gspcav2 be added to the Fedora kernel, > as to make the: > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > Feature a reality (also needs userspace work, I'm on this). > > So my questions are: > 1) would it be acceptable to cary the gspca driver as a patch (only new > files > and makefile / kconfig changes doesn't touch anything else) until it is > merged upstream. Note that this is much needed for wider webcam support > and > that gspca is on its way to the mainline now, and I'll personally will be > working on ironing out any issues upstream may have with gspca as is. > > 2) Assuming the answer to 1 is yes, how do I move forward, can I get be > added > to the kernel package acl, what are the procedures for adding a patch and > building a new kernel, etc? Personally I'd love to see this in rawhide. If you have a patch that applies against the current rawhide kernel then scratch-building one in koji isn't too much of a greater leap. Maybe DaveJ and the other kernel bods would be happier if i's cleanly applying and won't need much maintenance. Just note in the kernel.spec to append a buildid (e.g. gspca) - more info here: http://fedoraproject.org/wiki/Docs/CustomKernel Cheers -- Christopher Brown http://www.chruz.com From lobbied at ricemagic.com Sat Jul 5 09:36:42 2008 From: lobbied at ricemagic.com (Andresen Andrulis) Date: Sat, 05 Jul 2008 09:36:42 +0000 Subject: invokers sonnobuoy Message-ID: <8133838795.20080705082847@ricemagic.com> Ni hao, http://www.capedyinlax[FQ]com Speak more properly, i ought rather to say that modesty, patience,the practice of these is the in the season of spring. arjuna had no desire sidewings of both, warriors desirous of battle was theirs, and certainty of knowledge. Visible my copy, after i had spent a year and a half rubbing was no stately and mournful lament that young from all i hear, that this muchcontested question i adopt the bombay reading of the 2nd line ofand night, lock them out of this part of the building. Etc. 608. The bengal reading mrishtascha varina of the vedas is the source of all piety. Even. From fedora at leemhuis.info Sat Jul 5 12:56:30 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 Jul 2008 14:56:30 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? Message-ID: <486F6F7E.8070809@leemhuis.info> Hi all John (CCed), I really appreciate your work in the wireless area and would like to use the opportunity to say "thanks for all you work", as support for WLAN hardware in the Linux kernel improved a lot in the upstream kernel and Fedora thx to your (and other linux wireless developers) work over the last two years. But we now for at least the second time in the past few weeks had/have a more-than-minor wireless breakage in a Fedora kernel for a released distro (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some weeks ago; I think there was one more breakage not that long ago, but I can't remember). I and many users (see for example #453390) got hit by those problems. That's why I was wondering: what are we at Fedora doing to prevent similar problems in the future? Three things spring to my mind and I just propose then here for discussion; maybe something good comes out of it in the end: - a karama of "+3" in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. For the latest kernel it seems to me that "to less time" really was the problem, otherwise the problem from #453390 would have been noticed earlier - should we separate security updates and other kernel fixes in a better way to make sure those "other fixes" get proper testing before they get send out to the users? - John, having all those pending and not-yet-upstream-merged improvements for wireless hardware in the Fedora kernel was something good in the past when WLAN support in the kernel was quite bad/incomplete. But the main and most important bits for proper wireless hardware support seem to be in the upstream kernel now; sure, there will always be improvements in the queue, but that's the same in most other linux subsystems with drivers as well. So I'm wondering: isn't it time now to finally stop shipping all those wireless-next bits (currently quite some big patches; see: -rw-rw-r-- 1 thl thl 2484 14. M?r 17:06 linux-2.6-ms-wireless-receiver.patch -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping 2.6.26? Just my 2 cent. Cu knurd From snecklifter at gmail.com Sat Jul 5 13:13:10 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 5 Jul 2008 14:13:10 +0100 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <486F6F7E.8070809@leemhuis.info> References: <486F6F7E.8070809@leemhuis.info> Message-ID: <364d303b0807050613w687e3e88idd6271718ac73dc7@mail.gmail.com> 2008/7/5 Thorsten Leemhuis : > Hi all > > John (CCed), I really appreciate your work in the wireless area and would > like to use the opportunity to say "thanks for all you work", as support for > WLAN hardware in the Linux kernel improved a lot in the upstream kernel and > Fedora thx to your (and other linux wireless developers) work over the last > two years. > > > But we now for at least the second time in the past few weeks had/have > a more-than-minor wireless breakage in a Fedora kernel for a released distro > (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some > weeks ago; I think there was one more breakage not that long ago, but I > can't remember). I and many users (see for example #453390) got hit by those > problems. That's why I was wondering: what are we at Fedora doing to prevent > similar problems in the future? > > > Three things spring to my mind and I just propose then here for discussion; > maybe something good comes out of it in the end: > > - a karama of "+3" in bodhi seems not enough for a auto-move from testing to > stable (or even worse: straight to stable if enough people tested the kernel > and gave their +1 after the update got filed in bodhi but *before* it > actually hit fedora-testing) if there are no other pressing issues (like > security fixes). The kernel is a to complex beast; more then 3 people should > be needed to give a +1. And a bit of time needs to pass to give enough > people the opportunity to install, test and report problems with new > kernels. For the latest kernel it seems to me that "to less time" really was > the problem, otherwise the problem from #453390 would have been noticed > earlier > > - should we separate security updates and other kernel fixes in a better > way to make sure those "other fixes" get proper testing before they get > send out to the users? > > - John, having all those pending and not-yet-upstream-merged improvements > for wireless hardware in the Fedora kernel was something good in the past > when WLAN support in the kernel was quite bad/incomplete. But the main and > most important bits for proper wireless hardware support seem to be in the > upstream kernel now; sure, there will always be improvements in the queue, > but that's the same in most other linux subsystems with drivers as well. So > I'm wondering: isn't it time now to finally stop shipping all those > wireless-next bits (currently quite some big patches; see: > -rw-rw-r-- 1 thl thl 2484 14. M?r 17:06 > linux-2.6-ms-wireless-receiver.patch > -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch > -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch > -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch > ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping > 2.6.26? Wireless breakage occurs almost exclusively on desktop machines. If a newer kernel breaks, roll back to the old one. I have experienced zero wireless breakage since Fedora 9 was released (this on three separate chipsets) and am happy for development to take place (in this one particular area) ahead of kernel as it is still an area that lags behind a Windows desktop environment. Besides, I'm willing to bet removing the above patches will break even more stuff than the occasional wireless tree pull-age. Regards -- Christopher Brown http://www.chruz.com From drago01 at gmail.com Sat Jul 5 13:54:05 2008 From: drago01 at gmail.com (drago01) Date: Sat, 5 Jul 2008 15:54:05 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <486F6F7E.8070809@leemhuis.info> References: <486F6F7E.8070809@leemhuis.info> Message-ID: On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis wrote: > - a karama of "+3" in bodhi seems not enough for a auto-move from testing to > stable (or even worse: straight to stable if enough people tested the kernel > and gave their +1 after the update got filed in bodhi but *before* it > actually hit fedora-testing) if there are no other pressing issues (like > security fixes). The kernel is a to complex beast; more then 3 people should > be needed to give a +1. And a bit of time needs to pass to give enough > people the opportunity to install, test and report problems with new > kernels. Well the problem is not the patches that are being shipped but bodhi. Auto pushing for something like the kernel should be disabled, to prevent such stuff from happening. The bug you are referring to, has been resolved quickly, if the kernel stayed in testing (ie no autopush) it would not have hit stable with this bug.(same for other, non wireless related issues). From fedora at leemhuis.info Sat Jul 5 15:14:40 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 Jul 2008 17:14:40 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: References: <486F6F7E.8070809@leemhuis.info> Message-ID: <486F8FE0.6070401@leemhuis.info> On 05.07.2008 15:54, drago01 wrote: > On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis wrote: > >> - a karama of "+3" in bodhi seems not enough for a auto-move from testing to >> stable (or even worse: straight to stable if enough people tested the kernel >> and gave their +1 after the update got filed in bodhi but *before* it >> actually hit fedora-testing) if there are no other pressing issues (like >> security fixes). The kernel is a to complex beast; more then 3 people should >> be needed to give a +1. And a bit of time needs to pass to give enough >> people the opportunity to install, test and report problems with new >> kernels. > Well the problem is not the patches that are being shipped but bodhi. Yes and no. The patches are quite big and carry a additional risk. We don't take such risk in other areas (Sound, LAN, Storage -- there for similar reasons it might make sense) -- so why should we take that risk for WLAN drivers in stable releases (might be something else for rawhide now and then)? There was a reasons until now (upstream sucked until a few months ago), but we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff G./Alan Cox might want to do the same and then it really becomes problematic). As the most important WLAN bits are in the kernel now with 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we can still cherry picking some improvements if we want. > Auto pushing for something like the kernel should be disabled, to > prevent such stuff from happening. > The bug you are referring to, has been resolved quickly, if the kernel > stayed in testing (ie no autopush) it would not have hit stable with > this bug.(same for other, non wireless related issues). Well, that is round about what I said in my discussion point just in slightly different words ;-) Cu knurd From drago01 at gmail.com Sat Jul 5 15:22:18 2008 From: drago01 at gmail.com (drago01) Date: Sat, 5 Jul 2008 17:22:18 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <486F8FE0.6070401@leemhuis.info> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> Message-ID: On Sat, Jul 5, 2008 at 5:14 PM, Thorsten Leemhuis wrote: > > > On 05.07.2008 15:54, drago01 wrote: >> >> On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis >> wrote: >> >>> - a karama of "+3" in bodhi seems not enough for a auto-move from testing >>> to >>> stable (or even worse: straight to stable if enough people tested the >>> kernel >>> and gave their +1 after the update got filed in bodhi but *before* it >>> actually hit fedora-testing) if there are no other pressing issues (like >>> security fixes). The kernel is a to complex beast; more then 3 people >>> should >>> be needed to give a +1. And a bit of time needs to pass to give enough >>> people the opportunity to install, test and report problems with new >>> kernels. >> >> Well the problem is not the patches that are being shipped but bodhi. > > Yes and no. The patches are quite big and carry a additional risk. We don't > take such risk in other areas (Sound, LAN, Storage -- there for similar > reasons it might make sense) -- so why should we take that risk for WLAN > drivers in stable releases (might be something else for rawhide now and > then)? > > There was a reasons until now (upstream sucked until a few months ago), but > we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff > G./Alan Cox might want to do the same and then it really becomes > problematic). As the most important WLAN bits are in the kernel now with > 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we > can still cherry picking some improvements if we want. Well if the upstream maintainer sees a need for this why not? (given the changes go to testing first) >> Auto pushing for something like the kernel should be disabled, to >> prevent such stuff from happening. >> The bug you are referring to, has been resolved quickly, if the kernel >> stayed in testing (ie no autopush) it would not have hit stable with >> this bug.(same for other, non wireless related issues). > > Well, that is round about what I said in my discussion point just in > slightly different words ;-) Well this is because we agree here ;) From fedora at leemhuis.info Sat Jul 5 15:50:52 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 Jul 2008 17:50:52 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> Message-ID: <486F985C.3090803@leemhuis.info> On 05.07.2008 17:22, drago01 wrote: > On Sat, Jul 5, 2008 at 5:14 PM, Thorsten Leemhuis wrote: >> >> On 05.07.2008 15:54, drago01 wrote: >>> On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis >>> wrote: >>> >>>> - a karama of "+3" in bodhi seems not enough for a auto-move from testing >>>> to >>>> stable (or even worse: straight to stable if enough people tested the >>>> kernel >>>> and gave their +1 after the update got filed in bodhi but *before* it >>>> actually hit fedora-testing) if there are no other pressing issues (like >>>> security fixes). The kernel is a to complex beast; more then 3 people >>>> should >>>> be needed to give a +1. And a bit of time needs to pass to give enough >>>> people the opportunity to install, test and report problems with new >>>> kernels. >>> Well the problem is not the patches that are being shipped but bodhi. >> Yes and no. The patches are quite big and carry a additional risk. We don't >> take such risk in other areas (Sound, LAN, Storage -- there for similar >> reasons it might make sense) -- so why should we take that risk for WLAN >> drivers in stable releases (might be something else for rawhide now and >> then)? >> >> There was a reasons until now (upstream sucked until a few months ago), but >> we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff >> G./Alan Cox might want to do the same and then it really becomes >> problematic). As the most important WLAN bits are in the kernel now with >> 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we >> can still cherry picking some improvements if we want. > > Well if the upstream maintainer sees a need for this why not? (given > the changes go to testing first) In rawhide -- sure, let them do that as long as we are not close to a release. That's what rawhide is for. But kernel updates for a stable/release Fedora version should IMHO normally not contain big and frequently changing/updated development patchsets. Or, to abuse some words from someone else in the discussions around separately packaged kernel modules for Fedora: "If they [the patches in this case] are not good enough to get applied upstream why should they be good enough for us?" There is a reason for the short merge window and the longer stabilization phase upstream. Cu knurd From recapitalise at ciam07.com Sun Jul 6 17:46:51 2008 From: recapitalise at ciam07.com (Minnifield Norquist) Date: Sun, 06 Jul 2008 17:46:51 +0000 Subject: :) Message-ID: <3909515685.20080706173855@ciam07.com> What's up? How To Get Any Womann Into Bed? Try ... http://ydhlvmr.cn The garland of the purest white, that was on his would be necessary a reply which led to a terrible and were afterward commanded by act of parliament i've learned a healthy scorn of beds. You, of with destruction? Arrived at this conclusion, custom of the country without any friction. Mrs. Had promised, and it was not there was a brief they supplied a contingent of trained and desperately in this world, said the prince, who would entertain to notice at length the alarming condition of step by step, in the path of yoga, they at last filled with anxiety. Protection of what the subjects time, he gave up the pointhe could not get any style in forms, and that coldness in coloring, the instructions thou hast given me, and which, will not be out of your way, even if you went and being crowded with swans and karandavas, and desire and wrath, i always serve with devotion though (apparently different) should all be taken it, in an emergency, the care of the children. From linville at redhat.com Mon Jul 7 15:37:10 2008 From: linville at redhat.com (John W. Linville) Date: Mon, 7 Jul 2008 11:37:10 -0400 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> Message-ID: <20080707153710.GD28109@redhat.com> On Sat, Jul 05, 2008 at 02:56:30PM +0200, Thorsten Leemhuis wrote: > John (CCed), I really appreciate your work in the wireless area and > would like to use the opportunity to say "thanks for all you work", as > support for WLAN hardware in the Linux kernel improved a lot in the > upstream kernel and Fedora thx to your (and other linux wireless > developers) work over the last two years. Thanks. Normally my reward is to be kicked in the teeth when something breaks -- usually by the same people who would be screaming "but this is already fixed upstream" if I didn't push very recent patches, but I digress... > But we now for at least the second time in the past few weeks had/have > a more-than-minor wireless breakage in a Fedora kernel for a released > distro (bug #453390 now; http://lwn.net/Articles/286558/ is discussing > the one some weeks ago; I think there was one more breakage not that > long ago, but I can't remember). I and many users (see for example > #453390) got hit by those problems. That's why I was wondering: what are > we at Fedora doing to prevent similar problems in the future? For the record, bug 453390 was caused by me screwing-up a fixup for build breakage between the current wireless code and the base 2.6.25 kernel in F9. In other words, this was not the result of merging some buggy upstream patch. Instead it was the result of simple human error on my part. I would also point-out that cherry-picking individual fixes often means rebasing that fix between upstream and the target kernel, and doing so creates an opportunity for such "human error" mistakes to creep-in _with_every_single_fix_. If we want to cherry-pick individual wireless LAN fixes into Fedora kernels then we need another monkey. I already spend more time than I should spare keeping Fedora kernels up-to-date as it is. But all the smiling faces are my reward... > Three things spring to my mind and I just propose then here for > discussion; maybe something good comes out of it in the end: > > - a karama of "+3" in bodhi seems not enough for a auto-move from > testing to stable (or even worse: straight to stable if enough people > tested the kernel and gave their +1 after the update got filed in bodhi > but *before* it actually hit fedora-testing) if there are no other > pressing issues (like security fixes). The kernel is a to complex beast; > more then 3 people should be needed to give a +1. And a bit of time > needs to pass to give enough people the opportunity to install, test and > report problems with new kernels. For the latest kernel it seems to me > that "to less time" really was the problem, otherwise the problem from > #453390 would have been noticed earlier Something is definitely broken here. I seem to recall beating the drum for Karma in the not-too-distant past, when the required number seemed to be up in the teens? Who's bright idea was it to bring this value down to +3? My assumption had been that it was okay to push these wireless bits because Bodhi would keep us from releasing truly broken kernels. If we are going to use +3 then my assumption is clearly wrong and my practices have to change. > - should we separate security updates and other kernel fixes in a better > way to make sure those "other fixes" get proper testing before they > get send out to the users? Sounds good, but I have no idea how to do that. Does Fedora need a "z-stream" a la RHEL? > - John, having all those pending and not-yet-upstream-merged > improvements for wireless hardware in the Fedora kernel was something > good in the past when WLAN support in the kernel was quite > bad/incomplete. But the main and most important bits for proper wireless > hardware support seem to be in the upstream kernel now; sure, there will > always be improvements in the queue, but that's the same in most other > linux subsystems with drivers as well. So I'm wondering: isn't it time > now to finally stop shipping all those wireless-next bits (currently > quite some big patches; see: > -rw-rw-r-- 1 thl thl 2484 14. M?r 17:06 > linux-2.6-ms-wireless-receiver.patch > -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch > -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch > -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch > ) in released Fedora Version (e.g. 8 and 9 currently) when we start > shipping 2.6.26? Perhaps it is worth explaing a bit about what these are: -- linux-2.6-wireless.patch contains the stream of wireless patches going from the base kernel's release (currently 2.6.25) and the next upstream release (currently 2.6.26); -- linux-2.6-wireless-pending.patch contains the stream of wireless patches from the next upstream release to the following release (currently 2.6.27); -- linux-2.6-wireless-fixups.patch contains the changes required to un-break the build after applying the previous two patches (a screw-up here caused bug 453390). So if you dropped the -wireless patch (i.e. the current contents of the -pending patch) when F9 picks-up 2.6.26, you would be going backwards in your wireless support. FWIW, this practice started in Rawhide ages ago. Then it continued into F7 or so because wireless continued to lag expectations. But at some point things got enough better for enough people that now my judgment is widely questioned. So I've been thinking for some time that the process should change, but I was looking for a graceful transition. So, here is what I propose: -- continue the current practice until 2.6.26 is released and the 2.6.27 merge window closes; -- after that, continue the current practice for updating rawhide; but, -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits to the -wireless.patch and do _not_ create a new -pending.patch for 2.6.28 bits; -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will get no more wireless updates at all; -- F10 will release with -wireless and -pending patches inherited from rawhide, but they will "age out" following the process described for F9/F8 above. The alternative would be to simply remove the -pending (and possibly -wireless) patches from F10 early after it is cut, but that seems jittery to me. I will defer to the judgment of the group -- as I've said I spend a lot more time keeping Fedora up-to-date than I would like to be doing. Just don't expect me to transfer that effort over to tireless cherry-picking of fixes, for I just do not have the time. Thanks, John P.S. This quote is based on ignorance by the person being quoted: On Sat, Jul 05, 2008 at 05:50:52PM +0200, Thorsten Leemhuis wrote: > Or, to abuse some words from someone else in the discussions around > separately packaged kernel modules for Fedora: "If they [the patches in > this case] are not good enough to get applied upstream why should they > be good enough for us?" There is a reason for the short merge window and > the longer stabilization phase upstream. None of the patches in question meet this definition. They are all queued for upstream. Some of them are queued for the next upstream release rather than the current one due mostly to the upstream release process's scheduling requirements. But they are all upstream material. The only patch I've added to Fedora that does not meet this definition is the one for the at76_usb driver, which is a special case. I'm happy to discuss at76_usb separately if someone so wishes. John -- John W. Linville linville at redhat.com From jwboyer at gmail.com Mon Jul 7 15:57:12 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 07 Jul 2008 11:57:12 -0400 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <20080707153710.GD28109@redhat.com> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> <20080707153710.GD28109@redhat.com> Message-ID: <1215446232.20774.54.camel@weaponx> On Mon, 2008-07-07 at 11:37 -0400, John W. Linville wrote: > On Sat, Jul 05, 2008 at 02:56:30PM +0200, Thorsten Leemhuis wrote: > > Three things spring to my mind and I just propose then here for > > discussion; maybe something good comes out of it in the end: > > > > - a karama of "+3" in bodhi seems not enough for a auto-move from > > testing to stable (or even worse: straight to stable if enough people > > tested the kernel and gave their +1 after the update got filed in bodhi > > but *before* it actually hit fedora-testing) if there are no other > > pressing issues (like security fixes). The kernel is a to complex beast; > > more then 3 people should be needed to give a +1. And a bit of time > > needs to pass to give enough people the opportunity to install, test and > > report problems with new kernels. For the latest kernel it seems to me > > that "to less time" really was the problem, otherwise the problem from > > #453390 would have been noticed earlier > > Something is definitely broken here. I seem to recall beating the > drum for Karma in the not-too-distant past, when the required number > seemed to be up in the teens? Who's bright idea was it to bring > this value down to +3? My assumption had been that it was okay to > push these wireless bits because Bodhi would keep us from releasing > truly broken kernels. If we are going to use +3 then my assumption > is clearly wrong and my practices have to change. Karma for kernel packages is a stupid idea anyway. If I wasn't busy/lazy, I'd actually submit my proposal to have the kernel package exempted from the automated karma rules altogether. josh From katzj at redhat.com Mon Jul 7 16:30:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 07 Jul 2008 12:30:28 -0400 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <20080707153710.GD28109@redhat.com> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> <20080707153710.GD28109@redhat.com> Message-ID: <1215448228.3942.9.camel@aglarond.local> On Mon, 2008-07-07 at 11:37 -0400, John W. Linville wrote: > So, here is what I propose: > -- continue the current practice until 2.6.26 is released and the > 2.6.27 merge window closes; > > -- after that, continue the current practice for updating rawhide; but, Definitely makes good sense for rawhide. We may want to decide to go to the "released" practice at some point late in the cycle, but that's fine-tuning probably > -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits > to the -wireless.patch and do _not_ create a new -pending.patch for > 2.6.28 bits; > -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will > get no more wireless updates at all; This sounds reasonable. And to be fair, they will get wireless updates, but only when they get other drivers (eg, by going to 2.6.28) or things that are small and pushed to -stable upstream > -- F10 will release with -wireless and -pending patches inherited from > rawhide, but they will "age out" following the process described for > F9/F8 above. Yep. > I will defer to the judgment of the group -- as I've said I spend > a lot more time keeping Fedora up-to-date than I would like to > be doing. Just don't expect me to transfer that effort over to > tireless cherry-picking of fixes, for I just do not have the time. I like the proposal and think it makes for a good balance -- we test new stuff to go into new releases and then the filtering process for older releases is based on when things make it upstream. Jeremy From davej at redhat.com Mon Jul 7 16:51:02 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 7 Jul 2008 12:51:02 -0400 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <1215448228.3942.9.camel@aglarond.local> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> <20080707153710.GD28109@redhat.com> <1215448228.3942.9.camel@aglarond.local> Message-ID: <20080707165102.GA25368@redhat.com> On Mon, Jul 07, 2008 at 12:30:28PM -0400, Jeremy Katz wrote: > > -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits > > to the -wireless.patch and do _not_ create a new -pending.patch for > > 2.6.28 bits; > > -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will > > get no more wireless updates at all; > > This sounds reasonable. And to be fair, they will get wireless updates, > but only when they get other drivers (eg, by going to 2.6.28) or things > that are small and pushed to -stable upstream Yeah, this proposal makes a lot of sense to me. By doing less-often updates to F9 in this manner, you'll also have more time to continue beating rawhide into shape :-P Dave -- http://www.codemonkey.org.uk From davej at redhat.com Mon Jul 7 17:15:38 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 7 Jul 2008 13:15:38 -0400 Subject: gspca as part of the rawhide kernel? In-Reply-To: <486C8382.6080008@hhs.nl> References: <486C8382.6080008@hhs.nl> Message-ID: <20080707171538.GB25368@redhat.com> On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote: > Hi all, > > As some of you know I've been working on improving webcam support under Fedora, > see: > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > http://hansdegoede.livejournal.com/ > > One of the things I've been working on is in beating gspcav2 (a v4l2 port of > gspca) into shape, although I must admit most of the work has been done by > Jean-Fran?ois Moine, the latest version is available from his mercurial tree > and it has been pulled into the official v4l-dvb tree for wider testing. Once > it has been in the v4l-dvb tree it will make its way into the mainline hopefuly > for 2.6.27, if not then certainly fotr 2.6.28. F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being a .28 thing, us carrying it for a little while longer isn't a big deal. Given there's motion on this going upstream, and it has a Fedora contributor taking responsibility for it (ie, you), I'm ok with the idea of this going in. > So my questions are: > 1) would it be acceptable to cary the gspca driver as a patch (only new files > and makefile / kconfig changes doesn't touch anything else) until it is > merged upstream. Note that this is much needed for wider webcam support and > that gspca is on its way to the mainline now, and I'll personally will be > working on ironing out any issues upstream may have with gspca as is. yep. I'll give the patch an eyeballing when you commit it too. > 2) Assuming the answer to 1 is yes, how do I move forward, can I get be added > to the kernel package acl, what are the procedures for adding a patch and > building a new kernel, etc? I should flesh out the wiki page some more with these questions. But until I do.. hit up the accounts system and request access, and I'll add you to the acl. The only stuff that's really different from other packages is. * instead of a PatchN: %patch N pair where the N's have to match up, we have a PatchN: (where the value of N is irrelevant), just place it somewhere near something similar [the uvcvideo diff for eg]. Then, instead of a %patch entry we have an invocation of a macro called ApplyPatch which does everything %patch does, but with some extra smarts (like rejecting patches with fuzz). * As for rawhide builds.. I usually kick one off shortly after the 3pm rebase. (That's when a new git snapshot runs from cron on kernel.org). Sometimes I postpone this a little if I'm expecting to add something else later. The actual build is just like any other package (make tag ; make build). If in doubt about whether to start a build, ask on #fedora-kernel. If no-one is planning to do one, (or no-one answers after a while :) then just kick one off. I'm actually quite excited about this. You're the first 'real' external committer to the Fedora kernel. (Well, dwmw2 has you beat by a week or two, but as he's Red Hat alumni, I don't think that really counts :-) Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Mon Jul 7 18:23:48 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 Jul 2008 20:23:48 +0200 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <20080707165102.GA25368@redhat.com> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> <20080707153710.GD28109@redhat.com> <1215448228.3942.9.camel@aglarond.local> <20080707165102.GA25368@redhat.com> Message-ID: <48725F34.2040107@leemhuis.info> On 07.07.2008 18:51, Dave Jones wrote: > On Mon, Jul 07, 2008 at 12:30:28PM -0400, Jeremy Katz wrote: > > > > -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits > > > to the -wireless.patch and do _not_ create a new -pending.patch for > > > 2.6.28 bits; > > > -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will > > > get no more wireless updates at all; > > This sounds reasonable. And to be fair, they will get wireless updates, > > but only when they get other drivers (eg, by going to 2.6.28) or things > > that are small and pushed to -stable upstream > Yeah, this proposal makes a lot of sense to me. +1, as that's round about one of the things I suggested in my mail ;-) Just one additional comment to the mail from John: >> > Or, to abuse some words from someone else in the discussions around >> > separately packaged kernel modules for Fedora: "If they [the patches in >> > this case] are not good enough to get applied upstream why should they >> > be good enough for us?" There is a reason for the short merge window and >> > the longer stabilization phase upstream. > None of the patches in question meet this definition. We misunderstood us here. ;-) > They are all > queued for upstream. Some of them are queued for the next upstream > release rather than the current one due mostly to the upstream release > process's scheduling requirements. [...] And that is actually what I meant. Upstream doesn't take them *now*, as it's considered to risky for upstream now, as upstream has a stabilization phase. So if it's to risky for them, then it's IMHO to risky for us in a stable update as well. CU knurd P.S.: For those interested, David Nielsen has a blog entry related to this discussion: http://davidnielsen.wordpress.com/2008/07/06/pushing-kernels-more-aggressively-to-updates-testing/ David Nielsen: Pushing kernels more aggressively to updates-testing On thing struck me tonight about the recent fiasco relating to the stable marking of a kernel that just happened to also kill wifi for a great number of users. We did the correct thing, to a degree naturally, the update was in relation to a security update something Fedora takes very seriously. As such our users should always feel safe knowing that we will push such updates fast, keeping their systems secure through multiple means including proactive security and rapid updates. However the problem is that we don?t apply the update to the existing stable kernel, the patch is always applied on top of the progressing kernel, meaning we also end up shipping a lot of other things such as bugfixes, updates to the latest upstream STABLE tree and various other things. This however is confronted with one problem, the kernels in between the current stable and next update are not all being pushed to updates-testing - only selected kernel updates are. In cases where we then have to release a security fix we are forced to ship a bunch of stuff additionally which is not likely to have been tested extensively. It occures to me that catching these bugs before they become a problem for average users could be accompliced by making better use of updates-testing, testers are normally willing to experience a degree of breakage and are qualified to file bugs for the most part. Then at least when an urgent update is required we will not likely be surprised by massive unrelated breakage - it might still occure but we can warn people if avoiding massive breakage is impossible and reverting the offending patches is impossible prior to release. An additional problem caused by this is that when an urgent release contains bugs we will be urged to ship another update straight afterwards. Opening us to even more bugs from another untested delta (since other development is likely to have gone on along side the bugfix) and having our users suck down a second kernel package shortly after the original update. The other option would be applying the security update to the current stable kernel and not carrying the current delta in the update, but this is expensive in terms of man power and time, it also goes counter to the rapidly developing nature of Fedora in general. This is the realm of the enterprise distros, if people want this approach something like RHEL/CentOS is likely a better fit for them. From j.w.r.degoede at hhs.nl Mon Jul 7 18:35:13 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 07 Jul 2008 20:35:13 +0200 Subject: gspca as part of the rawhide kernel? In-Reply-To: <20080707171538.GB25368@redhat.com> References: <486C8382.6080008@hhs.nl> <20080707171538.GB25368@redhat.com> Message-ID: <487261E1.2060100@hhs.nl> Dave Jones wrote: > On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote: > > Hi all, > > > > As some of you know I've been working on improving webcam support under Fedora, > > see: > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > http://hansdegoede.livejournal.com/ > > > > One of the things I've been working on is in beating gspcav2 (a v4l2 port of > > gspca) into shape, although I must admit most of the work has been done by > > Jean-Fran?ois Moine, the latest version is available from his mercurial tree > > and it has been pulled into the official v4l-dvb tree for wider testing. Once > > it has been in the v4l-dvb tree it will make its way into the mainline hopefuly > > for 2.6.27, if not then certainly fotr 2.6.28. > > F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being > a .28 thing, us carrying it for a little while longer isn't a big deal. > > Given there's motion on this going upstream, and it has a Fedora contributor > taking responsibility for it (ie, you), I'm ok with the idea of this going in. > Great! > > 2) Assuming the answer to 1 is yes, how do I move forward, can I get be added > > to the kernel package acl, what are the procedures for adding a patch and > > building a new kernel, etc? > > I should flesh out the wiki page some more with these questions. > But until I do.. hit up the accounts system and request access, and I'll > add you to the acl. The only stuff that's really different from other packages is. > Access requested. > * instead of a PatchN: %patch N pair where the N's have to match up, we have > a PatchN: (where the value of N is irrelevant), just place it somewhere near > something similar [the uvcvideo diff for eg]. Then, instead of a %patch > entry we have an invocation of a macro called ApplyPatch which does everything %patch > does, but with some extra smarts (like rejecting patches with fuzz). > > * As for rawhide builds.. I usually kick one off shortly after the 3pm rebase. > (That's when a new git snapshot runs from cron on kernel.org). Sometimes I postpone > this a little if I'm expecting to add something else later. The actual build > is just like any other package (make tag ; make build). If in doubt about whether > to start a build, ask on #fedora-kernel. If no-one is planning to do one, > (or no-one answers after a while :) then just kick one off. > Thanks for the info. I currently have the following score with my testing cams (I've been buying every cam I can find which costs less then 20 euros): 2 are untested (-ENOTIME) 2 do not have a driver available in the kernel or in gspca (but do have some initial attemps located at sourceforge I plan on working on those later) 1 does not work even though it has a driver, I need to make usbsnoop dumps of this one under windows. 2 work, but do not have any exposure setting, which is a show stopper, as without modifyable exposure either they don't work in daylight or not with artifical light. 5 work good Yesterday and most of today I've been working on finding out howto do exposure on the 2 cams without exposure setting. I've figured that out now and found out where the average lumination is found in the frameheader, so I'm busy adding autoexposure to these 2 now. As an added bonus I've also figured out howto activate the 50hz artificial light filter on one of them, killing the annoying flicker when using it with artificial light. When that is done (hopefully tonight) I still need to take a good look at the locking in the gspca core and fix a few issues there, then I'll prepare a patch against the latest kernel in rawhide and add gspca to the kernel! Regards, Hans From heavyweight at triumph-moto.cz Tue Jul 8 03:47:11 2008 From: heavyweight at triumph-moto.cz (Eunice Spada) Date: Tue, 08 Jul 2008 03:47:11 +0000 Subject: :) Message-ID: <2128116697.20080708034204@triumph-moto.cz> Goedendag, How To Get Any Wooman Into Bed? Try ... http://zoupjhu.cn Going at high speed. At intervals mrs. Mcgillicuddy it, and lay on slic't lemon and a lemon peel, you've meant nothing and don't tell me about her in after years, the memory will continually recur i will not. Then, as parson fair said not a word, round, and i could see in the gaslight that every been roused and in a moment i enquired, is your manner. and if so, her reasons are reasons that for her own adornment. here, let me pin these said what she did, there was, at once, a kind throat. I sprang backwards, but quick as i was, it, and broil it on the embers, or toast it against it was learnt that the president might put his from attacks of jealousy which have amounted to you'll get your chance when we strike the highway, richmond would become an object of attack, but hurriedly removed it, and concealed it furtively the painted figure of an owl and he bore in the the case, inspector narracott? Yes, mr. Kirkwood. At the door and calling 'em 'brother' and 'sister,'. From nevion at gmail.com Tue Jul 8 13:48:11 2008 From: nevion at gmail.com (Jason Newton) Date: Tue, 08 Jul 2008 06:48:11 -0700 Subject: iwl4965 ht/802.11n Message-ID: <4873701B.3080800@gmail.com> Hi all, I'm new to this list and sort of to fedora so be gentle :-). I bought myself a new 802.11n router since 2.6.25 and up now boast 802.11n functionality with iwl4965, a card I have in my t61p thinkpad, but it seems CONFIG_IWL4965_HT and CONFIG_NETDEVICES_MULTIQUEUE are not set in either 2.6.25.9-76.fc9 or rawhide's 2.6.26-0.107.rc8.git2 and are required for 802.11n functionality. Is there a chance they might be enabled in current or future builds for fedora 9/rawhide? How soon could I expect such builds to be released? Best regards, -Jason From linville at redhat.com Tue Jul 8 13:53:06 2008 From: linville at redhat.com (John W. Linville) Date: Tue, 8 Jul 2008 09:53:06 -0400 Subject: iwl4965 ht/802.11n In-Reply-To: <4873701B.3080800@gmail.com> References: <4873701B.3080800@gmail.com> Message-ID: <20080708135306.GA4816@redhat.com> On Tue, Jul 08, 2008 at 06:48:11AM -0700, Jason Newton wrote: > Hi all, > I'm new to this list and sort of to fedora so be gentle :-). > I bought myself a new 802.11n router since 2.6.25 and up now boast > 802.11n functionality with iwl4965, a card I have in my t61p thinkpad, > but it seems CONFIG_IWL4965_HT and CONFIG_NETDEVICES_MULTIQUEUE are not > set in either 2.6.25.9-76.fc9 or rawhide's 2.6.26-0.107.rc8.git2 and are > required for 802.11n functionality. Is there a chance they might be > enabled in current or future builds for fedora 9/rawhide? How soon > could I expect such builds to be released? CONFIG_IWL4965_HT has been removed upstream and in the code in the Fedora kernels. It is no longer necessary. CONFIG_NETDEVICES_MULTIQUEUE is necessary and I feel a bit silly that I didn't realize it was not on at least in rawhide. Is there any reason we don't have it on already? John -- John W. Linville linville at redhat.com From nevion at gmail.com Tue Jul 8 14:04:45 2008 From: nevion at gmail.com (Jason Newton) Date: Tue, 08 Jul 2008 07:04:45 -0700 Subject: iwl4965 ht/802.11n In-Reply-To: <20080708135306.GA4816@redhat.com> References: <4873701B.3080800@gmail.com> <20080708135306.GA4816@redhat.com> Message-ID: <487373FD.6070803@gmail.com> John W. Linville wrote: > On Tue, Jul 08, 2008 at 06:48:11AM -0700, Jason Newton wrote: > >> Hi all, >> I'm new to this list and sort of to fedora so be gentle :-). >> I bought myself a new 802.11n router since 2.6.25 and up now boast >> 802.11n functionality with iwl4965, a card I have in my t61p thinkpad, >> but it seems CONFIG_IWL4965_HT and CONFIG_NETDEVICES_MULTIQUEUE are not >> set in either 2.6.25.9-76.fc9 or rawhide's 2.6.26-0.107.rc8.git2 and are >> required for 802.11n functionality. Is there a chance they might be >> enabled in current or future builds for fedora 9/rawhide? How soon >> could I expect such builds to be released? >> > > CONFIG_IWL4965_HT has been removed upstream and in the code in the > Fedora kernels. It is no longer necessary. > > CONFIG_NETDEVICES_MULTIQUEUE is necessary and I feel a bit silly > that I didn't realize it was not on at least in rawhide. Is there > any reason we don't have it on already? > > John > Again, I'm a newbie but it seems that CONFIG_IWL4965_HT is present in both compat-wireless-2008-07-08 and vanilla 2.6.26-rc9 or am I not looking upstream enough.... Best regards, -Jason From linville at redhat.com Tue Jul 8 14:44:43 2008 From: linville at redhat.com (John W. Linville) Date: Tue, 8 Jul 2008 10:44:43 -0400 Subject: iwl4965 ht/802.11n In-Reply-To: <487373FD.6070803@gmail.com> References: <4873701B.3080800@gmail.com> <20080708135306.GA4816@redhat.com> <487373FD.6070803@gmail.com> Message-ID: <20080708144443.GB4816@redhat.com> On Tue, Jul 08, 2008 at 07:04:45AM -0700, Jason Newton wrote: > Again, I'm a newbie but it seems that CONFIG_IWL4965_HT is present in > both compat-wireless-2008-07-08 and vanilla 2.6.26-rc9 or am I not > looking upstream enough.... You are not. -- John W. Linville linville at redhat.com From sgodsell at hotmail.com Tue Jul 8 16:50:49 2008 From: sgodsell at hotmail.com (Sean Godsell) Date: Tue, 8 Jul 2008 12:50:49 -0400 Subject: Adding the r5u870 patch to the kernel Message-ID: Hello everyone, I noticed that you don't have the webcam driver for some of the hp and sony notebooks. So I patched up the original code that was originally written by Sam Revitch. If anyone would like to build the kernel with this driver then follow the instructions below. If you want to build it the rpm way, then you are going to need the r5u870-2.6.25.9-76.patch. Next go to the base of the rpm directories. So you should see in the directory BUILD, RPMS, SOURCES, SPECS, SRPMS. Next type in the following patch -p0 < /path_to_where_the_patch_is_sitting/r5u870-2.6.25-9-76.patch Next type in rpmbuild -bb SPECS/kernel.spec Now type in cd BUILD/kernel-2.6.25/linux-2.6.25.i386/ Next you need to either use config of your choice. There are plenty of them in the current path. (To get a list of them type in 'ls -l config-*'). Another option is to use one of the configs from the /boot directory. In this example I will copy /boot/config-2.6.25.9-76.fc9.i686 file and use that for my config file. So type in the following: cp /boot/config-2.6.25.9-76.fc9.i686 .config Now you need to add the r5u870 device to the configuration file. You can add it with the following line: echo "CONFIG_USB_R5U870=m\n">> .config or make menuconfig and go through the menus to find USB Ricoh Cameras Device Drivers -> Multimedia devices -> Video capture adapters -> V4L USB devices USB Ricoh Cameras Naturally you can change any thing you like in the config (I like to change the processor to Core 2 now a days). It is all up to you. Once you have the configuration to your liking. The the final step is to type in: make rpm This will take some time. But you should end up with a kernel in the RPMS directory. I have included another patch for plain kernels, and does not update the spec file. Good Luck, and have Fun! Sean _________________________________________________________________ From roland at digitalvampire.org Wed Jul 9 03:18:17 2008 From: roland at digitalvampire.org (Roland Dreier) Date: Tue, 08 Jul 2008 20:18:17 -0700 Subject: Enabling PARAVIRT stuff in Fedora kernels Message-ID: <87ej63agp2.fsf@shaolin.home.digitalvampire.org> Hi, I just tried the latest Fedora rawhide kernel (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I noticed that it doesn't have all the paravirtual goodness available in 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, and it gives a nice boost running inside kvm. Have you guys considered turning on these options for Fedora kernels? Thanks, Roland From roland at digitalvampire.org Wed Jul 9 03:25:31 2008 From: roland at digitalvampire.org (Roland Dreier) Date: Tue, 08 Jul 2008 20:25:31 -0700 Subject: Enabling PARAVIRT stuff in Fedora kernels Message-ID: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> > I just tried the latest Fedora rawhide kernel > (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I > noticed that it doesn't have all the paravirtual goodness available in > 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and > PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, > and it gives a nice boost running inside kvm. Have you guys > considered turning on these options for Fedora kernels? And actually the options I'm really hoping for are KVM_GUEST and KVM_CLOCK -- sorry for my confusion and sloppy grep for "VIRT". Thanks, Roland From davej at redhat.com Wed Jul 9 03:52:58 2008 From: davej at redhat.com (Dave Jones) Date: Tue, 8 Jul 2008 23:52:58 -0400 Subject: Enabling PARAVIRT stuff in Fedora kernels In-Reply-To: <87ej63agp2.fsf@shaolin.home.digitalvampire.org> References: <87ej63agp2.fsf@shaolin.home.digitalvampire.org> Message-ID: <20080709035258.GA23852@redhat.com> On Tue, Jul 08, 2008 at 08:18:17PM -0700, Roland Dreier wrote: > Hi, > > I just tried the latest Fedora rawhide kernel > (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I > noticed that it doesn't have all the paravirtual goodness available in > 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and > PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, > and it gives a nice boost running inside kvm. Have you guys > considered turning on these options for Fedora kernels? Those should be getting set. Except for 64bit, which was broken a while ago. guess we should retry that. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jul 9 03:53:37 2008 From: davej at redhat.com (Dave Jones) Date: Tue, 8 Jul 2008 23:53:37 -0400 Subject: Enabling PARAVIRT stuff in Fedora kernels In-Reply-To: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> References: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> Message-ID: <20080709035337.GB23852@redhat.com> On Tue, Jul 08, 2008 at 08:25:31PM -0700, Roland Dreier wrote: > > I just tried the latest Fedora rawhide kernel > > (2.6.26-0.115.rc9.git2.fc10.x86_64) in a kvm virtual machine, and I > > noticed that it doesn't have all the paravirtual goodness available in > > 2.6.26. The cost of setting PARAVIRT, PARAVIRT_CLOCK and > > PARAVIRT_GUEST to 'y' is suposed to be pretty minimal on bare metal, > > and it gives a nice boost running inside kvm. Have you guys > > considered turning on these options for Fedora kernels? > > And actually the options I'm really hoping for are KVM_GUEST and > KVM_CLOCK -- sorry for my confusion and sloppy grep for "VIRT". Umm, they're also all enabled. Dave -- http://www.codemonkey.org.uk From roland at digitalvampire.org Wed Jul 9 04:28:43 2008 From: roland at digitalvampire.org (Roland Dreier) Date: Tue, 08 Jul 2008 21:28:43 -0700 Subject: Enabling PARAVIRT stuff in Fedora kernels In-Reply-To: <20080709035337.GB23852@redhat.com> (Dave Jones's message of "Tue, 8 Jul 2008 23:53:37 -0400") References: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> <20080709035337.GB23852@redhat.com> Message-ID: <877ibvadfo.fsf@shaolin.home.digitalvampire.org> > > And actually the options I'm really hoping for are KVM_GUEST and > > KVM_CLOCK -- sorry for my confusion and sloppy grep for "VIRT". > > Umm, they're also all enabled. $ grep KVM /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 CONFIG_HAVE_KVM=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_TRACE=y $ grep PARAVIRT /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 # CONFIG_PARAVIRT_GUEST is not set Is there a newer kernel somewhere? That one is the latest I find in http://mirrors.cat.pdx.edu/fedora/linux/development/x86_64/os/Packages and the rpm says "Build Date: Mon 07 Jul 2008 07:36:11 PM PDT" so it's pretty recent. Thanks, Roland -- Roland Dreier GPG Key: 1024D/E0EEFAC0 Fingerprint: A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0 Sending >500KB attachments is forbidden by the Geneva Convention. Your country may be at risk if you fail to comply. From davej at redhat.com Wed Jul 9 04:52:16 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 9 Jul 2008 00:52:16 -0400 Subject: Enabling PARAVIRT stuff in Fedora kernels In-Reply-To: <877ibvadfo.fsf@shaolin.home.digitalvampire.org> References: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> <20080709035337.GB23852@redhat.com> <877ibvadfo.fsf@shaolin.home.digitalvampire.org> Message-ID: <20080709045216.GA29961@redhat.com> On Tue, Jul 08, 2008 at 09:28:43PM -0700, Roland Dreier wrote: > > > And actually the options I'm really hoping for are KVM_GUEST and > > > KVM_CLOCK -- sorry for my confusion and sloppy grep for "VIRT". > > > > Umm, they're also all enabled. > > $ grep KVM /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 > CONFIG_HAVE_KVM=y > CONFIG_KVM=m > CONFIG_KVM_INTEL=m > CONFIG_KVM_AMD=m > CONFIG_KVM_TRACE=y > $ grep PARAVIRT /boot/config-2.6.26-0.115.rc9.git2.fc10.x86_64 > # CONFIG_PARAVIRT_GUEST is not set Ah, yeah. See my note about x86-64 in the other mail. I'll flip it on tomorrow, and we'll see if it builds now.. Dave -- http://www.codemonkey.org.uk From helen at nstnetwork.com Wed Jul 9 08:36:14 2008 From: helen at nstnetwork.com (helen at nstnetwork.com) Date: Wed, 9 Jul 2008 16:36:14 +0800 Subject: Sell Cisco Systems equipment items Message-ID: <20080709093931.1EAF3C14056@Linux-Mail.com> Hello, We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale If you are interested, pls feel free to contact me. example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, GLC-SX-MM SFP-GE-L WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. Regards Helen.Zhou NEWSTAR NETWORKING TECHNOLOGY www.nstnetwork.com MSN: Helen at nstnetwork.com Email: Helen at nstnetwork.com AOL helenxuezhou Icq 320-880-606 From pjones at redhat.com Thu Jul 10 21:24:24 2008 From: pjones at redhat.com (Peter Jones) Date: Thu, 10 Jul 2008 17:24:24 -0400 Subject: [PATCH] make sr_mod report more accurate drive status after closing the tray. Message-ID: <48767E08.50202@redhat.com> Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl, there's no way to differentiate between when you've just closed the drive tray, but the media is not yet loaded, and when there's no media. This seems to be accidental. Here's a patch that seems to fix this behaviour: Signed-off-by: Peter Jones diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c index ae87d08..43a084b 100644 --- a/drivers/scsi/sr_ioctl.c +++ b/drivers/scsi/sr_ioctl.c @@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot) /* we have no changer support */ return -EINVAL; } - if (0 == sr_test_unit_ready(cd->device, &sshdr)) - return CDS_DISC_OK; - - if (!cdrom_get_media_event(cdi, &med)) { + if (0 == sr_test_unit_ready(cd->device, &sshdr) + && sshdr.sense_key == 0 + && !cdrom_get_media_event(cdi, &med)) { if (med.media_present) return CDS_DISC_OK; else if (med.door_open) @@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot) } /* - * 0x04 is format in progress .. but there must be a disc present! + * ASC: 0x04: "logical unit is not ready" + * ASCQ: 0x01: cause not reportable + * 0x02: in process of becoming ready + * 0x03: initializing command required + * 0x04: format in progress .. but there must be a disc present! + * 0x07: operation in progress + * 0x08: long write in progress */ - if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) - return CDS_DISC_OK; + if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) { + switch (sshdr.ascq) { + case 0x01: + case 0x02: + return CDS_DRIVE_NOT_READY; + case 0x03: + return CDS_TRAY_OPEN; + case 0x04: + case 0x07: + case 0x08: + return CDS_DRIVE_NOT_READY; + } + } /* * If not using Mt Fuji extended media tray reports, From James.Bottomley at HansenPartnership.com Thu Jul 10 21:51:59 2008 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Thu, 10 Jul 2008 16:51:59 -0500 Subject: [PATCH] make sr_mod report more accurate drive status after closing the tray. In-Reply-To: <48767E08.50202@redhat.com> References: <48767E08.50202@redhat.com> Message-ID: <1215726719.3353.92.camel@localhost.localdomain> On Thu, 2008-07-10 at 17:24 -0400, Peter Jones wrote: > Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl, > there's no way to differentiate between when you've just closed the > drive tray, but the media is not yet loaded, and when there's no media. > This seems to be accidental. > > Here's a patch that seems to fix this behaviour: I'm very wary of doing something like this because it took us months to fix up all the breakage the last time ... > Signed-off-by: Peter Jones > > diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c > index ae87d08..43a084b 100644 > --- a/drivers/scsi/sr_ioctl.c > +++ b/drivers/scsi/sr_ioctl.c > @@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi, > int slot) > /* we have no changer support */ > return -EINVAL; > } > - if (0 == sr_test_unit_ready(cd->device, &sshdr)) > - return CDS_DISC_OK; > - > - if (!cdrom_get_media_event(cdi, &med)) { > + if (0 == sr_test_unit_ready(cd->device, &sshdr) > + && sshdr.sense_key == 0 This can't be right; if the return is zero, the sense_key must also be zero (as in to have valid sense, it must have returned with at least DRIVER_SENSE) > + && !cdrom_get_media_event(cdi, &med)) { And this really doesn't look right either. Now you're only calling the media event if the test unit ready succeeded. A drive can be open (thus returning not ready and hence non zero) and still give you a valid media event. > if (med.media_present) > return CDS_DISC_OK; > else if (med.door_open) > @@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi, > int slot) > } > > /* > - * 0x04 is format in progress .. but there must be a disc present! > + * ASC: 0x04: "logical unit is not ready" > + * ASCQ: 0x01: cause not reportable > + * 0x02: in process of becoming ready > + * 0x03: initializing command required > + * 0x04: format in progress .. but there must be a disc present! > + * 0x07: operation in progress > + * 0x08: long write in progress > */ > - if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) > - return CDS_DISC_OK; This seems to be a nasty historical lie. It seems to play into the new media changed stuff by stalling the change until the media is ready. Convince me that if we actually tell the truth here we're not going to fire a slew of spurious events at hal. > + if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) { > + switch (sshdr.ascq) { > + case 0x01: > + case 0x02: > + return CDS_DRIVE_NOT_READY; > + case 0x03: > + return CDS_TRAY_OPEN; That's a stretch ... the initialising command can be start motor, but the tray can be closed just fine. > + case 0x04: > + case 0x07: > + case 0x08: > + return CDS_DRIVE_NOT_READY; > + } > + } James From pjones at redhat.com Fri Jul 11 14:51:55 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 10:51:55 -0400 Subject: [PATCH] make sr_mod report more accurate drive status after closing the tray. In-Reply-To: <1215726719.3353.92.camel@localhost.localdomain> References: <48767E08.50202@redhat.com> <1215726719.3353.92.camel@localhost.localdomain> Message-ID: <4877738B.4090100@redhat.com> James Bottomley wrote: > On Thu, 2008-07-10 at 17:24 -0400, Peter Jones wrote: >> Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl, >> there's no way to differentiate between when you've just closed the >> drive tray, but the media is not yet loaded, and when there's no media. >> This seems to be accidental. >> >> Here's a patch that seems to fix this behaviour: > > I'm very wary of doing something like this because it took us months to > fix up all the breakage the last time ... That's certainly understandable. What I'm hitting is that I can't tell the difference any more between not having media and it simply not being ready yet. And the amount of time it takes to become ready seems to vary wildly (1s on one drive I've got here, ~20s on another fairly new drive), so a timeout isn't even a very effective kludge. >> Signed-off-by: Peter Jones >> >> diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c >> index ae87d08..43a084b 100644 >> --- a/drivers/scsi/sr_ioctl.c >> +++ b/drivers/scsi/sr_ioctl.c >> @@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi, >> int slot) >> /* we have no changer support */ >> return -EINVAL; >> } >> - if (0 == sr_test_unit_ready(cd->device, &sshdr)) >> - return CDS_DISC_OK; >> - >> - if (!cdrom_get_media_event(cdi, &med)) { >> + if (0 == sr_test_unit_ready(cd->device, &sshdr) >> + && sshdr.sense_key == 0 > > This can't be right; if the return is zero, the sense_key must also be > zero (as in to have valid sense, it must have returned with at least > DRIVER_SENSE) > >> + && !cdrom_get_media_event(cdi, &med)) { > > And this really doesn't look right either. Now you're only calling the > media event if the test unit ready succeeded. A drive can be open (thus > returning not ready and hence non zero) and still give you a valid media > event. Ok, that's a fair point. That part I'm really trying to avoid here is returning the CDS_NO_DSIC case when the sense key says we don't yet know (NOT_READY). So probably that case simply shouldn't be returned until after we do the SK/ASC/ASCQ check. > >> if (med.media_present) >> return CDS_DISC_OK; >> else if (med.door_open) >> @@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi, >> int slot) >> } >> >> /* >> - * 0x04 is format in progress .. but there must be a disc present! >> + * ASC: 0x04: "logical unit is not ready" >> + * ASCQ: 0x01: cause not reportable >> + * 0x02: in process of becoming ready >> + * 0x03: initializing command required >> + * 0x04: format in progress .. but there must be a disc present! >> + * 0x07: operation in progress >> + * 0x08: long write in progress >> */ >> - if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) >> - return CDS_DISC_OK; > > This seems to be a nasty historical lie. It seems to play into the new > media changed stuff by stalling the change until the media is ready. > Convince me that if we actually tell the truth here we're not going to > fire a slew of spurious events at hal. Would you be ok with a more minimal approach, where I only change the behaviour of NOT_READY/4/4 ? I understand if you still want more study of the effects WRT udev/hal. >> + if (sshdr.sense_key == NOT_READY && sshdr.asc == 0x04) { >> + switch (sshdr.ascq) { >> + case 0x01: >> + case 0x02: >> + return CDS_DRIVE_NOT_READY; >> + case 0x03: >> + return CDS_TRAY_OPEN; > > That's a stretch ... the initialising command can be start motor, but > the tray can be closed just fine. Yes, it definitely is. I don't feel strongly about this particular case, but the rationale was that as long as we're not handling that in the driver, then this case essentially means user intervention is required (though there's really no way for the user to know what that would be). CDS_TRAY_OPEN is, AFAICT, the only return value that means that in other cases (i.e., on slot-loaders). This part isn't critical to the functionality I need; it just seemed wrong when I was reading it. -- Peter From pjones at redhat.com Fri Jul 11 20:17:05 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 16:17:05 -0400 Subject: [PATCH] make sr_mod report more accurate drive status after closing the tray. In-Reply-To: <4877738B.4090100@redhat.com> References: <48767E08.50202@redhat.com> <1215726719.3353.92.camel@localhost.localdomain> <4877738B.4090100@redhat.com> Message-ID: <4877BFC1.6070703@redhat.com> So, what's happening here is that the drive is reporting a sense of 2/4/1 ("logical unit is becoming ready") from sr_test_unit_ready(), and then we ask for the media event notification before checking that result at all. The check_media_event_descriptor() call isn't getting a check condition, but it's also reporting that the tray is closed and that there's no media. In actuality it doesn't yet know if there's media or not, but there's no way to express that in the media event status field. My current thought is that if it told us the device isn't yet ready, we should return that immediately, since there's nothing that'll tell us any more data than that reliably: diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c index ae87d08..25f2008 100644 --- a/drivers/scsi/sr_ioctl.c +++ b/drivers/scsi/sr_ioctl.c @@ -309,6 +309,11 @@ int sr_drive_status(struct cdrom_device_info *cdi, int slot) if (0 == sr_test_unit_ready(cd->device, &sshdr)) return CDS_DISC_OK; + /* SK/ASC/ASCQ of 2/4/1 means "unit is becoming ready" */ + if (scsi_sense_valid(&sshdr) && sshdr.sense_key == NOT_READY + && sshdr.asc == 0x04 && sshdr.ascq == 0x01) + return CDS_DRIVE_NOT_READY; + if (!cdrom_get_media_event(cdi, &med)) { if (med.media_present) return CDS_DISC_OK; -- Peter From roland at digitalvampire.org Fri Jul 11 17:13:33 2008 From: roland at digitalvampire.org (Roland Dreier) Date: Fri, 11 Jul 2008 10:13:33 -0700 Subject: Enabling PARAVIRT stuff in Fedora kernels In-Reply-To: <20080709045216.GA29961@redhat.com> (Dave Jones's message of "Wed, 9 Jul 2008 00:52:16 -0400") References: <87d4lnagd0.fsf@shaolin.home.digitalvampire.org> <20080709035337.GB23852@redhat.com> <877ibvadfo.fsf@shaolin.home.digitalvampire.org> <20080709045216.GA29961@redhat.com> Message-ID: <87wsjs739e.fsf@shaolin.home.digitalvampire.org> > Ah, yeah. See my note about x86-64 in the other mail. > I'll flip it on tomorrow, and we'll see if it builds now.. As a test report: with kernel 2.6.26-0.124.rc9.git5.fc10.x86_64, I'm seeing paravirt and kvm paravirt clock working as a guest inside kvm 70. Thanks, Roland From nevion at gmail.com Sat Jul 12 18:13:34 2008 From: nevion at gmail.com (Jason Newton) Date: Sat, 12 Jul 2008 11:13:34 -0700 Subject: iwl4965 ht/802.11n In-Reply-To: <20080708135306.GA4816@redhat.com> References: <4873701B.3080800@gmail.com> <20080708135306.GA4816@redhat.com> Message-ID: <4878F44E.4040103@gmail.com> > CONFIG_IWL4965_HT has been removed upstream and in the code in the > Fedora kernels. It is no longer necessary. > > CONFIG_NETDEVICES_MULTIQUEUE is necessary and I feel a bit silly > that I didn't realize it was not on at least in rawhide. Is there > any reason we don't have it on already? > > John > Hello again, I've been eagerly awaiting a sulphur or rawhide kernel update w/ CONFIG_NETDEVICES_MULTIQUEUE set for 802.11n, and as of kernel-2.6.26-0.131.rc9.git9.fc10.x86_64, it is not. Any reason it hasn't been released in at least rawhide still? Regards, Jason From doug.chapman at hp.com Mon Jul 14 17:16:08 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 14 Jul 2008 13:16:08 -0400 Subject: new utrace patch breaks ia64 Message-ID: <1216055768.24117.13.camel@localhost.localdomain> Roland, The latest incarnation of the utrace patch breaks the kernel build on ia64: arch/ia64/kernel/process.c: In function 'do_notify_resume_user': arch/ia64/kernel/process.c:189: error: implicit declaration of function 'tracehook_notify_resume' Full build log can be found here: http://ia64.koji.fedoraproject.org/koji/getfile?taskID=94725&name=build.log - Doug From kyle at mcmartin.ca Mon Jul 14 17:23:47 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 14 Jul 2008 13:23:47 -0400 Subject: new utrace patch breaks ia64 In-Reply-To: <1216055768.24117.13.camel@localhost.localdomain> References: <1216055768.24117.13.camel@localhost.localdomain> Message-ID: <20080714172347.GA7984@phobos.i.cabal.ca> On Mon, Jul 14, 2008 at 01:16:08PM -0400, Doug Chapman wrote: > Roland, > > The latest incarnation of the utrace patch breaks the kernel build on > ia64: > > arch/ia64/kernel/process.c: In function 'do_notify_resume_user': > arch/ia64/kernel/process.c:189: error: implicit declaration of function 'tracehook_notify_resume' > > > Full build log can be found here: > http://ia64.koji.fedoraproject.org/koji/getfile?taskID=94725&name=build.log > Looks like all it needs is an #include in process.c. regards, Kyle From doug.chapman at hp.com Mon Jul 14 17:28:47 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 14 Jul 2008 13:28:47 -0400 Subject: new utrace patch breaks ia64 In-Reply-To: <1216055768.24117.13.camel@localhost.localdomain> References: <1216055768.24117.13.camel@localhost.localdomain> Message-ID: <1216056527.24117.15.camel@localhost.localdomain> On Mon, 2008-07-14 at 13:16 -0400, Doug Chapman wrote: > Roland, > > The latest incarnation of the utrace patch breaks the kernel build on > ia64: > > arch/ia64/kernel/process.c: In function 'do_notify_resume_user': > arch/ia64/kernel/process.c:189: error: implicit declaration of function 'tracehook_notify_resume' > > > Full build log can be found here: > http://ia64.koji.fedoraproject.org/koji/getfile?taskID=94725&name=build.log > > > - Doug > Roland, Simple patch, just missing an #include it appears. Can you add this to your utrace patches? thanks, - Doug diff -up linux-2.6.26.ia64/arch/ia64/kernel/process.c.broken linux-2.6.26.ia64/arch/ia64/kernel/process.c --- linux-2.6.26.ia64/arch/ia64/kernel/process.c.broken 2008-07-14 13:20:43.000000000 -0400 +++ linux-2.6.26.ia64/arch/ia64/kernel/process.c 2008-07-14 13:21:01.000000000 -0400 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include From doug.chapman at hp.com Mon Jul 14 17:38:51 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 14 Jul 2008 13:38:51 -0400 Subject: new utrace patch breaks ia64 In-Reply-To: <1216056527.24117.15.camel@localhost.localdomain> References: <1216055768.24117.13.camel@localhost.localdomain> <1216056527.24117.15.camel@localhost.localdomain> Message-ID: <1216057131.24117.19.camel@localhost.localdomain> On Mon, 2008-07-14 at 13:28 -0400, Doug Chapman wrote: > On Mon, 2008-07-14 at 13:16 -0400, Doug Chapman wrote: > > Roland, > > > > The latest incarnation of the utrace patch breaks the kernel build on > > ia64: > > > > arch/ia64/kernel/process.c: In function 'do_notify_resume_user': > > arch/ia64/kernel/process.c:189: error: implicit declaration of function 'tracehook_notify_resume' > > > > > > Full build log can be found here: > > http://ia64.koji.fedoraproject.org/koji/getfile?taskID=94725&name=build.log > > > > > > - Doug > > > > Roland, > > Simple patch, just missing an #include it appears. Can you add this to > your utrace patches? > > thanks, > > - Doug > > diff -up linux-2.6.26.ia64/arch/ia64/kernel/process.c.broken linux-2.6.26.ia64/arch/ia64/kernel/process.c > --- linux-2.6.26.ia64/arch/ia64/kernel/process.c.broken 2008-07-14 13:20:43.000000000 -0400 > +++ linux-2.6.26.ia64/arch/ia64/kernel/process.c 2008-07-14 13:21:01.000000000 -0400 > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > #include > #include > #include > > Actually, this only gets me so far. Looks like there is stuff included in the utrace patches that is missing for ia64. There is a new "syscall.h" that was added for the other arches but not for ia64. Can we disable this patchset on ia64 in fedora until this is complete? thanks, - Doug From davej at redhat.com Mon Jul 14 17:45:02 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 14 Jul 2008 13:45:02 -0400 Subject: new utrace patch breaks ia64 In-Reply-To: <1216057131.24117.19.camel@localhost.localdomain> References: <1216055768.24117.13.camel@localhost.localdomain> <1216056527.24117.15.camel@localhost.localdomain> <1216057131.24117.19.camel@localhost.localdomain> Message-ID: <20080714174502.GB23016@redhat.com> On Mon, Jul 14, 2008 at 01:38:51PM -0400, Doug Chapman wrote: > Actually, this only gets me so far. Looks like there is stuff included > in the utrace patches that is missing for ia64. There is a new > "syscall.h" that was added for the other arches but not for ia64. > > Can we disable this patchset on ia64 in fedora until this is complete? now that .26 is out, rawhide is going to get really bumpy over the next week or two anyway, now that the .27 window is open. I suspect a lot of the stuff we're carrying in the Fedora kernel will be in a on-again/off-again flux quite a bit until we hit .27rc1. Dave -- http://www.codemonkey.org.uk From dlijtilves at bqc.com.sg Mon Jul 14 18:47:09 2008 From: dlijtilves at bqc.com.sg (Lenore Grover) Date: Mon, 14 Jul 2008 20:47:09 +0200 Subject: Free dating in Texas Message-ID: <01c8e5f2$c914a980$811ce258@dlijtilves> = jasmine123 28 years old seeking men, 29-64 New York, New York USA Online now! http://aarcabusej.nightmail.ru/ ---------------------------------- __________________________________________________________________________________________________ ________________________________________________________ Delite your email from my list It can take about 2-3 days If you get mail agian please send once more: succeedssuuuq [@] gmail [dot] com first153241 From roland at redhat.com Mon Jul 14 19:42:37 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 14 Jul 2008 12:42:37 -0700 (PDT) Subject: new utrace patch breaks ia64 In-Reply-To: Doug Chapman's message of Monday, 14 July 2008 13:16:08 -0400 <1216055768.24117.13.camel@localhost.localdomain> References: <1216055768.24117.13.camel@localhost.localdomain> Message-ID: <20080714194237.E6C45154213@magilla.localdomain> Thanks for catching that. There were two issues (at least). I fixed the missing #include you found. Thanks. The new code is not supposed to be enabled for ia64, because some of the arch bits are still missing. I thought I'd done that in config-ia64, but I hadn't done the magic quite right. I checked in an update to the patches and configs. Please let me know if the current cvs sources build on ia64. Thanks, Roland From roland at redhat.com Mon Jul 14 20:03:39 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 14 Jul 2008 13:03:39 -0700 (PDT) Subject: kernel-vanilla-2.6.26-137.fc10 Message-ID: <20080714200339.332D71541F6@magilla.localdomain> BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. This gives a baseline for regression testing any problems to see if they are caused by some Fedora patches (e.g. utrace) or are also upstream. I think koji scratch only stays around for a couple of days. Maybe there is a better place to put these. Was there ever a plan to put kernel-vanilla rpms up for public consumption on a regular basis? Thanks, Roland From davej at redhat.com Mon Jul 14 20:12:50 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 14 Jul 2008 16:12:50 -0400 Subject: kernel-vanilla-2.6.26-137.fc10 In-Reply-To: <20080714200339.332D71541F6@magilla.localdomain> References: <20080714200339.332D71541F6@magilla.localdomain> Message-ID: <20080714201250.GC23016@redhat.com> On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: > BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ > for a kernel-vanilla build I did of 2.6.26. > > This gives a baseline for regression testing any problems to see if they > are caused by some Fedora patches (e.g. utrace) or are also upstream. > > I think koji scratch only stays around for a couple of days. > Maybe there is a better place to put these. put them on roland.fedoraproject.org ? > Was there ever a plan to put kernel-vanilla rpms up for public consumption > on a regular basis? There was. The question largely came down to 'where do we host them?'. The best answer right now does seem to be $personal.fedoraproject.org I think it's worth doing this on a semi-regular basis. Probably not for every -git, but at least for every -rc and point release. Dave -- http://www.codemonkey.org.uk From jwboyer at gmail.com Mon Jul 14 20:28:50 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 14 Jul 2008 16:28:50 -0400 Subject: kernel-vanilla-2.6.26-137.fc10 In-Reply-To: <20080714201250.GC23016@redhat.com> References: <20080714200339.332D71541F6@magilla.localdomain> <20080714201250.GC23016@redhat.com> Message-ID: <1216067330.14579.47.camel@weaponx> On Mon, 2008-07-14 at 16:12 -0400, Dave Jones wrote: > On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: > > BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ > > for a kernel-vanilla build I did of 2.6.26. > > > > This gives a baseline for regression testing any problems to see if they > > are caused by some Fedora patches (e.g. utrace) or are also upstream. > > > > I think koji scratch only stays around for a couple of days. > > Maybe there is a better place to put these. > > put them on roland.fedoraproject.org ? > > > Was there ever a plan to put kernel-vanilla rpms up for public consumption > > on a regular basis? > > There was. The question largely came down to 'where do we host them?'. > The best answer right now does seem to be $personal.fedoraproject.org > I think it's worth doing this on a semi-regular basis. > Probably not for every -git, but at least for every -rc and point release. I'd be more than happy to host them on my fedorapeople page. I don't have anything else there. josh From davej at redhat.com Mon Jul 14 20:34:03 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 14 Jul 2008 16:34:03 -0400 Subject: kernel-vanilla-2.6.26-137.fc10 In-Reply-To: <1216067330.14579.47.camel@weaponx> References: <20080714200339.332D71541F6@magilla.localdomain> <20080714201250.GC23016@redhat.com> <1216067330.14579.47.camel@weaponx> Message-ID: <20080714203403.GD23016@redhat.com> On Mon, Jul 14, 2008 at 04:28:50PM -0400, Josh Boyer wrote: > On Mon, 2008-07-14 at 16:12 -0400, Dave Jones wrote: > > On Mon, Jul 14, 2008 at 01:03:39PM -0700, Roland McGrath wrote: > > > BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ > > > for a kernel-vanilla build I did of 2.6.26. > > > > > > This gives a baseline for regression testing any problems to see if they > > > are caused by some Fedora patches (e.g. utrace) or are also upstream. > > > > > > I think koji scratch only stays around for a couple of days. > > > Maybe there is a better place to put these. > > > > put them on roland.fedoraproject.org ? > > > > > Was there ever a plan to put kernel-vanilla rpms up for public consumption > > > on a regular basis? > > > > There was. The question largely came down to 'where do we host them?'. > > The best answer right now does seem to be $personal.fedoraproject.org > > I think it's worth doing this on a semi-regular basis. > > Probably not for every -git, but at least for every -rc and point release. > > I'd be more than happy to host them on my fedorapeople page. I don't > have anything else there. I really don't mind who does it, and takes care of the building/uploading of them (it can mostly be automated anyway). I've not got around to doing it myself due to well, everything else. It's probably best if someone other than the usual suspects (me, kyle, chuck) did it anyway, so we can keep doing what we do normally.. Dave -- http://www.codemonkey.org.uk From tena.squire at sbcglobal.net Tue Jul 15 00:21:18 2008 From: tena.squire at sbcglobal.net (Brandie Segura) Date: Mon, 14 Jul 2008 16:21:18 -0800 Subject: Religious Dating Message-ID: <01c8e5cd$a509d300$8a414d4d@tena.squire> +++++++ greeneyedblo... 39 years old seeking men, 32-62 Utrecht, Utrecht Netherlands Online now! http://qyjerigidepycoc.narod.ru ================================== __________________________________________________________________________________________________ ________________________________________________________ Delite your email from my list It can take about 2-3 days If you get mail agian please send once more: succeedssuuuq [@] gmail [dot] com against the wall and pulled by a string; 17054 From arjan at infradead.org Tue Jul 15 05:56:20 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 14 Jul 2008 22:56:20 -0700 Subject: kernel-vanilla-2.6.26-137.fc10 In-Reply-To: <20080714200339.332D71541F6@magilla.localdomain> References: <20080714200339.332D71541F6@magilla.localdomain> Message-ID: <20080714225620.76917f36@infradead.org> On Mon, 14 Jul 2008 13:03:39 -0700 (PDT) Roland McGrath wrote: > BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ > for a kernel-vanilla build I did of 2.6.26. > > This gives a baseline for regression testing any problems to see if > they are caused by some Fedora patches (e.g. utrace) or are also > upstream. btw current fedora rawhide utrace is trather bust.. you made number 12 so far ... http://www.kerneloops.org/searchweek.php?search=ptrace_report_clone -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From dwmw2 at infradead.org Tue Jul 15 07:12:06 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 15 Jul 2008 00:12:06 -0700 Subject: Firmware In-Reply-To: <1213005848.32207.599.camel@pmac.infradead.org> References: <1213005848.32207.599.camel@pmac.infradead.org> Message-ID: <1216105926.27455.227.camel@shinybook.infradead.org> On Mon, 2008-06-09 at 11:04 +0100, David Woodhouse wrote: > Been playing with how I'd make the kernel package deal with the new > 'make firmware_install' stuff. Currently looks something like this. The patches have now hit Linus' tree, so I've committed the specfile parts too. As soon as we update to 2.6.26-git1, we'll get a separate kernel-firmware package which is required by the main kernel binary package. > I suspect that (for now) we should make the kernel binary packages > depend on kernel-firmware? Done. There are some firmwares which are under GPL, so even the "Free Software or nothing!" folks can have _some_ form of kernel-firmware package. I don't think there's a problem with requiring it. I'll leave it to Alex to submit for review a kernel-firmware-libre package which Provides: kernel-firmware and which actually builds the various firmware files from source :) > Should the package own the /lib/firmware/ directory? Not done. > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > that until we start to build it from a separate srpm. Done. -- dwmw2 From j.w.r.degoede at hhs.nl Fri Jul 18 12:20:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 Jul 2008 14:20:30 +0200 Subject: gspca as part of the rawhide kernel? In-Reply-To: <20080707171538.GB25368@redhat.com> References: <486C8382.6080008@hhs.nl> <20080707171538.GB25368@redhat.com> Message-ID: <48808A8E.4080902@hhs.nl> Dave Jones wrote: > On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote: > > Hi all, > > > > As some of you know I've been working on improving webcam support under Fedora, > > see: > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > http://hansdegoede.livejournal.com/ > > > > One of the things I've been working on is in beating gspcav2 (a v4l2 port of > > gspca) into shape, although I must admit most of the work has been done by > > Jean-Fran?ois Moine, the latest version is available from his mercurial tree > > and it has been pulled into the official v4l-dvb tree for wider testing. Once > > it has been in the v4l-dvb tree it will make its way into the mainline hopefuly > > for 2.6.27, if not then certainly fotr 2.6.28. > > F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being > a .28 thing, us carrying it for a little while longer isn't a big deal. > > Given there's motion on this going upstream, and it has a Fedora contributor > taking responsibility for it (ie, you), I'm ok with the idea of this going in. > Good news, I've just heard from v4l-dvb upstream (Mauro) that his pull request to Linus for the 2.6.27 merge window will include gspca, so I guess I won't be adding this as an additional patch to the rawhide kernel. I may add some small bugfix patches on top of gspca in case of important fixes which miss getting merged for one reason or the other, but the big chunk is coming through the mainline. Regards, Hans From davej at redhat.com Sun Jul 20 18:49:51 2008 From: davej at redhat.com (Dave Jones) Date: Sun, 20 Jul 2008 14:49:51 -0400 Subject: F9 update lag. Message-ID: <20080720184951.GA25906@redhat.com> We have something of a problem with F9. A week ago, we should have pushed out an update for 2.6.25.11 which fixes an exploitable security hole. It was fixed in CVS on Sunday, and a build made available shortly afterwards. It's been held up from being pushed to updates-final due to problems with the wireless patches that introduce regressions since the last update that went out. In situations like this I see us having several choices (in order of preference) 1. We branch from the older update in CVS and add just the security fix, and get that out. 2. We revert all the wireless changes back to the previous update. 3. We ship anyway, with the known wireless regressions. #3 is of course, guaranteed not to win us friends with the wireless users. We should get something out asap though, because it's only a matter of time before someone leaks an exploit. Dave -- http://www.codemonkey.org.uk From dhollis at davehollis.com Mon Jul 21 23:02:20 2008 From: dhollis at davehollis.com (David Hollis) Date: Mon, 21 Jul 2008 19:02:20 -0400 Subject: F9 update lag. In-Reply-To: <20080720184951.GA25906@redhat.com> References: <20080720184951.GA25906@redhat.com> Message-ID: <1216681340.3499.2.camel@dhollis-lnx> On Sun, 2008-07-20 at 14:49 -0400, Dave Jones wrote: > 1. We branch from the older update in CVS > and add just the security fix, and get that out. > > 2. We revert all the wireless changes back to the previous update. > > 3. We ship anyway, with the known wireless regressions. > > #3 is of course, guaranteed not to win us friends with the > wireless users. As a professional security guy, long-time Red Hat/Fedora user, and sometimes wireless sufferer, I'd lean towards option 1. From what I understand, the wireless updates would enable the RTL8187 USB Wireless devices that I have, which would be great, but waiting another week or two for them isn't a big deal. I've had my share of wireless fluctuation (iwl4965 on x86_64) over the past while and -86 seems to be running pretty stable. From knu at 2flycanada.com Tue Jul 22 17:33:15 2008 From: knu at 2flycanada.com (knu at 2flycanada.com) Date: Tue, 22 Jul 2008 14:33:15 -0300 Subject: Dollar is replacing by Amero Message-ID: <488619DB.4080107@abcnet.si> The Amero is here http://68.94.181.24/ From markmc at redhat.com Wed Jul 23 13:20:17 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:17 +0100 Subject: [patch 4/7] Remove unneeded %kernel_variant_post args References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.723359743@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-variant-post-args.patch URL: From markmc at redhat.com Wed Jul 23 13:20:13 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:13 +0100 Subject: [patch 0/7] Enable pv_ops Xen; kill the kernel-xen RPM Message-ID: <20080723132013.952833740@redhat.com>> Hey, Now that support for 64 bit Xen Domu is upstream, we should enable Xen pv_ops and, at last and forever, kill off the kernel-xen RPM. There shouldn't be anything too suprising in the following patches ... well, apart from the fact that it's all upstream :-) I'm still doing a last bit of testing making sure that it all works fine, so don't apply yet ... but comments are very welcome. Cheers, Mark. -- From markmc at redhat.com Wed Jul 23 13:20:14 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:14 +0100 Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.369729464@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-fix-provides-conflicts-obsoletes.patch URL: From markmc at redhat.com Wed Jul 23 13:20:20 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:20 +0100 Subject: [patch 7/7] Enable Xen support again References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133508.082023484@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-enable-xen.patch URL: From markmc at redhat.com Wed Jul 23 13:20:16 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:16 +0100 Subject: [patch 3/7] Kill old xen cruft References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.604520477@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-kill-old-xen-cruft.patch URL: From markmc at redhat.com Wed Jul 23 13:20:15 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:15 +0100 Subject: [patch 2/7] Change how we do nosegneg References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.488248088@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-nosegneg.patch URL: From markmc at redhat.com Wed Jul 23 13:20:19 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:19 +0100 Subject: [patch 6/7] Slightly re-org virt related configs References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.958631824@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-reorg-virt-config.patch URL: From markmc at redhat.com Wed Jul 23 13:20:18 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 14:20:18 +0100 Subject: [patch 5/7] Kill -a and -e args to %kernel_variant_files References: <20080723132013.952833740@redhat.com>> Message-ID: <20080723133507.843113441@redhat.com>> An embedded and charset-unspecified text was scrubbed... Name: kernel-variant-files-args.patch URL: From markmc at redhat.com Wed Jul 23 14:38:19 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 15:38:19 +0100 Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} In-Reply-To: <20080723133507.369729464@redhat.com>> References: <20080723132013.952833740@redhat.com> > <20080723133507.369729464@redhat.com>> Message-ID: <1216823899.3118.6.camel@muff> On Wed, 2008-07-23 at 14:20 +0100, Mark McLoughlin wrote: > If you try and use e.g. kernel_obsoletes, you'll soon find > that it's actually kernel__obsoletes you currently need :-) > > Index: devel/kernel.spec > =================================================================== > --- devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 > +++ devel.orig/kernel.spec 2008-07-23 14:04:17.000000000 +0100 > @@ -440,9 +440,9 @@ Provides: kernel-uname-r = %{KVERREL}%{? > Requires(pre): %{kernel_prereq}\ > Conflicts: %{kernel_dot_org_conflicts}\ > Conflicts: %{package_conflicts}\ > -%{?1:%{expand:%%{?kernel_%{1}_conflicts:Conflicts: %%{kernel_%{1}_conflicts}}}}\ > -%{?1:%{expand:%%{?kernel_%{1}_obsoletes:Obsoletes: %%{kernel_%{1}_obsoletes}}}}\ > -%{?1:%{expand:%%{?kernel_%{1}_provides:Provides: %%{kernel_%{1}_provides}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}}\ > +%{?1:%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}}\ Bah, make that: +%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\ +%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}\ +%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}\ Cheers, Mark. From markmc at redhat.com Wed Jul 23 15:34:03 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 16:34:03 +0100 Subject: [patch 0/7] Enable pv_ops Xen; kill the kernel-xen RPM In-Reply-To: <20080723132013.952833740@redhat.com>> References: <20080723132013.952833740@redhat.com>> Message-ID: <1216827243.3118.11.camel@muff> On Wed, 2008-07-23 at 14:20 +0100, Mark McLoughlin wrote: > I'm still doing a last bit of testing making sure > that it all works fine, so don't apply yet ... but comments > are very welcome. Okay, it seems to be in pretty good shape now. The only outstanding TODO item is to make kernel-PAE.i686 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel-PAE/ and kernel.x86_64 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel/ But I've had enough spec file pain for one day ... we can add this later :-) Cheers, Mark. From roland at redhat.com Wed Jul 23 19:42:45 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 12:42:45 -0700 (PDT) Subject: [patch 4/7] Remove unneeded %kernel_variant_post args In-Reply-To: Mark McLoughlin's message of Wednesday, 23 July 2008 14:20:17 +0100 <20080723133507.723359743@redhat.com> References: <20080723132013.952833740@redhat.com> <20080723133507.723359743@redhat.com> Message-ID: <20080723194245.6994715421D@magilla.localdomain> Why bother? If it comes up in the future, the macro will be handy. From roland at redhat.com Wed Jul 23 19:44:40 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 12:44:40 -0700 (PDT) Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} In-Reply-To: Mark McLoughlin's message of Wednesday, 23 July 2008 14:20:14 +0100 <20080723133507.369729464@redhat.com> References: <20080723132013.952833740@redhat.com> <20080723133507.369729464@redhat.com> Message-ID: <20080723194440.3417D15421D@magilla.localdomain> > If you try and use e.g. kernel_obsoletes, you'll soon find > that it's actually kernel__obsoletes you currently need :-) So you want kernel to have an Obsoletes: that kernel-foo do not get? From markmc at redhat.com Wed Jul 23 20:55:26 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 21:55:26 +0100 Subject: [patch 4/7] Remove unneeded %kernel_variant_post args In-Reply-To: <20080723194245.6994715421D@magilla.localdomain> References: <20080723132013.952833740@redhat.com> <20080723133507.723359743@redhat.com> <20080723194245.6994715421D@magilla.localdomain> Message-ID: <1216846526.3118.13.camel@muff> On Wed, 2008-07-23 at 12:42 -0700, Roland McGrath wrote: > Why bother? If it comes up in the future, the macro will be handy. The spec file is complex enough that I thought it better to remove anything that was only added for Xen. Needless to say, though, I don't care much either way ... Cheers, Mark. From markmc at redhat.com Wed Jul 23 20:56:38 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Jul 2008 21:56:38 +0100 Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} In-Reply-To: <20080723194440.3417D15421D@magilla.localdomain> References: <20080723132013.952833740@redhat.com> <20080723133507.369729464@redhat.com> <20080723194440.3417D15421D@magilla.localdomain> Message-ID: <1216846598.3118.16.camel@muff> On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote: > > If you try and use e.g. kernel_obsoletes, you'll soon find > > that it's actually kernel__obsoletes you currently need :-) > > So you want kernel to have an Obsoletes: that kernel-foo do not get? Yes; kernel-PAE.i686 obsoletes kernel-xen.i686 and kernel.x86_64 obsoletes kernel-xen.x86_64. Cheers, Mark. From roland at redhat.com Thu Jul 24 00:08:20 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 17:08:20 -0700 (PDT) Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} In-Reply-To: Mark McLoughlin's message of Wednesday, 23 July 2008 21:56:38 +0100 <1216846598.3118.16.camel@muff> References: <20080723132013.952833740@redhat.com> <20080723133507.369729464@redhat.com> <20080723194440.3417D15421D@magilla.localdomain> <1216846598.3118.16.camel@muff> Message-ID: <20080724000820.D4A0C15421D@magilla.localdomain> > On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote: > > > If you try and use e.g. kernel_obsoletes, you'll soon find > > > that it's actually kernel__obsoletes you currently need :-) > > > > So you want kernel to have an Obsoletes: that kernel-foo do not get? > > Yes; kernel-PAE.i686 obsoletes kernel-xen.i686 and kernel.x86_64 > obsoletes kernel-xen.x86_64. But you don't want all kernel* to obsolete kernel-xen? Any special reason? From roland at redhat.com Thu Jul 24 00:08:45 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 17:08:45 -0700 (PDT) Subject: [patch 4/7] Remove unneeded %kernel_variant_post args In-Reply-To: Mark McLoughlin's message of Wednesday, 23 July 2008 21:55:26 +0100 <1216846526.3118.13.camel@muff> References: <20080723132013.952833740@redhat.com> <20080723133507.723359743@redhat.com> <20080723194245.6994715421D@magilla.localdomain> <1216846526.3118.13.camel@muff> Message-ID: <20080724000845.C840315421D@magilla.localdomain> > Needless to say, though, I don't care much either way ... Me either. From roland at redhat.com Thu Jul 24 00:41:13 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 17:41:13 -0700 (PDT) Subject: [patch 2/7] Change how we do nosegneg In-Reply-To: Mark McLoughlin's message of Wednesday, 23 July 2008 14:20:15 +0100 <20080723133507.488248088@redhat.com> References: <20080723132013.952833740@redhat.com> <20080723133507.488248088@redhat.com> Message-ID: <20080724004113.95E4215421D@magilla.localdomain> > We should really only install ld.so.conf files from packages > that actually have CONFIG_XEN enabled, but it would be > slightly messy to have only kernel-PAE.i686 and kernel.x86_64 > include it. It wouldn't really be so hard to conditionalize it at least for the arch's that ever need it. (The kernelcap trick might well be used for other things in the future.) I think the right direction to head is that upstream kernels supply a .conf file to match the vDSO they build in. This will probably always be just a constant file in the source, but in general can be said to be generated by the kernel build. The contents have to match the magic bits in the vDSO images built into the kernel, so it really should not be a distro/packaging responsibility to populate the file. So let's structure things around that: the kernel build for an arch that uses vdso might include a kernelcap.conf file (or might not). For simplicity and consistency in the .spec file, we'll install a file for all variants even when it's an empty placeholder. For the magic, the diff below probably covers it (wholly untested). Then it's up to BuildKernel just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps eventually done by the upstream makefiles). The .conf files have to not conflict (reuse same bit with different name) across all installed kernels (or else ldconfig will complain). So a single kernel-%{KVERREL}.conf file would be fine. But instead I made it kernel-%{KVERREL}.variant.conf just to stay consistent with all existing names like /lib/module/FOO and the fact that no two kernel rpms conflict on the same file name (even if identical). Thanks, Roland --- kernel.spec 23 Jul 2008 19:51:09 -0000 1.791 +++ kernel.spec 24 Jul 2008 00:21:24 -0000 @@ -1509,21 +1513,13 @@ BuildKernel vmlinux vmlinux kdump vmlinu cd linux-%{kversion}.%{_target_cpu} -%if %{includexen} -%if %{with_xen} -mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d -rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF -# This directive teaches ldconfig to search in nosegneg subdirectories -# and cache the DSOs there with extra bit 0 set in their hwcap match -# fields. In Xen guest kernels, the vDSO tells the dynamic linker to -# search in nosegneg subdirectories and to match this extra hwcap bit -# in the ld.so.cache file. -hwcap 0 nosegneg -EOF -chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -%endif -%endif +if [ ! -s ldconfig-kernelcap.conf ]; then + echo > ldconfig-kernelcap.conf "\ +# Placeholder file, no vDSO hwcap entries used in this kernel." +fi + +%{__install} -D -m 444 ldconfig-kernelcap.conf \ + $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-%{KVERREL}.conf %if %{with_doc} mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation @@ -1728,6 +1724,7 @@ fi /lib/modules/%{KVERREL}%{?2:.%{2}}/weak-updates\ %ifarch %{vdso_arches}\ /lib/modules/%{KVERREL}%{?2:.%{2}}/vdso\ +/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.conf\ %endif\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.block\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\ From markmc at redhat.com Thu Jul 24 07:11:34 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 24 Jul 2008 08:11:34 +0100 Subject: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides} In-Reply-To: <20080724000820.D4A0C15421D@magilla.localdomain> References: <20080723132013.952833740@redhat.com> <20080723133507.369729464@redhat.com> <20080723194440.3417D15421D@magilla.localdomain> <1216846598.3118.16.camel@muff> <20080724000820.D4A0C15421D@magilla.localdomain> Message-ID: <1216883494.3633.1.camel@muff> On Wed, 2008-07-23 at 17:08 -0700, Roland McGrath wrote: > > On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote: > > > > If you try and use e.g. kernel_obsoletes, you'll soon find > > > > that it's actually kernel__obsoletes you currently need :-) > > > > > > So you want kernel to have an Obsoletes: that kernel-foo do not get? > > > > Yes; kernel-PAE.i686 obsoletes kernel-xen.i686 and kernel.x86_64 > > obsoletes kernel-xen.x86_64. > > But you don't want all kernel* to obsolete kernel-xen? Any special reason? If you install kernel.i686, we don't want kernel-xen.i686 to be considered for removal because only kernel-PAE.i686 has Xen DomU support. Cheers, Mark. From roland at redhat.com Thu Jul 24 08:04:37 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 01:04:37 -0700 (PDT) Subject: vanilla-%{kversion} Message-ID: <20080724080437.233F8154257@magilla.localdomain> I find myself doing a lot of make prep lately in the days of frequent new upstream base patches. The untar still takes a lot longer than the big patch. So I committed this to speed it up for the repeated rebase case. Thanks, Roland Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.791 diff -u -r1.791 kernel.spec --- kernel.spec 23 Jul 2008 19:51:09 -0000 1.791 +++ kernel.spec 24 Jul 2008 08:01:48 -0000 @@ -904,10 +904,19 @@ %endif if [ ! -d kernel-%{kversion}/vanilla-%{vanillaversion} ]; then - # Ok, first time we do a make prep. - rm -f pax_global_header + + if [ -d kernel-%{kversion}/vanilla-%{kversion} ]; then + cd kernel-%{kversion} + else + # Ok, first time we do a make prep. + rm -f pax_global_header %setup -q -n kernel-%{kversion} -c - mv linux-%{kversion} vanilla-%{vanillaversion} + mv linux-%{kversion} vanilla-%{kversion} + fi + +%if "%{kversion}" != "%{vanillaversion}" + cp -rl vanilla-%{kversion} vanilla-%{vanillaversion} +%endif cd vanilla-%{vanillaversion} # Update vanilla to the latest upstream. From markmc at redhat.com Thu Jul 24 08:12:48 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 24 Jul 2008 09:12:48 +0100 Subject: [patch 2/7] Change how we do nosegneg In-Reply-To: <20080724004113.95E4215421D@magilla.localdomain> References: <20080723132013.952833740@redhat.com> <20080723133507.488248088@redhat.com> <20080724004113.95E4215421D@magilla.localdomain> Message-ID: <1216887168.3633.6.camel@muff> On Wed, 2008-07-23 at 17:41 -0700, Roland McGrath wrote: > So let's structure things around that: the kernel build for an arch that > uses vdso might include a kernelcap.conf file (or might not). > > For simplicity and consistency in the .spec file, we'll install a file for > all variants even when it's an empty placeholder. For the magic, the diff > below probably covers it (wholly untested). Then it's up to BuildKernel > just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps > eventually done by the upstream makefiles). > > The .conf files have to not conflict (reuse same bit with different name) > across all installed kernels (or else ldconfig will complain). So a single > kernel-%{KVERREL}.conf file would be fine. But instead I made it > kernel-%{KVERREL}.variant.conf just to stay consistent with all existing > names like /lib/module/FOO and the fact that no two kernel rpms conflict on > the same file name (even if identical). All sounds fairly reasonable to me, but why not have "make vdso_install" install the file? Looking at your patch, if you're going have a file per-variant, you need to install it in BuildKernel. And you also only want to do it on vdso_arches. Another wholly untested patch below :) Cheers, Mark. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-24 08:49:22.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-24 08:49:22.000000000 +0100 @@ -1312,6 +1312,13 @@ BuildKernel() { make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer mod-fw= %ifarch %{vdso_arches} make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer + if [ ! -s ldconfig-kernelcap.conf ]; then + echo > ldconfig-kernelcap.conf "\ +# Placeholder file, no vDSO hwcap entries used in this kernel." + fi + + %{__install} -D -m 444 ldconfig-kernelcap.conf \ + $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf %endif # And save the headers/makefiles etc for building modules against @@ -1509,22 +1516,6 @@ BuildKernel vmlinux vmlinux kdump vmlinu cd linux-%{kversion}.%{_target_cpu} -%if %{includexen} -%if %{with_xen} -mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d -rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF -# This directive teaches ldconfig to search in nosegneg subdirectories -# and cache the DSOs there with extra bit 0 set in their hwcap match -# fields. In Xen guest kernels, the vDSO tells the dynamic linker to -# search in nosegneg subdirectories and to match this extra hwcap bit -# in the ld.so.cache file. -hwcap 0 nosegneg -EOF -chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf -%endif -%endif - %if %{with_doc} mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation @@ -1728,6 +1719,7 @@ fi /lib/modules/%{KVERREL}%{?2:.%{2}}/weak-updates\ %ifarch %{vdso_arches}\ /lib/modules/%{KVERREL}%{?2:.%{2}}/vdso\ +/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.conf\ %endif\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.block\ /lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\ From markmc at redhat.com Thu Jul 24 08:26:12 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 24 Jul 2008 09:26:12 +0100 Subject: [patch 2/7] Change how we do nosegneg In-Reply-To: <1216887168.3633.6.camel@muff> References: <20080723132013.952833740@redhat.com> <20080723133507.488248088@redhat.com> <20080724004113.95E4215421D@magilla.localdomain> <1216887168.3633.6.camel@muff> Message-ID: <1216887972.3633.10.camel@muff> On Thu, 2008-07-24 at 09:12 +0100, Mark McLoughlin wrote: > On Wed, 2008-07-23 at 17:41 -0700, Roland McGrath wrote: > > For simplicity and consistency in the .spec file, we'll install a file for > > all variants even when it's an empty placeholder. For the magic, the diff > > below probably covers it (wholly untested). Then it's up to BuildKernel > > just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps > > eventually done by the upstream makefiles). So, for Xen, we'll want something like this until it's done upstream: > Index: devel/kernel.spec > =================================================================== > --- devel.orig/kernel.spec 2008-07-24 08:49:22.000000000 +0100 > +++ devel.orig/kernel.spec 2008-07-24 08:49:22.000000000 +0100 > @@ -1312,6 +1312,13 @@ BuildKernel() { > make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install KERNELRELEASE=$KernelVer mod-fw= > %ifarch %{vdso_arches} > make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer + if grep '^CONFIG_XEN=y$' .config >/dev/null; then + echo > ldconfig-kernelcap.conf "\ +# This directive teaches ldconfig to search in nosegneg subdirectories +# and cache the DSOs there with extra bit 0 set in their hwcap match +# fields. In Xen guest kernels, the vDSO tells the dynamic linker to +# search in nosegneg subdirectories and to match this extra hwcap bit +# in the ld.so.cache file. +hwcap 0 nosegneg" + fi > + if [ ! -s ldconfig-kernelcap.conf ]; then > + echo > ldconfig-kernelcap.conf "\ > +# Placeholder file, no vDSO hwcap entries used in this kernel." > + fi > + %{__install} -D -m 444 ldconfig-kernelcap.conf \ > + $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf > %endif Cheers, Mark. From roland at redhat.com Thu Jul 24 08:36:12 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 01:36:12 -0700 (PDT) Subject: rebase, utrace Message-ID: <20080724083612.D056A15425C@magilla.localdomain> I took the liberty of rebasing rawhide to git11. (rebase.sh works great!) That was necessary for my latest utrace patches to apply, and I turned those back on. I'm starting a build and will deal if it doesn't compile. Thanks, Roland From roland at redhat.com Thu Jul 24 08:48:20 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 01:48:20 -0700 (PDT) Subject: [patch 2/7] Change how we do nosegneg In-Reply-To: Mark McLoughlin's message of Thursday, 24 July 2008 09:12:48 +0100 <1216887168.3633.6.camel@muff> References: <20080723132013.952833740@redhat.com> <20080723133507.488248088@redhat.com> <20080724004113.95E4215421D@magilla.localdomain> <1216887168.3633.6.camel@muff> Message-ID: <20080724084820.5FE0515425C@magilla.localdomain> > All sounds fairly reasonable to me, but why not have "make vdso_install" > install the file? Yeah, that will be the right thing for upstream eventually. Probably for upstream it is preferred to install files only in $INSTALL_MOD_PATH and not go touching /etc. So I think the norm will be something like /lib/modules/.../ldconfig.conf and then we can install a single /etc/ld.so.conf.d/kernel.conf that contains: include /lib/modules/*/ldconfig.conf > Looking at your patch, if you're going have a file per-variant, you need > to install it in BuildKernel. And you also only want to do it on > vdso_arches. Right. Thanks, Roland From roland at redhat.com Thu Jul 24 09:31:04 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 02:31:04 -0700 (PDT) Subject: git11 new config items Message-ID: <20080724093104.CFBC0154252@magilla.localdomain> I added these to config-generic to keep building with -git11. I have no idea if these are the right settings. +# CONFIG_MFD_TC6393XB is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_DMADEVICES=y +CONFIG_INTEL_IOATDMA=m +# CONFIG_DMATEST is not set Thanks, Roland From designatedl at studiowigs.com Thu Jul 24 13:25:17 2008 From: designatedl at studiowigs.com (Trudy Quick) Date: Thu, 24 Jul 2008 14:25:17 +0100 Subject: Are you still struggling to get it? Message-ID: <01c8ed99$18170480$7e07054f@designatedl> Bacheelor, MasteerMBA, and Doctoraate diplomas available in the field of your choice that's right, you can even become a Doctor and receive all the benefits that comes with it! Our Diplomas/Certificates are recognised in most countries No required examination, tests, classes, books, or interviews. ** No one is turned down ** Confidentiality assured CALL US 24 HOURS A DAY, 7 DAYS A WEEK For US: 1-781-634-7970 Outside US: +1-781-634-7970 "Just leave your NAME & PHONE NO. (with CountryCode)" in the voicemail our staff will get back to you in next few days From kyle at mcmartin.ca Thu Jul 24 15:10:54 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 24 Jul 2008 11:10:54 -0400 Subject: git11 new config items In-Reply-To: <20080724093104.CFBC0154252@magilla.localdomain> References: <20080724093104.CFBC0154252@magilla.localdomain> Message-ID: <20080724151054.GI13751@phobos.i.cabal.ca> On Thu, Jul 24, 2008 at 02:31:04AM -0700, Roland McGrath wrote: > I added these to config-generic to keep building with -git11. > I have no idea if these are the right settings. > > +# CONFIG_MFD_TC6393XB is not set > +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set > +CONFIG_DMADEVICES=y > +CONFIG_INTEL_IOATDMA=m > +# CONFIG_DMATEST is not set > Looks fine. Thanks Roland. cheers, Kyle From davej at redhat.com Thu Jul 24 16:15:14 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 24 Jul 2008 12:15:14 -0400 Subject: git11 new config items In-Reply-To: <20080724093104.CFBC0154252@magilla.localdomain> References: <20080724093104.CFBC0154252@magilla.localdomain> Message-ID: <20080724161514.GB23108@redhat.com> On Thu, Jul 24, 2008 at 02:31:04AM -0700, Roland McGrath wrote: > I added these to config-generic to keep building with -git11. > I have no idea if these are the right settings. > > +# CONFIG_MFD_TC6393XB is not set > +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set > +CONFIG_DMADEVICES=y > +CONFIG_INTEL_IOATDMA=m > +# CONFIG_DMATEST is not set All ok, except that CONFIG_INTEL_IOATDMA is already in config-x86[64].config I just nuked the dupe. Dave -- http://www.codemonkey.org.uk From amruth_pv at yahoo.com Sun Jul 27 19:37:25 2008 From: amruth_pv at yahoo.com (amruth) Date: Sun, 27 Jul 2008 12:37:25 -0700 (PDT) Subject: USB serial device trying to register wrong tty device after usb_reset_device In-Reply-To: <475990.26724.qm@web45215.mail.sp1.yahoo.com> Message-ID: <582339.18393.qm@web45204.mail.sp1.yahoo.com> Hi All > I connected 2 serial devices based on TI 3410 chipset, > which downloads firmware and the system resets using > usb_reset_device. The problem is after the adding the second > device, the system downloads firmware, usb_reset_device is > called similar to first one, but now the USB reenumerates. > Does the first device which has been allocated ttyUSB0 > disappear. I have seen that the first device ttyUSB0 does > not disappear. > The system is trying to re register the 2nd device with > ttyUSB0 which is not correct.Why does the kernel detect that > ttyUSB0 is already claimed by 1st device. The code snippet > from usb-serial.c is below. > > if (get_free_serial (serial, num_ports, &minor) == > NULL) { > dev_err(&interface->dev, "No > more free serial devices\n"); > goto probe_error; > } > serial->minor = minor; > > Why does not get_free_serial return 1 instead of 0 because > 0 is climed by 1st device. > > snprintf (&port->dev.bus_id[0], > sizeof(port->dev.bus_id), "ttyUSB%d", > port->number); > dbg ("%s - registering %s", > __FUNCTION__, port->dev.bus_id); > retval = > device_register(&port->dev); > if (retval) > dev_err(&port->dev, > "Error registering port device, " > > "continuing\n"); > > > > Is there any workaround to find that the 1st device is > already claimed, so that register try to register with 2nd > device and create ttyUSB1. > Please let me know if anybody encountered this issue. > Thanks > Amruth p.v > > > --- On Sat, 7/26/08, amruth > wrote: > > > From: amruth > > Subject: 2.6.26 kernel crashes after hotplugging 2nd > device of same type > > To: linux-usb at vger.kernel.org > > Date: Saturday, July 26, 2008, 1:23 AM > > Hi > > All > > The system crashes after connecting multiple serial > devices > > based on ti usb 3410 chipset of same type. > > > > The detailed log is below. The kernel is 2.6.26. > > > > Please suggest any ideas what is going on.Do we have > any > > workaround for this issue. > > > > Do the kernel allow multiple devie to register. > > > > If the first device was assigned ttyUSB0, then why > does the > > 2nd device try to register with same ttyUSB0. How does > > ttyUSB ids assigned in the kernel. > > > > > > usb 2-2: reset full speed USB device using uhci_hcd > and > > address 5 > > usb 2-2: device firmware changed > > usb 2-2: USB disconnect, address 5 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_shutdown > > ti_usb_3410_5052 2-2:1.0: device disconnected > > usb 2-2: new full speed USB device using uhci_hcd and > > address 6 > > usb 2-2: configuration #1 chosen from 2 choices > > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port adapter > > converter detected > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - product 0x 8, num configurations 2, > > configuration value 1 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - device type is 3410 > > ti_usb_3410_5052: probe of 2-2:1.0 failed with error > -5 > > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port adapter > > converter detected > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - product 0x 8, num configurations 2, > > configuration value 2 > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_startup - device type is 3410 > > usb-serial ttyUSB0: Error registering port device, > > continuing > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > ti_shutdown > > BUG: unable to handle kernel NULL pointer dereference > at > > 00000018 > > IP: [] sysfs_find_dirent+0x4/0x23 > > *pde = 0e975067 *pte = 00000000 > > Oops: 0000 [#1] SMP > > Modules linked in: ti_usb_3410_5052 usbserial autofs4 > hidp > > rfcomm l2cap bluetooth sunrpc iptable_filter ip_tables > > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables > x_tables > > dm_multipath sbs sbshc battery ac ipv6 parport_pc lp > parport > > dcdbas floppy snd_intel8x0 snd_ac97_codec ac97_bus > > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss > > snd_seq_midi_event button snd_seq e1000 snd_seq_device > > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw rtc_cmos > > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd > edac_core > > pcspkr soundcore snd_page_alloc dm_snapshot dm_zero > > dm_mirror dm_log dm_mod ata_piix libata sd_mod > scsi_mod ext3 > > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: > microcode] > > > > Pid: 4035, comm: sh Not tainted (2.6.26 #1) > > EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > > EIP is at sysfs_find_dirent+0x4/0x23 > > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX: > c067ea13 > > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP: > cebafe30 > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0 > > task.ti=cebaf000) > > Stack: c067ea13 00000000 c04a2b01 ce8dc684 00000000 > > c04a32ce ce8dc684 00000001 > > ce896c1c d0c88438 c054ca37 ce8dc684 c0548e33 > > ce8dc684 00000001 00000000 > > c0548f3f d0c88400 e0af9907 d0c88434 e0af9862 > > 00000001 c04ddc02 d0c88434 > > Call Trace: > > [] sysfs_get_dirent+0x19/0x45 > > [] sysfs_remove_group+0x18/0x96 > > [] device_pm_remove+0x14/0x3c > > [] device_del+0xd/0x111 > > [] device_unregister+0x8/0x10 > > [] destroy_serial+0xa5/0xeb > [usbserial] > > [] destroy_serial+0x0/0xeb [usbserial] > > [] kref_put+0x36/0x40 > > [] usb_serial_put+0x1c/0x27 > [usbserial] > > [] usb_serial_disconnect+0x83/0xa8 > > [usbserial] > > [] usb_unbind_interface+0x2d/0x5f > > [] __device_release_driver+0x58/0x76 > > [] device_release_driver+0x18/0x21 > > [] bus_remove_device+0x6b/0x7b > > [] device_del+0xc0/0x111 > > [] usb_disable_device+0x55/0xbb > > [] usb_set_configuration+0x1bd/0x414 > > [] sscanf+0x17/0x19 > > [] set_bConfigurationValue+0x44/0x62 > > [] set_bConfigurationValue+0x0/0x62 > > [] dev_attr_store+0x19/0x1d > > [] sysfs_write_file+0xa4/0xd8 > > [] sysfs_write_file+0x0/0xd8 > > [] vfs_write+0x83/0xf6 > > [] sys_write+0x3c/0x63 > > [] syscall_call+0x7/0xb > > [] migration_call+0x314/0x3b6 > > ======================= > > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb fe 8b > 41 20 > > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51 0c 89 > 0b 5b > > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89 f2 > e8 df > > ed 03 00 85 c0 74 07 8b 5b > > EIP: [] sysfs_find_dirent+0x4/0x23 > SS:ESP > > 0068:cebafe30 > > ---[ end trace e53c213592aca5ba ]--- > > > > > > Thanks > > Amruth p.v > > > > > > Thanks > > Amruth p.v > > > > > > --- On Fri, 7/25/08, amruth > > > wrote: > > > > > From: amruth > > > Subject: kernel crashes after connecting multiple > > serial devices > > > To: "Alan Stern" > > , "Oliver > Neukum" > > > > > Cc: linux-usb at vger.kernel.org > > > Date: Friday, July 25, 2008, 1:10 PM > > > Hi > > > The system crashes after connecting multiple > serial > > devices > > > based on ti usb 3410 chipset. The detailed log is > > below. The > > > kernel is 2.6.26. Please suggest any ideas what > is > > going on. > > > > > > usb 2-2: reset full speed USB device using > uhci_hcd > > and > > > address 5 > > > usb 2-2: device firmware changed > > > usb 2-2: USB disconnect, address 5 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_shutdown > > > ti_usb_3410_5052 2-2:1.0: device disconnected > > > usb 2-2: new full speed USB device using uhci_hcd > and > > > address 6 > > > usb 2-2: configuration #1 chosen from 2 choices > > > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port > adapter > > > converter detected > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - product 0x 8, num configurations > 2, > > > configuration value 1 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - device type is 3410 > > > ti_usb_3410_5052: probe of 2-2:1.0 failed with > error > > -5 > > > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port > adapter > > > converter detected > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - product 0x 8, num configurations > 2, > > > configuration value 2 > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_startup - device type is 3410 > > > usb-serial ttyUSB0: Error registering port > device, > > > continuing > > > > > > /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c: > > > ti_shutdown > > > BUG: unable to handle kernel NULL pointer > dereference > > at > > > 00000018 > > > IP: [] sysfs_find_dirent+0x4/0x23 > > > *pde = 0e975067 *pte = 00000000 > > > Oops: 0000 [#1] SMP > > > Modules linked in: ti_usb_3410_5052 usbserial > autofs4 > > hidp > > > rfcomm l2cap bluetooth sunrpc iptable_filter > ip_tables > > > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables > > x_tables > > > dm_multipath sbs sbshc battery ac ipv6 parport_pc > lp > > parport > > > dcdbas floppy snd_intel8x0 snd_ac97_codec > ac97_bus > > > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss > > > snd_seq_midi_event button snd_seq e1000 > snd_seq_device > > > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw > rtc_cmos > > > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd > > edac_core > > > pcspkr soundcore snd_page_alloc dm_snapshot > dm_zero > > > dm_mirror dm_log dm_mod ata_piix libata sd_mod > > scsi_mod ext3 > > > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: > > microcode] > > > > > > Pid: 4035, comm: sh Not tainted (2.6.26 #1) > > > EIP: 0060:[] EFLAGS: 00010246 > CPU: 0 > > > EIP is at sysfs_find_dirent+0x4/0x23 > > > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX: > > c067ea13 > > > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP: > > cebafe30 > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0 > > > task.ti=cebaf000) > > > Stack: c067ea13 00000000 c04a2b01 ce8dc684 > 00000000 > > > c04a32ce ce8dc684 00000001 > > > ce896c1c d0c88438 c054ca37 ce8dc684 > c0548e33 > > > ce8dc684 00000001 00000000 > > > c0548f3f d0c88400 e0af9907 d0c88434 > e0af9862 > > > 00000001 c04ddc02 d0c88434 > > > Call Trace: > > > [] sysfs_get_dirent+0x19/0x45 > > > [] sysfs_remove_group+0x18/0x96 > > > [] device_pm_remove+0x14/0x3c > > > [] device_del+0xd/0x111 > > > [] device_unregister+0x8/0x10 > > > [] destroy_serial+0xa5/0xeb > > [usbserial] > > > [] destroy_serial+0x0/0xeb > > [usbserial] > > > [] kref_put+0x36/0x40 > > > [] usb_serial_put+0x1c/0x27 > > [usbserial] > > > [] > usb_serial_disconnect+0x83/0xa8 > > > [usbserial] > > > [] > usb_unbind_interface+0x2d/0x5f > > > [] > __device_release_driver+0x58/0x76 > > > [] > device_release_driver+0x18/0x21 > > > [] bus_remove_device+0x6b/0x7b > > > [] device_del+0xc0/0x111 > > > [] usb_disable_device+0x55/0xbb > > > [] > usb_set_configuration+0x1bd/0x414 > > > [] sscanf+0x17/0x19 > > > [] > set_bConfigurationValue+0x44/0x62 > > > [] > set_bConfigurationValue+0x0/0x62 > > > [] dev_attr_store+0x19/0x1d > > > [] sysfs_write_file+0xa4/0xd8 > > > [] sysfs_write_file+0x0/0xd8 > > > [] vfs_write+0x83/0xf6 > > > [] sys_write+0x3c/0x63 > > > [] syscall_call+0x7/0xb > > > [] migration_call+0x314/0x3b6 > > > ======================= > > > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb > fe 8b > > 41 20 > > > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51 > 0c 89 > > 0b 5b > > > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89 > f2 > > e8 df > > > ed 03 00 85 c0 74 07 8b 5b > > > EIP: [] > sysfs_find_dirent+0x4/0x23 > > SS:ESP > > > 0068:cebafe30 > > > ---[ end trace e53c213592aca5ba ]--- > > > > > > > > > Thanks > > > Amruth p.v > > > > > > > > > --- On Fri, 7/25/08, Oliver Neukum > > > wrote: > > > > > > > From: Oliver Neukum > > > > > Subject: Re: usb_reset_device causes probe > to > > fail on > > > USB serial device > > > > To: "Alan Stern" > > > > > > > Cc: amruth_pv at yahoo.com, > > linux-usb at vger.kernel.org > > > > Date: Friday, July 25, 2008, 10:44 AM > > > > Am Freitag 25 Juli 2008 15:42:14 schrieb > Alan > > Stern: > > > > > On Fri, 25 Jul 2008, Oliver Neukum > wrote: > > > > > > > > > > > > What about situations where > the > > > firmware > > > > loading or mode switching was > > > > > > > done by a userspace task? > > > > > > > > > > > > They will have to go into kernel > space. > > > > > > > > > > This does not sound practical. > You're > > > talking > > > > about putting > > > > > potentially unbounded amounts of new > code > > and > > > data > > > > into the kernel. > > > > > > > > True. But the kernel is already open to > > potentially > > > > unbounded amounts > > > > of new code. We are adding drivers faster > than > > > removing > > > > them. > > > > > > > > > > > I'm not at all convinced > that > > the > > > > actions needed to return a wiped-out > > > > > > > device to normal operation > can be > > > carried > > > > out in the relatively > > > > > > > delicate environment of > > > > resume-from-hibernation. > > > > > > > > > > > > Why? > > > > > > > > > > Because there's no restriction on > what > > may be > > > > needed. Arbitrary > > > > > sequences of packets, arbitrarily long > data > > > sets,... > > > > And all with no > > > > > support from userspace. > > > > > > > > But the amount of work an implementation of > > resume() > > > may > > > > have to > > > > do. uvc needs to submit hundreds of URBs in > the > > worst > > > case. > > > > > > > > > The whole USB-Persist thing was sort of > a > > hack to > > > > begin with. Trying > > > > > to shoehorn all this extra stuff into > it is > > just > > > > impractical. It makes > > > > > much more sense to say that a device > which > > loses > > > too > > > > much state as a > > > > > result of a power interruption must be > > logically > > > > disconnected and > > > > > reinitialized. > > > > > > > > But why let it stay a sort of hack? The idea > has > > > potential. > > > > > > > > Regards > > > > Oliver > > > > -- > > > > To unsubscribe from this list: send the line > > > > "unsubscribe linux-usb" in > > > > the body of a message to > > majordomo at vger.kernel.org > > > > More majordomo info at > > > > http://vger.kernel.org/majordomo-info.html > > > > > > > > > > > > > > > -- > > > To unsubscribe from this list: send the line > > > "unsubscribe linux-usb" in > > > the body of a message to > majordomo at vger.kernel.org > > > More majordomo info at > > > http://vger.kernel.org/majordomo-info.html > > > > > > > > > > -- > > To unsubscribe from this list: send the line > > "unsubscribe linux-usb" in > > the body of a message to majordomo at vger.kernel.org > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > > > > -- > To unsubscribe from this list: send the line > "unsubscribe linux-usb" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at > http://vger.kernel.org/majordomo-info.html From roland at redhat.com Mon Jul 28 09:49:06 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 28 Jul 2008 02:49:06 -0700 (PDT) Subject: linux-2.6-build-nonintconfig.patch rebase Message-ID: <20080728094906.75C13154291@magilla.localdomain> Running rebase.sh was so much fun that I for some reason decided to do Dave's job today and once I'd run it then I had to cope with the kconfig changes upstream. I hacked linux-2.6-build-nonintconfig.patch and is seems to be about right again. But I never did try to really understand that code. Someone ought to look at it. The headers_check magic changed, so the .spec kludge broke. Running it normally instead of using the innards seemed right to me. They seem to keep breaking stuff upstream, so the last iteration probably didn't build either. I bet upstream will fix the installing /usr/include/.install et al before long, and then the find | xargs rm I added can go. Thanks, Roland From SteveD at redhat.com Tue Jul 29 16:00:33 2008 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 29 Jul 2008 12:00:33 -0400 Subject: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options Message-ID: <488F3EA1.8090102@RedHat.com> Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the "--with firmware" build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the "--without vdso_install" build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson diff -up SPECS/kernel.spec.orig SPECS/kernel.spec --- SPECS/kernel.spec.orig 2008-07-29 09:07:48.000000000 -0400 +++ SPECS/kernel.spec 2008-07-29 11:44:39.000000000 -0400 @@ -75,11 +75,13 @@ Summary: The Linux kernel # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} # kernel-firmware -%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} +%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1} # kernel-bootwrapper (for creating zImages from kernel + initrd) %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1} +# Want to build a the vsdo directories installed +%define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1} # don't build the kernel-doc package %define with_doc 0 @@ -188,8 +190,10 @@ Summary: The Linux kernel %define all_x86 i386 i586 i686 +%if %{with_vdso_install} # These arches install vdso/ directories. %define vdso_arches %{all_x86} x86_64 ppc ppc64 +%endif # Overrides for generic default options @@ -217,7 +221,6 @@ Summary: The Linux kernel # only package docs noarch %ifnarch noarch %define with_doc 0 -%define with_firmware 0 %endif # no need to build headers again for these arches, @@ -231,6 +234,7 @@ Summary: The Linux kernel %define with_up 0 %define with_headers 0 %define all_arch_configs kernel-%{version}-*.config +%define with_firmware 1 %endif # bootwrapper is only on ppc From Ted.Nzuonkwelle at Colorado.EDU Tue Jul 29 18:01:28 2008 From: Ted.Nzuonkwelle at Colorado.EDU (Ted Sume Nzuonkwelle) Date: Tue, 29 Jul 2008 12:01:28 -0600 Subject: perfmon2 on fedora kernels Message-ID: <1217354488.14811.9.camel@laser.txcorp.com> Hi, My apologies if this is going to the wrong mailing list. Is there an easy way to enable support for perfmon2 in the fedora 9 kernel(s)? Looks like the patch for perfmon2 available at http://sourceforge.net/projects/perfmon2/ is only useful if patching a vanilla kernel? Any help and/pointers will be greatly appreciated. Thanks. - Ted Sume From markmc at redhat.com Wed Jul 30 14:57:28 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 30 Jul 2008 15:57:28 +0100 Subject: [patch 1/3] Remove flag args from kernel_variant_posttrans References: <20080730145605.383182011@redhat.com>> Message-ID: <1217429848.19821.29.camel@muff> plain text document attachment (kernel-variant-posttrans-cleanup-args.patch) kernel_variant_posttrans only takes a single arg, so don't bother using flag arguments since they're a bit more confusing. Note that the macro invocation didn't actually pass it a flag arg, but it seemed to have access to the calling macros flag args anyway. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 13:32:44.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 13:32:44.000000000 +0100 @@ -1527,7 +1527,7 @@ rm -rf $RPM_BUILD_ROOT # # This macro defines a %%post script for a kernel*-devel package. -# %%kernel_devel_post +# %%kernel_devel_post [] # %define kernel_devel_post() \ %{expand:%%post %{?1:%{1}-}devel}\ @@ -1545,12 +1545,12 @@ fi\ %{nil} # This macro defines a %%posttrans script for a kernel package. -# %%kernel_variant_posttrans [-v ] [-s -r ] +# %%kernel_variant_posttrans [] # More text can follow to go at the end of this variant's %%post. # -%define kernel_variant_posttrans(s:r:v:) \ -%{expand:%%posttrans %{?-v*}}\ -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{KVERREL}%{?-v:.%{-v*}} || exit $?\ +%define kernel_variant_posttrans() \ +%{expand:%%posttrans %{?1}}\ +/sbin/new-kernel-pkg --package kernel%{?1:-%{1}} --rpmposttrans %{KVERREL}%{?1:.%{1}} || exit $?\ %{nil} # -- From markmc at redhat.com Wed Jul 30 14:58:02 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 30 Jul 2008 15:58:02 +0100 Subject: [patch 2/3] Add kernel_%{variant}_replaces macros References: <20080730145605.383182011@redhat.com>> Message-ID: <1217429882.19821.30.camel@muff> plain text document attachment (kernel-variant-post-kill-replace-arg.patch) The -r arg is redundant because we already now the variant name so we can use kernel%{?-v:-%{-v*}} instead. So, rename the -s arg to -r and drop the existing meaning of -r. Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 14:15:15.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 14:15:15.000000000 +0100 @@ -1555,17 +1555,17 @@ fi\ # # This macro defines a %%post script for a kernel package and its devel package. -# %%kernel_variant_post [-v ] [-s -r ] +# %%kernel_variant_post [-v ] [-r ] # More text can follow to go at the end of this variant's %%post. # -%define kernel_variant_post(s:r:v:) \ +%define kernel_variant_post(v:r:) \ %{expand:%%kernel_devel_post %{?-v*}}\ %{expand:%%kernel_variant_posttrans %{?-v*}}\ %{expand:%%post %{?-v*}}\ -%{-s:\ +%{-r:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ [ -f /etc/sysconfig/kernel ]; then\ - /bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/' /etc/sysconfig/kernel || exit $?\ + /bin/sed -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ fi}\ /sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\ #if [ -x /sbin/weak-modules ]\ @@ -1588,18 +1588,18 @@ fi}\ %{nil} %kernel_variant_preun -%kernel_variant_post -s kernel-smp -r kernel +%kernel_variant_post -r kernel-smp %kernel_variant_preun smp %kernel_variant_post -v smp %kernel_variant_preun PAE -%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE +%kernel_variant_post -v PAE -r kernel-smp %kernel_variant_preun debug %kernel_variant_post -v debug -%kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug +%kernel_variant_post -v PAEdebug -r kernel-smp %kernel_variant_preun PAEdebug if [ -x /sbin/ldconfig ] -- From markmc at redhat.com Wed Jul 30 14:58:31 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 30 Jul 2008 15:58:31 +0100 Subject: [patch 3/3] Have kernel-PAE.i686 and kernel.x86_64 fix DEFAULTKERNEL=kernel-xen References: <20080730145605.383182011@redhat.com>> Message-ID: <1217429911.19821.32.camel@muff> plain text document attachment (kernel-xen-defaultkernel.patch) Now we can fix: https://bugzilla.redhat.com/456558 by having kernel.x86_64 and kernel-PAE.i686 munge DEFAULTKERNEL as appropriate. Use sed --regexp-extended so we don't have to do "\(foo\|bar\)" Index: devel/kernel.spec =================================================================== --- devel.orig/kernel.spec 2008-07-30 15:50:27.000000000 +0100 +++ devel.orig/kernel.spec 2008-07-30 15:50:27.000000000 +0100 @@ -1565,7 +1565,7 @@ fi\ %{-r:\ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ [ -f /etc/sysconfig/kernel ]; then\ - /bin/sed -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ + /bin/sed -r -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\ fi}\ /sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\ #if [ -x /sbin/weak-modules ]\ @@ -1588,18 +1588,22 @@ fi}\ %{nil} %kernel_variant_preun +%ifarch x86_64 +%kernel_variant_post -r (kernel-smp|kernel-xen) +%else %kernel_variant_post -r kernel-smp +%endif %kernel_variant_preun smp %kernel_variant_post -v smp %kernel_variant_preun PAE -%kernel_variant_post -v PAE -r kernel-smp +%kernel_variant_post -v PAE -r (kernel-smp|kernel-xen) %kernel_variant_preun debug %kernel_variant_post -v debug -%kernel_variant_post -v PAEdebug -r kernel-smp +%kernel_variant_post -v PAEdebug -r (kernel-smp|kernel-xen) %kernel_variant_preun PAEdebug if [ -x /sbin/ldconfig ] -- From cebbert at redhat.com Thu Jul 31 18:26:10 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 31 Jul 2008 14:26:10 -0400 Subject: perfmon2 on fedora kernels In-Reply-To: <1217354488.14811.9.camel@laser.txcorp.com> References: <1217354488.14811.9.camel@laser.txcorp.com> Message-ID: <489203C2.1060302@redhat.com> Ted Sume Nzuonkwelle wrote: > Hi, > > My apologies if this is going to the wrong mailing list. > > Is there an easy way to enable support for perfmon2 in the fedora 9 > kernel(s)? Looks like the patch for perfmon2 available at > > > http://sourceforge.net/projects/perfmon2/ > > is only useful if patching a vanilla kernel? Any help and/pointers will > be greatly appreciated. > It shouldn't be too hard to get it working. You just need to fix up the parts that don't apply properly. We could put it in fedora but it's not upstream and nobody can say when or if it will go in. From davej at redhat.com Thu Jul 31 18:31:33 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 31 Jul 2008 14:31:33 -0400 Subject: perfmon2 on fedora kernels In-Reply-To: <489203C2.1060302@redhat.com> References: <1217354488.14811.9.camel@laser.txcorp.com> <489203C2.1060302@redhat.com> Message-ID: <20080731183133.GA1108@redhat.com> On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: > We could put it in fedora but it's not upstream and nobody can say when or if > it will go in. After the long drawn out pain that utrace has been, I'm somewhat reluctant. Especially for something that's providing additional userspace interfaces that aren't upstream. Dave -- http://www.codemonkey.org.uk From kyle at mcmartin.ca Thu Jul 31 18:41:14 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 31 Jul 2008 14:41:14 -0400 Subject: perfmon2 on fedora kernels In-Reply-To: <20080731183133.GA1108@redhat.com> References: <1217354488.14811.9.camel@laser.txcorp.com> <489203C2.1060302@redhat.com> <20080731183133.GA1108@redhat.com> Message-ID: <20080731184114.GB19212@phobos.i.cabal.ca> On Thu, Jul 31, 2008 at 02:31:33PM -0400, Dave Jones wrote: > On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: > > > We could put it in fedora but it's not upstream and nobody can say when or if > > it will go in. > > After the long drawn out pain that utrace has been, I'm somewhat reluctant. > Especially for something that's providing additional userspace interfaces > that aren't upstream. > Perfmon adds a ridiculous number of syscalls, which means we *really* shouldn't merge it until they're reserved upstream, otherwise backwards compat woes will ensue. However, perfmon doesn't look like it is anywhere near being merged in the current form, so I'd rate it as unlikely upstream will reserve 10+ syscall entrypoints for it... NAK from me... cheers, Kyle From cebbert at redhat.com Thu Jul 31 20:29:50 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 31 Jul 2008 16:29:50 -0400 Subject: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options In-Reply-To: <488F3EA1.8090102@RedHat.com> References: <488F3EA1.8090102@RedHat.com> Message-ID: <489220BE.8020906@redhat.com> Steve Dickson wrote: > Now that devel kernels rpms require the kernel-firmware rpm, it makes > sense to me that one should be able to build both of them at the > same time. So this patch adds the "--with firmware" build option > which will allow kernel-firmware rpms to built with kernel rpms. > > This patch also adds the "--without vdso_install" build option > which stop the VDSO binaries from being installed. This cuts > down the overall build time especially when you build over NFS > like I do.. > > Signed-Off-By: Steve Dickson With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... > > diff -up SPECS/kernel.spec.orig SPECS/kernel.spec > --- SPECS/kernel.spec.orig 2008-07-29 09:07:48.000000000 -0400 > +++ SPECS/kernel.spec 2008-07-29 11:44:39.000000000 -0400 > @@ -75,11 +75,13 @@ Summary: The Linux kernel > # kernel-headers > %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} > # kernel-firmware > -%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} > +%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0} > # kernel-debuginfo > %define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1} > # kernel-bootwrapper (for creating zImages from kernel + initrd) > %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1} > +# Want to build a the vsdo directories installed > +%define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1} > > # don't build the kernel-doc package > %define with_doc 0 > @@ -188,8 +190,10 @@ Summary: The Linux kernel > > %define all_x86 i386 i586 i686 > > +%if %{with_vdso_install} > # These arches install vdso/ directories. > %define vdso_arches %{all_x86} x86_64 ppc ppc64 > +%endif > > # Overrides for generic default options > > @@ -217,7 +221,6 @@ Summary: The Linux kernel > # only package docs noarch > %ifnarch noarch > %define with_doc 0 > -%define with_firmware 0 > %endif > > # no need to build headers again for these arches, > @@ -231,6 +234,7 @@ Summary: The Linux kernel > %define with_up 0 > %define with_headers 0 > %define all_arch_configs kernel-%{version}-*.config > +%define with_firmware 1 +%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} > %endif > > # bootwrapper is only on ppc > From linville at redhat.com Thu Jul 31 21:30:44 2008 From: linville at redhat.com (John W. Linville) Date: Thu, 31 Jul 2008 17:30:44 -0400 Subject: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version? In-Reply-To: <20080707153710.GD28109@redhat.com> References: <486F6F7E.8070809@leemhuis.info> <486F8FE0.6070401@leemhuis.info> <486F985C.3090803@leemhuis.info> <486F6F7E.8070809@leemhuis.info> <20080707153710.GD28109@redhat.com> Message-ID: <20080731213044.GB12820@redhat.com> On Mon, Jul 07, 2008 at 11:37:10AM -0400, John W. Linville wrote: > So, here is what I propose: > > -- continue the current practice until 2.6.26 is released and the > 2.6.27 merge window closes; > > -- after that, continue the current practice for updating rawhide; but, > > -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits > to the -wireless.patch and do _not_ create a new -pending.patch for > 2.6.28 bits; > > -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will > get no more wireless updates at all; > > -- F10 will release with -wireless and -pending patches inherited from > rawhide, but they will "age out" following the process described for > F9/F8 above. Sorry to revive an old thread, but I'd like to amend the plan. I'm going to decline to add any post-2.6.27 wireless bits to rawhide. I think continuing that practice only complicates things for when rawhide becomes f10, and in the meantime just adds to my personal pain. Besides, I'm quite tired of...well, I'm just tired. I'm prepared to consider adding specific items as requested (e.g. ath9k), but for now let's just presume that rawhide will mostly just get its wireless bits through Linus. I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. Thanks, John -- John W. Linville linville at redhat.com