Re: R: How to avoid serial port buffer overruns?

Re: R: How to avoid serial port buffer overruns?

[Robert Hancock]

Giampaolo Tomassoni wrote:
> I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:
> 
> 	static irqreturn_t snd_uart16550_interrupt(int irq, void *dev_id, struct pt_regs *regs)
> 	{
> 	        snd_uart16550_t *uart;
> 	
> 	        uart = (snd_uart16550_t *) dev_id;
> 	        spin_lock(&uart->open_lock);
> 	        if (uart->filemode == SERIAL_MODE_NOT_OPENED) {
> 	                spin_unlock(&uart->open_lock);
> 	                return IRQ_NONE;
> 	        }
> 	        inb(uart->base + UART_IIR);             /* indicate to the UART that the interrupt has been serviced */
> 	        snd_uart16550_io_loop(uart);
> 	        spin_unlock(&uart->open_lock);
> 	        return IRQ_HANDLED;
> 	}
> 
> means to me that IRQ_HANDLED is returned even when the interrupt is not issued by the specific UART. This may lead to problems when two or more uarts share the same irq line and the irq line is edge-triggered instead of level-triggered, as is the case with ISA.
> 
> To my knowledge, IRQ_HANDLED should be returned when an interrupt had been served by that specific device handler. Returning a IRQ_HANDLED when the device didn't request for service, in the best case cuases interrupt latencies, in the worst (like in an ISA environment) impairs servicing requests from devices sharing the same IRQ line.
> 
> The byte returned from inb(uart->base + UART_IIR) can be used to detect if this is the requesting UART.
> 
> Am I wrong?

IRQ_HANDLED vs. IRQ_NONE has no effect on what interrupt handlers are 
called, etc. It is only used to detect if an interrupt is firing without 
being handled by any driver, in this case the kernel can detect this and 
disable the interrupt.

I'm not sure exactly why the driver is returning IRQ_HANDLED all the 
time, but edge-triggered interrupts are always tricky and there may be a 
case where it can't reliably detect this. Returning IRQ_HANDLED is the 
safe thing to do if you cannot be sure if your device raised an 
interrupt or not.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

R: R: How to avoid serial port buffer overruns?

[Giampaolo Tomassoni]

> -----Messaggio originale-----
> Da: Robert Hancock [mailto:hancockr@shaw.ca]
> Inviato: venerdì 18 agosto 2006 16.31
> A: Giampaolo Tomassoni
> Cc: Linux Kernel ML
> Oggetto: Re: R: How to avoid serial port buffer overruns?
>
> IRQ_HANDLED vs. IRQ_NONE has no effect on what interrupt handlers are 
> called, etc. It is only used to detect if an interrupt is firing without 
> being handled by any driver, in this case the kernel can detect this and 
> disable the interrupt.
> 
> I'm not sure exactly why the driver is returning IRQ_HANDLED all the 
> time, but edge-triggered interrupts are always tricky and there may be a 
> case where it can't reliably detect this. Returning IRQ_HANDLED is the 
> safe thing to do if you cannot be sure if your device raised an 
> interrupt or not.

Oh, I see. This in handle_IRQ_event in /kernel/irq/handle.c confirms what you said:

        do {
                ret = action->handler(irq, action->dev_id, regs);
                if (ret == IRQ_HANDLED)
                        status |= action->flags;
                retval |= ret;
                action = action->next;
        } while (action);

There is no escape from the loop when the handler returns IRQ_HANDLED.

Thanks,

	giampaolo

> 
> -- 
> Robert Hancock      Saskatoon, SK, Canada
> To email, remove "nospam" from hancockr@nospamshaw.ca
> Home Page: http://www.roberthancock.com/
> 

Re: R: R: How to avoid serial port buffer overruns?

[linux-os (Dick Johnson)]

On Fri, 18 Aug 2006, Giampaolo Tomassoni wrote:

