Re: Recompile kernel without SMP
On Monday 17 August 2009 20:17:29 Paul Grinberg wrote: > Josh, > > I have a good reason for that. I use Cisco VPN client for Linux, and it > does not work with SMP kernel. I vaguely recall using the cisco vpn client for linux on an smp kernel just fine, but I stopped using it years ago, as vpnc works well enough as a replacement for it. > >Thank you for the reply! Do you know how to "fix" it. What needs to be > >done to compile non-SMP? I do know how, but its semi-involved, and I'm afraid I'm a bit tied up with other slightly more pressing work. Short version is that you need to add a config-foo target in merge.pl, iirc, add that to the spec as another Source, tweak instances of %with_up within the spec file, and that would at least get you close. But again, I think this is really pointless, since 1) I'm pretty sure the cisco vpn client runs fine on smp 2) if it doesn't, vpnc works reasonably well to replace it and 3) you can likely just boot the current smp-enabled kernel with maxcpus=1 added to the command line to get up behavior if you absolutely must run the cisco vpn client in a single-processor environment. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Recompile kernel without SMP
On Friday 14 August 2009 17:24:22 Paul Grinberg wrote:
> Markus,
>
> Thank you for your reply! I already feel better knowing that I'm not
> alone :)
> Maybe someone might have a clue "Why"
Fedora doesn't ship any single-proc kernels anymore except for on
powerpc32. The spec file and sources don't contain an UP target or
the necessary support bits (config-foo) to build one for anything but
powerpc32, because its mostly pointless.
> -Original Message-
> From: Markus Kesaromous [mailto:remotes...@live.com]
> Sent: Friday, August 14, 2009 4:52 PM
> To: Paul Grinberg; Linux Kernel List
> Subject: RE: Recompile kernel without SMP
>
>
> > Date: Fri, 14 Aug 2009 14:35:22 -0400
> > From: pgrinb...@nyc.saic.com
> > To: fedora-kernel-list@redhat.com
> > Subject: Recompile kernel without SMP
> >
> > Hi there,
> >
> > I am trying to recompile kernel without SMP. So far I've been
> > unsuccessful. Meaning I am able to compile, but it was still SMP..
> >
> > Can someone tell me what I am doing wrong?
> > And why I don't get "kernel-headers" build?
> >
> > It is probably related to spec parameters
> >
> > So far this is what I've done:
> >
> > cd ~/
> > rpmdev-setuptree # as regular user
> > cd rmpbuild
> > yumdownloader --source kernel # as regular user
> >
> > cd ~/rpmbuild/BUILD/kernel-2.6.29/linux-2.6.29.i686/
> > cp configs/kernel-2.6.29.6-i586.config .config
> > make menuconfig # console setup
> >
> > Select option: Processor type and features.
> > Disable "Symmetric multi-processing support" (SMP)
> >
> > cp .config ~/rpmbuild/SOURCES/config-i686-generic
> > cp .config ~/rpmbuild/SOURCES/config-i686
> > cd ~/rpmbuild/SPECS
> > nano kernel.spec
> > Add line:
> > % define buildid .NONSMP
> > Replace:
> >
> > # Allow kernel-firmware building
> > #%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
> > %define with_firmware %{?_with_firmware: 0} %{?!_with_firmware: 1}
> >
> > #%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware:
> > 1}
> > %define with_firmware %{?_without_firmware: 1} %{?!_without_firmware:
> > 0}
> >
> > # Allow kernel-headers building
> >
> > # Allow kernel-devel building
> >
> > # Create RPM package
> > rpmbuild -bb --with firmware --target=i686 kernel.spec
> >
> > # To actually install kernel
> > su
> > rpm -ivh kernel-firmware-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
> > kernel-PAE-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
> > kernel-PAE-devel-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
> >
> >
> >
> > Just in case:
> > $ cat config-i686-PAE | egrep -i "smp" | more
> > CONFIG_BROKEN_ON_SMP=y
> > # CONFIG_SMP is not set
> > CONFIG_X86_FIND_SMP_CONFIG=y
> > # CONFIG_X86_VSMP is not set
> > CONFIG_SCSI_SAS_HOST_SMP=y
> > CONFIG_VIDEO_VP27SMPX=m
> >
> >
> >
> >
> >
> > Best,
> > Paul
> >
>
>
>
> I just got bit by a similar problem in trying to build
>
> kernel-2.6.31-0.125.4.2.rc5.git2.fc12.src.rpm
>
> I followed the steps outlined in
>
> http://fedoraproject.org/wiki/Docs/CustomKernel
>
>
>
> I only wanted to build i686 architecture
>
> - without SMP
>
> - without cpu id support
>
> - without multicore support
>
> - without hyperthreading support
>
> - with kernel config support
>
> - with kernel config via /proc support
>
> - with frequency default governor set to Performance
>
> - with preemptible kernel
>
> - with rt2860 module support
>
> - with NTFS read/write support
>
>
>
> Well, it ended up building i686-PAE Debug kernel with SMP support.
>
>
>
> It seems as if the architecture is i686, then only i686 PAE Debug gets
> built.
>
>
>
> I do not know where the problem lies, but SOURCES/Makefile.config
>
> might be the place where the target kernel build is being selected.
>
> To get around it, I edited
> ...SOURCES/Makefile.config and removed all rules and definitions
> pertaining to i686-PAE and only left the simple i686 def and rule.
>
> PS: I do not know if this is necessary, but after I copied .config to
> ...SOURCES/config-i686
> I also copied it to
> ...SOURCES/config-x86-generic
>
> Then running rpmbuild -v -bb --target=i686 kernel.spec
> is proceeding without problems
>
> MK
--
Jarod Wilson
ja...@redhat.com
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel Loading Sequence
On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > Hi all, > > I came across a problem when trying to compile a custom kernel for F11: both > the stock kernel and my custom kernel have i915 modesetting enabled by > default. In the stock kernel the loading screen starts up immediately when > the kernel starts loading, but using the custom kernel, some text is > displayed before the loading screen starts up (the kernel finishes loading > without problems). I'm trying to figure out the reason for this and if > there's a way to fix it so that the user doesn't see this text. Could the > reason be the order in which different parts of the kernel are loaded? If > yes, how can I control which parts load first? Is your 'custom kernel' an F11 kernel + your patches, or starting from an upstream tarball + your patches? (In which case, its lacking all the patches Fedora has added, and therein probably lies your answer to why things are behaving differently). -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: EDAC on AMD with Fedora 10
On Wednesday 15 April 2009 05:13:36 Jeremy Sanders wrote: > Chuck Ebbert wrote: > > > According to the kernel Kconfig file it's only available for old 32-bit > > Athlons, and it is in the i686 kernel(s). > > > > > > config EDAC_AMD76X > > tristate "AMD 76x (760, 762, 768)" > > depends on EDAC_MM_EDAC && PCI && X86_32 > > help > > Support for error detection and correction on the AMD 76x > > series of chipsets used with the Athlon processor. > > Thanks. I didn't realise it was only 32 bit athlons only. > > Any idea what EDAC modules 64 bit Athlon 64s should use? Under RHEL the > k8_edac module provides ECC checking, but this module no longer exists as > far as I can tell in Fedora 10. > > I seems strange that Fedora doesn't support ECC on AMD systems, but RHEL > does! The k8_edac module in RHEL5 is there via an out-of-tree patch. I can't recall why, but upstream had issues with the code, so it has yet to be merged into Linus' kernel, thus the reason its not in the Fedora kernel. CC'ing Aris, who might have a better idea on upstream progress of that code... -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] squashfs broken when pageszie > blocksize
On Tuesday 14 April 2009 08:57:07 Josh Boyer wrote: > On Tue, Apr 14, 2009 at 08:18:40AM -0400, Doug Chapman wrote: > >Not sure if we are too late for F11 on this or not but this patch > >is needed to be able to mount squashfs (as used by anaconda) on > >ia64. Our goal is to be able to build Fedora on ia64 with no > >custom SRPMs so it would be appreciated if this could be pulled > >in. > > It would be needed for ppc64 kernels using a 64KiB pagesize as well > from what I can see. Sounds like a good idea to me. Committed to the F11 branch. Not needed for F10 and earlier, since they're still using squashfs v3, even for the 2.6.29.x builds. Will just let it trickle in via upstream for the devel branch. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] x86: fix DMI for EFI
On Friday 06 March 2009 15:38:40 Brian Maly wrote: > I had attached the patch in my previous post but the patch seems to have > been stripped off once it got posted to the list. > I can forward a patch to whomever needs it if its undesirable to extract > from the commit info. Just let me know what works best. It'll get picked up via an upstream rebase long before then. I saw it last night in rc7-git2, and that or later is bound to be pulled into rawhide long before April (its likely to get in today). -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: File conflicts between alsa-firmware and kernel-firmware
On Saturday 28 February 2009 11:47:57 Tim Jackson wrote: > I maintain alsa-firmware and the following bug regarding file conflicts > between recent versions of kernel-firmware and alsa-firmware got raised today: > > https://bugzilla.redhat.com/show_bug.cgi?id=487873 > > I'm not really familiar with the kernel package maintenance, nor who/what > governs what firmware goes into kernel-firmware (and indeed how that is > related to the upstream kernel). I had a cursory look at the kernel spec > in CVS but that didn't appear to have any relevant recent changes that > were obvious. > > I did a diff between the firmware in alsa-firmware and in > kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although > there are some overlaps, much of the audio firmware in alsa-firmware isn't > in kernel-firmware. > > The current conflicting files are: > > ess/* > korg/* > sb16/* > yamaha/ds1_ctrl.fw > yamaha/ds1_dsp.fw > yamaha/ds1e_ctrl.fw > > Things that are in alsa-firmware but NOT in the above version of > kernel-firmware are: > > asihpi/* > digiface* > 3g* > ea/* > emu/* > mixart/* > multiface* > pcxhr/* > vx/* > yamaha/yss225_registers.bin > [usx2y, which does something funky so it's not in /lib/firmware] > > Either way, it looks like we need to work together on this. > > - I'm happy to just drop the conflicting files from alsa-firmware - is >that the right thing to do? I'd say yes. The versions shipped in the kernel are (supposed to be) known to work with the matching shipped kernel code. > - Are the above audio firmware files in kernel-firmware there to stay? They're put into kernel-firmware as part of the kernel's firmware "build" process, so as long as they're part of the kernel, yeah, they'll be there. > - Is there a long term goal to bring all the firmware from alsa-firmware >upstream into the kernel-firmware package? No clue... Would have to talk to some alsa folks. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Friday 10 October 2008 21:23:34 Dave Airlie wrote: > On Fri, 2008-10-10 at 15:01 -0400, Dave Jones wrote: > > For a while, diffs in the Fedora kernel have followed the form > > > > linux-2.6-*.patch > > > > Then, we started seeing some git snapshots show up as > > > > git-*.diff > > > > and lately, everything seems to have gone bananas, with no > > particular scheme at all.. > > > > nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch > > etc etc. > > > > Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless > > (given that duh, they're all going to be against Linux 2.6), but it > > does group things nicely in an ls output if nothing else. > > > > So, what are peoples thoughts on this? > > The linux-2.6 thing groups nicely for ls, but make tab complete a waste > of time, and is pretty pointless as you say. > > nvidia-agp I apologise for, it just came with that name from upstream, I > meant to rename it to at least agp-nvidia. > > I don't suppose we could use a subdirectory called patches if we want to > keep ls clean.. this being the 21st century :) I vaguely recall trying a test implementation of this at one point, and if I recall correctly, it made rpm very unhappy. However, its been a while, maybe this is doable with the latest rpm and/or maybe my recollections are wrong. A patches subdir would certainly clean things up considerably, and then I think a constant patch name prefix matters a lot less (certainly still could stand to apply some standard formula to naming, of course, but it wouldn't impact tab completion near as much anymore). -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Friday 10 October 2008 20:37:24 Dave Jones wrote: > On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote: > > On Friday 10 October 2008 17:27:00 Chris Snook wrote: > > > Dave Jones wrote: > > > > For a while, diffs in the Fedora kernel have followed the form > > > > > > > > linux-2.6-*.patch > > > > > > > > Then, we started seeing some git snapshots show up as > > > > > > > > git-*.diff > > > > > > > > and lately, everything seems to have gone bananas, with no > > > > particular scheme at all.. > > > > > > > > nvidia-agp.patch, percpu_counter_sum_cleanup.patch, > > > > xfs-barrier-fix.patch etc etc. > > > > > > > > Maybe I'm being overly anal. The linux-2.6- prefix is kind of > > > > pointless (given that duh, they're all going to be against Linux > > > > 2.6), but it does group things nicely in an ls output if nothing > > > > else. > > > > > > > > So, what are peoples thoughts on this? > > > > > > > >Dave > > > > > > If we'd prefix them with the source package name, in this case > > > "kernel", it would make it a lot easier to find things in > > > /usr/src/redhat/SOURCES when we've got SRPMs from different packages > > > installed. We should probably avoid using names that refer to a > > > specific upstream version, because the name becomes misleading once we > > > rebase. When there's a suitable upstream patch name, like the names > > > Andrew Morton uses in -mm, we should probably use those (perhaps > > > prepended with kernel-) to make it clear what it corresponds to > > > upstream. > > > > Yeah, I'd be happy with --.patch, > > omitting the tree id portion if there isn't one, or some variant > > thereof. Being able to do an 'ls kernel*.patch' is definitely useful. > > kernel-* is sacred. Tab completion ftw. :) Ah, good point, s/kernel/linux/ then maybe? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Friday 10 October 2008 17:27:00 Chris Snook wrote: > Dave Jones wrote: > > For a while, diffs in the Fedora kernel have followed the form > > > > linux-2.6-*.patch > > > > Then, we started seeing some git snapshots show up as > > > > git-*.diff > > > > and lately, everything seems to have gone bananas, with no > > particular scheme at all.. > > > > nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch > > etc etc. > > > > Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless > > (given that duh, they're all going to be against Linux 2.6), but it > > does group things nicely in an ls output if nothing else. > > > > So, what are peoples thoughts on this? > > > > Dave > > If we'd prefix them with the source package name, in this case "kernel", it > would make it a lot easier to find things in /usr/src/redhat/SOURCES when > we've got SRPMs from different packages installed. We should probably > avoid using names that refer to a specific upstream version, because the > name becomes misleading once we rebase. When there's a suitable upstream > patch name, like the names Andrew Morton uses in -mm, we should probably > use those (perhaps prepended with kernel-) to make it clear what it > corresponds to upstream. Yeah, I'd be happy with --.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fwd: [PATCH] modprobe: Read module options from kernel command line]
On Wednesday 03 September 2008 00:31:03 Jon Masters wrote: > Hi folks, > > This patch randomly turned up in my inbox this evening and does what was > discussed on IRC the other day, Did you mean to send it along here so we can see too, or are you just taunting us? ;) > so I'll be adding this feature to > module-init-tools...I think it's the least worst option right now. We should definitely all strive for this -- Fedora: we're your least worst option! :D -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] nfs: BUG_ON in nfs_follow_mountpoint
On Wednesday 27 August 2008 12:48:41 Steve Dickson wrote: > Here is a patch that was posted a while back on lkml that does > indeed stop a OOPS I notice that is not in the latest rawhide > kernel... We might want to think about taking this one early due > to the obvious... The patch comments mention Fedora 8... Do we need/want this for the F8 and F9 kernels as well? > From: "Denis V. Lunev" <[EMAIL PROTECTED]> > > Unfortunately, BUG_ON(IS_ROOT(dentry)) can happen inside > nfs_follow_mountpoint with NFS running Fedora 8 using a specific setup. > > See https://bugzilla.redhat.com/show_bug.cgi?id=458622 -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: boot failures on very-large systems with CONFIG_SYSFS_DEPRECATED not set
On Monday 25 August 2008 14:27:16 Doug Chapman wrote: > Sometime leading up to the F9 kernel my very large ia64 system (64 cpu > 1TB ram, bunch of PCI busses and I/O) fails to boot. It appears to be > something in how nash/mkinitrd gets information from sysfs. Since this > is an early boot-time issue and nash isn't very easy to debug I am > having trouble getting to the root of the issue (but I am still > investigating). > > I have however found what change triggered this. The default config > file used to have CONFIG_SYSFS_DEPRECATED=y set. Upstream kernel commit > d47846c5866b7d98a1173c86a39d810a06647329 renamed this to > CONFIG_SYSFS_DEPRECATED_V2. It appears the default is still "y" however > somehow with the transition the Fedora kernel now has this off. > > If possible I would like to see this get set to "y" for now. I will > continue to debug this as it certainly _should_ boot just fine without > this set. Even if we just turn it on for ia64 that works for me (but I > imagine some new big x86_64 systems may run into it once they grow this > large). Just committed the change to flip those on for ia64-only. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: split changelog out of spec
John W. Linville wrote:
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson <[EMAIL PROTECTED]> wrote:
We could also, if so desired, install the split-out changelog as a %doc
file, the thought being that not everyone knows to look at 'rpm -q
--changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
How so?
I presume the rpm command would still work
Correct.
so I would see no harm
in adding the changelog as a %doc (if/when it is broken-out from the
spec file).
Just to be clear... To make sure its 100% clear which kernel the changelog
matches up with, it'd have to be %doc'd for each kernel and kernel-flavour, so
it winds up in /usr/share/doc/kernel%{?flavour:-%{flavour}}-%{version}. If its
part of kernel-doc, I think its not always obvious which actual kernel package
it matches.
With those clarifications, I don't see how it'd be confusing, or how it would
cause any meaningful consistency problems with other distros. But please do
enlighten me if I'm missing something. :)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: split changelog out of spec
Dave Jones wrote:
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
> Hey all,
>
> Been toying with the idea of splitting the changelog out of the kernel spec
> itself, to reduce the size of the spec file. Basically, instead of %changelog
> followed by all the entries, it'd be %include %{SOURCE1}, which is a file
> 'fedora-kernel-changelog', which carries all the usual changelog entries. Its
> reasonably trivial to implement, though my current hack-around for 'make clog'
> complains about me redefining the clog target. Is shaving 800+ lines out of
> the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck.
It'd be nice if 'make build' slurped the changelog out of the SCM.
I stupidly left out the part where I was supposed to mention that what I had
in mind longer-term was that it'd be more straight-forward to manipulate a
stand-alone changelog, esp. if we could just dump the changelog out of our
SCM. (Some of what Don and Vivek are doing for RHEL w/git is what motivated me
in the first place).
We could also, if so desired, install the split-out changelog as a %doc file,
the thought being that not everyone knows to look at 'rpm -q --changelog'
output or look in the srpm/cvs/etc to see what's changed.
John W. Linville wrote:
> I don't see how. What is the motivation?
Apologies, see above. :)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
RFC: split changelog out of spec
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec
itself, to reduce the size of the spec file. Basically, instead of %changelog
followed by all the entries, it'd be %include %{SOURCE1}, which is a file
'fedora-kernel-changelog', which carries all the usual changelog entries. Its
reasonably trivial to implement, though my current hack-around for 'make clog'
complains about me redefining the clog target. Is shaving 800+ lines out of
the spec file (only to put them in another file) worth the hassle though?
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: > Chuck Ebbert wrote: > > Steve Dickson wrote: > >> Now that devel kernels rpms require the kernel-firmware rpm, it makes > >> sense to me that one should be able to build both of them at the same > >> time. So this patch adds the "--with firmware" build option > >> which will allow kernel-firmware rpms to built with kernel rpms. > >> > >> This patch also adds the "--without vdso_install" build option > >> which stop the VDSO binaries from being installed. This cuts > >> down the overall build time especially when you build over NFS > >> like I do.. > >> Signed-Off-By: Steve Dickson <[EMAIL PROTECTED]> > > > > With one small change we can still support --without firmware. That way > > the default behavior can be overridden in either case. See below... > > Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Monday 30 June 2008 05:54:32 am Richard Hughes wrote: > Right, cheers for your feedback. In view of everybodies comments, what > about the following: > > * Compile _into_ the kernel ondemand, performance, powersave and > userspace. Sounds reasonable. > * Default to performance in the kernel rather than userspace What's the difference? Both leave the cpu at its max speed all the time, unless the cpuspeed daemon gets started up in the userspace case. > * Build as a module conservative with the view of just fixing ondemand > if there are any special use-cases that conservative is better at > * Export the P and C state latency to userspace and let the system > policy dictate the governor. For instance, even for machines that have a > long latency for changing P states should be able to use ondemand if we > want to save maximum power. > > How does that sound? Mostly sane. System policy dictating governor over the ugliness we do in the cpuspeed init script would be nice. Even nicer would be if we could outright get rid of the initscript (not sure what people who need the cpuspeed daemon are to do in that case though). -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? Not sure. What happens in such cases today? Have to install a new kernel or kmod? A stub kernel? Ew. Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk? Could get messy, littering /boot with old initrds that aren't cleaned up, and your bootloader with extra entries you may never use -- what would trigger their removal and when? I just assume leave out the auto-rebuilding of the initrd though. I think if you know you need/want new firmware for a device, you should be able to figure out how to create a new initrd with it (and save the old initrd as a fallback). I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that. Yeah, I sent a follow-up email saying the same, didn't take that into account until after hitting send, and my unsend button never seems to work... :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jarod Wilson wrote: We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. But of course, you've still got a system that at least boots, and can back-rev the firmware if needed, so not a big issue vs. boot-path-dependent firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jon Masters wrote: On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote: On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :) Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package. And that of course is a nicer fix, yeah, then people can have their own per-device firmware package if they choose to do so. Coolness. Yeah, something like /lib/firmware/updates/ sounds gravy. I was initially thinking we could have a kernel-firmware package that was a meta-package, pulling in umpteen individual firmware packages (a la xorg-x11-drivers), but I like this idea better. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of this could be done sans-udev in some particular case. Just requiring udev does sound like the way to go then. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Yeah, seems the sanest thing to do at least initially, so people don't suddenly wind up with non-functional devices. Should the package own the /lib/firmware/ directory? Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote: > Been playing with how I'd make the kernel package deal with the new > 'make firmware_install' stuff. Currently looks something like this. > > I suspect that (for now) we should make the kernel binary packages > depend on kernel-firmware? > > Should the package own the /lib/firmware/ directory? > > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get > that until we start to build it from a separate srpm. > > Other comments? We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: how to recompile/rebuild fedora core 7 kernel
On Saturday 24 May 2008 03:11:04 am Nooruddin Dar wrote: > i have linux-2.6.25.tar.bz2 kernel source > i want to rebuild it and also want to add a system call in the kernel > if any one knows about that plz reply > i will wait for ur response This: http://fedoraproject.org/wiki/BuildingUpstreamKernel and this: http://fedoraproject.org/wiki/Docs/CustomKernel should help. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson
On Saturday 03 May 2008 10:35:37 pm Jarod Wilson wrote: > On Saturday 03 May 2008 12:37:22 am Koji Build System wrote: > > Package: kernel-2.6.25.1-1.fc10 > > Tag: dist-f10 > > Status: failed [...] > > Failed tasks: > > - > > > > Task 593871 on ppc4.fedora.phx.redhat.com > > Task Type: build (dist-f10, devel:kernel-2_6_25_1-1_fc10) > > > > Task 593873 on ppc4.fedora.phx.redhat.com > > Task Type: buildArch (kernel-2.6.25.1-1.fc10.src.rpm, ppc) > > logs: > > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=build.log > > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=root.log > > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=state.log > > Anyone have any idea why the ppc build tanked like this? Will have to try a > mock build once I have my ppc box back up and running in the new office... Never mind, Roland's fixes in -3 fixed it. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson
On Saturday 03 May 2008 12:37:22 am Koji Build System wrote: > Package: kernel-2.6.25.1-1.fc10 > Tag: dist-f10 > Status: failed > Built by: jwilson > ID: 47960 > Started: Sat, 03 May 2008 03:42:41 UTC > Finished: Sat, 03 May 2008 04:20:53 UTC > Changelog: > * Fri May 02 2008 Jarod Wilson <[EMAIL PROTECTED]> 2.6.25.1-1 > - Linux 2.6.25.1 > - Drop patches merged in 2.6.25.1: > * linux-2.6-netdev-tehuti-check-register-size.patch > * > linux-2.6-netdev-tehuti-move-ioctl-perm-check-closer-to-function-start.patc >h * linux-2.6-selinux-ssinitialized-bugon.patch > * bits of wireless patches > > * Thu May 01 2008 Dave Airlie <[EMAIL PROTECTED]> 2.6.25-14 > - fix radeon fast-user-switch oops + i915 breadcrumb oops > > * Wed Apr 30 2008 Chuck Ebbert <[EMAIL PROTECTED]> 2.6.25-13 > - Fix drive detection on some Macbook models (#439398) > - Fix oops in RAID code (#441765) > > > > kernel-2.6.25.1-1.fc10 (47960) failed on ppc4.fedora.phx.redhat.com > (noarch), ppc4.fedora.phx.redhat.com (ppc): BuildrootError: error building > package (arch ppc), mock exited with status 1 SRPMS: > kernel-2.6.25.1-1.fc10.src.rpm > > Failed tasks: > - > > Task 593871 on ppc4.fedora.phx.redhat.com > Task Type: build (dist-f10, devel:kernel-2_6_25_1-1_fc10) > > Task 593873 on ppc4.fedora.phx.redhat.com > Task Type: buildArch (kernel-2.6.25.1-1.fc10.src.rpm, ppc) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=state.log Anyone have any idea why the ppc build tanked like this? Will have to try a mock build once I have my ppc box back up and running in the new office... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fwd: Apport]
On Friday 02 May 2008 05:54:55 pm Tom "spot" Callaway wrote: > Passing this along for consideration. iirc, Will Woods was working on making this usable with Fedora a while back... > Forwarded Message > > > From: James Westby <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Apport > > Date: Fri, 02 May 2008 21:58:23 +0100 > > > > Hi all, > > > > I just wanted to let you all know about a little package that we > > use in Ubuntu that may benefit other distributions. This package > > is called "apport". > > > > Apport is an automatic bug reporting tool. It does a number of things, > > the main one of which is to pop up on crashes of system programs. > > To do this it installs a kernel core pattern in > > /proc/sys/kernel/core_pattern that pipes core files to it (available > > since the .23 kernel I believe). This writes out a .crash file to > > /var/crash. The user is then notified with a notification icon and > > libnotify message that something has crashed. Clicking on the icon > > tells them what and offers to report a bug. > > > > For Ubuntu this opens a new bug in launchpad with all the information, > > and then opens the page in the users web browser for them to provide > > more details. > > > > It also hooks in to python failures somehow to provide the same service, > > and also has intergration with update-manager so that you can report a > > bug if a package installation/upgrade fails. > > > > Some people may be disturbed by the thought of the flood of bugs that > > would be generated. You're right, it does generate a lot of > > bug reports, but there are a few things that make it worthwhile. > > > > Firstly, it's only active for development releases, as it's easiest > > to fix the bugs then, and those users will generally be more equipped > > to provide the necessary information. > > > > Secondly, and this is what makes apport so great, it can detect > > duplicates by itself. It takes the core file, enters a chroot, > > and using some magic it "retraces" the bug report, using full symbol > > table information. > > > > This means that it can detect duplicates on it's own and mark them as > > such, and also that without the users having to have debugging symbols > > in their executable, or know what gdb is, provide full backtraces. > > > > In addition to this a package can provide an apport script that gathers > > information from a user's system before reporting the bugs. For instance > > Firefox can report all of the extensions that the user has installed. > > > > It is obviously currently quite specific to Ubuntu, however it is surely > > possible to make it work on other systems as well, and I'm sure Martin > > would be happy to merge patches that did that. You can find more details > > about the project at > > > > https://wiki.ubuntu.com/Apport > > > > and the code at > > > > https://launchpad.net/apport > > > > I think other distributions would do well to look at it, and even if you > > don't want to use it in your distribution there may be ideas that you > > want to take. > > > > Does anyone else already have a system like this? Are there any aspects > > that are covered by other tools used in your distro? Can anyone see > > anything that would make it even better? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling a module outside kernel
On Wednesday 30 April 2008 11:28:15 am Robert M. Albrecht wrote: > Hi Sam, > > I have a problem in compiling a kernel module > (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. > > [EMAIL PROTECTED] toshiba_acpi]# ll > insgesamt 24 > -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile > -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c > > [EMAIL PROTECTED] toshiba_acpi]# make > make: F?r das Ziel ?default? ist nichts zu tun. > > [EMAIL PROTECTED] toshiba_acpi]# cat Makefile > obj-m := toshiba_acpi.o > > KDIR := /lib/modules/$(shell uname -r)/build > PWD := $(shell pwd) > > default: > $(MAKE) -C $(KDIR) M=$(PWD) modules > > [EMAIL PROTECTED] toshiba_acpi]# > > Nothing happens. Has the Makefile to be changed for F9 or do I make a > stupid mistake ? The Makefile looks correct at a glance... Do you kernel-devel installed? If not, build will be a dangling symlink... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-xen f9 spec update
On Tuesday 01 April 2008 10:09:17 am Mark McLoughlin wrote:
> On Mon, 2008-03-31 at 09:52 +0200, Mark McLoughlin wrote:
>
> > On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote:
> >
> > > We recently tweaked the main kernel package's spec file such that we now
> > > include arch in uname -r output, and have standardized a bunch of path
> > > names
> > > to match. Completely forgot about kernel-xen in the process, until
> > > yesterday,
> > > when I started porting everything over the the kernel-xen-2.6/devel spec.
> > >
> > > The attached spec patch has been build-tested, with some manual
> > > inspection of
> > > the resulting packages, but hasn't yet been run-time tested for possible
> > > issues (none expected, but you never know...). I'll happily help out with
> > > any
> > > possible issues if you guys could give this a spin.
> > >
> > > Definitely want this in ASAP so the kernel and kernel-xen bits stay
> > > mostly in
> > > sync (speaking of which, there's also some rpmposttrans stuff -- dkms
> > > hooks -- which went into the main kernel spec a bit ago that I don't see
> > > in
> > > the kernel-xen-2.6 spec
> >
> > Thanks for the heads-up and the patch. I'm planning on rebasing
> > kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so
> > we'll pick up all this stuff.
>
> Okay, kernel-xen in rawhide is rebased to 2.6.25-0.182.rc7.git6 if you
> want to take a look.
Apologies if this is a dupe, X is being a tad crashy on me today... Looks much
better, but a few places where %{KVERREL}xen should be changed to
%{KVERREL}.xen to be consistent with the other flavoured kernels.
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel-xen-2.6/devel/kernel.spec,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 kernel.spec
--- kernel.spec 1 Apr 2008 12:52:48 - 1.26
+++ kernel.spec 1 Apr 2008 14:42:34 -
@@ -1519,8 +1519,8 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd %{xen_hv_dirname}/xen/
mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
make %{?_smp_mflags} %{xen_flags}
- install -m 644 xen.gz
$RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}xen
- install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}xen
+ install -m 644 xen.gz
$RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}.xen
+ install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}.xen
cd ../..
%endif
%endif
@@ -1588,8 +1588,8 @@ cd linux-%{kversion}.%{_target_cpu}
%if %{includexen}
%if %{with_xen}
mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d
-rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf
-cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf <<\EOF
+rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
+cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf <<\EOF
# This directive teaches ldconfig to search in nosegneg subdirectories
# and cache the DSOs there with extra bit 0 set in their hwcap match
# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
@@ -1597,7 +1597,7 @@ cat > $RPM_BUILD_ROOT/etc/ld.so.conf.d/k
# in the ld.so.cache file.
hwcap 0 nosegneg
EOF
-chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf
+chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
%endif
%endif
@@ -1744,7 +1744,7 @@ fi}\
%if %{with_xen}
%kernel_variant_preun xen
-%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen
-a ! -e /proc/xen/xsd_kva ] || echo
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}xen`
+%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen
-a ! -e /proc/xen/xsd_kva ] || echo
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}.xen`
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
@@ -1842,7 +1842,7 @@ fi
%kernel_variant_files %{with_pae} PAE
%kernel_variant_files %{with_pae_debug} PAEdebug
%kernel_variant_files -k vmlinux %{with_kdump} kdump
-%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}xen -e
/etc/ld.so.conf.d/kernelcap-%{KVERREL}xen.conf %{with_xen} xen
+%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen -e
/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %{with_xen} xen
%changelog
* Tue Apr 1 2008 Mark McLoughlin <[EMAIL PROTECTED]>
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch to remove utrace patch for ia64
On Tuesday 01 April 2008 10:40:02 am Doug Chapman wrote: > As discussed in another thread the utrace support for ia64 is not > complete upstream yet. The current utrace patch breaks building on > ia64. To allow us to continue progress on ia64 can we apply this patch > until these issues are resolved? Done. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 05:39:47 pm Roland McGrath wrote:
> > On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
> > > I had a fix for this test-building when I went to watch some schlock TV
> > > last night and forgot to check on it and commit before I went to bed.
> > >
> > > This was my .spec diff. The regexp has three chars different from your
> > > version.
> > >
> > > +%{expand:%%global debuginfo_args %{?debuginfo_args} -p
> > > '/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?'
> > > -o debuginfo%{?1}.list}\ ^
> >
> > Gah. Now, in your email, the ^ pointed to the ? in debuginfo%{?1}.list,
> > while when quoted (and rewrapped by kmail), it pointed at the ?
> > in %%{KVERREL}%{?1:.?%{1}}... And I'm not 100% certain which one you were
> > actually questioning now.
>
> In fact, it pointed at the last (third) ? in
>
> %%{KVERREL}%{?1:.?%{1}}?/.*
>
> The two that you thought I might have been referring to are both correct.
>
> > From a later reply, looks like actually the one in debuginfo%{?1}.list,
> > which is necessary, so that for the base kernel, we get debuginfo.list.
> > At least, I think that's the case, no?
>
> That ? is an rpm macro syntax ? and none of those should change.
>
> > So I *think* this would do now:
> >
> > %{expand:%%global debuginfo_args %{?debuginfo_args} -p
> > '/.*/%%{KVERREL}%{?1:\.%{1}}/.*|/.*%%{KVERREL}%{?1:\.%{1}}(\.debug)?' -o
> > debuginfo%{?1}.list}\
>
> Note, I unwrapped the line from your message. If you don't use an MUA that
> lets you be positive what the actual bytes in the message were, let alone
> send the actual bytes you intended, we are not going to be able to discuss
> this in email.
Gah. kmail sometimes does interesting things, and I failed to compensate... Now
I see how I hit
both my mistakes. Stupidly, kmail's 'view source' option doesn't use a fixed
width font by default,
and I've had it set to hard-wrap at 78 chars. I think both of those can be
remedied...
> The line quoted above is only one char different from my version.
> You have removed the ? that did not belong (right before /.* as I cited
> above).
>
> You also removed another one that I did not remove. That one permitted
> either %{KVERREL}.flavor or %{KVERREL}flavor to match. I think that one is
> indeed no longer needed. It was originally -? rather than \.? and was to
> match /lib/modules/RELflavor as well as /usr/src/kernels/REL-flavor
> when that was how they looked.
>
> So, I think the line quoted above is now correct.
Committed, thanks for bearing with me. :)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
> I had a fix for this test-building when I went to watch some schlock TV
> last night and forgot to check on it and commit before I went to bed.
>
> This was my .spec diff. The regexp has three chars different from your
> version.
>
> +%{expand:%%global debuginfo_args %{?debuginfo_args} -p
> '/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
> debuginfo%{?1}.list}\ ^
Gah. Now, in your email, the ^ pointed to the ? in debuginfo%{?1}.list, while
when quoted (and rewrapped by kmail), it pointed at the ?
in %%{KVERREL}%{?1:.?%{1}}... And I'm not 100% certain which one you were
actually questioning now.
>From a later reply, looks like actually the one in debuginfo%{?1}.list, which
is necessary, so that for the base kernel, we get debuginfo.list. At least, I
think that's the case, no?
So I *think* this would do now:
%{expand:%%global debuginfo_args %{?debuginfo_args} -p '/.*/%%{KVERREL}%{?1:\.
%{1}}/.*|/.*%%{KVERREL}%{?1:\.%{1}}(\.debug)?' -o debuginfo%{?1}.list}\
Since we have the arch in all the paths as part of KVERREL, no need to worry
about paths with or without %{_target_cpu} in 'em.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
> I had a fix for this test-building when I went to watch some schlock TV
> last night and forgot to check on it and commit before I went to bed.
>
> This was my .spec diff. The regexp has three chars different from your
> version.
>
> +%{expand:%%global debuginfo_args %{?debuginfo_args} -p
> '/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
> debuginfo%{?1}.list}\ ^
>
> what's that ? for?
I wondered that myself, but it was already there... Might have been a typo I
inserted earlier. Yanking it works for me.
> The other differences are \. instead of . for matching
> literal . in two places.
Ah, that's even better. Forgot this is essentially regex passed down to
find-debuginfo.sh... I'll drop the ? and add the \'s.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 01:17:59 pm Jarod Wilson wrote: > On Monday 31 March 2008 03:00:00 am Ananth N Mavinakayanahalli wrote: > > Hi, > > > > Updating my rawhide box, I found: > > > > kernel-debuginfo i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 47 k > > kernel-debuginfo-common i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo > > 486 M > > > > - Did anything in the F9 builds change that lead to this more than > > two-fold increase in the debuginfo size? > > - Or is it that the "common" rpm needs updation once every kernel > > release with just "updates" for every update to the same release > > thereafter? > > There's a problem with some of the changes I made to add arch to our uname > -r output screwing with debuginfo a bit. The size isn't double though. > > Before > -- > kernel-debuginfo: ~198M > kernel-debuginfo-common: ~32M > > Now > --- > kernel-debuginfo: 47k > kernel-debuginfo-common: 230M > > So same size overall, I just haven't got all the bits getting into the > right sub-packages. Working on fixing that now. Got a fix committed to kernel-2.6.25-0.178.rc7.git6.fc9. This gets us back to: 199M kernel-debuginfo.x86_64: 199M kernel-debuginfo-common.x86_64: 31M -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:00:00 am Ananth N Mavinakayanahalli wrote: > Hi, > > Updating my rawhide box, I found: > > kernel-debuginfo i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 47 k > kernel-debuginfo-common i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo > 486 M > > - Did anything in the F9 builds change that lead to this more than > two-fold increase in the debuginfo size? > - Or is it that the "common" rpm needs updation once every kernel > release with just "updates" for every update to the same release > thereafter? There's a problem with some of the changes I made to add arch to our uname -r output screwing with debuginfo a bit. The size isn't double though. Before -- kernel-debuginfo: ~198M kernel-debuginfo-common: ~32M Now --- kernel-debuginfo: 47k kernel-debuginfo-common: 230M So same size overall, I just haven't got all the bits getting into the right sub-packages. Working on fixing that now. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
arch-in-uname tweaks (was: rpms/kernel/devel...)
On Wednesday 26 March 2008 09:19:56 am Thorsten Leemhuis wrote:
[...]
> >> Just wondering: If we are working in this area why not finally chose one
> >> of the two variants ("%{KVERREL}-$Flavour" or "%{KVERREL}$Flavour") and
> >> stick to it everywhere as well? Or even use a "." as delimiter here as
> >> well?
> >> Then the duplication due to the "if [ -n "$Flavour" ]" could be removed
> >> in this area of the spec file by using something like this everywhere:
> >> DevelDir=/usr/src/kernels/%{KVERREL}${Flavour:+-${Flavour}}
> >
> > I thought about trying to yank that extra symlink and the if clause, but
> > wasn't sure exactly what they were there for, so I didn't want to cause
> > any further breakage...
>
> Understood.
>
> > But yeah, I'd be all for simplifying there, if its not
> > going to cause someone/something headaches.
>
> +1 -- let's remove it and see what breaks; we can easily re-add later if
> it's needed somewhere
>
> > To be consistent with the rest of
> > the paths laid down, it really should be %{KVERREL}${Flavour} without any
> > "-" or "."
>
> +1
>
> > (unless we also change all the other paths to also use "-" or ".".)
>
> Hmmm. This would look cleaner IMHO. But it likely would create even more
> trouble for kmods and other kernel module stuff. But as there are
> adjustments needed already due to the other changes it might be a good
> idea to do this change now as well.
>
> But I'm not really sure if that's really worth the effort.
I'm trying out a local build now that eliminates the DevelLink and uses your
suggestion above for DevelDir, and makes use of %{KVERREL}-%{Flavour} right
now, which as discussed on irc, looks more correct to both of us. :)
i.e., this changes uname -r for kernel-PAE from 2.6.25-1.fc9.i686PAE to
2.6.25-1.fc9.i686-PAE, and all paths laid down are changed accordingly.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel kernel.spec, 1.537, 1.538 linux-2.6-firewire-git-pending.patch, 1.22, 1.23
On Wednesday 26 March 2008 03:01:29 am Thorsten Leemhuis wrote:
> One comment:
>
> On 25.03.2008 21:43, Jarod Wilson (jwilson) wrote:
> > Author: jwilson
> >
> > Update of /cvs/pkgs/rpms/kernel/devel
> > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22927
> >
> > Modified Files:
> > kernel.spec linux-2.6-firewire-git-pending.patch
> > Log Message:
> > * Tue Mar 25 2008 Jarod Wilson <[EMAIL PROTECTED]>
> > - Put %{_target_cpu} into kernel uname, and tack it onto assorted
> > files and directories. Makes it possible to do parallel installs
> > of say both i686 and x86_64 kernels of the same version on x86_64
> > x86_64 hardware (#197065).
> > [...]
> > Index: kernel.spec
> > ===
> > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
> > retrieving revision 1.537
> > retrieving revision 1.538
> > diff -u -r1.537 -r1.538
> > --- kernel.spec 25 Mar 2008 18:42:30 - 1.537
> > +++ kernel.spec 25 Mar 2008 20:42:18 - 1.538
> > [...]
> > @@ -1243,11 +1243,11 @@
> > # Pick the right config file for the kernel we're building
> > if [ -n "$Flavour" ] ; then
> >Config=kernel-%{version}-%{_target_cpu}-$Flavour.config
> > - DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour-%{_target_cpu}
> > - DevelLink=/usr/src/kernels/%{KVERREL}$Flavour-%{_target_cpu}
> > + DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour
> > + DevelLink=/usr/src/kernels/%{KVERREL}$Flavour
>
> Just wondering: If we are working in this area why not finally chose one
> of the two variants ("%{KVERREL}-$Flavour" or "%{KVERREL}$Flavour") and
> stick to it everywhere as well? Or even use a "." as delimiter here as
> well?
>
> Then the duplication due to the "if [ -n "$Flavour" ]" could be removed
> in this area of the spec file by using something like this everywhere:
>
> DevelDir=/usr/src/kernels/%{KVERREL}${Flavour:+-${Flavour}}
I thought about trying to yank that extra symlink and the if clause, but
wasn't sure exactly what they were there for, so I didn't want to cause any
further breakage... But yeah, I'd be all for simplifying there, if its not
going to cause someone/something headaches. To be consistent with the rest of
the paths laid down, it really should be %{KVERREL}${Flavour} without any "-"
or "." (unless we also change all the other paths to also use "-" or ".".)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 03:28:37 pm Jarod Wilson wrote:
> On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote:
> > On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:
> > > On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
> > > > On 25.03.2008 13:47, Jarod Wilson wrote:
> > > > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
> > > > >> On 24.03.2008 20:53, Jarod Wilson wrote:
> > > > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> > > > >>>> I took a stab at bz 197065 and arrived at the patch below.
> > > > >>>> Would appreciate some eyeballs before I commit from people
> > > > >>>> familiar with the macro goo in the specfile. (Hi Roland!)
[...]
> Crap, disregard that version. Things blow up on flavo{,u}red builds,
> because the flavo{,u}r gets inserted between the f9 and .arch instead of
> after arch (the ppc64 build blew up on kdump bits). So a teeny bit more
> spec hackage required, but its still doable.
Fixed up version committed and building. I think I'll go on vacation now... :)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote:
> On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:
> > On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
> > > On 25.03.2008 13:47, Jarod Wilson wrote:
> > > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
> > > >> On 24.03.2008 20:53, Jarod Wilson wrote:
> > > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> > > >>>> I took a stab at bz 197065 and arrived at the patch below.
> > > >>>> Would appreciate some eyeballs before I commit from people
> > > >>>> familiar with the macro goo in the specfile. (Hi Roland!)
>
> [...]
>
> > Test build up and running:
> >
> > [EMAIL PROTECTED] x86_64]# ls /boot/*.x86_64*
> > /boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64
> > /boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img
> > /boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64
> > /boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64
> >
> > [EMAIL PROTECTED] x86_64]# uname -r
> > 2.6.25-0.152.rc6.git7.fc9.x86_64
> >
> > [EMAIL PROTECTED] x86_64]# ls /lib/modules/
> > 2.6.25-0.152.rc6.git7.fc9.x86_64
> >
> > [EMAIL PROTECTED] x86_64]# ls /usr/src/kernels/
> > 2.6.25-0.152.rc6.git7.fc9.x86_64
>
> And here's the patch I came up with for the above:
Crap, disregard that version. Things blow up on flavo{,u}red builds, because
the flavo{,u}r gets inserted between the f9 and .arch instead of after arch
(the ppc64 build blew up on kdump bits). So a teeny bit more spec hackage
required, but its still doable.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:
> On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
> > On 25.03.2008 13:47, Jarod Wilson wrote:
> > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
> > >> On 24.03.2008 20:53, Jarod Wilson wrote:
> > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> > >>>> I took a stab at bz 197065 and arrived at the patch below.
> > >>>> Would appreciate some eyeballs before I commit from people
> > >>>> familiar with the macro goo in the specfile. (Hi Roland!)
[...]
> Test build up and running:
>
> [EMAIL PROTECTED] x86_64]# ls /boot/*.x86_64*
> /boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64
> /boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img
> /boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64
> /boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64
>
> [EMAIL PROTECTED] x86_64]# uname -r
> 2.6.25-0.152.rc6.git7.fc9.x86_64
>
> [EMAIL PROTECTED] x86_64]# ls /lib/modules/
> 2.6.25-0.152.rc6.git7.fc9.x86_64
>
> [EMAIL PROTECTED] x86_64]# ls /usr/src/kernels/
> 2.6.25-0.152.rc6.git7.fc9.x86_64
And here's the patch I came up with for the above:
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.536
diff -u -p -r1.536 kernel.spec
--- kernel.spec 25 Mar 2008 03:19:46 - 1.536
+++ kernel.spec 25 Mar 2008 16:52:04 -
@@ -135,7 +135,7 @@ Summary: The Linux kernel (the core of t
%define xen_target vmlinuz
%define xen_image vmlinuz
-%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
+%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}.%{_target_cpu}
%define hdrarch %_target_cpu
%if 0%{!?nopatches:1}
@@ -1243,11 +1243,11 @@ BuildKernel() {
# Pick the right config file for the kernel we're building
if [ -n "$Flavour" ] ; then
Config=kernel-%{version}-%{_target_cpu}-$Flavour.config
- DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour-%{_target_cpu}
- DevelLink=/usr/src/kernels/%{KVERREL}$Flavour-%{_target_cpu}
+ DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour
+ DevelLink=/usr/src/kernels/%{KVERREL}$Flavour
else
Config=kernel-%{version}-%{_target_cpu}.config
- DevelDir=/usr/src/kernels/%{KVERREL}-%{_target_cpu}
+ DevelDir=/usr/src/kernels/%{KVERREL}
DevelLink=
fi
@@ -1259,11 +1259,11 @@ BuildKernel() {
CopyKernel=cp
fi
-KernelVer=%{version}-%{release}$Flavour
+KernelVer=%{version}-%{release}$Flavour.%{_target_cpu}
echo BUILDING A KERNEL FOR $Flavour %{_target_cpu}...
# make sure EXTRAVERSION says what we want it to say
-perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION =
%{?stablerev}-%{release}$Flavour/" Makefile
+perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION =
%{?stablerev}-%{release}$Flavour.
%{_target_cpu}/" Makefile
# if pre-rc1 devel kernel, must fix up SUBLEVEL for our versioning scheme
%if !0%{?rcrev}
@@ -1585,7 +1585,7 @@ then\
fi\
if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ]\
then\
-(cd /usr/src/kernels/%{KVERREL}-%{?1:%{1}-}%{_target_cpu} &&\
+(cd /usr/src/kernels/%{KVERREL}%{?1:-%{1}} &&\
/usr/bin/find . -type f | while read f; do\
hardlink -c /usr/src/kernels/*.fc*-*/$f $f\
done)\
@@ -1719,8 +1719,8 @@ fi
%{?-e:%{-e*}}\
%{expand:%%files %{?2:%{2}-}devel}\
%defattr(-,root,root)\
-%verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\
-/usr/src/kernels/%{KVERREL}%{?2}-%{_target_cpu}\
+%verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:-%{2}}\
+/usr/src/kernels/%{KVERREL}%{?2}\
%if %{with_debuginfo}\
%ifnarch noarch\
%if %{fancy_debuginfo}\
@@ -1734,7 +1734,7 @@ fi
%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\
%endif\
%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\
-%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\
+%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}\
%endif\
%endif\
%endif\
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
> On 25.03.2008 13:47, Jarod Wilson wrote:
> > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
> >> On 24.03.2008 20:53, Jarod Wilson wrote:
> >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> >>>> I took a stab at bz 197065 and arrived at the patch below.
> >>>> Would appreciate some eyeballs before I commit from people
> >>>> familiar with the macro goo in the specfile. (Hi Roland!)
> >
> > [...]
> >
> >>>> -install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
> >>>> -install -m 644 System.map
> >>>> $RPM_BUILD_ROOT/boot/System.map-$KernelVer -touch
> >>>> $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
> >>>> +install -m 644 .config
> >>>> $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} +install -m 644
> >>>> System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} +
> >>>> touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
> >>>
> >>> For the sake of consistency, [...]
> >>
> >> For the sake of consistency we IMHO should use the same delimiter
> >> between "$(uname -r)" and arch in all places. E.g. either "." (like
> >> quoted above) everywhere or a "-", like we already use in the devel
> >> packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
> >
> > One thing I like about using "." over "-" is that you'd get
> > 2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with
> > what rpm -q outputs, now that we're defaulting to outputting n-v-r.arch.
>
> Sounds good. Or, IOW: I'm fine with using "." as delimiter, if we use it
> for the directories found in the devel packages as well.
>
> This whole idea of course means that there are some adjustments needed
> for kmods in livna (or other kernel module packaging schemes). That
> shouldn't be to hard; doing it for F9 might be a bit late, but if you
> guys really want to go that route I'm sure we'll find a way to deal with
> it before F9 ships.
>
> CU
> knurd
Test build up and running:
[EMAIL PROTECTED] x86_64]# ls /boot/*.x86_64*
/boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img
/boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# uname -r
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /lib/modules/
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /usr/src/kernels/
2.6.25-0.152.rc6.git7.fc9.x86_64
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
> On 24.03.2008 20:53, Jarod Wilson wrote:
> > On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> >> I took a stab at bz 197065 and arrived at the patch below.
> >> Would appreciate some eyeballs before I commit from people
> >> familiar with the macro goo in the specfile. (Hi Roland!)
[...]
> >> -install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
> >> -install -m 644 System.map
> >> $RPM_BUILD_ROOT/boot/System.map-$KernelVer -touch
> >> $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
> >> +install -m 644 .config
> >> $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} +install -m 644
> >> System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} +
> >> touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
> >
> > For the sake of consistency, [...]
>
> For the sake of consistency we IMHO should use the same delimiter
> between "$(uname -r)" and arch in all places. E.g. either "." (like
> quoted above) everywhere or a "-", like we already use in the devel
> packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
One thing I like about using "." over "-" is that you'd get
2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what
rpm -q outputs, now that we're defaulting to outputting n-v-r.arch.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 06:36:49 pm Roland McGrath wrote:
[...]
> All this suggests to me that the only thing we really can make fly is to
> include the differentiator in EXTRAVERSION. It will be noticeable to
> users and probably draw a lot of questions and look redundant in many
> places that display the arch too. But it would not be any new can of
> worms on technical grounds.
That's basically the conclusion I came to too, and I've got a 2-line spec
patch (actually also using %{_target_cpu} instead of %{_arch}) that I'm
prodding at. Definitely way too many things that'll go boom if its not there
after some discussion on irc (and on this list).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
> I took a stab at bz 197065 and arrived at the patch below.
> Would appreciate some eyeballs before I commit from people
> familiar with the macro goo in the specfile. (Hi Roland!)
>
> Aparently pm-utils will need a change to cope with the changed
> filename, but I think that should be the limit of the damage.
> (oprofile will need to append the archname on the end of System.map-$ver
> filenames, but they're user-passed anyway, and not coded anywhere afaik
> Hmm. Not sure about Systemtap).
>
> Comments?
Yep!
> -install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
> -install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
> -touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
> +install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
> +install -m 644 System.map
> $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
> +touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, I'd try to keep $KernelVer and %{_arch} together.
The above would give
us for example config-2.6.25-1.fc9.x86_64, System.map-2.6.25-1.fc9.x86_64 and
initrd-2.6.25-1.fc9.img.x86_64. I'd make the initrd either
initrd-2.6.25-1.fc9.x86_64.img or
initrd.img-2.6.25-1.fc9.x86_64.
> -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
> %{KVERREL}%{?-v*} || exit
$?\
> +/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
> %{KVERREL}%{?-v*}.
%{_arch} || exit $?\ %{nil}
I suspect this will make new-kernel-package very unhappy, since I think its
expecting to be fed what
essentially amounts to $(uname -r).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pls enable CONFIG_MODULE_SRCVERSION_ALL=y
On Tuesday 18 March 2008 10:10:17 pm Matt Domsch wrote: > On Sat, Feb 16, 2008 at 09:55:04AM -0600, Matt Domsch wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=427311 > > > > The kernel does not use CONFIG_MODULE_SRCVERSION_ALL=y, which prevents > > modules that don't use MODULE_VERSION() tags from getting a srcversion > > field in their modinfo. DKMS uses the srcversion field to determine > > if a module is exactly the same or not. It would benefit from having > > srcversion enabled for all modules. Ubuntu and openSUSE enable this > > option. > > Just reminding folks of this request. Doesn't look like it'll cause us any problems, so... Following the 'its easier to ask for forgiveness than to ask for permission' paradigm, I just flipped it on in rawhide, so next build spit out of koji will have it, barring someone beating me with a cluebat and turning it back off... :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bug 384281: acpi-cpufreq reports ENODEV on Q6600
On Wednesday 20 February 2008 10:36:12 am davide rossetti wrote: > On Feb 20, 2008 4:11 PM, Jarod Wilson <[EMAIL PROTECTED]> wrote: > > On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: > > > As soon as I unwrapped my brand new Core 2 Quad, I discovered that > > > acpi-cpufreq seems not able to offer its services :( the point is why > > > ? is there anything (code, debugging, testing) I can do to support it > > > (or its BIOS) ? > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=384281 > > > > Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% > > certain the fault lays with the bios. HP has been notorious about > > shipping bioses with broken linux cpufreq support... I'd look for a bios > > update, and if you can't find one, yell at HP. :) > > isn't there something low-level, driving the CPU/chipset registers directly > ? Like... The BIOS? :) Seriously, the acpi-cpufreq driver needs good data from the BIOS's ACPI tables to be able to do anything. Try booting with 'cpufreq.debug=7' added to your kernel boot params, and you should get some more data on why its failing to work, but pretty sure its the BIOS at fault. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bug 384281: acpi-cpufreq reports ENODEV on Q6600
On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: > As soon as I unwrapped my brand new Core 2 Quad, I discovered that > acpi-cpufreq seems not able to offer its services :( the point is why > ? is there anything (code, debugging, testing) I can do to support it > (or its BIOS) ? > > https://bugzilla.redhat.com/show_bug.cgi?id=384281 Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% certain the fault lays with the bios. HP has been notorious about shipping bioses with broken linux cpufreq support... I'd look for a bios update, and if you can't find one, yell at HP. :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Another question on module unloading
On Wednesday 20 February 2008 09:25:46 am Matt Domsch wrote: > On Wed, Feb 20, 2008 at 04:20:33PM +0200, Eugene Goubine wrote: > >Where can I get an information about the order in which the modules > > are unloaded > >when the system shuts down.I am writing a module which is going to be > > sort of networking protocol > >so the unloading order is crucial for me. > > In general, kernel modules are not unloaded at system shutdown. > > If they are unloaded, that's done so by the initscripts of various > programs. A quick grep 'modprobe -r' /etc/init.d/* shows that > cpuspeed, ip6tables, ip6tables, and lm_sensors initscripts (on my > system) unload kernel modules. Nb: in the cpuspeed case, the module unloads aren't on shutdown either. They're done when we try loading a cpufreq driver that we think will work on the system, but it doesn't find supported hardware. Rather than leaving a useless module loaded, we do some clean-up in this case. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Monday 11 February 2008 02:01:01 pm Kyle McMartin wrote: > On Mon, Feb 11, 2008 at 01:54:25PM -0500, Jarod Wilson wrote: > > On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: > > > git trees: > > > firewire - commented out, pending didn't apply > > > > Yeah, the pending bits depend on some bits that are in linux1394-git that > > haven't yet made their way over to Linus, I believe. Figure I'll just fix > > things up after the rebase. > > if you want, you can attach a diff here and i'll put it into the first > upload, or commit it with something like pending-rc1.patch or something > and i'll move it when we update. Didn't get back around to it until the new bits were already in cvs, but have since fixed things up, so its all good now. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: > git trees: > firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 03:47:26 pm Jarod Wilson wrote: > On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: > > On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > > > Roland, I don't suppose any of the recent changes I seem to recall > > > > hearing you were going to make to debuginfo might have anything to do > > > > with this... > > > > > > Seems unlikely since I haven't actually made any yet. > > > > D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) > > Chuck figured it out. The output of file 4.23 when looking at unstripped > binaries changed, which broke find-debuginfo.sh... :\ Okay, I should just go home. My head hurts like hell right now, and I can't seem to get anything right... It seems the new file only has issues with .ko files, other binaries it reports on as it always has. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: > On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > > Roland, I don't suppose any of the recent changes I seem to recall > > > hearing you were going to make to debuginfo might have anything to do > > > with this... > > > > Seems unlikely since I haven't actually made any yet. > > D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) Chuck figured it out. The output of file 4.23 when looking at unstripped binaries changed, which broke find-debuginfo.sh... :\ -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: > > Roland, I don't suppose any of the recent changes I seem to recall > > hearing you were going to make to debuginfo might have anything to do > > with this... > > Seems unlikely since I haven't actually made any yet. D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 11:05:44 am Jarod Wilson wrote: > Roland, I don't suppose any of the recent changes I seem to recall hearing > you were going to make to debuginfo might have anything to do with this... Further prodding reveals its not a case of us winding up with extra files in the package or anything like that, its simply that none of the bits are stripped. Still poking at things trying to understand why... # file libata.ko libata.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped > -- Forwarded Message -- > > Subject: Re: rawhide report: 20080130 changes > Date: Wednesday 30 January 2008 > From: Jarod Wilson <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > On Wednesday 30 January 2008 10:57:18 am Jarod Wilson wrote: > > On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > > > Hi. > > > > > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > > > kernel-2.6.24-9.fc9 > > > > --- > > > > * Tue Jan 29 2008 John W. Linville <[EMAIL PROTECTED]> > > > > - A few more wireless fixes for 2.6.25 > > > > - Some post-2.6.25 wireless updates > > > > - Actually, we support the new b43 firmware... > > > > > > the -PAE package for this is 202MB in size, which can't be right. > > > > Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and > > kernel.ppc are all in the 200MB range. kernel.x86_64 and kernel.ppc64 > > look fine though. Investibigating... > > Something is horked with debug stripping. All the massive kernels have > unnaturally small -debuginfo packages. We'll get that fixed... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Fwd: Re: rawhide report: 20080130 changes
Roland, I don't suppose any of the recent changes I seem to recall hearing you were going to make to debuginfo might have anything to do with this... --jarod -- Forwarded Message -- Subject: Re: rawhide report: 20080130 changes Date: Wednesday 30 January 2008 From: Jarod Wilson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] On Wednesday 30 January 2008 10:57:18 am Jarod Wilson wrote: > On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > > kernel-2.6.24-9.fc9 > > > --- > > > * Tue Jan 29 2008 John W. Linville <[EMAIL PROTECTED]> > > > - A few more wireless fixes for 2.6.25 > > > - Some post-2.6.25 wireless updates > > > - Actually, we support the new b43 firmware... > > > > the -PAE package for this is 202MB in size, which can't be right. > > Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and kernel.ppc > are all in the 200MB range. kernel.x86_64 and kernel.ppc64 look fine > though. Investibigating... Something is horked with debug stripping. All the massive kernels have unnaturally small -debuginfo packages. We'll get that fixed... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.24
On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: > Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly > soon? Chuck was talking about branching in cvs to start doing 2.6.24 builds for at least F8 as soon as possible for people to test w/o committing to an immediate upgrade from 2.6.23, but I'd assume if testing goes well with 2.6.24, we'll move to it fairly soon. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
Christopher Brown wrote: > On 21/01/2008, Adam Jackson <[EMAIL PROTECTED]> wrote: >> http://people.freedesktop.org/~ajax/kernel-autopatch.patch >> >> Based on something I did for the xserver specfile. Essentially this >> makes it so you only have to name the patches once, in the order you >> want to apply them, which makes it both easier to work with and harder >> to forget things. >> >> I've tried to make this as friendly and robust as possible, including >> bailing out appropriately when faced with a bad patch, and explicitly >> naming patches that fail to apply right at the end of build output. >> Feedback would be appreciated, even if it's of the form "no, that's >> gross." > > Can't speak from an implementation point of view but you must be a > mind-reader. Several people will appreciate the thought behind it, > myself included. On #fedora-kernel recently: > > i really find it irritating that i need to edit Patchxx: *and* > add an ApplyPatch. > * kylem ponders converting the spec file to use quilt. > fark > not a fan of that either > why not j-rod ? > I think he meant he's not a fan of editing twice. > not that he wasn't a fan of quilt. > oh > i always forget to do one or the other :\ First glance says oh hell yeah, check it in. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: tpm_infineon=m for config-ia64
Matt Anderson wrote: > Bill Nottingham wrote: >> Dave Jones ([EMAIL PROTECTED]) said: >>> No objection either, though it's worth noting that there's no userspace >>> support in Fedora for any of the TPM kernel stuff. >> >> It's there in rawhide (tpm_tools, trousers) > > So is this something that can just be enabled, or would you like me to > open a bugzilla for this? Kyle already did it. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: tpm_infineon=m for config-ia64
Dave Jones wrote: On Thu, Jan 17, 2008 at 06:59:05PM -0500, Kyle McMartin wrote: > On Thu, Jan 17, 2008 at 06:49:51PM -0500, Matt Anderson wrote: > > I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but > > config-ia64 does not. I enabled that on my system and rebuild the kernel > > rpm and everything just worked. Could tpm_infineon be built as a module by > > default for ia64? > > > > er, sure, i guess. No objection either, though it's worth noting that there's no userspace support in Fedora for any of the TPM kernel stuff. However, I believe trousers has been submitted for fedora review, and was close to being accepted if it hasn't been already. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IIDC camera's and the juju firewirestack
Jarod Wilson wrote: > Jarod Wilson wrote: >> Hans de Goede wrote: >>> In the thread I started about Fedora perhaps being to cutting edge, it >>> was said that I shouldn't complain as there is only one problem left >>> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. >> Oh, there's definitely more than one problem left... :) > >>> Further analysis of the problem has learned that this is not true, I'm >>> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. >> The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 >> mode doing dv capture. iidc is much less tested. I already know where at >> least >> a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting >> you... I've also got an idea or two on what's up with dv capture, just need >> to >> get the spare cycles to test (which could happen shortly, just finished a >> major piece of lirc...) > >>> However most documents talk about using the juju stack with either >>> harddisks or DV for homevideo camera's. However I'm trying to use an >>> industrial cam which used the IIDC protocol, and support in the new juju >>> stack (kernel + userspace) for the IIDC protocol isn't very good. >> I believe David Moore's patch in linux1394-2.6.git[*] should help, and it >> looks like that also needs to be ported over to the OHCI 1.0 code paths... > > Nope, looks like he's already done that too. As I said in another thread, I'm > going to try to start tracking the linux1394 git tree in rawhide, and > selectively pull back patches into released kernels. David's done a lot of > excellent work of late while I was busy not paying attention, due to the > holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) After a bit of positive testing, I committed a linux1394 git patch plus David's dynamic buffer alloc patch, which is about to be in linux1394 git, to the rawhide kernel. We've now got working iidc streaming on all OHCI 1.0 and 1.1 cards, so far as I know. I'll see about back-porting these bits to the F7 and F8 kernels as well. Would definitely like to hear what *doesn't* work now, short of dv capture with Via VT630x OHCI 1.0 cards, which is known broken and under investigation. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [libdc] IDCC camera's & firewire juju stack
Jarod Wilson wrote: > David Moore wrote: >> On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >>> No, according to what several people saw with VT630x in OHCI 1.0 mode, >>> there is still the bug that the DMA program stops after receiving one or >>> a few frames. This is 100% reproducible with coriander + IIDC camera >>> and dvgrab + DV camcorder. >>> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >>> >>> As far as I understood, this presumably happens because the problem >>> which David Moore addressed with "fw-ohci: Fix for dualbuffer >>> three-or-more buffers" is also present but unfixed in the >>> packet-per-buffer code. >> I thought I had fixed that in my "fw-ohci: Bug fixes for >> packet-per-buffer support" patch > > That's what I was thinking/hoping, but... > >> but maybe it's still not working perfectly yet. > > ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm > working with right now. :( On the positive side, I *do* have coriander displaying video from a Unibrain Fire-i hooked to this same controller now, so the remaining problems appear to be dv-specific. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [libdc] IDCC camera's & firewire juju stack
David Moore wrote: > On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >> No, according to what several people saw with VT630x in OHCI 1.0 mode, >> there is still the bug that the DMA program stops after receiving one or >> a few frames. This is 100% reproducible with coriander + IIDC camera >> and dvgrab + DV camcorder. >> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >> >> As far as I understood, this presumably happens because the problem >> which David Moore addressed with "fw-ohci: Fix for dualbuffer >> three-or-more buffers" is also present but unfixed in the >> packet-per-buffer code. > > I thought I had fixed that in my "fw-ohci: Bug fixes for > packet-per-buffer support" patch That's what I was thinking/hoping, but... > but maybe it's still not working perfectly yet. ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm working with right now. :( > I'm running out of ideas for why that still might not > work so further testing or insights would be appreciated. I'm rather short on ideas too. I was really hoping the dynamic buffer allocation patch might help too, thinking maybe these cards were just exhausting the buffer and getting wedged, but no dice. Oh, I should also mention that I get some lockdep spew w/the dynamic buffer alloc patch added to the mix... (will get that report over to you via linux1394-devel though) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [libdc] IDCC camera's & firewire juju stack
Stefan Richter wrote: > Hans de Goede wrote: >> Thanks for all the help, I have it working now by building a 2.6.23 kernel >> with >> the patchset from here applied: >> http://me.in-berlin.de/~s5r6/linux1394/updates/ >> >> Then it works if I lower the number of buffer passed to >> dc1394_capture_setup() >> to 2, after also applying this patch: >> http://marc.info/?l=linux1394-devel&m=119965813322642 ? >> >> This is no longer needed and even coriander (from cvs) works fine! >> >> This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for >> this pci card), should the above patches be enough to also get it to work in >> 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if >> that >> will also work. I can take care of testing on an VT6306 OHCI 1.0 controller, as well as a VT6307 OHCI 1.0 controller. Just bumping to the latest linux1394 git code wasn't enough to get dv capture working (via dvgrab) on one of my VT6307 1.0 controllers, but I'm about to give it a go with the addition of David's dynamic buffer allocation patch. > No, according to what several people saw with VT630x in OHCI 1.0 mode, > there is still the bug that the DMA program stops after receiving one or > a few frames. This is 100% reproducible with coriander + IIDC camera > and dvgrab + DV camcorder. > https://bugzilla.redhat.com/show_bug.cgi?id=415841 > > As far as I understood, this presumably happens because the problem > which David Moore addressed with "fw-ohci: Fix for dualbuffer > three-or-more buffers" is also present but unfixed in the > packet-per-buffer code. I can probably get a similar fix added on top of the packet-per-buffer code today, if it is indeed still needed. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IIDC camera's and the juju firewirestack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jarod Wilson wrote: > Hans de Goede wrote: >> In the thread I started about Fedora perhaps being to cutting edge, it >> was said that I shouldn't complain as there is only one problem left >> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. > > Oh, there's definitely more than one problem left... :) > >> Further analysis of the problem has learned that this is not true, I'm >> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. > > The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 > mode doing dv capture. iidc is much less tested. I already know where at least > a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting > you... I've also got an idea or two on what's up with dv capture, just need to > get the spare cycles to test (which could happen shortly, just finished a > major piece of lirc...) > >> However most documents talk about using the juju stack with either >> harddisks or DV for homevideo camera's. However I'm trying to use an >> industrial cam which used the IIDC protocol, and support in the new juju >> stack (kernel + userspace) for the IIDC protocol isn't very good. > > I believe David Moore's patch in linux1394-2.6.git[*] should help, and it > looks like that also needs to be ported over to the OHCI 1.0 code paths... Nope, looks like he's already done that too. As I said in another thread, I'm going to try to start tracking the linux1394 git tree in rawhide, and selectively pull back patches into released kernels. David's done a lot of excellent work of late while I was busy not paying attention, due to the holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) - -- Jarod Wilson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmdDtO+bni+75QMRAuXMAKCpQrPfZlS0fGOLqU4Lg2HRk2KxLACgy6xP yNP1JUzpzhAlOE5eGH6h4Go= =DZkp -END PGP SIGNATURE- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IIDC camera's and the juju firewirestack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: > In the thread I started about Fedora perhaps being to cutting edge, it > was said that I shouldn't complain as there is only one problem left > with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Oh, there's definitely more than one problem left... :) > Further analysis of the problem has learned that this is not true, I'm > using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 mode doing dv capture. iidc is much less tested. I already know where at least a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting you... I've also got an idea or two on what's up with dv capture, just need to get the spare cycles to test (which could happen shortly, just finished a major piece of lirc...) > However most documents talk about using the juju stack with either > harddisks or DV for homevideo camera's. However I'm trying to use an > industrial cam which used the IIDC protocol, and support in the new juju > stack (kernel + userspace) for the IIDC protocol isn't very good. I believe David Moore's patch in linux1394-2.6.git[*] should help, and it looks like that also needs to be ported over to the OHCI 1.0 code paths... > As the consensus from the other thread seems to be that having 2 > parallel stacks is not a good plan, I have decided to spend some time to > get the IIDC situation with the juju stack improved. However I'm pretty > new to all this, so I will need a couple of pointers to get me up to speed. Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now... > I've been testing with the grab_gray_image example from libdc1394-2.0.0. > The problem is that it hangs at the dc1394_capture_dequeue(camera, > DC1394_CAPTURE_POLICY_WAIT, &frame) call. > > The camera does seem to be sending data, as its activity led is flickering. > > Any clues for further debugging this would be much appreciated That git patch would be the first step. I'll look at doing similar for OHCI 1.0, as well as testing out an idea I had wrt dv capture on OHCI 1.0... > shall I put this in bugzilla? Might as well. Some of it is already there, but nothing iidc-specific yet. > If so against which component? I'd file it against kernel, but assign it to me and cc [EMAIL PROTECTED] and [EMAIL PROTECTED] [*] http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commitdiff;h=e9f5ca46377ac60a6b7d52c6c19a1661c87c6e20 - -- Jarod Wilson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhjlqtO+bni+75QMRAptqAJ4ndhFsNe9yyHVzjKVv7Mlzq7wHbACg0FFB eOsRcGVaAUtv7QbgEus+np4= =K0/M -END PGP SIGNATURE- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
Thomas J. Baker wrote: > On Thu, 2007-12-06 at 16:47 -0500, Jarod Wilson wrote: >> Thomas J. Baker wrote: >>> I've got a Precision 490 that hangs at reboot unless I use reboot=bios >>> on the kernel command line. A bug filed against the kernel should >>> include what other information? >> I might suggest looking for a BIOS update and/or downgrade before you >> file any bugs. I've got a Precision 490 here that reboots just peachy. >> Dell actually has bios updates that can be done from Linux on these boxes. >> > > I'm running the latest BIOS as it was shipped with the machine. I'd > rather use reboot=bios than run an old BIOS. Sorry, I was suggesting it more as a "see if this is a bios issue and not a kernel issue" than "fix it by running an old bios". Did you see Roland's note about his own 490? He said his only fails to reboot when running an i386 kernel, but works fine w/an x86_64 kernel, which doesn't conflict with what I've seen, since mine's also running an x86_64 kernel. He also mentioned that this started sometime between 2.6.22 and 2.6.23. If you are indeed running a 32-bit kernel, it sounds like an i686-specific kernel bug. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
Thomas J. Baker wrote: > I've got a Precision 490 that hangs at reboot unless I use reboot=bios > on the kernel command line. A bug filed against the kernel should > include what other information? I might suggest looking for a BIOS update and/or downgrade before you file any bugs. I've got a Precision 490 here that reboots just peachy. Dell actually has bios updates that can be done from Linux on these boxes. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: ALSA versions in the Fedora kernel
Dave Jones wrote: > On Mon, Nov 19, 2007 at 12:58:55PM -0500, Chuck Ebbert wrote: > > Here's a proposal for what version of ALSA we deliver with our kernel: > > > > Fedora 7 will stay with the version it has, 1.0.14, which is being > > maintained with stable patches by the ALSA team. > > > > Fedora 8 will stay with 1.0.15 and only merge carefully selected bug fixes > > from upstream ALSA. > > > > Fedora 9 / devel will track upstream ALSA development so we can shake out > > bugs as soon as possible. This can be done by carrying the git-alsa-mm > > patch from the -mm kernel. > > Sounds good to me. Likewise. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How can I develop loadable module for Fedora 7 and later?
Cary Fu wrote: > When I tried to build a loadable module for Fedora 7, there are lots of > error warning came up regarding the line of #include . > Is there anyone knows where can I find the information about making a > loadable module for Fedora 7. Thanks in advance for any input. Just take a look at the source to any of the umpteen modules in the kernel... May also want to visit http://kernelnewbies.org/. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Adding a pointrelease option to the spec
Chuck Ebbert wrote:
> This might be useful for people building their own kernels:
>
> --- kernel.spec 12 Nov 2007 22:05:50 - 1.237
> +++ kernel.spec 13 Nov 2007 17:05:39 -
> @@ -12,7 +12,16 @@
> # that the kernel isn't the stock distribution kernel, for example,
> # by setting the define to ".local" or ".bz123456"
> #
> +# You may also add a "pointrelease" with or without the "buildid"
> +# so that your locally built kernel gets a version number that
> +# is higher than the kernel it is based on and lower than the
> +# next offical Fedora release.
> +#
> #% define buildid .local
> +#% define pointrelease .1
> +%if 0{?pointrelease}
> +%define buildid {pointrelease}{?buildid}
> +%endif
>
> # fedora_build defines which build revision of this kernel version we're
> # building. Rather than incrementing forever, as with the prior versioning
I generally just use buildid for the same, i.e., I set buildid to .xyz1,
.xyz2, .xyz3, etc as I rebuild a newer versions. I think its probably
not worth the extra lines added to the spec file (which, by the way, in
the example above, are missing a bunch of % symbols before the {. :)
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: help! My re-compiled kernel always got crashed in a machine with scsi/sata disk
Feng Xian wrote: > Thanks! Now I know what confused me. What I downloaded was linux > kernel from "Linux Archive" website instead of fedora source from > redhat. I used to believe that these two sources are the same. From > your message, they are apparently different. As far as the code itself goes, we try to stay as close to upstream as possible. We start with the upstream kernel tarball and apply some patches and our own kernel config from there. Generally, if you take an upstream tarball and just use the Fedora kernel config, you'll get a booting system (usually works for me, anyhow). -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: help! My re-compiled kernel always got crashed in a machine with scsi/sata disk
Feng Xian wrote: > I downloaded a clean version of 2.6.23 and didnt do any modification on > it (athough I am about to modify it in the future). By default, the > clean version doesnt enable sata features, so I enabled these features > and compiled this clean version. But I couldn't boot linux with the > compiled kernel like I mentioned in my previous posts. Like I said, its not a Fedora kernel, and thus not something we can reasonably support here. The only possible list-relevant bit of info here would be knowing *why* you're building your own, such that we can make the Fedora kernel provide what you need so you don't have to, if possible and/or relevant. That said, seeing as how a Fedora kernel does boot your system, you'll probably get a lot closer to a bootable system with your own kernel if you start with the Fedora kernel config file instead of the upstream kernel config file, and go from there. > On 11/12/07, *Jarod Wilson* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Feng Xian wrote: > > Thanks for all your help. I ran into another problem. > > > > My 16-core machine has a scsi/sata disk. I have enabled all important > > features related with scsi and sata. I built 2.6.23 kernel on this > > machine. But the kernel always got crashed randomly. Sometimes it > > couldnot even boot, reporting some random errors, like "segment > > violation, sleep for 40 seconds", or "Group volume VolGroup00 uses > lvm2 > > metadata: read-only", then jump to a strange login window that I > cannot > > log in using my root password. > > > > Another thing is that Linux works perfect if I installed Fecore > Core 7 > > on this multi-core machine with scsi/sata disk. Why it didnt work if I > > used re-compiled kernel. I guess it is because I didnt config kernel > > right (although I enabled all important features related with > scsi/sata) > > in "make menuconfig". If you happen to know how to enable scsi/sata > > features correctly, please let me know. Thanks! > > I don't think this is the correct forum for this question. This list is > targeted at issues surrounding the Fedora kernel, and you're building > your own kernel. Once you start building your own, with a config that > obviously differs significantly from the Fedora config, we can't > realistically provide support here. > > Furthermore, I'm not quite sure I understand why you think you need to > build your own kernel either. To be bluntly honest, if you can't figure > out what's going wrong there on your own, you probably shouldn't be > building your own. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: help! My re-compiled kernel always got crashed in a machine with scsi/sata disk
Feng Xian wrote: > Thanks for all your help. I ran into another problem. > > My 16-core machine has a scsi/sata disk. I have enabled all important > features related with scsi and sata. I built 2.6.23 kernel on this > machine. But the kernel always got crashed randomly. Sometimes it > couldnot even boot, reporting some random errors, like "segment > violation, sleep for 40 seconds", or "Group volume VolGroup00 uses lvm2 > metadata: read-only", then jump to a strange login window that I cannot > log in using my root password. > > Another thing is that Linux works perfect if I installed Fecore Core 7 > on this multi-core machine with scsi/sata disk. Why it didnt work if I > used re-compiled kernel. I guess it is because I didnt config kernel > right (although I enabled all important features related with scsi/sata) > in "make menuconfig". If you happen to know how to enable scsi/sata > features correctly, please let me know. Thanks! I don't think this is the correct forum for this question. This list is targeted at issues surrounding the Fedora kernel, and you're building your own kernel. Once you start building your own, with a config that obviously differs significantly from the Fedora config, we can't realistically provide support here. Furthermore, I'm not quite sure I understand why you think you need to build your own kernel either. To be bluntly honest, if you can't figure out what's going wrong there on your own, you probably shouldn't be building your own. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How to build smp kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Feng Xian wrote: > Hi, > > I had a 16-core machine and tried to build a smp version of > linux-2.6.23 kernel. I did the following steps: > > 1. make menuconfig ( actually I didt change the configuration since it > builds SMP support by default) All of our x86 and x86_64 kernels are smp-aware, there is no separate smp kernel, the same kernel is used for single-processor and multi-processor systems. > 2. make; make modules; make modules_install; make install > > But the final image file is vmlinuz-2.6.23, not vmlinuz-2.6.23smp. Is > this final image a real smp kernel? If not, do i need to apply > patches. Thanks! In the past when we did have a separate kernel-smp package (actually, we still do for ppc32), the 'smp' was inserted by part of the rpm build process, it doesn't happen automagically, just because you enabled smp in the kernel config. - -- Jarod Wilson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHN5CdtO+bni+75QMRAsORAJsHxl06Z/pqEttj085JP5qPXOanIACgxO4m 4t55vz3JJAOfcWpo1Gcnf5c= =BzxM -END PGP SIGNATURE- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
Chuck Ebbert wrote: On 10/23/2007 06:28 PM, Dave Jones wrote: > Are the addresses in System.map accurate? On the F7 2.6.23 kernel, > I had to subtract 0x40 and add 0x100 to the address in an > oops message to get an address to use with eu-addr2line. Relocatable kernel is another thing that really screws with this. CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x40 CONFIG_PHYSICAL_START=0x100 Address in oops was c04622db. I had to use "eu-addr2line -e vmlinux 0xc10622db" And objdump just flat refuses to show line number information from vmlinux containing debug info. (But on Fedora 8 it will.) I vaguely recall seeing a bug about this one, and I thought the solution was to set _ALIGH and _START to the same value, but these are only vague recollections... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Building a kernel "--without debuginfo" is kind of broken
Chuck Ebbert wrote:
I got a 160MB kernel package and discovered that the kernel and
modules contained debug info. This seems to fix it, does anyone
see a problem with it?
make -s mrproper
cp configs/$Config .config
+%if !%{with_debuginfo}
+perl -p -i -e 's/^CONFIG_DEBUG_INFO=y$/# CONFIG_DEBUG_INFO is not set/'
.config
+%endif
Arch=`head -1 .config | cut -b 3-`
echo USING ARCH=$Arch
I believe at one point in the past, debuginfo was still getting
stripped, just not packaged, with that option. Then things changed
around a bit, and with that option, stripping didn't happen. The above
seems like a sane remedy to me.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
Dave Jones wrote: > On Thu, Sep 27, 2007 at 09:11:38PM +0100, Christopher Brown wrote: > > It would appear Macbook Pro users need to additionally press the fn key to > > make F1 - F10 work as expected under Linux. Therefore to switch to a vt > they > > have to perform a wierd kind of hand twister to get it to work as it now > > requires Ctrl+Alt+Fn+F1. Just as an fyi, this is also the case on my 2+ year old PowerBook G4. And I'm pretty sure it was also the case on the iBook I had prior to that, which I got roughly 5 years ago. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling Secure Computing (SECCOMP)
Chuck Ebbert wrote: > We have a bug report requesting that we enable SECCOMP: > > https://bugzilla.redhat.com/show_bug.cgi?id=295841 > > I suggest we enable it in Fedora 8 but leave it disabled in F7. > That way we're not changing a config item in a stable release, > and we don't have to carry patches to lower the feature's > overhead and make its API match 2.6.23's. Saw that one too. Turning it on just in F8 sounds sane to me. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Jarod Wilson wrote: Its been added to the build, and is working its way through the build system right now. Local build worked, but that was just one arch and variant, so here's hoping it makes it through the gamut. Ran into a hiccup on ppc64, but got that ironed out, and the second try just finished building for all arches and flavors. http://koji.fedoraproject.org/packages/kernel/2.6.23/0.142.rc3.git10.fc8/ -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Jarod Wilson wrote: > All of the work Eric and I did over the weekend is now in a proper git > tree, which can be browsed (and cloned) here: > > http://git.wilsonet.com/linux-2.6-lirc.git/ I restructured the order of commits a bit, so if anyone did a checkout before noon eastern US time, you probably want to throw it away and start over. > A few more clean-ups and we'll slap this puppy into an actual rawhide > kernel build to start getting some wider testing... Its been added to the build, and is working its way through the build system right now. Local build worked, but that was just one arch and variant, so here's hoping it makes it through the gamut. Still need to get more feedback from upstream LIRC to see how they want to move forward with this (query submitted, awaiting reply), since the git tree is already starting to diverge a bit... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Jarod Wilson wrote: > Eric Sandeen wrote: >> Jarod Wilson wrote: >>> Hey all, >>> >>> So... As I've mentioned on various forums here and there in the >>> recent past, I'd really like to see fedora carry the lirc drivers >>> (http://www.lirc.org/) in-kernel, and help push them into the >>> upstream kernel. I finally got around to doing something significant >>> about it this evening. The link below is the completion of my first >>> attempt at a patch tailored for upstream, based partially on work >>> done by Mario Limonciello for Ubuntu (cc'd). >>> >>> http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch >> >> Cool, I tossed a few build-related fixes (warnings, deprecated >> interfaces/flags, etc..) on top of this up at >> >> http://people.redhat.com/esandeen/lirc/ > > Very nice. Gah, at least one of those fixes some things I screwed up > merging in the latest bits from cvs... > >> (There's also usb stuff going on I don't understand in the commandir >> driver :) but with the warning about the callback it will probably >> explode when run.) > > Hrm, that's not so good... I was thinking of seeing if I could find one > somewhere for cheap, but ouch, those things look pricey... > > http://www.commandir.com/order/ > >> Also given that each subdir under drivers/input/lirc generally has just >> one .c file, I'd probably flatten it out, and drop everything into >> drivers/input/lirc/*.c > > Yeah, that idea crossed my mind too after I'd sent the mail off before > drifting off to sleep. I'll do that for the next rendition. > >> Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - >> perhaps each individual driver should just do "select LIRC_DEV" rather >> than "depends on?" and remove the prompt for LIRC_DEV? > > Sounds like a good idea to me. All of the work Eric and I did over the weekend is now in a proper git tree, which can be browsed (and cloned) here: http://git.wilsonet.com/linux-2.6-lirc.git/ A few more clean-ups and we'll slap this puppy into an actual rawhide kernel build to start getting some wider testing... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Eric Sandeen wrote: Jarod Wilson wrote: Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch Cool, I tossed a few build-related fixes (warnings, deprecated interfaces/flags, etc..) on top of this up at http://people.redhat.com/esandeen/lirc/ Very nice. Gah, at least one of those fixes some things I screwed up merging in the latest bits from cvs... (There's also usb stuff going on I don't understand in the commandir driver :) but with the warning about the callback it will probably explode when run.) Hrm, that's not so good... I was thinking of seeing if I could find one somewhere for cheap, but ouch, those things look pricey... http://www.commandir.com/order/ Also given that each subdir under drivers/input/lirc generally has just one .c file, I'd probably flatten it out, and drop everything into drivers/input/lirc/*.c Yeah, that idea crossed my mind too after I'd sent the mail off before drifting off to sleep. I'll do that for the next rendition. Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - perhaps each individual driver should just do "select LIRC_DEV" rather than "depends on?" and remove the prompt for LIRC_DEV? Sounds like a good idea to me. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[RFC PATCH] lirc IR receiver drivers
Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch It includes all the latest bits from lirc cvs, save the lirc_gpio driver, which doesn't compile of late, but restructures the code in a few ways: 1) header include paths have been altered to match the file layout as patched into the kernel tree 2) in theory, all '#if LINUX_VERSION_CODE' and similar bits have been eliminated, along with all code sections for older kernels dropped, which trims down the patch by over 1000 lines and definitely makes it more manageable. 3) a few minor changes from the upstream code base to compile with the latest rawhide gcc (a few "error: void value not ignored as it ought to be" messages, which I've not yet properly fixed). -- I've done a local x86_64 test build with this patch against 2.6.23-rc3-git6, which upon initial inspection, looks good, though I have yet to try it out on actual hardware (on my todo list this weekend). See resulting build file listing below. If deemed appropriate, I'd like to slap this patch into the rawhide kernel builds as soon as possible. Would also rather like to get it into F7 and FC6 kernels after its had a bit of soak time... Next up, I'd like to get the patch broken up into manageable chunks and sent off to lkml for review so we can get this thing up to kernel coding standards and hopefully included in the kernel proper. $ rpm -qpl RPMS/x86_64/kernel-2.6.23-0.133.rc3.git6.lirc1.fc8.x86_64.rpm | grep -e 'lirc_.*.ko' /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_atiusb/lirc_atiusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_bt829/lirc_bt829.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/commandir.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/lirc_cmdir.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_dev/lirc_dev.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_i2c/lirc_i2c.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_igorplugusb/lirc_igorplugusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_imon/lirc_imon.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_it87/lirc_it87.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb/lirc_mceusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb2/lirc_mceusb2.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_pvr150/lirc_pvr150.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_serial/lirc_serial.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_sir/lirc_sir.ko/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc7/kernel/drivers/input/lirc/lirc_streamzap/lirc_streamzap.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_ttusbir/lirc_ttusbir.ko Thanks for listening, time for z's... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fwd: Testing the Current Upstream Kernel]
> On Thu, Aug 16, 2007 at 06:59:29PM +0200, Thorsten Leemhuis wrote: >=20 > > * in the proper repo >=20 > Hmm. This would be great, but I think we may get some pushback on this > one. (Especially as kernel rpms are so big). >=20 > I'm thinking that a repo on people.fedoraproject.org is probably > the best of the bunch. I kinda like 'in the proper repo' myself, but I'd have to agree a separate repo is probably best. > > Maybe we should just try on rawhide first and look if many of such b= ugs > > show up? > >=20 > > > Once we have that figured out, regular builds and pushes are a bre= eze. > >=20 > > Should we move this discussion to fedora-devel instead, so everyone = can > > participate? > =20 > I think most of the concerned parties (rel-eng, infrastructure etc) are= > represented on this list already. but I've no objection. Note that we can't currently build kernel and kernel-vanilla in the same rpmbuild pass. Further changes to the spec would be needed to make that doable, but if they aren't going in the official repo, perhaps we don't want to do that anyway. --=20 Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Jarod Wilson wrote: Roland McGrath wrote: The signature sections are identical. Triple-checked that I was comparing with the ext3.ko from the initrd that booted the system. [...] To make it even more interesting: # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 # insmod e1000.ko Modules signature verification failed insmod: error inserting 'e1000.ko': -1 Key was rejected by service # strip -g e1000.ko # insmod e1000.ko # lsmod |grep e1000 e1000 125977 0 Ok. This makes me think that the signature generation and/or verification are looking at something they shouldn't be. i.e., something strip changed. Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. Sure, I'll add that too. Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract for a given module and the printks from verification looking at that module should give us something to go on. The build is just about done, but I gotta run. I'll poke at it some more in a few hours though... Hrm, something appears to have gone a touch screwy with my output redirection, but most of the good stuff (from mod-extract -v) is there: http://people.redhat.com/jwilson/misc/buildlog dmesg output (as much as possible) post-boot here: http://people.redhat.com/jwilson/misc/dmesg-modsign -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote: >> The signature sections are identical. Triple-checked that I was >> comparing with the ext3.ko from the initrd that booted the system. > [...] >> To make it even more interesting: >> >> # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 >> # insmod e1000.ko >> Modules signature verification failed >> insmod: error inserting 'e1000.ko': -1 Key was rejected by service >> # strip -g e1000.ko >> # insmod e1000.ko >> # lsmod |grep e1000 >> e1000 125977 0 > > Ok. This makes me think that the signature generation and/or verification > are looking at something they shouldn't be. i.e., something strip changed. > >>> Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c >>> (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. >> Sure, I'll add that too. > > Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract > for a given module and the printks from verification looking at that module > should give us something to go on. The build is just about done, but I gotta run. I'll poke at it some more in a few hours though... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Bug 250377: External modules of removed kernels are not removed
Jeremy Katz wrote: > On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote: >> Roland McGrath wrote: >>> Is there a reason to add a hack to the kernel %post in particular, >>> instead of just making people use rpm triggers? I mean, horror and all >>> that. >>> But at least it's generic SEP horror, and not new hair for the kernel rpm >>> itself (i.e. our problem). >> On the surface, I don't see why the couldn't. I suppose we should prod >> Matt Domsch on why he's against using triggers for dkms, since his >> objection in the bug doesn't list any details... > > Triggers run at not exactly the time you expect them to. Which makes > them a little bit less helpful. Really, you want to plug-in after > depmod, etc are run but before the initrd is made. And you can't do > that from a trigger. Ew, yeah, okay, I could see that having odd side-effects in a few cases... So what you're saying is we should do this in new-kernel-pkg? ;) At least that would make it mostly mkinitrd's problem and not the kernel's... > Also, triggers manage to cause all sorts of crazy fun weird corner > cases. Fear them. :-) /me cringes in terror... :) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Bug 250377: External modules of removed kernels are not removed
Roland McGrath wrote: > Is there a reason to add a hack to the kernel %post in particular, > instead of just making people use rpm triggers? I mean, horror and all that. > But at least it's generic SEP horror, and not new hair for the kernel rpm > itself (i.e. our problem). On the surface, I don't see why the couldn't. I suppose we should prod Matt Domsch on why he's against using triggers for dkms, since his objection in the bug doesn't list any details... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Bug 250377: External modules of removed kernels are not removed
Jeremy Katz wrote: > On Tue, 2007-08-14 at 16:18 -0400, Chuck Ebbert wrote: >> Is anyone looking at this? Only insofar as asking for yours and davej's thoughts about doing it. >> The basic proposal is to create >> /etc/kernel/preinst.d and /etc/kernel/postinst.d directories >> and let external packages drop scripts in there that get called >> on every kernel install. > > The easiest place for it to not require lots of cruft in the kernel spec > file would be /sbin/new-kernel-pkg. Ooh, I like that. > I'm not going to pass judgement on it being a good idea or not though :) I will! I think it could be a Good Thing or at least a Useful Thing for both kmod packages and dkms payloads. Of course, I also see the potential for abuse here... Sketchy kmods or dkms payloads could potentially wreak havoc on kernel installs if they cause a hang or failure. I'd be happy to take a crack at implementation. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote: >> Ya got me, but upon unpacking the initrd, modinfo tells me the bits in >> the initrd have the right vermagic. > > That doesn't tell you anything useful. Compare the signature sections, > e.g. readelf -x .module_sig on each. The signature sections are identical. Triple-checked that I was comparing with the ext3.ko from the initrd that booted the system. >> However, the file sizes don't match. >> In fact, they aren't even close. >> >> # (cd /tmp/initrd-104/lib; ll ext3.ko) >> -rw--- 1 root root 189096 2007-08-14 15:31 ext3.ko >> >> # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) >> -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko > > mkinitrd runs strip -g on the modules copied to the initrd. > I hadn't noticed that before, but it should not be a problem. > (Its affect on the signature issue should not have changed.) And indeed, the size matches if I manually run strip -g on the unstripped ko. To make it even more interesting: # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 # insmod e1000.ko Modules signature verification failed insmod: error inserting 'e1000.ko': -1 Key was rejected by service # strip -g e1000.ko # insmod e1000.ko # lsmod |grep e1000 e1000 125977 0 >> Okay, so I rebuilt the initrd and bounced the box... And there's the >> expected kernel panic. Only, if mkinitrd is stripping the modules, based on the above info, this *should* have worked... >> So now I'm thoroughly confused as to where the >> hell the modules that at least booted the system came from... > > Ok, we'll call the first experience a mysterious hiccup then. > > Did you save your rpmbuild log? Can you double-check that it has no > debugedit or find-debuginfo.sh runs that follow the modsign.sh runs? I didn't save it, but I can do a rebuild with the same options. > Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c > (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. Sure, I'll add that too. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote:
>> Roland McGrath wrote:
>>>> That was from revision 1.87.
>>> Hmm. Actually the failure mode from before was not "modprobe" problems,
>>> but never getting that far because the insmods in the initrd failed.
>>> Do you have some magical setup that needs no modules? Or did it really
>>> succeed at boot-time insmods and then modprobe fails?
>> Looks like it really succeeded at boot-time insmods, I've got dm_*,
>> ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and
>> {e,o,u}hci_hcd modules all loaded.
>
> Ok, color me ungentlemanly, but I have to ask if you've got the right
> things installed on disk where modprobe is looking.
So far as I know, yeah. I built an rpm and installed it, then booted
from the entry the kernel %post added to grub.conf, same as I've always
done... :)
> I mean, where did you
> get those modules with good signatures for the initrd if the ones on disk
> are bad?
Ya got me, but upon unpacking the initrd, modinfo tells me the bits in
the initrd have the right vermagic. However, the file sizes don't match.
In fact, they aren't even close.
# (cd /tmp/initrd-104/lib; ll ext3.ko)
-rw--- 1 root root 189096 2007-08-14 15:31 ext3.ko
# (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko)
-rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko
Okay, so I rebuilt the initrd and bounced the box... And there's the
expected kernel panic. So now I'm thoroughly confused as to where the
hell the modules that at least booted the system came from...
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote:
>> That was from revision 1.87.
>
> Hmm. Actually the failure mode from before was not "modprobe" problems,
> but never getting that far because the insmods in the initrd failed.
> Do you have some magical setup that needs no modules? Or did it really
> succeed at boot-time insmods and then modprobe fails?
Looks like it really succeeded at boot-time insmods, I've got dm_*,
ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and
{e,o,u}hci_hcd modules all loaded.
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
>> Roland McGrath wrote: >>> This has nothing to do with the modsign issue. >> Hrm... It didn't start happening (that I noticed) until after some of >> the recent changes you'd made, so I thought you might have an inkling = as >> to what was going on. >=20 > I do, but it's harmless and not related to the modsign issue. My main point was to make sure it was going to get fixed, and if you already know what's up, I presume you'll fix it and I don't need to spend time looking into it. :) >> However, the behavior of the resulting kernel build *does* appear to b= e >> related. I can't load any modules: >> >> # modprobe e1000 >> FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was >> rejected by service. >=20 > The is the failure mode that revision 1.84 of kernel.spec fixed. > Are you using the current spec? That was from revision 1.87. >> Best guess is that something goes haywire since I did this build >> '--without debuginfo'. >=20 > I can't see how that would break the fix for module signing. Was just a guess and perhaps not even an educated one. I'll poke at it a bit more. --=20 Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote: > This has nothing to do with the modsign issue. Hrm... It didn't start happening (that I noticed) until after some of the recent changes you'd made, so I thought you might have an inkling as to what was going on. However, the behavior of the resulting kernel build *does* appear to be related. I can't load any modules: # modprobe e1000 FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was rejected by service. Best guess is that something goes haywire since I did this build '--without debuginfo'. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: modsign vs build-id
Roland McGrath wrote: > I fixed this in rawhide kernel.spec over the weekend and left a somewhat > detailed comment in the changed bit. But I thought I'd bring this up > directly and explain the story. > > The short version of What Broke is "what, you sha1 on me? no, i sha1 on you!" Something I'm still seeing: $ rpmbuild --bb --with baseonly --without debuginfo kernel.spec [...] Processing files: kernel-headers-2.6.23-0.104.rc3.vsc.fc8 Provides: glibc-kernheaders = 3.0-46 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 Obsoletes: glibc-kernheaders Processing files: kernel-devel-2.6.23-0.104.rc3.vsc.fc8 warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64 warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64/.config [...repeat for every file in kernel-devel...] warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64/usr/Makefile Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/kernel-2.6.23-0.104.rc3.vsc.fc8-root-x86_64 Wrote: /usr/src/redhat/RPMS/x86_64/kernel-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Wrote: /usr/src/redhat/RPMS/x86_64/kernel-headers-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Wrote: /usr/src/redhat/RPMS/x86_64/kernel-devel-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.34783 + umask 022 + cd /usr/src/redhat/BUILD + cd kernel-2.6.22 + rm -rf /var/tmp/kernel-2.6.23-0.104.rc3.vsc.fc8-root-x86_64 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.42722 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf kernel-2.6.22 + exit 0 -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Anyone else?
Prarit Bhargava wrote: > Is anyone else seeing this when scp'ing INTO a box with F8T1 or newer > kernels? x86_64, intel 4-way > > > BUG: warning at kernel/softirq.c:138/local_bh > _enable() (Not tainted) I haven't seen it myself, but I know I've seen this message in a few bugzilla subjects now... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
Axel Thimm wrote: > On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote: >>> Actually the 0. prefix is not neccessary it is a leftover from 3rd >>> party techniques to indicate vendor hierarchies, but it's difficult >>> to knock out people's head. >> It has nothing to do with any 3rd-party techniques in the case. The >> '0.#' instead of just '#' is so that we can rebase the release number to >> 1 on each new major kernel version, > > It has everything to do with 3rd parties and the key element here is > history: Many years ago we started to discuss the beginning of what > today became the packaging guidelines in fedora.us. One element was > what to do with packages that override the vendors' (RHL 6.x/7.x at > that time), especially when the vendor was shippijng foo-1 and one > would like to use foo-3. > > So foo-3-0.whatever was considered as a hierachy solution to allow the > vendor to catch up with the 3rd party package w/o the vendor having to > coordinate build tags with the little 3rd party repos. > > In reality many foo-1 -> foo-3 upgrades were for foo-3 = some > prerelease, so this idiom got confused for prepending a 0. to > prereleases. > > So, "0." had a semantic wandering to land where it's used now, and the > beginnings were 3rd party techniques to auto-overide their own > packages when the vendor would update his. > ;) Yes, there's history behind why the "0." convention is in the packaging guidelines, but I still maintain that the 3rd-party history has/had zero bearing on the decision to use it in the kernel package. > There is nothing wrong with not using "0." to mark prereleases, it's > just Fedora legacy/tradition. I'm not a fan of resetting the build tag > anyway. I think your distaste of resetting the build tag is the real sticking point here. The main reason for "0." in pre-release versioning is because the majority of people *are* fans of resetting the build tag. > But whatever the "0." the important thing is that the build tag (`#´) > remains in front even if today the sub-versioning scheme for the > kernel looks like it would automatically happen to fit in rpmvercmp > ordering. Another history lesson shows that once one thought a > versioning style would settle and work it is "usefully" extended in a > way as to break theis assumption ;) True, true... rh9 -> fc1, fc6 -> f7... :) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: pre-release kernel release tag
Axel Thimm wrote: On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote: On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: I propose we change the release format for snapshot kernels. Now we get e.g.: kernel-2.6.23-0.89.rc2.git2.fc8 and I suggest instead: kernel-2.6.23-0.rc2.git2.89.fc8 That is, put the spec file version number last, not first. This way, when we forget to reset fedora_cvs_origin after a rebase, we don't have to wait for the next kernel version to do it, just the next gitN. We can't make this change until 2.6.23 sails, since for rpm version comparison rc* is < any [0-9]. Please don't do this. The kernel package is finally compliant with the Fedora Packaging Guidelines and this change would break it again. The reason we prefix with the 0.# is to prevent versioning comparison madness. What? I didn't propose removing the 0. prefix. What is the problem? Look closer, there's a `#´ in Tom's reply, which is what you want to move away. Actually the 0. prefix is not neccessary it is a leftover from 3rd party techniques to indicate vendor hierarchies, but it's difficult to knock out people's head. It has nothing to do with any 3rd-party techniques in the case. The '0.#' instead of just '#' is so that we can rebase the release number to 1 on each new major kernel version, so the first released 2.6.23 kernel for fc8 will be 2.6.23-1.fc8. At least, that was my intention when I wrote this stuff up, and its how we've used it thus far. Of course, my initial thought had been it'd be nice to not even have the '.#' portion in there, since you get reasonably decent rpm ordering with just 0.rcX.gitY.fc8, but then if we end up doing a rebuild of the same git snap, you have to worry about it, but we don't want to have to muck around with that manually. That being the case, putting it after the leading 0 for git snaps, automatically incremented over the period leading up to the next kernel release, in line with the packaging guidelines, made the most sense. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
