IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Netlink events get lost when the kernel creates thousends of events
faster than udevd reads it. The default is 128 KB, which can carry
app. 500 events. Set it to 16 MB now.
I have 4000 fibrechannel LUNs connected to my system. There are two
paths to the devices and two ports on the host connected via a switch.
This gives 16000 when probed.
I have had problems getting all of the entries in /dev created.
-- Mark Haverkamp <markh@osdl.org>
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
UDEVD_EVENT_TIMEOUT=0 didn't work directly after udevd startup.
The whole event timeout handling is not needed since we use netlink.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Moving events directly to the exec queue instead of the reordering
incoming queue, leaves holes in the sequence, that lead to timeouts for
all other events. Remove that part of the special handling.
(With netlink, events can't get out-of-order and the maximum timeout is 5
seconds and should not cause any trouble with the 10 sec timout for the
firmware class anyway. Events with timeouts are still prioritized for
execution, but don't bypass the incoming queue anymore.)
Many thanks to:
Uberto Barbini <uberto@ubiland.net>
for his endless debugging and sending all the traces, that showed this
failure with his DVB device:
UEVENT[1124474094] add@/module/stv0299
UEVENT[1124474094] add@/module/ves1x93
UEVENT[1124474094] add@/module/ttpci_eeprom
UEVENT[1124474094] add@/module/saa7146
UEVENT[1124474094] add@/module/video_buf
UEVENT[1124474094] add@/module/saa7146_vv
UEVENT[1124474094] add@/module/dvb_core
UEVENT[1124474094] add@/module/dvb_ttpci
UEVENT[1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] add@/class/firmware/0000:00:14.0
UDEV [1124474094] add@/module/dvb_core
UDEV [1124474094] add@/module/saa7146_vv
UDEV [1124474094] add@/module/dvb_ttpci
UDEV [1124474094] add@/module/ves1x93
UDEV [1124474094] add@/module/ttpci_eeprom
UDEV [1124474094] add@/module/saa7146
UDEV [1124474094] add@/module/stv0299
UDEV [1124474094] add@/module/video_buf
UDEV [1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] remove@/class/firmware/0000:00:14.0 <- event with TIMEOUT will leave a hole in the incoming
UDEV [1124474094] add@/class/firmware/0000:00:14.0 sequence, which will cause a wait for the alarm()
UEVENT[1124474094] add@/class/i2c-adapter/i2c-1 that flushes the queue
UEVENT[1124474094] add@/class/i2c-dev/i2c-1
UDEV [1124474094] remove@/class/firmware/0000:00:14.0 <- event also has TIMEOUT and is executed immediately
UEVENT[1124474095] add@/class/dvb/dvb0.demux0
UEVENT[1124474095] add@/class/dvb/dvb0.dvr0
UEVENT[1124474095] add@/class/dvb/dvb0.video0
UEVENT[1124474095] add@/class/dvb/dvb0.audio0
UEVENT[1124474095] add@/class/dvb/dvb0.ca0
UEVENT[1124474095] add@/class/dvb/dvb0.osd0
UEVENT[1124474095] add@/class/dvb/dvb0.net0
UEVENT[1124474095] add@/class/video4linux/video1
UEVENT[1124474095] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/i2c-adapter/i2c-1 <- all others have 5 seconds delay cause of the missing event
UDEV [1124474099] add@/class/dvb/dvb0.ca0 missing events
UDEV [1124474099] add@/class/dvb/dvb0.osd0
UDEV [1124474099] add@/class/video4linux/video1
UDEV [1124474099] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/dvb/dvb0.video0
UDEV [1124474099] add@/class/dvb/dvb0.audio0
UDEV [1124474099] add@/class/i2c-dev/i2c-1
UDEV [1124474099] add@/class/dvb/dv
My test program that simulates a similar sequence, runs without any delay
now. (With one of the next versions we will make netlink mandatory, then
we can remove the whole input queue crap with the reordering anyway.)
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
If the kernel forks us as an usermodhelper, we don't have any of
the standard fd's and the first open() will start with fd=0.
This is inherited to all forked childs and confuses later forked
helpers where we want to read from a pipe connected to the helpers
stdout/stderr.
# ls -l /proc/$(pidof udevd)/fd
total 6
dr-x------ 2 root root 0 2005-08-18 12:44 .
dr-xr-xr-x 4 root root 0 2005-08-18 12:44 ..
lrwx------ 1 root root 64 2005-08-18 12:44 0 -> /dev/null
lrwx------ 1 root root 64 2005-08-18 12:44 1 -> socket:[1274617]
lr-x------ 1 root root 64 2005-08-18 12:44 2 -> pipe:[1274618]
l-wx------ 1 root root 64 2005-08-18 12:44 3 -> pipe:[1274618]
lrwx------ 1 root root 64 2005-08-18 12:44 4 -> socket:[1274619]
lrwx------ 1 root root 64 2005-08-18 12:44 5 -> socket:[1274620]
Ouch! This will obviously not redirect sterr, it will kill the pipe
we established between the parent and the child:
devnull = open("/dev/null", O_RDWR);
dup2(devnull, STDERR_FILENO);
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Export the type of device from ata_id and scsi_id, also strip
leading and trailing whitespace and substitute consecutive
whitespace with a single underline char.
From: Hannes Reinecke <hare@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Controls the behavior of the running daemon. Currently only stopping and starting
of the execution queue is supported.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
After the first valid netlink-event all event with a serial number
received on the udevsend socket will be ignored.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
SUBSYSTEM=="block", RUN="/sbin/program"
will execute the program only for block device events.
ACTION="remove", SUBSYSTEM=="block", RUN"/sbin/program"
will execute the program, if a block device is removed.
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> The current implementation of the firmware class breaks a fundamental
> assumption in udevd: that the physical device can be initialised fully
> prior to executing the next event for that device.
Thanks to Hannes for the patch.
If the system reaches a defined limit of processes in running state, udevd
starts to count its own processes in running state from its session (all
forked hotplug child processes, subprocesses and callouts) and throttles
further process forking if the limit is reached.
This should help setups with hundreds of events emitted hotplug events
in parallel with hundreds of processes in "R" state. which makes the machine
unresponsible.
I placed a 100% cpu time consuming program in /etc/hotplug.d/ which runs for 5
seconds. With this patch I can load "scsi_debug add_host=100" without any major
problem. Without the patch the box is completly unresponsible for many minutes.
We delay the execution of events if there is already an event running for
the same device, a parent or a child device. "add" events with a reference
to a physical device will also wait for the physical device to finish.
Here we fix the devpath comparison logic to return "busy" only if a complete
device names is matching. /block/sdaa will not longer block a /block/sda event.
Define an inititialization phase, where we delay the events only
for a short time to eventually recollect the event sequence instead
of delaying the very first events for 10 seconds, which breaks the
firmware loader.
If we take over the hotplug call and manage the events we don't need
to call the event fake script in dev.d/. Just set all expected values
to the new network interface name and call hotplug.d/. This way the
device renaming is completely handled inside of udev and userspace
can't get confused.
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
