January 2009 - kernel - Fedora mailing-lists

config changes
by Bill Nottingham 14 Feb '09

14 Feb '09

Here's some proposed config changes. Bill

9 14

alsa forth and back?
by Axel Thimm 30 Jan '09

30 Jan '09

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

3 4

[PATCH] Disable kvmclock for non constant tsc cpus.
by Mark McLoughlin 29 Jan '09

29 Jan '09

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

1 0

crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27?
by Tom Davidson 28 Jan '09

28 Jan '09

Hi all, Bug 470225 crashes systems with Intel 3945/4965/5300 wireless cards on busy networks. The kernel warning generated is currently the #1 most-reported item at kerneloops (www.kerneloops.org -- several k reports mostly from FC10 machines) Intel has produced a patch, and John Linville has applied this to the 2.6.28 kernel (available from koji), but it now sounds like 2.6.28 might not make it out soon, or ever. Can this fix be applied to the 2.6.27 branch? Thanks much! Tom References: https://bugzilla.redhat.com/show_bug.cgi?id=470225 (Bug at Redhat) http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1822 (Bug at Intel) http://kerneloops.org/searchweek.php?search=rs_get_rate (Counts of warnings reported to kerneloops)

5 6

Re: Package: kernel-2.6.29-0.59.rc2.git3.fc11 Tag: dist-f11 Status: failed Built by: markmc
by Mark McLoughlin 28 Jan '09

28 Jan '09

Hey, I enabled CONFIG_PCI_STUB (#482792), but the build failed on ppc: drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_load': drivers/gpu/drm/nouveau/nouveau_state.c:487: error: implicit declaration of function '___swab32' make[4]: *** [drivers/gpu/drm/nouveau/nouveau_state.o] Error 1 http://koji.fedoraproject.org/koji/getfile?taskID=1088040&name=build.log I considered disabling nouveau again, but I see the last few commits haven't been built so I just left it be. Cheers, Mark.

2 1

Skipping 2.6.28 for F8 and F9
by Chuck Ebbert 27 Jan '09

27 Jan '09

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?

2 1

[PATCH] kernel: only build kernel-headers on ARM
by Kedar Sovani 26 Jan '09

26 Jan '09

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

2 3

Re: rpms/kernel/devel linux-2.6-defaults-intel_iommu-off.patch, NONE, 1.1 kernel.spec, 1.1225, 1.1226
by Mark McLoughlin 26 Jan '09

26 Jan '09

Hi Kyle, On Fri, 2009-01-23 at 18:49 +0000, Kyle McMartin wrote: > * Fri Jan 23 2009 Kyle McMartin <kyle(a)redhat.com> > - disable intel_iommu by default (enable with "intel_iommu=on") Why so? We're pretty much guaranteed that no-one will enable this ... do we know of specific hardware that this is breaking? One of the major virt features in F11 needs this: https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment Thanks, Mark.

1 1

Question: Is memory resource controller (cgroup) available in Fedora11 ?
by KAMEZAWA Hiroyuki 25 Jan '09

25 Jan '09

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

3 4

Semi-OT: Profiling 10GbE devices... Help?
by Gilboa Davara 24 Jan '09

24 Jan '09

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)

1 1

Re: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
by Bron Gondwana 23 Jan '09

23 Jan '09

Hi, I'm chasing this up on the kernel mailing list now. We hit exactly the same issue on a production Postfix machine, which also uses epoll in this way. I've taken your suggestions of 1024 as a good point - I've also seen that value suggested elsewhere on the internet, so that sounds reasonable. We've set 4096 in /etc/sysctl.conf to be certain we're OK! Bron.

1 0

F10 EDAC Errors on intel based server
by Ted Sume Nzuonkwelle 22 Jan '09

22 Jan '09

Hi, Just did a new install of Fedora 10 on an 8 core intel server (2 quad cores) and i got the following messages during first boot. They are continuosly being printed to the terminal just about every second. I originally had an install of Fedora 9 on this server and did not see any such errors. kernel version 2.6.27.5-117.fc10.x86_64 Below are the errors EDAC i5000 MCO: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x40000 EDAC i5000: SPD Protocol Error, bits=0x40000 Any thoughts why this is happening? - Ted

2 2