>> -----Messaggio originale-----
>> Da: Robert Hancock [mailto:hancockr@shaw.ca]
>> Inviato: venerdì 18 agosto 2006 16.31
>> A: Giampaolo Tomassoni
>> Cc: Linux Kernel ML
>> Oggetto: Re: R: How to avoid serial port buffer overruns?
>>
>> IRQ_HANDLED vs. IRQ_NONE has no effect on what interrupt handlers are
>> called, etc. It is only used to detect if an interrupt is firing without
>> being handled by any driver, in this case the kernel can detect this and
>> disable the interrupt.
>>
>> I'm not sure exactly why the driver is returning IRQ_HANDLED all the
>> time, but edge-triggered interrupts are always tricky and there may be a
>> case where it can't reliably detect this. Returning IRQ_HANDLED is the
>> safe thing to do if you cannot be sure if your device raised an
>> interrupt or not.
>
> Oh, I see. This in handle_IRQ_event in /kernel/irq/handle.c confirms what you said:
>
>        do {
>                ret = action->handler(irq, action->dev_id, regs);
>                if (ret == IRQ_HANDLED)
>                        status |= action->flags;
>                retval |= ret;
>                action = action->next;
>        } while (action);
>
> There is no escape from the loop when the handler returns IRQ_HANDLED.
>
> Thanks,
>
> 	giampaolo
>
>>
>> --
>> Robert Hancock      Saskatoon, SK, Canada
>> To email, remove "nospam" from hancockr@nospamshaw.ca
>> Home Page: http://www.roberthancock.com/
>>

Hardware designed for shared interrupts use what's called
open-collector or open-drain outputs. This allows all devices
to be connected as a "wired-OR".

           Vcc
            |
            R
            |--------------|--------IRQ...
           /              /
1 ------||        -----||
           \       |      \
           |       |      |
           Ve      |      Ve
2 ----------------|

In this case, any device can pull down on the IRQ line.
The wire will remain active LOW until all the hardware
interrupt demands are satisfied. This is used for "level"
interrupts.

Hardware designed for edge interrupts use active devices
to pull a normally-low line up. This produces an edge
which is latched by the interrupt controller. Since
the interrupt controller has only one latch per input
any subsequent edges that occur before the first instance
of an interrupt is serviced (which clears the latch),
will be lost.

This is why devices that produce edges upon interrupt
request can't be shared. However, some people who claim
to know more than the designers of the devices, reason
that if upon any interrupt all of the devices sharing
the edge-type line, are checked for an interrupt request,
then the devices will eventually all get serviced without
losing any interrupts. The reasoning is faulty because
the only way to accomplish this logic is, if you have
N devices sharing an interrupt, then all N interrupt
service routines need to be called N times to handle
all the possibilities of hardware interrupt requests
happening before the latch is reset.

Apparently to handle these kinds of kludges, the kernel
interrupt code was modified so that the device-driver
code needs to returna value to the kernel core code.
If the value is not IRQ_HANDLED, then the ISR will be
called again. If your ISR never returns IRQ_HANDLED,
then the kernel core code will shut you off when it
detects a loop of (last I checked) 10,000 spins.

Any device that uses an edge-type interrupt intended
to be shared is broken by design. There are kludges
that allow for lost interrupt recovery, such as
kicking the device ISR off a timer-queue, but they
are kludges, something to get bad hardware out the
door. The 8250 UART and its modern counterparts
use edge-type interrupt requests. If you have a special
clone (there are some) that can programmed to use
level interrupts, then you need to select an IRQ that
can be programmed for level operation without screwing
up the rest of the computer. This generally means
that you can't use the default IRQ3 or IRQ4.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: How to avoid serial port buffer overruns?

[Lee Revell]

On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> On Wed, Aug 16, 2006 at 07:15:06PM -0400, Lee Revell wrote:
> > On Thu, 2006-08-17 at 00:10 +0100, Russell King wrote:
> > > MIDI uses its own driver - sound/drivers/serial-u16550.c.  My guess
> > > is there's something in the system starving interrupt servicing.
> > > Serial is very sensitive to that, and increases in other system
> > > latencies tends to have an adverse impact on serial.
> > 
> > Have you seen many other reports of serial working reliably in 2.4 but
> > not in 2.6?  Right now this is the only clue I have to go on...
> 
> There have been one or two, but the above is basically as far as I've
> got.  Unfortunately, I don't have any machines slow enough (or maybe
> with the right hardware) to exhibit the problem.
> 

