From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev fails to add/remove devices
Date: Fri, 26 Mar 2004 17:39:58 +0000 [thread overview]
Message-ID: <20040326173958.GB493@vrfy.org> (raw)
In-Reply-To: <20040326180855.37deecab.elfy666@gmx.de>
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
next prev parent reply other threads:[~2004-03-26 17:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-26 17:08 udev fails to add/remove devices Oliver Paschke
2004-03-26 17:39 ` Kay Sievers [this message]
2004-03-26 20:05 ` Treeve Jelbert
2004-03-26 20:13 ` Oliver Paschke
2004-03-26 20:42 ` Oliver Paschke
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040326173958.GB493@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).