On Sunday 07 August 2005 20:59, Alan Stern wrote: > On Sun, 7 Aug 2005, Vlado Handziski wrote: > > > Hi Alan, > > > > Thanks for the pointers. Unfortunately, even with debugging on, I can not > > detect any connect-change event. As you can see above, after sending the > > command to turn-off the power of the port, the port status query does return > > "data 00 00 00 00", and it stays zero until I send a command to set the power > > back on. But although the status says that the power is off, the power is > > still on! > > Are you saying that after you turn off the port power, there are no > messages from the hub driver in the dmesg log? If so, then the hub driver > is not interfering in any way with what you're doing.
Yes, there are no messages generated in this case. > > Do you know how the port status reply is generated? I.e. Is the HW queried, or > > some cached values in the driver are used? It is as the commands > > that I am sending are never reaching the hub, but are effecting its software > > state. Is there a way to snoop on the complete USB traffic? > > The port status reply comes directly from the hardware. There are no > cached values and the hub driver doesn't see the interchange at all. You > can snoop the complete USB traffic using usbmon (see > Documentation/usb/usbmon.txt). Thx. I was not aware that there is a monitor for linux available. I will recompile with monitoring enabled and see if there is something strange going on. > > Funnily, if I send the same command as above, but to the host controller to > > which the hub is connected, the hub powers down all ports for couple of > > seconds, before the driver detects too many -71 errors and the reset logic > > re-powers the hub. > > Isn't that what you would expect? The hub driver is no longer able to > communicate with the external hub (because the port power is off). After > enough errors, the hub driver tries to reset the external hub. The reset > fails, so the hub driver does a "logical disconnect". This causes power > to be restored to the root hub port, and then the external hub is > rediscovered. Yes, it is completely logical. I just mentioned this as it shows that the hub ports do shut down under some circumstances and since this was the second divergence from the behavior we were seeing with the old setup. > > I am still completely at a loss why my commands for turning-off the power of > > the hub-ports are not working. I have also tried to first put the port into > > suspend, but nothing changed. I would be thankfull for any hints how to > > proceed with the debugging. > > Is it possible that something funny is going on with the hub's firmware? > If the hub reports that port power is off when in fact it isn't... Well, > that is legal under some circumstances (power-ganging schemes). But it > shouldn't be happening with your hubs. Hmm. Now that you mention it, in our new setup some of the hubs do have a newer firmware (DUBH4E..B2 instead of DUBH4E..A1). But the hub driver properly reports this as a hub with individual port power controls, so I don't see any reason why it should not work as expected. Anyhow, thanks a lot for your help. I will see how far I can get with the monitoring and I will definitely try out using a hub with older firmware once I get back to work tomorrow. Best regards, Vlado Handziski ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
