exec-shield=2
by Roland McGrath
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
13 years, 4 months
[Fedora PATCH] x86 config: turn off I2O support
by Prarit Bhargava
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
13 years, 5 months
Re: kernel-perf subpackage
by Arnaldo Carvalho de Melo
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
13 years, 5 months
kernel-perf subpackage
by Roland McGrath
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}}\
13 years, 5 months
kernel 2.6.35-rc3 pushed to rawhide
by Kyle McMartin
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
13 years, 5 months
v2.6.34 for F-13
by Kyle McMartin
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
13 years, 5 months
[PATCH] drm: radeon: provide a module_param toggle to enable/disable power management
by Kyle McMartin
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;
13 years, 5 months
Re: 2.6.34-14 for F-13
by Didier G
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
13 years, 5 months
mac80211,iwlwifi: fix connections to some APs (for F-12)
by Stanislaw Gruszka
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.
13 years, 5 months