On Thu, Apr 1, 2010 at 15:55, Jonas Schwertfeger <jschwertfeger@xxxxxxxxx> wrote: > On Thu, Apr 1, 2010 at 3:42 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: >>> Renamed both /usr/bin/udisks >> >> That's the commandline tool, you need to check for something like: >> /usr/lib/udisks/udisks-daemon >> >> Can you run as root: >> udevadm test /sys/class/block/sd... >> and post the output here. So we see what udev would run on bootup. > > Since the drive doesn't even show up as a block device when connected > to the USB 3.0 port I can't run that command for the device directly. That means it does not show up, or it disappears after something is trying to do something with it. If it does not appear at all, we don't need to look in userspace, I guess. :) > However, what I completely forgot to mention is that the drive works > just fine when connected to a USB 2.0 port. This was why I initially > thought the xHCI driver is to blame, but now that we are investigating > udev this does seem kind of odd to me. So, attached is the udevadm > test output with the drive connected to a USB 2.0 port. What are your rules trying to do with hdparm on the drive, that seems rather odd to apply to a USB device: RUN '/lib/udev/hdparm' /lib/udev/rules.d/85-hdparm.rules:2 Kay -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
