Hi,
"Michael 'Mickey' Lauer" <[EMAIL PROTECTED]> writes:
> Am Thursday 27 November 2008 22:48:31 schrieb Paul Fertser:
>> BTW, i get buggy (losing information from the modem) behaviour with it
>> today all day long. Especially i can't read phonebook cleanly. Killed
>> it and executed without -vvv flags and it's "stable" as it was
>> earlier. "It's getting curiouser and curiouser" indeed.
>
> Strange. Could that be http://docs.openmoko.org/trac/ticket/1435 by any
> chance?
No. I carefully analysed my debug log and here is my conclusion:
In gsm0710muxd a circular buffer for storing incoming data is
used. The macros (unneeded btw, as the same function most probably would
be inlined by the compiler automatically) to calculate the free space
is:
#define gsm0710_buffer_free(buf) ((buf->readp > buf->writep) ?
(buf->readp - buf->writep) : (GSM0710_BUFFER_SIZE -
(buf->writep-buf->readp)))
You see? If (buf->readp == buf->writep) we consider the buffer empty
and return the full size. But if we write GSM0710_BUFFER_SIZE bytes to
the buffer, we'll have (buf->readp == buf->writep) again.
In serial_device_read we have:
unsigned char buf[4096];
int len;
//input from serial port
LOG(LOG_DEBUG, "Serial Data");
int length;
if ((length = gsm0710_buffer_free(serial->in_buf)) > 0
&& (len = read(serial->fd, buf, min(length, sizeof(buf)))) > 0)
{
syslogdump("<s ", buf, len);
gsm0710_buffer_write(serial->in_buf, buf, len);
//extract and handle ready frames
if (extract_frames(serial->in_buf) > 0)
{
time(&serial->frame_receive_time); //get the
current time
serial->ping_number = 0;
}
}
When we see that a buffer is empty, we try to read()
GSM0710_BUFFER_SIZE bytes from the modem. Sometimes it's able to
deliver all that bytes (2048 as it is now) at once, especially when we
read the phonebook (and i think additional delays on verbose output
increase the probabality). And in my debug log i indeed see exactly
0x0800 bytes from syslogdump. All of which are then written to
the serial->in_buf, and lost in extract_frames, as it thinks that the
buffer is empty.
An excerpt from the log:
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:374:syslogdump(): <s 000007f0:
30 36 39 30 30 36 44 30-30 32 30 30 30 35 36 30 069006D002000560
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:870:gsm0710_buffer_write(): Enter
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:886:gsm0710_buffer_write(): Leave
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:1360:extract_frames(): Enter
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:1045:gsm0710_advanced_buffer_get_frame(): Enter
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:1474:extract_frames(): Leave
Nov 27 13:40:35 debian-gta02 /usr/sbin/gsm0710muxd[27748]:
gsm0710muxd.c:1577:serial_device_read(): Leave keep watching
Other log data perfectly corresponds to the fact that all 0x0800-sized
chunks are lost. And it explains the garbled entry (it's the beginning
of the last frame from the first chunk that is not too big and the end
of the frame from the last chunk). BTW, why we don't use UI mode and
instead do checksumming for the header only (therefore garbled frames
are going notticed)?
So, the proposed fix is to make gsm0710_buffer_free return the correct
free size, i.e. one byte less than it does now.
I'm sorry that i cannot really check the fix as i don't have a proper
compiling environment set up yet.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[EMAIL PROTECTED]
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
