kernel June 2007

kernel@lists.fedoraproject.org

33 participants
24 discussions

uevent order fix
by David Zeuthen 15 Jun '07

15 Jun '07

Dave, Please take a look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… Can we include this simple patch in Fedora 7 and Rawhide please? Without this, events arrive in the wrong order meaning that udev and hal may get confused. Thanks. David

2 3

fedora kernel utrace updates
by Roland McGrath 14 Jun '07

14 Jun '07

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

3 9

F7 redux, and the road to F8.
by Dave Jones 13 Jun '07

13 Jun '07

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

9 14

mkinitrd. dep (was: Re: rpms/kernel/F-7 kernel-2.6.spec, 1.3226, 1.3227)
by Thorsten Leemhuis 13 Jun '07

13 Jun '07

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

2 3

quilt-import script
by Roland McGrath 11 Jun '07

11 Jun '07

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 }

1 0

iwl3945
by Jonathan Underwood 11 Jun '07

11 Jun '07

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.

5 4

kernel modules not stripped?
by drago01 10 Jun '07

10 Jun '07

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

2 1

atop?
by Axel Thimm 08 Jun '07

08 Jun '07

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

2 4

where to get KDB debugger for FC6
by kathy pu 08 Jun '07

08 Jun '07

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

3 2

Sunifdef
by Jonathan Underwood 07 Jun '07

07 Jun '07

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.

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel June 2007