Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #1841: white screen of death (WSOD) after
resume (Openmoko Public Trac)
2. Re: Openmoko Bug #1841: white screen of death (WSOD) after
resume (Openmoko Public Trac)
3. Re: Openmoko Bug #2166: USB keyboard breaks after suspend.
(Openmoko Public Trac)
4. Re: Openmoko Bug #1489: sometimes volume is too low during a
call (Openmoko Public Trac)
5. Re: Openmoko Bug #2140: Should use different volumes for
ringtone and receiver (Openmoko Public Trac)
6. Re: Openmoko Bug #2144: [location]unable to see the last item
in list after scrolling to the bottom (Openmoko Public Trac)
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
-----------------------+----------------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Keywords: wsod,resume
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------+----------------------------------------------------
Comment(by joerg):
Results of our tests so far:
first we found two devices to show WSOD relatively frequent and
reproduceably:
#51 from https://docs.openmoko.org/trac/ticket/1621
and a A7 PP model.
We verified temperature dependency, by warming up whole device (-> no
WSOD),
then cooling down LCM while keeping rest of device in warmed up state ->
WSOD
on first try.
We applied the no_deep_suspend patch to recent stable branch 2.6.24, and
we
found (on #51) it reduces probability of WSOD but won't fix it. There are
other reports [http://docs.openmoko.org/trac/ticket/2115] of WSOD not
being
dependent on going to deep_suspend mode at all (and thus this patch
shouldn't
be able to help there).
Seems deep_suspend can trigger WSOD very easily, but WSOD has some
different
operation scheme than exactly something going wrong during deep_suspend or
resume from that.
WSOD is dependent on time the device is suspended, i.e. it seems like it
takes
quite a few minutes sometimes until suspend triggers WSOD. This seems
somewhat paradox regarding paragraph above.
We patched JBT6K74.c driver to increase existing mdelay() and inserting
new
ones on every reasonable point of communication-flow, and even lowered
GLAMO-SPI clockfrequency, to make LCM feel quite comfortable with any
aspect
of timing regarding the control-communication. Result: none. Randomness of
WSOD seems unchanged.
We added printk() and created logs of a consecutive resume-ok, and a
resume-WSOD following immediately. On comparing both sequences we didn't
notice any significant difference, neither in sequence of function calls
nor
in timing.
We had 2 or 3 times a complete refusal of #51 to produce WSOD. After
taking
out battery for 10min it was back to normal (means 95% immediate WSOD
after
20sec suspend)
We swapped LCM of #51 with the one of a known good device. Result: 40
suspend/resume, as well as placing #51 with new LCM to the fridge for
30min
and then resuming, didn't show any WSOD.
We attached #51-LCM to a known-good device, and it didn't show WSOD on 6
cycles. So obviously the issue isn't located on the LCM entirely.
We never seen any WSOD recovering on subsequent suspend/resume cycles. It
always needed a reboot to recover. *)
So far we didn't see a single WSOD on boot.
So we are wondering what's the difference between
a) switching LCM power down via LDO6, while keeping *all* lines to LCM at
low
(to stop reverse powering by sneak currents, and not to violate JBT6K74
electrical specs), then power up and reset
~and
b) a usual boot bringing up LCM in sane state
Maybe that's pure incidence we never seen a WSOD on boot so far?
*) Further results:
we attached debug-board and resetted the device to reboot without power-
down:
WSOD recovered.
We probed for the signals on LCM-FPC by using a GTA03-debugboard (task not
completed yet): With an old image and kernel (2008.08) there was 3.2V for
powersupply and some of the datalines. We didn't find differences in
probed
signals between WSOD and clear display.
We didn't see a LCM-RESET on resume though.
By messing around with probing the signals, we got a recover from WSOD
once,
but it wasn't reproduceable and only *might* be connected with shorting
reset
to GND.
Removing a WSODed LCM from device during suspend, then reconnecting it,
then
resume: WSOD recovered at least on second resume after that (first one
probably got some confusion by reconnecting FPC made not a nice switch and
some bounces on the lines and wrong sequences for power-up).
First resume LCM usually faded from white to black.
Conclusion: root cause of WSOD is some 'analog' thing depending on LCM and
device. We can not provide a good clue to nature of the issue.
By first(! Vio <= VDD) switching all glamo->lcm IO's to 0V/high-Z, then
disabling LDO6 for suspend, and on resume first powering up device via
LDO6
and then initializing it (incl. activating glamo interface), we should
achieve to get zero power-consumption during suspend for LCM, and be able
to
recover/avoid WSOD.
As Andy is much more savvy in meddling the kernel space, and
LDO6-switchoff is
announced by him anyway, we didn't try to implement this plus the needed
glamo-lines-pulldown here in TPE.
jOERG
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841#comment:119>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
-----------------------+----------------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Keywords: wsod,resume
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------+----------------------------------------------------
Comment(by andy):
> There are other reports http://docs.openmoko.org/trac/ticket/2115 of
> WSOD not being dependent on going to deep_suspend mode at all
> (and thus this patch shouldn't be able to help there).
No Harald's patches did in fact push the LCM in deep suspend on
framebuffer blanking:
http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=f9e5eb98527feda1937f87d93a5b6dd6322baf83;hp=0e7b63e010904140cc39fe98a5d8abd3de7e4f0f
+ case FB_BLANK_POWERDOWN:
+ jbt6k74_enter_state(jbt, JBT_STATE_DEEP_STANDBY);
+ break;
and the report is from before Nicolas' patch, but after Harald's stuff, so
that bug is not evidence of WSOD without deep sleep on jbt6k74 I think you
find. It is expected Nicolas' patch solves that bug report too.
While there are no further reports of WSOD from several people running
just Nicolas' fix, and they definitely had devices that were prone to it,
I would suspect a WSOD you observed can be something else, maybe related
to stable branch suspend / resume.
For example if stable branch resume fails with backlight up but Glamo /
LCM resume not having happened for unrelated reasons (since stable suspend
/ resume is known to be busted by potential races). But I didn't read yet
about "occasional" or "rare" WSOD from testers of Nicolas' patch, but that
it was completely gone.
If you're interested to go further into that, an idea would be not to use
suspend but to reduce the framebuffer blanking timeout to a few seconds
and repeatedly tap the touchscreen to keep bringing it back and see if you
ever get a WSOD (using Nicolas' patches).
On andy-tracking we already hard-reset the Glamo on resume, and I never
ever saw a sticky WSOD by using reset button on debug board: in both cases
there is no power cycling just hard reset. So I don't think zeroing the
Glamo LCM bus is involved in WSOD avoidance, but it can make sense on
leakage grounds during suspend.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841#comment:120>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2166: USB keyboard breaks after suspend.
----------------------+-----------------------------------------------------
Reporter: lysgaard | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords: usb keyboard suspend resume
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
----------------------+-----------------------------------------------------
Comment(by iknowjoseph):
I've suffered this problem too. Although lsusb seems to fix it. Running
this after a suspend operation would not enable a usb keyboard to work:
ifconfig usb0 down
echo "host" > /sys/devices/platform/s3c2410-ohci/usb_mode
echo "1" > /sys/devices/platform/neo1973-pm-host.0/hostmode
echo USB-Port is in host-mode now.
but this would:
ifconfig usb0 down
echo "host" > /sys/devices/platform/s3c2410-ohci/usb_mode
echo "1" > /sys/devices/platform/neo1973-pm-host.0/hostmode
lsusb
echo USB-Port is in host-mode now.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2166#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1489: sometimes volume is too low during a call
---------------------------+------------------------------------------------
Reporter: regina_kim | Owner: tick
Type: defect | Status: closed
Priority: high | Milestone: Om2008.9
Component: hardware | Version:
Severity: critical | Resolution: fixed
Keywords: Om2008.11 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
---------------------------+------------------------------------------------
Changes (by wendy_hung):
* status: in_testing => closed
* resolution: => fixed
Comment:
tested with image below:
kernel:testing-om-gta02-20081210.uImage.bin
rootfs:openmoko-testing-om-gta02.rootfs.jffs2 (20081210)
The volume bar works now, this problem should solved.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1489#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2140: Should use different volumes for ringtone and receiver
--------------------------+-------------------------------------------------
Reporter: john_lee | Owner: tick
Type: defect | Status: closed
Priority: normal | Milestone:
Component: Qtopia | Version: Om2008.9-dev
Severity: normal | Resolution: fixed
Keywords: Om2008.11 | Haspatch: 1
Blockedby: | Estimated:
Patchreview: positive | Blocking:
Reproducible: always |
--------------------------+-------------------------------------------------
Changes (by wendy_hung):
* status: in_testing => closed
* resolution: => fixed
Comment:
tested with image below:
kernel:testing-om-gta02-20081210.uImage.bin
rootfs:openmoko-testing-om-gta02.rootfs.jffs2 (20081210)
Check it's fixed, thanks!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2140#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2144: [location]unable to see the last item in list after scrolling to the
bottom
--------------------------+-------------------------------------------------
Reporter: sushama | Owner: jeremy
Type: defect | Status: closed
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: Om2008.11 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
--------------------------+-------------------------------------------------
Changes (by wendy_hung):
* status: in_testing => closed
* resolution: => fixed
Comment:
Tested with the image below:
kernel:testing-om-gta02-20081210.uImage.bin
rootfs:openmoko-testing-om-gta02.rootfs.jffs2 (20081210)
the problem already been fixed.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2144#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
