From jacliburn at bellsouth.net Mon Apr 2 00:04:39 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 1 Apr 2007 19:04:39 -0500 Subject: Kernel oops 2.6.20-2925.5.fc7xen Message-ID: <20070401190439.6f772756@osprey.hogchain.net> Are there any Fedora Xen kernel gurus reading this list? I'm trying to get my head around a problem reported by one of our atl1 (network driver) users. I can duplicate his problem. It happens when we load the atl1 module while running 2.6.20-2925.5.fc7xen. Here's the oops: Unable to handle kernel paging request at ffff880382180ae8 RIP: [] swiotlb_map_page+0x54/0x125 PGD 1100067 PUD 0 Oops: 0000 [1] SMP last sysfs file: /class/net/eth0/address CPU 0 Modules linked in: atl1 mii i915 drm netloop netbk blktap blkbk ipt_MASQUERADE iptable_nat nf_nat xt_physdev bridge w83627ehf hwmon i2c_isa eeprom nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 ipt_LOG ipt_recent iptable_filter ip_tables ip6t_LOG nf_conntrack_ipv6 xt_state nf_conntrack nfnetlink xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 video sbs i2c_ec dock button battery asus_acpi backlight ac parport_pc lp parport snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss i2c_i801 i2c_core snd_pcm serio_raw snd_timer snd iTCO_wdt iTCO_vendor_support pcspkr soundcore snd_page_alloc shpchp sr_mod cdrom floppy sg dm_snapshot dm_zero dm_mirror dm_mod ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Pid: 2710, comm: ip Not tainted 2.6.20-2925.5.fc7xen #1 RIP: e030:[] [] swiotlb_map_page+0x54/0x125 RSP: e02b:ffff880019f2bd28 EFLAGS: 00010246 RAX: 7fffffffffffffff RBX: ffff880000f4c070 RCX: 000000007003975d RDX: ffff880001fb5000 RSI: ffff881881f6ec58 RDI: 0000000000000012 RBP: 0000000000000002 R08: 0000000000000002 R09: ffff88002ba8a580 R10: ffff880038383780 R11: 00000000000000d0 R12: 00000000000005f0 R13: ffff88002ba8a880 R14: 0000000000000000 R15: ffff88002ba8a580 FS: 00002aaaaaac6820(0000) GS:ffffffff80579000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000019d24000 CR4: 0000000000002620 Process ip (pid: 2710, threadinfo ffff880019f2a000, task ffff880026a73080) Stack: ffff88002ba8a880 0000000000000000 ffff880019f99000 ffff880019db1800 0000000000000001 ffffffff883d2be0 ffff880019f99000 ffff88002ba8a000 ffff880000f4c000 00000000fffffff4 ffff88002ba8a580 ffff88002ba8a000 Call Trace: [] :atl1:atl1_alloc_rx_buffers+0x180/0x220 [] :atl1:atl1_up+0x2f/0x660 [] :atl1:atl1_open+0x2b/0x60 [] dev_open+0x2f/0x6e [] dev_change_flags+0x5a/0x11a [] devinet_ioctl+0x235/0x59c [] __might_sleep+0x26/0xd0 [] sock_ioctl+0x1c8/0x1e5 [] do_ioctl+0x21/0x6b [] vfs_ioctl+0x25c/0x275 [] sys_ioctl+0x59/0x78 [] tracesys+0xb2/0xb7 Code: 48 8b 14 ca 48 21 c2 48 c1 e2 0c 48 85 db 48 8d 04 3a 74 11 RIP [] swiotlb_map_page+0x54/0x125 RSP CR2: ffff880382180ae8 <3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 Call Trace: [] down_read+0x15/0x23 [] acct_collect+0x42/0x18e [] do_exit+0x200/0x809 [] do_page_fault+0x129c/0x134b [] link_path_walk+0xc5/0xd7 [] __rmqueue+0x50/0xf9 [] error_exit+0x0/0x6e [] swiotlb_map_page+0x54/0x125 [] :atl1:atl1_alloc_rx_buffers+0x180/0x220 [] :atl1:atl1_up+0x2f/0x660 [] :atl1:atl1_open+0x2b/0x60 [] dev_open+0x2f/0x6e [] dev_change_flags+0x5a/0x11a [] devinet_ioctl+0x235/0x59c [] __might_sleep+0x26/0xd0 [] sock_ioctl+0x1c8/0x1e5 [] do_ioctl+0x21/0x6b [] vfs_ioctl+0x25c/0x275 [] sys_ioctl+0x59/0x78 [] tracesys+0xb2/0xb7 I'm pretty sure what's happening is that swiotlb -- apparently used by Xen to do IO memory mapping -- doesn't like pci_map_page(). Here's the driver code snippet that does the dma mapping for our receive buffers: static u16 atl1_alloc_rx_buffers(struct atl1_adapter *adapter) { [snip} skb_reserve(skb, NET_IP_ALIGN); skb->dev = netdev; buffer_info->alloced = 1; buffer_info->skb = skb; buffer_info->length = (u16) adapter->rx_buffer_len; page = virt_to_page(skb->data); offset = (unsigned long)skb->data & ~PAGE_MASK; buffer_info->dma = pci_map_page(pdev, page, offset, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); rfd_desc->buffer_addr = cpu_to_le64(buffer_info->dma); rfd_desc->buf_len = cpu_to_le16(adapter->rx_buffer_len); rfd_desc->coalese = 0; [snip] } The Xen kernel seems to work okay if I change pci_map_page() to pci_map_single(), but there are other dma mappings in the code that seem to /need/ pci_map_page(). (We inherited this driver from the vendor, BTW.) Should swiotlb_map_page() work? I can't even /find/ the function in 2.6.21-rc5 (non-xen). Thanks, Jay From cebbert at redhat.com Mon Apr 2 15:29:42 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 02 Apr 2007 11:29:42 -0400 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <20070329132406.GB11824@unplugged.rdu.redhat.com> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> Message-ID: <46112166.8010304@redhat.com> Sam Folk-Williams wrote: > Hi, > > I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a > while back that we remove the building instructions from the release notes and > put those in a separate doc devoted to more detailed instructions on building > the kernel RPM (including applying patches and configuring options). > > I've got a draft doc now. I come to this from a support perspective - building > kernels with patches I get from Engineering to pass on for testing. I'd like to > get the point of view of some kernel developers as well. > > - Is what's here correct? > - Is there more that should be here? > - Does the info here conform to best practices? > > Any feedback appreciated. I am happy to make edits myself if you reply, or of > course any one can make edits on their own. > > http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel > When copying the kernel tree, the second copy should be: cp -alv ~/rpmbuild/redhat/kernel-2.6.x.orig ~/rpmbuild/redhat/kernel-2.6.x.new this will hardlink the original and new trees so diff will run much faster. Hardlinks should not present a problem because text editors know how to break them -- Midnight Commander now asks, so maybe a note telling people about the hardlinks could be added there as well. From cebbert at redhat.com Mon Apr 2 18:05:54 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 02 Apr 2007 14:05:54 -0400 Subject: Putting the full unstripped modules in the kernel-debuginfo package Message-ID: <46114602.4090500@redhat.com> Right now we package the debuginfo so it contains only the DWARF debug information, but some utilities can't work with that. If we put the full modules with debug info in the package then everything should work, at the cost of making the package about 14MB larger. Is there any reason not to do this? (i686 debuginfo is about 175MB now.) From jwboyer at jdub.homelinux.org Mon Apr 2 18:20:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Apr 2007 13:20:28 -0500 Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: <46114602.4090500@redhat.com> References: <46114602.4090500@redhat.com> Message-ID: <1175538028.32658.47.camel@vader.jdub.homelinux.org> On Mon, 2007-04-02 at 14:05 -0400, Chuck Ebbert wrote: > Right now we package the debuginfo so it contains only the > DWARF debug information, but some utilities can't work with > that. If we put the full modules with debug info in the > package then everything should work, at the cost of making > the package about 14MB larger. Is there any reason not to > do this? (i686 debuginfo is about 175MB now.) Which utilities don't work with just DWARF by the way? josh From cebbert at redhat.com Mon Apr 2 18:40:40 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 02 Apr 2007 14:40:40 -0400 Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: <1175538028.32658.47.camel@vader.jdub.homelinux.org> References: <46114602.4090500@redhat.com> <1175538028.32658.47.camel@vader.jdub.homelinux.org> Message-ID: <46114E28.8070202@redhat.com> Josh Boyer wrote: > On Mon, 2007-04-02 at 14:05 -0400, Chuck Ebbert wrote: >> Right now we package the debuginfo so it contains only the >> DWARF debug information, but some utilities can't work with >> that. If we put the full modules with debug info in the >> package then everything should work, at the cost of making >> the package about 14MB larger. Is there any reason not to >> do this? (i686 debuginfo is about 175MB now.) > > Which utilities don't work with just DWARF by the way? > objdump for one - I can't get a mixed source/disassembly listing for modules. This makes debugging oopses inside of modules a lot harder than it needs to be. From roland at redhat.com Mon Apr 2 20:13:25 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Apr 2007 13:13:25 -0700 (PDT) Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: Chuck Ebbert's message of Monday, 2 April 2007 14:05:54 -0400 <46114602.4090500@redhat.com> Message-ID: <20070402201325.B6526180064@magilla.sf.frob.com> I'm not positive everything will work, i.e. systemtap et al that do deal with separate debuginfo properly now. We could test it. OTOH, it may take less time than mucking with the build and testing the results for me to write an "unstrip" to paste together what was separated at build time. And that kludge is more of an explicit kludge rather than yet more obscure weirdness because of tool inadequacies that will eventually go away. Thanks, Roland From cebbert at redhat.com Mon Apr 2 22:54:42 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 02 Apr 2007 18:54:42 -0400 Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: <20070402201325.B6526180064@magilla.sf.frob.com> References: <20070402201325.B6526180064@magilla.sf.frob.com> Message-ID: <461189B2.4030807@redhat.com> Roland McGrath wrote: > I'm not positive everything will work, i.e. systemtap et al that do deal > with separate debuginfo properly now. We could test it. OTOH, it may take > less time than mucking with the build and testing the results for me to > write an "unstrip" to paste together what was separated at build time. And > that kludge is more of an explicit kludge rather than yet more obscure > weirdness because of tool inadequacies that will eventually go away. What we really need is eu-objdump. Apparently the unit-at-a-time compiler option breaks the old one, in addition to it not handling the separate debug info. From roland at redhat.com Mon Apr 2 23:51:26 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Apr 2007 16:51:26 -0700 (PDT) Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: Chuck Ebbert's message of Monday, 2 April 2007 18:54:42 -0400 <461189B2.4030807@redhat.com> Message-ID: <20070402235126.148EE180064@magilla.sf.frob.com> > What we really need is eu-objdump. Apparently the unit-at-a-time compiler > option breaks the old one, in addition to it not handling the separate > debug info. We have one upstream, but without a disassembler (yet). Do you have a reference to the unit-at-a-time problem with binutils' disassembler? From acme at redhat.com Tue Apr 3 00:14:05 2007 From: acme at redhat.com (Arnaldo Carvalho de Melo) Date: Mon, 02 Apr 2007 21:14:05 -0300 Subject: Putting the full unstripped modules in the kernel-debuginfo package In-Reply-To: <20070402235126.148EE180064@magilla.sf.frob.com> References: <20070402235126.148EE180064@magilla.sf.frob.com> Message-ID: <46119C4D.5040705@redhat.com> Roland McGrath wrote: >> What we really need is eu-objdump. Apparently the unit-at-a-time compiler >> option breaks the old one, in addition to it not handling the separate >> debug info. >> > > We have one upstream, but without a disassembler (yet). Do you have a > reference to the unit-at-a-time problem with binutils' disassembler? > > Have to check with Andi Kleen, that keeps complaining, but was along the lines that the source gets unreadable, sorry for the lack of details, will talk to Andi when he gets back online. - Arnaldo From samfw at redhat.com Tue Apr 3 13:38:56 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Tue, 3 Apr 2007 09:38:56 -0400 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <46112166.8010304@redhat.com> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> <46112166.8010304@redhat.com> Message-ID: <20070403133855.GI10736@unplugged.rdu.redhat.com> On 04/02/07 11:29 -0400 Chuck Ebbert wrote: > When copying the kernel tree, the second copy should be: > > cp -alv ~/rpmbuild/redhat/kernel-2.6.x.orig ~/rpmbuild/redhat/kernel-2.6.x.new > > this will hardlink the original and new trees so diff will run much faster. > Hardlinks should not present a problem because text editors know how to break > them -- Midnight Commander now asks, so maybe a note telling people about > the hardlinks could be added there as well. Thanks Chuck - made that change. Anything else - just let me know. -Sam -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA From cebbert at redhat.com Tue Apr 3 19:16:08 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 03 Apr 2007 15:16:08 -0400 Subject: Make "pci=nomsi" the default on 2.6.20 kernels? In-Reply-To: <460D5B40.5030003@redhat.com> References: <460D25FC.3030305@redhat.com> <20070330104953.4b7ce52a.zaitcev@redhat.com> <460D50EB.5090209@redhat.com> <20070330182122.GC18649@redhat.com> <460D5B40.5030003@redhat.com> Message-ID: <4612A7F8.4020206@redhat.com> Chuck Ebbert wrote: > Dave Jones wrote: >> Gets my vote too. >> I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times >> now for FC5/FC6, because each time it starts to look more promising, >> it seems to find new ways to regress. >> >> I might do a build next week in rawhide with it off again too, >> to see if any oddball bugs fall out. > > I was thinking of leaving MSI enabled and applying this patch. > Ended up applying the attached patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6-pci_no_msi.patch URL: From jwilson at redhat.com Tue Apr 3 20:41:55 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Apr 2007 16:41:55 -0400 Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: <20070331074741.2BC081801C4@magilla.sf.frob.com> References: <20070331074741.2BC081801C4@magilla.sf.frob.com> Message-ID: <4612BC13.7020008@redhat.com> Roland McGrath wrote: >> I kinda like it in %name whichever route we go here. Along the same >> lines as Ingo's kernel-rt packages, it makes it easier to install them >> in parallel with normal kernels for testing. > > I was just remembering about Ingo's -rt builds. I hadn't looked. What he > uses is nearly identical to what I wind up with. It should be easy to use > a unified spec file for his -rt patch version too. Definitely doable. Probably lots more %if'age in the spec, but hey, there's already a ton... > I've tweaked my hacks slightly to use name: kernel-vanilla and > kernel-branch for the git stuff. For git builds, it now produces > e.g. kernel-upstream-2.6.20-2.6.21.rc5.97.1.3025 > or kernel-roland-fedora-PAE-2.6.20-2.6.18.rc6.256.1.3025 > using the tag and "commit number" from git (1.5) describe, so upgrades for > the same branch package should work right without the ginormous date string > release numbers I had before. If I'm understanding correctly, my current implementation isn't quite as flexible as yours, as it only adds the ability to build kernel-vanilla (and all sub-variants/bits), but it does do so for both released and in-development -rc and -rc-git vanilla kernels. I've been toying around with a few different variations, shuffling %name, %version and %release around a bit, and I think I've come upon one that I'm liking. My current version outputs a kernel-vanilla-2.6.21-0.rc5.git9.1.fc7 from a 1.3040-based spec, which is (hopefully) obviously 2.6.21-rc5-git9. A 2.6.20.4-based build should wind up being kernel-vanilla-2.6.20-4.1.fc6 using similar spec tweaks, and a forthcoming F7 2.6.21 kernel ought to wind up being kernel-vanilla-2.6.21-0.1.fc7. > (Those changes are small but I don't have > intermediate diffs on hand since I didn't commit the old version. I can > send you the new files if you want.) Absolutely, shoot me whatcha got. I still have your prior changes in patch form (as well as a good portion merged into a working copy), extracting the diffs is no prob. Renaming to kernel-vanilla while still using the same spec does introduce a few problems I hadn't considered... 1) it breaks some build setups, where spec and sources are both somewhere like %_topdir/sources/%name. The build gets confused if %name is now kernel-vanilla. I can work around it locally with a symlink in my build root, but something programmatic would be good. Haven't looked into this much just yet. 2) kernel-xyz-headers is going to conflict with kernel-headers. Perhaps solved by simply 'if kernel-xyz, kernel-xyz-headers Provides: kernel-headers'. I've got this in my latest edition, will see how it behaves... Despite those issues, I still vote for the %name change. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Apr 3 21:02:57 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Apr 2007 14:02:57 -0700 (PDT) Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: Jarod Wilson's message of Tuesday, 3 April 2007 16:41:55 -0400 <4612BC13.7020008@redhat.com> Message-ID: <20070403210257.E1AD8180064@magilla.sf.frob.com> > Definitely doable. Probably lots more %if'age in the spec, but hey, > there's already a ton... Nope, pretty much just the same ones I added. > Absolutely, shoot me whatcha got. I still have your prior changes in > patch form (as well as a good portion merged into a working copy), > extracting the diffs is no prob. Index: Makefile =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/Makefile,v retrieving revision 1.45 diff -B -p -u -r1.45 Makefile --- Makefile 19 Mar 2007 21:32:30 -0000 1.45 +++ Makefile 3 Apr 2007 21:02:40 -0000 @@ -68,3 +68,120 @@ reconfig: # since i386 isn't a target... compile compile-short: DIST_DEFINES += --target $(shell uname -m) + +# +# Hacks for building vanilla (unpatched) kernel rpms. +# Use "make vanilla-TARGET" like "make TARGET" (make vanilla-scratch-build). +# +vanilla-%: $(SPECFILE:.spec=-vanilla.spec) + @$(MAKE) $* SPECFILE=$< + +$(SPECFILE:.spec=-vanilla.spec): $(SPECFILE) + @rm -f $@ + (echo %define nopatches 1; cat $<) > $@ + +scratch-build: test-srpm + $(BUILD_CLIENT) $(BUILD_FLAGS) --scratch $(COLLECTION) \ + $(SRCRPMDIR)/$(NAME)-$(VERSION)-$(RELEASE).src.rpm + +# Dismal kludge for building via brew from cvs after "make vanilla-tag". +ifdef BEEHIVE_SRPM_BUILD +export CHECKOUT_TAG ?= $(shell sed s/^.// CVS/Tag) +tag-pattern = $(TAG_NAME)-$(TAG_VERSION)-0_%_$(TAG_RELEASE) +ifeq (,$(filter-out $(tag-pattern),$(CHECKOUT_TAG))) +variant := $(patsubst $(tag-pattern),%,$(CHECKOUT_TAG)) +srpm: SPECFILE := $(wildcard $(SPECFILE:.spec=-$(variant).spec) \ + $(SPECFILE:.spec=-t.$(variant).spec)) +srpm beehive-sprm: RELEASE := 0.$(variant).$(RELEASE) +endif +endif + + +# +# Hacks for building kernel rpms from upstream code plus local GIT branches. +# Use "make git/BRANCH/TARGET" like "make TARGET". +# Use "make git/BRANCH-fedora/TARGET" to include Fedora patches on top. +# +ifndef GIT_SPEC +git/%: + @$(MAKE) GIT_SPEC=$(subst /,-,$(*D)) git-$(*F) +else +git-%: $(SPECFILE:.spec=-t.$(GIT_SPEC).spec) + @$(MAKE) GIT_SPEC= $* SPECFILE=$< +endif + +# +# Your git-branches.mk file can define GIT_DIR, e.g.: +# GIT_DIR = ${HOME}/kernel/.git +# Make sure GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL are also set +# or your rpm changelogs will look like crap. +# +# For each branch it can define a variable branch-BRANCH or tag-BRANCH +# giving the parent of BRANCH to diff against in a separate patch. If +# the parent is unknown, it will use $(branch-upstream) defaulting to +# "upstream". +# +# Defining tag-BRANCH means the tag corresponds to an upstream patch in +# the sources file, so that is used instead of generating a patch with +# git. If there is no tag-upstream defined, it will figure out a vNNN +# tag or vNNN-gitN pseudo-tag from the last patch in the sources file. +# For example: +# tag-some-hacks = v2.6.21-rc5 +# branch-more-hacks = first-hacks +# Leads to patches: +# git diff v2.6.21-rc5..more-hacks > linux-2.6.21-rc5-some-hacks.patch +# git diff some-hacks..more-hacks > linux-2.6.21-rc5-more-hacks.patch +# Whereas having no git-branches.mk at all but doing +# "make GIT_DIR=... git/mybranch/test-srpm" does: +# id=`cat patch-2.6.21-rc5-git4.id` # auto-fetched via upstream file +# git diff $id..upstream > linux-2.6.21-rc5-git4-upstream.patch +# git diff upstream..mybranch > linux-2.6.21-rc5-git4-mybranch.patch +# If the upstream patch (or any branch patch) is empty it's left out. +# +git-branches.mk:; +-include git-branches.mk + +branch-upstream ?= upstream + +ifdef GIT_DIR +export GIT_DIR +export GIT_AUTHOR_NAME +export GIT_AUTHOR_EMAIL +gen-patches ?= gen-patches + +ifndef havespec +$(SPECFILE:.spec=-t.%-fedora.spec): $(SPECFILE) $(gen-patches) FORCE + ./$(gen-patches) --fedora < $< > $@ $(gen-patches-args) +$(SPECFILE:.spec=-t.%.spec): $(SPECFILE) $(gen-patches) FORCE + ./$(gen-patches) < $< > $@ $(gen-patches-args) +.PRECIOUS: $(SPECFILE:.spec=-t.%.spec) $(SPECFILE:.spec=-t.%-fedora.spec) +endif + +spec-%: $(SPECFILE:.spec=-t.%.spec) ; +$(SPECFILE):; +FORCE:; + +branch-of-* = $(firstword $(head-$*) $*) +gen-patches-args = --name $* v$(VERSION) $(call heads,$(branch-of-*)) +define heads +$(if $(tag-$1),$(filter-out v$(VERSION),$(tag-$1)),\ + $(call heads,$(firstword $(branch-$1) $(branch-upstream)))) $1 +endef + +files-%-fedora: + @echo $(SPECFILE:.spec=-t.$*-fedora.spec) + @$(call list-patches,$(branch-of-*)) +files-%: + @echo $(SPECFILE:.spec=-t.$*.spec) + @$(call list-patches,$(branch-of-*)) +define list-patches +$(if $(tag-$1),version=$(patsubst v%,%,$(tag-$1)),\ + $(call list-patches,$(firstword $(branch-$1) $(branch-upstream)))); \ +echo linux-$${version}-$1.patch +endef + +ifndef tag-$(branch-upstream) +tag-$(branch-upstream) := $(shell \ + sed -n 's/^.* *//;s/\.bz2$$//;s/patch-/v/p' sources) +endif +endif Index: kernel-2.6.spec =================================================================== RCS file: /cvs/dist/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3040 diff -B -p -u -r1.3040 kernel-2.6.spec --- kernel-2.6.spec 2 Apr 2007 19:39:38 -0000 1.3040 +++ kernel-2.6.spec 3 Apr 2007 21:02:40 -0000 @@ -60,7 +60,8 @@ Summary: The Linux kernel (the core of t %define sublevel 20 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define release %(R="$Revision: 1.3040 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define specrelease %(R="$Revision: 1.3040 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define release %{specrelease} %define make_target bzImage %define kernel_image x86 @@ -73,6 +74,24 @@ Summary: The Linux kernel (the core of t %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE} %define hdrarch %_target_cpu +%if 0%{!?nopatches:1} +%define nopatches 0 +%endif + +%if %{nopatches} +%define includexen 0 +%define variant -vanilla +%else +%define variant_fedora -fedora +%endif + +%define using_upstream_branch 0 +%if 0%{?upstream_branch:1} +%define using_upstream_branch 1 +%define variant -%{upstream_branch}%{?variant_fedora} +%define release %{upstream_branch_release}.%{specrelease} +%endif + # if requested, only build base kernel %if %{with_baseonly} %define with_smp 0 @@ -237,6 +256,15 @@ Summary: The Linux kernel (the core of t %define xen_image vmlinux.gz %endif +%if %{nopatches} +%define signmodules 0 +# Ignore unknown options in our config-* files. +# Some options go with patches we're not applying. +%define oldconfig_target loose_nonint_oldconfig +%else +%define oldconfig_target nonint_oldconfig +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -285,7 +313,7 @@ Summary: The Linux kernel (the core of t # %define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.4-1 -Name: kernel +Name: kernel%{?variant} Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} @@ -373,8 +401,16 @@ Source82: config-olpc-generic # # Patches 0 through 100 are meant for core subsystem upgrades # + +%if %{using_upstream_branch} +### BRANCH PATCH ### +%else +# Here should be only the patches up to the upstream canonical Linus tree. Patch1: patch-2.6.21-rc5.bz2 Patch2: patch-2.6.21-rc5-git9.bz2 +%endif + +%if !%{nopatches} Patch3: git-geode.patch # Patches 10 through 99 are for things that are going upstream really soon. @@ -448,7 +484,9 @@ Patch366: linux-2.6-ps3av-export-header. # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # -Patch800: linux-2.6-build-nonintconfig.patch +%endif +Patch800: linux-2.6.17-nonintconfig.patch +%if !%{nopatches} # Exec-shield. Patch810: linux-2.6-execshield.patch @@ -582,6 +620,7 @@ Patch20001: xen-11668-hvm_disable_fix.pa Patch20002: xen-dom0-reboot.patch # END OF PATCH DEFINITIONS +%endif BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu} @@ -959,10 +998,17 @@ cp -rl vanilla linux-%{kversion}.%{_targ cd linux-%{kversion}.%{_target_cpu} +%if %{using_upstream_branch} +### BRANCH APPLY ### +%else + # Update to latest upstream. %patch1 -p1 %patch2 -p1 +%endif +%if !%{nopatches} + # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. @@ -1056,13 +1102,14 @@ cd linux-%{kversion}.%{_target_cpu} # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build # - +%endif # This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). %patch800 -p1 +%if !%{nopatches} # Exec shield %patch810 -p1 @@ -1280,6 +1327,7 @@ mv drivers/xen/blktap/blktap.c drivers/x %patch10001 -p1 # END OF PATCH APPLICATIONS +%endif cp %{SOURCE10} Documentation/ @@ -1310,7 +1358,7 @@ for i in *.config do mv $i .config Arch=`head -1 .config | cut -b 3-` - make ARCH=$Arch nonint_oldconfig > /dev/null + make ARCH=$Arch %{oldconfig_target} > /dev/null echo "# $Arch" > configs/$i cat .config >> configs/$i done @@ -1404,7 +1452,7 @@ BuildKernel() { KernelImage=arch/$Arch/boot/bzImage fi - make -s ARCH=$Arch nonint_oldconfig > /dev/null + make -s ARCH=$Arch %{oldconfig_target} > /dev/null make -s ARCH=$Arch %{?_smp_mflags} $MakeTarget %{?sparse_mflags} make -s ARCH=$Arch %{?_smp_mflags} modules %{?sparse_mflags} || exit 1 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gen-patches URL: From jwilson at redhat.com Tue Apr 3 22:21:55 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Apr 2007 18:21:55 -0400 Subject: Spinning kernel-vanilla packages via standard spec In-Reply-To: <20070403210257.E1AD8180064@magilla.sf.frob.com> References: <20070403210257.E1AD8180064@magilla.sf.frob.com> Message-ID: <4612D383.9090506@redhat.com> Roland McGrath wrote: >> Definitely doable. Probably lots more %if'age in the spec, but hey, >> there's already a ton... > > Nope, pretty much just the same ones I added. Ah, sorry, I see where the disconnect is here... I've not taken some of the build system side of things into account, and was trying to do things solely via spec mods. I think I now understand the necessity of Makefile hacks too. :\ -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From zaitcev at redhat.com Fri Apr 6 00:05:05 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 5 Apr 2007 17:05:05 -0700 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <20070329132406.GB11824@unplugged.rdu.redhat.com> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> Message-ID: <20070405170505.9551b141.zaitcev@redhat.com> On Thu, 29 Mar 2007 09:24:07 -0400, Sam Folk-Williams wrote: > Any feedback appreciated. I am happy to make edits myself if you reply, or of > course any one can make edits on their own. > http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel I'm not quite sure that I have the last word here, so I'll just reply > * rpm-build > * rpmdevtools > * yum-utils > * gcc > * redhat-rpm-config > * ncurses-devel > * unifdef This changes over time and I do not bother remember this. I just run rpmbuild --bp, and it tells what packages it needs. Maybe you want to mention that it's ok to run rpmbuild, see what falls out? For example, it's likely that we'll require sparse just as soon as the Core+Extras merge happens. > The second diff command will hardlink the orig and new trees > so that the diff will run faster. Text editors should know how > to break the hardlink, so this should not present a problem. I see you applied Chuck's suggestion. I would mention also that vi specifically is the most notable exception. You have to break links before editing with vi. -- Pete From samfw at redhat.com Sun Apr 8 22:36:48 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Sun, 8 Apr 2007 18:36:48 -0400 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <20070405170505.9551b141.zaitcev@redhat.com> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> <20070405170505.9551b141.zaitcev@redhat.com> Message-ID: <20070408223648.GU1321@unplugged.rdu.redhat.com> On 04/05/07 17:05 -0700 Pete Zaitcev wrote: > On Thu, 29 Mar 2007 09:24:07 -0400, Sam Folk-Williams > wrote: > > > Any feedback appreciated. I am happy to make edits myself if you reply, or of > > course any one can make edits on their own. > > http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel > > I'm not quite sure that I have the last word here, so I'll just reply > > > * rpm-build > > * rpmdevtools > > * yum-utils > > * gcc > > * redhat-rpm-config > > * ncurses-devel > > * unifdef > > This changes over time and I do not bother remember this. I just > run rpmbuild --bp, and it tells what packages it needs. Maybe you > want to mention that it's ok to run rpmbuild, see what falls out? > For example, it's likely that we'll require sparse just as soon > as the Core+Extras merge happens. Thanks Pete - I had been trying to keep a comprehensive list, but if it changes frequently there's really no point. Applied your recommendation. > > > The second diff command will hardlink the orig and new trees > > so that the diff will run faster. Text editors should know how > > to break the hardlink, so this should not present a problem. > > I see you applied Chuck's suggestion. I would mention also that > vi specifically is the most notable exception. You have to break > links before editing with vi. > Noted. Thanks, Sam > -- Pete -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA From Daniel.Kirsten at gmx.net Thu Apr 12 15:49:05 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Thu, 12 Apr 2007 17:49:05 +0200 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys Message-ID: <200704121749.05863.Daniel.Kirsten@gmx.net> Hallo, we discussed the following problem in march >my compiled 2.6.20-1.2925 kernel does not boot. >It hangs after unmounting the old proc and >sys filesystems. However, I can still use >Ctrl+Alt+Del to reboot. > >Maybe, the problem is related to Selinux. > >My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 >worked fine, and I did not change the kernel >configuration. > >The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and >2.6.20-1.2925 also work. The same problem occured in 2.6.20-1.2933. However, in a needle-in-the-haystick search, I solved the problem by DISabeling the option Compat VDSO support (COMPAT_VDSO) Best regards, Daniel From davej at redhat.com Thu Apr 12 17:53:00 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 12 Apr 2007 13:53:00 -0400 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200704121749.05863.Daniel.Kirsten@gmx.net> References: <200704121749.05863.Daniel.Kirsten@gmx.net> Message-ID: <20070412175300.GA25646@redhat.com> On Thu, Apr 12, 2007 at 05:49:05PM +0200, Daniel Kirsten wrote: > Hallo, > > we discussed the following problem in march > > >my compiled 2.6.20-1.2925 kernel does not boot. > >It hangs after unmounting the old proc and > >sys filesystems. However, I can still use > >Ctrl+Alt+Del to reboot. > > > >Maybe, the problem is related to Selinux. > > > >My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 > >worked fine, and I did not change the kernel > >configuration. > > > >The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and > >2.6.20-1.2925 also work. > > The same problem occured in 2.6.20-1.2933. > However, in a needle-in-the-haystick search, I solved the > problem by DISabeling the option > > Compat VDSO support (COMPAT_VDSO) That should only be necessary if you're running an ancient glibc. (FC1 era). You can also boot with vdso=off in such situations. Dave -- http://www.codemonkey.org.uk From Daniel.Kirsten at gmx.net Thu Apr 12 18:20:14 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Thu, 12 Apr 2007 20:20:14 +0200 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070412175300.GA25646@redhat.com> References: <200704121749.05863.Daniel.Kirsten@gmx.net> <20070412175300.GA25646@redhat.com> Message-ID: <200704122020.14187.Daniel.Kirsten@gmx.net> On Thursday April 12 2007, you wrote: > On Thu, Apr 12, 2007 at 05:49:05PM +0200, Daniel Kirsten wrote: > > Hallo, > > > > we discussed the following problem in march > > > > >my compiled 2.6.20-1.2925 kernel does not boot. > > >It hangs after unmounting the old proc and > > >sys filesystems. However, I can still use > > >Ctrl+Alt+Del to reboot. > > > > > >Maybe, the problem is related to Selinux. > > > > > >My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 > > >worked fine, and I did not change the kernel > > >configuration. > > > > > >The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and > > >2.6.20-1.2925 also work. > > > > The same problem occured in 2.6.20-1.2933. > > However, in a needle-in-the-haystick search, I solved the > > problem by DISabeling the option > > > > Compat VDSO support (COMPAT_VDSO) > > That should only be necessary if you're running an ancient glibc. > (FC1 era). I use glibc-2.5-10.fc6 Daniel From davej at redhat.com Thu Apr 12 18:33:17 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 12 Apr 2007 14:33:17 -0400 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200704122020.14187.Daniel.Kirsten@gmx.net> References: <200704121749.05863.Daniel.Kirsten@gmx.net> <20070412175300.GA25646@redhat.com> <200704122020.14187.Daniel.Kirsten@gmx.net> Message-ID: <20070412183317.GA13968@redhat.com> On Thu, Apr 12, 2007 at 08:20:14PM +0200, Daniel Kirsten wrote: > On Thursday April 12 2007, you wrote: > > On Thu, Apr 12, 2007 at 05:49:05PM +0200, Daniel Kirsten wrote: > > > Hallo, > > > > > > we discussed the following problem in march > > > > > > >my compiled 2.6.20-1.2925 kernel does not boot. > > > >It hangs after unmounting the old proc and > > > >sys filesystems. However, I can still use > > > >Ctrl+Alt+Del to reboot. > > > > > > > >Maybe, the problem is related to Selinux. > > > > > > > >My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911 > > > >worked fine, and I did not change the kernel > > > >configuration. > > > > > > > >The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and > > > >2.6.20-1.2925 also work. > > > > > > The same problem occured in 2.6.20-1.2933. > > > However, in a needle-in-the-haystick search, I solved the > > > problem by DISabeling the option > > > > > > Compat VDSO support (COMPAT_VDSO) > > > > That should only be necessary if you're running an ancient glibc. > > (FC1 era). > > I use glibc-2.5-10.fc6 That's.. puzzling. Roland, any ideas? does booting with vdso=0 as I suggested also work ? Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Apr 12 21:58:24 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Apr 2007 14:58:24 -0700 (PDT) Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: Dave Jones's message of Thursday, 12 April 2007 14:33:17 -0400 <20070412183317.GA13968@redhat.com> Message-ID: <20070412215824.C74D9D82FC@pipsqueak.sf.frob.com> I may have missed some of the context, so forgive me if I'm confused. It sounds like the report was of CONFIG_COMPAT_VDSO=y causing problems, the problem being fixed by using CONFIG_COMPAT_VDSO=n. Is that right, or inverted? CONFIG_COMPAT_VDSO=y has never been set in Fedora configs AFAIK. It is not desireable. It's been cleaned up and fixed upstream, some by me and some not by me, fairly recently (probably after 2.6.19, don't really remember). It may well never have been reconciled with the exec-shield patch, and I wouldn't lay odds on whether the current upstream code jibes or not, though I don't know of any interaction problems there off hand. With the very latest code (certainly after 2.6.20), now perhaps in -mm and not yet all the way in upstream, it will become possible to compile in support for the compatibility mode without undesireable effects when it's not enabled at runtime (by "vdso=2" or a sysctl equivalent). When those changes go in, it will make sense to compile in the compatibility support but not enable it at boot, and this will also likely be the default upstream configuration. As to the state of some existing or older Fedora kernel, I don't really know off hand (and won't be in a position to try any debugging of my own until I get home next week). print-fatal-signals might shed some light. Thanks, Roland From Daniel.Kirsten at gmx.net Fri Apr 13 09:21:25 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Fri, 13 Apr 2007 11:21:25 +0200 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <20070412215824.C74D9D82FC@pipsqueak.sf.frob.com> References: <20070412215824.C74D9D82FC@pipsqueak.sf.frob.com> Message-ID: <200704131121.25078.Daniel.Kirsten@gmx.net> On Thursday April 12 2007, you wrote: > I may have missed some of the context, so forgive me if I'm confused. It > sounds like the report was of CONFIG_COMPAT_VDSO=y causing problems, the > problem being fixed by using CONFIG_COMPAT_VDSO=n. Is that right, or inverted? It is right. CONFIG_COMPAT_VDSO=y causes the kernel to hang after unmounting the old proc and sys filesystems. I can boot the same kernel if I use the kernel option vdso=0. I can boot with CONFIG_COMPAT_VDSO=n The problem appeared in 2.6.20-1.2925 and 2.6.20-1.2933. I do not know how the option CONFIG_COMPAT_VDSO was turned on. It is turned on in every kernel-config since 2868 (the oldest one I found) Daniel From cebbert at redhat.com Fri Apr 13 14:38:19 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Fri, 13 Apr 2007 10:38:19 -0400 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <200704131121.25078.Daniel.Kirsten@gmx.net> References: <20070412215824.C74D9D82FC@pipsqueak.sf.frob.com> <200704131121.25078.Daniel.Kirsten@gmx.net> Message-ID: <461F95DB.1060009@redhat.com> Daniel Kirsten wrote: > > The problem appeared in 2.6.20-1.2925 and 2.6.20-1.2933. > I do not know how the option CONFIG_COMPAT_VDSO was turned on. It is turned on > in every kernel-config since 2868 (the oldest one I found) You mean in your own private config, right? It's not enabled in the standard Fedora kernel config. From Daniel.Kirsten at gmx.net Fri Apr 13 18:05:58 2007 From: Daniel.Kirsten at gmx.net (Daniel Kirsten) Date: Fri, 13 Apr 2007 20:05:58 +0200 Subject: solved!!! VDSO support, 2.6.20-1.2925 hangs after unmounting old proc and sys In-Reply-To: <461F95DB.1060009@redhat.com> References: <20070412215824.C74D9D82FC@pipsqueak.sf.frob.com> <200704131121.25078.Daniel.Kirsten@gmx.net> <461F95DB.1060009@redhat.com> Message-ID: <200704132005.58695.Daniel.Kirsten@gmx.net> On Friday April 13 2007, Chuck Ebbert wrote: > Daniel Kirsten wrote: > > > > The problem appeared in 2.6.20-1.2925 and 2.6.20-1.2933. > > I do not know how the option CONFIG_COMPAT_VDSO was turned on. It is turned on > > in every kernel-config since 2868 (the oldest one I found) > > You mean in your own private config, right? It's not enabled > in the standard Fedora kernel config. yes. in my private config From dwmw2 at infradead.org Mon Apr 16 12:29:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Apr 2007 13:29:59 +0100 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <20070329132406.GB11824@unplugged.rdu.redhat.com> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> Message-ID: <1176726599.3304.37.camel@pmac.infradead.org> On Thu, 2007-03-29 at 09:24 -0400, Sam Folk-Williams wrote: > I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a > while back that we remove the building instructions from the release notes and > put those in a separate doc devoted to more detailed instructions on building > the kernel RPM (including applying patches and configuring options). I'm surprised that you advocate downloading the src.rpm and building from that. I would recommend checking the kernel package out from CVS instead. It's easier to see what you've changed ('cvs diff'), and much easier and quicker to update to later kernels when the Fedora folks ship an erratum and you want to update your own version to be based on it. I'd also like to see the document cover building _modules_. For example, I have this patch to bcm43xx and how do I make a module to test it? I certainly don't rebuild the whole damn kernel -- I run 'make prep' in the CVS directory, then apply the patch manually (or hack on the code as appropriate), and build it with: make -C /lib/modules/`uname -r`/build SUBDIRS=drivers/net/wireless/bcm43xx modules -- dwmw2 From cebbert at redhat.com Wed Apr 18 20:44:41 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 18 Apr 2007 16:44:41 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? Message-ID: <46268339.9060900@redhat.com> The number of bugs reported against the FC6 kernel is now dropping. Should we move to kernel 2.6.21 and risk a whole new wave of bug reports, or leave it on 2.6.20 and live with the fact that some things can't/won't be fixed right, like support for PCI message signaled interrupts? From roland at redhat.com Wed Apr 18 20:47:55 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 18 Apr 2007 13:47:55 -0700 (PDT) Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: Chuck Ebbert's message of Wednesday, 18 April 2007 16:44:41 -0400 <46268339.9060900@redhat.com> Message-ID: <20070418204755.8F6971800A1@magilla.sf.frob.com> I'd say let F7 testing iron out 2.6.21 for a while before deciding about FC6. We should be in the part of freeze where serious Fedora weenies are doing a lot of testing. From davej at redhat.com Wed Apr 18 21:23:45 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 18 Apr 2007 17:23:45 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070418204755.8F6971800A1@magilla.sf.frob.com> References: <46268339.9060900@redhat.com> <20070418204755.8F6971800A1@magilla.sf.frob.com> Message-ID: <20070418212345.GC20566@redhat.com> On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > I'd say let F7 testing iron out 2.6.21 for a while before deciding about > FC6. We should be in the part of freeze where serious Fedora weenies are > doing a lot of testing. Getting 2.6.21 into FC6 does also have the additional advantage that it's an extra round of testing for what will become the F7 kernel. It'd be a good idea to nail some of the known outstanding regressions first though I think. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Apr 19 04:58:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 06:58:53 +0200 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070418212345.GC20566@redhat.com> References: <46268339.9060900@redhat.com> <20070418204755.8F6971800A1@magilla.sf.frob.com> <20070418212345.GC20566@redhat.com> Message-ID: <4626F70D.6070204@leemhuis.info> On 18.04.2007 23:23, Dave Jones wrote: > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > I'd say let F7 testing iron out 2.6.21 for a while before deciding about > > FC6. We should be in the part of freeze where serious Fedora weenies are > > doing a lot of testing. > Getting 2.6.21 into FC6 does also have the additional advantage that > it's an extra round of testing for what will become the F7 kernel. +1 -- putting in in updates-testing quite soon might be a start. CU thl From davidz at redhat.com Thu Apr 19 05:50:55 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 19 Apr 2007 01:50:55 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070418212345.GC20566@redhat.com> References: <46268339.9060900@redhat.com> <20070418204755.8F6971800A1@magilla.sf.frob.com> <20070418212345.GC20566@redhat.com> Message-ID: <1176961855.20826.46.camel@zelda.fubar.dk> On Wed, 2007-04-18 at 17:23 -0400, Dave Jones wrote: > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > I'd say let F7 testing iron out 2.6.21 for a while before deciding about > > FC6. We should be in the part of freeze where serious Fedora weenies are > > doing a lot of testing. > > Getting 2.6.21 into FC6 does also have the additional advantage that > it's an extra round of testing for what will become the F7 kernel. > > It'd be a good idea to nail some of the known outstanding regressions > first though I think. Please also test that FC6 user space works with this new kernel. Thanks. David From snecklifter at gmail.com Thu Apr 19 16:08:29 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 19 Apr 2007 17:08:29 +0100 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? Message-ID: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> > On 18.04.2007 23:23, Dave Jones wrote: > > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > > I'd say let F7 testing iron out 2.6.21 for a while before deciding > about > > > FC6. We should be in the part of freeze where serious Fedora weenies > are > > > doing a lot of testing. > > Getting 2.6.21 into FC6 does also have the additional advantage that > > it's an extra round of testing for what will become the F7 kernel. > > +1 -- putting in in updates-testing quite soon might be a start. +1 for moving it straight into updates for reasons already stated plus isn't a kernel upgrade dependent on user confirmation? I have always felt for this reason that updates-testing is not the right place for testing kernels as the installonlyn plugin for yum ensures that a backup kernel (hopefully stable) is always available. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Apr 19 16:26:23 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 19 Apr 2007 12:26:23 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> References: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> Message-ID: <20070419162623.GC16001@redhat.com> On Thu, Apr 19, 2007 at 05:08:29PM +0100, Chris Brown wrote: > > On 18.04.2007 23:23, Dave Jones wrote: > > > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > > > I'd say let F7 testing iron out 2.6.21 for a while before deciding > > about > > > > FC6. We should be in the part of freeze where serious Fedora weenies > > are > > > > doing a lot of testing. > > > Getting 2.6.21 into FC6 does also have the additional advantage that > > > it's an extra round of testing for what will become the F7 kernel. > > > > +1 -- putting in in updates-testing quite soon might be a start. > > > +1 for moving it straight into updates for reasons already stated plus isn't > a kernel upgrade dependent on user confirmation? I have always felt for this > reason that updates-testing is not the right place for testing kernels as > the installonlyn plugin for yum ensures that a backup kernel (hopefully > stable) is always available. I usually recommend at least 1 day in updates-testing, if only to catch any *really* stupid bugs. A few times I've been hit by dumb packaging thinkos and even a few 'doesnt boot' bugs which were blindingly obvious after testing. Especially the older hardware, which I don't test as much these days. updates-testing doesn't get the level of feedback that I'd like to see, but I think this is largely because a lot of people don't know it's there. If firstboot had a "would you like to test experimental updates?" dialog, we may find we get a lot more feedback. Well,.. I can dream. Dave -- http://www.codemonkey.org.uk From snecklifter at gmail.com Thu Apr 19 18:52:47 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 19 Apr 2007 19:52:47 +0100 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070419162623.GC16001@redhat.com> References: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> <20070419162623.GC16001@redhat.com> Message-ID: <364d303b0704191152o53d1c7f4peb0157332d1e95df@mail.gmail.com> On 19/04/07, Dave Jones wrote: > > On Thu, Apr 19, 2007 at 05:08:29PM +0100, Chris Brown wrote: > > > On 18.04.2007 23:23, Dave Jones wrote: > > > > On Wed, Apr 18, 2007 at 01:47:55PM -0700, Roland McGrath wrote: > > > > > I'd say let F7 testing iron out 2.6.21 for a while before > deciding > > > about > > > > > FC6. We should be in the part of freeze where serious Fedora > weenies > > > are > > > > > doing a lot of testing. > > > > Getting 2.6.21 into FC6 does also have the additional advantage that > > > > it's an extra round of testing for what will become the F7 kernel. > > > > > > +1 -- putting in in updates-testing quite soon might be a start. > > > > > > +1 for moving it straight into updates for reasons already stated plus > isn't > > a kernel upgrade dependent on user confirmation? I have always felt for > this > > reason that updates-testing is not the right place for testing kernels > as > > the installonlyn plugin for yum ensures that a backup kernel (hopefully > > stable) is always available. > > I usually recommend at least 1 day in updates-testing, if only to catch > any *really* stupid bugs. A few times I've been hit by dumb packaging > thinkos > and even a few 'doesnt boot' bugs which were blindingly obvious after > testing. > Especially the older hardware, which I don't test as much these days. > > updates-testing doesn't get the level of feedback that I'd like to see, > but I think this is largely because a lot of people don't know it's there. > If firstboot had a "would you like to test experimental updates?" dialog, > we may find we get a lot more feedback. Well,.. I can dream. > If I want to test the latest and greatest I've always used your people.redhat.com/davej ftp. It would be good to have the above option you mention and the place for it would be the additional CD's dialog. I only discovered updates-testing by chance myself. I think there is room for a middle-ground between rawhide and updates but its probably a discussion for a list other than this one... Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Apr 19 19:11:42 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 19 Apr 2007 15:11:42 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <364d303b0704191152o53d1c7f4peb0157332d1e95df@mail.gmail.com> References: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> <20070419162623.GC16001@redhat.com> <364d303b0704191152o53d1c7f4peb0157332d1e95df@mail.gmail.com> Message-ID: <20070419191142.GF16001@redhat.com> On Thu, Apr 19, 2007 at 07:52:47PM +0100, Chris Brown wrote: > If I want to test the latest and greatest I've always used your > people.redhat.com/davej ftp. At one point I had a cronjob that would sync the latest I'd built through the buildsys there, but it broke when we migrated to a newer buildsystem. I keep meaning to get around to fixing it up. *adds to todays todo* Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Apr 19 19:56:37 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 19 Apr 2007 15:56:37 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070419191142.GF16001@redhat.com> References: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> <20070419162623.GC16001@redhat.com> <364d303b0704191152o53d1c7f4peb0157332d1e95df@mail.gmail.com> <20070419191142.GF16001@redhat.com> Message-ID: <20070419195637.GG16001@redhat.com> On Thu, Apr 19, 2007 at 03:11:42PM -0400, Dave Jones wrote: > On Thu, Apr 19, 2007 at 07:52:47PM +0100, Chris Brown wrote: > > > If I want to test the latest and greatest I've always used your > > people.redhat.com/davej ftp. > > At one point I had a cronjob that would sync the latest I'd built > through the buildsys there, but it broke when we migrated to a newer > buildsystem. I keep meaning to get around to fixing it up. > > *adds to todays todo* That wasn't so hard. http://people.redhat.com/davej/kernels/Fedora/fc7/ will update each time a build completes. It should also be yum'able. I excluded the debuginfo's as they're a) ginormous, b) rarely needed and c) take forever to sync to the webserver. Oh, and would probably murder my quota there. Dave -- http://www.codemonkey.org.uk From snecklifter at gmail.com Thu Apr 19 20:44:02 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 19 Apr 2007 21:44:02 +0100 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070419195637.GG16001@redhat.com> References: <364d303b0704190908v60ade503lb1c0967980bb6bbd@mail.gmail.com> <20070419162623.GC16001@redhat.com> <364d303b0704191152o53d1c7f4peb0157332d1e95df@mail.gmail.com> <20070419191142.GF16001@redhat.com> <20070419195637.GG16001@redhat.com> Message-ID: <364d303b0704191344h1135d665x7ca9a19e795fdd00@mail.gmail.com> On 19/04/07, Dave Jones wrote: > > On Thu, Apr 19, 2007 at 03:11:42PM -0400, Dave Jones wrote: > > On Thu, Apr 19, 2007 at 07:52:47PM +0100, Chris Brown wrote: > > > > > If I want to test the latest and greatest I've always used your > > > people.redhat.com/davej ftp. > > > > At one point I had a cronjob that would sync the latest I'd built > > through the buildsys there, but it broke when we migrated to a newer > > buildsystem. I keep meaning to get around to fixing it up. > > > > *adds to todays todo* > > That wasn't so hard. http://people.redhat.com/davej/kernels/Fedora/fc7/ > will update each time a build completes. It should also be yum'able. > > I excluded the debuginfo's as they're a) ginormous, b) rarely needed > and c) take forever to sync to the webserver. Oh, and would probably > murder my quota there. > Nice. I've asked the question regarding enabling updates-testing on the development list. This is an ideal chance to test pungi. So thanks for the suggestion. Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From samfw at redhat.com Fri Apr 20 11:09:51 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Fri, 20 Apr 2007 07:09:51 -0400 Subject: [OT] please review new kernel build doc on fedora wiki In-Reply-To: <1176726599.3304.37.camel@pmac.infradead.org> References: <20070329132406.GB11824@unplugged.rdu.redhat.com> <1176726599.3304.37.camel@pmac.infradead.org> Message-ID: <1177067391.3163.73.camel@localhost.localdomain> On Mon, 2007-04-16 at 13:29 +0100, David Woodhouse wrote: > On Thu, 2007-03-29 at 09:24 -0400, Sam Folk-Williams wrote: > > I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a > > while back that we remove the building instructions from the release notes and > > put those in a separate doc devoted to more detailed instructions on building > > the kernel RPM (including applying patches and configuring options). > > I'm surprised that you advocate downloading the src.rpm and building > from that. I would recommend checking the kernel package out from CVS > instead. It's easier to see what you've changed ('cvs diff'), and much > easier and quicker to update to later kernels when the Fedora folks ship > an erratum and you want to update your own version to be based on it. > I hadn't thought of this. The src RPM method has been recommended for a long time. I think it would be good to add an additional section on using CVS as an alternative. I'll work on that. > I'd also like to see the document cover building _modules_. For example, > I have this patch to bcm43xx and how do I make a module to test it? > I certainly don't rebuild the whole damn kernel -- I run 'make prep' in > the CVS directory, then apply the patch manually (or hack on the code as > appropriate), and build it with: > make -C /lib/modules/`uname -r`/build SUBDIRS=drivers/net/wireless/bcm43xx modules > Good point. I added a bit about building kernel modules for the currently running kernel (requiring the kernel-devel package). I will also include this in the new CVS info. Thanks, Sam > From anderson at redhat.com Thu Apr 26 19:40:00 2007 From: anderson at redhat.com (Dave Anderson) Date: Thu, 26 Apr 2007 15:40:00 -0400 Subject: [PATCH FC6] x86_64 page_is_ram() uses __initdata; breaks /dev/crash and /dev/mem restriction Message-ID: <46310010.4F7C0B3F@redhat.com> Somewhere after the 2.6.18 timeframe, Andi Kleen made the x86_64 e820 map __initdata: struct e820map e820 __initdata; This is fine for upstream x86_64 kernels, because the e820 map never gets used during runtime. But because we (RHEL/Fedora) have an x86_64 version of page_is_ram(), it ends up using __init data. I became aware of this when I got an FC6/crash-utility bugzilla #237383, filed because the crash utility started failing on later FC6 live systems. This is because the kernel's /dev/crash module crash.ko started failing because it uses page_is_ram() as a memory access qualifer. Also, because of Red Hat's restriction on the use of /dev/mem to only the first 256 RAM pages, the __initdata addition ends up opening the flood gates for /dev/mem usage. That's because of this: /* * devmem_is_allowed() checks to see if /dev/mem access to a certain address is * valid. The argument is a physical page number. * * * On x86-64, access has to be given to the first megabyte of ram because that area * contains bios code and data regions used by X and dosemu and similar apps. * Access has to be given to non-kernel-ram areas as well, these contain the PCI * mmio resources as well as potential bios/acpi data regions. */ int devmem_is_allowed(unsigned long pagenr) { if (pagenr <= 256) return 1; if (!page_is_ram(pagenr)) return 1; return 0; } The function is meant to allow /dev/mem accesses above pagenr 256 only if they are *not* RAM -- but since since page_is_ram() is failing, it inadvertantly allows access to any pagenr. (Interestingly enough, this bug allows the user of the crash utility to work around the /dev/crash failure by alternatively using /dev/mem instead! /dev/crash was only created to begin with because of the /dev/mem restriction... Anyway, reverting back from __initdata fixes the situation for both /dev/crash and the /dev/mem restriction. Dave Anderson (patch is against 2.6.20-1.2944) -------------- next part -------------- --- linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c.orig 2007-04-26 14:38:12.000000000 -0400 +++ linux-2.6.20.x86_64/arch/x86_64/kernel/e820.c 2007-04-26 14:38:24.000000000 -0400 @@ -25,7 +25,7 @@ #include #include -struct e820map e820 __initdata; +struct e820map e820; /* * PFN of last memory page. From kmustlinux at gmail.com Fri Apr 27 03:14:34 2007 From: kmustlinux at gmail.com (bluehat prometheus) Date: Fri, 27 Apr 2007 11:14:34 +0800 Subject: About audio programming Message-ID: Hello! I want to know something more about audio programming on Fedora I using Fedora Core 4 ,by the way. But I have no idea about it, can anyone tell me how to do with it?? Such as which header file to use, libs, etc. Please give me a sample if you can.. Thanks,pretty thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Sun Apr 29 13:03:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 29 Apr 2007 15:03:42 +0200 Subject: Pre-release kernel versioning Message-ID: <463497AE.8040605@leemhuis.info> Hi all! I'd like to put a old but still valid discussion on the table again where a solution never was found: Pre-release kernel versioning. In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in reality 2.6.21-rc6-git5. That's not only confusing to users, it also breaks outside kernel modules sometimes; just yesterday I saw a patch in 3rd party repo applied that did this... +-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20) ...to make it compile against the kernel from FC4-test4 (no idea if it helped, but I had to apply similar patches in the past nyself to make somethign work), as the kernels in rawhide until they switched to 2.6.21-final announces itself as 2.6.20-1.3066.fc7 instead of 2.6.21-rc6-git5, as upstream would do. I don't want to get further into the details if I don't have to, as this stuff was discussed multiple times already on mailing lists. The last time was here: https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00897.html So, what will we do in the future? Can we (after F7 is out and rawhide rolls again) please switch to something less confusing where version somehow allows normal users to clearly see what kernel they got? And one that doesn't confuse outside modules? Something like kernel-2.6.22-1.3200.fc7.rc2.git15 maybe? CU thl From tcallawa at redhat.com Sun Apr 29 13:13:19 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 29 Apr 2007 08:13:19 -0500 Subject: Pre-release kernel versioning In-Reply-To: <463497AE.8040605@leemhuis.info> References: <463497AE.8040605@leemhuis.info> Message-ID: <1177852399.4390.25.camel@localhost.localdomain> On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote: > kernel-2.6.22-1.3200.fc7.rc2.git15 Not to distract from Thorsten's good points here, but the longer the kernel n-v-r, the more painful it is for SPARC. The SPARC bootloader (silo) can't handle label names longer than 15 characters. So, for example, when booty tries to automagically label a new kernel on Aurora, we get a label like: 2.6.22-1.3200.fc The more we overload that n-v-r, the less useful that label is. Proposal: - Lose the leading 1. It really doesn't serve much purpose. It would be better to roll to 10000 if you have that many builds before the kernel increments. If we only do this, then we get boot labels of: 2.6.22-3200.fc7 (with room for 2.6.22-10000.fc7 if we need it) Also, I'll simply note that Fedora has established naming policy for pre-release and post-release packages, and I suspect that policy could be adapted to apply to the kernel. (http://fedoraproject.org/wiki/Packaging/NamingGuidelines) ~spot From drago01 at gmail.com Sun Apr 29 16:36:32 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 29 Apr 2007 18:36:32 +0200 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <46268339.9060900@redhat.com> References: <46268339.9060900@redhat.com> Message-ID: <4634C990.7010201@gmail.com> 2.6.21.1 is out ... so whats the plan now? Relase a FC6 update(updates-testing) or stick with 2.6.20.x until 2.6.22 is out/2.6.21 get some more testing? From davej at redhat.com Sun Apr 29 18:57:49 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 29 Apr 2007 14:57:49 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <4634C990.7010201@gmail.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> Message-ID: <20070429185749.GB23750@redhat.com> On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote: > 2.6.21.1 is out ... so whats the plan now? Relase a FC6 > update(updates-testing) or stick with 2.6.20.x until 2.6.22 is > out/2.6.21 get some more testing? We could do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates. Most of the scary stuff (new libata pata drivers etc), we'd keep off, so things shouldn't be too bad. The timer changes for tickless are probably the only remaining scary thing. For that we have a few choices. - Leave NO_HZ off. Feature parity with FC6, though the code has still changed, and may still find regressions. Probably the safest option. - Turn NO_HZ on. Early preview of F7 features, saves power yadayada, may find new bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) - Turn NO_HZ on, but do the same as we did for MSI (enable the config, but only if you boot with a command line option). Might find us even more regressions, that aren't even relevant upstream. Chuck? Dave -- http://www.codemonkey.org.uk From davej at redhat.com Sun Apr 29 19:08:33 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 29 Apr 2007 15:08:33 -0400 Subject: Pre-release kernel versioning In-Reply-To: <463497AE.8040605@leemhuis.info> References: <463497AE.8040605@leemhuis.info> Message-ID: <20070429190833.GC23750@redhat.com> On Sun, Apr 29, 2007 at 03:03:42PM +0200, Thorsten Leemhuis wrote: > So, what will we do in the future? Can we (after F7 is out and rawhide > rolls again) please switch to something less confusing where version > somehow allows normal users to clearly see what kernel they got? And one > that doesn't confuse outside modules? Something like > > kernel-2.6.22-1.3200.fc7.rc2.git15 How does this help up until rc1 ? For example right now, upstream is 2.6.21-git2, yet there's 14MB of patches already, (and much more to come before .22rc1) so it's clearly not .21 and is likely to break anything that relies upon kernel interfaces not changing vs .21 and it's not .22 either yet. the package versioning isn't whats relevant here, it's the versioning in version.h that broken external drivers insist on comparing against instead of comparing against #defines to check for features. Finally, there are cases where we'll change a prototype of a function in Fedora vs upstream when we backport something early, or develop some new feature etc, so just matching the version number isn't a panacea anyway. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Sun Apr 29 19:11:19 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 29 Apr 2007 15:11:19 -0400 Subject: Pre-release kernel versioning In-Reply-To: <1177852399.4390.25.camel@localhost.localdomain> References: <463497AE.8040605@leemhuis.info> <1177852399.4390.25.camel@localhost.localdomain> Message-ID: <20070429191119.GD23750@redhat.com> On Sun, Apr 29, 2007 at 08:13:19AM -0500, Tom spot Callaway wrote: > The SPARC bootloader (silo) can't handle label names longer than 15 > characters. So, for example, when booty tries to automagically label a > new kernel on Aurora, we get a label like: > > 2.6.22-1.3200.fc > > The more we overload that n-v-r, the less useful that label is. silo can't be fixed ? > Proposal: > > - Lose the leading 1. It really doesn't serve much purpose. It would be > better to roll to 10000 if you have that many builds before the kernel > increments. it's the cvs ident, so it'll need some shell scripting to sed it away or something. > (with room for 2.6.22-10000.fc7 if we need it) Eventually, it'll get that high. Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Mon Apr 30 00:28:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 29 Apr 2007 19:28:48 -0500 Subject: Pre-release kernel versioning In-Reply-To: <20070429191119.GD23750@redhat.com> References: <463497AE.8040605@leemhuis.info> <1177852399.4390.25.camel@localhost.localdomain> <20070429191119.GD23750@redhat.com> Message-ID: <1177892928.3836.31.camel@localhost.localdomain> On Sun, 2007-04-29 at 15:11 -0400, Dave Jones wrote: > silo can't be fixed ? Maybe. How's your forth? ~spot From jacliburn at bellsouth.net Sun Apr 29 21:55:15 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 29 Apr 2007 16:55:15 -0500 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429185749.GB23750@redhat.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> Message-ID: <20070429165515.4d168dad@osprey.hogchain.net> On Sun, 29 Apr 2007 14:57:49 -0400 Dave Jones wrote: > We could do a rebase to .21 this week, and push that out to testing, > and if anything critical turns up before that becomes deemed stable, > we could push a branched build off of .20 directly to updates. > > Most of the scary stuff (new libata pata drivers etc), we'd keep off, > so things shouldn't be too bad. The timer changes for tickless are > probably the only remaining scary thing. For that we have a few > choices. > - Leave NO_HZ off. > Feature parity with FC6, though the code has still changed, and > may still find regressions. Probably the safest option. > - Turn NO_HZ on. > Early preview of F7 features, saves power yadayada, may find new > bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) > - Turn NO_HZ on, but do the same as we did for MSI (enable the config, > but only if you boot with a command line option). > Might find us even more regressions, that aren't even relevant > upstream. What about MSI? On or off? From davej at redhat.com Mon Apr 30 01:16:30 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 29 Apr 2007 21:16:30 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429165515.4d168dad@osprey.hogchain.net> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <20070429165515.4d168dad@osprey.hogchain.net> Message-ID: <20070430011630.GF14857@redhat.com> On Sun, Apr 29, 2007 at 04:55:15PM -0500, Jay Cliburn wrote: > > Early preview of F7 features, saves power yadayada, may find new > > bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) > > - Turn NO_HZ on, but do the same as we did for MSI (enable the config, > > but only if you boot with a command line option). > > Might find us even more regressions, that aren't even relevant > > upstream. > > What about MSI? On or off? As mentioned above, the config option is on, but you need a boot-time argument to enable it. Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Mon Apr 30 03:20:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 29 Apr 2007 22:20:56 -0500 Subject: Pre-release kernel versioning In-Reply-To: <1177892928.3836.31.camel@localhost.localdomain> References: <463497AE.8040605@leemhuis.info> <1177852399.4390.25.camel@localhost.localdomain> <20070429191119.GD23750@redhat.com> <1177892928.3836.31.camel@localhost.localdomain> Message-ID: <1177903256.4903.19.camel@vader.jdub.homelinux.org> On Sun, 2007-04-29 at 19:28 -0500, Tom "spot" Callaway wrote: > On Sun, 2007-04-29 at 15:11 -0400, Dave Jones wrote: > > > silo can't be fixed ? > > Maybe. How's your forth? I've noticed similar restrictions in yaboot. josh From zaitcev at redhat.com Mon Apr 30 03:30:02 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sun, 29 Apr 2007 20:30:02 -0700 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429165515.4d168dad@osprey.hogchain.net> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <20070429165515.4d168dad@osprey.hogchain.net> Message-ID: <20070429203002.6bbd8cae.zaitcev@redhat.com> On Sun, 29 Apr 2007 16:55:15 -0500, Jay Cliburn wrote: > What about MSI? On or off? Off for FC6, on for Rawhide, or at least this is how I understood DaveJ's preference. Considering how unstable it is, makes sense, I guess. I have a laptop (Dell 1501), where MSI is DOA. Very fresh unit, PCIe all around, and still... -- Pete From davej at redhat.com Mon Apr 30 04:10:57 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 30 Apr 2007 00:10:57 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429203002.6bbd8cae.zaitcev@redhat.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <20070429165515.4d168dad@osprey.hogchain.net> <20070429203002.6bbd8cae.zaitcev@redhat.com> Message-ID: <20070430041057.GA15512@redhat.com> On Sun, Apr 29, 2007 at 08:30:02PM -0700, Pete Zaitcev wrote: > On Sun, 29 Apr 2007 16:55:15 -0500, Jay Cliburn wrote: > > > What about MSI? On or off? > > Off for FC6, on for Rawhide, or at least this is how I understood > DaveJ's preference. I did the same thing in rawhide for now too (in the run-up to F7, I wanted it to get some testing before we ship, as that's how we'll end up shipping probably). After F7 is out, I'll disable that patch again in rawhide, run with MSI on by default for a week or so, and see if its any better. I'll also keep an eye on upstream discussion in this area as people are working on improving the heuristic to decide if its supported/useful/necessary. > Considering how unstable it is, makes sense, I guess. > I have a laptop (Dell 1501), where MSI is DOA. Very fresh unit, PCIe all > around, and still... Aparently some of the newer Apple hardware _needs_ it enabled too. For every case to do something one way, there's always one to do the opposite it seems. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Mon Apr 30 04:51:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Apr 2007 06:51:18 +0200 Subject: Pre-release kernel versioning In-Reply-To: <20070429190833.GC23750@redhat.com> References: <463497AE.8040605@leemhuis.info> <20070429190833.GC23750@redhat.com> Message-ID: <463575C6.5050808@leemhuis.info> On 29.04.2007 21:08, Dave Jones wrote: > On Sun, Apr 29, 2007 at 03:03:42PM +0200, Thorsten Leemhuis wrote: > > > So, what will we do in the future? Can we (after F7 is out and rawhide > > rolls again) please switch to something less confusing where version > > somehow allows normal users to clearly see what kernel they got? And one > > that doesn't confuse outside modules? Something like > > > > kernel-2.6.22-1.3200.fc7.rc2.git15 > > How does this help up until rc1 ? That's a good question I don't have a answer to myself, as Linus seems to increase "SUBLEVEL =" in Makefile when releasing rc1 afaics. So for this case I'm fine with either going with kernel-2.6.21-1.3200.fc7.git3 or kernel-2.6.22-1.3200.fc7.git3 As the number before ".fc7." increases in any case we don't have to care what comes after in in %release as it won't confuse rpmvercmp. > For example right now, upstream is 2.6.21-git2, yet there's > 14MB of patches already, (and much more to come before .22rc1) > so it's clearly not .21 and is likely to break anything > that relies upon kernel interfaces not changing vs .21 > and it's not .22 either yet. I just want no special Fedora handling. Just let the Fedora kernel identify itself similar to what upstream would do, as everything else just confuses external modules and users -- the latter includes probably other Kernel developers as well, if they are not aware how Fedora versions its kernels. If seen that on LKML once or twice. > the package versioning isn't whats relevant here, it's the > versioning in version.h that broken external drivers > insist on comparing against instead of comparing against > #defines to check for features. Yeah, but that how life is ^w^w external module authors are. > Finally, there are cases where we'll change a prototype > of a function in Fedora vs upstream when we backport > something early, or develop some new feature etc, so > just matching the version number isn't a panacea anyway. Happens, we are all used to it. But that is not relevant for the discusson at hand IMHO, as that "feature" is independent of version and release in any case (e.g. it can happen to you in final or rc kernels). CU thl From drago01 at gmail.com Mon Apr 30 10:04:28 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 30 Apr 2007 12:04:28 +0200 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429185749.GB23750@redhat.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> Message-ID: <4635BF2C.4080002@gmail.com> Dave Jones wrote: > On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote: > > 2.6.21.1 is out ... so whats the plan now? Relase a FC6 > > update(updates-testing) or stick with 2.6.20.x until 2.6.22 is > > out/2.6.21 get some more testing? > > We could do a rebase to .21 this week, and push that out to testing, > and if anything critical turns up before that becomes deemed stable, > we could push a branched build off of .20 directly to updates. > > ok > Most of the scary stuff (new libata pata drivers etc), we'd keep off, > so things shouldn't be too bad. The timer changes for tickless are > probably the only remaining scary thing. For that we have a few choices. > - Leave NO_HZ off. > Feature parity with FC6, though the code has still changed, and > may still find regressions. Probably the safest option. > - Turn NO_HZ on. > Early preview of F7 features, saves power yadayada, may find new > bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) > what kind of bugs would this trigger? crashes? or "only" some weird timer/clock issues? if this is done does this also mean that we can backport x86_64 tickless for F7 when its ready? From dwmw2 at infradead.org Mon Apr 30 15:45:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 30 Apr 2007 16:45:02 +0100 Subject: Pre-release kernel versioning In-Reply-To: <463497AE.8040605@leemhuis.info> References: <463497AE.8040605@leemhuis.info> Message-ID: <1177947902.3085.103.camel@pmac.infradead.org> On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote: > In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in > reality 2.6.21-rc6-git5. That's not only confusing to users, it also > breaks outside kernel modules sometimes; just yesterday I saw a patch in > 3rd party repo applied that did this... > > +-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) > ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20) Those issues happen when you ship a kernel which is neither 2.6.20 nor 2.6.21. They don't magically go away if you call it 2.6.21 when in fact it's only 2.6.21-rc1. -- dwmw2 From davej at redhat.com Mon Apr 30 16:03:33 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 30 Apr 2007 12:03:33 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <4635BF2C.4080002@gmail.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <4635BF2C.4080002@gmail.com> Message-ID: <20070430160333.GC18187@redhat.com> On Mon, Apr 30, 2007 at 12:04:28PM +0200, dragoran wrote: > > Most of the scary stuff (new libata pata drivers etc), we'd keep off, > > so things shouldn't be too bad. The timer changes for tickless are > > probably the only remaining scary thing. For that we have a few choices. > > - Leave NO_HZ off. > > Feature parity with FC6, though the code has still changed, and > > may still find regressions. Probably the safest option. > > - Turn NO_HZ on. > > Early preview of F7 features, saves power yadayada, may find new > > bugs. (Gets us that nice fuzzy 'f6 bugs are f7 bugs' bonus though) > > > what kind of bugs would this trigger? crashes? or "only" some weird > timer/clock issues? all sorts of things rely on timers, so it could manifest itself in any number of ways. > if this is done does this also mean that we can backport x86_64 tickless > for F7 when its ready? Given its still not upstream, it'll likely be a while before it lands in FC6. It'll get backported to F7 first after GA, but first it needs to land in Linus' tree. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Mon Apr 30 16:18:48 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 30 Apr 2007 12:18:48 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <20070429185749.GB23750@redhat.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> Message-ID: <463616E8.5030100@redhat.com> Dave Jones wrote: > On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote: > > 2.6.21.1 is out ... so whats the plan now? Relase a FC6 > > update(updates-testing) or stick with 2.6.20.x until 2.6.22 is > > out/2.6.21 get some more testing? > > We could do a rebase to .21 this week, and push that out to testing, > and if anything critical turns up before that becomes deemed stable, > we could push a branched build off of .20 directly to updates. > This doesn't make me very confident: http://kernelnewbies.org/known_regressions I'd like to see some kind of stability in FC6 while FC7 continues shaking out 2.6.21 bugs. From fedora at leemhuis.info Mon Apr 30 17:03:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Apr 2007 19:03:45 +0200 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <463616E8.5030100@redhat.com> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <463616E8.5030100@redhat.com> Message-ID: <46362171.3010801@leemhuis.info> Chuck Ebbert schrieb: > Dave Jones wrote: >> On Sun, Apr 29, 2007 at 06:36:32PM +0200, dragoran wrote: >> > 2.6.21.1 is out ... so whats the plan now? Relase a FC6 >> > update(updates-testing) or stick with 2.6.20.x until 2.6.22 is >> > out/2.6.21 get some more testing? >> >> We could do a rebase to .21 this week, and push that out to testing, >> and if anything critical turns up before that becomes deemed stable, >> we could push a branched build off of .20 directly to updates. > > This doesn't make me very confident: > http://kernelnewbies.org/known_regressions Well, didn't we have such bugs in the past, too? We just had no compiled list of them afaik... > I'd like to see some kind of stability in FC6 while FC7 continues > shaking out 2.6.21 bugs. Well, getting a quite stable and working-on-lots-of-machines kernel on the install media of F7 is also quite important imho. /me votes for what davej suggested: "do a rebase to .21 this week, and push that out to testing, and if anything critical turns up before that becomes deemed stable, we could push a branched build off of .20 directly to updates." Add a "send a announcement 'want do help getting the kernel of F7 tested? Then use "yum --enablerepo=updates-testing update kernel*" and report any bugs'" to it. Well, something like that, I don't know if kernel* really works... CU thl From fedora at leemhuis.info Mon Apr 30 17:09:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Apr 2007 19:09:31 +0200 Subject: Pre-release kernel versioning In-Reply-To: <1177947902.3085.103.camel@pmac.infradead.org> References: <463497AE.8040605@leemhuis.info> <1177947902.3085.103.camel@pmac.infradead.org> Message-ID: <463622CB.7040301@leemhuis.info> David Woodhouse schrieb: > On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote: >> In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in >> reality 2.6.21-rc6-git5. That's not only confusing to users, it also >> breaks outside kernel modules sometimes; just yesterday I saw a patch in >> 3rd party repo applied that did this... >> >> +-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) >> ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20) > > Those issues happen when you ship a kernel which is neither 2.6.20 nor > 2.6.21. They don't magically go away if you call it 2.6.21 when in fact > it's only 2.6.21-rc1. Ehh, I'm not a kernel-developer and no real programmer at all, but I can't follow here. Can somebody be so kind and tell me what I missing here? And sure, I fully understand that compiling a external module might break if the API that gets used changes between x, (x+1)-rc1 and (x+1). But that doesn't happen that often. CU thl From davej at redhat.com Mon Apr 30 17:20:56 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 30 Apr 2007 13:20:56 -0400 Subject: Pre-release kernel versioning In-Reply-To: <463622CB.7040301@leemhuis.info> References: <463497AE.8040605@leemhuis.info> <1177947902.3085.103.camel@pmac.infradead.org> <463622CB.7040301@leemhuis.info> Message-ID: <20070430172056.GF18187@redhat.com> On Mon, Apr 30, 2007 at 07:09:31PM +0200, Thorsten Leemhuis wrote: > And sure, I fully understand that compiling a external module might > break if the API that gets used changes between x, (x+1)-rc1 and (x+1). > But that doesn't happen that often. Exactly the opposite, the bulk of the changes happen between x and x+1-rc1 It's neither .20, nor .21 at that point. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Mon Apr 30 18:04:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Apr 2007 20:04:45 +0200 Subject: Pre-release kernel versioning In-Reply-To: <20070430172056.GF18187@redhat.com> References: <463497AE.8040605@leemhuis.info> <1177947902.3085.103.camel@pmac.infradead.org> <463622CB.7040301@leemhuis.info> <20070430172056.GF18187@redhat.com> Message-ID: <46362FBD.6070903@leemhuis.info> Dave Jones schrieb: > On Mon, Apr 30, 2007 at 07:09:31PM +0200, Thorsten Leemhuis wrote: > > > And sure, I fully understand that compiling a external module might > > break if the API that gets used changes between x, (x+1)-rc1 and (x+1). > > But that doesn't happen that often. > Exactly the opposite, the bulk of the changes happen between x and x+1-rc1 > It's neither .20, nor .21 at that point. Argh, my wording was bad. Sure I know that it's changing a lot between X and x+1-rc1. But it doesn't happen often that it changes twice (what was what I was up to). To get back to the specific example to show the annoying problem of the Fedora packaging in more detail: Download madwifi 0.93 from http://sourceforge.net/project/downloading.php?group_id=82936&use_mirror=switch&filename=madwifi-0.9.3.tar.bz2&2919227 Extract it and run this to not get confused by a different problem: sed -i 's|COPTS+=.*-Werror||' Makefile.inc Madwifi 0.93 includes a adjustment that was integrated weeks ago (e.g. weeks before 2.6.21 even was released) to make it compile with both 2.6.20 and 2.6.21. See include/compat.h ; relevant part: #include #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t, 1) #else #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t) #endif Compiling it against a recent 2.6.21 kernel from rawhide works just fine: > $ LC_ALL=C make KERNELPATH=/usr/src/kernels/2.6.21-1.3116.fc7-i686/ KERNELRELEASE=2.6.21-1.3116.fc7 UUDECODE=/usr/bin/uudecode modules > Checking requirements... ok. > Checking kernel configuration... ok. > make -C /usr/src/kernels/2.6.21-1.3116.fc7-i686/ SUBDIRS=/home/thl/tmp/madwifi-0.9.3 modules > make[1]: Entering directory `/usr/src/kernels/2.6.21-1.3116.fc7-i686' > CC [M] /home/thl/tmp/madwifi-0.9.3/ath/if_ath.o [...] > LD [M] /home/thl/tmp/madwifi-0.9.3/net80211/wlan_wep.ko > CC /home/thl/tmp/madwifi-0.9.3/net80211/wlan_xauth.mod.o > LD [M] /home/thl/tmp/madwifi-0.9.3/net80211/wlan_xauth.ko > make[1]: Leaving directory `/usr/src/kernels/2.6.21-1.3116.fc7-i686' > $ echo $? > 0 Compiling it against the kernel from test4, which is nearly the same as the final 2.6.21, fails, because Fedora is playing stupid tricks with version in Makefile: > $ LC_ALL=C make KERNELPATH=/usr/src/kernels/2.6.20-1.3104.fc7-i686/ KERNELRELEASE=2.6.20-1.3104.fc7 UUDECODE=/usr/bin/uudecode modules > Checking requirements... ok. > Checking kernel configuration... ok. > make -C /usr/src/kernels/2.6.20-1.3104.fc7-i686/ SUBDIRS=/home/thl/tmp/madwifi-0.9.3 modules > make[1]: Entering directory `/usr/src/kernels/2.6.20-1.3104.fc7-i686' > CC [M] /home/thl/tmp/madwifi-0.9.3/ath/if_ath.o > cc1: warnings being treated as errors > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_sysctl_halparam': > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9315: warning: comparison of unsigned expression < 0 is always false > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9327: warning: comparison of unsigned expression < 0 is always false > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9337: warning: comparison of unsigned expression < 0 is always false > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_dynamic_sysctl_register': > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9600: error: too many arguments to function 'register_sysctl_table' > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_sysctl_register': > /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9754: error: too many arguments to function 'register_sysctl_table' > make[3]: *** [/home/thl/tmp/madwifi-0.9.3/ath/if_ath.o] Error 1 > make[2]: *** [/home/thl/tmp/madwifi-0.9.3/ath] Error 2 > make[1]: *** [_module_/home/thl/tmp/madwifi-0.9.3] Error 2 > make[1]: Leaving directory `/usr/src/kernels/2.6.20-1.3104.fc7-i686' > make: *** [modules] Error 2 This is just annoying, makes life harder for packagers of kernel-modules in 3rd party repos and confuses users a lot. For no good reason IMHO. CU thl From drago01 at gmail.com Mon Apr 30 18:58:21 2007 From: drago01 at gmail.com (dragoran dragoran) Date: Mon, 30 Apr 2007 20:58:21 +0200 Subject: Pre-release kernel versioning In-Reply-To: <46362FBD.6070903@leemhuis.info> References: <463497AE.8040605@leemhuis.info> <1177947902.3085.103.camel@pmac.infradead.org> <463622CB.7040301@leemhuis.info> <20070430172056.GF18187@redhat.com> <46362FBD.6070903@leemhuis.info> Message-ID: see http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=1618&sid=b96d93357fa5c8f16164a5f64231bd47 they get bugreports which are not bugs but problems caused by fedora's kernel versioning system -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Mon Apr 30 20:45:36 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 30 Apr 2007 16:45:36 -0400 Subject: Keep the FC6 kernel at 2.6.20 or move it to 2.6.21? In-Reply-To: <46362171.3010801@leemhuis.info> References: <46268339.9060900@redhat.com> <4634C990.7010201@gmail.com> <20070429185749.GB23750@redhat.com> <463616E8.5030100@redhat.com> <46362171.3010801@leemhuis.info> Message-ID: <46365570.3060600@redhat.com> Thorsten Leemhuis wrote: > > Well, getting a quite stable and working-on-lots-of-machines kernel on > the install media of F7 is also quite important imho. > > /me votes for what davej suggested: "do a rebase to .21 this week, and > push that out to testing, and if anything critical turns up before that > becomes deemed stable, we could push a branched build off of .20 > directly to updates." > There is another 2.6.20-stable release in the works and I think we should release that for FC5/FC6. The work is already done. In the meantime I've started collecting fixes for 2.6.21 and I think it will be at least decent after a 40-patch or so update (not just a small two patch update like 2.6.21.1.)