Kay Sievers wrote:
On Wed, 2006-08-02 at 22:04 -0700, Piet Delaney wrote:
On Wed, 2006-08-02 at 10:57 +0200, Kay Sievers wrote:
On Tue, 2006-08-01 at 00:16 -0700, Piet Delaney wrote:
We were wondering why there is a 60 second delay on our systems
from the time that the kernel releases memory and the file system
is checked.
I dropped into kgdb during this period and found that an init
script, S10udev in our case, was sleeping in sys_nanosleep()
or sys_wait4(). Looks like thread/process S10udev forks udevstart
which forks udev which appears to be sleeping or waiting every time
I check in on it; Seems terribly wasteful.
udev seems to be a utility for hotplug and configured
with /etc/udev/udev.conf. Since we have no hot plug devices
I wonder if it really has to be called on every startup. On
solaris the device nodes are only re-established if you boot
with a -r option.
I never see any children of udev, so I wonder why it's
calling wait4() and nanosleep() so often.
You may check with your distro, that sounds like a broken setup. And
please ask further questions on: [EMAIL PROTECTED]
Yep, look like LFS linux-hotplug Developers Lists might be a good idea.
Looks like we must be using a LFS version prior to 6.1.1, as
we are using udev 030. I tried the latest 096 and installed it
in /usr/local. Was getting a bit tied on upgrading the config
and rule files to the new "==" convention for KERNEL and just installed
030 in /usr/local so I could use the existing config and rules for now.
Booted fine with new udev utils from src with debug going
to /var/log/messages. As expected I saw a lot of nanosleeps,
a few for what appeared to be more than 10 iterations of 10 msec.
Since succeeding cases seemed to pass within 2 or 3 iterations of
10 msec I tried decreasing the loops (for us) to 5 iterations of 5
msec. So far I don't see a problem or a substantial improvement;
at least not with the tracing enabled.
We are using the 2.6.12 thru 2.6.15 kernels and are based on the stable
linux from scratch (LFS) pre 6.1.1 distro; I think it's 6.1; we
shouldn't be running on such an old distro (support gets hard).
http://www.linuxfromscratch.org/
in the future I guess we will migrate to the development LFS distro
which is currently useing udev-096 and linux 2.6.16.27.
Tonight I tried udev 096 to /usr/local/ and installed the
LFS udev-config-6.2.tar rules.
Syslog is showing some confusion with an exising daemon running:
----------------------------------------------------------------
Aug 2 20:38:53 localhost udevsend[1794]: starting udevd daemon
Aug 2 20:38:53 localhost udevd[1796]: udev_config_init:
UDEV_CONFIG_FILE='/usr/local/etc/udev/udev.conf'
Aug 2 20:38:53 localhost udevd[1796]: udev_config_init:
udev_root='/dev'
Aug 2 20:38:53 localhost udevd[1796]: udev_config_init:
udev_rules='/usr/local/etc/udev/rules.d'
Aug 2 20:38:53 localhost udevd[1796]: udev_config_init: udev_log=7
Aug 2 20:38:53 localhost udevd[1796]: main: version 096
Aug 2 20:38:53 localhost udevd[1796]: init_udevd_socket: bind failed:
Address already in use
Ugh, disable /proc/sys/kernel/hotplug and get rid of udevsend? All that
old stuff can't, and never worked reliably and should be disabled.
Kay
Next time, with any LFS problems, please ask the guy to upgrade to the
latest kernel, bootscripts, udev, and udev configuration in the
development LFS book, and ensure that old bootscripts and udev
configuration are erased completely. Partial upgrades and leftover junk
are not supported.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
