On Dec 30, 2010, at 13:10 , Neil Jerram wrote:

> Thomas Zimmermann <m...@vdm-design.de> writes:
> 
>> Am Donnerstag 30 Dezember 2010, 11:13:17 schrieb Neil Jerram:
>>> 
>>> FWIW, I suspect my phone has a particular fault that makes freezes more
>>> prevalent for me than for others.  It's something I've experienced very
>>> regularly whenever using the glamo driver, on many previous
>>> distributions as well as the latest SHR-T.  I don't recall anyone else
>>> ever reporting this with a similar prevalence.
>>> 
>>> Also, thanks for your report on the phone function.  I had only made a
>>> few short calls to myself to check the audio quality (which was fine).
>>> 
>>>     Neil
>> 
>> Please send me the logs, so that i can have a closer look at it, best would 
>> be 
>> logs with loglevel debug.
> 
> What logs would you like?  Please note that when the freeze occurs, I
> can't get into the system in any way (i.e. SSH over Wifi or USB), so the
> logs would need to be something that is still there after a reboot.

I *think* I experience the same thing but mostly when I run my (unstable) SHR 
on the SD card (when I boot from the SHR testing on NAND freezes are highly 
unlikely mostly b/c the SD card is rarely used, just my guess).

Usually the system is not usable anymore if that "freeze" occurs: sometimes the 
system is just horribly slow, the mouse pointer (when enabled) jumps around 
with a delay. If I have a shell open per SSH I can usually not run any 
applications that access the SD card or /proc (or top, ps and friends, as well 
as logread).

However, once I was able to get logread to spit out some information:

Incident 1: Unstable on SD: Freerunner got slow, I think X cursor was 
flickering when touching screen:
> Nov 30 20:34:33 Freerunner user.err kernel: [   89.820000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:33 Freerunner user.err kernel: [   89.820000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:33 Freerunner user.err kernel: [   89.820000] [glamo-drm] Fence 
> seq#310 was not signalled
> Nov 30 20:34:34 Freerunner user.err kernel: [   90.820000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:34 Freerunner user.err kernel: [   90.820000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:34 Freerunner user.err kernel: [   90.820000] [glamo-drm] Fence 
> seq#311 was not signalled
> Nov 30 20:34:35 Freerunner user.err kernel: [   91.820000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:35 Freerunner user.err kernel: [   91.820000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:35 Freerunner user.err kernel: [   91.820000] [glamo-drm] Fence 
> seq#312 was not signalled
> Nov 30 20:34:40 Freerunner user.err kernel: [   96.360000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:40 Freerunner user.err kernel: [   96.360000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:40 Freerunner user.err kernel: [   96.360000] [glamo-drm] Fence 
> seq#455 was not signalled
> Nov 30 20:34:41 Freerunner user.err kernel: [   97.360000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:41 Freerunner user.err kernel: [   97.360000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:41 Freerunner user.err kernel: [   97.360000] [glamo-drm] Fence 
> seq#456 was not signalled
> Nov 30 20:34:42 Freerunner user.err kernel: [   98.360000] [glamo-drm] 
> Timeout!
> Nov 30 20:34:42 Freerunner user.err kernel: [   98.360000] [glamo-drm] 
> Attempting to recover...
> Nov 30 20:34:42 Freerunner user.err kernel: [   98.360000] [glamo-drm] Fence 
> seq#457 was not signalled

and so on...

Incident 2: after booting with a Qi with 4-4-4 timings into unstable on SD I 
switched to 2-4-2 timings using omhacks (maybe that is something one should 
never do b/c it can yield unexpected results?):
> Nov 30 20:48:03 Freerunner user.crit kernel: [  592.650000] Setting mode!
> Nov 30 20:48:03 Freerunner user.crit kernel: [  592.760000] Setting base!
> Nov 30 20:48:18 Freerunner user.crit kernel: [  608.000000] Setting base!
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] attempt to access 
> beyond end of device
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] mmcblk0p1: rw=0, 
> want=2152874536, limit=14680065
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] attempt to access 
> beyond end of device
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] mmcblk0p1: rw=0, 
> want=1109902816, limit=14680065
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] attempt to access 
> beyond end of device
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] mmcblk0p1: rw=0, 
> want=3302457432, limit=14680065
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] attempt to access 
> beyond end of device
> Nov 30 20:48:18 Freerunner user.info kernel: [  608.250000] mmcblk0p1: rw=0, 
> want=312722768, limit=14680065
and then some...

(The time stamps are actually correct, EDT)

Not sure if the two are related to each other. I usually don't have FS 
corruption on the SD card or at least it's not too bad for the journal to 
recover. I *once* had lost my partition table as it was reported a couple of 
times on this ML, though.

I had the feeling that the 2-4-2 timings were horribly unstable on my FR until 
the latest kernel, which seemed to improve the situation a lot.

A note on Neils comment:

> FWIW, I suspect my phone has a particular fault that makes freezes more
> prevalent for me than for others.

I'm not sure if that is entirely true. It seems that the circumstances that 
need to be present to trigger bugs seem to vary greatly. While I've now read a 
lot on this ML that WiFi seems works for most people it doesn't at all for me 
("sdio_ar6000 mmc1:0001:1: deviceInsertedHandler: -1", I guess it's this kernel 
bug: https://docs.openmoko.org/trac/ticket/2327; the suggested delay did not 
work anymore with 2.6.32, btw.)

Hope this wasn't too much noise ;-)
Dirk
_______________________________________________
Shr-User mailing list
Shr-User@lists.shr-project.org
http://lists.shr-project.org/mailman/listinfo/shr-user

Reply via email to