WSOD (ticket #1841) (unofficial) survey question

[grslmpf]

Andy Green wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> 
> | I am also affected by the WSOD and read many about it.
> | So I try several things and figured out that WSOD is gone if I keep the
> | freerunner over 30°C AND suspend it by the power button.
> 
> The high incidence of WSOD on some devices started when we added
> Harald's nice powersaving patches.  These turn off video clocks during
> framebuffer blanking.  So it makes sense you avoid that fallout by using
> power button suspend rather than waiting for some timeout that the
> framebuffer blanking gets to first.
> 
> Not all devices show the symptom, whether through their local
> temperature or some other private state.  Harald doesn't see the WSOD on
> his device and when he spent some time looking at one which does show
> the problem he wasn't able to crack it in the limited time available to
> him.
> 
> | If I dont switch of dimming and automatic suspend - everytime the WSOD
> will
> | appear.
> | I can imagine this happens because some kind of signal levels are to
> close
> | at their specifications. Digital IO seems to work whole time but what
> about
> | RST?
> | Part R1813 & R1814 seems to be used as "level shifter" (from 3,3V to
> Glamos
> | 1,8V?) at RST#.
> | Such kind of "level shifter" are little bit problematic - poor
> performance
> | and bad timing. If the RST could not raised fast enough - mayby the
> glamo
> | sucks.
> | If i had the datasheet i would dive into this point...
> 

So we have two kinds of WSOD - one caused by the patches and the other one
because ?

I think the powersaving WSOD isn't realy the problem - it isn't
temperature-dependent, it will always be there.
But the other one _only_ occurs below some temperatur level.



> That "level shifter" is definitely evil, if you pop the can and touch it
> with a scope probe it hard resets the Glamo, as you would expect with
> such high source impedence.  Other things seem to be able to make spikes
> on it too somehow.  But to be fair to it I never saw it make a failure
> in normal operation, only during suspend / resume time.
> 

I am creating/programm for years yC based designs and not long ago I've seen
some similar thing.
The schematic worked perfect and sometimes only partly.  I thought little
gremlins must be in there - but the result was only two resistors wich
drives some parts to close to their specifications.



> In stable-tracking we work around this by always hard resetting the
> Glamo on resume ourselves on the basis there can have been an
> uncontrolled reset in the meanwhile.
> 
> Stable-tracking has a related problem on resume I will be looking into
> this week, the GPIO on the Glamo don't seem to operate properly after
> resume, although it is issuing video again nicely and the SD Card is
> working fine through it.  It's possible this is behind the problems with
> the framebuffer blanking WSOD.
> 
> Mayby the Glamo will work only partly caused by a bad reset?  
> 
> - -Andy
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkkYLJUACgkQOjLpvpq7dMr46gCdH+hE8eYsQihdN3M7vCNfqkPO
> VEUAoIpqYW/HUdNMgqSF8BflBUqgx1L8
> =flSO
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 
> 

-- 
View this message in context: http://n2.nabble.com/WSOD-%28ticket--1841%29-%28unofficial%29-survey-question-tp1476924p1493227.html
Sent from the Openmoko Community mailing list archive at Nabble.com.