config changes
by Bill Nottingham
Here's some proposed config changes.
Bill
14 years, 10 months
alsa forth and back?
by Axel Thimm
Hi,
alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel
packages. Could someone explain why?
Thanks!
--
Axel.Thimm at ATrpms.net
14 years, 10 months
[PATCH] Disable kvmclock for non constant tsc cpus.
by Mark McLoughlin
Hi,
We've a pretty gnarly issue with KVM paravirt clock at the moment.
Basically, cpufreq can kick the TSC out of sync on CPUs and that
confuses the hell out of guests because the current code assumes the
same TSC rate on all CPUs.
The problem manifests itself as completely random hangs and guest
crashes, with the current workaround being to boot the guest with
clocksource=acpi_pm. See:
https://bugzilla.redhat.com/475598
Glommer, Gerd, Juan and Marcelo are all trying to figure out the best
fix, with the latest candidate being:
https://bugzilla.redhat.com/attachment.cgi?id=329812
But we'd really like to add this temporary patch to rawhide (and maybe
F10 if we don't fix it soon) ... any objections?
Thanks,
Mark.
From: Glauber Costa <glommer(a)redhat.com>
Date: Thu, 29 Jan 2009 12:39:22 -0500
Subject: [PATCH] Disable kvmclock for non constant tsc cpus.
Currently, this code path is posing us big troubles,
and we won't have a decent patch in time. So, temporarily
disable it.
See:
https://bugzilla.redhat.com/475598
There's a module parameter for the adventurous who want to force
it.
Signed-off-by: Glauber Costa <glommer(a)redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti(a)redhat.com>
Signed-off-by: Mark McLoughlin <markmc(a)redhat.com>
---
arch/x86/kvm/x86.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc17546..2e22ac9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -957,6 +957,9 @@ out:
return r;
}
+static int force_kvmclock = 0;
+module_param(force_kvmclock, bool, 0644);
+
int kvm_dev_ioctl_check_extension(long ext)
{
int r;
@@ -967,7 +970,6 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
case KVM_CAP_SET_TSS_ADDR:
case KVM_CAP_EXT_CPUID:
- case KVM_CAP_CLOCKSOURCE:
case KVM_CAP_PIT:
case KVM_CAP_NOP_IO_DELAY:
case KVM_CAP_MP_STATE:
@@ -992,6 +994,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_IOMMU:
r = iommu_found();
break;
+ case KVM_CAP_CLOCKSOURCE:
+ r = force_kvmclock || boot_cpu_has(X86_FEATURE_CONSTANT_TSC);
+ break;
default:
r = 0;
break;
--
1.6.1
14 years, 10 months
Skipping 2.6.28 for F8 and F9
by Chuck Ebbert
2.6.28 has turned out to be a bit buggy. Also 2.6.27 has been chosen to be
a long-term supported kernel upstream. This means we can leave F9 and F10
on .27 and concentrate on getting .29 into shape for F10 and F11. With the
extra resources available from not trying to fix up .28 we can make .29 even
better.
Comments?
14 years, 10 months
[PATCH] kernel: only build kernel-headers on ARM
by Kedar Sovani
Since kernels for different ARM CPUs differ wildly, and since
embedded folks tend to provide their own kernels, this patch makes
the Fedora kernel package only build kernel-headers when built for
ARM.
Please consider for inclusion.
Signed-off-by: Lennert Buytenhek <buytenh(a)marvell.com>
Signed-off-by: Kedar Sovani <kedars(a)marvell.com>
---
Makefile.config | 5 ++++-
config-arm | 15 +++++++++++++++
kernel.spec | 16 +++++++++++++---
3 files changed, 32 insertions(+), 4 deletions(-)
create mode 100644 config-arm
diff --git a/Makefile.config b/Makefile.config
index 09adc2e..bc1420a 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -9,7 +9,7 @@ CONFIGFILES = \
$(CFG)-i686.config $(CFG)-i686-PAE.config \
$(CFG)-i686-debug.config $(CFG)-i686-PAEdebug.config \
$(CFG)-x86_64.config $(CFG)-x86_64-debug.config \
- $(CFG)-s390x.config \
+ $(CFG)-s390x.config $(CFG)-arm.config \
$(CFG)-ppc.config $(CFG)-ppc-smp.config \
$(CFG)-sparc64.config $(CFG)-sparc64-smp.config \
$(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ppc64-debug.config \
@@ -102,6 +102,9 @@ kernel-$(VERSION)-ppc64-debug.config: config-powerpc64 temp-powerpc-debug-generi
kernel-$(VERSION)-s390x.config: config-s390x temp-s390-generic
perl merge.pl $^ s390 > $@
+kernel-$(VERSION)-arm.config: config-arm temp-generic
+ perl merge.pl $^ arm > $@
+
kernel-$(VERSION)-ppc.config: /dev/null temp-powerpc32-generic
perl merge.pl $^ powerpc > $@
diff --git a/config-arm b/config-arm
new file mode 100644
index 0000000..692f205
--- /dev/null
+++ b/config-arm
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+# CONFIG_SMP is not set
+
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+
+CONFIG_ARCH_VERSATILE=y
+
+CONFIG_ARM_THUMB=y
+
+CONFIG_AEABI=y
+CONFIG_OABI_COMPAT=y
+
+CONFIG_CMDLINE="console=ttyAM0,115200 root=/dev/sda1 rootdelay=20"
+
diff --git a/kernel.spec b/kernel.spec
index 04fc5ee..2ce025d 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -347,6 +347,14 @@ Summary: The Linux kernel
%define kernel_image vmlinux
%endif
+%ifarch %{arm}
+%define all_arch_configs kernel-%{version}-arm*.config
+%define image_install_path boot
+%define hdrarch arm
+%define make_target vmlinux
+%define kernel_image vmlinux
+%endif
+
%if %{nopatches}
# XXX temporary until last vdso patches are upstream
%define vdso_arches ppc ppc64
@@ -367,8 +375,8 @@ Summary: The Linux kernel
# Which is a BadThing(tm).
# We don't build a kernel on i386; we only do kernel-headers there,
-# and we no longer build for 31bit S390. Same for 32bit sparc.
-%define nobuildarches i386 s390 sparc
+# and we no longer build for 31bit S390. Same for 32bit sparc and arm.
+%define nobuildarches i386 s390 sparc %{arm}
%ifarch %nobuildarches
%define with_up 0
@@ -463,7 +471,7 @@ Version: %{rpmversion}
Release: %{pkg_release}
# DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD.
# SET %%nobuildarches (ABOVE) INSTEAD
-ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56
+ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56 %{arm}
ExclusiveOS: Linux
%kernel_reqprovconf
@@ -562,6 +570,8 @@ Patch00: patch-2.6.%{base_sublevel}-git%{gitrev}.bz2
%endif
%endif
+Source100: config-arm
+
%if %{using_upstream_branch}
### BRANCH PATCH ###
%endif
--
1.5.3.3
14 years, 10 months
Question: Is memory resource controller (cgroup) available in Fedora11 ?
by KAMEZAWA Hiroyuki
Hi,
I thought there was a request to make memroy resource controller
(CONFIG_CGROUP_MEM_RES_CTLR) availele in Fedora10 age.
(But not configured.)
I'd like to request memory cgroup configured in Fedora 11.
(I'm sorry if too late.)
Comapring current implementation(2.6.28) with the version half year ago,
- There is no pointer from struct page.
IIRC, this pointer was a big obstacle for the merge request.
BTW, what kernel version Fedora11 will be based on ?
I prefer 2.6.29-rc version of memory cgroup rather than 2.6.28 ;)
Thanks,
-Kame
14 years, 10 months
Semi-OT: Profiling 10GbE devices... Help?
by Gilboa Davara
Hello all,
I'm almost certain that is the not the right place to ask this question,
but if RedHat/Fedora's kernel engineers can't help me, I'm truly
screwed.
I'm are using two Intel 10GbE (ixgbe) cards to passively monitor 10GbE
lines (Under RHEL 5.2) either using the in-kernel dev_add_pack interface
(built-in ixgbe driver) or using a slightly modified ixgbe driver.
(built around Intel's latest ixgbe driver)
However, I'm experiencing odd performance issues - namely, once I
configure the driver to use MSI-X w/ multi-queue [MQ] (forcing pci=msi)
and assign each IRQ to one CPU core (irq cpu affinity), my software
requires -10x- more CPU cycles (measured using rdtsc; compared to
multiple GbE links and/or w/ MSI-X/MQ disabled) to process each packet,
causing massive missed IRQs (rx_missed_errors) induced packet loss.
Looking at mpstat I can see the each CPU core is handling a fairly low
number of interrupts (200-1000) while spending most of its time in
softIRQ. (>90%, most likely within my own code)
I decided to check newer kernels so I've installed F10 (24C Xeon-MP
Intel S7000FC4U) and F9 (16C Opteron DL585G5, *) on two machines, but
even with 2.6.27 kernels and I'm experiencing the same performance
issues.
Given the fact that the same code is used to process packets - no matter
what type of links are being used, my first instinct was to look at the
CPU cores themselves. (E.g. L1 & L2 dcache miss rates; TLB flushes;
etc).
I tried using oprofile, but I failed to make it work.
On one machine (Xeon-MP, F10), oprofile failed to identify the
Dunnington CPU (switching to timer mode) and on the other (Barcelona
8354, F9), even though it was configured to report dcache statistics
[1,2] opreport returns empty reports.
In-order to verify that oprofile indeed works on Opteron machine, I
reconfigured oprofile to report CPU usage [3], but even than, oprofile
either returns empty results to hard-locks the machine.
So:
A. Anyone else seeing the same odd behavior once MSI-X/MQ is enabled on
Intel's 10G cards? (P.S. MQ cannot be enabled on both machines unless I
add pci=msi to the kernel's command line)
B. Any idea why oprofile refuses to generate cache statistics and/or
what did I do wrong?
C. Before I dive into AMD's and Intel's MSR/PMC documentation and spend
the next five days trying to decipher which architectural /
non-architectural counter needs to set/used and how, do you have any
idea how I can access the performance counters without writing the code
myself?
- Gilboa
[1] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=DATA_CACHE_ACCESS:1000:0:1:1
[2] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=L2_CACHE_MISS:1000:0:1:1
[3] opcontrol --setup --vmlinux /usr/lib/debug/lib/modules/2.6.27.9-73.fc9.x86_64/vmlinux --event=CPU_CLK_UNHALTED:10000000:0:1:1
* F10 seems to dislike the DL585G5; Issue already reported against anaconda. (#480638)
14 years, 10 months