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