[OT] please review new kernel build doc on fedora wiki
by Sam Folk-Williams
Hi,
I (with DaveJ) help maintain the kernel release notes for Fedora. A user suggested a
while back that we remove the building instructions from the release notes and
put those in a separate doc devoted to more detailed instructions on building
the kernel RPM (including applying patches and configuring options).
I've got a draft doc now. I come to this from a support perspective - building
kernels with patches I get from Engineering to pass on for testing. I'd like to
get the point of view of some kernel developers as well.
- Is what's here correct?
- Is there more that should be here?
- Does the info here conform to best practices?
Any feedback appreciated. I am happy to make edits myself if you reply, or of
course any one can make edits on their own.
http://fedoraproject.org/wiki/Docs/Drafts/CustomKernel
Thanks,
Sam
--
Sam Folk-Williams, RHCE Red Hat Global Support Services
Phone: 919/754-4558 GPG ID: 1B0D46BA
17 years
Spinning kernel-vanilla packages via standard spec
by Jarod Wilson
A little follow-on to the "Longing for git-bisect" thread, in a
newly-created/subjected thread...
So, I've been poking around in the kernel spec file extensively the past
few days already... Any objections to my attempting to implement the
building of a kernel-vanilla package as well?
Roland, not sure if you were already planning to do this in conjunction
with digging up your old patches, or if you were just throwing the
patches out there, but either way, I'm happy to take on the task, but
I'll defer to anyone else that really wants to do it.
--
Jarod Wilson
jwilson(a)redhat.com
17 years
Make "pci=nomsi" the default on 2.6.20 kernels?
by Chuck Ebbert
It seems like more and more problems with PCI MSI are turning up
in the 2.6.20 kernel. Discussion upstream concluded that maybe
it should have been off by default in 2.6.20, so maybe we should
just do that in Fedora and make people who want it use "pci=msi"
to enable it? It's probably not going to be really stable until
2.6.22...
17 years
Needed: An easier way to build a subset of kernel packages
by Chuck Ebbert
I was thinking about adding something like this to the .spec file
at the beginning:
%define allowup 1
%define allowsmp 1
%define allowpae 1
%define allowxen 1
%define allowdoc 1
%define allowdump 1
%define allowheaders 1
%define allowdebug 1
Then, after all the automatic enable/disable of various options is done,
turn off everything that's not allowed.
This would make it much easier to change what gets built.
17 years, 1 month
Backwards compatible module symlinks
by Chuck Ebbert
At first glance it doesn't seem very hard to do something like this
on kernel install:
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid6.ko
We could have left mkinitrd alone if the %post script for the kernel that
combined those three modules into one had done this.
17 years, 1 month
Something is changing the firmware loading timeout
by Chuck Ebbert
Firmware default loading timeout is set to 60 seconds by a Fedora
patch (it's 10 seconds in the stock kernel.) Somehow, by the time
I've finished booting it's back to 10 seconds. Does anyone have an
idea why? I came up with this patch to make the minimum 60 seconds,
still allowing 0 for "no timeout."
--- linux-2.6.20.noarch/drivers/base/firmware_class.c.orig 2007-03-26 14:20:38.000000000 -0400
+++ linux-2.6.20.noarch/drivers/base/firmware_class.c 2007-03-26 18:10:09.000000000 -0400
@@ -81,8 +81,15 @@
firmware_timeout_store(struct class *class, const char *buf, size_t count)
{
loading_timeout = simple_strtol(buf, NULL, 10);
- if (loading_timeout < 0)
+ if (loading_timeout <= 0)
loading_timeout = 0;
+ else if (loading_timeout < 60) {
+ if (printk_ratelimit)
+ printk(KERN_INFO
+ "firmware_class: attempt to set timeout to %d\n",
+ loading_timeout);
+ loading_timeout = 60;
+ }
return count;
}
17 years, 1 month
Qlogic firmware isn't in the FC7 kernel
by Chuck Ebbert
Apparently the qlogic drivers don't have any firmware included in FC7,
so nobody can actually use a qlogic adapter. Should we be patching the
kernel like in FC6 or do we need a separate package? Or maybe the
firmware goes in the kernel package?
Peter says the support for Anaconda / mkinitrd to load the firmware
is already written, so we could do it either way.
17 years, 1 month
Longing for git-bisect
by Josh Boyer
Has anyone played with keeping the Fedora kernel in a git tree
somewhere? Current rawhide makes my T60p weep on a regular basis in the
form of nice hard lockups with no oops output or anything. I'd love to
be able to do a bisect on the kernel and see where things started going
south. I just have no idea how to do that with the tree the way it
currently is.
Of course, I can see where tracking the Fedora kernel in git would be
pretty painful at times too. So if anyone has a better suggestion, I'm
all ears.
josh
17 years, 1 month
Crazy idea
by Hans de Goede
Hi all,
Reading the thread about adding support to the kernel spec file to build a
vanilla kernel, I had this crazy (really crazy) idea:
Wouldn't it be great to share one kernel package or atleast one kernel source
(as in pristine source + patches) between different distro's?
The kernel is a _very_ important and complicated piece of software, which
requires many many eyes, I'm sure that many kernel bugs are hitting more then
one distro, and some are fixed with distro specific patches in one distro, but
not in the next.
So in an ideal word all distro's would have one kernel with a team made of the
current maintainers from all distros working on it. I know this is impossible
taking the different rate of changes between distro's but maybe ubuntu + suse?
+ Fedora could use a common kernel source?
I know this is a really long shot, but if we could pull it off it would be
really great.
As said a really crazy (as in probably undoable) idea. So if not this, then
what can be done to work better together on the kernel side of distro's, maybe
a distro-kernel-maintainers-list(a)kernel.org?
And maybe also a common bugzilla?
Call me crazy but I think a lot could be gained here.
Regards,
Hans
17 years, 1 month
rpms for vanilla kernel builds ...
by Clinton Lee Taylor
Greetings ...
I for one would like to vote for rpms of vanilla kernel build!
I have an Adaptec ASR-3410S, which is an i2o device, but since
2.6.18-1.2869.fc6, I can't use it and the i2o maintaner suggests I try a
vanilla kernel build to see if it's an FC kernel problem or a general
problem, but I don't have the skill to build a bootable kernel, let alone
give good debug info.
Thanks
Mailed
Lee
17 years, 1 month
