linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.13 breaks udev rule
@ 2005-09-04  0:31 Jim McCloskey
  2005-09-04  1:00 ` Kay Sievers
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jim McCloskey @ 2005-09-04  0:31 UTC (permalink / raw)
  To: linux-hotplug

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

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-09-04 22:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-04  0:31 2.6.13 breaks udev rule Jim McCloskey
2005-09-04  1:00 ` Kay Sievers
2005-09-04 16:04 ` Greg KH
2005-09-04 22:13 ` Jim McCloskey

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