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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
