WSOD (ticket #1841) (unofficial) survey question
nabble_openmoko at geheimbilder.de
Thu Nov 13 09:14:01 CET 2008
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
> | If I dont switch of dimming and automatic suspend - everytime the WSOD
> | appear.
> | I can imagine this happens because some kind of signal levels are to
> | at their specifications. Digital IO seems to work whole time but what
> | RST?
> | Part R1813 & R1814 seems to be used as "level shifter" (from 3,3V to
> | 1,8V?) at RST#.
> | Such kind of "level shifter" are little bit problematic - poor
> | and bad timing. If the RST could not raised fast enough - mayby the
> | 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
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
> -----END PGP SIGNATURE-----
> Openmoko community mailing list
> community at lists.openmoko.org
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.
More information about the community