OK, thanks.  FWIW here is the serial board we are using:

http://www.moschip.com/html/MCS9845.html

The hardware guy says "The mn9845cv, have in default 2 serial ports and
one ISA bus, where we have connected the tl16c554, quad serial port."

Hopefully Ingo's latency tracer can tell me what is holding off
interrupts.

Lee

R: How to avoid serial port buffer overruns?

[Giampaolo Tomassoni]

> OK, thanks.  FWIW here is the serial board we are using:
> 
> http://www.moschip.com/html/MCS9845.html
> 
> The hardware guy says "The mn9845cv, have in default 2 serial ports and
> one ISA bus, where we have connected the tl16c554, quad serial port."
> 
> Hopefully Ingo's latency tracer can tell me what is holding off
> interrupts.

That may be an interrupt-sharing issue: quad port often use at most two irq lines and, FWIK, ISA irqs are edge-triggered, not level-triggered. Are you tring to use two MIDI ports at the same time?

Giampaolo

> 
> Lee
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

R: How to avoid serial port buffer overruns?

[Giampaolo Tomassoni]

> On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> 
> 
> OK, thanks.  FWIW here is the serial board we are using:
> 
> http://www.moschip.com/html/MCS9845.html
> 
> The hardware guy says "The mn9845cv, have in default 2 serial ports and
> one ISA bus, where we have connected the tl16c554, quad serial port."
> 
> Hopefully Ingo's latency tracer can tell me what is holding off
> interrupts.

I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:

	static irqreturn_t snd_uart16550_interrupt(int irq, void *dev_id, struct pt_regs *regs)
	{
	        snd_uart16550_t *uart;
	
	        uart = (snd_uart16550_t *) dev_id;
	        spin_lock(&uart->open_lock);
	        if (uart->filemode == SERIAL_MODE_NOT_OPENED) {
	                spin_unlock(&uart->open_lock);
	                return IRQ_NONE;
	        }
	        inb(uart->base + UART_IIR);             /* indicate to the UART that the interrupt has been serviced */
	        snd_uart16550_io_loop(uart);
	        spin_unlock(&uart->open_lock);
	        return IRQ_HANDLED;
	}

means to me that IRQ_HANDLED is returned even when the interrupt is not issued by the specific UART. This may lead to problems when two or more uarts share the same irq line and the irq line is edge-triggered instead of level-triggered, as is the case with ISA.

To my knowledge, IRQ_HANDLED should be returned when an interrupt had been served by that specific device handler. Returning a IRQ_HANDLED when the device didn't request for service, in the best case cuases interrupt latencies, in the worst (like in an ISA environment) impairs servicing requests from devices sharing the same IRQ line.

The byte returned from inb(uart->base + UART_IIR) can be used to detect if this is the requesting UART.

Am I wrong?

Regards,

	Giampaolo

Re: R: How to avoid serial port buffer overruns?

[Lee Revell]

On Fri, 2006-08-18 at 10:48 +0200, Giampaolo Tomassoni wrote:
> > On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> > 
> > 
> > OK, thanks.  FWIW here is the serial board we are using:
> > 
> > http://www.moschip.com/html/MCS9845.html
> > 
> > The hardware guy says "The mn9845cv, have in default 2 serial ports and
> > one ISA bus, where we have connected the tl16c554, quad serial port."
> > 
> > Hopefully Ingo's latency tracer can tell me what is holding off
> > interrupts.
> 
> I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:

OK, they are not using serial-u16550 but 8250_fourport for some reason:

# cat /proc/tty/driver/serial 
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:unknown port:000002B8 irq:5
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:16550A port:0000DD00 irq:185 tx:234335 rx:47502 RTS|DTR
5: uart:16550A port:0000E300 irq:185 tx:249926 rx:27732 RTS|DTR
6: uart:16550A port:0000E400 irq:185 tx:120958 rx:0 RTS|DTR
7: uart:16550A port:0000D000 irq:185 tx:0 rx:0
8: uart:16550A port:0000D100 irq:185 tx:0 rx:0 RTS|DTR
9: uart:16550A port:0000D200 irq:185 tx:0 rx:123406 RTS|DTR

