On Thu, 2006-08-03 at 21:51 +0600, Alexander E. Patrakov wrote:
> 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.
How about avoid releasing:
* old stuff
* leftover junk
* stuff that doesn't work
also more documentation on the internals of udev and the kernel
would be nice. Lots of stuff on how to use it but when shit happens
it's really helpful to know what it's doing inside the components.
The junk and left over crap just makes it more difficult to sort out
problems.
It's sometimes the case when merging a lot of TCP changes, as in my
case, convenient to run on a range of kernels to compare behavior.
Our upgrading to LFS 6.2 is still a ways out, but testing with newer
kernels is a necessity.
Supporting leftover junk seems like something that shouldn't even be
an issue.
-piet
>
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; [EMAIL PROTECTED]
H: (408) 243-8872; [EMAIL PROTECTED]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
