[udev/vcs] tons of creating/removing /dev/vcs* during boot

[udev/vcs] tons of creating/removing /dev/vcs* during boot

[Edgar Toernig]

Hi,

switching from SuSE's 2.6.11.4 to vanilla 2.6.13 I noticed
that I get tons of these lines in the log during boot:

udev[2124]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
udev[2121]: creating device node '/dev/vcs5'
udev[2124]: creating device node '/dev/vcsa3'
udev[2140]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
udev[2144]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
udev[2140]: creating device node '/dev/vcs3'
udev[2144]: creating device node '/dev/vcsa6'
udev[2147]: removing device node '/dev/vcs6'
udev[2149]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
udev[2158]: removing device node '/dev/vcs4'
udev[2157]: removing device node '/dev/vcsa3'
udev[2149]: creating device node '/dev/vcsa5'
udev[2172]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ....
udev[2171]: removing device node '/dev/vcsa2'
udev[2172]: creating device node '/dev/vcs5'

It's caused by various loadkeys, setleds, etc performed early in an
init script.  It seems, that every open/close of a tty generates
a hotplug event for the appropriate vcs/vcsa device.  It stops at
the moment gettys are spawned.

Looking at the 2.6.11.4 source of drivers/char/vc_screen.c I see
that hotplug events are explicitly disabled for the vcs and vcsa
devices (not sure whether this was done by SuSE).  In 2.6.13 all
of that code is gone, including the class_simple that was used to
disable hotplug events.

How can I avoid all of these hotplug events?  Best would be of
course to generate only a single event at the same time the
tty device is create.  But I could also live with no hotplug
events for vcs* at all.

Ciao, ET.

Re: [udev/vcs] tons of creating/removing /dev/vcs* during boot

[Greg KH]

On Mon, Sep 12, 2005 at 05:06:18PM +0200, Edgar Toernig wrote:
> Hi,
> 
> switching from SuSE's 2.6.11.4 to vanilla 2.6.13 I noticed
> that I get tons of these lines in the log during boot:
> 
> udev[2124]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2121]: creating device node '/dev/vcs5'
> udev[2124]: creating device node '/dev/vcsa3'
> udev[2140]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2144]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2140]: creating device node '/dev/vcs3'
> udev[2144]: creating device node '/dev/vcsa6'
> udev[2147]: removing device node '/dev/vcs6'
> udev[2149]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2158]: removing device node '/dev/vcs4'
> udev[2157]: removing device node '/dev/vcsa3'
> udev[2149]: creating device node '/dev/vcsa5'
> udev[2172]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ....
> udev[2171]: removing device node '/dev/vcsa2'
> udev[2172]: creating device node '/dev/vcs5'
> 
> It's caused by various loadkeys, setleds, etc performed early in an
> init script.  It seems, that every open/close of a tty generates
> a hotplug event for the appropriate vcs/vcsa device.  It stops at
> the moment gettys are spawned.
> 
> Looking at the 2.6.11.4 source of drivers/char/vc_screen.c I see
> that hotplug events are explicitly disabled for the vcs and vcsa
> devices (not sure whether this was done by SuSE).

Yes, this was a SUSE change, that's never been in mainline.

> In 2.6.13 all of that code is gone, including the class_simple that
> was used to disable hotplug events.

Well, consider it "never present" instead of gone :)

> How can I avoid all of these hotplug events?

Why do you want to?  You need them in order to create the proper device
node for the virtual terminal, right?

And, if you use the latest versions of udev, no hotplug events need
cause a program execute, udev can watch the hotplug netlink socket and
just act on it, _very_ quickly.  So quickly you will not even care I
bet...

> Best would be of course to generate only a single event at the same
> time the tty device is create.

That's what you are seeing.  And then watching as it's being destroyed.
And then created.  And then destroyed.  And so on (virtual ttys are
nasty at times..)

> But I could also live with no hotplug events for vcs* at all.

You would not be able to use them if you use udev then :(

Seriously, try the latest udev, with the netlink socket, and see if it
still matters anymore.

thanks,

greg k-h

Re: [udev/vcs] tons of creating/removing /dev/vcs* during boot

[Andreas Jellinghaus]

Greg KH wrote:
>> Best would be of course to generate only a single event at the same
>> time the tty device is create.
> 
> That's what you are seeing.  And then watching as it's being destroyed.
> And then created.  And then destroyed.  And so on (virtual ttys are
> nasty at times..)

wait a second, the kernel code opens /dev/console before running
init. so that should trigger that first hotplug event. and if
init is a process that does not close stdin/out/err, there should
not be any additional hotplug event, right?

I know for sure that some gentoo machine created > 3000 hotplug
events during bootup. I'm note sure if the init closed stdin/out/err,
and that installation was replaced by debian anyway, but it sure
killed the machine, if I hadn't disabled hotplugging (3000 bash
processes need more ram than a normal machine has).

init strarts processes and those sure have stdin/out/err open,
so they can write to the console. so I somehow doubt it closes
and opens those all the time, but I haven't checked the code.
so I wonder: is or was there any bug in the kernel where hundreds
or thousands of hotplug requests are created, simply because
processed are executed? 

it is a fact I saw thousands of hotplug events during a boot sequence.
I'd like to know why that happened, and whether it would happen again.
rm -rf /sbin/hotplug and switching to udevd is once option to solve
the problem, but not an explanation why it happened in the first place.

Regards, Andreas
p.a. I don't use udevd, but my initramfs disables hotplug and
the last initscript enables it again. also works ok.