inconsistent renaming of devices

inconsistent renaming of devices

[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 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

-- 
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_id\x1278&alloc_id371&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

Re: inconsistent renaming of devices

[Greg KH]

On Wed, Dec 17, 2003 at 10:33:51AM +0100, Martin Lorenz wrote:
> 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)

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_id\x1278&alloc_id371&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

RE: inconsistent renaming of devices

[Surekha.PC]

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: linux-hotplug-devel-admin@lists.sourceforge.net
[mailto:linux-hotplug-devel-admin@lists.sourceforge.net] On Behalf Of
Greg KH
Sent: Wednesday, December 17, 2003 11:44 PM
To: Martin Lorenz
Cc: linux-hotplug-devel@lists.sourceforge.net
Subject: Re: inconsistent renaming of devices


On Wed, Dec 17, 2003 at 10:33:51AM +0100, Martin Lorenz wrote:
> 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)

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_id\x1278&alloc_id371&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



-------------------------------------------------------
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Greg KH]

On Thu, Feb 05, 2004 at 11:58:53AM +0530, Surekha.PC wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Olaf Hering]

 On Thu, Feb 05, Greg KH wrote:

> On Thu, Feb 05, 2004 at 11:58:53AM +0530, Surekha.PC wrote:
> > 
> > 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?

It is probalby the same sort of race that I reported earlier this week.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: inconsistent renaming of devices

[Surekha.PC]

>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 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/sde2
udev_hotplug: looking at '/block/sde/sde3
get_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/sdc3
udev_hotplug: don't care about 'scsi_device' devices
udev_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: linux-hotplug-devel-admin@lists.sourceforge.net
[mailto:linux-hotplug-devel-admin@lists.sourceforge.net] On Behalf Of
Greg KH
Sent: Thursday, February 05, 2004 2:26 PM
To: Surekha.PC
Cc: 'Martin Lorenz'; linux-hotplug-devel@lists.sourceforge.net
Subject: Re: inconsistent renaming of devices


On Thu, Feb 05, 2004 at 11:58:53AM +0530, Surekha.PC wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Greg KH]

On Thu, Feb 05, 2004 at 10:56:45AM +0100, Olaf Hering wrote:
>  On Thu, Feb 05, Greg KH wrote:
> 
> > On Thu, Feb 05, 2004 at 11:58:53AM +0530, Surekha.PC wrote:
> > > 
> > > 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?
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Greg KH]

On Thu, Feb 05, 2004 at 03:29:41PM +0530, Surekha.PC wrote:
> 
> 
> >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 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.

What kind of block device is this?  

> ------------------------------------------------------------------------
> -----------------
> udev_hotplug: looking at '/block/sdc'
> udev_hotplug: looking at '/block/sde/sde2
> udev_hotplug: looking at '/block/sde/sde3
> get_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/sdc3
> udev_hotplug: don't care about 'scsi_device' devices
> udev_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.

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.

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Kay Sievers]

On Thu, Feb 05, 2004 at 03:29:41PM +0530, Surekha.PC wrote:
> 
> 
> >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 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.

We don't need sysfs for device removal.


> ------------------------------------------------------------------------
> -----------------
> udev_hotplug: looking at '/block/sdc'
> udev_hotplug: looking at '/block/sde/sde2
> udev_hotplug: looking at '/block/sde/sde3
> get_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/sdc3
> udev_hotplug: don't care about 'scsi_device' devices
> udev_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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: inconsistent renaming of devices

[Surekha.PC]

On Thu, Feb 05, 2004 at 03:29:41PM +0530, Surekha.PC wrote:
> 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.

}We don't need sysfs for device removal.

>>>> It seems that udev is trying to lookup the
"/class/scsi_device/40:0:38:1" from the debug below ?

> ----------------------------------------------------------------------
> --
> -----------------
> udev_hotplug: looking at '/block/sdc'
> udev_hotplug: looking at '/block/sde/sde2
> udev_hotplug: looking at '/block/sde/sde3
> get_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/sdc3
> udev_hotplug: don't care about 'scsi_device' devices
> udev_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.

>>>> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

['Kay Sievers']

On Fri, Feb 06, 2004 at 11:52:31AM +0530, Surekha.PC wrote:
> 
> 
> On Thu, Feb 05, 2004 at 03:29:41PM +0530, Surekha.PC wrote:
> > 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.
> 
> }We don't need sysfs for device removal.
> 
> >>>> 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.


> > ----------------------------------------------------------------------
> > --
> > -----------------
> > udev_hotplug: looking at '/block/sdc'
> > udev_hotplug: looking at '/block/sde/sde2
> > udev_hotplug: looking at '/block/sde/sde3
> > get_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/sdc3
> > udev_hotplug: don't care about 'scsi_device' devices
> > udev_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.
> 
> >>>> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: inconsistent renaming of devices

[Surekha.PC]

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:greg@kroah.com] 
Sent: Friday, February 06, 2004 5:22 AM
To: Surekha.PC
Cc: 'Martin Lorenz'; linux-hotplug-devel@lists.sourceforge.net
Subject: Re: inconsistent renaming of devices


On Thu, Feb 05, 2004 at 03:29:41PM +0530, Surekha.PC wrote:
> 
> 
> >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 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.

What kind of block device is this?  

> ----------------------------------------------------------------------
> --
> -----------------
> udev_hotplug: looking at '/block/sdc'
> udev_hotplug: looking at '/block/sde/sde2
> udev_hotplug: looking at '/block/sde/sde3
> get_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/sdc3
> udev_hotplug: don't care about 'scsi_device' devices
> udev_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.

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.

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Olaf Hering]

 On Thu, Feb 05, Greg KH wrote:

> On Thu, Feb 05, 2004 at 10:56:45AM +0100, Olaf Hering wrote:
> >  On Thu, Feb 05, Greg KH wrote:
> > 
> > > On Thu, Feb 05, 2004 at 11:58:53AM +0530, Surekha.PC wrote:
> > > > 
> > > > 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?
> > 
> > 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 greg@kroah.com
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.

--- udev-glibc/libsysfs/sysfs_device.c  2004-01-17 02:42:37.000000000 +0100
+++ udev-glibc-debug/libsysfs/sysfs_device.c    2004-02-08 15:06:10.738209173 +0100
@@ -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


> I still need to try to track down that permissions problem...

Could be a dietlibc problem. Havent look closer yet.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Ananth N Mavinakayanahalli]

On Sun, Feb 08, 2004 at 03:13:23PM +0100, Olaf Hering wrote:
> 
> 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.
> 
> 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? 

> @@ -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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: inconsistent renaming of devices

[Olaf Hering]

 On Mon, Feb 09, Ananth N Mavinakayanahalli wrote:


> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel