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. [Bug 1289] PSC (power saving commands in muxer mode) seems to
be broken ([EMAIL PROTECTED])
2. [Bug 1289] PSC (power saving commands in muxer mode) seems to
be broken ([EMAIL PROTECTED])
3. [Bug 1268] Build fails because of glib & libogg dependencies
([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1289
------- Additional Comments From [EMAIL PROTECTED] 2008-03-28 05:57 -------
GSM 07.10 is pretty clear in this respect (5.4.7):
"""
If either TE or MS wishes to enter a low-power state a power saving control
command message is sent to the other station on the multiplexer control channel.
The station receiving the message will complete the transmission of any
frames in progress, report a busy or power-down condition to higher layers,
freeze all timers and transmit the power saving control response message. When
the station that initiated the power saving control message receives the
acknowledgement it is then free to enter the reduced-power state.
"""
Yes, the modem would have to send something before going to (deep) sleep, it
doesn't, a violation to the spec. But honestly I think this is no big deal. I
don't remember seeing this on Wavecom (well they use their own multiplexer
format) and Siemens modules.
"""
Either station may send a power saving control command requesting that the other
station enters a low power state. The responding station must acknowledge this
command with a power saving control response message but need not obey the
command to enter a low-power state. If no response is received the commanding
station may repeat the command but must first use the wake-up procedure.
"""
This is the GSM stack on the host requesting the modem to sleep, I have seen a
variation of this on Siemens multiplexers. From a small chat with Sean Chiang
the modem is doing its own (deep) sleep, so sending this message is not
necessary (from what I understand). E.g. even if the modem would not respond to
these PSC, I think I wouldn't say there is much to fix. An obvious spec
violation but if we save power I think it is fine.
You should file a separate bug on the losing of frame and failing resync? From
what I have heard from Sean Chiang, the modem will drop/lose the first bytes
sent to the uart after a deep sleep, this is a hardware shortcoming. This means
the modem receives a frame without the sync/start flag/byte, which is by
definition invalid. The question is: Will it resync properly? Will it resync at
some point? I will try to do some tests myself, but please file a separate bug
on this issue. I think it is the only one to research and fix.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1289
------- Additional Comments From [EMAIL PROTECTED] 2008-03-28 09:14 -------
you did not quote the most important part:
"""
Either station may initiate a wake-up from the reduced power state by
the transmission of the wake-up signal which consists of continuous
flag characters. When the other station receives the flag characters
it will wake-up (if necessary) and start sending flag characters. When
the first station receives these flag characters it will stop sending
flags and start transmitting the first frame. When the second station
detects a valid frame it stops sending flags. The stations unfreeze
their timers and continue operation as before.
"""
i can easily ignore that there are not 'i want to sleep' event and send
the wakeup flag as described above. but can i be shure that the modem
actually woke up when i don't get a response as the spec describes?
and if the modem really drops one byte in the uart when sleeping i would
not care as long as it is one of those flag-chars i send. but some
negotiation that the modem really woke up is required i think.
btw: the timeout T3 for this procedure is 10sec which is a long time
when i.e. transmitting ppp packages...
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1268
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From [EMAIL PROTECTED] 2008-03-28 11:05 -------
the current pair of glib-2.0 and libogg is
PREFERRED_VERSION_glib-2.0 ?= "2.14.1"
PREFERRED_VERSION_libogg ?= "1.1"
in angstrom-2007-for-openmoko-versions.inc
and I cannot find the libogg >= 1.1.3 dependency you mentioned in
org.openmoko.dev branch. could you update the branch and check your local.conf.
If the problem still exists please kindly reopen.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
