kernel January 2009

kernel@lists.fedoraproject.org

41 participants
23 discussions

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 13 Jan '09

13 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2009