It looks like no overruns are reported, but I have to find out whether
they have reproduced the bug since the last reboot.

Re: R: How to avoid serial port buffer overruns?

[Russell King]

On Fri, Aug 18, 2006 at 01:00:00PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 10:48 +0200, Giampaolo Tomassoni wrote:
> > > On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> > > 
> > > 
> > > OK, thanks.  FWIW here is the serial board we are using:
> > > 
> > > http://www.moschip.com/html/MCS9845.html
> > > 
> > > The hardware guy says "The mn9845cv, have in default 2 serial ports and
> > > one ISA bus, where we have connected the tl16c554, quad serial port."
> > > 
> > > Hopefully Ingo's latency tracer can tell me what is holding off
> > > interrupts.
> > 
> > I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:
> 
> OK, they are not using serial-u16550 but 8250_fourport for some reason:

Doesn't look like it.  fourport cards have their ports at 0x1a0..0x1bf
and 0x2a0..0x2bf, and have some special and non-standard features.

> # cat /proc/tty/driver/serial 
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
> 1: uart:unknown port:000002B8 irq:5
> 2: uart:unknown port:000003E8 irq:4
> 3: uart:unknown port:000002E8 irq:3
> 4: uart:16550A port:0000DD00 irq:185 tx:234335 rx:47502 RTS|DTR
> 5: uart:16550A port:0000E300 irq:185 tx:249926 rx:27732 RTS|DTR
> 6: uart:16550A port:0000E400 irq:185 tx:120958 rx:0 RTS|DTR
> 7: uart:16550A port:0000D000 irq:185 tx:0 rx:0
> 8: uart:16550A port:0000D100 irq:185 tx:0 rx:0 RTS|DTR
> 9: uart:16550A port:0000D200 irq:185 tx:0 rx:123406 RTS|DTR
> 
> It looks like no overruns are reported, but I have to find out whether
> they have reproduced the bug since the last reboot.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: R: How to avoid serial port buffer overruns?

[Lee Revell]

On Fri, 2006-08-18 at 18:04 +0100, Russell King wrote:
> On Fri, Aug 18, 2006 at 01:00:00PM -0400, Lee Revell wrote:
> > On Fri, 2006-08-18 at 10:48 +0200, Giampaolo Tomassoni wrote:
> > > > On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> > > > 
> > > > 
> > > > OK, thanks.  FWIW here is the serial board we are using:
> > > > 
> > > > http://www.moschip.com/html/MCS9845.html
> > > > 
> > > > The hardware guy says "The mn9845cv, have in default 2 serial ports and
> > > > one ISA bus, where we have connected the tl16c554, quad serial port."
> > > > 
> > > > Hopefully Ingo's latency tracer can tell me what is holding off
> > > > interrupts.
> > > 
> > > I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:
> > 
> > OK, they are not using serial-u16550 but 8250_fourport for some reason:
> 
> Doesn't look like it.  fourport cards have their ports at 0x1a0..0x1bf
> and 0x2a0..0x2bf, and have some special and non-standard features.
> 

Which driver is being used then?

# cat /proc/interrupts 
           CPU0       
  0:     801050    IO-APIC-edge  timer
  1:         42    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:      11022    IO-APIC-edge  i8042
 14:       2517    IO-APIC-edge  ide0
169:     536096   IO-APIC-level  ohci1394, ICE1712
185:       3908   IO-APIC-level  eth0, serial
193:       8610   IO-APIC-level  libata
201:        326   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb5
217:      84947   IO-APIC-level  nvidia
NMI:          0 
LOC:     800973 
ERR:          0
MIS:          0

# lsmod | egrep serial\|8250
8250_fourport           2048  0 [permanent]
8250_pnp                8704  0 
parport_serial          7680  0 
parport_pc             31984  1 parport_serial
8250_pci               19968  1 parport_serial
8250                   22704  12 8250_pnp,8250_pci
serial_core            19200  1 8250

