* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
@ 2004-03-26 17:39 ` Kay Sievers
2004-03-26 20:05 ` Treeve Jelbert
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Kay Sievers @ 2004-03-26 17:39 UTC (permalink / raw)
To: linux-hotplug
On Fri, Mar 26, 2004 at 06:08:55PM +0100, Oliver Paschke wrote:
> Hi,
>
> I have a problem with my current udev/hotplug configuration (023/2004_03_11) since i rebuilt my system (lfs-5.1_pre1, glibc-3.3 against 2.4.25 headers). Udev worked perfectly before (lfs-3.1).
>
> When I assign /sbin/udev as hotplugging-agent device-adding/-removal works the way it should, but when /proc/sys/kernel/hotplug points to /sbin/hotplug udev queues the events while hotplugging still works fine. Compiling udev with or without klibc doesn't make a difference.
All events are queued by udevd. /sbin/hotplug calls udevsend to
send a message to udevd, which calls the real udev after a possibly
reordering of the sequence numbers.
What says your syslog after doing this as root. I've pasted in, what I
get with a working setup. You can follow the udevsend->udevd->udev->udevd call:
manual send without sequence number:
ACTIONd DEVPATH=/test /sbin/udevsend test
Mar 26 18:31:21 pim udevsend[2619]: main: daemon started
Mar 26 18:31:21 pim udevd[2621]: udev_run: => exec seq -1 [2622] working at '/test'
Mar 26 18:31:21 pim udevd[2621]: exec_queue_manager: moved seq -1 to running list
Mar 26 18:31:21 pim udev[2622]: get_dirs: sysfs_path='/sys'
Mar 26 18:31:21 pim udev[2622]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Mar 26 18:31:21 pim udev[2622]: main: version 023
Mar 26 18:31:21 pim udev[2622]: udev_hotplug: looking at '/test'
Mar 26 18:31:21 pim udev[2622]: udev_hotplug: not a block or class device
Mar 26 18:31:21 pim udevd[2621]: udev_done: <= exec seq -1 came back
manual send with sequence number:
SEQNUM\x1000000 ACTIONd DEVPATH=/test /sbin/udevsend test
Mar 26 18:34:03 pim udevsend[2623]: main: version 023
Mar 26 18:34:03 pim udevsend[2623]: main: subsystem = 'test'
Mar 26 18:34:03 pim udevsend[2623]: main: DEVPATH = '/test'
Mar 26 18:34:03 pim udevsend[2623]: main: ACTION = 'add'
Mar 26 18:34:03 pim udevsend[2623]: main: SEQNUM = '1000000'
Mar 26 18:34:03 pim udevd[2621]: msg_queue_insert: queued message seq 1000000
Mar 26 18:34:03 pim udevd[2621]: msg_queue_manager: msg queue manager, next expected is 0
Mar 26 18:34:03 pim udevd[2621]: msg_dump_queue: sequence 1000000 in queue
Mar 26 18:34:03 pim udevd[2621]: msg_queue_manager: next event expires in 5 seconds
Mar 26 18:34:08 pim udevd[2621]: msg_queue_manager: msg queue manager, next expected is 0
Mar 26 18:34:08 pim udev[2624]: get_dirs: sysfs_path='/sys'
Mar 26 18:34:08 pim udev[2624]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Mar 26 18:34:08 pim udev[2624]: main: version 023
Mar 26 18:34:08 pim udev[2624]: udev_hotplug: looking at '/test'
Mar 26 18:34:08 pim udevd[2621]: udev_run: => exec seq 1000000 [2624] working at '/test'
Mar 26 18:34:08 pim udevd[2621]: exec_queue_manager: moved seq 1000000 to running list
Mar 26 18:34:08 pim udevd[2621]: msg_move_exec: moved seq 1000000 to exec, next expected is 1000001
Mar 26 18:34:08 pim udev[2624]: udev_hotplug: not a block or class device
Mar 26 18:34:08 pim udevd[2621]: udev_done: <= exec seq 1000000 came back
> Any help would be appreciated,
> thanks
>
>
> Syslog debug-messages of a 'modprobe nvidia' call as example:
> (nvidia module with sysfs patch - alsa behaves the same way..)
>
> /sbin/hotplug:
> Mar 26 16:53:08 pandora udevsend[1429]: main: version 023
> Mar 26 16:53:08 pandora udevsend[1429]: main: subsystem = 'nvidia'
> Mar 26 16:53:08 pandora udevsend[1429]: main: DEVPATH = '/class/nvidia/nvidiactl'
> Mar 26 16:53:08 pandora udevsend[1429]: main: ACTION = 'add'
> Mar 26 16:53:08 pandora udevsend[1429]: main: SEQNUM = '192'
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_insert: queued message seq 192
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: msg queue manager, next expected is 0
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 116 in queue
> ...
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 192 in queue
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: next event expires in 2907 seconds
> Mar 26 16:53:08 pandora udevsend[1435]: main: version 023
> Mar 26 16:53:08 pandora udevsend[1435]: main: subsystem = 'nvidia'
> Mar 26 16:53:08 pandora udevsend[1435]: main: DEVPATH = '/class/nvidia/nvidia0'
> Mar 26 16:53:08 pandora udevsend[1435]: main: ACTION = 'add'
> Mar 26 16:53:08 pandora udevsend[1435]: main: SEQNUM = '193'
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_insert: queued message seq 193
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: msg queue manager, next expected is 0
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 116 in queue
> ...
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 193 in queue
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: next event expires in 2907 seconds
Huh, what's this 2907 seconds? Sounds a bit too much :)
> /sbin/udev:
> Mar 26 16:50:59 pandora udev[1412]: get_dirs: sysfs_path='/sys'
> Mar 26 16:50:59 pandora udev[1412]: parse_config_file: reading '/etc/udev/udev.conf' as config file
> Mar 26 16:50:59 pandora udev[1412]: main: version 023
> Mar 26 16:50:59 pandora udev[1412]: udev_hotplug: looking at '/class/nvidia/nvidiactl'
> ...
> Mar 26 16:50:59 pandora udev[1413]: sleep_for_file: looking for '/sys/class/nvidia/nvidia0/dev'
> Mar 26 16:51:00 pandora udev[1412]: sleep_for_file: looking for '/sys/class/nvidia/nvidiactl/dev'
> Mar 26 16:51:00 pandora udev[1412]: get_class_dev: looking at '/sys/class/nvidia/nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: get_class_dev: class_dev->name='nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: get_major_minor: dev='195:255 '
> Mar 26 16:51:00 pandora udev[1412]: get_major_minor: found major\x195, minor%5
> Mar 26 16:51:00 pandora udev[1413]: sleep_for_file: looking for '/sys/class/nvidia/nvidia0/dev'
> Mar 26 16:51:00 pandora udev[1413]: get_class_dev: looking at '/sys/class/nvidia/nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: get_class_dev: class_dev->name='nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: get_major_minor: dev='195:0 '
> Mar 26 16:51:00 pandora udev[1413]: get_major_minor: found major\x195, minor=0
> Mar 26 16:51:00 pandora udev[1413]: sysfs_path_is_link: stat() failed
> Mar 26 16:51:00 pandora last message repeated 7 times
> Mar 26 16:51:00 pandora udev[1413]: sysfs_open_device_path: Could not get device 0000:01:00.0's driver
> Mar 26 16:51:00 pandora udev[1413]: get_sysfs_device: device 0000:01:00.0 is registered with bus 'pci'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: sysfs_device->path='/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: sysfs_device->bus_id='0000:01:00.0'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: sysfs_device->bus='pci'
> Mar 26 16:51:00 pandora udev[1413]: wait_for_device_to_initialize: looking for file 'vendor' on bus 'pci'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: class_dev->name = 'nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: udev->kernel_name = 'nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: kernel_number='0'
> Mar 26 16:51:00 pandora udev[1413]: namedev_name_device: name, 'nvidia0' is going to have owner='root', group='video', mode = 0660
> Mar 26 16:51:00 pandora udev[1413]: udev_add_device: udevdb_add_dev failed, but we are going to try to create the node anyway. But remove might not work properly for this device.
> Mar 26 16:51:00 pandora udev[1413]: udev_add_device: name='nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: creating device node '/dev/nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: make_node: chmod(/dev/nvidia0, 020660)
> Mar 26 16:51:00 pandora udev[1413]: make_node: chown(/dev/nvidia0, 0, 12)
> ...
> Mar 26 16:51:00 pandora udev[1412]: sysfs_path_is_link: stat() failed
> Mar 26 16:51:00 pandora last message repeated 8 times
> Mar 26 16:51:00 pandora udev[1412]: get_sysfs_device: timed out waiting for device symlink, continuing on anyway...
> Mar 26 16:51:00 pandora udev[1412]: namedev_name_device: class_dev->name = 'nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: namedev_name_device: udev->kernel_name = 'nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: namedev_name_device: kernel_number=''
> Mar 26 16:51:00 pandora udev[1412]: namedev_name_device: name, 'nvidiactl' is going to have owner='root', group='video', mode = 0660
> Mar 26 16:51:00 pandora udev[1412]: udev_add_device: udevdb_add_dev failed, but we are going to try to create the node anyway. But remove might not work properly for this device.
Are you sure, that you have removed to old db after upgrading?
Normally 'make install' should do this.
> Mar 26 16:51:00 pandora udev[1412]: udev_add_device: name='nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: creating device node '/dev/nvidiactl'
> Mar 26 16:51:00 pandora udev[1412]: make_node: chmod(/dev/nvidiactl, 020660)
> Mar 26 16:51:00 pandora udev[1412]: make_node: chown(/dev/nvidiactl, 0, 12)
thanks,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
2004-03-26 17:39 ` Kay Sievers
@ 2004-03-26 20:05 ` Treeve Jelbert
2004-03-26 20:13 ` Oliver Paschke
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Treeve Jelbert @ 2004-03-26 20:05 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 26 March 2004 18:08, Oliver Paschke wrote:
> Hi,
>
> I have a problem with my current udev/hotplug configuration
> (023/2004_03_11) since i rebuilt my system (lfs-5.1_pre1, glibc-3.3 against
> 2.4.25 headers). Udev worked perfectly before (lfs-3.1).
I have a similar problem, devices don't appear in /dev, but after a long (> 30
minutes) delay, they do!
linux-2.6.5-rc2
glibc-3.3 with nptl threading
>
> When I assign /sbin/udev as hotplugging-agent device-adding/-removal works
> the way it should, but when /proc/sys/kernel/hotplug points to
> /sbin/hotplug udev queues the events while hotplugging still works fine.
> Compiling udev with or without klibc doesn't make a difference.
>
> Any help would be appreciated,
> thanks
>
>
> Syslog debug-messages of a 'modprobe nvidia' call as example:
> (nvidia module with sysfs patch - alsa behaves the same way..)
>
> /sbin/hotplug:
> Mar 26 16:53:08 pandora udevsend[1429]: main: version 023
> Mar 26 16:53:08 pandora udevsend[1429]: main: subsystem = 'nvidia'
> Mar 26 16:53:08 pandora udevsend[1429]: main: DEVPATH > '/class/nvidia/nvidiactl' Mar 26 16:53:08 pandora udevsend[1429]: main:
> ACTION = 'add'
> Mar 26 16:53:08 pandora udevsend[1429]: main: SEQNUM = '192'
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_insert: queued message seq
> 192 Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: msg queue
> manager, next expected is 0 Mar 26 16:53:08 pandora udevd[226]:
> msg_dump_queue: sequence 116 in queue ...
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 192 in queue
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: next event expires
> in 2907 seconds Mar 26 16:53:08 pandora udevsend[1435]: main: version 023
> Mar 26 16:53:08 pandora udevsend[1435]: main: subsystem = 'nvidia'
> Mar 26 16:53:08 pandora udevsend[1435]: main: DEVPATH > '/class/nvidia/nvidia0' Mar 26 16:53:08 pandora udevsend[1435]: main:
> ACTION = 'add'
> Mar 26 16:53:08 pandora udevsend[1435]: main: SEQNUM = '193'
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_insert: queued message seq
> 193 Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: msg queue
> manager, next expected is 0 Mar 26 16:53:08 pandora udevd[226]:
> msg_dump_queue: sequence 116 in queue ...
> Mar 26 16:53:08 pandora udevd[226]: msg_dump_queue: sequence 193 in queue
> Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: next event expires
> in 2907 seconds
>
> /sbin/udev:
> Mar 26 16:50:59 pandora udev[1412]: get_dirs: sysfs_path='/sys'
> Mar 26 16:50:59 pandora udev[1412]: parse_config_file: reading
> '/etc/udev/udev.conf' as config file Mar 26 16:50:59 pandora udev[1412]:
> main: version 023
> Mar 26 16:50:59 pandora udev[1412]: udev_hotplug: looking at
> '/class/nvidia/nvidiactl' ...
> Mar 26 16:50:59 pandora udev[1413]: sleep_for_file: looking for
> '/sys/class/nvidia/nvidia0/dev' Mar 26 16:51:00 pandora udev[1412]:
> sleep_for_file: looking for '/sys/class/nvidia/nvidiactl/dev' Mar 26
> 16:51:00 pandora udev[1412]: get_class_dev: looking at
> '/sys/class/nvidia/nvidiactl' Mar 26 16:51:00 pandora udev[1412]:
> get_class_dev: class_dev->name='nvidiactl' Mar 26 16:51:00 pandora
> udev[1412]: get_major_minor: dev='195:255 ' Mar 26 16:51:00 pandora
> udev[1412]: get_major_minor: found major\x195, minor%5 Mar 26 16:51:00
> pandora udev[1413]: sleep_for_file: looking for
> '/sys/class/nvidia/nvidia0/dev' Mar 26 16:51:00 pandora udev[1413]:
> get_class_dev: looking at '/sys/class/nvidia/nvidia0' Mar 26 16:51:00
> pandora udev[1413]: get_class_dev: class_dev->name='nvidia0' Mar 26
> 16:51:00 pandora udev[1413]: get_major_minor: dev='195:0 '
> Mar 26 16:51:00 pandora udev[1413]: get_major_minor: found major\x195,
> minor=0 Mar 26 16:51:00 pandora udev[1413]: sysfs_path_is_link: stat()
> failed Mar 26 16:51:00 pandora last message repeated 7 times
> Mar 26 16:51:00 pandora udev[1413]: sysfs_open_device_path: Could not get
> device 0000:01:00.0's driver Mar 26 16:51:00 pandora udev[1413]:
> get_sysfs_device: device 0000:01:00.0 is registered with bus 'pci' Mar 26
> 16:51:00 pandora udev[1413]: namedev_name_device:
> sysfs_device->path='/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0' Mar
> 26 16:51:00 pandora udev[1413]: namedev_name_device:
> sysfs_device->bus_id='0000:01:00.0' Mar 26 16:51:00 pandora udev[1413]:
> namedev_name_device: sysfs_device->bus='pci' Mar 26 16:51:00 pandora
> udev[1413]: wait_for_device_to_initialize: looking for file 'vendor' on bus
> 'pci' Mar 26 16:51:00 pandora udev[1413]: namedev_name_device:
> class_dev->name = 'nvidia0' Mar 26 16:51:00 pandora udev[1413]:
> namedev_name_device: udev->kernel_name = 'nvidia0' Mar 26 16:51:00 pandora
> udev[1413]: namedev_name_device: kernel_number='0' Mar 26 16:51:00 pandora
> udev[1413]: namedev_name_device: name, 'nvidia0' is going to have
> owner='root', group='video', mode = 0660 Mar 26 16:51:00 pandora
> udev[1413]: udev_add_device: udevdb_add_dev failed, but we are going to try
> to create the node anyway. But remove might not work properly for this
> device. Mar 26 16:51:00 pandora udev[1413]: udev_add_device: name='nvidia0'
> Mar 26 16:51:00 pandora udev[1413]: creating device node '/dev/nvidia0' Mar
> 26 16:51:00 pandora udev[1413]: make_node: chmod(/dev/nvidia0, 020660) Mar
> 26 16:51:00 pandora udev[1413]: make_node: chown(/dev/nvidia0, 0, 12) ...
> Mar 26 16:51:00 pandora udev[1412]: sysfs_path_is_link: stat() failed
> Mar 26 16:51:00 pandora last message repeated 8 times
> Mar 26 16:51:00 pandora udev[1412]: get_sysfs_device: timed out waiting for
> device symlink, continuing on anyway... Mar 26 16:51:00 pandora udev[1412]:
> namedev_name_device: class_dev->name = 'nvidiactl' Mar 26 16:51:00 pandora
> udev[1412]: namedev_name_device: udev->kernel_name = 'nvidiactl' Mar 26
> 16:51:00 pandora udev[1412]: namedev_name_device: kernel_number='' Mar 26
> 16:51:00 pandora udev[1412]: namedev_name_device: name, 'nvidiactl' is
> going to have owner='root', group='video', mode = 0660 Mar 26 16:51:00
> pandora udev[1412]: udev_add_device: udevdb_add_dev failed, but we are
> going to try to create the node anyway. But remove might not work properly
> for this device. Mar 26 16:51:00 pandora udev[1412]: udev_add_device:
> name='nvidiactl' Mar 26 16:51:00 pandora udev[1412]: creating device node
> '/dev/nvidiactl' Mar 26 16:51:00 pandora udev[1412]: make_node:
> chmod(/dev/nvidiactl, 020660) Mar 26 16:51:00 pandora udev[1412]:
> make_node: chown(/dev/nvidiactl, 0, 12) ...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
> _______________________________________________
> Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Regards, Treeve
- --
PGP Key ID: AB929B24
PGP Key Fingerprint:31D9 D22F 42E6 F545 662E AB6F 9697 34C5 AB92 9B24
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAZI0clpc0xauSmyQRAqOQAKDm9Wm5hpe+2g68OtvTIJq0ph0ICACfYRP3
DDuIkSfjCBOuDZK8Dw5WIbg=5W7n
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&opÌk
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
2004-03-26 17:39 ` Kay Sievers
2004-03-26 20:05 ` Treeve Jelbert
@ 2004-03-26 20:13 ` Oliver Paschke
2004-03-26 20:42 ` Oliver Paschke
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Oliver Paschke @ 2004-03-26 20:13 UTC (permalink / raw)
To: linux-hotplug
On Fri, 26 Mar 2004 18:39:58 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> What says your syslog after doing this as root?
These are my results for the manual send calls:
ACTIONd DEVPATH=/test /sbin/udevsend test
Mar 26 20:40:03 pandora udevsend[1233]: main: version 023
Mar 26 20:40:03 pandora udevsend[1233]: main: subsystem = 'test'
Mar 26 20:40:03 pandora udevsend[1233]: main: DEVPATH = '/test'
Mar 26 20:40:03 pandora udevsend[1233]: main: ACTION = 'add'
Mar 26 20:40:03 pandora udevsend[1233]: main: SEQNUM = '-1'
Mar 26 20:40:03 pandora udev[1234]: get_dirs: sysfs_path='/sys'
Mar 26 20:40:03 pandora udev[1234]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Mar 26 20:40:03 pandora udevd[226]: udev_run: => exec seq -1 [1234] working at '/test'
Mar 26 20:40:03 pandora udevd[226]: exec_queue_manager: moved seq -1 to running list
Mar 26 20:40:03 pandora udevd[226]: udev_done: <= exec seq -1 came back
SEQNUM\x1000000 ACTIONd DEVPATH=/test /sbin/udevsend test
Mar 26 20:40:38 pandora udevsend[1243]: main: version 023
Mar 26 20:40:38 pandora udevsend[1243]: main: subsystem = 'test'
Mar 26 20:40:38 pandora udevsend[1243]: main: DEVPATH = '/test'
Mar 26 20:40:38 pandora udevsend[1243]: main: ACTION = 'add'
Mar 26 20:40:38 pandora udevsend[1243]: main: SEQNUM = '1000000'
Mar 26 20:40:38 pandora udevd[226]: msg_queue_insert: queued message seq 1000000
Mar 26 20:40:38 pandora udevd[226]: msg_queue_manager: msg queue manager, next expected is 0
Mar 26 20:40:38 pandora udevd[226]: msg_dump_queue: sequence 116 in queue
[...]
Mar 26 20:40:38 pandora udevd[226]: msg_dump_queue: sequence 153 in queue
Mar 26 20:40:38 pandora udevd[226]: msg_dump_queue: sequence 1000000 in queue
Mar 26 20:40:38 pandora udevd[226]: msg_queue_manager: next event expires in 3199 seconds
Seems like some problem with udevd handeling the sequence numbers..
> > Mar 26 16:53:08 pandora udevd[226]: msg_queue_manager: next event expires in 2907 seconds
> Huh, what's this 2907 seconds? Sounds a bit too much :)
This seems to be the problem with udevd queueing the event forever.
> > Mar 26 16:51:00 pandora udev[1412]: udev_add_device: udevdb_add_dev failed, but we are going to try to create the node anyway. But remove might not work properly for this device.
>
> Are you sure, that you have removed to old db after upgrading?
> Normally 'make install' should do this.
I resolved this issue by increasing the size of my tmpfs mounted /dev. The db grew too big for the 100k size limit.
thanks,
Oli
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
` (2 preceding siblings ...)
2004-03-26 20:13 ` Oliver Paschke
@ 2004-03-26 20:42 ` Oliver Paschke
2004-03-26 21:28 ` Oliver Paschke
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Oliver Paschke @ 2004-03-26 20:42 UTC (permalink / raw)
To: linux-hotplug
On Fri, 26 Mar 2004 21:05:41 +0100
Treeve Jelbert <treeve01@pi.be> wrote:
> I have a similar problem, devices don't appear in /dev, but after a long (> 30
> minutes) delay, they do!
>
> linux-2.6.5-rc2
> glibc-3.3 with nptl threading
Several people seem to have a problem with this.. After several 'killall udevd' and 'modprobe' attempts udev starts to create/remove devicenodes properly on my system.
My configuration is pretty similar:
linux-2.6.4
glibc-3.3 with glibc-linuxthreads
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
` (3 preceding siblings ...)
2004-03-26 20:42 ` Oliver Paschke
@ 2004-03-26 21:28 ` Oliver Paschke
2004-03-26 21:57 ` Kay Sievers
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Oliver Paschke @ 2004-03-26 21:28 UTC (permalink / raw)
To: linux-hotplug
Applied the patch. This is what my syslog reads:
Mar 26 22:14:24 pandora udevsend[1157]: main: version 023
Mar 26 22:14:24 pandora udevsend[1157]: main: subsystem = 'test'
Mar 26 22:14:24 pandora udevsend[1157]: main: DEVPATH = '/test'
Mar 26 22:14:24 pandora udevsend[1157]: main: ACTION = 'add'
Mar 26 22:14:24 pandora udevsend[1157]: main: SEQNUM = '1000000'
Mar 26 22:14:24 pandora udevd[227]: msg_queue_insert: queued message seq 1000000
Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: msg queue manager, next expected is 0
Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: xxx msg age is -3484
Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 116 in queue
[...]
Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 153 in queue
Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 1000000 in queue
Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: next event expires in 3489 seconds
Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: xxx itimer seconds is 3489
Negative message age... ?
Could all this result from a possible bug in my glibc-3.3?
thanks,
Oli
On Fri, 26 Mar 2004 21:48:41 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, Mar 26, 2004 at 09:13:39PM +0100, Oliver Paschke wrote:
> > On Fri, 26 Mar 2004 18:39:58 +0100
> > Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> > > What says your syslog after doing this as root?
> > These are my results for the manual send calls:
> >
> Mar 26 20:40:38 pandora udevd[226]: msg_dump_queue: sequence 153 in queue
> > Mar 26 20:40:38 pandora udevd[226]: msg_dump_queue: sequence 1000000 in queue
> > Mar 26 20:40:38 pandora udevd[226]: msg_queue_manager: next event expires in 3199 seconds
>
> Very strange.
> Could you please apply the attached patch and retry it?
> This is what I get:
>
> Mar 26 21:44:28 pim udevd[3664]: msg_queue_insert: queued message seq 1000003
> Mar 26 21:44:28 pim udevd[3664]: msg_queue_manager: msg queue manager, next expected is 1000002
> Mar 26 21:44:28 pim udevd[3664]: msg_queue_manager: xxx msg age is 0
> Mar 26 21:44:28 pim udevd[3664]: msg_dump_queue: sequence 1000003 in queue
> Mar 26 21:44:28 pim udevd[3664]: msg_queue_manager: next event expires in 5 seconds
> Mar 26 21:44:28 pim udevd[3664]: msg_queue_manager: xxx itimer seconds is 5
> Mar 26 21:44:33 pim udevd[3664]: msg_queue_manager: msg queue manager, next expected is 1000002
> Mar 26 21:44:33 pim udevd[3664]: msg_queue_manager: xxx msg age is 5
> Mar 26 21:44:33 pim udev[3669]: get_dirs: sysfs_path='/sys'
> Mar 26 21:44:33 pim udev[3669]: parse_config_file: reading '/etc/udev/udev.conf' as config file
> Mar 26 21:44:33 pim udev[3669]: main: version 023
> Mar 26 21:44:33 pim udev[3669]: udev_hotplug: looking at '/test'
> Mar 26 21:44:33 pim udev[3669]: udev_hotplug: not a block or class device
> Mar 26 21:44:33 pim udevd[3664]: udev_run: => exec seq 1000003 [3669] working at '/test'
> Mar 26 21:44:33 pim udevd[3664]: exec_queue_manager: moved seq 1000003 to running list
> Mar 26 21:44:33 pim udevd[3664]: msg_move_exec: moved seq 1000003 to exec, next expected is 1000004
> Mar 26 21:44:33 pim udevd[3664]: udev_done: <= exec seq 1000003 came back
>
>
> thanks,
> Kay
>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
` (4 preceding siblings ...)
2004-03-26 21:28 ` Oliver Paschke
@ 2004-03-26 21:57 ` Kay Sievers
2004-03-27 12:55 ` Treeve Jelbert
2004-03-27 19:02 ` Kay Sievers
7 siblings, 0 replies; 9+ messages in thread
From: Kay Sievers @ 2004-03-26 21:57 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Fri, Mar 26, 2004 at 10:28:06PM +0100, Oliver Paschke wrote:
> Applied the patch. This is what my syslog reads:
>
> Mar 26 22:14:24 pandora udevsend[1157]: main: version 023
> Mar 26 22:14:24 pandora udevsend[1157]: main: subsystem = 'test'
> Mar 26 22:14:24 pandora udevsend[1157]: main: DEVPATH = '/test'
> Mar 26 22:14:24 pandora udevsend[1157]: main: ACTION = 'add'
> Mar 26 22:14:24 pandora udevsend[1157]: main: SEQNUM = '1000000'
> Mar 26 22:14:24 pandora udevd[227]: msg_queue_insert: queued message seq 1000000
> Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: msg queue manager, next expected is 0
> Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: xxx msg age is -3484
> Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 116 in queue
> [...]
> Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 153 in queue
> Mar 26 22:14:24 pandora udevd[227]: msg_dump_queue: sequence 1000000 in queue
> Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: next event expires in 3489 seconds
> Mar 26 22:14:24 pandora udevd[227]: msg_queue_manager: xxx itimer seconds is 3489
>
> Negative message age... ?
> Could all this result from a possible bug in my glibc-3.3?
Hmm, don't know. I can't reproduce it.
Now I start to guess :)
Could you please try this.
thanks,
Kay
[-- Attachment #2: udevd.patch --]
[-- Type: text/plain, Size: 550 bytes --]
===== udevd.c 1.24 vs edited =====
--- 1.24/udevd.c Wed Mar 17 23:40:12 2004
+++ edited/udevd.c Fri Mar 26 22:29:41 2004
@@ -104,11 +104,12 @@
list_for_each_entry(loop_msg, &msg_list, list)
if (loop_msg->seqnum > msg->seqnum)
break;
- list_add_tail(&msg->list, &loop_msg->list);
- dbg("queued message seq %d", msg->seqnum);
/* store timestamp of queuing */
msg->queue_time = time(NULL);
+
+ list_add_tail(&msg->list, &loop_msg->list);
+ dbg("queued message seq %d", msg->seqnum);
/* run msg queue manager */
msg_queue_manager();
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
` (5 preceding siblings ...)
2004-03-26 21:57 ` Kay Sievers
@ 2004-03-27 12:55 ` Treeve Jelbert
2004-03-27 19:02 ` Kay Sievers
7 siblings, 0 replies; 9+ messages in thread
From: Treeve Jelbert @ 2004-03-27 12:55 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 26 March 2004 21:05, Treeve Jelbert wrote:
I have just changed /etc/sysconfig/hwclock to that the hardware clock is kept
in UTC. Previously it was CET, as I still dual boot into Windows98
sometimes.
The next boot started correctly and all expected devices were created, apart
from the ide cd drive which does not appear as cdrom. The scsi cdrw appears
correctly.
Perhaps the udev sleep function got confused by changes to the clock? A one
hour time change might explain wait 3599 seconds?
Regards, Treeve
- --
PGP Key ID: AB929B24
PGP Key Fingerprint:31D9 D22F 42E6 F545 662E AB6F 9697 34C5 AB92 9B24
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAZXnUlpc0xauSmyQRAkFSAJ9fctUIhlUMGRzafcMgpoXa6P5atQCfdIca
Li77Bq0JuJ7XTfM1SMQGi4Y=Vr+f
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&opÌk
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: udev fails to add/remove devices
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
` (6 preceding siblings ...)
2004-03-27 12:55 ` Treeve Jelbert
@ 2004-03-27 19:02 ` Kay Sievers
7 siblings, 0 replies; 9+ messages in thread
From: Kay Sievers @ 2004-03-27 19:02 UTC (permalink / raw)
To: linux-hotplug
On Sat, Mar 27, 2004 at 01:55:27PM +0100, Treeve Jelbert wrote:
> I have just changed /etc/sysconfig/hwclock to that the hardware clock is kept
> in UTC. Previously it was CET, as I still dual boot into Windows98
> sometimes.
>
> The next boot started correctly and all expected devices were created, apart
> from the ide cd drive which does not appear as cdrom. The scsi cdrw appears
> correctly.
>
> Perhaps the udev sleep function got confused by changes to the clock? A one
> hour time change might explain wait 3599 seconds?
Great work, you saved my weekend :)
Many thanks for figuring it out, I will prepare a change that limits the
timout value to the maximum value.
thanks again,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 9+ messages in thread