Switching Fedora to pae kernel by default?
by Avi Kivity 21 Jan '09

21 Jan '09

This probably comes up once in a while, thought I'd raise it again. I'd like to suggest switching the default kernel to -PAE on machines that support it, for the following reasons: - many machines have 4GB+ these days, even desktops - NX is only available with -PAE, improves security - kvm is significantly faster on AMD when PAE is selected (since we don't support NPT on non-PAE) Not subscribed - please copy. -- error compiling committee.c: too many arguments to function

15 33

PPC kernel build times
by Josh Boyer 16 Jan '09

16 Jan '09

So I poked around at why ppc builds seem so slow. Net result: I still have no idea. On a quad-970 machine with 2GiB of DRAM running the latest F-9, I did a 'make ppc64' build of the devel kernel with a modified kernel.spec file that spit out some basic timestamps on the RPM sections. Results: Total time: real 65m58.701s user 89m53.501s sys 11m4.737s Each section: Prep: 52 seconds Build: ~33 minutes Install: 38 seconds [jwboyer@yoda devel]$ grep -e Prep -e Build -e Install .build-2.6.29-0.39.rc1.git5.fc11.log | grep -v + Building target platforms: ppc64 Building for target ppc64 Prep Start: Thu Jan 15 15:48:16 EST 2009 Prep End: Thu Jan 15 15:49:08 EST 2009 Build Start: Thu Jan 15 15:49:08 EST 2009 Build End: Thu Jan 15 16:22:57 EST 2009 Install Start: Thu Jan 15 16:22:57 EST 2009 Install End: Thu Jan 15 16:23:35 EST 2009 The overall time is slightly faster than the koji builds I've seen by a few minutes. This is somewhat expected, as my box wasn't really doing much else at the time and some of the builders are blades with fewer cores and slower hard drives. Since I had nothing better to do in my sad life, I was watching the top output a bit during one of my builds. I noticed that when rpmbuild got to the part where it was writing out the -debuginfo RPM, it took almost 18 minutes. Why this is, I have no idea. For gits and shiggles, I grabbed the config from the resulting RPM and used it with a 'time make -j4' on Linus' latest git tree: real 28m46.829s user 70m30.520s sys 7m43.533s So the build time seems roughly equivalent. Yay for doing stuff that garners no new insight! josh

1 0

applypatch.sh script
by Kyle McMartin 15 Jan '09

15 Jan '09

I dislike looking at those C=`wc -l ..` if [ -gt ... ] things in the spec-file... How about something like this? ? prep2.log Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.1218 diff -u -p -r1.1218 kernel.spec --- kernel.spec 15 Jan 2009 07:41:04 -0000 1.1218 +++ kernel.spec 15 Jan 2009 08:16:29 -0000 @@ -862,19 +862,12 @@ exit 1 %endif %endif -patch_command='patch -p1 -F1 -s' ApplyPatch() { local patch=$1 shift - if [ ! -f $RPM_SOURCE_DIR/$patch ]; then - exit 1; - fi - case "$patch" in - *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; - *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; - *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;; - esac + + $RPM_SOURCE_DIR/scripts/applypatch.sh "$RPM_SOURCE_DIR/$patch" ${1+"$@"} } # First we unpack the kernel tarball. @@ -998,18 +991,12 @@ ApplyPatch linux-2.6-makefile-after_link # # misc small stuff to make things compile # -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-compile-fixes.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-compile-fixes.patch -fi %if !%{nopatches} # revert patches from upstream that conflict or that we get via other means -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-upstream-reverts.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-upstream-reverts.patch -R -fi #ApplyPatch git-cpufreq.patch @@ -1151,10 +1138,7 @@ ApplyPatch linux-2.6-net-tulip-interrupt # linux1394 git patches #ApplyPatch linux-2.6-firewire-git-update.patch -C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-firewire-git-pending.patch | awk '{print $1}') -if [ "$C" -gt 10 ]; then ApplyPatch linux-2.6-firewire-git-pending.patch -fi # silence the ACPI blacklist code ApplyPatch linux-2.6-silence-acpi-blacklist.patch Index: scripts/applypatch.sh =================================================================== RCS file: scripts/applypatch.sh diff -N scripts/applypatch.sh --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ scripts/applypatch.sh 15 Jan 2009 08:16:29 -0000 @@ -0,0 +1,28 @@ +#!/bin/bash + +patch=$1 +shift + +# echo "<< applying $patch " + +if [ ! -f $patch ]; then + echo "applypatch: $patch was missing!"; + exit 1; +fi + +# ignore empty patches, culls the ugly wc -l checks we had +# around applypatch formerly... +if [[ `diffstat $patch | grep " 0 files changed"` ]]; then + echo "applypatch: $patch is empty"; + exit 0; +fi + +patchcmd='patch -p1 -F1 -s' + +case "$patch" in + *.bz2) bunzip2 < "$patch" | $patchcmd ${1+"$@"} ;; + *.gz) gunzip < "$patch" | $patchcmd ${1+"$@"} ;; + *) $patchcmd ${1+"$@"} < "$patch" ;; +esac + +# echo ">> "

2 1

[PATCH] build in microcode driver on x86
by Bill Nottingham 14 Jan '09

14 Jan '09

It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. Bill

4 8

Change set acpi_enforce_resources default to strict ?
by Hans de Goede 13 Jan '09

13 Jan '09

Hi Dave, The ACPI subsystem has a kernelcmdline setting called acpi_enforce_resources which defaults to lax, I would like to propose to change this the default to strict in *rawhide*. As you may (not) know I'm an active contributor to the lm_sensors project both to the userspace tools as to the kernel part (I've written and maintained numerous hwmon drivers, and yes feel free to assign any hwmon Fedora kernel bugs to me like you're doing with webcams :) Anyways back to changing the acpi_enforce_resources default, this change effects only the following 3 functions: acpi_check_resource_conflict() acpi_check_region() acpi_check_mem_region() These 3 methods only get used by smbus controller drivers and superio hwmon drivers. Actually they were added on our (lm_sensors project) request. The problem these functions try to fix is that sometimes the ACPI (byte)code touches hwmon IC's for doing things like thermalmanagement while we are banging the same IO's from native drivers. This is not good! So know all hwmon drivers which do direct IO (i2c drivers go through the smbus controller) call these functions to check if the ACPI tables claim the IO resources the smbus controller or superio hwmon driver touches. The idea here is that if ACPI claims the IO, the driver refuses to load. However this could be seen as a regression by users, as they were able to read their sensors using the native hwmon drivers before and now no longer will. Not loading however ofcourse is the safe and thus sane thing to do. As not loading could be seen as a regression the acpi_enforce_resources default is lax, which only causes a warning when ACPI claims the same resources as the driver is using, changing this to strict will outright make the driver not load. We would like to probe the water with how hard this change will make people scream, hence I would like to make this change in rawhide (and yes you may redirect all blame to me). So are you ok with giving this a try? Regards, Hans

1 0

turn SND_HDA_POWER_SAVE_DEFAULT back on?
by Eric Sandeen 12 Jan '09

12 Jan '09

Can we turn the sound powersave options back on in rawhide? Based on http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm… http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm… (thanks to Thorsten Leemhuis for those pointers) it's no longer "experimental...." Thanks, -Eric

3 4

2.6.29 rc1 crashlog
by Robert M. Albrecht 12 Jan '09

12 Jan '09

Hi, I updated the kernel and this crash is new. The systems boots, but it takes several minutes. Also the systems overall is very slow. This is running on an Asus EEE PC901 with Fedora 10 (not Rawhide). cu romal Jan 12 18:57:19 durin kernel: Linux version 2.6.29-0.28.rc1.fc11.i686 (mockbuild(a)x86-2.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Sun Jan 11 21:09:22 EST 2009 Jan 12 18:57:19 durin kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 Jan 12 18:57:19 durin kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter Jan 12 18:57:19 durin kernel: ODEBUG: object is on stack, but not annotated Jan 12 18:57:19 durin kernel: ------------[ cut here ]------------ Jan 12 18:57:19 durin kernel: WARNING: at lib/debugobjects.c:253 __debug_object_init+0x25c/0x2f1() Jan 12 18:57:19 durin kernel: Hardware name: 901 Jan 12 18:57:19 durin kernel: Modules linked in: Jan 12 18:57:19 durin kernel: Pid: 1, comm: swapper Not tainted 2.6.29-0.28.rc1.fc11.i686 #1 Jan 12 18:57:19 durin kernel: Call Trace: Jan 12 18:57:19 durin kernel: [<c0430225>] warn_slowpath+0x71/0xa8 Jan 12 18:57:19 durin kernel: [<c0430700>] ? release_console_sem+0x5/0x1e0 Jan 12 18:57:19 durin kernel: [<c044e03f>] ? trace_hardirqs_off_caller+0x18/0xa3 Jan 12 18:57:19 durin kernel: [<c044e03f>] ? trace_hardirqs_off_caller+0x18/0xa3 Jan 12 18:57:19 durin kernel: [<c044e0d5>] ? trace_hardirqs_off+0xb/0xd Jan 12 18:57:19 durin kernel: [<c06e2bfd>] ? _spin_unlock_irqrestore+0x39/0x50 Jan 12 18:57:19 durin kernel: [<c04308ae>] ? release_console_sem+0x1b3/0x1e0 Jan 12 18:57:19 durin kernel: [<c0407fa3>] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [<c044d76b>] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [<c0541cc5>] ? __debug_object_init+0x164/0x2f1 Jan 12 18:57:19 durin kernel: [<c0541dbd>] __debug_object_init+0x25c/0x2f1 Jan 12 18:57:19 durin kernel: [<c0541e7d>] debug_object_init+0x13/0x16 Jan 12 18:57:19 durin kernel: [<c04388a7>] init_timer+0x11/0x47 Jan 12 18:57:19 durin kernel: [<c0419e18>] hpet_cpuhp_notify+0x78/0xca Jan 12 18:57:19 durin kernel: [<c0419f1b>] ? hpet_work+0x0/0x1b9 Jan 12 18:57:19 durin kernel: [<c044007b>] ? parse_args+0x69/0x1d2 Jan 12 18:57:19 durin kernel: [<c05a7e94>] ? hpet_alloc+0x337/0x37f Jan 12 18:57:19 durin kernel: [<c08c6ba8>] hpet_late_init+0x14a/0x181 Jan 12 18:57:19 durin kernel: [<c08c6a5e>] ? hpet_late_init+0x0/0x181 Jan 12 18:57:19 durin kernel: [<c040114d>] _stext+0x65/0x17a Jan 12 18:57:19 durin kernel: [<c053c3b2>] ? put_dec+0x2a/0xff Jan 12 18:57:19 durin kernel: [<c044db8d>] ? register_lock_class+0x17/0x290 Jan 12 18:57:19 durin kernel: [<c044db8d>] ? register_lock_class+0x17/0x290 Jan 12 18:57:19 durin kernel: [<c044e90d>] ? mark_lock+0x1e/0x349 Jan 12 18:57:19 durin kernel: [<c0407fa3>] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [<c044d76b>] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [<c049f321>] ? check_valid_pointer+0x1f/0x4e Jan 12 18:57:19 durin kernel: [<c044e90d>] ? mark_lock+0x1e/0x349 Jan 12 18:57:19 durin kernel: [<c044ee87>] ? trace_hardirqs_on+0xb/0xd Jan 12 18:57:19 durin kernel: [<c0407fa3>] ? sched_clock+0x8/0xb Jan 12 18:57:19 durin kernel: [<c044d76b>] ? lock_release_holdtime+0x30/0x131 Jan 12 18:57:19 durin kernel: [<c04de76f>] ? proc_register+0x146/0x157 Jan 12 18:57:19 durin kernel: [<c0541024>] ? _raw_spin_unlock+0x74/0x78 Jan 12 18:57:19 durin kernel: [<c06e2c31>] ? _spin_unlock+0x1d/0x20 Jan 12 18:57:19 durin kernel: [<c04de76f>] ? proc_register+0x146/0x157 Jan 12 18:57:19 durin kernel: [<c04de898>] ? create_proc_entry+0x7b/0x91 Jan 12 18:57:19 durin kernel: [<c04719cd>] ? register_irq_proc+0x7f/0x9b Jan 12 18:57:19 durin kernel: [<c0471a3c>] ? init_irq_proc+0x53/0x60 Jan 12 18:57:19 durin kernel: [<c08b3382>] kernel_init+0x17e/0x1cf Jan 12 18:57:19 durin kernel: [<c08b3204>] ? kernel_init+0x0/0x1cf Jan 12 18:57:19 durin kernel: [<c040443f>] kernel_thread_helper+0x7/0x10 Jan 12 18:57:19 durin kernel: ---[ end trace 4eaa2a86a8e2da22 ]--- Jan 12 18:57:19 durin kernel: pnp: PnP ACPI init Jan 12 18:57:19 durin kernel: ACPI: bus type pnp registered Jan 12 18:57:19 durin kernel: pnp: PnP ACPI: found 13 devices

1 0

Custom Kernel USB Boot Problem
by Ahmad Al-Yaman 10 Jan '09

10 Jan '09

Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: Unable to access resume device (UUID=<UUID>) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? Thank you.

3 3

Re: A really "big" kernel (in a dead weight)
by Kyle McMartin 08 Jan '09

08 Jan '09

On Wed, Jan 07, 2009 at 11:20:20PM -0700, Michal Jaegermann wrote: > I tried to install kernel-2.6.29-0.12.rc0.git7.fc11.x86_64. Its rpm > package is quite reasonable 24M in size. Only rpm started to complain > about insufficient space on /. A check with 'rpm -qip ...' revealed > that the package claims to expand to 1035938542 bytes. Around 1 gig! > > Unpacking this in some other place revealed that indeed > lib/modules/2.6.29-0.12.rc0.git7.fc11.x86_64/ eats 997M of disk. > Only this is heavily padded with null bytes. With > 'cp -a --sparse=always ...' aplied to that tree a target drops > in size to 76M. More than a thirteenfold reduction. > > It is true that the same operation performed on > lib/modules/2.6.29-0.9.rc0.git4.fc11.x86_64 reduces that from 188M > to 78M, which is still quite a lot, but what 2.6.29-0.12.rc0.git7.fc11 > is doing seems to be somewhat excessive. Is this is a side effect > of some changes in a build process? Something seems to be a tad > pushy. > > That "module fattening" surely adds a lot of extra time to kernel > installation scripts but other than that a kernel for which modules > were made sparse boots as any other one. The latest updates caused > other serious and so far mysterious breakage, and in particular > haldaemon does not run for me anymore, but that does look like a > kernel dependent. > Hitting up fedora-kernel-list would be helpful. ;-) Any idea which revision this was introduced in? If not, I'll start poking koji. cheers, Kyle

1 0

Re: Enabling drivers in staging tree in rawhide
by Thorsten Leemhuis 08 Jan '09

08 Jan '09

CCing fedora-kernel On 08.01.2009 03:49, Rahul Sundaram wrote: > Quite a bit of new drivers in > http://lwn.net/Articles/313730/ Related: I raised the staging problem already in https://bugzilla.redhat.com/show_bug.cgi?id=477927 as rawhide contained the at76 driver as separate patch http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?… -- but the same driver (with two small changes) also was part of the upstream kernel since October/2.6.28-rc as one of the staging drivers: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… (for more details see bug). That sounds wrong to me, as - it's duplicated work - the at76 staging driver from upstream taints the kernel; the driver from our patch doesn't. > The ralink wireless drivers for example would hopefully make the newer > EEE PC model would out of the box. Does it make sense to enable the > drivers in staging tree by default and bring more exposure to them > atleast via rawhide if not in general releases? +1 to the "I think providing hardware support in rawhide and then removing it before release would be somewhat user-hostile." comment from mjg59. IOW: Either enable or disable them. I'm unsure myself what to do but I tend to say that disabling the whole staging drivers might be the best for Fedora (Greg calls himself as "maintainer of crap" for a good reason). @Davej, Cebbert and Kylem: What's your position on this? If they are disabled completely in Fedora then I'll nevertheless consider to create a "kmod-staging" package for RPM Fusion. CU knurd

5 5

/proc/sys/fs/epoll/max_user_instances=128 considered harmful
by Joe Orton 08 Jan '09

08 Jan '09

The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by default. Apache httpd uses one epoll fd ("instance") per child process, so this sets a hard limit on 128 children (i.e. 100 concurrent clients) out of the box. 1) shouldn't this be an rlimit so that we can bump it appropriately in the parent as root? 2) can we get it tweaked in the default sysctl.conf to be something more sane, e.g. 1024? Regards, Joe

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2009