White Screen Of Death (gta02)

[Mike (mwester)]

Neat.  This problem has been observed by some; I've seen a few times.
However, the 2008.8 image seems to trigger it a lot more often -- and if
you add in the latest kernel and enable the flow-control of the GSM at
suspend, and if you have SIM installed, and you have left your suspend
timeout set to the very short default in that image, then you'll
probably trigger it within the first couple of minutes after boot.

Attached are two logs for fun reading; I'll work more on this in the
morning and any input would be appreciated.

You'll note that the two logs show that we never actually suspended --
GSM activity is going on right after boot, and when the image attempts
to suspend, the suspend handler in neo1973_pm_gsm.c catches the fact
that we had a GSM interrupt and aborts the suspend.  The first log has
no suspend debug, the second has the suspend debug messages enabled.

Reports earlier indicated that this problem was associated with GSM
activity as well; could it be that we have some race conditions or such
that require a certain amount of time to pass from suspend to resume?

Of particular note in the second log is the final stuff:

  soc-audio soc-audio: resume work completed
  JFFS2 notice: (1127) check_node_data: wrong data CRC in data node at
0x0a28c5dc: read 0xa766fee6, calculated 0xc1615797.
  modem wakeup interrupt

At this point, the display is blank, no buttons are responsive.  But one
can ssh into the device and poke about; it appears to be somewhat
running.  Attempting to suspend again by using the "apm -s" command
result in a "Device busy" error.  In the midst of this poking about, the
following message appears:

power_supply bat: driver failed to report `time_to_full_now' property

Shortly after that, I issues the "poweroff" command from the ssh
session.  Note that apm (or something) decided to suspend instead.  I've
seen that happen before as well; at that point one needs to pull the
battery to get it back.

Sooo...  if anyone wants to poke at this a bit, I rather suspect we'll
get some valuable hints if we try to deliberately abort any suspend
operation.  Edit the suspend handler in
/arc/arm/plat-sc324xx/neo1973_pm_gsm.c so that the suspend handler
always returns -EBUSY and see if the device properly resumes.

Mike (mwester)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: console_log_fail2
Url: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080808/300f1154/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: console_log_fail1
Url: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080808/300f1154/attachment-0001.txt