Hi,
We have custom board that using TI USB Hub and Fingerprint module don’t working sometime.
I see error log below:
Dec 29 10:04:13 vsm kernel: [ 1.810113] usb 1-2.1: new high-speed USB device number 3 using tegra-xusb
Dec 29 10:04:13 vsm kernel: [ 1.831417] usb 1-2.1: New USB device found, idVendor=1b55, idProduct=0120
Dec 29 10:04:13 vsm kernel: [ 1.831422] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 29 10:04:13 vsm kernel: [ 1.831425] usb 1-2.1: Product: SLK20R
Dec 29 10:04:13 vsm kernel: [ 1.831428] usb 1-2.1: Manufacturer: ZKTeco Inc.
Dec 29 10:04:13 vsm kernel: [ 1.831431] usb 1-2.1: SerialNumber: 4251212160002
…
Dec 29 10:04:35 vsm kernel: [ 25.178262] usb 1-2.1: reset high-speed USB device number 3 using tegra-xusb
Dec 29 10:04:35 vsm startx[3512]: [10:04:35.101][4636][ZkSLK20R::init:97] init m_zkfinger10 failed!
Could you please give me suggestion for checking this issue?
Thanks!
Full log attached:
syslog_IP106 211229.rar (5.7 MB)
Don’t know anything about this hardware, but it looks like USB was ok, and only the reader failed. The log basically shows a lot of network errors. I can’t be sure, but if the reader has anything to do with networking, then that might be the cause.
Some “/proc” files were also missing, which might mean the reader is looking for kernel features which don’t exist. It might also mean a customized kernel is at fault. About all I can suggest is that if you have any kind of kernel modification that you check that it was configured correctly (normally apps like NetworkManager won’t have any problems, but in this case it had a lot of errors).
Thanks linuxdev!
Could you please help me for explain error log?
usb 1-2.1: reset high-speed USB device number 3 using tegra-xusb
USB enumerates different devices in some order which is not guaranteed. Typically it will enumerate root HUBs in some order (which are integrated to the motherboard or module), and then within each root HUB it will enumerate devices in a “tree-like” fashion. Such devices are visible and named after either the enumeration order (which includes content which tells you which root HUB) or the device ID.
An example of seeing naming based on slot is “lsusb -t”. An example showing ID (which is basically “manufacturerID:deviceID” is from “lsusb” showing the “ID”. For plain “lsusb” the “Bus” is the root HUB enumeration, and the “Device” is the slot for that HUB. “Device” number can change, typically “Bus” will remain constant.
A reset is typically the act of enumeration running. This does not mean anything will be found, but it does say USB was looking for devices on a root HUB. USB will typically re-enumerate whenever a new device is detected while running, or when first starting.
A device reset is not an error of USB. However, if devices being detected have errors, and in some way that device is rejected, but then enumeration sees this again (in an infinite loop), then this would be an error. More common is to see bad signals which sometimes work but sometimes do not, and then there will be random resets of the USB devices at unexpected moments (which causes a re-enumeration).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.