Roger Oberholtzer wrote:
On Wed, 2008-08-27 at 14:00 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
we have two applications that both read/write to/from a serial port. One application reads temperature measurements and writes commands, the other is a standard NTP reading a DCF77 signal from the serial port. The first application is on SUSE 9.0, the second is on openSUSE 10.2. They've both been running for a couple of years, and neither have ever showed any problems. OOC, do you run X on these systems?
Nope, no X.
We run X. The GPS is recorded as part of a measurement in a moving vehicle, and it can steer location info during data collection.
Maybe the X server is part of my problem. (Of course, I do not want to rule out anything else.) I remember back when you had to restart X if you added an input device. If it was not found at X's start, it was not available. More recently, X finds these devices as they are available. Which is really nice. Does X ever re-check the serial ports after it starts? In my use, X is never restarted when this problem occurs.
Or maybe it is something in how /dev/input/mice is implemented. What does it consider to be a potential mouse?
Sorry, I can't answer that but I'd be interested to know too :) I have a couple of thoughts though. You seem quite focussed on the possibility that the problem is related to X - is there a particular reason for that? Can you set up a test system without X - or with X remoted to a different physical machine - to see if the problem goes away? One other difference Per mentioned is that his applications write to the serial port. Is there any way to try that on your system in case there's some hardware or driver glitch? When the problem occurs, are you able to check the status of the serial port? Either from within your application or by looking in /proc etc. Has the port somehow been set to non-blocking? Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org