I've found a weird serial bug. My host is a Via EPIA M-6000 running
2.6.17 connected to a PPC Yosemite board running 2.6.13.
In all cases the serial console works great. But, with the default
setting of IRQ 4, Kermit file transfers via the serial interface simply
time out. However if I use polling mode (setserial /dev/ttyS0 irq 0 on
the host), file transfers work.
When set to IRQ 4, the interrupt count does increase.
# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:267 rx:667 DSR|CD
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
# setserial /dev/ttyS0
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
# cat /proc/interrupts
CPU0
0: 175715279 XT-PIC timer
1: 137763 XT-PIC i8042
2: 0 XT-PIC cascade
4: 326 XT-PIC serial
[...]
Any ideas? I'm guessing it might be a quirk of the VIA chipset?
Lee
On Thu, 2006-08-17 at 20:47 -0400, Lee Revell wrote:
> I've found a weird serial bug. My host is a Via EPIA M-6000 running
> 2.6.17 connected to a PPC Yosemite board running 2.6.13.
>
> In all cases the serial console works great. But, with the default
> setting of IRQ 4, Kermit file transfers via the serial interface simply
> time out. However if I use polling mode (setserial /dev/ttyS0 irq 0 on
> the host), file transfers work.
>
> When set to IRQ 4, the interrupt count does increase.
>
> # cat /proc/tty/driver/serial
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:267 rx:667 DSR|CD
> [...]
>
> Any ideas? I'm guessing it might be a quirk of the VIA chipset?
You mention serial console. Hasn't there been some changes
related to reenabling the THRE interrupt after sending
console data? IIRC the changes fixed transmit stalls on
some machines but broke things on other machine.
Can you try disabling the serial console and see
if the file transfer starts working?
--
Paul Fulghum
Microgate Systems, Ltd
On Fri, 2006-08-18 at 10:44 -0500, Paul Fulghum wrote:
> Can you try disabling the serial console and see
> if the file transfer starts working?
>
Is there a way to disable/enable the serial console without rebooting?
Lee
On Fri, 2006-08-18 at 10:44 -0500, Paul Fulghum wrote:
> On Thu, 2006-08-17 at 20:47 -0400, Lee Revell wrote:
> > I've found a weird serial bug. My host is a Via EPIA M-6000 running
> > 2.6.17 connected to a PPC Yosemite board running 2.6.13.
> >
> > In all cases the serial console works great. But, with the default
> > setting of IRQ 4, Kermit file transfers via the serial interface simply
> > time out. However if I use polling mode (setserial /dev/ttyS0 irq 0 on
> > the host), file transfers work.
> >
> > When set to IRQ 4, the interrupt count does increase.
> >
> > # cat /proc/tty/driver/serial
> > serinfo:1.0 driver revision:
> > 0: uart:16550A port:000003F8 irq:4 tx:267 rx:667 DSR|CD
> > [...]
> >
> > Any ideas? I'm guessing it might be a quirk of the VIA chipset?
>
> You mention serial console. Hasn't there been some changes
> related to reenabling the THRE interrupt after sending
> console data? IIRC the changes fixed transmit stalls on
> some machines but broke things on other machine.
>
> Can you try disabling the serial console and see
> if the file transfer starts working?
>
I tried it with the serial console inactive (not disabled) and file
transfers don't work whether I set IRQ 0 or 4. Maybe I'm doing it wrong
- I connected to the target via SSH and ran "gkermit -r" then ran
ckermit locally and issued a "send file.txt" command.
Normally I connect to the target with "kermit -c" which gives me a
serial console, then issue a "gkermit -r", then escape to my local
Kermit and issue the send file command.
Lee
On Fri, 2006-08-18 at 10:44 -0500, Paul Fulghum wrote:
> On Thu, 2006-08-17 at 20:47 -0400, Lee Revell wrote:
> > I've found a weird serial bug. My host is a Via EPIA M-6000 running
> > 2.6.17 connected to a PPC Yosemite board running 2.6.13.
> >
> > In all cases the serial console works great. But, with the default
> > setting of IRQ 4, Kermit file transfers via the serial interface simply
> > time out. However if I use polling mode (setserial /dev/ttyS0 irq 0 on
> > the host), file transfers work.
> >
> > When set to IRQ 4, the interrupt count does increase.
> >
> > # cat /proc/tty/driver/serial
> > serinfo:1.0 driver revision:
> > 0: uart:16550A port:000003F8 irq:4 tx:267 rx:667 DSR|CD
> > [...]
> >
> > Any ideas? I'm guessing it might be a quirk of the VIA chipset?
>
> You mention serial console. Hasn't there been some changes
> related to reenabling the THRE interrupt after sending
> console data? IIRC the changes fixed transmit stalls on
> some machines but broke things on other machine.
I tried Paul's suggestion:
--- drivers/serial/8250.c~ 2006-06-17 21:49:35.000000000 -0400
+++ drivers/serial/8250.c 2006-08-18 12:57:16.000000000 -0400
@@ -2263,7 +2263,7 @@
* and restore the IER
*/
wait_for_xmitr(up, BOTH_EMPTY);
- serial_out(up, UART_IER, ier);
+ serial_out(up, UART_IER, ier | UART_IER_THRI);
if (locked)
spin_unlock_irqrestore(&up->port.lock, flags);
But it had no effect.
Could it be a hardware-specific bug? After all VIA chipsets are
notorious for interrupts not working right.
Any other suggestions?
Lee
Lee Revell wrote:
> But it had no effect.
>
> Could it be a hardware-specific bug? After all VIA chipsets are
> notorious for interrupts not working right.
>
> Any other suggestions?
I can't think of any. The interrupts are occurring
and being serviced. Nothing else seems to be sitting
on that interrupt. It's reaching a bit: maybe there
is some console output interfering with the
file transfer protocol, but it only occurs with
interrupt enabled because of some initial timing?
(polling mode may delay things enough to work)
What protocol is ckermit using? (zmodem, etc)
--
Paul Fulghum
Microgate Systems, Ltd.
On Fri, 2006-08-18 at 13:11 -0500, Paul Fulghum wrote:
> Lee Revell wrote:
> > But it had no effect.
> >
> > Could it be a hardware-specific bug? After all VIA chipsets are
> > notorious for interrupts not working right.
> >
> > Any other suggestions?
>
> I can't think of any. The interrupts are occurring
> and being serviced. Nothing else seems to be sitting
> on that interrupt. It's reaching a bit: maybe there
> is some console output interfering with the
> file transfer protocol, but it only occurs with
> interrupt enabled because of some initial timing?
> (polling mode may delay things enough to work)
> What protocol is ckermit using? (zmodem, etc)
>
I think it's just using the kermit file transfer protocol.
Lee
On Fri, Aug 18, 2006 at 02:17:04PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 13:11 -0500, Paul Fulghum wrote:
> > Lee Revell wrote:
> > > But it had no effect.
> > >
> > > Could it be a hardware-specific bug? After all VIA chipsets are
> > > notorious for interrupts not working right.
> > >
> > > Any other suggestions?
> >
> > I can't think of any. The interrupts are occurring
> > and being serviced. Nothing else seems to be sitting
> > on that interrupt. It's reaching a bit: maybe there
> > is some console output interfering with the
> > file transfer protocol, but it only occurs with
> > interrupt enabled because of some initial timing?
> > (polling mode may delay things enough to work)
> > What protocol is ckermit using? (zmodem, etc)
> >
>
> I think it's just using the kermit file transfer protocol.
Are you transferring from or two the machine which is having a problem?
IOW, is the problem machine doing lots of receive or lots of transmit?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Fri, 2006-08-18 at 19:36 +0100, Russell King wrote:
> On Fri, Aug 18, 2006 at 02:17:04PM -0400, Lee Revell wrote:
> Are you transferring from or two the machine which is having a problem?
> IOW, is the problem machine doing lots of receive or lots of transmit?
>
Neither uploads nor downloads work in interrupt mode. Both work in
polled mode.
Lee
On Fri, Aug 18, 2006 at 02:40:05PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 19:36 +0100, Russell King wrote:
> > On Fri, Aug 18, 2006 at 02:17:04PM -0400, Lee Revell wrote:
> > Are you transferring from or two the machine which is having a problem?
> > IOW, is the problem machine doing lots of receive or lots of transmit?
> >
>
> Neither uploads nor downloads work in interrupt mode. Both work in
> polled mode.
Ho hum. This probably requires the use of a serial splitter so that
an independent known good machine can monitor what's being sent by
each end.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Russell King wrote:
> On Fri, Aug 18, 2006 at 02:40:05PM -0400, Lee Revell wrote:
>
>>On Fri, 2006-08-18 at 19:36 +0100, Russell King wrote:
>>
>>>On Fri, Aug 18, 2006 at 02:17:04PM -0400, Lee Revell wrote:
>>>Are you transferring from or two the machine which is having a problem?
>>>IOW, is the problem machine doing lots of receive or lots of transmit?
>>>
>>
>>Neither uploads nor downloads work in interrupt mode. Both work in
>>polled mode.
>
>
> Ho hum. This probably requires the use of a serial splitter so that
> an independent known good machine can monitor what's being sent by
> each end.
Since you have 2 serial ports, can you test
using ttyS1 as the console (kernel boot parameter console=ttyS1)
and do a transfer on ttyS0 (interrupt mode) with a separate
connection to another machine?
This at least removes interaction with the console
from the picture.
--
Paul Fulghum
Microgate Systems, Ltd.
On Fri, Aug 18, 2006 at 02:06:59PM -0500, Paul Fulghum wrote:
> Russell King wrote:
> >On Fri, Aug 18, 2006 at 02:40:05PM -0400, Lee Revell wrote:
> >
> >>On Fri, 2006-08-18 at 19:36 +0100, Russell King wrote:
> >>
> >>>On Fri, Aug 18, 2006 at 02:17:04PM -0400, Lee Revell wrote:
> >>>Are you transferring from or two the machine which is having a problem?
> >>>IOW, is the problem machine doing lots of receive or lots of transmit?
> >>>
> >>
> >>Neither uploads nor downloads work in interrupt mode. Both work in
> >>polled mode.
> >
> >
> >Ho hum. This probably requires the use of a serial splitter so that
> >an independent known good machine can monitor what's being sent by
> >each end.
>
> Since you have 2 serial ports, can you test
> using ttyS1 as the console (kernel boot parameter console=ttyS1)
> and do a transfer on ttyS0 (interrupt mode) with a separate
> connection to another machine?
Who are you referring to? Since your message was addressed to me, one
would assume you want _me_ to do it, but somehow I suspect you're really
asking Lee. Please be more careful with your To: and CC: _and_ which
message you're replying to.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Fri, 18 Aug 2006, Lee Revell wrote:
> On Fri, 2006-08-18 at 13:11 -0500, Paul Fulghum wrote:
>> Lee Revell wrote:
>>> But it had no effect.
>>>
>>> Could it be a hardware-specific bug? After all VIA chipsets are
>>> notorious for interrupts not working right.
>>>
>>> Any other suggestions?
>>
>> I can't think of any. The interrupts are occurring
>> and being serviced. Nothing else seems to be sitting
>> on that interrupt. It's reaching a bit: maybe there
>> is some console output interfering with the
>> file transfer protocol, but it only occurs with
>> interrupt enabled because of some initial timing?
>> (polling mode may delay things enough to work)
>> What protocol is ckermit using? (zmodem, etc)
>>
>
> I think it's just using the kermit file transfer protocol.
>
> Lee
A file-transfer protocol??? Has he got hardware the __required__
hardware flow-control enabled on both ends? One can't spew
high-speed serial data out forever without a hardware handshake.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Fri, 2006-08-18 at 15:15 -0400, linux-os (Dick Johnson) wrote:
> A file-transfer protocol??? Has he got hardware the __required__
> hardware flow-control enabled on both ends? One can't spew
> high-speed serial data out forever without a hardware handshake.
>
Interesting you should mention that. As a matter of fact I have to
disable all flow control or the serial console doesn't even work. I
considered this a minor issue and had forgotten about it.
But, in polled mode with no flow control I can transfer a 10MB file.
There are a lot of retransmits but it works.
Lee
On Fri, 18 Aug 2006, Lee Revell wrote:
> On Fri, 2006-08-18 at 15:15 -0400, linux-os (Dick Johnson) wrote:
>> A file-transfer protocol??? Has he got hardware the __required__
>> hardware flow-control enabled on both ends? One can't spew
>> high-speed serial data out forever without a hardware handshake.
>>
>
> Interesting you should mention that. As a matter of fact I have to
> disable all flow control or the serial console doesn't even work. I
> considered this a minor issue and had forgotten about it.
>
> But, in polled mode with no flow control I can transfer a 10MB file.
> There are a lot of retransmits but it works.
>
> Lee
>
Using RS-232C for file transfer and as a serial console are two
different things. Many terminals and terminal emulators don't
even activate RTS/CTS. If you are just getting data from the
output of a UART to view on a screen, the data usually comes
in spurts, a line at a time, and a screen at a time. There
is plenty of time for the receiving terminal to write the
stuff to the screen.
However, with file transfers, data streams with no breaks.
There needs to be time for these buffers of data to be written
to files, etc., or else you eventually run out of buffers even
if no interrupts are ever lost. Therefore, you must use hardware
handshake. In other words, you need to connect your machines
together with a complete null-modem cable, not just three wires.
Then both machines need to cooperate, i.e., the receiving machine
needs to lower CTS before its buffers get full and the sender,
must look at its RTS bit and wait for it to go false before
sending anymore data. Failure to do this __will__ result in
lost data.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) wrote:
> On Fri, 18 Aug 2006, Lee Revell wrote:
>
>> On Fri, 2006-08-18 at 15:15 -0400, linux-os (Dick Johnson) wrote:
>>> A file-transfer protocol??? Has he got hardware the __required__
>>> hardware flow-control enabled on both ends? One can't spew
>>> high-speed serial data out forever without a hardware handshake.
>>>
>> Interesting you should mention that. As a matter of fact I have to
>> disable all flow control or the serial console doesn't even work. I
>> considered this a minor issue and had forgotten about it.
>>
>> But, in polled mode with no flow control I can transfer a 10MB file.
>> There are a lot of retransmits but it works.
>>
>> Lee
>>
>
> Using RS-232C for file transfer and as a serial console are two
> different things. Many terminals and terminal emulators don't
> even activate RTS/CTS. If you are just getting data from the
> output of a UART to view on a screen, the data usually comes
> in spurts, a line at a time, and a screen at a time. There
> is plenty of time for the receiving terminal to write the
> stuff to the screen.
>
> However, with file transfers, data streams with no breaks.
> There needs to be time for these buffers of data to be written
> to files, etc., or else you eventually run out of buffers even
> if no interrupts are ever lost. Therefore, you must use hardware
> handshake. In other words, you need to connect your machines
> together with a complete null-modem cable, not just three wires.
> Then both machines need to cooperate, i.e., the receiving machine
> needs to lower CTS before its buffers get full and the sender,
> must look at its RTS bit and wait for it to go false before
> sending anymore data. Failure to do this __will__ result in
> lost data.
>
Don't mean to but it but:
Take it from someone who actually still uses dumb terminals every day, any thing
over 9600 baud still requires some kind of flow control for reliable consistent
operation. Software (Xon/Xoff) and or hardware (RTS/RTS/DTE) flow control.
Mark
On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
> Take it from someone who actually still uses dumb terminals every day,
> any thing over 9600 baud still requires some kind of flow control for
> reliable consistent operation. Software (Xon/Xoff) and or hardware
> (RTS/RTS/DTE) flow control.
>
Any idea why the serial console does not work at all with flow control
enabled (regardless of whether the host runs Linux or another OS)?
Lee
Lee Revell wrote:
> On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
>> Take it from someone who actually still uses dumb terminals every day,
>> any thing over 9600 baud still requires some kind of flow control for
>> reliable consistent operation. Software (Xon/Xoff) and or hardware
>> (RTS/RTS/DTE) flow control.
>>
>
> Any idea why the serial console does not work at all with flow control
> enabled (regardless of whether the host runs Linux or another OS)?
>
> Lee
>
>
Your cable is probably wrong. Both ends have to be using the type of flow
control your cable is wired for.
Mark
On Fri, Aug 18, 2006 at 04:28:36PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
> > Take it from someone who actually still uses dumb terminals every day,
> > any thing over 9600 baud still requires some kind of flow control for
> > reliable consistent operation. Software (Xon/Xoff) and or hardware
> > (RTS/RTS/DTE) flow control.
> >
>
> Any idea why the serial console does not work at all with flow control
> enabled (regardless of whether the host runs Linux or another OS)?
I use serial console with flow control and haven't seen any problems.
Can you describe your issue with more detail?
What actions are required to get this "does not work at all" state?
Are you passing a kernel parameter to enable flow control?
Are you saying that you get kernel messages if flow control is disabled,
but if you subsequently enable flow control, and provoke a kernel message,
you don't see any messages? When you re-disable flow control, you do?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Fri, Aug 18, 2006 at 04:32:43PM -0400, Mark Hounschell wrote:
> Lee Revell wrote:
> > On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
> >> Take it from someone who actually still uses dumb terminals every day,
> >> any thing over 9600 baud still requires some kind of flow control for
> >> reliable consistent operation. Software (Xon/Xoff) and or hardware
> >> (RTS/RTS/DTE) flow control.
> >>
> >
> > Any idea why the serial console does not work at all with flow control
> > enabled (regardless of whether the host runs Linux or another OS)?
> >
> > Lee
> >
> >
>
> Your cable is probably wrong. Both ends have to be using the type of flow
> control your cable is wired for.
Not quite true. You can use XON/XOFF or hardware flow with a fully
populated cable, but if you have a sparsely populated cable (RX,TX,GND
only) then hardware flow control can't (and won't) work.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Fri, 2006-08-18 at 21:34 +0100, Russell King wrote:
> On Fri, Aug 18, 2006 at 04:28:36PM -0400, Lee Revell wrote:
> > On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
> > > Take it from someone who actually still uses dumb terminals every day,
> > > any thing over 9600 baud still requires some kind of flow control for
> > > reliable consistent operation. Software (Xon/Xoff) and or hardware
> > > (RTS/RTS/DTE) flow control.
> > >
> >
> > Any idea why the serial console does not work at all with flow control
> > enabled (regardless of whether the host runs Linux or another OS)?
>
> I use serial console with flow control and haven't seen any problems.
>
> Can you describe your issue with more detail?
>
> What actions are required to get this "does not work at all" state?
>
> Are you passing a kernel parameter to enable flow control?
>
> Are you saying that you get kernel messages if flow control is disabled,
> but if you subsequently enable flow control, and provoke a kernel message,
> you don't see any messages? When you re-disable flow control, you do?
>
I believe the flow control problem is due to my cable.
Anyway I don't want to confuse the issue: the problem that I want to
solve (or at least explain) is that while the serial console works with
the host serial port in both interrupt and polled mode, kermit file
transfers only work in polled mode ("setserial /dev/ttyS0 irq 0").
It's not a showstopper, it just seems weird, and I thought it might
indicate a kernel bug.
Lee
Russell King wrote:
> On Fri, Aug 18, 2006 at 04:32:43PM -0400, Mark Hounschell wrote:
>> Lee Revell wrote:
>>> On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
>>>> Take it from someone who actually still uses dumb terminals every day,
>>>> any thing over 9600 baud still requires some kind of flow control for
>>>> reliable consistent operation. Software (Xon/Xoff) and or hardware
>>>> (RTS/RTS/DTE) flow control.
>>>>
>>> Any idea why the serial console does not work at all with flow control
>>> enabled (regardless of whether the host runs Linux or another OS)?
>>>
>>> Lee
>>>
>>>
>> Your cable is probably wrong. Both ends have to be using the type of flow
>> control your cable is wired for.
>
> Not quite true. You can use XON/XOFF or hardware flow with a fully
> populated cable, but if you have a sparsely populated cable (RX,TX,GND
> only) then hardware flow control can't (and won't) work.
>
Ok I should have said. Both ends have to be using the type of flow
control your cable is wired for if you are using hardware flow control and you
expect it to work correctly.
If you have the hardware signals wired wrong, depending on how it is actually
wrong, and you are using hardware flow control, anything to nothing can happen.
I have incorrectly tied CTS to gnd(false) on both ends, I have CTS/RTS flow
control enabled, why don't I get any data on either end?
Is there a definition of a fully populated cable? Obviously if all you have
wired it xmit/rcve hardware flow control won't work.
Mark
On Fri, Aug 18, 2006 at 04:54:13PM -0400, Lee Revell wrote:
> On Fri, 2006-08-18 at 21:34 +0100, Russell King wrote:
> > On Fri, Aug 18, 2006 at 04:28:36PM -0400, Lee Revell wrote:
> > > On Fri, 2006-08-18 at 16:25 -0400, Mark Hounschell wrote:
> > > > Take it from someone who actually still uses dumb terminals every day,
> > > > any thing over 9600 baud still requires some kind of flow control for
> > > > reliable consistent operation. Software (Xon/Xoff) and or hardware
> > > > (RTS/RTS/DTE) flow control.
> > > >
> > >
> > > Any idea why the serial console does not work at all with flow control
> > > enabled (regardless of whether the host runs Linux or another OS)?
> >
> > I use serial console with flow control and haven't seen any problems.
> >
> > Can you describe your issue with more detail?
> >
> > What actions are required to get this "does not work at all" state?
> >
> > Are you passing a kernel parameter to enable flow control?
> >
> > Are you saying that you get kernel messages if flow control is disabled,
> > but if you subsequently enable flow control, and provoke a kernel message,
> > you don't see any messages? When you re-disable flow control, you do?
> >
>
> I believe the flow control problem is due to my cable.
>
> Anyway I don't want to confuse the issue: the problem that I want to
> solve (or at least explain) is that while the serial console works with
> the host serial port in both interrupt and polled mode, kermit file
> transfers only work in polled mode ("setserial /dev/ttyS0 irq 0").
If you're talking about sending via a polled port, the average data rate
is probably slow enough that the receiving side can keep up. But in
interrupt mode, it's probably a stream of characters at the specified
baud rate, which results in lost characters.
That explaination doesn't resolve the receiving via a polled port though.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core