Accelerometers jerky with new stable kernels?

Andy Green andy at
Fri Nov 7 09:56:34 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Timo Jyrinki wrote:
|> 2008/11/6 Michael Zanetti <michael_zanetti at>:
|>> What do you mean with "working fine now"? Are they working as they
were always
|>> or are they now really working (no crashes on suspend or after some
minutes of
|>> use)?
|> "Working fine" as in accelerometer using applications (I have
|> AccelGame and Doom) work, unlike with the patch (jerkiness). I don't
|> use suspend with my own kernels since resume is always broken -
|> probably because I only flash the self-compiled kernel and don't know
|> how I could easily also copy the compiled modules into use on Neo.
| Using this reverting list [1] to get a woking stable kernel (image [2]).
| With itthe accelerometers work well also after suspend/resume (that
| works here, since it seems needed to the
| fix-glamo-mci-slow-clock-until-first-bulk.patch as reported in the
| kernel ML).
| I'm using my moko with OpenDoom in these days and all is completely

It's great you found some suspend stability, but on 2.6.24 / stable
there is zero doubt it is purely random chance build by build.  I would
guess that's why you can 'tune' stability by just removing patches that
affect the resume race by timing, even though the patches themselves
have no direct impact on suspend otherwise.  I found I could make or
break a 2.6.24 kernel for suspend merely by adding printk()s around.

Real solution is coming closer in stable-tracking for these problems
hopefully, although right now accel comms is completely broken in there.
~ But it should be straight in next couple of weeks kind of timeframe.

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


More information about the support mailing list