2.2.5 is using the same UART setup (trigger level of 8) as
the current code. There is no obvious difference in the
interrupt setup (same devices on the same interrupts).
So I have no helpful suggestions :-(
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
2.2.5 is using the same UART setup (trigger level of 8) as
the current code. There is no obvious difference in the
interrupt setup (same devices on the same interrupts).
So I have no helpful suggestions :-(
--
Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Paul Fulghum wrote:
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases
an increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases an
increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not exhibit this problem.
Was
Mark Lord wrote:
The "fix" could be to have the serial IRQ handler never unmask
interrupts,
but that's a bit unsociable to others. The IDE stuff really needs to not
do so much during the actual IRQ handler.
Ingo's RT patches would probably fix all of this.
I did a Fedora 7 installation
Ray Lee wrote:
On 7/27/07, Lee Howard <[EMAIL PROTECTED]> wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred
Maciej W. Rozycki wrote:
On Fri, 27 Jul 2007, Lee Howard wrote:
Okay, so let's say we've got a loop around a blocking read on the modem file
descriptor...
for (;;) {
read some data from modem
process data from modem
if (end-of-data detected) break;
}
Are you suggesting that
Maciej W. Rozycki wrote:
On Fri, 27 Jul 2007, Lee Howard wrote:
Okay, so let's say we've got a loop around a blocking read on the modem file
descriptor...
for (;;) {
read some data from modem
process data from modem
if (end-of-data detected) break;
}
Are you suggesting that
Ray Lee wrote:
On 7/27/07, Lee Howard [EMAIL PROTECTED] wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred
Mark Lord wrote:
The fix could be to have the serial IRQ handler never unmask
interrupts,
but that's a bit unsociable to others. The IDE stuff really needs to not
do so much during the actual IRQ handler.
Ingo's RT patches would probably fix all of this.
I did a Fedora 7 installation and
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases an
increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not exhibit this problem.
Was
Paul Fulghum wrote:
Lee Howard wrote:
And in repeat tests it is quite evident that IDE disk activity is,
indeed, at least part of the problem. As IDE disk activity increases
an increased amount of data coming in on the serial port goes missing.
Lee, you mentioned 2.2.x kernels did not
On Thu, 2 Aug 2007, Alan Cox wrote:
> Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
> some work on that but its actually very hard to fix without doing polled
> PIO.
Hmm, when the drive signals it is ready for a PIO data transfer can't
just the interrupt handler
On Thu, 2 Aug 2007, Alan Cox wrote:
Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
some work on that but its actually very hard to fix without doing polled
PIO.
Hmm, when the drive signals it is ready for a PIO data transfer can't
just the interrupt handler mask
> That's what "hdparm -u1" (or -u0) controls.
Only some of the time.
> Ingo's RT patches would probably fix all of this.
The worst case IDE times we've seen for executing a single indivisible
un-interruptible I/O cycle with a drive are around 1mS. Thats a hardware
limit.
Alan
-
To unsubscribe
Alan Cox wrote:
I think that PIO transfers only have to be done with interrupts disabled
on really old, evil controllers (without unmask set). I don't think
libata ever disables interrupts during transfers(?)
Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
some work
> I think that PIO transfers only have to be done with interrupts disabled
> on really old, evil controllers (without unmask set). I don't think
> libata ever disables interrupts during transfers(?)
Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
some work on that but
Mark Lord wrote:
I think that PIO transfers only have to be done with interrupts
disabled on really old, evil controllers (without unmask set). I don't
think libata ever disables interrupts during transfers(?)
That's what "hdparm -u1" (or -u0) controls.
But it doesn't matter a whit here.
Robert Hancock wrote:
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often
pan out
in practice. More
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often pan
out
in practice. More typical is something
Maciej W. Rozycki wrote:
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux 1.x had bottom halves - so that
the time
Maciej W. Rozycki wrote:
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux 1.x had bottom halves - so that
the time
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often pan
out
in practice. More typical is something
I think that PIO transfers only have to be done with interrupts disabled
on really old, evil controllers (without unmask set). I don't think
libata ever disables interrupts during transfers(?)
Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
some work on that but its
Robert Hancock wrote:
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often
pan out
in practice. More
Mark Lord wrote:
I think that PIO transfers only have to be done with interrupts
disabled on really old, evil controllers (without unmask set). I don't
think libata ever disables interrupts during transfers(?)
That's what hdparm -u1 (or -u0) controls.
But it doesn't matter a whit here. The
That's what hdparm -u1 (or -u0) controls.
Only some of the time.
Ingo's RT patches would probably fix all of this.
The worst case IDE times we've seen for executing a single indivisible
un-interruptible I/O cycle with a drive are around 1mS. Thats a hardware
limit.
Alan
-
To unsubscribe from
Alan Cox wrote:
I think that PIO transfers only have to be done with interrupts disabled
on really old, evil controllers (without unmask set). I don't think
libata ever disables interrupts during transfers(?)
Currently libata PIO is mostly done in the IRQ path. Albert Lee was doing
some work
On Mon, Jul 30, 2007 at 10:45:19AM +0100, Maciej W. Rozycki wrote:
> On Sat, 28 Jul 2007, Russell King wrote:
>
> > Essentially, any complex interrupt handler (such as an IDE interrupt
> > doing a multi-sector PIO transfer _in interrupt context_) can cause this
> > kind of starvation. That's why
On Sat, 28 Jul 2007, Russell King wrote:
> Essentially, any complex interrupt handler (such as an IDE interrupt
> doing a multi-sector PIO transfer _in interrupt context_) can cause this
> kind of starvation. That's why Linux 1.x had bottom halves - so that
> the time consuming work could be
On Fri, 27 Jul 2007, Paul Fulghum wrote:
> I can't see anyplace in serial_core.c or 8250.c that sets TTY_OVERRUN.
Look for UART_LSR_OE in 8250.c -- the serial core accepts any bit that
has been defined by the low-level driver and sets TTY_OVERRUN in
uart_insert_char().
Maciej
-
To
On Fri, 27 Jul 2007, Lee Howard wrote:
> >The serial drivers have nothing to do about it -- all they can do is pushing
> >data upstream, to the discipline driver. They can provide an interface to
> >hardware flow control features though, if implemented by a given UART.
> >
>
> Thank you for
On Fri, 27 Jul 2007, Robert Hancock wrote:
> > The TTY line discipline driver could do that based on the amount of received
> > data present in its buffer. And it should if asked to (a brief look at
> > drivers/char/n_tty.c reveals it does; obviously there may be a bug
>
> Really, where? In my
On Fri, 27 Jul 2007, Robert Hancock wrote:
The TTY line discipline driver could do that based on the amount of received
data present in its buffer. And it should if asked to (a brief look at
drivers/char/n_tty.c reveals it does; obviously there may be a bug
Really, where? In my look
On Fri, 27 Jul 2007, Lee Howard wrote:
The serial drivers have nothing to do about it -- all they can do is pushing
data upstream, to the discipline driver. They can provide an interface to
hardware flow control features though, if implemented by a given UART.
Thank you for this
On Fri, 27 Jul 2007, Paul Fulghum wrote:
I can't see anyplace in serial_core.c or 8250.c that sets TTY_OVERRUN.
Look for UART_LSR_OE in 8250.c -- the serial core accepts any bit that
has been defined by the low-level driver and sets TTY_OVERRUN in
uart_insert_char().
Maciej
-
To
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux 1.x had bottom halves - so that
the time consuming work could be moved
On Mon, Jul 30, 2007 at 10:45:19AM +0100, Maciej W. Rozycki wrote:
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux
On 7/27/07, Lee Howard <[EMAIL PROTECTED]> wrote:
> Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
> not just in sequence but also in precice timing within the session, with
> a small but noticeable disk load that I caused by grepping through a
> hundred session logs. (I
Alan Cox wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred session logs. (I can't reproduce it easily, though,
> Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
> not just in sequence but also in precice timing within the session, with
> a small but noticeable disk load that I caused by grepping through a
> hundred session logs. (I can't reproduce it easily, though, because of
On Fri, Jul 27, 2007 at 09:51:25PM -0700, Lee Howard wrote:
> Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
> not just in sequence but also in precice timing within the session, with
> a small but noticeable disk load that I caused by grepping through a
> hundred
On Fri, Jul 27, 2007 at 12:22:57PM -0600, Robert Hancock wrote:
> Maciej W. Rozycki wrote:
> > The TTY line discipline driver could do that based on the amount of
> >received data present in its buffer. And it should if asked to (a brief
> >look at drivers/char/n_tty.c reveals it does;
On Fri, Jul 27, 2007 at 12:22:57PM -0600, Robert Hancock wrote:
Maciej W. Rozycki wrote:
The TTY line discipline driver could do that based on the amount of
received data present in its buffer. And it should if asked to (a brief
look at drivers/char/n_tty.c reveals it does; obviously there
On Fri, Jul 27, 2007 at 09:51:25PM -0700, Lee Howard wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred session
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred session logs. (I can't reproduce it easily, though, because of
Alan Cox wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred session logs. (I can't reproduce it easily, though,
On 7/27/07, Lee Howard [EMAIL PROTECTED] wrote:
Curiously, the session at 38400 bps that skipped 858 bytes... coincided,
not just in sequence but also in precice timing within the session, with
a small but noticeable disk load that I caused by grepping through a
hundred session logs. (I can't
Paul Fulghum wrote:
So this seems to be a latency issue reading the receive
FIFO in the ISR. The current rx FIFO trigger level
should be 8 bytes (UART_FCR_R_TRIG_10) which gives the
ISR 694usec to get the data at 115200bps.
IIRC, in 2.2.X kernels this defaulted to 4 bytes
(TRIG_01) which gave
On Fri, 2007-07-27 at 13:48 -0700, Lee Howard wrote:
> Here's the output:
>
> type: 4
> line: 1
> line: 760
> irq: 3
>flags: 1358954688
> xmit_fifo_size: 16
> custom_divisor: 0
>baud_base: 115200
OK, the FIFO should be
Paul Fulghum wrote:
Tilman Schmidt wrote:
Could this be related?
http://lkml.org/lkml/2007/7/18/245
Quote:
"I've recently found (using 2.6.21.4) that configuring a serial ports
(ST16654) which use the 8250 driver using setserial results in the
UART's FIFOs being disabled (unless you specify
Tilman Schmidt wrote:
Lee Howard schrieb:
So, does this explain why I wouldn't have a problem at 115200 bps with
kernel 2.2.5 but why I do with 2.6.5 and 2.6.18? Both hardware and
software flow control work fine with 2.2.5 (meaning I don't see any
error message and I don't have any data
Tilman Schmidt wrote:
Could this be related?
http://lkml.org/lkml/2007/7/18/245
Quote:
"I've recently found (using 2.6.21.4) that configuring a serial ports
(ST16654) which use the 8250 driver using setserial results in the
UART's FIFOs being disabled (unless you specify autoconfig)."
That
OK, I see where TTY_OVERRUN is set:
include/linux/serial_core.h:uart_insert_char()
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 2007-07-27 at 12:22 -0600, Robert Hancock wrote:
> In this situation, though, it appears it's not the TTY buffers that are
> filling but the UART's own buffer. I would think this must be caused by
> some kind of interrupt latency that results in not draining the FIFO in
> time.
You
On Fri, 2007-07-27 at 12:22 -0600, Robert Hancock wrote:
> Maciej W. Rozycki wrote:
> > The TTY line discipline driver could do that based on the amount of
> > received data present in its buffer. And it should if asked to (a brief
> > look at drivers/char/n_tty.c reveals it does; obviously
Maciej W. Rozycki wrote:
On Fri, 27 Jul 2007, Lee Howard wrote:
Okay, so let's say we've got a loop around a blocking read on the modem file
descriptor...
for (;;) {
read some data from modem
process data from modem
if (end-of-data detected) break;
}
Are you suggesting that
Maciej W. Rozycki wrote:
The TTY line discipline driver could do that based on the amount of
received data present in its buffer. And it should if asked to (a brief
look at drivers/char/n_tty.c reveals it does; obviously there may be a bug
somewhere though). So could e.g. the SLIP and PPP
Alan Cox wrote:
As the flow control is driven by software on most 16x50 chips (there are
a couple of exceptions) if we fail to empty the fifo fast enough then any
flow control will be asserted too late to save the day.
If you stop the application and do the following
cat
On Fri, 27 Jul 2007, Lee Howard wrote:
> Okay, so let's say we've got a loop around a blocking read on the modem file
> descriptor...
>
> for (;;) {
> read some data from modem
> process data from modem
> if (end-of-data detected) break;
> }
>
> Are you suggesting that the
> I had previously thought that the control of RTS was something that the
> serial/tty driver was supposed to do independently based on the buffer
> fill. Was I wrong?
If the kernel is asked to do CRTSCTS then the kernel handles the flow
control. It uses it when the internal buffers are nearly
Maciej W. Rozycki wrote:
On Thu, 26 Jul 2007, Lee Howard wrote:
If the application were to use TIOCM_RTS how would it know when to apply it or
not? Is there some approach that the application could take to manage flow
control on the serial port? What about software flow control? Does
Lee Howard schrieb:
>
> So, does this explain why I wouldn't have a problem at 115200 bps with
> kernel 2.2.5 but why I do with 2.6.5 and 2.6.18? Both hardware and
> software flow control work fine with 2.2.5 (meaning I don't see any
> error message and I don't have any data corruption), but
> -parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
Ok so crtscts is set, but you have clocal set too. That shouldn't matter
> Using software flow control this is what stty tells me about the port
> set up done by the application:
This also looks fine
> They seem correct to me, but I am
On Thu, 26 Jul 2007, Lee Howard wrote:
> If the application were to use TIOCM_RTS how would it know when to apply it or
> not? Is there some approach that the application could take to manage flow
> control on the serial port? What about software flow control? Does the
Well, an application
Alan Cox wrote:
The manufacturer is using a scope to look for RTS and they're not seeing
it, either. I just use my eyes to look at the LED, but I can see the
CTS, DTR, DCD, RD, and TD lights blink, flicker, or dim... (and TD, RD,
and CTS tend to go on and off rather quickly).
And you
Alan Cox wrote:
The manufacturer is using a scope to look for RTS and they're not seeing
it, either. I just use my eyes to look at the LED, but I can see the
CTS, DTR, DCD, RD, and TD lights blink, flicker, or dim... (and TD, RD,
and CTS tend to go on and off rather quickly).
And you
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
Ok so crtscts is set, but you have clocal set too. That shouldn't matter
Using software flow control this is what stty tells me about the port
set up done by the application:
This also looks fine
They seem correct to me, but I am
On Thu, 26 Jul 2007, Lee Howard wrote:
If the application were to use TIOCM_RTS how would it know when to apply it or
not? Is there some approach that the application could take to manage flow
control on the serial port? What about software flow control? Does the
Well, an application
Lee Howard schrieb:
So, does this explain why I wouldn't have a problem at 115200 bps with
kernel 2.2.5 but why I do with 2.6.5 and 2.6.18? Both hardware and
software flow control work fine with 2.2.5 (meaning I don't see any
error message and I don't have any data corruption), but
Maciej W. Rozycki wrote:
On Thu, 26 Jul 2007, Lee Howard wrote:
If the application were to use TIOCM_RTS how would it know when to apply it or
not? Is there some approach that the application could take to manage flow
control on the serial port? What about software flow control? Does
I had previously thought that the control of RTS was something that the
serial/tty driver was supposed to do independently based on the buffer
fill. Was I wrong?
If the kernel is asked to do CRTSCTS then the kernel handles the flow
control. It uses it when the internal buffers are nearly
On Fri, 27 Jul 2007, Lee Howard wrote:
Okay, so let's say we've got a loop around a blocking read on the modem file
descriptor...
for (;;) {
read some data from modem
process data from modem
if (end-of-data detected) break;
}
Are you suggesting that the application
Maciej W. Rozycki wrote:
On Fri, 27 Jul 2007, Lee Howard wrote:
Okay, so let's say we've got a loop around a blocking read on the modem file
descriptor...
for (;;) {
read some data from modem
process data from modem
if (end-of-data detected) break;
}
Are you suggesting that
Alan Cox wrote:
As the flow control is driven by software on most 16x50 chips (there are
a couple of exceptions) if we fail to empty the fifo fast enough then any
flow control will be asserted too late to save the day.
If you stop the application and do the following
cat
Maciej W. Rozycki wrote:
The TTY line discipline driver could do that based on the amount of
received data present in its buffer. And it should if asked to (a brief
look at drivers/char/n_tty.c reveals it does; obviously there may be a bug
somewhere though). So could e.g. the SLIP and PPP
On Fri, 2007-07-27 at 12:22 -0600, Robert Hancock wrote:
Maciej W. Rozycki wrote:
The TTY line discipline driver could do that based on the amount of
received data present in its buffer. And it should if asked to (a brief
look at drivers/char/n_tty.c reveals it does; obviously there may
On Fri, 2007-07-27 at 12:22 -0600, Robert Hancock wrote:
In this situation, though, it appears it's not the TTY buffers that are
filling but the UART's own buffer. I would think this must be caused by
some kind of interrupt latency that results in not draining the FIFO in
time.
You are
Tilman Schmidt wrote:
Could this be related?
http://lkml.org/lkml/2007/7/18/245
Quote:
I've recently found (using 2.6.21.4) that configuring a serial ports
(ST16654) which use the 8250 driver using setserial results in the
UART's FIFOs being disabled (unless you specify autoconfig).
That
OK, I see where TTY_OVERRUN is set:
include/linux/serial_core.h:uart_insert_char()
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Tilman Schmidt wrote:
Lee Howard schrieb:
So, does this explain why I wouldn't have a problem at 115200 bps with
kernel 2.2.5 but why I do with 2.6.5 and 2.6.18? Both hardware and
software flow control work fine with 2.2.5 (meaning I don't see any
error message and I don't have any data
Paul Fulghum wrote:
Tilman Schmidt wrote:
Could this be related?
http://lkml.org/lkml/2007/7/18/245
Quote:
I've recently found (using 2.6.21.4) that configuring a serial ports
(ST16654) which use the 8250 driver using setserial results in the
UART's FIFOs being disabled (unless you specify
On Fri, 2007-07-27 at 13:48 -0700, Lee Howard wrote:
Here's the output:
type: 4
line: 1
line: 760
irq: 3
flags: 1358954688
xmit_fifo_size: 16
custom_divisor: 0
baud_base: 115200
OK, the FIFO should be enabled.
What
Paul Fulghum wrote:
So this seems to be a latency issue reading the receive
FIFO in the ISR. The current rx FIFO trigger level
should be 8 bytes (UART_FCR_R_TRIG_10) which gives the
ISR 694usec to get the data at 115200bps.
IIRC, in 2.2.X kernels this defaulted to 4 bytes
(TRIG_01) which gave
Alan Cox wrote:
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
It's a Shuttle HOT-661 motherboard (VIA Apollo Pro Plus mainboard
chipset). Both FreeBSD and Linux identify the serial
> The manufacturer is using a scope to look for RTS and they're not seeing
> it, either. I just use my eyes to look at the LED, but I can see the
> CTS, DTR, DCD, RD, and TD lights blink, flicker, or dim... (and TD, RD,
> and CTS tend to go on and off rather quickly).
And you have
1.
Uwe Kleine-König wrote:
Hello,
This is evidenced in hardware flow control by a little LED labeled "RTS"
that is on the external modem. This LED lights up when pin 7 of the DB9
serial connection is given +12Vdc current (signalling "RTS" is on - that
the host can accept data). The LED
> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>
> It's a Shuttle HOT-661 motherboard (VIA Apollo Pro Plus mainboard
> chipset). Both FreeBSD and Linux identify the serial chipset
Robert Hancock wrote:
Lee Howard wrote:
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at
once. (So, the fax modem handles an incoming fax and periodically
will send between 256 bytes and 64
Hello,
> This is evidenced in hardware flow control by a little LED labeled "RTS"
> that is on the external modem. This LED lights up when pin 7 of the DB9
> serial connection is given +12Vdc current (signalling "RTS" is on - that
> the host can accept data). The LED goes dark when the
Lee Howard wrote:
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at once.
(So, the fax modem handles an incoming fax and periodically will send
between 256 bytes and 64 kilobytes of data in bursts.)
Lee Howard wrote:
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at once.
(So, the fax modem handles an incoming fax and periodically will send
between 256 bytes and 64 kilobytes of data in bursts.)
The manufacturer is using a scope to look for RTS and they're not seeing
it, either. I just use my eyes to look at the LED, but I can see the
CTS, DTR, DCD, RD, and TD lights blink, flicker, or dim... (and TD, RD,
and CTS tend to go on and off rather quickly).
And you have
1. The
Uwe Kleine-König wrote:
Hello,
This is evidenced in hardware flow control by a little LED labeled RTS
that is on the external modem. This LED lights up when pin 7 of the DB9
serial connection is given +12Vdc current (signalling RTS is on - that
the host can accept data). The LED goes
Robert Hancock wrote:
Lee Howard wrote:
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at
once. (So, the fax modem handles an incoming fax and periodically
will send between 256 bytes and 64
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
It's a Shuttle HOT-661 motherboard (VIA Apollo Pro Plus mainboard
chipset). Both FreeBSD and Linux identify the serial chipset type as
Hello,
This is evidenced in hardware flow control by a little LED labeled RTS
that is on the external modem. This LED lights up when pin 7 of the DB9
serial connection is given +12Vdc current (signalling RTS is on - that
the host can accept data). The LED goes dark when the current is
Alan Cox wrote:
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
It's a Shuttle HOT-661 motherboard (VIA Apollo Pro Plus mainboard
chipset). Both FreeBSD and Linux identify the serial
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at once.
(So, the fax modem handles an incoming fax and periodically will send
between 256 bytes and 64 kilobytes of data in bursts.)
When the DCE-DTE
Hello.
I have fax modems that will, in their proper behavior with certain
features, send up to 64 kilobytes of data to the host DTE all at once.
(So, the fax modem handles an incoming fax and periodically will send
between 256 bytes and 64 kilobytes of data in bursts.)
When the DCE-DTE
100 matches
Mail list logo
