On Mon, 29 Dec 2008, Erik Ekman wrote: > I should explain what the tf-tool does. I ran it with option --acquire > which means > you swipe three times and it produces a file which is the recorded fingerprint. > I dont know what interval is 2 ms, I sure didnt run it that way. I got a version of the thinkfinger code from Sourceforge. Evidently it opens the device file, does some stuff, and closes the file. Then it opens the file again in order to acquire a fingerprint. That's why the pause is so short; the file gets opened twice during a single run of the program. > The "reverted" log shows a full fingerprint acquire with three swipes, > all in the same run of tf-tool. The shorter log shows an attempt to do it, > but tf-tool stopped with an error before I could swipe anything. The error occurred during the attempt to claim interface 0 the second time the file was opened. The EBUSY error code means the kernel thought the interface was already claimed. > This time I have added pam_thinkfinger.so as sufficient for system > login, and have recorded login attempts with and without the specific > commit in the kernel. > > Stock 2.6.28 did not log me in, I had to write a password. dmesg shows: > input: Virtual ThinkFinger Keyboard as /class/input/input8 > usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use > usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use > usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use ... Here you see another confusing aspect of the problem. The kernel thinks the program used interface 0 before claiming it, and the program thinks it tried to claim the interface but failed! And I still don't see what connection any of this has to that commit. The commit has no effect on interface claims. > Bus 5, device 2 is my reader: > Bus 005 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader > > 2.6.28 minus the commit lets me in when I swipe, and dmesg only shows: > input: Virtual ThinkFinger Keyboard as /class/input/input8 Now this is confusing too, because you've got the program running automatically to verify logins and you've got it running directly from the command line. I get the impression that there may be something funky going on involving multiple threads or multiple processes all trying to access the reader simultaneously. That's just a guess, though. Still, it's easier to figure out what's happening when there's only one task running and it is started from the command line -- not automatically. Do you have the thinkfinger source code handy? Can you build it with the USB_DEBUG option enabled? Alan Stern -- 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
