Re: getting udev to work with USB combo drive

[Greg KH <greg@kroah.com>]

On Wed, Feb 11, 2004 at 09:45:41PM -0800, Dave Hansen wrote:
> On Wed, 2004-02-11 at 17:38, Greg KH wrote:
> > On Sat, Feb 07, 2004 at 07:22:04PM -0800, Dave Hansen wrote:
> > > I have a pretty stupid USB combo device that doesn't like to report very
> > > detailed information about itself (For Google's sake, the drive is a
> > > Vosonic X's Drive Pro VP-300):
> > >     SYSFS_vendor="USB     "
> > >     SYSFS_model="USB             "
> > >     SYSFS_rev="1.00"
> > > 
> > > Despite that, SYSFS_serial looked good, so I decided to use it for
> > > udev.  The device has an internal hard disk, and 3 media slots, so I
> > > laid out 3 entries like this:
> > > SYSFS_serial="0123", ID="*:0", NAME="xdrive/disk%n"
> > > SYSFS_serial="0123", ID="*:1", NAME="xdrive/cf%n"
> > > SYSFS_serial="0123", ID="*:2", NAME="xdrive/sm%n"
> > > SYSFS_serial="0123", ID="*:3", NAME="xdrive/xd%n"
> > > 
> > > But, these rules never matched.  The wildcard in the ID= field appears
> > > to be ignored.  Is that a bug? 
> > 
> > As Pat showed, this was never checked.  With his patch, it should be
> > now.  Will that give you enough to match properly without needing your
> > script?
> 
> It still doesn't work, but I don't think it's because of the wildcard
> any more.  I can actually see that rule match in the debug output.
> 
> How important is the order in which you specify your 'FOO="bar",' rules
> in udev.rules?

Very important.  They are evaluated in the order in which they show up
in the udev.rules file.

> Don't you have to start with the specifications that are
> lowest in the tree and work up from there?  The "goto try_parent" is a
> pop off the stack, and you don't ever get back down to the children. 
> Maybe I just missed this until now.  

You need to put the rules that are the most specific first in the list.
Put more general ones at the end to catch anything not found above them.

> Also, I think I'm getting some garbage in the SYSFS_serial variable. 
> When I get down to the match_rule() area for SYSFS_serial="...", I get
> some output in the debug log like this:
> compare_sysfs_attribute: compare attribute 'serial' value '0A4110002CEA'
> with 'HXOLL0012202323480'
> 
> But, I have no idea where HXOLL0012202323480 came from.  
> 
> 'grep -r HXOLL0012202323480 /sys' comes up with nothing.
> 
> Any ideas?  Is that some memory garbage from somewhere?

What type of device is this that exports a serial number in sysfs?  A
USB device?  If so, remember, USB serial numbers can change on you
(nasty isn't it) as they are read from the device when asked for.
Perhaps this is what is happening.

Try enabling  CONFIG_USB_DEBUG in your kernel and look at your kernel
log when the device is inserted.  It will tell you what the serial
number is for the device at that point in time.  See if that matches up
with what udev is reading from sysfs.

That data looks too text like to be random garbage (but I could be
wrong.)

thanks,

greg k-h


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&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