Hi Kay: Kay Sievers 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' > > > This of course causes failures later because of a bad file descriptor: > > Jul 29 11:03:25 test-laptop udevd-work[20561]: '/lib/udev/hid2hci' > (stderr) 'USB error: could not detach kernel driver from interface > 0: Bad file descriptor' > Jul 29 11:03:25 test-laptop udevd-work[20561]: '/lib/udev/hid2hci' > (stderr) 'USB error: could not claim interface 0: Bad file descriptor' I'm attaching a diff to follow up to this that removes the 'braindead' libusb open() on every device, and instead only opens the device that is needed. There is still a problem here with udev that the device node is not able to be opened necessarily at the time hid2hci is called, so I've got a workaround in place that I verified to sleep and try two more times before bailing out. -- Mario Limonciello *Dell | Linux Engineering* mario_limonciello@xxxxxxxx
Attachment:
iterate.diff
Description: iterate.diff
