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 exh
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 and
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 sess
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 th
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 f
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 o
> 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 i
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
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 t
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 clo
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 consumin
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 move
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 unsubscri
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, 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 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, be
> 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 sessi
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
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 a
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 enabl
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 c
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 wo
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 http://vger.kernel.org/majordo
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
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 the
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 t
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 li
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 /dev/ttywhatev
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 appli
> 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 the
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 n
> -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 co
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 h
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 chi
> 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 goe
> 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 ty
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 kilobytes
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 curren
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.)
Wh
49 matches
Mail list logo
