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
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!
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 188.8.131.52-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?
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
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:
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:
So the build time seems roughly equivalent. Yay for doing stuff that
garners no new insight!
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:
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?
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?