Fedora kernel has branched for F-12
The F-12 branch is now for Fedora 12, and devel is now targeted for Fedora 13. If you have updates that you don't expect to be upstream soon, please update both branches. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
On Mon, 7 Sep 2009 14:27:24 -0700 Markus Kesaromous wrote: > > Still not fixed: > > arch/x86/kernel/pvclock.c:63:7: warning: "__x86_64__" is not defined > > It really is just a warning, arising because the kernel gets built with -Wundef. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: snd-vxpocket in kernel not enabled in fedora ?
On Sat, 29 Aug 2009 01:52:16 +0200 tom-ipp wrote: > Hello, > I assume it's the place to ask my question : > is there some known reason to not enable the module alsa snd-vxpocket, > for the digigram soundcard? > Otherwise, due to its audio quality, and despite of its long life, it > should be included in the fedora kernel... > Compilation of the module from alsa 1.0.20 lib is ok. Wow, $618 from B&H. We can enable it in rawhide/F-12 I guess. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29)
On Fri, 14 Aug 2009 10:44:25 -0400 "John W. Linville" wrote: > On Fri, Aug 14, 2009 at 04:35:03PM +0200, Stanislaw Gruszka wrote: > > On Thu, Jul 23, 2009 at 04:35:39PM +0200, Stanislaw Gruszka wrote: > > > Due to backport of patch > > > > > > linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch > > > > > > we have bunch of iwl3945 bugs (race conditions) that are not reproducible > > > on vanilla 2.6.29. These patches address them (at least some of them). > > > > I see in cvs that F10 is moving to 2.6.29, so these patches should go F-10 > > too. > > I'm heading out for the weekend. Would someone else care to shepherd this? I've added those three plus the recent TX queue fix from F-11. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: ia64 no longer should set CONFIG_SYSFS_DEPRECATED=y
On Tue, 28 Apr 2009 15:02:46 -0400 Doug Chapman wrote: > > On Wed, 2009-04-22 at 16:40 -0400, Dave Jones wrote: > > On Wed, Apr 22, 2009 at 04:33:22PM -0400, Doug Chapman wrote: > > > Back in the F9 timeframe we had recommended that > > > CONFIG_SYSFS_DEPRECATED=y be set for the ia64 config. It appears that > > > recent anaconda changes no longer work at all with that set. > > > > > > Can we get this removed? It was set only for ia64 so it will have no > > > affect on other arches. > > > > Done. > > > > Dave > > > > I see this change has been made to the fc12 tree but not fc11. Can we > get this change in the current F-11 branch also? > Done. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Tue, 28 Apr 2009 13:14:08 -0400 Chuck Anderson wrote: > Sorry, I should have specified the command I had used. It was similar > to this: > > rpmbuild -ba --target=i386,i686,noarch --with vanilla --without debuginfo > --without debug --with firmware kernel.spec > > I was building on an F10 i386 host. > I don't think the target can be a list. And if you say '--with firmware' you don't need to build the noarch target unless you want docs (if you do want the whole noarch build then you don't need '--with firmware'.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Tue, 28 Apr 2009 10:27:38 -0700 (PDT) Roland McGrath wrote: > > You should always specify an arch. > > make prep uses noarch and generally works fine. You can just ignore the > strange assembler messages in the 'make configs' phase and the .config > files come out fine, in my experience. Well yeah, but if you're running rpmbuild -ba you probably want to build a kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Tue, 28 Apr 2009 11:17:04 -0400 Chuck Anderson wrote: > > Great. I ended up having lots of other issues with vanilla build. At > some point during the build, the "make oldconfig" becomes interactive > during the %install phase. I answer all the questions with default > values (hitting enter on each one) and then the build fails. I also > see some interesting thigs with ia64. Why is it messing with ia64 > configs? > > Excerpts: > > Building for target noarch > ... You should always specify an arch. I normally use: rpmbuild -bb --target x86_64 --with baseonly --without debuginfo --with firmware kernel.spec (--with firmware has some problems when building 32-bit kernels on x86_64 though.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.29.1-102.fc11 --with vanilla broken
On Wed, 22 Apr 2009 18:18:07 -0400
Chuck Anderson wrote:
> ERROR: Patch linux-2.6-build-nonintconfig.patch not listed as a
> source patch in specfile
> error: Bad exit status from /var/tmp/rpm-tmp.8pegaB (%prep)
>
> this is due to the following code in ApplyPatch():
>
> if ! egrep "^Patch[0-9]+: $patch\$" %{_specdir}/%{name}.spec ; then
> if [ "${patch:0:10}" != "patch-2.6." ] ; then
> echo "ERROR: Patch $patch not listed as a source patch in specfile"
> exit 1
> fi
> fi 2>/dev/null
>
It's trying to grep in {_specdir}/kernel-vanilla.spec because of the ugly
name-munging
that's used to build the vanilla kernel.
Fixed in 2.6.29.1-114:
if ! egrep "^Patch[0-9]+: $patch\$"
%{_specdir}/${RPM_PACKAGE_NAME%{?variant}}.spec ; then
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: EDAC on AMD with Fedora 10
On Tue, 07 Apr 2009 21:44:19 +0100 Jeremy Sanders wrote: > Is there any reason the amd76x_edac module doesn't appear in the Fedora 10 > kernel RPM? As far as I can see it should be being built from the > configuration. > > We've got an AMD 790X based motherboard which doesn't seem to have any > Fedora 10 support for ECC RAM. > According to the kernel Kconfig file it's only available for old 32-bit Athlons, and it is in the i686 kernel(s). config EDAC_AMD76X tristate "AMD 76x (760, 762, 768)" depends on EDAC_MM_EDAC && PCI && X86_32 help Support for error detection and correction on the AMD 76x series of chipsets used with the Athlon processor. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Patch incomplete write error not returned to NFS client
On Tue, 24 Mar 2009 16:17:24 -0400 Victor wrote: > Request for integrating this patch into the next kernel update for > Fedora 10. The patch fixes a bug in NFS where an error will not be > returned to the NFS client when an incomplete write happens at the > filesystem level on the server. > > http://git.linux-nfs.org/?p=bfields/linux.git;a=commitdiff;h=192a3cb6bc1f12a0af55bcf2fbb6e923d48a5b58;hp=82f69c6c0efae204dbf428f5c93fcc8d088696c2 > Please file a bug against Fedora 10 in bugzilla so we can track this. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: File conflicts between alsa-firmware and kernel-firmware
On Tue, 3 Mar 2009 16:07:38 -0500 Jarod Wilson wrote: > > > - Is there a long term goal to bring all the firmware from alsa-firmware > >upstream into the kernel-firmware package? > > No clue... Would have to talk to some alsa folks. > David Woodhouse is working on firmware packaging. He just did a new package: http://www.kernel.org/pub/linux/kernel/people/dwmw2/firmware/linux-firmware-20090319.tar.bz2 Tim, you might want to ask if he's going to put the ALSA firmware in there. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
On Wed, 25 Feb 2009 14:15:37 +0100 Thorsten Leemhuis wrote: > On 25.02.2009 13:27, Chris Lalancette wrote: > > Gerd Hoffmann wrote: > >> We can also simply do this: > >> > >> - Install PAE kernel if the CPU supports PAE. > >> > >> i.e. make PAE the default kernel. > > > > Yes, I really think we should just do this. It's simple, it means we get > > the > > logic right for Xen as well as bare-metal (without any special cases), and > > the > > performance hit for those who have PAE and < 4GB isn't that bad, I don't > > think > > (although numbers one way or the other would be interesting to see). > > What about compatibility problems? My old laptop had a PAE capable CPU > but could not boot a PAE kernel -- I noticed when I was trying a PAE > kernel for some tests two or three years ago. I asked a kernel-developer > back then if it was worth reporting and I got told that such problems > are not unusual and often BIOS or hardware problems. Those likely didn't > vanish magically is that statement is correct. > > The algorithm I posted should handle that. If you support NX or you have >4GB of memory then it's pretty much impossible for you to have one of those old CPUs. And all SVM/VMX capable machines support NX so we'd always have the right kernel for them too. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How should anaconda check for PAE? (was Re: arch fun.)
On Tue, 24 Feb 2009 15:38:42 -0800 (PST) Roland McGrath wrote: > > If we have NX (which anything made in the last few years will) > > it's a performance win to use the hardware NX instead of the > > segment limit hack we implemented in execshield. > > It's more than performance. The segment limit hack is a hack, and does not > actually do full enforcement in all cases (though we have already bent over > backward to ensure that these cases do not come up by default). > Hardware NX is 100% reliable. > We also need to look for lm to see if we can install a 64-bit kernel. So something like: if (lm) install 64-bit else if (!pae) || (!nx && memory < 4GB) install i586 else install PAE ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec,1.1311,1.1312
On Thu, 19 Feb 2009 10:33:03 -0500 Kyle McMartin wrote: > On Thu, Feb 19, 2009 at 10:30:56AM -0500, Bill Nottingham wrote: > > Kyle McMartin (k...@infradead.org) said: > > > On Thu, Feb 19, 2009 at 09:53:57AM -0500, Bill Nottingham wrote: > > > > The compose process (for rawhide/updates) only pulls the latest build > > > > for each source package; ergo, this won't work as far as havong > > > > -docs always available to install. > > > > > > Well, that's broken. But honestly I suspect nobody actually cares. > > > And if they do, I'm sure the F-10 package is still installable. > > > > Why not just make it conditional on whatver the release/non-debug/etc. > > switch is? > > > > I don't care if it gets /composed/ the goal of building it every once > and a while is to make sure it actually does build. We're pretty much > the only people shipping top of tree code in a distro... > But once the release switch gets flipped we should always build it. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Rawhide kernel options not enabled?
I thought we were going to enable these in rawhide since the e1000 EEPROM problem was fixed: CONFIG_FUNCTION_TRACER (was CONFIG_FTRACE) CONFIG_DYNAMIC_FTRACE Also hda audio powersave is still off; we have: CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Skipping 2.6.28 for F8 and F9
2.6.28 has turned out to be a bit buggy. Also 2.6.27 has been chosen to be a long-term supported kernel upstream. This means we can leave F9 and F10 on .27 and concentrate on getting .29 into shape for F10 and F11. With the extra resources available from not trying to fix up .28 we can make .29 even better. Comments? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: config changes
On Fri, 9 Jan 2009 16:45:11 -0500 Bill Nottingham wrote: > Here's some proposed config changes. > >-CONFIG_HAMRADIO=y >+# CONFIG_HAMRADIO is not set hamradio was enabled because of user request. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
dropping the defaults-fat-utf8 patch
I think upstream is trying to tell us something here: we shouldn't default to utf8. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=8d44d9741f6808c107a144f469fb89e6fe7c55e3 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.27 kernel for F-9?
On Fri, 17 Oct 2008 10:10:23 -0400 Kyle McMartin <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 08:03:39AM -0400, Josh Boyer wrote: > > On Fri, Oct 17, 2008 at 06:33:49AM -0400, Jon Masters wrote: > > >Hi, > > > > > >Anyone planning to respin the F-9 kernel with a .27 base? Webcams! :) > > > > I'd recommend waiting until at least the first batch of -stable patches > > is released. > > > > We're going to wait until F-8 is EOL before doing that in F-9. > I was thinking about doing the 2.6.27 update for F9 right after F10 ships. F8 can just stay on 2.6.26 until it goes EOL. In the meantime we need to get the F10 kernel into shape for release... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fwd: [PATCH 1/1] cciss: fix regression, sysfs symlink missing]
On Wed, 15 Oct 2008 12:39:55 -0400 Doug Chapman <[EMAIL PROTECTED]> wrote: > > Sorry, meant to include the BZ in the original email. It has been > reported at least once. I have heard from several co-workers back in HP > that have been blocked by this. > > https://bugzilla.redhat.com/show_bug.cgi?id=466181 > Patch went in 2.6.27-15. I closed the bug too. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [EMAIL PROTECTED]: rpms/kernel/devel kernel.spec, 1.1006, 1.1007]
On Fri, 3 Oct 2008 13:20:29 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]> wrote: > > What's this about? > Just reducing the time it takes to do 'make prep' when the next stable update is released. The patches are so small it doesn't make sense to untar the kernel and apply the stable update every time a new one gets released. It's been in F9 for a while and I wanted it in rawhide before we branched. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, 1 Oct 2008 19:51:30 -0400 Kyle McMartin <[EMAIL PROTECTED]> wrote: > > > > I've got to agree, for ALSA who provide a turnkey package that lets people > > test the latest drivers. Our users do compile that package and report back > > whether it fixes their problems. We probably shouldn't build any sound > > drivers > > in so they can keep doing that. > > > > Heh, we come back to this again... Why can't we do a debug/nodebug style > split for rawhide's built-in-ness? For release we do what's best for > the silent (core sound modules built in, drivers not, since they're pigs.) > majority... > There will be complaints if we do anything that keeps people from building and running ALSA on the released kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 30 Sep 2008 11:10:35 +0200 Thorsten Leemhuis <[EMAIL PROTECTED]> wrote: > The alsa-project is a good example. Say you purchase a new motherboard > and it has a brand new audio codec that is not yet supported by the > in-kernel drivers. You report that to the alsa-project and they develop > code to support that codec; a few days or weeks later they might tell > you to download alsa-driver-1.0.18-alpha1.tar.bz and compile that for > testing. If certain sound drivers (say snd-hda-intel) or the soundcore > are compiled into the kernel (like planed for Fedora) then you will > often be forced to recompile the whole kernel to test the new driver. > That's a whole lot more complicated then compiling just the > alsa-drivers, which is not that hard to do these days with current > Fedora kernels. > I've got to agree, for ALSA who provide a turnkey package that lets people test the latest drivers. Our users do compile that package and report back whether it fixes their problems. We probably shouldn't build any sound drivers in so they can keep doing that. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
John W. Linville wrote: 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. If you push wireless fixes to -stable Fedora would then get them for "free". I don't see many wireless patches in there generally, though the ath5k memory corruption fix just went in. And new drivers would be great. Lots of people seem to want ath9k, for example. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
Steve Dickson wrote: Chuck Ebbert wrote: 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 <[EMAIL PROTECTED]> With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? Applied. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
Kyle McMartin wrote: On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote: That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. Does this cover the case of firmware declared in Makefiles in subdirs that are obj-$(CONFIG_i) += subdir/? If so, cool, but I can't be arsed to check. It only does its thing for stuff in firmware/ Every firmware file needs to be moved there; some are not and they don't get into the package. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] be less annoying on boot
Bill Nottingham wrote: As long as we're printing mostly useless messages on every boot regardless of debug level, make them 5% more amusing. Signed-off-by: Bill Nottingham <[EMAIL PROTECTED]> "Kernel not dead yet" Suggested by drago01 on IRC. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
Kyle McMartin wrote: On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote: On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: 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 <[EMAIL PROTECTED]> With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? You bring up a pretty good point here Jarod, what happens with firmware for arch-specific drivers? The Makefile rules will have to be written in such a way that it gets built into the package despite the CONFIG_* symbol being unset on the build arch. That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
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 <[EMAIL PROTECTED]>
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.0 -0400
+++ SPECS/kernel.spec 2008-07-29 11:44:39.0 -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
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: perfmon2 on fedora kernels
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. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Self Introduction: Hans de Goede
On 03/28/2008 05:44 PM, Hans de Goede wrote: > Hi All, > > I'm a Linux enthusiast / developer. Lately I'm mainly active doing > development for Fedora and writing kernel drivers (and as my day job I'm > a lecturer in Computer Science). > > Fedora has a policy of not shipping a heavily patched kernel, but > instead tries to work with upstream to get any needed patches > integrated. This policy extends to not shipping any addon drivers, but > rather working to get drivers integrated upstream. > > As such I've decided to start spending my spare time on getting more and > better usb webcam support integrated upstream (for non usb video class > devices). I wanted to have something to show, so I've gone to the store, > bought a couple of webcams and started hacking and learning. > There is a partially completed driver for an Acer webcam here: https://sourceforge.net/projects/m560x-driver/ And I have the hardware... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Disable CONFIG_ACPI_SYSFS_POWER?
On 02/16/2008 06:53 AM, drago01 wrote: > Hi, > I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build > directly) on my laptop. > Hal detects two batteries because it looks in sysfs and in procfs for > the battery info. I tryed to apply the patch from the hal-list which > causes hal to not look in procfs but in sysfs only when the sysfs info > is available. The problem with this is that the info in sysfs is broken > (capcity 3.0 Wh etc while the procfs info is correct 45Wh). > I would suggest to set CONFIG_ACPI_SYSFS_POWER to n because the procfs > info already provides this data for userspace and does not report broken > values. > We should be enabling either one or the other, not both. For Fedora 9 maybe it should be the sysfs interface if it works. For 8 it should be only procfs to be backwards compatible. I'll do that. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.24
On 02/10/2008 04:31 AM, drago01 wrote: > Jarod Wilson wrote: >> On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: >> >>> Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 >>> fairly >>> soon? >>> >> >> Chuck was talking about branching in cvs to start doing 2.6.24 builds >> for at least F8 as soon as possible for people to test w/o committing >> to an immediate upgrade from 2.6.23, but I'd assume if testing goes >> well with 2.6.24, we'll move to it fairly soon. >> >> > Any update on this? > Or has the plans for 2.6.24 been changed? > Starting the backport now. It took longer than I thought it would to get a (hopefully) final 2.6.23 kernel ready. I will make some scratch builds available for early testing soon. No CVS branch should be needed. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel build fails with GCC 4.3
On 02/01/2008 05:17 PM, Jan Kratochvil wrote:
> On Fri, 01 Feb 2008 22:06:29 +0100, Chuck Ebbert wrote:
> ...
>> And, after fixing that one we get (on ppc):
>>
>> *** ERROR: same build ID in nonidentical files!
>> /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
>>and /boot/vmlinuz-2.6.24-14.fc9
>
> Currently:
>
> vmlinuz-$VER: Not marked as executable and therefore not splitted into
> binary + .debug
> vmlinux: Copied directly into /usr/lib/debug and therefore its stripped part
> is
> duplicite to the vmlinuz-$VER one
>
> Proposing:
>
> vmlinuz-$VER: Marked as executable, split into a separete vmlinuz-$VER.debug
> vmlinux: Just a symlink into vmlinuz-$VER, GDB will load the
> vmlinuz-$VER.debug
> file for it. This symlink could be dropped but some tools may expect
> the /lib/modules/$VER/vmlinux file to exist. Still they will now
> have
> to deal with the split binary + .debug file for it.
>
> If you agree I can test if it works well, it takes a lot of time to build it.
>
>
>
> Regards,
> Jan
>
>
>
>
> --- kernel.spec 1 Feb 2008 17:45:46 - 1.398
> +++ kernel.spec 1 Feb 2008 22:10:44 -
> @@ -1422,8 +1422,14 @@ BuildKernel() {
> # save the vmlinux file for kernel debugging into the kernel-debuginfo
> rpm
> #
> %if %{with_debuginfo}
> -mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> -cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> +if [ $KernelImage != vmlinux ]; then
> + mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> + cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> +else
> + # mark it executable so that strip-to-file can strip it
> + chmod u+x $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
> + ln -s %{image_install_path}/vmlinuz-$KernelVer
> $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux
> +fi
> %endif
>
> find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f
> >modnames
Roland is looking into this; I added a cc: for him.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
On 02/01/2008 04:22 PM, Roland McGrath wrote: > Oh wait, the "copied not linked" warning probaby explains the whole thing. > The /usr/lib/debug copy is not stripped, so it's not identical. > Yeah, ok. I wonder why this wasn't happening before. > Maybe the compiler is adding some new section type that eu-elfcmp doesn't know it should be ignoring? (If either cmp or eu-elfcmp say the files are identical the script treats them as such. And stripped and unstripped files are found to be identical by eu-elfcmp on my F8 install...) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
On 02/01/2008 02:00 PM, Chuck Ebbert wrote: > Could this be yet another problem caused by the switch to GCC 4.3? > > http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log > > + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p > '/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9' -o debuginfo.list -p > '/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp' -o debuginfosmp.list > -p '/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE' -o > debuginfoPAE.list -p > '/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug' -o > debuginfoPAEdebug.list -p > '/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug' -o > debuginfodebug.list -p '/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen' > -o debuginfoxen.list -p > '/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump' -o > debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24 > extracting debug info from > /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9 > extracting debug info from > /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp > extracting debug info from > /var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux > *** ERROR: same build ID in nonidentical files! > /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux >and /boot/vmlinuz-2.6.24-14.fc9 > error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install) > Before this, it said: *** WARNING: identical binaries are copied, not linked: /usr/lib/debug/lib/modules/2.6.24-9.fc9/vmlinux and /boot/vmlinuz-2.6.24-9.fc9 In find-debuginfo.sh the two files are compared with both 'cmp' and 'eu-elfcmp' -- something has changed that causes them to be considered different where they weren't before. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
Could this be yet another problem caused by the switch to GCC 4.3? http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p '/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9' -o debuginfo.list -p '/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp' -o debuginfosmp.list -p '/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE' -o debuginfoPAE.list -p '/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug' -o debuginfoPAEdebug.list -p '/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug' -o debuginfodebug.list -p '/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen' -o debuginfoxen.list -p '/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump' -o debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24 extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9 extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp extracting debug info from /var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux *** ERROR: same build ID in nonidentical files! /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux and /boot/vmlinuz-2.6.24-14.fc9 error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel build fails with GCC 4.3
On 02/01/2008 03:46 AM, Jakub Jelinek wrote:
> On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote:
>> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
>>> Why are we building these broken kernels with our shiny new compiler?
>>>
>> Does using -ffreestanding fix these references to libgcc? I notice
>> we're not using it when we build x86 or powerpc kernels, where we see
>> this...
>
> No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1]
> self-contained and assumed to be present in both -fhosted and -ffreestanding
> linking. This is nothing new, has been like that for many years.
> AFAIK kernel on several architectures uses libgcc.a, on those where it
> intentionally decides not to do that, it either needs to supply its own
> implementation of the needed entrypoints, or make sure they are not needed.
> In this case you should put in an asm optimization barrier into the loop
> to avoid optimizing the loop into modulo. See the gcc PR opened for it.
>
The below patch fixes it too, but that just leads to the next error
(on ppc64):
drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section
type conflict
Was someone supposed to test building the kernel package with the new
compiler before making it the default?
--- linux-2.6.24.noarch.orig/include/linux/time.h
+++ linux-2.6.24.noarch/include/linux/time.h
@@ -169,7 +169,7 @@ extern struct timeval ns_to_timeval(cons
* @a: pointer to timespec to be incremented
* @ns:unsigned nanoseconds value to be added
*/
-static inline void timespec_add_ns(struct timespec *a, u64 ns)
+static inline void timespec_add_ns(struct timespec *a, volatile u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Kernel build fails with GCC 4.3
Why are we building kernels with this broken compiler? http://bugzilla.kernel.org/show_bug.cgi?id=8501 http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On 01/30/2008 03:54 PM, Jarod Wilson wrote: > On Wednesday 30 January 2008 03:47:26 pm Jarod Wilson wrote: >> On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: >>> On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > Roland, I don't suppose any of the recent changes I seem to recall > hearing you were going to make to debuginfo might have anything to do > with this... Seems unlikely since I haven't actually made any yet. >>> D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) >> Chuck figured it out. The output of file 4.23 when looking at unstripped >> binaries changed, which broke find-debuginfo.sh... :\ > > Okay, I should just go home. My head hurts like hell right now, and I can't > seem to get anything right... It seems the new file only has issues with .ko > files, other binaries it reports on as it always has. > Maybe this is because even after we strip out the debuginfo, file was reporting "not stripped", so someone decided to override that and always report them as stripped? I just used eu-unstrip to reassemble a module with the full debuginfo and file still doesn't say anything about it... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On 01/22/2008 01:47 PM, Chuck Ebbert wrote:
> awk '/^Patch.*:/ { print $1" %{_sourcedir}/"$2 }' %{_specdir}/%{name}.spec |
> while read num patch ; do
> optfield="$( echo $num | cut -f 1 -d : | tr [:lower:] [:upper:] )_OPTS"
> opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2 -d = )"
Should be this, just in case any option contains an "=":
opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2- -d =
)"
> [[ $opts == "SKIP" ]] && continue
> if ! ApplyPatch "$patch" $opts ; then
> set +x
> echo Failed to apply $(basename $patch).
> exit 1
> fi
> done || exit 1
>
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On 01/21/2008 05:22 PM, Adam Jackson wrote:
> http://people.freedesktop.org/~ajax/kernel-autopatch.patch
>
Using the below script, based on what you suggested, we can add lines like
this to specify patch options:
Patch101: a.patch
PATCH101_OPTS=-R -F2
And this to skip a patch:
Patch101: a.patch
PATCH101_OPTS=SKIP
With this change I'd say go for it.
awk '/^Patch.*:/ { print $1" %{_sourcedir}/"$2 }' %{_specdir}/%{name}.spec |
while read num patch ; do
optfield="$( echo $num | cut -f 1 -d : | tr [:lower:] [:upper:] )_OPTS"
opts="$( cat %{_specdir}/%{name}.spec | grep ^${optfield} | cut -f 2 -d = )"
[[ $opts == "SKIP" ]] && continue
if ! ApplyPatch "$patch" $opts ; then
set +x
echo Failed to apply $(basename $patch).
exit 1
fi
done || exit 1
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: UVESAFB in kernel 2.6.24
On 01/08/2008 09:30 AM, Mark wrote: > Hey, > > I just downloaded and installed the latest kernel rpm from koji [1] > but found out that uvesafb isn't enabled in the fedora kernels. Could > a kernel maintainer put the following value in the config-generc: > > CONFIG_FB_UVESA=y > > so that uvesafb is enabled in the next build? > more information about uvesafb can be found here [2]. > > Thanx, > Mark > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=30342 > [2] http://dev.gentoo.org/~spock/projects/uvesafb/ > I can actually see a use for this: debugging video BIOS code could be much easier. But who wwould maintain the v86d userspace code package if we enabled the driver? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Do recent kernels allow firmware to load at initrd time?
On 12/20/2007 10:47 AM, Chuck Murnane wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=329511 and > https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to > address failure of the kernel to load firmware in the initrd phase of > system booting. I can confirm that the second (aic94xx) bug, although it > results in a failure during boot, if followed by rmmod aic94xx and then > modprobe aic94xx results in firmware being properly loaded and the > system able to make use of disks attached to the controller. I can also > state that the nash find command locates the proper firmware file within > the initrd file system even though the kernel fails to locate it. This > takes place on a x86_64 system with both kernel-2.6.23.1-49.fc8 and > kernel-2.6.23.8-63.fc8 and mkinitrd-6.0.19-4.fc8 (I modified mkinitrd to > include the nash find command.) > > My question is: is firmware loading working for anyone with recent > Fedora kernels or is there some sort of bug in the kernel firmware > routines exercised only by an initrd file system? > See bug 378651; does the updated mkinitrd mentioned there work? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Automating build of stable kernel release candidates
There are some manual hacks in the kernel specfile now for building
stable release candidates. However, kernel 2.6.23.9-rc1 ends up being
released as 2.6.23.8-NN because we don't have a good way to change the
version. This update automates that; the only question is whether we
should label the built kernel as an -rc. I didn't add that part, and the
changes are untested:
--- kernel.spec 29 Nov 2007 00:25:06 - 1.279
+++ kernel.spec 29 Nov 2007 22:45:41 -
@@ -34,6 +34,15 @@
%if 0%{?released_kernel}
# Do we have a 2.6.21.y update to apply?
%define stable_update 9
+# Do we have a stable RC update to apply?
+%define stable_rc 0
+# Stable rc patches are incremental against the previous -stable
+# If this is an rc we need the previous stable patch too
+%if 0%{?stable_rc}
+%define stable_base %(expr %{stable_update} - 1)
+%else
+%define stable_base %{stable_update}
+%endif
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev .%{stable_update}
@@ -534,8 +543,12 @@
# Here should be only the patches up to the upstream canonical Linus tree.
# For a stable release kernel
-%if 0%{?stable_update}
-Patch00: patch-2.6.%{base_sublevel}.%{stable_update}.bz2
+%if 0%{?stable_base}
+Patch00: patch-2.6.%{base_sublevel}.%{stable_base}.bz2
+%endif
+%if 0%{?stable_rc}
+Patch01: patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2
+%endif
# non-released_kernel case
# These are automagically defined by the rcrev and gitrev values set up
@@ -1006,8 +1019,12 @@
# Update to latest upstream.
# released_kernel with stable_update available case
-%if 0%{?stable_update}
-ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}.bz2
+%if 0%{?stable_base}
+ApplyPatch patch-2.6.%{base_sublevel}.%{stable_base}.bz2
+%endif
+%if 0%{?stable_rc}
+ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2
+%endif
# non-released_kernel case
%else
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: i686 build on x86_64 fails
On 11/28/2007 03:29 AM, Pete Zaitcev wrote: > It's not important why stubs-32.h does not exist in glibc-headers. stubs-32.h is in glibc-devel on Fedora 6 and was apparently removed sometime after that. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
ALSA versions in the Fedora kernel
Here's a proposal for what version of ALSA we deliver with our kernel: Fedora 7 will stay with the version it has, 1.0.14, which is being maintained with stable patches by the ALSA team. Fedora 8 will stay with 1.0.15 and only merge carefully selected bug fixes from upstream ALSA. Fedora 9 / devel will track upstream ALSA development so we can shake out bugs as soon as possible. This can be done by carrying the git-alsa-mm patch from the -mm kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Install hang on a Dell PowerEdge SC1430
On 11/16/2007 09:00 AM, Steve Dickson wrote: > Are there known issues with F8 (and F7) being > installed on PowerEdges? Booting from DVD (and CDs) > I get the following three lines than nothing... > > Loading Vmlinuz > Loading initrd.img. > Read. > > This happens with both x86 and x86_64 installs > from DVD of either F8 or F7. I also tried burning > the boot.iso from the DVD to a CD and boot from > that with the same results. > > Being this is pretty broken, I'm hoping this is a known > problem and there is some type of workaround. > edd=skipmbr ?? If that fixes it, visit https://bugzilla.redhat.com/show_bug.cgi?id=379411 and add your report. (This bug was supposedly fixed before release but still seems to be present, just a lot less common than before.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Adding a pointrelease option to the spec
This might be useful for people building their own kernels:
--- kernel.spec 12 Nov 2007 22:05:50 - 1.237
+++ kernel.spec 13 Nov 2007 17:05:39 -
@@ -12,7 +12,16 @@
# that the kernel isn't the stock distribution kernel, for example,
# by setting the define to ".local" or ".bz123456"
#
+# You may also add a "pointrelease" with or without the "buildid"
+# so that your locally built kernel gets a version number that
+# is higher than the kernel it is based on and lower than the
+# next offical Fedora release.
+#
#% define buildid .local
+#% define pointrelease .1
+%if 0{?pointrelease}
+%define buildid {pointrelease}{?buildid}
+%endif
# fedora_build defines which build revision of this kernel version we're
# building. Rather than incrementing forever, as with the prior versioning
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
On 10/24/2007 02:13 PM, Dave Anderson wrote: > > > CONFIG_RELOCATABLE=y > > > CONFIG_PHYSICAL_ALIGN=0x40 > > > CONFIG_PHYSICAL_START=0x100 > > > > > > Address in oops was c04622db. > > > > > > I had to use "eu-addr2line -e vmlinux 0xc10622db" > > > > > > And objdump just flat refuses to show line number information > > > from vmlinux containing debug info. (But on Fedora 8 it will.) > > > > I vaguely recall seeing a bug about this one, and I thought the solution > > was to set _ALIGH and _START to the same value, but these are only vague > > recollections... > > If CONFIG_PHYSICAL_START is equal to or less than CONFIG_PHYSICAL_ALIGN > then all is well. > here's the bug report: https://bugzilla.redhat.com/show_bug.cgi?id=309751 [patch] kernel runs at different offset than compiled start ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
On 10/23/2007 06:28 PM, Dave Jones wrote: > > Are the addresses in System.map accurate? On the F7 2.6.23 kernel, > > I had to subtract 0x40 and add 0x100 to the address in an > > oops message to get an address to use with eu-addr2line. > > Relocatable kernel is another thing that really screws with this. > CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x40 CONFIG_PHYSICAL_START=0x100 Address in oops was c04622db. I had to use "eu-addr2line -e vmlinux 0xc10622db" And objdump just flat refuses to show line number information from vmlinux containing debug info. (But on Fedora 8 it will.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
On 10/23/2007 09:05 AM, Roland McGrath wrote: > The systemtap folks are interested in having System.map installed by > kernel-devel, not just by the kernel rpm itself. This makes it possible to > do more preparations off-line for a kernel other than an installed one. > > Without objection, I'll check this in on all branches. > Are the addresses in System.map accurate? On the F7 2.6.23 kernel, I had to subtract 0x40 and add 0x100 to the address in an oops message to get an address to use with eu-addr2line. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Building a kernel "--without debuginfo" is kind of broken
I got a 160MB kernel package and discovered that the kernel and
modules contained debug info. This seems to fix it, does anyone
see a problem with it?
make -s mrproper
cp configs/$Config .config
+%if !%{with_debuginfo}
+perl -p -i -e 's/^CONFIG_DEBUG_INFO=y$/# CONFIG_DEBUG_INFO is not set/'
.config
+%endif
Arch=`head -1 .config | cut -b 3-`
echo USING ARCH=$Arch
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Vacation
On 10/17/2007 10:30 AM, Christopher Brown wrote: > Hi folks, > > As per http://fedoraproject.org/wiki/Vacation I'm away for a little under a > month from tomorrow, pretty much out of contact. I have been through most of > the Fedora 7 kernel bugs and will resume these duties on my return. I hope I > have been of some help but for now, Australia awaits! > You deserve a break after the great work you've been doing. Have fun! ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Fun with ALSA
We should consider carrying the latest ALSA patchset in Fedora. That way we wouldn't be forever chasing bugs they have already fixed... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Fedora 6/7 kernel update plans
Fedora 6: leave on 2.6.22 until end-of-life There are so many workarounds and backwards-compatibility issues in there that it just doesn't seem worthwhile to upgrade. Fedora 7: update to 2.6.23 after Fedora 8 is released May as well update, the issues aren't nearly so great and users will probably want the latest kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling Secure Computing (SECCOMP)
On 09/19/2007 04:30 PM, Roland McGrath wrote: >> The reasons against it in the past were that it slowed down >> the common case (people who aren't using the feature) > > It doesn't look like it should. > With the latest patches in 2.6.23 it looks like the overhead is just about zero, so I enabled it on the principle that we basically enable everything we possibly can... And I wish more people would look at using it for untrusted code, e.g. a JPEG decoder could run in the "jail" and it couldn't cause any harm even if someone managed to exploit it. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Enabling Secure Computing (SECCOMP)
We have a bug report requesting that we enable SECCOMP: https://bugzilla.redhat.com/show_bug.cgi?id=295841 I suggest we enable it in Fedora 8 but leave it disabled in F7. That way we're not changing a config item in a stable release, and we don't have to carry patches to lower the feature's overhead and make its API match 2.6.23's. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
New kernel option in F8/devel: libata.pata_dma
I just checked in a patch from Alan that allows selectively disabling DMA on libata PATA drives: libata.pata_dma= [LIBATA] libata.pata_dma=0 Disable all PATA DMA like old IDE libata.pata_dma=1 Disk DMA only libata.pata_dma=2 ATAPI DMA only libata.pata_dma=4 CF DMA only These can be combined, e.g. libata.pata_dma=3 will enable DMA on disks and ATAPI devices (mainly CD-ROM) while leaving it disabled on Compact Flash. This should allow installation on systems where DMA doesn't work, so the problem can be fixed later by a kernel update. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: The NFS "nosharecache" patch in F7 is broken
On 08/22/2007 11:36 AM, Steve Dickson wrote: >>> Just curious... What are the differences in the mounts options that >>> is causing this new check to pop, which in turn is failing the mount? >> >> In at least one case it is read-only vs. read-write. > This should not make the check pop... > >> User mounts something from the server read-only, then mounts selected >> exports from the same filesystem read-write on top of that. > The check looks for difference protocols, I/O sizes, or cache timeouts > so there has to be something other ro/rw that is causing the > mounts to fail... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253530 This may be some other problem, user changed to r/w and the problem went away: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250271 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: The NFS "nosharecache" patch in F7 is broken
On 08/22/2007 11:18 AM, Steve Dickson wrote: > > > Dave Jones wrote: >> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >> > If people try mounting several exports from the same filesystem, it >> fails >> > with confusing error messages if the mount options are different >> for some >> > of the mount points. Adding "nosharecache" to the mount options >> fixes that, >> > but people with working setups suddenly find they need this new >> option to >> > use a setup that used to work without it. Should we just revert >> that patch? > Just curious... What are the differences in the mounts options that > is causing this new check to pop, which in turn is failing the mount? In at least one case it is read-only vs. read-write. User mounts something from the server read-only, then mounts selected exports from the same filesystem read-write on top of that. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: The NFS "nosharecache" patch in F7 is broken
On 08/21/2007 12:14 PM, Steve Dickson wrote: > > > Dave Jones wrote: >> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >> > If people try mounting several exports from the same filesystem, it >> fails >> > with confusing error messages if the mount options are different >> for some >> > of the mount points. Adding "nosharecache" to the mount options >> fixes that, >> > but people with working setups suddenly find they need this new >> option to >> > use a setup that used to work without it. Should we just revert >> that patch? > Thats been the million dollar question lately... there has been quite a > bit of complaints about this patch... but note the check does do some > correct sanity checking so the changes it point would be a good > thing to do > > But with that said, I would if making it a warning first, giving > people time to clean up their setups and then making it an > error later on... > Can't it be made to automatically set the nosharecache flag if it's needed? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
The NFS "nosharecache" patch in F7 is broken
If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Bug 250377: External modules of removed kernels are not removed
On 08/14/2007 04:43 PM, Jarod Wilson wrote: > > I will! I think it could be a Good Thing or at least a Useful Thing for > both kmod packages and dkms payloads. Of course, I also see the > potential for abuse here... Sketchy kmods or dkms payloads could > potentially wreak havoc on kernel installs if they cause a hang or failure. > That's what scares me about the whole idea. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Bugzilla Bug 250377: External modules of removed kernels are not removed
Is anyone looking at this? The basic proposal is to create /etc/kernel/preinst.d and /etc/kernel/postinst.d directories and let external packages drop scripts in there that get called on every kernel install. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
On 08/14/2007 03:48 PM, Jarod Wilson wrote: > > Ya got me, but upon unpacking the initrd, modinfo tells me the bits in > the initrd have the right vermagic. However, the file sizes don't match. > In fact, they aren't even close. > > # (cd /tmp/initrd-104/lib; ll ext3.ko) > -rw--- 1 root root 189096 2007-08-14 15:31 ext3.ko > > # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) > -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko > Looks like one has the debug info in it and the other doesn't. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Trying to add s390 arch build back to FC-6 failed
On 08/09/2007 06:13 PM, Eduardo Habkost wrote: > On Thu, Aug 09, 2007 at 06:05:35PM -0400, Chuck Ebbert wrote: >> What did I miss? >> >> Not only did I not get s390 to build, somehow I broke s390x as well. >> It doesn't even submit the build jobs... > > The only problem is that the build jobs for s390 aren't even starting > anymore, or is it failing in other ways? > > If I understdood correctly, s390 was removed from the FC-6 buildroot > arch list on Brew today. So probably s390 won't build anymore. It seems > that it was supposed to be disabled a long time ago. Well I guess the headers aren't needed anymore then. Never mind. :) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Trying to add s390 arch build back to FC-6 failed
What did I miss?
Not only did I not get s390 to build, somehow I broke s390x as well.
It doesn't even submit the build jobs...
Index: kernel-2.6.spec
===
RCS file: /cvs/dist/rpms/kernel/FC-6/kernel-2.6.spec,v
retrieving revision 1.3003
retrieving revision 1.3004
diff -u -r1.3003 -r1.3004
--- kernel-2.6.spec 9 Aug 2007 21:01:34 - 1.3003
+++ kernel-2.6.spec 9 Aug 2007 21:26:49 - 1.3004
@@ -20,7 +20,7 @@
# kernel spec when the kernel is rebased, so fedora_build automatically
# works out to the offset from the rebase, so it doesn't get too ginormous.
%define fedora_cvs_origin 2968
-%define fedora_build %(R="$Revision: 1.3003 $"; R="${R%% \$}"; R="${R##: 1.}";
expr $R - %{fedora_cvs_origin})
+%define fedora_build %(R="$Revision: 1.3004 $"; R="${R%% \$}"; R="${R##: 1.}";
expr $R - %{fedora_cvs_origin})
# base_sublevel is the kernel version we're starting with and patching
# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
@@ -247,7 +247,7 @@
%endif
# don't sign modules on these platforms
-%ifarch s390x sparc sparc64 ppc alpha
+%ifarch s390 s390x sparc sparc64 ppc alpha
%define with_modsign 0
%endif
@@ -280,6 +280,13 @@
%define hdrarch powerpc
%endif
+%ifarch s390
+%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{version}-s390.config
+%define image_install_path boot
+%define make_target image
+%define kernel_image arch/s390/boot/image
+%endif
+
%ifarch s390x
%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{version}-s390x.config
%define image_install_path boot
@@ -396,7 +403,7 @@
Release: %{pkg_release}
# DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN
ARCHITECTURE BUILD.
# SET %nobuildarches (ABOVE) INSTEAD
-ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x
alpha alphaev56
+ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390
s390x alpha alphaev56
ExclusiveOS: Linux
Provides: kernel-drm = 4.3.0
Provides: kernel-drm-nouveau = 6
@@ -449,7 +456,8 @@
Source30: kernel-%{version}-ppc64.config
Source31: kernel-%{version}-ppc64-kdump.config
-Source35: kernel-%{version}-s390x.config
+Source35: kernel-%{version}-s390.config
+Source36: kernel-%{version}-s390x.config
Source36: kernel-%{version}-ia64.config
@@ -2263,6 +2271,10 @@
%changelog
* Thu Aug 09 2007 Chuck Ebbert <[EMAIL PROTECTED]>
+- hopefully add s390 back to the build
+ (ugly hack, s390 overrides s390x, no -generic used)
+
+* Thu Aug 09 2007 Chuck Ebbert <[EMAIL PROTECTED]>
- disable CONFIG_SCSI_SCAN_ASYNC
* Thu Aug 09 2007 Chuck Ebbert <[EMAIL PROTECTED]>
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: MSI and MMCONFIG, again...
On 08/08/2007 10:50 PM, Dave Jones wrote: > On Wed, Aug 08, 2007 at 01:41:57PM -0400, Chuck Ebbert wrote: > > On 08/08/2007 01:28 PM, Prarit Bhargava wrote: > > >> We are still hitting problems with MSI (and probably mmconfig) > > >> with kernel 2.6.22: > > >> > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 > > >> > > >> Should we just go back to disabling these by default? > > >> > > > > > > Chuck -- how long have we had this re-enabled? What about (groan) doing > > > quirks for msi/mmconfig? > > > > > > > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. > > > > And there are quirks in there now, I guess the list just isn't complete > > (and probably never can be.) > > Weren't there other newer devices that need MSI on ? > Some of the infiniband stuff maybe? > > As painful as it is, additional quirks would be the best all-round > solution I think. > I think it would be best to turn MSI off in FC6, where it's already been off for a long time anyway. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
New Intel e1000 device support
I just put Intel's latest cut at ICH9 e1000 support into rawhide, removing the preliminary hack that backported the support into the old driver. Since this new one *only* supports ICH9, it looks pretty safe to put it into Fedora 6 and 7 as well. Comments? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Should we just build the pcspkr driver into the X86 kernels?
On 08/08/2007 02:59 PM, Bill Nottingham wrote: > Chuck Ebbert ([EMAIL PROTECTED]) said: >>> No! Evil. Unless there's some way to disable it when it's built in. >> Okay 2-1 so far. >> >> I think it should be added to /etc/sysconfig/modules > > Has any one actually diagnosed how it got loaded before, and why > that stopped working? I gave up trying to figure that one out. Jeff Garzik says it never did work for him; others have reported it worked on i386 but not on x86_64. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Should we just build the pcspkr driver into the X86 kernels?
On 08/08/2007 02:43 PM, Josh Boyer wrote: > On Wed, 8 Aug 2007 14:21:46 -0400 > Bill Nottingham <[EMAIL PROTECTED]> wrote: > >> Chuck Ebbert ([EMAIL PROTECTED]) said: >>> The pcspkr driver doesn't load automatically any more with kernel >>> 2.6.22. >>> >>> Should we build it in, or maybe add it to the list of drivers that >>> always get loaded? >> Lists are bad - just build it in. > > No! Evil. Unless there's some way to disable it when it's built in. Okay 2-1 so far. I think it should be added to /etc/sysconfig/modules ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Should we just build the pcspkr driver into the X86 kernels?
The pcspkr driver doesn't load automatically any more with kernel 2.6.22. Should we build it in, or maybe add it to the list of drivers that always get loaded? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: MSI and MMCONFIG, again...
On 08/08/2007 01:28 PM, Prarit Bhargava wrote: >> We are still hitting problems with MSI (and probably mmconfig) >> with kernel 2.6.22: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 >> >> Should we just go back to disabling these by default? >> > > Chuck -- how long have we had this re-enabled? What about (groan) doing > quirks for msi/mmconfig? > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. And there are quirks in there now, I guess the list just isn't complete (and probably never can be.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
MSI and MMCONFIG, again...
We are still hitting problems with MSI (and probably mmconfig) with kernel 2.6.22: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 Should we just go back to disabling these by default? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kqemu inclusion in kernel
On 08/02/2007 02:20 PM, dragoran wrote: > > well but kqemu seems not to break that often I just recompile it after each > kernel release and it just works. > the code might be big but it does not depend on (fast) changing interfaces. > Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Who decides what drivers go on the install disk?
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Kernel Prerequisites?
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249587 Some users need mdadm to build an initrd. Others might need a new release of cpuspeed (if they use it.) We don't require those packages because not all users will need them, AFAICT -- it depends on what features they use. Should we require all of the packages that might be needed? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora Core 6 Test Update: kernel-2.6.22.1-15.fc6
On 07/19/2007 01:47 PM, KH KH wrote: > Hello! > > Actually this updated kernel contains the juju firewire... > This will bring some regression, as state here: > https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00843.html > > For example,here is what i wouln't like to see rising for FC-6 also... > http://www.ezplanetone.com/xwiki/bin/view/KnowledgeBase/BrokenFC7FireWire > > Is it possible to prevent thoses regression from appearing into FC-6 ? > If not, this may break many userland applications... Another kernel is building now with the old stack instead of the new one. It also has the libata combined mode option restored. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] Switch to including config-* instead of kernel-*.config
On 07/12/2007 12:36 PM, Dave Jones wrote: > On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: > > I'm going to assume you're asking "why doesn't davej like that idea", > > since the mv desire is probably obvious (compliance w/packaging > > standards). Basically, because cvs sucks, and all revision history goes > > bye-bye if we do the move. Though really... Dave, how big a deal is that > > really if we do it this early in rawhide? You can always go to the attic > > if you *really* need to see some historical info on the spec, and we'll > > have plenty built back up by the time we get to F8... > > Probably not so big a deal if we do it right now I guess. > It's been handy in the past for "it broke somewhere between 1.2345 and > 1.2367", but tbh now that we have sensible versioning, that at least > partially solves that probably without the need for cvs annotate. > > Feel free to rename it, but be sure to fix up all the scripts/makefiles too. Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] Switch to including config-* instead of kernel-*.config
On 07/11/2007 01:37 PM, Jarod Wilson wrote: > The attached patch switches the kernel rpm over from including the > current static kernel-*.config files to instead including the config-* > files that are actually in cvs. > > It means we don't leave kernel-*.config droppings all over the place > (following a rebase, its entirely too easy to end up with > kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, > which can sometimes cause odd things to happen), and we don't modify > SOURCE files in %prep (see bug 232602), which could otherwise result in > repacking an srpm with the same n-v-r with different kernel-*.config > files. As a bonus, along the way, this cleans up a number of rpmlint > warnings (though there are still a TON to poke at). > > In the future, this would also make life easier for the RHEL6 and later > maintainers, as we typically prefer config changes against the config-* > files, rather than against the kernel-*.config files, but (most) non-rh > folks don't have cvs access to get at the config-* files right now. > > Thus far, the only real downside is that it requires moving all the > config-* files up to the root of the kernel cvs dir, which is 1) a bit > messy and 2) results in losing prior versioning history on those files, > since cvs blows. > 1) No big deal, though. 2) There's not much relevant history in there anyway. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: cpuspeed und cpuidle
On 07/11/2007 12:48 PM, Jarod Wilson wrote: > I submitted a push request for the FC6 update I did w/the other pre-F7 > update system, but haven't got any notice about it being pushed just > yet. I'll ping someone in rel-eng. > > Can't wait for FC-6 to die now, so we don't have two different ways of > doing things (er, make that three w/the RHEL stuff I do too)... > Not until December... I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package. (And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: cpuspeed und cpuidle
On 07/11/2007 12:35 PM, Jarod Wilson wrote: >> > Cpuspeed afaics needs an adjustment if cpuidle stays: >> > >> > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart >> > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: >> /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or >> directory >> > /etc/init.d/cpuspeed: line 213: >> /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or >> directory >> >[ OK ] >> > /etc/init.d/cpuspeed: line 62: >> /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or >> directory >> > Enabling ondemand cpu frequency scaling: [ OK ] >> >> Jarod checked a fix in a day or so ago, might be working its way through >> koji somewhere. > > Yep, it was sitting for a day or two waiting for someone to notice my > bodhi push request. It just got pushed over to stable updates a few > hours ago. Fedora 6 too? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.22 rebase.
On 07/11/2007 01:23 AM, Dave Jones wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > Problems start to appear when the hpet stuff for x86_64 went it, and did > > not vanish when you disabled the forced-hpet for some of the recent > > ICH's from Intel (which afaics [would need the lspci data to be sure] > > are in both our machines). > > > > /me will later update the bug with the lspci output when I'm in front of > > my laptop again. > > Yeah, I'm picking over that bug now. Will try and find a box I can > reproduce this on tomorrow. The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet". AND it requires a version of mkinitrd (6.something) that's not available for Fedora 6. (I installed with --nodeps and it seems okay but there's no 'symvers' file in /boot/grub for the new kernel.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: how kernel distinguish threads
On 07/09/2007 06:29 PM, Feng Xian wrote: > Hi, I am working on a project about reducing page faults of multi-threaded > programs. I am using latest Fedora core (Linux 2.6) and pthread library. In > this project, each user-level thread (created by pthread_create() > function) > needs to pass a value to the task structure in the kernel which corresponds > to the thread. The first step is getting a unique id of the task structure > of each thread. But what is this unique id? > > I tried to use getpid() to get the process id of each thread and use it as > unique id. But this didnt work out since all threads in a process share the > same pid. I tried to use the thread_id returned by pthread_create() > function > but this id is meaningless to the kernel. Could anyone help me out on this? Use gettid() ?? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Removing atomic.h from Fedora kernel headers
On 06/24/2007 03:25 PM, David Woodhouse wrote: > On Fri, 2007-06-22 at 16:36 -0400, Chuck Ebbert wrote: >> Why do we explicitly remove atomic.h from our kernel header package? > > No reason any more. Once upon a time, before the cleanup of the upstream > kernel's exports was complete, we needed to remove this unwanted crap. > > These days, the kernel's standard 'make headers_install' doesn't include > it anyway, so we no longer need to strip it out for ourselves. I dug through the makefiles to try and figure out if that was true, but gave up. Where is the list of included and/or excluded files? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kmods poll
On 06/20/2007 11:12 AM, Josh Boyer wrote: > >> And if it isn't good enough for upstream to ship and support, why in >> $DEITY's name would we want to ship it, again? > > *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen > *cough* > ... exec-shield ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kmods poll
On 06/19/2007 04:01 PM, Josh Boyer wrote: > I'd like to just do a brief poll here just to see how many are yay or > nay for kmods. And I'm not talking about their current implementation > or the other various ways that the idea can be accomplished, but rather > on the idea of having kernel modules as separate packages in general. > > If you're against the general idea and want to follow up with reasons > why that's fine. I just want to avoid implementation discussions at the > moment if possible. > Necessary evil. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
CONFIG_USB_SUSPEND
[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] (In reply to comment #5) > We can do two things > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without >changing anything else, see if that helps, and I think we need this anyway. There are devices that require quirks to work with it enabled, and we'll be forever chasing those if we leave it that way. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: fedora kernel utrace updates
On 06/11/2007 05:40 PM, Roland McGrath wrote: > Right now the backport series have some fixes not in update kernels. I > haven't done very exhaustive testing after the fresh backport work, so > there might be some regression there and I wouldn't push those before I get > some folks to do more testing. If you aren't pushing an update real soon > anyway, now would be a good time to commit and do some unreleased builds I > can have people test. > In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel out but really want to get this update in. If it's broken I can revert. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: fedora kernel utrace updates
On 06/11/2007 04:46 PM, Roland McGrath wrote: > I've started using quilt to maintain backport versions of my utrace patches. > http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and > 2.6.20.11 (for FC-6). Done this way it is easy for me to plop in the new > utrace/ptrace code from the bleeding edge version when I have fixes, without > repeating the backport work, which is confined to the earlier patches in the > series. > > Since quilt doesn't have a handy feature for generating a single patch, and > I know better than to trust combinediff, I'd like to switch the Fedora > update kernels to using the broken out patches separately in the spec file. > If one were actually trying to keep track, this also makes it a little > easier to follow the changed patches in cvs, since there will be less > flutter around parts that aren't actually changing. > 'quilt snapshot' can be used to make combined patches, but I prefer the separate patches anyway. For FC6 I'd prefer to do the commits; if you'd notify us when you make a change that would help. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: where to get KDB debugger for FC6
On 05/29/2007 02:06 PM, kathy pu wrote: > Hello Everybody: > > Just wondering if FC6 supports KDB. If not, would like to know the > current status andhow to get it and port it? > > My great appreciation. > I think Keith Owens keeps it updated: ftp://oss.sgi.com/www/projects/kdb/download/v4.4 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: F7 redux, and the road to F8.
On 06/07/2007 03:39 PM, Bill Nottingham wrote: > >> Xen. >> >> This might get interesting to watch for F8 if XenU gets upstream >> (Which akpm seems to suggest it might). Given we've decoupled >> kernel/kernel-xen, we might want to just disable the upstream variant >> until F9, and wait until we have both the dom0 and the domU stuff >> coming from the same pieces. Will need more discussion with >> the virtualisation team when that lands in Linus' tree. > > As it's decoupled, exactly how much pain are we running into with > various fixes (PATA/SATA, suspend, etc., etc.) not being consistent? > Xen is on kernel 2.6.20, which means they need to track the FC6 updates. Apparently they're not -- AFAICT from a quick look at CVS, they shipped kernel 2.6.20.3, while current FC6 is 2.6.20.11 plus additional patches. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: questions on reconfigure and re-install a kernel on FC6
On 05/25/2007 04:15 PM, kathy pu wrote: > My machine already has 2.6.20.2948 installed, and I want to change the > kernel configuration, > I am not sure what directory the source code, and .config, that I should > use. > Start here: http://fedoraproject.org/wiki/Docs/CustomKernel ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: willing to contribute - so laptops suspend better - but how?
On 05/24/2007 02:51 PM, Valent Turkovic wrote: > On 5/24/07, Valent Turkovic <[EMAIL PROTECTED]> wrote: >> On 5/24/07, John bowden <[EMAIL PROTECTED]> wrote: >> > On Thursday 24 May 2007 13:08:32 Valent Turkovic wrote: >> > > On 5/24/07, Gianluca Sforna <[EMAIL PROTECTED]> wrote: >> > > > On 5/24/07, Valent Turkovic <[EMAIL PROTECTED]> wrote: >> > > > > I would like to help troubleshoot my laptop and then other 10 >> I have >> > > > > access to but I can't find how to do that. >> > > > > >> > > > > Is there any wiki page or some other resource that I can use? >> Or can >> > > > > you look at this one and give me some specific pointers? >> > > > >> > > > Try here: >> > > > http://people.freedesktop.org/~hughsient/quirk/ >> > > >> > > Been there, done that - no honey :) >> > > >> > > Does fedora community have some more resourceful page regarding >> > > suspend/resume on laptops? >> > > >> > > When I had the same issue with the same laptop I was blown away with >> > > OpenSuse page - http://en.opensuse.org/S2ram - they hit nail on the >> > > head with their wiki page IMHO. >> > > >> > > Fedora needs more online resources - quirks page is not sufficient. >> > > >> > > Valent from Croatia. >> > >> > Don't know if this is of any help as I'm trying to get my touch pad >> working my >> > note book is a similar model. >> > http://www.red-web.ro/ics/f7-on-HP500.html >> > >> >> I must say Fedora 7 test 4 works just great in other respects on my >> laptop - seams you have much more problems. Ok, my wireless iwl3945 >> doesn't work (I filed a bug also for that) but I can make it work with >> few commands... but suspend/resume I can't make to work no matter what >> I try. >> >> Valent. >> > Ok, it seams I have some bios problem issues! > > I wen't back to OpenSuse 10.2 in which I claimed suspend works - and > it did work before - now it doesn't work anymore! > > I had to upgrade my bios in order to get Intel VT option in bios - and > that FINALLY enabled me to run Xen virtualisation! But it seams that > this new bios now has some other issues so not even OpenSuse which > worked doesn't now :( > > First time I tried to suspend under OpenSuse 10.2 it freezed, and > second time it started to wakeup but some really strange noises came > from the HDD that FREAKED me out! I powered it off as soon as possible > - and everything worked fine on power up! > > Do you have any information, does Intel virtualisation have any thing > to do with suspend/resume? Does it need to be disabled in order for > suspend/resume to work? Try unloading the kvm and kvm-intel modules before suspending. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Latest updates to the FC7 kernel
Thomas Gleixner wrote: >>> >> It gets stranger. "notsc" and "clocksource=acpi_pm" don't >> prevent the freezes and the tsc syncronization messages still >> appear. Freezes are random and just hitting any key makes it >> continue. > > Hmm. This is racking my nerves. 3 bugs closed and a new opened. > > Chuck, is there a chance to bisect the changes on top of 2.6.21? > > http://tglx.de/private/tglx/hrtimer-fixups.tar.bz2 > Note this is the Test4 Live CD with an older kernel, that's why I asked what those patches fixed. And I can't test with the latest stuff unless I install to the hard drive. It stalled on every line during shutdown scripts; I had to keep pressing keys. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Latest updates to the FC7 kernel
dragoran wrote: >> >> "notsc" worked. But it should not even be trying to use the TSC. >> (System is an AMD Turion 64 x2 notebook.) >> >> > ok so this change did broke something... > > It gets stranger. "notsc" and "clocksource=acpi_pm" don't prevent the freezes and the tsc syncronization messages still appear. Freezes are random and just hitting any key makes it continue. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Latest updates to the FC7 kernel
dragoran wrote: >>> >>> I just tried the Test4 Live CD and it locked up after this: >>> >>> Clocksource tsc unstable (delta = 14060692691 ns) >>> >>> >> >> Even stranger, pressing ctrl-alt-del caused a clean shutdown >> (synchronized SCSI caches etc.) >> >> So it was just stuck there, not really locked up. >> >> > does notsc help? > "notsc" worked. But it should not even be trying to use the TSC. (System is an AMD Turion 64 x2 notebook.) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Latest updates to the FC7 kernel
Chuck Ebbert wrote: > Chuck Ebbert wrote: >> * Wed May 02 2007 Dave Jones <[EMAIL PROTECTED]> >> - Assorted dyntick/clock/timer fixes. >> > > What do these fix? > > I just tried the Test4 Live CD and it locked up after this: > > Clocksource tsc unstable (delta = 14060692691 ns) > Even stranger, pressing ctrl-alt-del caused a clean shutdown (synchronized SCSI caches etc.) So it was just stuck there, not really locked up. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
