Re: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
by Bron Gondwana
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.
14 years, 8 months
F10 EDAC Errors on intel based server
by Ted Sume Nzuonkwelle
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
14 years, 8 months
Switching Fedora to pae kernel by default?
by Avi Kivity
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
14 years, 8 months
PPC kernel build times
by Josh Boyer
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
14 years, 8 months
applypatch.sh script
by Kyle McMartin
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 ">> "
14 years, 8 months
Change set acpi_enforce_resources default to strict ?
by Hans de Goede
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
14 years, 8 months
2.6.29 rc1 crashlog
by Robert M. Albrecht
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
14 years, 8 months
Custom Kernel USB Boot Problem
by Ahmad Al-Yaman
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.
14 years, 8 months
