Re: [PATCH] perf: install trace-event plugins
On Tue, Jun 03, 2014 at 07:54:03AM -0400, Josh Boyer wrote:
On Mon, Jun 2, 2014 at 3:11 PM, Kyle McMartin kmcma...@redhat.com wrote:
perf hardcodes $libdir to be lib for all but x86_64, so kludge around it
until upstream gets their act together.
Nice. Thanks Kyle. I'll get this in today.
I'll try to dream up something saner for upstream... Basically all this
perf machinery is junk and they've gone and reinvented autoconf with
less features... I don't know for example how Debian which installs into
multilib triplet dirs /usr/lib/i386-linux-gnu/*.so is going to handle
this besides doing something similar... :/
--Kyle
josh
--kyle
diff --git a/kernel.spec b/kernel.spec
index fbfa738..bee43f2 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -641,6 +641,8 @@ Patch25071:
s390-appldata-add-slab.h-for-kzalloc-kfree.patch
# CVE-2014-3917 rhbz 1102571 1102715
Patch25093: auditsc-audit_krule-mask-accesses-need-bounds-checking.patch
+Patch26000: perf-lib64.patch
+
# END OF PATCH DEFINITIONS
%endif
@@ -723,7 +725,7 @@ This package provides debug information for the perf
package.
# symlinks because of the trailing nonmatching alternation and
# the leading .*, because of find-debuginfo.sh's buggy handling
# of matching the pattern against the symlinks file.
-%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'.*%%{_bindir}/perf(\.debug)?|.*%%{_libexecdir}/perf-core/.*|XXX' -o
perf-debuginfo.list}
+%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'.*%%{_bindir}/perf(\.debug)?|.*%%{_libexecdir}/perf-core/.*|.*%%{_libdir}/traceevent/plugins/.*|XXX'
-o perf-debuginfo.list}
%package -n python-perf
Summary: Python bindings for apps which will manipulate perf events
@@ -1358,6 +1360,8 @@ ApplyPatch
s390-appldata-add-slab.h-for-kzalloc-kfree.patch
# CVE-2014-3917 rhbz 1102571 1102715
ApplyPatch auditsc-audit_krule-mask-accesses-need-bounds-checking.patch
+ApplyPatch perf-lib64.patch
+
# END OF PATCH APPLICATIONS
%endif
@@ -1893,7 +1897,7 @@ find $RPM_BUILD_ROOT/usr/include \
%if %{with_perf}
# perf tool binary and supporting scripts/binaries
-%{perf_make} DESTDIR=$RPM_BUILD_ROOT install-bin
+%{perf_make} DESTDIR=$RPM_BUILD_ROOT MULTILIBDIR=%{_lib} install-bin
install-traceevent-plugins
# remove the 'trace' symlink.
rm -f %{buildroot}%{_bindir}/trace
@@ -2092,6 +2096,8 @@ fi
%files -n perf
%defattr(-,root,root)
%{_bindir}/perf
+%dir %{_libdir}/traceevent/plugins
+%{_libdir}/traceevent/plugins/*
%dir %{_libexecdir}/perf-core
%{_libexecdir}/perf-core/*
%{_mandir}/man[1-8]/perf*
diff --git a/perf-lib64.patch b/perf-lib64.patch
new file mode 100644
index 000..3e3a33e
--- /dev/null
+++ b/perf-lib64.patch
@@ -0,0 +1,17 @@
+diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
+index 802cf54..7f30bfa 100644
+--- a/tools/perf/config/Makefile
b/tools/perf/config/Makefile
+@@ -621,8 +621,12 @@ endif
+ ifeq ($(IS_X86_64),1)
+ lib = lib64
+ else
++ifdef MULTILIBDIR
++lib = $(MULTILIBDIR)
++else
+ lib = lib
+ endif
++endif
+ libdir = $(prefix)/$(lib)
+
+ # Shell quote (do not use $(call) to accommodate ancient setups);
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH] perf: install trace-event plugins
On Tue, Jun 03, 2014 at 03:28:41PM -0400, Don Zickus wrote: On Tue, Jun 03, 2014 at 02:46:39PM -0400, Josh Boyer wrote: On Tue, Jun 3, 2014 at 2:45 PM, Don Zickus dzic...@redhat.com wrote: On Mon, Jun 02, 2014 at 03:11:01PM -0400, Kyle McMartin wrote: perf hardcodes $libdir to be lib for all but x86_64, so kludge around it until upstream gets their act together. Did you post this upstream too? Read later in the thread. He said he wants to come up with something better for upstream. I saw the part about 'dreaming up something better' and figured if a couple of beers can't conjure up an idea, Kyle would move on to more exciting things. :-p I figured if he poked upstream about it, they might be able to fix it faster. Regardless, I poked Jiri Olsa about it and he isn't familar enough with multilib to know how to fix it correctly. There isn't some doc floating around with best multilib practices or something is there? Well, the canonical answer would be to stop trying to poorly reinvent something awful, ie: autoconf, which already allows distros to set all this stuff in a standard way... For example, the stuff in /usr/lib/rpm/redhat/macros:%configure which lets us muck with $libdir and jazz. libdir is really the only thing with variation across distros that can't be handled in other ways, since the paths get hardcoded. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH] kernel.spec: xz compress modules on i686 and x86_64
On Wed, May 07, 2014 at 11:51:09AM -0400, Josh Boyer wrote: Right. So the kmod.prov script got moved to redhat-rpm-config. I'll look at getting it fixed to strip off the .xz to generate the proper Provides as Kyle suggested in his other reply. One thing I thought about earlier, was hardcoding the debuginfo phase earlier, and then compressing the modules. That way, we could sign the modules as part of the kernel build, and not have to have this hack (since by the time find-debuginfo.sh runs For real we've compressed the modules and they'll not be touched.) Possibly worth investigating rather than continuing our gross hardcode of __debug_install_post. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Feb. Fedora Kernel Patch Report
On Fri, Feb 28, 2014 at 10:13:29AM -0500, Josh Boyer wrote: It's been a while since I sent one of these. Mostly that's due to the overlap between which upstream stable version we're using in Fedora across the releases, and how fast those have been happening upstream. We're settled on 3.13.y now, and with 3.14-rc4 out there things have calmed down enough to take stock again. Here's the patches we have on top of 3.13.5. Thanks for doing this, Josh. --Kyle josh fs-proc-devtree-remove_proc_entry.patch - Upstream commit c1d867a54d426b45da017fbe8e585f8a3064ce8d drm-radeon-Disable-writeback-by-default-on-ppc.patch - This is superseded by upstream commit ea31bf697d27270188a93cd78cf9de4bc968aca3 but that seems to be a bit big for a stable backport dm-cache-policy-mq_fix-large-scale-table-allocation-bug.patch (rhbz 993744) - Still pending upstream (no idea why...) sunrpc-create-a-new-dummy-pipe-for-gssd-to-hold-open.patch sunrpc-replace-gssd_running-with-more-reliable-check.patch nfs-check-gssd-running-before-krb5i-auth.patch - Added to fix a 15sec mount delay - Upstream commits 4b9a445e3eeb8bd9278b1ae51c1b3a651e370cd6 89f842435c630f8426f414e6030bc2ffea0d6f81 6aa23d76a7b549521a03b63b6d5b7880ea87eab7 respectively rpc_pipe-remove-the-clntXX-dir-if-creating-the-pipe-fails.patch sunrpc-add-an-info-file-for-the-dummy-gssd-pipe.patch rpc_pipe-fix-cleanup-of-dummy-gssd-directory-when-notification-fails.patch - Fixes for some of the patches above (rhbz 1037793) - Upstream commits 3396f92f8be606ea485b0a82d4e7749a448b013b e2f0c83a9de331d9352185ca3642616c13127539 23e66ba97127ff3b064d4c6c5138aa34eafc492f respectively elantech-Properly-differentiate-between-clickpads-an.patch (rhbz 1030802) - Upstream commit c15bdfd5b9831e4cab8cfc118243956e267dd30e KVM-MMU-handle-invalid-root_hpa-at-__direct_map.patch (rhbz 924916) - Upstream commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 - Probably should grab 37f6a4e237303549c8676dfe1fd1991ceab512eb too KVM-VMX-fix-use-after-free-of-vmx-loaded_vmcs.patch (rhbz 1047892) - Upstream commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 0001-Input-wacom-make-sure-touch_max-is-set-for-touch-dev.patch 0002-Input-wacom-add-support-for-three-new-Intuos-devices.patch 0003-Input-wacom-add-reporting-of-SW_MUTE_DEVICE-events.patch - rhbz 1003167 1046238 - Upstream commits 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 b5fd2a3e92ca5c8c1f3c20d31ac5daed3ec4d604 961794a00eab03f4344b7d5e825e8e789e55da87 Input-ALPS-add-support-for-Dolphin-devices.patch (rhbz 953211) - Upstream commit ee65d4b36de8ddf4467f788faa5d8ddd1bfcdaa2 xhci-fix-resume-issues-on-renesas-chips-in-samsung-laptops.patch (rhbz 950630) - Upstream commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d - Oddly not queued for stable? cgroup-fixes.patch (rhbz 1045755) - Upstream commits 0ab02ca8f887908152d1a96db5130fc661d36a1e - There was a 3.12 version of this patch sent to stable list from Michal Hocko. I don't remember why it wasn't applied, or why it wasn't applied for 3.13.y... ipv6-introduce-IFA_F_NOPREFIXROUTE-and-IFA_F_MANAGETEMPADDR-flags.patch ipv6-addrconf-revert-if_inet6ifa_flag-format.patch - rhbz 1064430 1056711 - Backports of commits to add this stuff in 3.14. Not suitable for stable. cifs-ensure-that-uncached-writes-handle-unmapped-areas-correctly.patch cifs-sanity-check-length-of-data-to-send-before-sending.patch cifs-mask-off-top-byte-in-get_rfc1002_length.patch - rhbz 1064253 CVE-2014-0069 rhbz 1068862 - Upstream commit 5d81de8e8667da7135d3a32a964087c0faf5483f and two additional fixes cpufreq-powernow-k8-Initialize-per-cpu-data-structures-properly.patch (rhbz 1054408) - Upstream commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e - CC'd to stable but not queued e100-Fix-disabling-already-disabled-device-warning.patch (rhbz 994438) - Upstream commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 usb-ehci-fix-deadlock-when-threadirqs-option-is-used.patch - Still pending upstream ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Reworked Secure Boot patches
On Fri, Aug 30, 2013 at 08:21:28AM -0400, Josh Boyer wrote: I've been working on rebasing Fedora's secure boot approach to using the secure_module patches Matthew Garrett posted upstream. Below are the changes to do this. Things to note: 1) Most people won't even notice a change as the impacts to userspace remain the same. 2) We're dropping the pekey patches. It's a large chunk of code that is dead upstream and has no usage within Fedora. 3) The kexec patch should likely get reworked to prevent loading, and that has been noted upstream. 4) At some point we'll look at adding support for hibernate likely via the patches that OpenSUSE has introduced. 5) This falls back to using the upstream .modsign_keyring instead of .system_keyring. The concept of a system keyring is decent, but at the moment it isn't going anywhere upstream. We can look at switching back at some point in the future. ACK or something. ;-) ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH] Minor kernel configs cleanup merging duplicated config opts into generic
On Fri, Aug 16, 2013 at 04:13:34PM +0100, Peter Robinson wrote: Merge config changes from the various arch configs into generic-config where there's overlapping identical configs across all architectures. If there's a single arch that is difference to the rest of the architectures that option remains in the arch specific config as it takes precedence over the generic config. lgtm ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH v3] kernel.spec: let flavors/variants end with +$flavor in the uname
On Fri, Jul 19, 2013 at 11:01:27AM +0200, Harald Hoyer wrote: kernel.spec | 74 ++--- 1 file changed, 37 insertions(+), 37 deletions(-) ping? Since nobody else replies, I guess I'll do it. I think this change is unnecessary. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH] update s390x config
On Mon, Jul 15, 2013 at 08:30:54PM +0200, Dan Horák wrote: - disable various drivers not relevant for s390x - enable kdump support applied, thanks dan. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Unknown Symbol fc20
On Wed, Jul 10, 2013 at 10:17:22AM -0400, Dave Anderson wrote:
OK, but for those of us who use it, the change that presumably causes this
would be this part of this commit:
Yeah, we have duplicate declarations in crash-driver.patch... I've fixed
it now in rawhide.
commit c5a130325f13b219438cb100e2da71a3e31199f3
Author: Chen Gong gong.c...@linux.intel.com
Date: Thu Jun 6 15:20:51 2013 -0700
ACPI/APEI: Add parameter check before error injection
When param1 is enabled in EINJ but not assigned with a valid
value, sometimes it will cause the error like below:
APEI: Can not request [mem 0x7aaa7000-0x7aaa7007] for APEI EINJ Trigger
registers
It is because some firmware will access target address specified in
param1 to trigger the error when injecting memory error. This will
cause resource conflict with regular memory. So It must be removed
from trigger table resources, but incorrect param1/param2
combination will stop this action. Add extra check to avoid
this kind of error.
Signed-off-by: Chen Gong gong.c...@linux.intel.com
Signed-off-by: Tony Luck tony.l...@intel.com
diff --git a/kernel/resource.c b/kernel/resource.c
index d738698..77bf11a 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -409,6 +409,7 @@ int __weak page_is_ram(unsigned long pfn)
{
return walk_system_ram_range(pfn, 1, NULL, __is_ram) == 1;
}
+EXPORT_SYMBOL_GPL(page_is_ram);
void __weak arch_remove_reservations(struct resource *avail)
{
where the additional EXPORT_SYMBOL_GPL(page_is_ram) above now makes
it available from both kernel/resource.c and arch/x86/mm/ioremap.c.
Why would that make it an unknown symbol?
Dave
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Kernel versioning policy
On Mon, Jul 08, 2013 at 04:20:52PM +0200, Mateusz Marzantowicz wrote: What is a policy of choosing EXTRAVERSION in Fedora kernels? I've found some short info about what is 200, 300 etc. but I'd like to understand precise algorithm of giving everything that's between dash and fcNN (NN - fedora version). What does -300.x mean? Sorry, for my novice question but I can't find any reliable source of information about Fedora's kernel version naming policy. I don't think it's documented anywhere, and I'm not on the Fedora kernel team so this is a best guess, but: I assume it's set such that for two identical kernel versions, the fc19 version would always be NVR-newer than the fc18 version, so that you always get upgraded to a fc19 kernel when you update, instead of getting stuck. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH] kernel.spec: let flavors/variants end with +$flavor in the uname
On Thu, Jun 27, 2013 at 08:29:11AM +0200, Harald Hoyer wrote:
'/.*/3.10.0-0.rc6.git0.2.fc20.x86_64.smp/.*|/.*3.10.0-0.rc6.git0.2.fc20.x86_64.smp(.debug)?'
-o debuginfosmp.list -p
'/.*/3.10.0-0.rc6.git0.2.fc20.x86_64.%{pae}/.*|/.*3.10.0-0.rc6.git0.2.fc20.x86_64.%{pae}(.debug)?'
-o 'debuginfo%{pae}.list' -p
'/.*/3.10.0-0.rc6.git0.2.fc20.x86_64.%{pae}debug/.*|/.*3.10.0-0.rc6.git0.2.fc20.x86_64.%{pae}debug(.debug)?'
-o 'debuginfo%{pae}debug.list' -p
intentional. just like the .smp above, this comes from the fact that we
define kernel_variant_package for all the possible variants, but only
populate those which are built, which saves having an explosion of
%with_foo tests all over the place.
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [rawhide PATCH] config: enable NVMe driver
On Thu, Jul 19, 2012 at 03:21:07PM -0500, Justin M. Forbes wrote: --- a/config-generic +++ b/config-generic @@ -248,7 +248,7 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m -# CONFIG_BLK_DEV_NVME is not set +CONFIG_BLK_DEV_NVME=m CONFIG_BLK_DEV_OSD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 Done, this should be in the next build. Thanks, I did a test scratch build after renewing my damned ssl key and it looks like it should be fine on the srpm build as well (I only tested upstream.) --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[rawhide PATCH] config: enable NVMe driver
Seems to build on i386 now, so it should probably be built as a module. --- a/config-generic +++ b/config-generic @@ -248,7 +248,7 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m -# CONFIG_BLK_DEV_NVME is not set +CONFIG_BLK_DEV_NVME=m CONFIG_BLK_DEV_OSD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[PATCH] rawhide: enable HYPERV drivers
Never noticed these had made it out of the staging doghouse in 3.2... should we enable them like the other v12n stuff? (Not on the list for some reason, I should probably fix that.) --Kyle --- a/config-x86-generic +++ b/config-x86-generic @@ -394,7 +394,11 @@ CONFIG_SCHED_SMT=y CONFIG_CC_STACKPROTECTOR=y CONFIG_RELOCATABLE=y -# CONFIG_HYPERV is not set +CONFIG_HYPERV=m +CONFIG_HYPERV_UTILS=m +CONFIG_HID_HYPERV_MOUSE=m +CONFIG_HYPERV_NET=m +CONFIG_HYPERV_STORAGE=m # Depends on HOTPLUG_PCI_PCIE CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[PATCH] attempt to not install to buildroot in %build
This can probably be better but...
---
kernel.spec | 112 +-
1 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index ff5734e..1e38fbe 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1,6 +1,3 @@
-# We have to override the new %%install behavior because, well... the kernel
is special.
-%global __spec_install_pre %{___build_pre}
-
Summary: The Linux kernel
# For a stable, released kernel, released_kernel should be 1. For rawhide
@@ -1386,6 +1383,8 @@ cd ..
###
%build
+TARGET=$PWD/buildroot-%{rpmversion}-%{pkg_release}
+
%if %{with_sparse}
%define sparse_mflags C=1
%endif
@@ -1457,36 +1456,36 @@ BuildKernel() {
# Start installing the results
%if %{with_debuginfo}
-mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot
-mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
+mkdir -p $TARGET%{debuginfodir}/boot
+mkdir -p $TARGET%{debuginfodir}/%{image_install_path}
%endif
-mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
+mkdir -p $TARGET/%{image_install_path}
+install -m 644 .config $TARGET/boot/config-$KernelVer
+install -m 644 System.map $TARGET/boot/System.map-$KernelVer
# We estimate the size of the initramfs because rpm needs to take this size
# into consideration when performing disk space calculations. (See bz
#530778)
-dd if=/dev/zero of=$RPM_BUILD_ROOT/boot/initramfs-$KernelVer.img bs=1M
count=20
+dd if=/dev/zero of=$TARGET/boot/initramfs-$KernelVer.img bs=1M count=20
if [ -f arch/$Arch/boot/zImage.stub ]; then
- cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
+ cp arch/$Arch/boot/zImage.stub
$TARGET/%{image_install_path}/zImage.stub-$KernelVer || :
fi
$CopyKernel $KernelImage \
- $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
-chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ $TARGET/%{image_install_path}/$InstallName-$KernelVer
+chmod 755 $TARGET/%{image_install_path}/$InstallName-$KernelVer
-mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
+mkdir -p $TARGET/lib/modules/$KernelVer
# Override $(mod-fw) because we don't want it to install any firmware
# we'll get it from the linux-firmware package and we don't want conflicts
-make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer mod-fw=
+make -s ARCH=$Arch INSTALL_MOD_PATH=$TARGET modules_install
KERNELRELEASE=$KernelVer mod-fw=
%ifarch %{vdso_arches}
-make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install
KERNELRELEASE=$KernelVer
+make -s ARCH=$Arch INSTALL_MOD_PATH=$TARGET vdso_install
KERNELRELEASE=$KernelVer
if [ ! -s ldconfig-kernel.conf ]; then
echo ldconfig-kernel.conf \
# Placeholder file, no vDSO hwcap entries used in this kernel.
fi
%{__install} -D -m 444 ldconfig-kernel.conf \
-$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf
+$TARGET/etc/ld.so.conf.d/kernel-$KernelVer.conf
%endif
# And save the headers/makefiles etc for building modules against
@@ -1496,52 +1495,52 @@ BuildKernel() {
# * all Makefile/Kconfig files
# * all script/ files
-rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
-rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/source
-mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
-(cd $RPM_BUILD_ROOT/lib/modules/$KernelVer ; ln -s build source)
+rm -f $TARGET/lib/modules/$KernelVer/build
+rm -f $TARGET/lib/modules/$KernelVer/source
+mkdir -p $TARGET/lib/modules/$KernelVer/build
+(cd $TARGET/lib/modules/$KernelVer ; ln -s build source)
# dirs for additional modules per module-init-tools, kbuild/modules.txt
-mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/extra
-mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/updates
+mkdir -p $TARGET/lib/modules/$KernelVer/extra
+mkdir -p $TARGET/lib/modules/$KernelVer/updates
# first copy everything
-cp --parents `find -type f -name Makefile* -o -name Kconfig*`
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build
-cp Module.symvers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
-cp System.map $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+cp --parents `find -type f -name Makefile* -o -name Kconfig*`
$TARGET/lib/modules/$KernelVer/build
+cp Module.symvers $TARGET/lib/modules/$KernelVer/build
+cp System.map $TARGET/lib/modules/$KernelVer/build
if [ -s Module.markers ]; then
- cp Module.markers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+ cp Module.markers $TARGET/lib/modules/$KernelVer/build
fi
# then drop all but the needed Makefiles/Kconfig files
-rm -rf
Re: 3.0.rc4 / 3.0 rc5.git5
On Mon, Jul 04, 2011 at 12:14:55PM -0400, Genes MailLists wrote: W: Possible missing firmware nouveau/fuc41ad for kernel module nouveau.ko http://nouveau.freedesktop.org/wiki/NVC0_Firmware and related information. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Tue, Jun 21, 2011 at 05:25:19PM +0200, Oleg Nesterov wrote: I understand. Once again, it was supposed to be a temporary solution until fedora switches to 3.1. And the reverted code does not make the real difference so far, the user-visible changes are minor. Yeah, I understand, it just looks bad for us. OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we should do this again in 3.1. I'll try to do something. I don't think worrying about 3.0 is necessary... it won't ship in anything, and we should be well on our way to 3.1 by the time we branch F-16 in 5 weeks, focusing effort there seems more sensible. (Rawhide will be changing awfully rapidly in the mean time anyway.) --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Fwd: MCE trouble booting Fedora 14
On Fri, May 13, 2011 at 01:25:38PM -0400, Kyle McMartin wrote: On Fri, May 13, 2011 at 01:23:22PM -0400, Steve Dickson wrote: Does anybody have a clue as to what is happening That's pretty weird, any chance they could try one of the Fedora 15 beta images? The 2.6.35.y kernels in F-14 are pretty crufty. :/ If they need a quick workaround, nosmp might help. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [kernel] Add a no lvds quirk for the Asus EB1007 to the i915 drm
On Thu, Apr 07, 2011 at 11:59:41AM +, Hans de Goede wrote: commit 042ba03b683a8705f44d86b5283cb84de54d4970 Author: Hans de Goede hdego...@redhat.com Date: Thu Apr 7 14:01:43 2011 +0200 Add a no lvds quirk for the Asus EB1007 to the i915 drm driver, this fixes gnome-shell not working on it Just curious, have you submitted it upstream? I don't see it on intel-gfx@ or linux-kernel@. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Oops on 2.6.34.8-68.fc13.x86_64
On Wed, Mar 23, 2011 at 09:43:32PM +0100, Ruben Kerkhof wrote: want to test: http://koji.fedoraproject.org/koji/taskinfo?taskID=2936814 and make sure I didn't screw up the backport? Sure, once I've figured out how to get it installed since I'm running the same version :) I've got it running now, and will generate some network traffic for a few hours to see if the problem has disappeared. I'll report back tomorrow. Thanks again! no problem, i should have cranked baserelease by .1 for the scratch build. :/ thanks for testing. --kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: config-local question
On Wed, Mar 09, 2011 at 08:29:35AM -0500, Don Zickus wrote: On Tue, Mar 08, 2011 at 06:26:13PM -0500, M Whitehead wrote: Don, I'm trying compile a F14 2.3.37-2 kernel with some support for old hardware. I'm trying to re-enable CONFIG_ISA and a few old ethernet cards such as CONFIG_EL2. Putting them into config-local doesn't seem to be turning them back on. Do you know what dependency I might have missed? I would need to see your .config to see what you are doing wrong, but it works for me over here. CONFIG_ISA seems to be enabled by default on Fedora in the git tree so you shouldn't have to do anything there. config-local was added after the branch to 2.6.37-git$x, ttbomk. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Tracking Rawhide's (released) kernel rpms through kernel.git
On Wed, Feb 23, 2011 at 10:46:02AM +0100, Paul Bolle wrote: Is it possible to track the (released) kernel rpms for Rawhide through kernel.git (git://pkgs.fedoraproject.org/kernel.git ) and build the (released) kernel rpms locally? https://fedoraproject.org/wiki/Building_a_non-debugging_kernel Basically follow these directions, but throw your own patches. I recommend patching your stuff in at the beginning of the list of patches, since they change less. Then you can git diff that, and probably reapply it every time you have to merge. YMMV, No warranty, guarantee void in Tennessee, etc. Don't complain to us about bugs. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: 2.6.18 netlink_kernel_create() always returns NULL
On Tue, Feb 22, 2011 at 11:10:49PM +0800, YANG wrote: My code fragment is below: nl_sk = netlink_kernel_create(16, 0, nl_data_ready, THIS_MODULE); It can be make and insmod correctly. But error mesage is printed into log. It indicates the netlink_kernel_create() returns NULL. Once I change the firt parameter to another(32 16), system crash when I execute insmod. Is the protocol ID occupied? Why can't use another and how to define a new ID? I have tried to update net_link.h but fail also. I'd highly suggest if you are running Fedora that you upgrade to something from this decade... If you're running CentOS5, you'll have to find a new mailing list, we don't do support for that here. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: 2.6.18 netlink_kernel_create() always returns NULL
On Tue, Feb 22, 2011 at 11:57:07PM +0800, 老杨 wrote: I feel sad for that. My question is suggested to post here from centos list because there has no such lists relevant to kernel. For this problem,is there other reasons besides version? If CentOS cannot provide you the support you need, maybe you shouldn't use CentOS. Posting your question here because they are incapable of providing you support is entirely inappropriate, like someone posting a question about Ubuntu on this list. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Update needed to Fedora13 Kernel Source
On Tue, Feb 08, 2011 at 01:20:02PM +, Paoloni, Gabriele wrote: In the Fedora13 Kernel Source there is an issue with the Intel AGP driver that does not allow the X server to start on some Sandybrige platform. The issue has been solved in the Vanilla 2.6.35 according to the commits inline below and as consequence also in the latest updated Fedora14 kernel. OK, no problem, this looks like it should be fine, I'll pull these patches in. --Kyle http://www.spinics.net/lists/stable-commits/msg08831.html http://www.spinics.net/lists/stable-commits/msg08832.html http://www.spinics.net/lists/stable-commits/msg08833.html ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH 1/3] [RFC] Print a device-tree message at KERN_WARNING level
On Thu, Feb 03, 2011 at 09:31:40PM -0500, Josh Boyer wrote: You should only see this if you are running on a machine that has an OpenFirmware style device tree and CONFIG_OF and CONFIG_PROC_DEVICETREE are set. Given the other patches in your set, I don't think you are running on a PowerPC machine. Unless you have an OLPC, then your config is just adding bloat. (And if you do have an OLPC, that would be odd anyway.) On machines where this is supposed to be used, it likely is an error. That being said, you can send this patch to the devicetree-discuss mailing list on list.ozlabs.org for further feedback. The OLPC config options seem to have mutated, but at any rate, if people are (still) running Fedora on OLPC, then we need to continue with this. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: linux-2.6-enable-more-pci-autosuspend.patch
On Mon, Jan 24, 2011 at 09:37:50PM +, Matthew Garrett wrote: It's effectively superceded in terms of implementation by the implicit notify support, so I'll verify that that works as expected and do any fixups. Awesome, thanks much. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: linux-2.6-debug-nmi-timeout.patch
On Mon, Jan 10, 2011 at 11:39:11AM -0500, Don Zickus wrote: Dropping the patch is appropriate. x86 stopped using the old nmi watchdog awhile ago, and Fedora seemed to have been using the new nmi_watchdog, so the patch does nothing now. Fair enough. :) --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [kernel: 2/2] Merge branch 'kernel-git'
On Thu, Dec 09, 2010 at 06:52:40PM +, Kyle McMartin wrote: commit eae11717a184705aad08a3783cba964bfa3a06dd Merge: 72b3729 cbb0019 Author: Kyle McMartin k...@redhat.com Date: Thu Dec 9 13:52:05 2010 -0500 Merge branch 'kernel-git' Sorry for the commit noise... the summary is that I squashed master into kernel-git (by using strategy 'ours') and then merged that back to kernel-git, which squashed the commits back. (Turns out -X theirs doesn't do what you want when there isn't a conflict... that's why I backed out the previous.) I think I cherry picked everything relevant from rawhide, but if you've touched it, you might want to make sure. Thanks, Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Fedora 15 Schedule
On Fri, Dec 03, 2010 at 02:49:48PM -0800, John Poelstra wrote: Any other dates the kernel team would like added to the schedule? If I don't hear anything by this Friday I will assume we've captured what you want. See the kernel tasks added to the development schedule and let me know if I can add anything else for you. http://poelstra.fedorapeople.org/schedules/f-15/f-15-devel-tasks.html Thanks very much for all your hard work, John. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Fedora 15 Schedule
On Thu, Nov 25, 2010 at 04:41:35AM +0100, Micha? Piotrowski wrote: So, whats with Xen support? http://lists.fedoraproject.org/pipermail/virt/2010-November/002324.html Personally, I don't care. If all the required things will be merged into 2.6.38 it's still too late, because of Tue 08-Feb Tue 08-Feb Feature Freeze (Testable|Complete) I put conservative things in the timeline, but said 2.6.37 in mid-January which implies 2.6.38-rc1 in mid-January + approximately 2.5 weeks which I would round to the first week of February because of LCA. If the Xen stuff is merged by 2.6.38-rc1 (and if it's not, it won't be in 2.6.38 at all) then I don't see why it can't be a feature. They'll just have to work on all their pieces seperately to begin with. I know it will probably be in F16, but for the F15 might be at hand (if all required Xen stuff will be merged into mainline). I'm not taking backports of core kernel code. Full stop. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: F14: tpm prevents suspend
On Fri, Oct 22, 2010 at 12:57:49PM +0530, Amit Shah wrote: Hello, While trying out 2.6.35.6-46.fc14.x86_64 on an F13 userspace, suspend fails on an X200 laptop: https://bugzilla.redhat.com/show_bug.cgi?id=644842 Bryan O'Sullivan on the bug reports kernel-2.6.35.4-28.fc14.x86_64 works, and this is a recent regression. Try this? http://koji.fedoraproject.org/koji/buildinfo?buildID=201535 It'll either be in F-14 if there's a blocker causing a respin, or a 0-day update post-release. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: ima: use of radix tree cache indexing == massive waste of memory?
On Mon, Oct 18, 2010 at 12:48:54PM -0400, Eric Paris wrote: I'll can address this on the fedora list, but I think this is the wrong approach. IMA is supposed to be of negligible impact when not 'enabled' and I believe the right solution is to fix places where that isn't true. At the moment 3 have been identified. My beef is #2, which is what I want to see solved. If there's a million people using Fedora, and 2 people use IMA, that's an awful lot of bytes that could be otherwise used. I think it should be entirely opt in, with a CONFIG_IMA_DEFAULT_ON or something like we do for security hooks. Anyway, If you can address #2, then I'm happy having it enabled. If it's taken us this long to notice the impact, then it doesn't seem to be all that large in the general case, and if it can be reduced, then that should make everyone happy. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Duplicate kernel-headers after upgrading to 2.6.35
On Fri, Oct 15, 2010 at 04:16:35PM +0200, Ryad Ben-El-Kezadri wrote: I will have to compile applications in userland that needs the new headers. Can I safely remove the old headers? Unless you need something from the new ones, you should probably keep the /old/ headers instead, since those are the ones the C library is built against (roughly.) I'm not entirely sure why that wiki page recommends installing new headers, but it probably shouldn't. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 12:37:42PM +1100, Rodd Clarkson wrote: Kyle, Sorry to email you off list, but I've noticed a number of other small issues with this kernel that I'm not sure are worth reporting on as it's an f15 kernel and I'm using f14. It's ok, though I'd prefer you just use the fedora-kernel-list for questions like this. (I added you to the allowed-senders list incase you didn't want to subscribe.) Examples include: The trackpad is 'sticky', with the action being jerky, but it's fine with a different pointing device (a logitech wireless mouse, for example). Sound is glitchy. Are these bugs worth filing against this kernel, or should I ignore them? There's no real meaty patches to either of these in F-14 or rawhide, so I'm not sure. I'll ask Peter about the input stuff, but I suspect that's close between F-14 and rawhide as well, so it's probably a legitimate bug in 2.6.36... --Kyle R. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Comparing other distros kernels to Fedora.
On Tue, Oct 12, 2010 at 01:09:18PM +0200, Micha? Piotrowski wrote: It might be a patch added by one of Fedora kernel developers. CC'ing fedora-kernel Honestly, there's nothing particularly relevant in F-14's kernel. Can you please try: http://kyle.fedorapeople.org/kernel/2.6.36-0.36.rc7.git3.fc15/x86_64/ Which is a nodebug rawhide kernel, which is even closer to upstream than the F-14 2.6.35 is, and let us know if that's any more helpful? (I could swear someone was doing pre-built vanilla kernels, we should bring that back if not.) --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: FYI: RIP: 0010:[ffffffff8122f04f] [ffffffff8122f04f] cfq_free_io_context+0x18/0x34
On Sun, Sep 26, 2010 at 04:04:43PM +0200, Micha? Piotrowski wrote: Hi Jan, I think that this problem is caused by bdi-fix-warnings-in-__mark_inode_dirty-for-dev-zero-and-friends.patch Fwiw, this just got dropped from stable. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: FYI: RIP: 0010:[ffffffff8122f04f] [ffffffff8122f04f] cfq_free_io_context+0x18/0x34
On Fri, Sep 24, 2010 at 02:50:35PM +0200, Micha? Piotrowski wrote: I looked at that on Monday, but haven't found it yet. So it is a known problem. Good to know. Aside from you reporting it, no, I haven't seen anything aside from some mails from Alexey in 2008. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: FYI: RIP: 0010:[ffffffff8122f04f] [ffffffff8122f04f] cfq_free_io_context+0x18/0x34
On Fri, Sep 24, 2010 at 09:03:00AM -0400, Kyle McMartin wrote: On Fri, Sep 24, 2010 at 02:50:35PM +0200, Micha? Piotrowski wrote: I looked at that on Monday, but haven't found it yet. So it is a known problem. Good to know. Aside from you reporting it, no, I haven't seen anything aside from some mails from Alexey in 2008. (This one fwiw: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/30/1984184) ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: FYI: RIP: 0010:[ffffffff8122f04f] [ffffffff8122f04f] cfq_free_io_context+0x18/0x34
On Thu, Sep 23, 2010 at 01:06:25PM +0200, Micha? Piotrowski wrote: RSP: 0018:88000d909d90 EFLAGS: 00010202 RAX: 0001075550e9 RBX: 6b6b6b6b6b6b6b6b RCX: Oh, poop, this is a use-after-free somewhere, and cfq is likely not the culprit... ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Re-compiling kernel-2.6.33.6-147.2.4
On Tue, Aug 10, 2010 at 09:23:29PM -0400, Jarod Wilson wrote: On Tue, Aug 10, 2010 at 9:16 PM, JD jd1...@gmail.com wrote: During build of this kernel, I got the following compilation error: I needed to add another kernel feature (added full preemption) CONFIG_PREEMPT=y so This isn't a bug. We don't support building other configurations than the one we provide. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: kernel dist-git
On Thu, Jul 29, 2010 at 01:48:49AM -0700, Roland McGrath wrote: The master branch (aka devel aka rawhide) is just all messed up. The kernel.spec is the right one, but nearly all the other files are the entirely wrong ones, as if it got everything else from another branch (including adding/removing files). It looks like a lot of the loss came in when rawhide was cvs branched for private-f14-2_6_34, a lot of the deleted files exist from that point in the git tree. That branch is useless now, can we re-run the script ignoring it and see what happens? --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: perf package
On Wed, Jul 07, 2010 at 05:15:10PM -0700, Roland McGrath wrote: This might mean some kind of pain for wrong-dominant multilib distros, but those people can pummel us later. Or maybe ppc32-built perf can talk to a ppc64 kernel OK, hell if I know. It certainly should be able to. I've been carefully watching the perf interface (parisc and all that) and it is quite 64-bit clean. That said, it would be cool if someone would test it... I suppose I could update my g5. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
kernel 2.6.35-rc3 pushed to rawhide
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 ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[PATCH] drm: radeon: provide a module_param toggle to enable/disable power management
From: Kyle McMartin k...@redhat.com
Allows us to narrow down power management related issues.
Signed-off-by: Kyle McMartin k...@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;
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [Fedora PATCH] x86 config: turn off I2O support
On Tue, Jun 15, 2010 at 09:35:43AM -0400, Prarit Bhargava wrote: 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. Thanks Prarit, I've applied this. (With one nit, we don't need to # CONFIG_I2O is not set in x86-generic since it's unset in config-generic, so we can just nuke it from orbit.) --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: 2.6.34-14 for F-13
On Wed, Jun 02, 2010 at 10:47:29PM +0200, Didier G wrote: 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. The latest 2.6.34-$x have a module option for this now. Let me know if I made a hash of it. It's off by default so boot with radeon.pm=1 if you want to use it. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
2.6.34-38 for F-13 [was Re: v2.6.34 for F-13]
Okies folks, feel free to pull the fc14 kernels from koji and try them out on F-13. http://koji.fedoraproject.org/koji/buildinfo?buildID=178210 I've sucked in the remainder of the DRM fixes from 2.6.35-rc3, so hopefully things are more or less where we wanted them to be for F-13. I've added a module param for enabling radeon power management, which defaults to off, so feel free to turn it back on and give it a try by passing radeon.pm=1 to the kernel. Don't blame me if it turns your cat into a badger or fills your computer with cobras or something. Have fun, Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: 2.6.34-14 for F-13
On Tue, Jun 15, 2010 at 12:51:40PM -0500, Bruno Wolff III wrote: Do I need a dist-f13 build of 2.6.34-38 to usefully test things on an F13 system? Nope... at least, I'm not and it didn't cause any issues. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: rpm-build 4.8.1 in F14 buildroots
On Mon, Jun 14, 2010 at 09:43:40AM +0300, Panu Matilainen wrote: If that known-to-build version fails to build with 4.8.1 then sure, we appear to have an rpm regression no matter how unlikely it should seems to me given the changes in 4.8.0 - 4.8.1. But until proven otherwise, I'd say the kernel.spec cleanup efforts have broken the noarch case. It's not exactly hard to break a spec of that complexity :) http://koji.fedoraproject.org/koji/taskinfo?taskID=2248476 We'll see. Given only the s390 and kdump code was removed, which hasn't even been built in years, it's unlikely to *not* be an rpm issue. --Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: rpm-build 4.8.1 in F14 buildroots
On Mon, Jun 14, 2010 at 10:23:17AM -0400, Dave Jones wrote: I don't see how. The man page generation part of the spec is no different from what we have in F13. I've looked over the changes I did, and don't see anything that would trigger that failure. (not denying it caused it, it's possible I've overlooked something, but I'm just not seeing it) Nor I, but reverting it fixes it. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: 2.6.34-14 for F-13 [was Re: v2.6.34 for F-13]
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 ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
On Wed, Apr 14, 2010 at 10:01:51AM +0200, Hans de Goede wrote: i've written support for acpi enumeration which seems to be working; i'll commit it tomorrow after one of my final exams, and drop the pnp neutering. --kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
friendly reminder about kernel branches
To avoid future confusion: - F-11/ and F-12/: - 2.6.32, which will hopefully be going into updates RSN. - F-13/: - 2.6.33, currently in -RC. Will be staying there quite likely until Fedora 13 releases, unless 2.6.34 comes out well before -RC of F-13. - **Your commits for Fedora should go here.** - devel/: - Fedora 14 branch, will fork to F-14/ in a couple months. - Currently 2.6.33-rc as F-13. Moving to 2.6.34-git immediately after 2.6.33 is stable. - Commits should *not* happen here. Get your patches upstream for 2.6.34. - (Frankly I'm tempted to just remove everyone elses commit bits until we open it to encourage F-13 commits...) There are stable branches of F-11 and F-12, containing 2.6.30 and 2.6.31 respectively. These are maintenance mode only, pushed straight to stable so that security fixes can get to users who may have issues with the 2.6.32 in updates-testing. You can get them by: $ cd rpms/kernel; mkdir stable; pushd stable; stable$ cp -a ../F-12 .; pushd F-12; cvs up -dr \ private-fedora-12-2_6_31; popd And ditto with F-11 and private-fedora-11-2_6_30 regards, Kyle. ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [GIT][IMA] fix null pointer deref (fwd)
On Mon, Feb 08, 2010 at 09:14:48AM +0800, Eugene Teo wrote: 6c21a7fb492bf7e2c4985937082ce58ddeca84bd was introduced in v2.6.33-rc1. Right, my question is, do we need the patch in the top mail of this thread, or not? regards, Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [GIT][IMA] fix null pointer deref (fwd)
On Sun, Feb 07, 2010 at 06:38:10PM +1100, James Morris wrote: FYI, This was introduced in 6c21a7fb492bf7e2c4985937082ce58ddeca84bd, i.e. in 2.6.32-rc5, it seems. Hi James, confused as to which patch fixes this, as in a private bug Viro identified a patch that kills the security_ call into IMA... I've pulled this patch into Fedora for now though. regards, Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [GIT][IMA] fix null pointer deref (fwd)
On Mon, Feb 08, 2010 at 11:55:34AM +1100, James Morris wrote: Wasn't it introcided in 2.6.32-rc5? Doesn't look like it... k...@ihatethathostname ~/src/linux-2.6 $ git log v2.6.32..master -- security/security.c | grep ima LSM: imbed ima calls in the security hooks security_ and ima_ calls in the vfs layer, move the ima_ calls to Looks to be added post-2.6.32 (not entirely sure why git-describe says k...@ihatethathostname ~/src/linux-2.6 $ git describe 6c21a7fb492bf7e2c4985937082ce58ddeca84bd v2.6.32-rc1-15-g6c21a7f ) regards, Kyle k...@ihatethathostname ~/src/linux-2.6 $ git cherry-pick 89068c576bf324ef6fbd50dfc745148f7def202c warning: too many files (created: 347 deleted: 1475), skipping inexact rename detection Finished one cherry-pick. # On branch stable-2.6.32 nothing to commit (working directory clean) regards, Kyle -- James Morris jmor...@namei.org ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: [PATCH 4/4] virtio: console: Add support for multiple devices and ports
On Fri, Feb 05, 2010 at 10:20:34AM +0530, Amit Shah wrote: This commit backports virtio console functionality that will be introduced in the 2.6.34 kernel for a guest-host communication channel. See the Fedora feature page for more information: https://fedoraproject.org/wiki/Features/VirtioSerial Applied, please keep us up to date with any fixes occuring upstream. regards, Kyle ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
