Roger, Are you reading the compoort like this: TEMP_FAILURE_RETRY(read(comDev, str, len)); For info on this see for instance: http://www.gnu.org/software/libtool/manual/libc/Interrupted-Primitives.html Met vriendelijke groet / Best regards, Wilfred van Velzen

...

...

Roger Oberholtzer 2008-08-27 11:08:11 >>>

I have a C application that access a GPS receiver over a serial port. Over the years, using Linux (SUSE variants back a long way), I have experienced a problem that has never gone away. Although it appears on the surface to be a programming question, I think it is really a kernel / serial port issue. As I see it in openSUSE, I am starting my quest for a solution here. The problem is that, after a variable amount of time, reads of the serial port stop blocking (as the port has been configured to do) when there is no data, and start returning immediately with errno set to EAGAIN. This can happen after 5 minutes of running the app, or after 5 hours. There is no discernible pattern. The code in the application is childishly simple: 1. Open the serial port in the C application, controlling it via termio(). 2. Do a blocking read on the port. 3. When data arrived, write it to a disk file. 4. Go to step 2. We have done variations on this theme. For example, setting the serial port to send SIGIO when there is data, and not doing a blocking read. It works great for a while. But suddenly the kernel starts sending SIGIO over and over, even when there is no data. This implies that at some lower level, the kernel thinks there is data to provide, even though the subsequent read will disagree. I would think that, since PPP is using the serial port, Linux's serial port code would be bulletproof. But I also think that such stability is perhaps present when the serial port is used as PPP uses it. For example, I would think that PPP data is of known sizes (headers of known size that report data sizes to be read), and may not do reads of any size. Also, PPP writes as well as reads. Our app never writes to the port. I can provide code examples. I do not think they will indicate anything unusual. Anyone else using the serial port to record data over long periods of time? If it is not a kernel issue, is it possible that there is some application that runs (X? something else?) that wakes up and interferes with the serial port? No serial port specific things seem to be changed. Baud rate and flow control remain unchanged. But maybe just opening it resets the blocking mode for all users? We do not use PPP and, AFAIK no applications that use the serial port are enabled. Could there be any apps enabled in a rather standard SUSE install that may occasionally interfere with the serial port? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org -- SERCOM Regeltechniek b.v. Heereweg 9 2161 AB Lisse Nederland +31 (0)252 416530 (voice) +31 (0)252 419481 (fax) http://www.sercom.nl/ Op al onze offertes, op alle opdrachten aan ons en op alle met ons gesloten overeenkomsten zijn toepasselijk de METAALUNIEVOORWAARDEN, gedeponeerd ter Griffie van de Rechtbank te Rotterdam, zoals deze luiden volgens de laatstelijk aldaar neergelegde tekst. De leveringsvoorwaarden worden u op verzoek toegezonden. --- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org