Serial: 8250/16550 driver $Revision: 1.90 $ 10 ports, IRQ sharing
enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: AGP aperture is 128M @ 0xe8000000
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Real Time Clock Driver v1.12ac
input: PC Speaker as /class/input/input1
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 185
0000:00:0b.0: ttyS4 at I/O 0xdd00 (irq = 185) is a 16550A
0000:00:0b.0: ttyS5 at I/O 0xe300 (irq = 185) is a 16550A
0000:00:0b.0: ttyS6 at I/O 0xe400 (irq = 185) is a 16550A
0000:00:0b.0: ttyS7 at I/O 0xd000 (irq = 185) is a 16550A
0000:00:0b.0: ttyS8 at I/O 0xd100 (irq = 185) is a 16550A
0000:00:0b.0: ttyS9 at I/O 0xd200 (irq = 185) is a 16550A

Lee

Re: R: How to avoid serial port buffer overruns?

[Russell King]

On Fri, Aug 18, 2006 at 01:30:40PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 18:04 +0100, Russell King wrote:
> > On Fri, Aug 18, 2006 at 01:00:00PM -0400, Lee Revell wrote:
> > > On Fri, 2006-08-18 at 10:48 +0200, Giampaolo Tomassoni wrote:
> > > > > On Thu, 2006-08-17 at 00:19 +0100, Russell King wrote:
> > > > > 
> > > > > 
> > > > > OK, thanks.  FWIW here is the serial board we are using:
> > > > > 
> > > > > http://www.moschip.com/html/MCS9845.html
> > > > > 
> > > > > The hardware guy says "The mn9845cv, have in default 2 serial ports and
> > > > > one ISA bus, where we have connected the tl16c554, quad serial port."
> > > > > 
> > > > > Hopefully Ingo's latency tracer can tell me what is holding off
> > > > > interrupts.
> > > > 
> > > > I beg your pardon: I'm not used that much to interrupts handling in Linux, but this piece of code from sound/drivers/serial-u16550.c in a linux-2.6.16:
> > > 
> > > OK, they are not using serial-u16550 but 8250_fourport for some reason:
> > 
> > Doesn't look like it.  fourport cards have their ports at 0x1a0..0x1bf
> > and 0x2a0..0x2bf, and have some special and non-standard features.
> > 
> 
> Which driver is being used then?
> 
> # lsmod | egrep serial\|8250
> 8250_fourport           2048  0 [permanent]
> 8250_pnp                8704  0 
> parport_serial          7680  0 
> parport_pc             31984  1 parport_serial
> 8250_pci               19968  1 parport_serial
> 8250                   22704  12 8250_pnp,8250_pci
> serial_core            19200  1 8250
> 
> Serial: 8250/16550 driver $Revision: 1.90 $ 10 ports, IRQ sharing
> enabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> Linux agpgart interface v0.101 (c) Dave Jones
> agpgart: Detected AGP bridge 0
> agpgart: AGP aperture is 128M @ 0xe8000000
> parport: PnPBIOS parport detected.
> parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
> Real Time Clock Driver v1.12ac
> input: PC Speaker as /class/input/input1
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 185
> 0000:00:0b.0: ttyS4 at I/O 0xdd00 (irq = 185) is a 16550A
> 0000:00:0b.0: ttyS5 at I/O 0xe300 (irq = 185) is a 16550A
> 0000:00:0b.0: ttyS6 at I/O 0xe400 (irq = 185) is a 16550A
> 0000:00:0b.0: ttyS7 at I/O 0xd000 (irq = 185) is a 16550A
> 0000:00:0b.0: ttyS8 at I/O 0xd100 (irq = 185) is a 16550A
> 0000:00:0b.0: ttyS9 at I/O 0xd200 (irq = 185) is a 16550A

That "0000:00:0b.0" looks like a PCI device ID.  If it were a fourport
board, it would be "serial8250.3" according to the current enumeration
in linux/serial_8250.h.

Also, another give away is that IRQ185 is being setup as a PCI interrupt
immediately prior to the devices being registered.

And I doubt that an ISA board (which is what fourport is) would ever get
such a high IRQ number.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: R: How to avoid serial port buffer overruns?

[Lee Revell]

