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 #1024: gsm modem oscillating between
registrated / not-registrated (Openmoko Public Trac)
2. Re: Openmoko Bug #2043: GTA02 WiFi signal reception too weak
(Openmoko Public Trac)
3. Re: Openmoko Bug #1716: [Package] add .edj
decompiler/compiler as a package (Openmoko Public Trac)
4. Re: Openmoko Bug #2043: GTA02 WiFi signal reception too weak
(Openmoko Public Trac)
5. Re: Openmoko Bug #1024: gsm modem oscillating between
registrated / not-registrated (Openmoko Public Trac)
6. Re: Openmoko Bug #2048: SMS messages are not received until
after a reboot. (Openmoko Public Trac)
7. Re: Openmoko Bug #1691: [Qtopia] qpe crash happened after
flash the new image (Openmoko Public Trac)
8. Re: Openmoko Bug #1562: 12 hour time format does not work
(Openmoko Public Trac)
--- Begin Message ---
#1024: gsm modem oscillating between registrated / not-registrated
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: sean_chiang
Type: defect | Status: assigned
Priority: high | Milestone:
Component: gsmd | Version: unspecified
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by [EMAIL PROTECTED]):
Disabling the GSM from entering "deep sleep" will stop this oscillation:
{{{
AT%SLEEP=2
}}}
The problem is related to the GSM's deep sleep mode. It seems that in
certain circumstances (I'm guessing on that, for me it is *all*
circumstances), the GSM experiences some sort of trouble when it is
permitted to enter deep sleep (which is the default mode, at least for any
recent GSM firmwares). Whatever trouble it encounters results in it
losing registration, regaining registration, entering this bad state after
a time. This is consistent with the data gathered by myself and several
other volunteers (thanks for your logs to those who helped!) -- the
frequency of the oscillation or bouncing is very consistent and usually at
a frequency of between 2 and 3 oscillations per minute.
The calypso is remarkably similar, at least from an AT command set point
of view, to a device called the "Enabler II" by Enfora. Documentation for
the latter is available on the Internet, unlike the calypso. The Enabler
supports sleep modes, and while the calypso does not list the AT%SLEEP
command, nor respond to query attempts using the AT%SLEEP? or AT%SLEEP=?
commands, it turns out that it does honor the actual setting of sleep
modes. See the Enfora document for details, and remember that we (the
community) do not know how closely this really maps to the calypso.
Using the AT%SLEEP=n command, when n=3 or n=4 the calypso bounces.
When n=0, n=1, or n=2, the bouncing ceases. Changing the sleep value will
result in immediate cessation or resumption of the bouncing behavior.
For currently unknown reasons not reproducible by hand, the Qtopia 4.3.2
firmware image (on a Neo with Moko 5 GSM firmware) displays this bouncing
behavior until a call is either placed or received. At that point, the
device behaves exactly as expected, until the GSM is reset. Exactly why
this is the case is not known; either something "fixes" whatever is broken
and allows the device to enter deep sleep, or something about this
sequence disables deep sleep. If we can figure out which of the two it
is, perhaps that might help in tracking the firmware issue down further.
As for what to do about this -- perhaps someone at Om can take a look at
the firmware and see what affects the deep sleep modes.
In the meantime, I'm working on a patch for Qt Extended (aka Qtopia 4.4.1)
that will detect the bouncing behavior and automatically change the sleep
mode when necessary. This will permit those who can actually enter deep
sleep to use that mode, while those who cannot will be no worse off in
terms of power consumption (the bouncing calypso isn't in any kind of
sleep mode) and will be better off in that they can at least use the GSM.
Other solutions or workarounds are welcome! Patches and other information
are on http://moko.mwester.net/brc.html
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1024#comment:43>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2043: GTA02 WiFi signal reception too weak
------------------------+---------------------------------------------------
Reporter: vnevoa | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by vnevoa):
Why isn't there any update on this bug? Do you need more info?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2043#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1716: [Package] add .edj decompiler/compiler as a package
-----------------------------+----------------------------------------------
Reporter: will | Owner: julian
Type: task | Status: in_testing
Priority: high | Milestone: Om2008.10
Component: Distro | Version:
Severity: critical | Resolution:
Keywords: edje package | Blockedby:
Reproducible: | Blocking:
-----------------------------+----------------------------------------------
Changes (by julian_chu):
* status: assigned => in_testing
Comment:
the problem came from missing some modules.
you can install them by this command
$opkg install libevas-saver-jpeg libevas-saver-png
I had did a test on my own neo phone, it works.
{{{
[EMAIL PROTECTED]:/var/volatile/tmp/test# edje_decc illume.edj
Output Image: illume/bd_button_close_shadow.png
Output Image: illume/bd_button_close_focused.png
Output Image: illume/bd_button_close_unfocused.png
( blah blah...)
Output Build Script: illume/build.sh
*** CAUTION ***
Please check the build script for anything malicious before running it!
}}}
I add those modules as recommends into edje-util packages in this commit:
[http://git.openmoko.org/?p=openmoko.git;a=commit;h=25a1910a6e4b0101c4502fff5fd77d1abebcb8f9
25a1910a6e4b0101c4502fff5fd77d1abebcb8f9 ]
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1716#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2043: GTA02 WiFi signal reception too weak
------------------------+---------------------------------------------------
Reporter: vnevoa | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by werner):
Just spotted it today :-) I don't really know if our WLAN performs much
worse than one could expect. Since wireless results tend to be quite
variable and often open to interpretation, I'd suggest to discuss the
issue on a proper mailing list. I've started a thread here:
http://lists.openmoko.org/pipermail/hardware/2008-October/000693.html
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2043#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1024: gsm modem oscillating between registrated / not-registrated
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: sean_chiang
Type: defect | Status: assigned
Priority: high | Milestone:
Component: gsmd | Version: unspecified
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by Treviño):
Replying to [comment:43 [EMAIL PROTECTED]:
> In the meantime, I'm working on a patch for Qt Extended (aka Qtopia
4.4.1) that will detect the bouncing behavior and automatically change the
sleep mode when necessary. This will permit those who can actually enter
deep sleep to use that mode, while those who cannot will be no worse off
in terms of power consumption (the bouncing calypso isn't in any kind of
sleep mode) and will be better off in that they can at least use the GSM.
Other solutions or workarounds are welcome! Patches and other information
are on http://moko.mwester.net/brc.html
That brc patches are also working in the Om2008 isn't it?
I've not tested them yet but the code should be very similar (if not the
same).
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1024#comment:44>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2048: SMS messages are not received until after a reboot.
------------------------+---------------------------------------------------
Reporter: BillK | Owner: julian_chu
Type: defect | Status: closed
Priority: high | Milestone: Om2008.10
Component: unknown | Version: Om2008.8
Severity: major | Resolution: duplicate
Keywords: SMS | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Changes (by zecke):
* component: Qtopia => unknown
Comment:
@tick: Are you sure? I don't see any information I could base that on.
@BillK: Please see http://wiki.openmoko.org/wiki/Bug_Filing_Policy
specially the section on reporting GSM related issues. Send a SMS, it will
not show up, login, execute logread, simple...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2048#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1691: [Qtopia] qpe crash happened after flash the new image
---------------------------+------------------------------------------------
Reporter: wendy_hung | Owner: tick
Type: defect | Status: accepted
Priority: highest | Milestone: Om2008.10
Component: Qtopia | Version:
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------+------------------------------------------------
Comment(by zecke):
@tick: What about taking a look at the coredump first?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1691#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1562: 12 hour time format does not work
---------------------------+------------------------------------------------
Reporter: regina_kim | Owner: zecke
Type: defect | Status: in_testing
Priority: normal | Milestone: Om2008.10
Component: Qtopia | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------+------------------------------------------------
Changes (by zecke):
* status: reopened => in_testing
* component: E - Illume => Qtopia
Comment:
We decided to disable the time format in Qtopia for now. This should hit
testing either on Monday or on Tuesday.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1562#comment:10>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
