-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Wed, Aug 27, 2008 at 09:03:08AM -0300, Cesar Eduardo Barros wrote: |> Andy Green escreveu: |>> No, one doesn't expect the hardware USB unit to go insane until the |>> device is reset because we were a little delayed servicing its |>> interrupt! I guess the same can happen in Linux if there was ever long |>> service time ISR with higher priority that pushed out this one's latency. |> Wait... THAT would explain why the USB gets stuck on cpufreq if it is in |> use during a frequency transition, but only if it is in use. The cpufreq |> frequency switch pauses the clock for the whole device for many clocks, |> while waiting for the PLL to recover. That's more than enough to cause a |> very high interrupt latency. | | maybe, but the routines in question are only used during control point | transfers, specifically device enumeration. Endpoint 0 works completely | different from the actual bulk/irq endpoints used during transfers.
If you have a scope Cesar you can tell really easily, just look at the USB D+ / D- pins and they will be spamming away like crazy if the hardware fell down that hole. Normally they just have a little pip at 1ms interval and are idle the whole rest of the time. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki1b4EACgkQOjLpvpq7dMoCAACghZ89R1Mb/M3uB1nZGJ4vxElg cTUAnR75crsH0nULKJYlmdxsuoutcomJ =bFMy -----END PGP SIGNATURE-----
