On Fri, 12 Oct 2012, Tim Sander wrote: > Hi Alan > > Thanks for your reply! You're welcome. > > > 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? That's right. Or rather, it will become possible from the shell directly once you have the appropriate program. > > > 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. No, nothing strange. It indicates a disconnect, nothing more. > > > 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... Maybe LPM is the 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). You ignored this statement. You should pay more attention to it; there's a very good chance that it explains your problem. > > 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? That's a strange way of looking at it. More to the point: There should not have been any disconnect in the first place. > > > 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? They are not _deferred_ from anything. They are _derived_ from the flags, in a rather indirect way. 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
