Re: [opensuse] Long standing serial port issue in openSuse
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 <roger@opq.se> 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
On Wed, 2008-08-27 at 11:28 +0200, Wilfred van Velzen wrote:
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
Interesting link. Not using this. It is describing the issue of non-restartable system calls. We always set up our signal handlers to specify SA_RESTART. But our problem happens even when the application does not get a signal or other asynchronous interrupt. We have no trouble with a read() call getting interrupted by some signal to the program. Occasional read returns with no data or incomplete data are no problem. What happens in our case is that the reads start returning immediately. So the application is suddenly using all available CPU time because it is doing reads as fast as it can, with only 1 in a 1000 actually providing data. I forgot to mention that I use strace to see all that is happening. -- 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
On Wednesday 27 August 2008, Roger Oberholtzer wrote:
On Wed, 2008-08-27 at 11:28 +0200, Wilfred van Velzen wrote:
Interesting link. Not using this. It is describing the issue of non-restartable system calls. We always set up our signal handlers to specify SA_RESTART. But our problem happens even when the application does not get a signal or other asynchronous interrupt.
We have no trouble with a read() call getting interrupted by some signal to the program. Occasional read returns with no data or incomplete data are no problem. What happens in our case is that the reads start returning immediately. So the application is suddenly using all available CPU time because it is doing reads as fast as it can, with only 1 in a 1000 actually providing data.
I forgot to mention that I use strace to see all that is happening.
-- 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.
Hi . I take it this system is mounted in some sort of vehicle you have of course made certain it is not a spike or other such electrical interference getting into the cable some how or somewhere else in the system . I have been designing and building an control system for a friends sons rally car and have had lots of trouble with spikes ect causing real havoc even stopping the car dead Pete . -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Aug 27, 2008, at 6:03 PM, peter nikolic wrote:
I take it this system is mounted in some sort of vehicle you have of course made certain it is not a spike or other such electrical interference getting into the cable some how or somewhere else in the system .
I have been designing and building an control system for a friends sons rally car and have had lots of trouble with spikes ect causing real havoc even stopping the car dead
Nope. Our systems are very sound electrically. They run 220 volts via a non-switching (a.k.a. on-line) ups, typically powered by a little known device from Electrolux called a TravelPower that runs off the engine. We usually set up 5000 watts of power. Vehicle power is one thing we also have had lots of experience with. We also have sensitive gyroscopes (SAAB fighter aircraft quality), accelerometers, inclinometers, lasers and whatnot. All work fine. And, for the faint of heart, high powered industrial strobes sucking thousands of watts. All working happily. Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
peter nikolic -
Roger Oberholtzer -
Wilfred van Velzen