linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim McCloskey <mcclosk@ucsc.edu>
To: linux-hotplug@vger.kernel.org
Subject: 2.6.13 breaks udev rule
Date: Sun, 04 Sep 2005 00:31:50 +0000	[thread overview]
Message-ID: <20050904003150.GA3958@branci40> (raw)

Hello. This simple rule for my Sandisk Minicruizer:

BUS="usb", SYSFS{serial}="0000183546", NAME="%k", SYMLINK="sandisk"

worked without problem under the 2.6.11 kernels, but ceased to work as
soon as I upgraded to 2.6.13.  There was no other change in hardware
or software.  Under 2.6.13 hotplug creates /dev/sda1, but udev does
not create the /dev/sandisk link. Mounting /dev/sda1 by hand works
fine.  Substituting this rule:

BUS="scsi", SYSFS{vendor}="Generic*", NAME="%k", SYMLINK="sandisk"

works, but it's hardly the best rule.

When I probed a bit, it turned out that none of the USB keys worked
under 2.6.13. And in fact, for this device, udevinfo (and so
presumably udev) `sees' only the scsi part of the /sys/ directory
tree. This is the total output:

device '/sys/block/sda' has major:minor 8:0
  looking at class device '/sys/block/sda':
    SUBSYSTEM="block"
    SYSFS{dev}="8:0"
    SYSFS{range}="16"
    SYSFS{removable}="1"
    SYSFS{size}="256000"
    SYSFS{stat}="1        0        8        1        0        0        0        0        0        1        1"

follow the class device's "device"
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0/host1/target1:0:0/1:0:0:0':
    BUS="scsi"
    ID="1:0:0:0"
    DRIVER="sd"
    SYSFS{device_blocked}="0"
    SYSFS{iocounterbits}="32"
    SYSFS{iodone_cnt}="0xa"
    SYSFS{ioerr_cnt}="0x1"
    SYSFS{iorequest_cnt}="0xa"
    SYSFS{max_sectors}="240"
    SYSFS{model}="STORAGE DEVICE  "
    SYSFS{queue_depth}="1"
    SYSFS{queue_type}="none"
    SYSFS{rev}="0026"
    SYSFS{scsi_level}="3"
    SYSFS{state}="running"
    SYSFS{timeout}="30"
    SYSFS{type}="0"
    SYSFS{vendor}="Generic "

where the same command run under 2.6.11 yields much much more
information (all the `usb' bus sections).

This must in turn be related to another difference between 2.6.11 and
2.6.13---namely, that the /sys/bus/usb/devices trees are quite
different under the two kernels:

/sys/bus/usb/devices, 2.6.13:

lrwxrwxrwx  1 root root 0 2005-09-03 15:55 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:55 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:55 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:55 4-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.3/usb4/4-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:55 5-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 5-1 -> ../../../devices/pci0000:00/0000:00:1d.7/usb5/5-1
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 5-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 usb1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 usb2 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 usb3 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 usb4 -> ../../../devices/pci0000:00/0000:00:1d.3/usb4
lrwxrwxrwx  1 root root 0 2005-09-03 15:59 usb5 -> ../../../devices/pci0000:00/0000:00:1d.7/usb5

/sys/bus/usb/devices, 2.6.11:

lrwxrwxrwx  1 root root 0 2005-09-03 15:05 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:25 1-2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-2
lrwxrwxrwx  1 root root 0 2005-09-03 15:26 1-2:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 4-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.3/usb4/4-0:1.0
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 usb1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 usb2 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 usb3 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3
lrwxrwxrwx  1 root root 0 2005-09-03 15:05 usb4 ->../../../devices/pci0000:00/0000:00:1d.3/usb4

2.6.13 creates usb5 while 2.6.11 doesn't, and it looks like udev does
not have access to the information in the usb5 subdirectory. The sandisk is:

/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0 under 2.6.11

/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0 under 2.6.13

This is udev 056 from Debian stable/testing (068 is in unstable).

Is this a problem that would be solved by upgrading, or is there
something else going on? I'd be very grateful indeed for any advice or
information. Thanks to all,

Jim








-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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

             reply	other threads:[~2005-09-04  0:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-04  0:31 Jim McCloskey [this message]
2005-09-04  1:00 ` 2.6.13 breaks udev rule Kay Sievers
2005-09-04 16:04 ` Greg KH
2005-09-04 22:13 ` Jim McCloskey

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=20050904003150.GA3958@branci40 \
    --to=mcclosk@ucsc.edu \
    --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).