Openmoko Bug #2217: Noise screen of death: Freerunner looses SDIO connection

[Openmoko Public Trac]

#2217: Noise screen of death: Freerunner looses SDIO connection
-----------------------------+----------------------------------------------
 Reporter:  xbaldauf         |          Owner:  openmoko-kernel
     Type:  defect           |         Status:  new            
 Priority:  normal           |      Milestone:                 
Component:  System Software  |        Version:                 
 Severity:  major            |       Keywords:                 
 Haspatch:  0                |      Blockedby:                 
Estimated:                   |    Patchreview:                 
 Blocking:                   |   Reproducible:                 
-----------------------------+----------------------------------------------

Comment(by xbaldauf):

 Replying to [comment:21 andy]:
 > Replying to [comment:19 xbaldauf]:
 > > Replying to [comment:18 andy]:
 > > > Replying to [comment:16 xbaldauf]:
 > > > > Interestingly, however, it looks like that, by using
 glamo_mci.sd_max_clk=1000000, I can raise the probability of getting such
 a crash like above to 100%. The crash happens always at GSM-login-time.
 >
 > I wonder if we simply delay SD access enough that we still intensively
 use it by the time GSM stuff starts up.
 Well, by now, this conclusion was too fast. Up to now, I've managed to
 login 2 times without such a crash. Maybe the crash probability is
 dependent on a frequency between my device and the GSM tower, or something
 like this.
 >
 > > > To be clear, at the time of this "crash", you have the permanent
 noisy screen business?
 > >
 > > Sometimes, sometimes not. Sometimes the noisy screen is busy (e.g.
 updated), sometimes even normal redraws happen (so the noisy screen is
 overwritten with the correct content), and sometimes everything stops,
 including screen updates.
 >
 > Ah... that's something totally different than I understood until now.  I
 thought we were talking about a dynamic, jittering permanently changing
 full-display "snow" of noise on the display.  I have seen this many times
 when working with Glamo internal memory parameters.
 >
 > It would imply we crapped on the control registers by accident.
 >
 > But when you say the "noisy screen is overwritten with the correct
 content" it sounds instead like the bitmap placed there is wrong data, and
 later it might come and invalidate and redraw that area perfectly well.

 Yes. It looks like that, initially, the bug is transient in nature. It is
 just that severe that the damages done are persistent (until the next
 power cycle). Sometimes it may happen that I can continue working with the
 device, sometimes I can continue working with the device as long as there
 is no write access (because the filesystem was re-mounted read-only due to
 I/O errors, but the I/O errors are now gone), and sometimes I cannot
 continue at all (because of some crash, sometimes I see the red lights of
 the AUX button blinking fast, sometimes not). Being able to continue
 implies that the correct screen is redrawn (e.g. by changing the currently
 visible application, the screen is redrawn).

 >
 > > The triggering of the bug seems to be strongly GSM-related. AFAIK, it
 only happened when I login into the GSM network, place a phonecall or
 receive a phonecall or short message. Thus, when I have no GSM traffic for
 some hours or even days, the system seems to remain stable.
 >
 > I hope only some "lucky" devices can suffer from this or we would have
 heard about it long before.

 So you are suggesting a hardware failure...? I've never experienced this
 bug under kernel 2.6.24 AFAIK.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:22>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac