On Tue, 2007-04-10 at 17:08 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Tuesday 2007-04-10 at 13:12 +0200, Roger Oberholtzer wrote:
Perhaps this is related to an issue I am starting to look in to. I have a system with a number of PCI I/O cards (firewire, video, SCSI, network) as well as the good old serial ports (16550-based - not PCI). In some system loads (not excessive) I see that the serial port driver starts to report data overruns. I also see missing characters in GPS data read over the serial port at this time.
Surprising... :-O
I get the point. But I do not think I have reached any resource limits when this happens. I know that is hard to judge. And I could be very wrong.
I am trying to see why these overruns are happening. The serial port is operating at 38400. The 16550 can only buffer 16 characters in hardware. So the device driver must service the hardware within that time or data will be lost (handshake issues aside - eventually some buffer can get full).
Hum.
This should not happen. The hardware should be able to signal the other side that it is not ready to receive data - that's what hardware handshake is for. Even an old 8086 was able to service the serial port at maximum speed, and if it couldn't, the other end would pause. The same should happen now with modern hardware.
I would look at the hardware handshake lines first.
It is being investigated. We are using cables made by Trimble that they feel we should really use. I am having the GPS receivers checked for any unexpected settings. The serial port really has limited settings. But that does not mean the users have not found something to cause problems.
Could it be that some device driver has a higher priority and is blocking the serial port driver from servicing the hardware? I am running whatever default priorities are in SUSE 10.0. Am I looking in the right direction?.
Maybe.
Interrupts are interrupts, should be attended regardless of conditions, although maybe later. If there is an unwanted delay, and there can be unless you have on a real time system (warrantied maximum response time), the system (hardware) should be able to inform the sending side to slow down and wait.
If hardware handshaking is impossible, revert to software handshake (much slower, chars have to be sent back)
But the software handshake must require that the driver is getting called in time, no? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org