Mailinglist Archive: opensuse (3175 mails)
| < Previous | Next > |
Re: [opensuse] Elevator Question
- From: Roger Oberholtzer <roger@xxxxxx>
- Date: Tue, 10 Apr 2007 17:27:13 +0200
- Message-id: <1176218833.21885.74.camel@xxxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
> -----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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |