inconsistent renaming of devices
maybe this one has been reported before...
I am not sure if I searched for the right keywords...
I see the following behaviour in an unpatched udev-008 on kernel 2.6.0-test11:
when inserting my memory stick the rule I defined fires, but the devices I get are somehow inconsistent.
the rule:
LABEL, BUS="scsi", vendor="Prolific", NAME="stick%n"
the result (one case)
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 sda3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4
another case:
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 stick3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4
see, what I mean?
tell me if you need more input (logfiles, etc)
thank you
Signature · 16 lines
martin lorenz no comment ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 30 lines · Martin Lorenz
maybe this one has been reported before...
I am not sure if I searched for the right keywords...I see the following behaviour in an unpatched udev-008 on kernel 2.6.0-test11:
when inserting my memory stick the rule I defined fires, but the devices I get are somehow inconsistent.
the rule:
LABEL, BUS="scsi", vendor="Prolific", NAME="stick%n"the result (one case)
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 sda3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4another case:
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 stick3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4
Quoted 3 lines
see, what I mean?
tell me if you need more input (logfiles, etc)
Yeah, this is an issue of userspace beating the kernel. I'll be working on fixing this up in udev today. Sorry about that.
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi,
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.
Thanks,
surekha
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Greg KH
Sent: Wednesday, December 17, 2003 11:44 PM
To: Martin Lorenz
Cc: [email protected]
Subject: Re: inconsistent renaming of devices
Quoted 30 lines · Martin Lorenz
maybe this one has been reported before...
I am not sure if I searched for the right keywords...I see the following behaviour in an unpatched udev-008 on kernel 2.6.0-test11:
when inserting my memory stick the rule I defined fires, but the devices I get are somehow inconsistent.
the rule:
LABEL, BUS="scsi", vendor="Prolific", NAME="stick%n"the result (one case)
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 sda3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4another case:
# ll /udev/ total 0 brw-rw-rw- 1 root root 8, 0 Dec 17 08:32 sda brw-rw-rw- 1 root root 8, 1 Dec 17 08:32 sda1 brw-rw-rw- 1 root root 8, 2 Dec 17 08:32 sda2 brw-rw-rw- 1 root root 8, 3 Dec 17 08:32 stick3 brw-rw-rw- 1 root root 8, 4 Dec 17 08:32 stick4
Quoted 3 lines
see, what I mean?
tell me if you need more input (logfiles, etc)
Yeah, this is an issue of userspace beating the kernel. I'll be working on fixing this up in udev today. Sorry about that.
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Surekha.PC
Hi,
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.
Yes, it should be fixed.
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog show for these devices?
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Greg KH
Quoted 3 lines · Surekha.PC
Hi,
Quoted 8 lines
Quoted 2 lines
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.Yes, it should be fixed.
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog show for these devices?
It is probalby the same sort of race that I reported earlier this week.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog
show for these
Quoted 1 line
devices?
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries are retained under /udev.
In this scenario I could see some debug messages as below.
Looks like the sysfs entries for the device are removed long before udev lookup.
------------------------------------------------------------------------
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
------------------------------------------------------------------------
------------------
In the above debug messages, I could observe the first few hotplug events for device removal are not getting passed to udev_remove_device(). This results in those device entries not getting removed.
Let me know if you need more information from the debug log, I will send it to you.
Thanks,
surekha
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Greg KH
Sent: Thursday, February 05, 2004 2:26 PM
To: Surekha.PC
Cc: 'Martin Lorenz'; [email protected]
Subject: Re: inconsistent renaming of devices
Quoted 5 lines · Surekha.PC
Hi,
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.
Yes, it should be fixed.
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog show for these devices?
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Olaf Hering
Quoted 7 lines · Greg KH
Quoted 5 lines · Surekha.PC
Hi,
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.
Quoted 7 lines
Quoted 5 lines
Yes, it should be fixed.
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog show for these devices?It is probalby the same sort of race that I reported earlier this week.
Do you mean the permisions one? That's all I remember seeing. If not, please let me know.
I still need to try to track down that permissions problem...
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Surekha.PC
Quoted 4 lines
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslogshow for these
Quoted 1 line
devices?
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Quoted 8 lines
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries are retained under /udev.
In this scenario I could see some debug messages as below.
Looks like the sysfs entries for the device are removed long before udev lookup.
What kind of block device is this?
Quoted 19 lines
------------------------------------------------------------------------
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
------------------------------------------------------------------------
------------------
Quoted 4 lines
In the above debug messages, I could observe the first few hotplug events for device removal are not getting passed to
udev_remove_device(). This results in those device entries not getting removed.
How are we dropping events? Are you using the udevsend/udevd/udev situation, or just udev? I don't see how we could drop events just using udev alone.
Quoted 2 lines
Let me know if you need more information from the debug log, I will send it to you.
Please do. Along with annotation of what is going on.
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Surekha.PC
Quoted 4 lines
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslogshow for these
Quoted 1 line
devices?
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Quoted 8 lines
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries are retained under /udev.
In this scenario I could see some debug messages as below.
Looks like the sysfs entries for the device are removed long before udev lookup.
We don't need sysfs for device removal.
Quoted 8 lines
------------------------------------------------------------------------
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....
Quoted 8 lines
namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
Huh, what version of udev is this?
'scsi_device' is blacklisted.
Kay
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Surekha.PC
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries
Quoted 6 lines
are retained under /udev.
In this scenario I could see some debug messages as below.
Looks like the sysfs entries for the device are removed long before udev lookup.
}We don't need sysfs for device removal.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
It seems that udev is trying to lookup the
"/class/scsi_device/40:0:38:1" from the debug below ?
Quoted 9 lines
----------------------------------------------------------------------
--
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....
Quoted 8 lines
namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
}Huh, what version of udev is this?
}'scsi_device' is blacklisted.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I am using the latest udev-016 package.
Thanks,
surekha
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 17 lines · Surekha.PC
Quoted 14 lines · Surekha.PC
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries
are retained under /udev.
In this scenario I could see some debug messages as below.
Quoted 7 lines
Quoted 2 lines
Looks like the sysfs entries for the device are removed long before udev lookup.
}We don't need sysfs for device removal.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
It seems that udev is trying to lookup the
"/class/scsi_device/40:0:38:1" from the debug below ?
No, it tries to find the device in its own database.
If udev creates a devices it maintains a record with the devpath in a database and on removal it looks up the database for the name to remove. There is no sysfs lookup. We just don't find the device for removal, cause we have never created one.
Quoted 19 lines
Quoted 9 lines
----------------------------------------------------------------------
--
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....Quoted 8 lines
namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
Quoted 4 lines
}Huh, what version of udev is this?
}'scsi_device' is blacklisted.Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I am using the latest udev-016 package.
Ahh, I see your driver seems to create a hotplug event with the devpath '/class/scsi_device/*' and the sysbsystem 'block' so it bypasses our blacklist. Greg, must we check the devpath too in udev, or is the driver to be fixed?
thanks,
Kay
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi all,
The problem is no longer seen on. It seems like a setup problem, the
installed udev binary size was not matching with that of udev-016. This could have happened when I installed udev-016 without uninstalling the old package. The udev binary was not installed properly, so 'udevsend' and 'udevd' were not started. This was causing problem in device creation. I cleanly uninstalled the old package and installed udev-016, now device addition/removal is happening fine.
Thanks much for your inputs.
regds,
surekha
-----Original Message-----
From: Greg KH [mailto:[email protected]]
Sent: Friday, February 06, 2004 5:22 AM
To: Surekha.PC
Cc: 'Martin Lorenz'; [email protected]
Subject: Re: inconsistent renaming of devices
Quoted 17 lines · Surekha.PC
Quoted 4 lines
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslogshow for these
Quoted 1 line
devices?
It seems the user<->kernel race still persists.
During device addition randomly few device/partition entries are not getting created. If debug is enabled all devices are created. With debug turned off, only few of them are created. So in this case I am not able to capture debug for devices not getting created.
Again device removal is also having the similar inconsistent behaviour. Irrespective of debug being on/off few stale device entries
Quoted 6 lines
are retained under /udev.
In this scenario I could see some debug messages as below.
Looks like the sysfs entries for the device are removed long before udev lookup.
What kind of block device is this?
Quoted 9 lines
----------------------------------------------------------------------
--
-----------------udev_hotplug: looking at '/block/sdc'udev_hotplug: looking at '/block/sde/sde2udev_hotplug: looking at '/block/sde/sde3get_dirs: sysfs_path='/sys'udev_hotplug: don't care about 'scsi_device' devices
.....
Quoted 9 lines
namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
.....udev_hotplug: looking at '/block/sdc/sdc3udev_hotplug: don't care about 'scsi_device' devicesudev_remove_device: name is 'iscsib0t38l0sd3'
......udev_remove_device: '/class/scsi_device/40:0:38:1' not found in database, falling back on default name
------------------------------------------------------------------------
Quoted 7 lines
------------------
In the above debug messages, I could observe the first few hotplug events for device removal are not getting passed to
udev_remove_device(). This results in those device entries not gettingremoved.
How are we dropping events? Are you using the udevsend/udevd/udev situation, or just udev? I don't see how we could drop events just using udev alone.
Quoted 2 lines
Let me know if you need more information from the debug log, I will send it to you.
Please do. Along with annotation of what is going on.
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · Greg KH
Quoted 11 lines · Olaf Hering
Quoted 9 lines · Greg KH
Quoted 5 lines · Surekha.PC
Hi,
Has this problem been fixed in udev? I installed the latest udev-016
package and device naming inconsistenty persists.Yes, it should be fixed.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
What do you see happening in your system?
If you build with DEBUG=true USE_LOG=true what does the debug syslog show for these devices?It is probalby the same sort of race that I reported earlier this week.
Do you mean the permisions one? That's all I remember seeing. If not, please let me know.
No, that was about that fact that block (and scsi) events run much earlier than expected. The properties below /block/sda/device/ and /sys/bus/*/devices/$bus_id appear to late, the result is that the BUS="scsi" rule doesnt match and it falls through to the BUS="usb" rule. I have to add sleep 3 in case of my USB stick.
It would make sense to run the /block/sda event just before the /block/sda/sda1 event (if there is a partition table). sda1 has always all properties in /block/sda/sda1/../device/
sysfs_path_is_link() does a stat(/sys/bus/*/devices/$bus_id) and this does not exist.
Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/scsi/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/ieee1394/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/usb/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/ide/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/macio/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/pci/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/of_platform/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: sysfs_path_is_link: stat(/sys/bus/platform/devices/15:0:0:0) failed Feb 8 14:36:33 ibook udev[12643]: get_sysfs_device: timed out waiting to find the device bus, continuing on anyway Feb 8 14:36:33 ibook udev[12643]: namedev_name_device: sysfs_device->path='/sys/devices/pci0001:01/0001:01:18.0/usb1/1-1/1-1:1.0/host15/15:0:0:0' Feb 8 14:36:33 ibook udev[12643]: namedev_name_device: sysfs_device->bus_id='15:0:0:0' Feb 8 14:36:33 ibook udev[12643]: namedev_name_device: sysfs_device->bus='' Feb 8 14:36:33 ibook udev[12643]: wait_for_device_to_initialize: did not find bus type '' on list of bus_id_files, contact [email protected] Feb 8 14:36:33 ibook udev[12643]: namedev_name_device: kernel_number='' Feb 8 14:36:33 ibook udev[12643]: namedev_name_device: process rule Feb 8 14:36:33 ibook udev[12643]: match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='' Feb 8 14:36:33 ibook udev[12643]: match_rule: BUS is not matching
Now, this little hack, and the result looks much better.
libsysfs/sysfs_device.c 2004-02-08 15:06:10.738209173 +0100 renamed from libsysfs/sysfs_device.c 2004-01-17 02:42:37.000000000 +0100 +9 -0
@@ -34,6 +34,7 @@ int sysfs_get_device_bus(struct sysfs_de unsigned char subsys[SYSFS_NAME_LEN], path[SYSFS_PATH_MAX]; unsigned char target[SYSFS_PATH_MAX], *bus = NULL, *c = NULL; struct dlist *buslist = NULL; + int retries; if (dev = NULL) { errno = EINVAL;
@@ -44,6 +45,8 @@ int sysfs_get_device_bus(struct sysfs_de strcat(subsys, "/"); strcpy(subsys, SYSFS_BUS_NAME); /* subsys = /bus */ buslist = sysfs_open_subsystem_list(subsys); + retries = 5; +retry: if (buslist != NULL) { dlist_for_each_data(buslist, bus, char) { memset(path, 0, SYSFS_PATH_MAX);
@@ -79,6 +82,12 @@ int sysfs_get_device_bus(struct sysfs_de } } } + if(--retries) { + dprintf("sleep one second for %s\n", dev->bus_id); + sleep(1); + dprintf("retries left: %d\n", retries); + goto retry; + } sysfs_close_list(buslist); } return -1;
Feb 8 15:06:46 ibook udev[16851]: main: version 016_bk Feb 8 15:06:46 ibook udev[16851]: udev_hotplug: looking at '/block/sda' Feb 8 15:06:46 ibook udev[16851]: get_dirs: sysfs_path='/sys' Feb 8 15:06:46 ibook udev[16851]: parse_config_file: reading '/etc/udev/udev.conf' as config file Feb 8 15:06:46 ibook udev[16851]: namedev_init_rules: reading '/etc/udev/udev.rules' as rules file Feb 8 15:06:46 ibook udev[16851]: namedev_init_permissions: reading '/etc/udev/udev.permissions' as permissions file Feb 8 15:06:46 ibook udev[16851]: sleep_for_dev: looking for '/sys/block/sda/dev' Feb 8 15:06:46 ibook udev[16851]: get_class_dev: looking at '/sys/block/sda' Feb 8 15:06:46 ibook udev[16851]: get_class_dev: class_dev->name='sda' Feb 8 15:06:46 ibook udev[16851]: get_major_minor: dev='8:0 ' Feb 8 15:06:46 ibook udev[16851]: get_major_minor: found major=8, minor=0 Feb 8 15:06:46 ibook udev[16851]: get_blockdev_parent: sda not a partition Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/scsi/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ieee1394/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/usb/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ide/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/macio/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/pci/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/of_platform/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/platform/devices/23:0:0:0) failed Feb 8 15:06:46 ibook udev[16851]: sysfs_get_device_bus: sleep one second for 23:0:0:0 Feb 8 15:06:47 ibook udev[16851]: sysfs_get_device_bus: retries left: 4 Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/scsi/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ieee1394/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/usb/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ide/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/macio/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/pci/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/of_platform/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/platform/devices/23:0:0:0) failed Feb 8 15:06:47 ibook udev[16851]: sysfs_get_device_bus: sleep one second for 23:0:0:0 Feb 8 15:06:48 ibook udev[16851]: sysfs_get_device_bus: retries left: 3 Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/scsi/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ieee1394/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/usb/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/ide/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/macio/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/pci/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/of_platform/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_path_is_link: stat(/sys/bus/platform/devices/23:0:0:0) failed Feb 8 15:06:48 ibook udev[16851]: sysfs_get_device_bus: sleep one second for 23:0:0:0 Feb 8 15:06:49 ibook udev[16851]: sysfs_get_device_bus: retries left: 2 Feb 8 15:06:49 ibook udev[16851]: get_sysfs_device: device 23:0:0:0 is registered with bus 'scsi' Feb 8 15:06:49 ibook udev[16851]: namedev_name_device: sysfs_device->path='/sys/devices/pci0001:01/0001:01:18.0/usb1/1-1/1-1:1.0/host23/23:0:0:0' Feb 8 15:06:49 ibook udev[16851]: namedev_name_device: sysfs_device->bus_id='23:0:0:0' Feb 8 15:06:49 ibook udev[16851]: namedev_name_device: sysfs_device->bus='scsi' Feb 8 15:06:49 ibook udev[16851]: wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi' Feb 8 15:06:49 ibook udev[16851]: namedev_name_device: kernel_number='' Feb 8 15:06:49 ibook udev[16851]: namedev_name_device: process rule Feb 8 15:06:49 ibook udev[16851]: match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi' Feb 8 15:06:49 ibook udev[16851]: match_rule: BUS matches
Quoted 1 line
I still need to try to track down that permissions problem...
Could be a dietlibc problem. Havent look closer yet.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Olaf Hering
No, that was about that fact that block (and scsi) events run much earlier than expected. The properties below /block/sda/device/ and
/sys/bus/*/devices/$bus_idappear to late, the result is that the BUS="scsi" rule doesnt match and it falls through to the BUS="usb" rule. I have to add sleep 3 in case of my USB stick.
Quoted 8 lines
It would make sense to run the /block/sda event just before the /block/sda/sda1 event (if there is a partition table). sda1 has always all properties in /block/sda/sda1/../device/
sysfs_path_is_link()does astat(/sys/bus/*/devices/$bus_id)and this does not exist.Now, this little hack, and the result looks much better.
Wouldn't it be much better if you increase the wait time in get_sysfs_device() in namedev.c from 10ms instead of adding a retry loop?
Review int sysfs_get_device_bus(struct sysfs_de · line 93
Quoted 13 lines
(quoted diff) +6
-0@@ -79,6 +82,12 @@ int sysfs_get_device_bus(struct sysfs_de } } } + if(--retries) { + dprintf("sleep one second for %s\n", dev->bus_id); + sleep(1); + dprintf("retries left: %d\n", retries); + goto retry; + } sysfs_close_list(buslist); } return -1;
I am not in favour of sleep()ing inside the library. I'd rather the app handle sleep and retries :)
Thanks,
Ananth
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Ananth N Mavinakayanahalli
I am not in favour of sleep()ing inside the library. I'd rather the app handle sleep and retries :)
This patch fails for other reasons. Better fix the kernel. IDE has the same problem.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel