[PATCH 3/3] fix-stop-sitting-printing-in-time-critical-context.patch

[Andy Green]

-----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-----