On Fri, 2006-08-18 at 19:34 +0100, Russell King wrote:
> That "0000:00:0b.0" looks like a PCI device ID.  If it were a fourport
> board, it would be "serial8250.3" according to the current enumeration
> in linux/serial_8250.h.
> 
> Also, another give away is that IRQ185 is being setup as a PCI interrupt
> immediately prior to the devices being registered.
> 
> And I doubt that an ISA board (which is what fourport is) would ever get
> such a high IRQ number.
> 

So you're saying that the standard 8250 driver is being used?

This is the board they are using:

http://www.moschip.com/html/MCS9845.html

Lee

Re: R: How to avoid serial port buffer overruns?

[Russell King]

On Fri, Aug 18, 2006 at 02:52:53PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 19:34 +0100, Russell King wrote:
> > That "0000:00:0b.0" looks like a PCI device ID.  If it were a fourport
> > board, it would be "serial8250.3" according to the current enumeration
> > in linux/serial_8250.h.
> > 
> > Also, another give away is that IRQ185 is being setup as a PCI interrupt
> > immediately prior to the devices being registered.
> > 
> > And I doubt that an ISA board (which is what fourport is) would ever get
> > such a high IRQ number.
> > 
> 
> So you're saying that the standard 8250 driver is being used?

Yes, which is also the case with 8250_fourport.  8250_fourport is just
a probe module just like 8250_pnp or 8250_pci.

> http://www.moschip.com/html/MCS9845.html

That also clearly says its a PCI device. 8)

What problem are we talking about here again?  Sorry, I've completely lost
track and this particular thread of 26 messages is soo convoluted and too
much to re-read.

Since you only appear to be the messenger, wouldn't it be far better to get
the person with the problem to report and respond rather than sitting in
the middle?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: R: How to avoid serial port buffer overruns?

[Russell King]

On Fri, Aug 18, 2006 at 08:01:06PM +0100, Russell King wrote:
> On Fri, Aug 18, 2006 at 02:52:53PM -0400, Lee Revell wrote:
> > On Fri, 2006-08-18 at 19:34 +0100, Russell King wrote:
> > > That "0000:00:0b.0" looks like a PCI device ID.  If it were a fourport
> > > board, it would be "serial8250.3" according to the current enumeration
> > > in linux/serial_8250.h.
> > > 
> > > Also, another give away is that IRQ185 is being setup as a PCI interrupt
> > > immediately prior to the devices being registered.
> > > 
> > > And I doubt that an ISA board (which is what fourport is) would ever get
> > > such a high IRQ number.
> > > 
> > 
> > So you're saying that the standard 8250 driver is being used?
> 
> Yes, which is also the case with 8250_fourport.  8250_fourport is just
> a probe module just like 8250_pnp or 8250_pci.
> 
> > http://www.moschip.com/html/MCS9845.html
> 
> That also clearly says its a PCI device. 8)
> 
> What problem are we talking about here again?  Sorry, I've completely lost
> track and this particular thread of 26 messages is soo convoluted and too
> much to re-read.
> 
> Since you only appear to be the messenger, wouldn't it be far better to get
> the person with the problem to report and respond rather than sitting in
> the middle?

BTW, let's have _one_ email which describes what problem it is, the
hardware which its being seen on, the kernel configuration, what
modules are loaded, the lspci output and so forth.  Let's not spread
all the information over 20 emails.

I just can't work with dribbled small bits of inforamtion sparsely
spread.  Neither can I work when it takes days to get that information -
I forget both the reported details and the thread of thought I was
following to maybe work towards a conclusion.

(Though at present I'm rather devoid of ideas in this area.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: R: How to avoid serial port buffer overruns?

[Lee Revell]

On Fri, 2006-08-18 at 20:01 +0100, Russell King wrote:
> What problem are we talking about here again?  Sorry, I've completely
> lost track and this particular thread of 26 messages is soo convoluted
> and too much to re-read.
> 

I thought I might have been seeing the same problem as the OP, but I've
found it's a separate issue.  I'll start a new thread.

The original poster in this thread was just wondering how to reduce the
number of serial overruns at baud rates over 19200.

> Since you only appear to be the messenger, wouldn't it be far better
> to get the person with the problem to report and respond rather than
> sitting in the middle?

Sorry, it took me a while but I have access to the machine with the
problem now.

Lee