fedora kernel utrace updates
by Roland McGrath
I've started using quilt to maintain backport versions of my utrace patches.
http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and
2.6.20.11 (for FC-6). Done this way it is easy for me to plop in the new
utrace/ptrace code from the bleeding edge version when I have fixes, without
repeating the backport work, which is confined to the earlier patches in the
series.
Since quilt doesn't have a handy feature for generating a single patch, and
I know better than to trust combinediff, I'd like to switch the Fedora
update kernels to using the broken out patches separately in the spec file.
If one were actually trying to keep track, this also makes it a little
easier to follow the changed patches in cvs, since there will be less
flutter around parts that aren't actually changing.
Any problem with that?
Whoever is maintaining each update stream can tell me how they'd prefer to
handle updates. You can snarf from my people page at will, or I can just
commit changed patches when I have a significant fix, or whatever.
For rawhide, it doesn't really matter to me one way or the other about using
the one patch or the series. The "trunk" patchset is generated from GIT,
not quilt, and I already have scripts that generate the one patch we use
now. If there is no reason not to, I'd probably switch it to using the
series just for consistency.
The F-7 spec change looks like this. I renumbered some nearby patches to
give utrace the 10-30 range.
Thanks,
Roland
Index: kernel-2.6.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-7/kernel-2.6.spec,v
retrieving revision 1.3226
diff -u -b -p -r1.3226 kernel-2.6.spec
--- kernel-2.6.spec 10 Jun 2007 01:28:50 -0000 1.3226
+++ kernel-2.6.spec 11 Jun 2007 20:40:07 -0000
@@ -397,20 +397,37 @@ Patch2: patch-2.6.21.5-rc2.bz2
Patch3: stable-reverts.patch
# Patches 10 through 99 are for things that are going upstream really soon.
-Patch10: linux-2.6-utrace.patch
-Patch11: nouveau-drm.patch
-Patch12: linux-2.6-fix-pmops-1.patch
-Patch13: linux-2.6-fix-pmops-2.patch
-Patch14: linux-2.6-fix-pmops-3.patch
-Patch15: linux-2.6-fix-pmops-4.patch
+Patch10: linux-2.6-sig_kernel-macros.patch
+Patch11: linux-2.6-recalc_sigpending_and_wake.patch
+Patch12: linux-2.6-utrace-tracehook.patch
+Patch13: linux-2.6-utrace-tracehook-ia64.patch
+Patch14: linux-2.6-utrace-tracehook-sparc64.patch
+Patch15: linux-2.6-utrace-tracehook-s390.patch
+Patch16: linux-2.6-utrace-tracehook-um.patch
+Patch17: linux-2.6-utrace-regset.patch
+Patch18: linux-2.6-utrace-regset-ia64.patch
+Patch19: linux-2.6-utrace-regset-sparc64.patch
+Patch20: linux-2.6-utrace-regset-s390.patch
+Patch21: linux-2.6-utrace-core.patch
+Patch22: linux-2.6-utrace-ptrace-compat.patch
+Patch23: linux-2.6-utrace-ptrace-compat-ia64.patch
+Patch24: linux-2.6-utrace-ptrace-compat-sparc64.patch
+Patch25: linux-2.6-utrace-ptrace-compat-s390.patch
+
+Patch30: nouveau-drm.patch
+
+Patch42: linux-2.6-fix-pmops-1.patch
+Patch43: linux-2.6-fix-pmops-2.patch
+Patch44: linux-2.6-fix-pmops-3.patch
+Patch45: linux-2.6-fix-pmops-4.patch
# enable sysrq-c on all kernels, not only kexec
# FIXME: upstream soon? When? It's been here for ages.
-Patch16: linux-2.6-sysrq-c.patch
+Patch46: linux-2.6-sysrq-c.patch
# DRM bits for 965
-Patch17: linux-2.6-i965gm-support.patch
+Patch47: linux-2.6-i965gm-support.patch
# Patches 100 through 500 are meant for architecture patches
@@ -1050,25 +1067,42 @@ cd linux-%{kversion}.%{_target_cpu}
# Update to latest upstream.
%patch1 -p1
%patch2 -p1
-%patch3 -p1 -R
+%%patch3 -p1 -R
# Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement.
%patch10 -p1
%patch11 -p1
-
-# Power management fixes
%patch12 -p1
%patch13 -p1
%patch14 -p1
%patch15 -p1
+%patch16 -p1
+%patch17 -p1
+%patch18 -p1
+%patch19 -p1
+%patch20 -p1
+%patch21 -p1
+%patch22 -p1
+%patch23 -p1
+%patch24 -p1
+%patch25 -p1
+
+# nouveau-drm
+%patch30 -p1
+
+# Power management fixes
+%patch42 -p1
+%patch43 -p1
+%patch44 -p1
+%patch45 -p1
# sysrq works always
-%patch16 -p1
+%patch46 -p1
# DRM support for 965GM
-%patch17 -p1
+%patch47 -p1
# Architecture patches
16 years, 10 months
F7 redux, and the road to F8.
by Dave Jones
I've been doing some thinking about "what went right/wrong" about F7
from the kernel standpoint, and how we can improve for F8.
Wrt 'what went right', I don't have much to say.
Not because nothing went right, but mostly because there was nothing
really positive that stood out over earlier releases.
The new firewire stuff was probably the only thing that went really
well. Kristian jumped on bugs quickly when they were found, we
got updated kernels out quickly, and best of all, it's now upstream.
The 'what went wrong' category gives me a bunch of ideas of areas
where we can improve however.
libata.
~~~~~~~
Looking at the incoming bugs, this seems to be the biggest area
where we have problems. No surprise really given the switchover
to new pata drivers. Though there are quite a few SATA bugs too.
I'm not sure what more we can do here other than keep pointing
Jeff & Alan at them, and hoping for the best.
We knew this was going to be bumpy first time around, so hopefully
for F8 we'll have most of the kinks worked out here, and won't
have introduced (m)any new problems.
Wireless.
~~~~~~~~~
Well, we got dscape and a bunch of new drivers in.
They don't seem to work too well though. For this to improve,
we really need more bodies. This was pretty much all linville.
How can we get more interaction from the various upstreams?
ipw3945 seemed to be busted for weeks on end, with very little
motion from Intel. How can we get them more involved?
Nouveau.
~~~~~~~~
This was pretty much a 'dump in the tree and forget' activity.
It really needs someone with the time to babysit it and make sure
it actually progresses. Ideally, we'd have someone involved
in improving the driver driving this along. Again, we lack bodies.
I doubt this is going to change much in the F8 timeframe.
Suspend/Resume.
~~~~~~~~~~~~~~~
We need a more focused testing effort here.
(And an even more 'fixing' effort when problems are found).
I fixed up 2-3 laptops in the last few weeks before release,
but pretty much every review I've read of F7 so far has dinged
us for this not working out the box. On common laptops like thinkpads
too. In part, this was us moving to new suspend infrastructure,
so I'm hoping a lot of the 'black screen' bugs will just go away
in a future hal-data/pm-utils update. But we can definitly do
better here. Work is ongoing to get better debugging tools
for resume failures too, more about that as it happens.
Xen.
~~~~
This might get interesting to watch for F8 if XenU gets upstream
(Which akpm seems to suggest it might). Given we've decoupled
kernel/kernel-xen, we might want to just disable the upstream variant
until F9, and wait until we have both the dom0 and the domU stuff
coming from the same pieces. Will need more discussion with
the virtualisation team when that lands in Linus' tree.
Last minute breakage.
~~~~~~~~~~~~~~~~~~~~~
The number one lesson I think to be learned was that just because
upstream -stable is called -stable, it isn't necessarily so.
The last minute rebase to 2.6.21.2 brought in the regression that
broke a lot of Dell laptops, and wasn't understood & fixed in time
for release.
For F8 onwards, I propose that we don't jump to the latest upstream
stable release as a last minute thing. Maybe hold off for the last
week (maybe 2 weeks?) allowing only *really critical* changes.
Where really critical ==
- Fixes a "machine won't boot" bug.
- Fixes a "ethernet doesn't work" bug (thus preventing updates being downloaded)
- Fixes a data corruption bug.
- Fixes a _critical_ security bug.
(Lower impact things like information leakage can wait until update 1 on
the day of release).
- Anything else?
The thing is, we nearly always do an update just after the release
anyway, so not-so-critical stuff that doesn't fall into the above
category can go out as an update.
It'll be a bit more work to do more backporting, but I think the
overall risk will be lower if we cherry pick.
On the subject of backporting, due to us only having 5 months
for F8, and a lot of that time being 'conference season', I expect
upstream to slow down a little, so we're probably looking at
2.6.23 for F8. I'm guessing .24 will begin way too late in our cycle,
so we'll have quite a bit of backporting to be doing for the final
month or so before release.
comments?
Dave
--
http://www.codemonkey.org.uk
16 years, 10 months
mkinitrd. dep (was: Re: rpms/kernel/F-7 kernel-2.6.spec, 1.3226, 1.3227)
by Thorsten Leemhuis
Hi!
On 12.06.2007 20:23, Dave Jones (davej) wrote:
> Author: davej
>
> Update of /cvs/pkgs/rpms/kernel/F-7
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30425
>
> Modified Files:
> kernel-2.6.spec
> Log Message:
> * Tue Jun 12 2007 Dave Jones <davej(a)redhat.com>
> - Require at least version 6.0.9-7.1 of mkinitrd.
> [...]
> -%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1
> +%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-7.1
> [...]
>
> %changelog
> +* Tue Jun 12 2007 Dave Jones <davej(a)redhat.com>
> +- Require at least version 6.0.9-7.1 of
> +
Dave, could you do me a small favor and in situations like this (and
more important: in the devel tree) please mention why a new mkinitrd is
needed (if possible without much hassle)? tia!
It's not that important, but would be nice to know now and then --
especially in situations I often run into: downloaded a new kernel on
machine foo, put it on a USB stick, go with it to computer bar, try to
install it with rpm directly because the old kernel has no network
support for that machine and fail because I need a new mkinitrd... if I
knew that a new mkinitrd is just needed for some obscure bug I then
might just use "--nodeps" instead of going back to machine foo to
download the the new mkinitrd .
CU
thl
16 years, 10 months
quilt-import script
by Roland McGrath
Btw, I wrote this script that is scripts/import-series in my tree.
For the utrace series I used:
scripts/import-series ~/redhat/people/utrace/2.6.21 10 linux-2.6-
Thanks,
Roland
---
#!/bin/sh
if [ $# -ne 2 -a $# -ne 3 ]; then
echo >&2 "Usage: $0 QUILT-PATCHES-DIR FIRST-PATCHN [PREFIX]"
exit 1
fi
dir="$1"
first="$2"
prefix="$3"
n=$first
QUILT_PATCHES="$dir" quilt series | {
while read patch; do
cp "$dir/$patch" "$prefix$patch"
echo "Patch$n: $prefix$patch"
n=$[$n + 1]
done
echo
i=$first
while (( i < n )); do
echo "%patch$i -p1"
i=$[$i + 1]
done
}
16 years, 10 months
iwl3945
by Jonathan Underwood
Hi,
I have a laptop with an ipw3945 wireless adapter and with F7
installed, things are quite.... flakey. Looking at forums and mailing
lists I see I'm not suffering alone. So, I was wondering what would be
useful information to help debug this, beyond "it doesn't work very
well".
TIA
Jonathan.
16 years, 10 months
kernel modules not stripped?
by drago01
I have read a thread on lkml about stripped and not stripped modules...
so I checked if they are in fedora (2.6.21-1.3194.fc7) and it seems that
they aren't.
so I tested how much it would gain (size) so I picked some random module
(sata_nv.ko) copied it to my home folder and did the test:
original size: 40512
stripped size: 26912
so it seems that we are wasting ~50% of space by not doing this.
reason for this?
note: this was on x86_64
16 years, 10 months
atop?
by Axel Thimm
Would it make sense to add these patches to Fedora's kernel?
http://www.atcomputing.nl/Tools/atop
This could help in the area of extending laptop battery life by
detecting unneccessary disk access. The first step is to have some
disk I/O to process mapping.
--
Axel.Thimm at ATrpms.net
16 years, 10 months
where to get KDB debugger for FC6
by kathy pu
Hello Everybody:
Just wondering if FC6 supports KDB. If not, would like to know the current
status andhow to get it and port it?
My great appreciation.
kathy
16 years, 10 months
Sunifdef
by Jonathan Underwood
Dear Kernel list,
I've noticed in the past that unifdef is used in kernel package
building. I wonder if you're aware of a maintained and more
featureful program, Sunifdef, which has evolved from unifdef (which
seems mostly unmaintained). It's packaged for Fedora, and has a
website here:
http://www.sunifdef.strudl.org/
Quoting:
Sunifdef is a commandline tool for eliminating superfluous
preprocessor clutter from C and C++ source files. It is a more
powerful successor to the FreeBSD 'unifdef' tool.
Sunifdef is most useful to developers of constantly evolving products
with large code bases, where preprocessor conditionals are used to
configure the feature sets, APIs or implementations of different
releases. In these environments the code base steadily accumulates
#ifdef pollution as transient configuration options become obselete.
Sunifdef can largely automate the recurrent task of purging redundant
#if logic from the code.
Apologies for a slightly off topic plug.
jonathan.
16 years, 10 months
