kernel June 2010

kernel@lists.fedoraproject.org

30 participants
19 discussions

exec-shield=2
by Roland McGrath 14 Jul '10

14 Jul '10

Do we care about the exec-shield=2 configuration? Does anybody use that? In the execshield patch we have in Fedora at this point, the (exec_shield & 2) special cases are the only arch-independent changes that are not fairly clean and isolated. The patch puts a comment in sysctl.c about several bit flags in exec_shield, but actually only &2 and !=0 are really meaningful in our code. If we could get rid of exec_shield&2 then it would be down to just exec_shield!=0 and as of now that already only affects NX-emulation in fact. If someone does want a behavior akin to exec_shield&2 that could be done cleanly (and upstreamed) with a saner sysctl or two. What it does now is a little incoherent. Thanks, Roland

4 8

[Fedora PATCH] x86 config: turn off I2O support
by Prarit Bhargava 24 Jun '10

24 Jun '10

Turn off I2O support for x86. It is broken on 64-bit address spaces (i686/PAE, x86_64), and frankly, I'm having trouble finding anyone who actually uses it. Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Index: config-x86-generic =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.99 diff -u -r1.99 config-x86-generic --- config-x86-generic 9 May 2010 17:27:13 -0000 1.99 +++ config-x86-generic 15 Jun 2010 13:32:49 -0000 @@ -112,15 +112,7 @@ CONFIG_CAPI_EICON=y -CONFIG_I2O=m -CONFIG_I2O_BLOCK=m -CONFIG_I2O_SCSI=m -CONFIG_I2O_PROC=m -CONFIG_I2O_CONFIG=y -CONFIG_I2O_EXT_ADAPTEC=y -CONFIG_I2O_EXT_ADAPTEC_DMA64=y -CONFIG_I2O_CONFIG_OLD_IOCTL=y -CONFIG_I2O_BUS=m +# CONFIG_I2O is not set # # APM (Advanced Power Management) BIOS Support Index: config-x86_64-generic =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-x86_64-generic,v retrieving revision 1.107 diff -u -r1.107 config-x86_64-generic --- config-x86_64-generic 2 Jun 2010 12:03:11 -0000 1.107 +++ config-x86_64-generic 15 Jun 2010 13:32:49 -0000 @@ -43,15 +43,7 @@ CONFIG_EFI_PCDP=y CONFIG_FB_EFI=y -CONFIG_I2O=m -CONFIG_I2O_BLOCK=m -CONFIG_I2O_SCSI=m -CONFIG_I2O_PROC=m -CONFIG_I2O_CONFIG=y -CONFIG_I2O_EXT_ADAPTEC=y -CONFIG_I2O_EXT_ADAPTEC_DMA64=y -CONFIG_I2O_CONFIG_OLD_IOCTL=y -CONFIG_I2O_BUS=m +# CONFIG_I2O is not set CONFIG_SECCOMP=y

3 2

Re: kernel-perf subpackage
by Arnaldo Carvalho de Melo 24 Jun '10

24 Jun '10

Em Thu, Jun 24, 2010 at 09:44:50AM -0400, Adam Jackson escreveu: > On Tue, 2010-06-22 at 17:37 -0700, Roland McGrath wrote: > > %package -n perf > > Summary: Performance monitoring for the Linux kernel > > Group: Development/System > > License: GPLv2 > > +%if %{with_perftool} > > +Requires: kernel-perf(%{_arch}) >= %{version}-%{release} > > +%endif > > Oughtn't this be: > > Requires: kernel-perf%{_isa} >= %{version}-%{release} The version-release part shouldn't be there, backward compatibility is a goal, so one can use an arbitrary perf binary with an arbitrary kernel. Features that are used in a perf binary, say, what is needed by 'perf probe', when not present in a kernel, should just produce an error message at runtime when people try to use 'perf probe'. - Arnaldo

3 2

kernel-perf subpackage
by Roland McGrath 24 Jun '10

24 Jun '10

