Date: Sat, 23 Jun 2007 09:42:59 -0300 From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> To: Fredrik Lindberg <fli+freebsd-hackers@shapeshifter.se> Cc: hackers@freebsd.org Subject: Re: UPEK/TouchChip Biometric Device problem Message-ID: <467D1553.7060808@freebsdbrasil.com.br> In-Reply-To: <467CFA51.40101@shapeshifter.se> References: <467C343C.60707@freebsdbrasil.com.br> <467C3D4F.5030106@shapeshifter.se> <467CA46E.6070705@freebsdbrasil.com.br> <467CFA51.40101@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Fredrik Lindberg wrote: > Patrick Tracanelli wrote: >>> >>>> >>>> All threads purged from ugen1.1 >>>> All threads purged from ugen1.2 >>>> All threads purged from ugen1.3 >>> >>> Harmless, as far as I know. >>> >>>> >>>> What is this about "threads purged"? Also, the port want >>>> libintl.so.6 while 6.2-STABLE has libintl.so.8. I have tried 1) >>>> linking .8 to .6 and also copied .6 from another system (also, >>>> 6.2-STABLE) to the current one. Didnt work both way. Same behavior, >>>> exactly. >>> >>> This is because of a gettext library bump, I just found out about it >>> (although it happened in march), and I have know good solution to it. >>> Installing an old version of gettext should of course work, but that's >>> ugly. >> >> So, this has nothing to do with the fact that the device can not be >> initiated? >> > > This is _exactly_ the same device as you have been using in the past > with libtfmessbsp.so ? No, not the same hardware, but same model/chipset. > Because if you try to use it with an unsupported device you'll get > the "unable to attach" message. Its a 0x2016 device from 0x0483 vendor. This is the only thing that is "the same" as the previously used device. > > Those "All threads purged" have "always" been there, it appears > to happen with other devices as well > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-May/018361.html > > Since the binary is built on top of libusb you can turn on debugging > in libusb by setting the environment variable USB_DEBUG (the larger > value the more verbose debugging). Goood hint,thank you. Here is what I get: # bbdm -b "{5550454b-2054-464d-2f45-535320425350}" -m filedb -c eksffa ; echo $? usb_set_debug: Setting debugging level to 3 (on) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_busses: Found /dev/usb3 usb_os_find_busses: Found /dev/usb4 usb_os_find_devices: Found /dev/ugen1 on /dev/usb2 usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000 usb_control_msg: 128 6 512 0 0x8058a80 39 1000 usb_os_find_devices: Found /dev/ugen0 on /dev/usb4 usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000 usb_control_msg: 128 6 512 0 0x8055200 396 1000 skipping descriptor 0xB skipped 1 class/vendor specific endpoint descriptors skipped 5 class/vendor specific interface descriptors skipping descriptor 0x25 skipped 1 class/vendor specific endpoint descriptors skipped 7 class/vendor specific interface descriptors usb_control_msg: 64 12 256 1024 0xbfbfdf80 1 100 usb_os_close: closing endpoint 14 usb_os_close: closing endpoint 15 bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350} And debugging on /var/log/messages shows: Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc8ef0220, pipe=0xc5ee2000 len=10 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000 edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bb5920, pipe=0xc5ee2000 len=20 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000 edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bb3720, pipe=0xc5ee2000 len=10 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000 edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bc0320, pipe=0xc5ee2000 len=36 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000 edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000 Jun 23 09:40:01 claire kernel: usb_cdev_close: closed Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6b5d520, pipe=0xc5ee9800 len=10 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee9800 edesc=0xc5ee9c3f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee9800 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6b58b20, pipe=0xc5ee9800 len=20 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee9800 edesc=0xc5ee9c3f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee9800 Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bba720, pipe=0xc5ee9800 len=10 dir=out Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee9800 edesc=0xc5ee9c3f isoc_next=0 toggle_next=0 bEndpointAddress =0x00 Seems that "start hardware" happened, at least.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?467D1553.7060808>