interrupt storm on current andy-tracking

Andy Green andy at
Thu Dec 11 18:08:28 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Somebody in the thread at some point said:
| | Hello,
| |
| | current andy-tracking (c59a8bdc7ca4b5470ebc43dfc31ed1d3d23a7c6f) seems
| | to cause an interrupt storm for input2/3. Such that the system gets dead
| | slow and the syslog filled with input event debugs.
| |
| | 9402b27b2a497f8eeb72f6fe1045f2c5be800fe2 works fine.
| |
| | Any idea?
| I guess it can be to do with the level interrupt processing change from
| Balaji, or the GPIO fixes from Werner between those two?  Or maybe it is
| config changes from me if this is that dumb input event debugging thing
| come back again.
| Can you show what the system input event things look like?  I don't
| think we need an "interrupt storm" to explain the system being slow if
| in fact we're spewing 200 input event debugs a second to syslog.

That'll be it I think...


It made trouble before that some rootfs will insert this module if it
exists and then it spews for every service of 2 x 100Hz motion sensors.
~ I'll remove it from the configs, it got introduced again here;a=commitdiff;h=201609904fb54abb87c9c30856a432d89567917c

Thanks for the report, it's real nice getting the last working hash as
well :-)

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list