On Wed, Jul 29, 2009 at 12:30, Mario Limonciello<mario_limonciello@xxxxxxxx> wrote: >> On Mon, Jul 27, 2009 at 23:32, Marcel Holtmann<marcel@xxxxxxxxxxxx> wrote: >> Now it's getting funny. We need to call the nonsense two times to make >> it work? We need to fix the real issue here instead of doing guesswork >> and adding hacks like this. Any idea what's going on with the first >> scan? The device node is guaranteed to exist when we call stuff from >> RUN+= instructions. >> > Are you absolutely positive that the device node will exist and be > usable by the time something is called from RUN? I've been > enabling/adding debugging code around libusb, and finally got down to > the point that when it tries to do an open( ) on the device node, here's > what's happening: > > Jul 29 11:03:25 test-laptop udevd-work[20561]: '/lib/udev/hid2hci' > (stderr) 'USB error: failed to open /dev/bus/usb/003/061: No such > file or directory' Yeah, I'm sure. The thing is that the kernel USB code for some weird reason returns -ENOENT instead -ENODEV -- hence the misleading error string. Alan, I suspect (haven't checked) that at the time we get the event for the usb_device, the device is not ready to be handled by usbfs operations. Is that likely? And if, any idea how, and until which point, to delay the usb_device uevent, in which we hook in to do the usbfs actions from userspace? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
