Hi Alan Thanks for your reply! > > I have some stange errors on a arm pcm043 with internal usb phy. The log > > is attached at the end of the mail. It would be nice if someone could > > give me a pointer whats going wrong?. It would also be nice to know > > where the status flags which are output by the usb debug messages are > > documented? <snip> > > As it might be a hw problem i would like to activate the testmodes of the > > ehci controller. The old Freescale BSP driver had a file in debugfs > > where enabling this stuff was easy. Is there also an easy way to enable > > the ehci debug facility from linux usermode? > > No. You will have to write a program to send a > Set-Port-Feature(PORT_TEST) request to the root hub. Or patch the > kernel to add a debugfs file like the BSP driver had. Ok, so i can instruct the root hub via usermode to go into test mode. So its possible from usermode as far as i see but not from shell directly? > > hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 > > mxc-ehci mxc-ehci.0: GetStatus port:1 status c00100a 6 ACK POWER sig=se0 Is there anything strang with this status code ^^^^^^^ ? This is where the trouble begins. > > PEC CSC > > hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s > > usb 1-1: USB disconnect, device number 23 > > usb 1-1: unregistering device > > usb 1-1: unregistering interface 1-1:1.0 > > usb-storage: storage_disconnect() called > > usb-storage: -- usb_stor_release_resources > > usb-storage: -- sending exit command to thread > > usb-storage: *** thread awakened. > > usb-storage: -- exiting > > usb-storage: -- dissociate_dev > > usb 1-1: usb_disable_device nuking all URBs > > These messages mean there was a disconnect. Assuming you didn't unplug > the cable, some signal made the controller or phy think it was > unplugged. Well, it is unconnecting then out of the blue, randomly very seldom without any good reason... > Possibly the event was connected with Link Power Management. You might > want to try disabling LPM for that port (write "disable 1" to the "lpm" > file in the EHCI debugging directory). > > > mxc-ehci mxc-ehci.0: GetStatus port:1 status 001803 0 ACK POWER sig=j > > CSC CONNECT > > hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 > > mxc-ehci mxc-ehci.0: port 1 high speed > > mxc-ehci mxc-ehci.0: GetStatus port:1 status 8001205 4 ACK POWER sig=se0 > > LPM PE CONNECT > > usb 1-1: new high-speed USB device number 24 using mxc-ehci > > mxc-ehci mxc-ehci.0: detected XactErr len 0/8 retry 1 > > ... > > > mxc-ehci mxc-ehci.0: devpath 1 ep0in 3strikes > > These messages mean that there was a low-level communication error. > The controller did not receive a response from the device. > > > mxc-ehci mxc-ehci.0: GetStatus port:1 status c00100a 6 ACK POWER sig=se0 > > PEC CSC > > The "c00100a" bits are explained in Table 2-16 of the EHCI spec and the > EHCI-1.1 addendum. The other fields are merely symbolic names for the bits > in the status value. Ah ok this is the status field i was talking about. The device is an USB stick doing file operations. So right after the disconnect the stick is not answering, but later it is working again. So after the disconnect the stick probably needs some time to reset? > > hub 1-0:1.0: unable to enumerate USB device on port 1 > > hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 > > "state 7" means the root hub is in the Configured state. "evt 0002" > means an event has occurred on port 1. These values are not documented > anywhere because they are used only for debugging the kernel. Ok but they are deferred from the flags if i understand the sourcecode correctly? Best regards Tim -- 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