When I changed the manual require from libdwarf to elfutils-libs because the perf tool upstream changed, I got nervous about a few things. Firstly, having this growingly complex userland binary packaged without automatic requires so changes like that are necessary. That change wasn't even really right, since it needs to be an arch-sensitive require to really win. So Fedora kernel weenies dimly following the wild upstream perf development actually managing to hand-maintain that perfectly is manifestly laughable. Second, sheesh, so now a new/old kernel rpm I only wanted to try booting might refuse to install because of the wrong version of some DWARF library? And/or all that gets installed just because I wanted to boot the kernel? You hear maniacal laughter in the distance. So I did the following spec hack (not really tested yet). This puts the perf tool into its own subpackage, i.e. kernel-perf. Now that subpackage gets normal autorequires and we don't have to worry about that. You don't have to install kernel-perf to install kernel{,-variant}. Two notes: 1. There is only one kernel-perf subpackage for all the kernel and kernel-variant subpackages enabled. I went with one perf binary and symlinks instead of separate binaries. The upstream code is really supposed to be a sane userland interface, if not a stable one. So new kernel sources will change it 8 ways from Sunday. But unless they've gone even more insane up there, kconfig differences should not change the kernel-user API that perf is built to. 2. Not to be confused with the existing perf package, i.e. the wrapper script (and docs). You still get to have only one of those installed, with a separate kernel-perf for each kernel build version you are using. 3. I thought about calling it kernel-tools or something, in case of future things from tools/ worth installing. But I shied away from any general name because they all seem misleadingly like a first-class thing a user would want to install, rather than some arcane bowels as this really is. I guess if there were more such things one day, there would be front-end multiplexor scripts as for perf and then we'd change that package's name too. (Yes, I know that was 3 out of 2. It's a bonus tangent.) Is this idea good, bad, or indifferent? It's really only the hand-maintenance of the rpm deps for the perf binary that make me want to run and hide. The "you want me to install *what* so I can rescue this damn lossage with an additional kernel rpm install?" scenario is only hypothetical off hand (and having some compatible elfutils-libs installed is already the normal situation anyway)--I just figure when it bites someone, it will happen to them at the fringes of their wits' end, so they will be especially peeved. Thanks, Roland Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.2039 diff -u -b -p -r1.2039 kernel.spec --- kernel.spec 22 Jun 2010 23:11:06 -0000 1.2039 +++ kernel.spec 23 Jun 2010 00:14:50 -0000 @@ -454,9 +454,6 @@ Requires(pre): %{initrd_prereq}\ Requires(pre): kernel-firmware >= %{rpmversion}-%{pkg_release}\ %else\ Requires(pre): linux-firmware\ -%if %{with_perftool}\ -Requires(pre): elfutils-libs\ -%endif\ %endif\ Requires(post): /sbin/new-kernel-pkg\ Requires(preun): /sbin/new-kernel-pkg\ @@ -768,13 +765,26 @@ Group: Development/Debug This package is required by %{name}-debuginfo subpackages. It provides the kernel source files common to all builds. +%if %{with_perftool} +%package perf +Summary: Performance monitoring for the Linux kernel +Group: Development/System +License: GPLv2 +%description perf +This package provides the perf tool to match this kernel package. +Install the perf package to get the %{_sbindir}/perf front-end script. +%endif + %package -n perf Summary: Performance monitoring for the Linux kernel Group: Development/System License: GPLv2 +%if %{with_perftool} +Requires: kernel-perf(%{_arch}) >= %{version}-%{release} +%endif %description -n perf This package provides the supporting documentation for the perf tool -shipped in each kernel image subpackage. +found in the %{name}-perf subpackage. # # This macro creates a kernel-<subpackage>-debuginfo package. @@ -1387,16 +1397,6 @@ BuildKernel() { make -s ARCH=$Arch V=1 %{?_smp_mflags} $MakeTarget %{?sparse_mflags} make -s ARCH=$Arch V=1 %{?_smp_mflags} modules %{?sparse_mflags} || exit 1 -%if %{with_perftool} - pushd tools/perf -# make sure the scripts are executable... won't be in tarball until 2.6.31 :/ - chmod +x util/generate-cmdlist.sh util/PERF-VERSION-GEN - make -s V=1 NO_DEMANGLE=1 %{?_smp_mflags} perf - mkdir -p $RPM_BUILD_ROOT/usr/libexec/ - install -m 755 perf $RPM_BUILD_ROOT/usr/libexec/perf.$KernelVer - popd -%endif - # Start installing the results %if %{with_debuginfo} mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot @@ -1545,6 +1545,11 @@ BuildKernel() { mkdir -p $RPM_BUILD_ROOT/usr/src/kernels mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir ln -sf ../../..$DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build + +%if %{with_perftool} + [ -z "$Flavour" ] || + ln -snf perf.%{KVERREL} $RPM_BUILD_ROOT%{_libexecdir}/perf.$KernelVer +%endif } ### @@ -1554,6 +1559,7 @@ BuildKernel() { # prepare directories rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/boot +mkdir -p $RPM_BUILD_ROOT%{_libexecdir} cd linux-%{kversion}.%{_target_cpu} @@ -1577,6 +1583,10 @@ BuildKernel %make_target %kernel_image BuildKernel %make_target %kernel_image smp %endif +%if %{with_perftool} +make -C tools/perf -s V=1 NO_DEMANGLE=1 %{?_smp_mflags} perf +%endif + %if %{with_doc} # Make the HTML and man pages. make %{?_smp_mflags} htmldocs mandocs || %{doc_build_fail} @@ -1651,12 +1661,16 @@ done popd %endif # with_perf +# perf tool binary +%if %{with_perftool} +mkdir -p $RPM_BUILD_ROOT%{_libexecdir} +install -m 755 tools/perf/perf $RPM_BUILD_ROOT%{_libexecdir}/perf.%{KVERREL} +%endif + # perf shell wrapper %if %{with_perf} -mkdir -p $RPM_BUILD_ROOT/usr/sbin/ -cp $RPM_SOURCE_DIR/perf $RPM_BUILD_ROOT/usr/sbin/perf -chmod 0755 $RPM_BUILD_ROOT/usr/sbin/perf -mkdir -p $RPM_BUILD_ROOT%{_datadir}/doc/perf +mkdir -p $RPM_BUILD_ROOT%{_sbindir} $RPM_BUILD_ROOT%{_datadir}/doc/perf +install -m 755 $RPM_SOURCE_DIR/perf $RPM_BUILD_ROOT%{_sbindir}/perf %endif %if %{with_headers} @@ -1826,10 +1840,16 @@ fi %files -n perf %defattr(-,root,root) %{_datadir}/doc/perf -/usr/sbin/perf +%{_sbindir}/perf %{_datadir}/man/man1/* %endif +%if %{with_perftool} +%files perf +%defattr(-,root,root) +%{_libexecdir}/perf.%{KVERREL}* +%endif + # This is %{image_install_path} on an arch where that includes ELF files, # or empty otherwise. %define elf_image_install_path %{?kernel_image_elf:%{image_install_path}} @@ -1845,9 +1865,6 @@ fi %defattr(-,root,root)\ /%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2:.%{2}}\ /boot/System.map-%{KVERREL}%{?2:.%{2}}\ -%if %{with_perftool}\ -/usr/libexec/perf.%{KVERREL}%{?2:.%{2}}\ -%endif\ #/boot/symvers-%{KVERREL}%{?2:.%{2}}.gz\ /boot/config-%{KVERREL}%{?2:.%{2}}\ %dir /lib/modules/%{KVERREL}%{?2:.%{2}}\

2 2

kernel 2.6.35-rc3 pushed to rawhide
by Kyle McMartin 23 Jun '10

23 Jun '10

Hi folks, As you may have noticed, I committed and pushed out builds for 2.6.35-rc3 to devel/ today overtop of 2.6.34, which is still on track for F-13. There are still some bugs in DRM on 2.6.35-rc3, which have been backported to 2.6.34. (In particular, the 'flickering' bug where kslowd takes a lot of cpu.) These seem to only bite on radeon and nouveau though, and I believe have been fixed with reverts in both 2.6.34-45 and 2.6.35-0.1.rc3, and if confirmed fixed, will hopefully be properly fixed quickly so we're back on the mainline track. Anyway, I've re-enabled debug builds in rawhide, so things will be slow again. If you want to keep testing, there's a dist-f13 scratch build with debugging /disabled/ here: (assuming it completes.) http://koji.fedoraproject.org/koji/taskinfo?taskID=2266056 I'm going to push 2.6.34 to F-13 once it's had a bit more baking and we've confirmed that the DRM issues are fixed. regards, Kyle

7 10

v2.6.34 for F-13
by Kyle McMartin 16 Jun '10

16 Jun '10

http://koji.fedoraproject.org/koji/taskinfo?taskID=2199579 I've done a scratch build of the rawhide kernel, with debugging disabled, with most of the patches from F-13 caught back up, for people to test. Obviously, we're shipping F-13 with 2.6.33, but I'd like to get the update out there pretty quickly afterwards, if possible. It's currently missing a bit of DRM rebasing, which is kind of ironic, but it looks like Fedora's 2.6.33 has half of a newer DRM, both have seperate fixes though. Anyway, hopefully we can get that sorted by the weekend, and get rawhide moved over to 2.6.35-git. regards, Kyle

9 34

[PATCH] drm: radeon: provide a module_param toggle to enable/disable power management
by Kyle McMartin 16 Jun '10

16 Jun '10

From: Kyle McMartin <kyle(a)redhat.com> Allows us to narrow down power management related issues. Signed-off-by: Kyle McMartin <kyle(a)redhat.com> --- diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 5f96fe8..5b23cb9 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -92,6 +92,7 @@ extern int radeon_new_pll; extern int radeon_audio; extern int radeon_disp_priority; extern int radeon_hw_i2c; +extern int radeon_pm; /* * Copy from radeon_drv.h so we don't have to include both and have conflicting diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 902d173..76be38d 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -95,6 +95,7 @@ int radeon_new_pll = -1; int radeon_audio = 1; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; +int radeon_pm = 0; MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers"); module_param_named(no_wb, radeon_no_wb, int, 0444); @@ -141,6 +142,9 @@ module_param_named(disp_priority, radeon_disp_priority, int, 0444); MODULE_PARM_DESC(hw_i2c, "hw i2c engine enable (0 = disable)"); module_param_named(hw_i2c, radeon_hw_i2c, int, 0444); +MODULE_PARM_DESC(pm, "enable power management (0 = disable)"); +module_param_named(pm, radeon_pm, int, 0444); + static int radeon_suspend(struct drm_device *dev, pm_message_t state) { drm_radeon_private_t *dev_priv = dev->dev_private; diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 4d3c1e4..0f902e4 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -411,7 +411,7 @@ int radeon_pm_init(struct radeon_device *rdev) rdev->pm.current_clock_mode_index = -1; } - if (rdev->pm.num_power_states > 1) { + if (radeon_pm && rdev->pm.num_power_states > 1) { if (rdev->pm.pm_method == PM_METHOD_PROFILE) { mutex_lock(&rdev->pm.mutex); rdev->pm.profile = PM_PROFILE_DEFAULT;

1 0

Re: 2.6.34-14 for F-13
by Didier G 15 Jun '10

15 Jun '10

On my machine with HD5770 manufactured by Gigabyte I have no problem with kernel 2.6.34.14 from Fedora or with vanilla 2.6.35-x As rv280 is an old GPU (2002) and as futur is power management, can I suggest to add a kernel command line option to disable power management but let power management enable by default ? This will allow people with no problem to continue to test it and people with problem to disable it. Didier. > 2.6.34-14 for F-13 [was Re: v2.6.34 for F-13] > Kyle McMartin kmcmartin at redhat.com > Tue Jun 1 09:02:17 UTC 2010 > > * Previous message: 2.6.34-14 for F-13 [was Re: v2.6.34 for F-13] > * Next message: 2.6.34-14 for F-13 [was Re: v2.6.34 for F-13] > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > On Tue, Jun 01, 2010 at 02:19:08AM -0500, Bruno Wolff III wrote: > > On my machine with an rv280 video card the screen would either blank or > > have repeated lines with glyphs that weren't characters. I tried > entering > > my luks password blind, but that didn't seem to work. It doesn't appear > > to have gotten far enough in the boot process to have logged anything > > in /var/log/messages. I have xorg-x11-drv-ati-6.13.0-2.fc13.i686 > installed > > which never got pushed to testing. > > I suspect this is due to radeon_pm being enabled. I'll disable that in > the next go around today. > > --Kyle

3 5

rpm-build 4.8.1 in F14 buildroots
by Kyle McMartin 14 Jun '10

14 Jun '10

Kernel builds have been failing when built noarch since rpm 4.8.1 went into the buildroots, it seems. https://koji.fedoraproject.org/koji/getfile?taskID=2247441&name=build.log The symptom is that rpm/usr/lib/rpm/check-files is failing because it thinks all the documentation in noarch is unpackaged. Any idea what we can do to fix this? --Kyle

4 5

mac80211,iwlwifi: fix connections to some APs (for F-12)
by Stanislaw Gruszka 13 Jun '10

13 Jun '10

Patches 1,2 resolves RHBZ 539878, all 4 patches are needed to resolve 558002. Patches are included in 2.6.35-rc and posted to -stable. Due to code change separate patches are needed for F-13 and F-14, they will follow.

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel June 2010