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. Your Bugzilla buglist needs attention. ([EMAIL PROTECTED])
2. [Bug 1376] New: GSM does not respond to flow control
([EMAIL PROTECTED])
--- Begin Message ---
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugzilla.openmoko.org/cgi-bin/bugzilla/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at them, and
decide on an initial action.
Generally, this means one of three things:
(1) You decide this bug is really quick to deal with (like, it's INVALID),
and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to someone
else. (Hint: if you don't know who to reassign it to, make sure that
the Component field seems reasonable, and then use the "Reassign bug to
owner of selected component" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
Just use the "Accept bug" command.
To get a list of all NEW bugs, you can use this URL (bookmark it if you like!):
http://bugzilla.openmoko.org/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL
PROTECTED]
Or, you can use the general query page, at
http://bugzilla.openmoko.org/cgi-bin/bugzilla/query.cgi.
Appended below are the individual URLs to get to all of your NEW bugs that
haven't been touched for a week or more.
You will get this message once a day until you've dealt with these bugs!
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1012
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1081
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1107
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1127
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1133
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1136
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1158
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1162
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1189
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1193
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1197
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1199
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1200
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1201
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1206
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1212
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1215
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1216
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1217
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1218
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1276
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1292
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1376
Summary: GSM does not respond to flow control
Product: Neo1973 Hardware
Version: GTA02v6
Platform: Neo1973
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P1
Component: GSM Modem
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [email protected]
The GSM does not respond to the hardware flow control signals in a timely
manner, resulting in occasional buffer overruns from the UART, and associated
data loss. This happens most often when the GTA0x is brought out of suspend
mode due to incoming call or SMS, with the result being that the call or SMS is
missed.
Specifics of the test setup, remediation attempts, and other information will be
happily shared with whomever is assigned to work on this bug.
Briefly, the easiest way to observe this is to have the GSM flow-controlled
during a suspend, then wake the device by sending it an SMS or a call. You'll
observe a buffer overrun approximately 1 out of 10 attempts by default,
depending on timing issues and the length of the message that caused the wakeup.
By changing the point at which the UART interrupts the host CPU from the default
1/2 full to 3/4 full, the problem becomes almost a certainty, with better than 2
out of 3 probability that a buffer overrun will occur.
The UART hardware will signal to flow-control the GSM when the GTA01 UART FIFO
reaches 14 characters deep (it has 16 slots). We can assume that the hardware
does not signal this until after the 14th character is complete, and therefore
it is logical to assume that the GSM will transmit the 15th character before it
can respond to the flow-control -- this would allow one full character time
extra headroom. However, looking at the dumps of the buffers when this overrun
occurs, it does not appear that the overrun is by some small, constant number of
characters (which might indicate a timing issue in the GSM or perhaps the
hardware between it and the host UART). Instead all remaining characters in the
message being transmitted are lost, regardless of the length of the message. In
other words, the behavior is consistent with a GSM that only checks for
flow-control _before sending an entire message_.
Regardless of the cause, the fact is that the GSM does not honor flow-control in
the way it should, which has been proven to cause data-loss on the GTA01, and
based on observed behavior is likely to cause data-loss on the GTA02 as well.
------- 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
