Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I got a brain smashing problem with Fedora 16 and my serial port.

I use the serial to monitor an STB on which I'm developping. The STB runs on Linux and when booted, I launch the program I'm working on through the serial interface.

Now, my program outputs lots of traces when I'm debugging, and I get loads of buffer overrun errors in dmesg.

This makes debugging the application a mess, because the serial output gets unreadable.

So, what's bothering me is that when I was running on Fedora 15, there was no buffer overrun at all!

Some more details on my setup:

  • Fedora Core 16 under Cinnamon / gnome-terminal for the serial. Uname: 3.2.6-3.fc16.x86_64
  • to connect the serial port, I use this command: screen -R -d -t "Serial" /dev/ttyS0 115200

Any idea of how I could fix that?

(some more details:)

$ cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:3395 rx:11899157 fe:6 brk:4 oe:3496 RTS|DTR
###                                                               ^^^^^^^
###                                                            overflow errors
1: uart:16550A port:0000EC98 irq:17 tx:32 rx:0 CTS|DSR|CD
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3

Typical dmegs output:

[370425.080452] ttyS0: 24 input overrun(s)
[370426.092382] ttyS0: 30 input overrun(s)
[370427.109291] ttyS0: 36 input overrun(s)
[370428.173344] ttyS0: 28 input overrun(s)
[370429.583198] ttyS0: 26 input overrun(s)
[370430.638700] ttyS0: 32 input overrun(s)

:( :( :(

Output of sudo setserial -v -a -g /dev/ttyS0:

/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test low_latency
share|improve this question
1  
Can you enable hardware flow control on your STB? It's not clear if screen allows you to set the crtscts flag, so I'm not sure whether or not this might work. You could use something like kermit or minicom or something that does have explicit support for setting the hardware flow-control flag... –  larsks Mar 2 '12 at 21:17
    
Yeah I'll try that on monday. Although I don't understand why on Fedora 15 it was working like a charm! –  Gui13 Mar 2 '12 at 21:40
    
So... didn't work either. My machine is a c2d e8400, which I guess is not supposed to fail that many serial interruptions, no? –  Gui13 Mar 5 '12 at 12:43
    
Bummer. I'm running F16 with some serial attached devices (a pair of v.everything modems. Don't ask.) and I haven't noticed any problems...but on the other hand, I'm not really driving anything very hard. I'm using USB-to-serial adapters rather than the native serial port(s). I'm out of ideas for you at this point. Let us know if you're able to get things going, because I'm curious! –  larsks Mar 5 '12 at 14:28
    
I tried running powertop to see what was making that many interruptions, and I enabled whatever was enablable, but still no luck. I'll try with another WM (I use Cinnamon.. maybe it's him?) and without any other program running just to be sure. But this issue is absolutely mind boggling... –  Gui13 Mar 5 '12 at 19:52
show 3 more comments

2 Answers

up vote 2 down vote accepted
+100

According to the Fedora 16 documentation /etc/rc.serial is responsible for setting up the serial lines.

Has anything changed here between your 15 and 16 install?

Setting "low latency" and "rx/tx_trigger" (if possible) might help.

I remember that the 16550A has a 15-byte-input-buffer. Somehow you can set at which fill-level an interrupt is being generated - I used 7 bytes for a tradeoff between reliability and speed (with DOS). Perhaps the rx/tx-trigger about does a comparable tuning.

Update 2012-03-12:

I just checked on my workstation (CentOS5 - should be comparable to Fedora):

rpm -qd setserial shows the available documentation. There is a README and a sample rc.serial file - see the README.

Apart from that - I looked again at your output: spd_normal does not look ok to me. You want 115 kb - so you propably should set spd_vhi (see man setserial). The reason for this is that you can not request more than 38.4 kb, since the UART-standard did not allow for more. Later on came 57.6kb then 115kb - there had to be a "trick" to set these speeds, too.

share|improve this answer
    
Do you have a /etc/rc.serial example for me? I've shuffled through the setserial manual to find some options to tinker with, to no avail for the moment. –  Gui13 Mar 12 '12 at 9:04
    
I tried the low_latency option but it doesn't seem to change anything. –  Gui13 Mar 12 '12 at 9:21
    
@Gui13 As I said - the last time I did this it was under DOS. But I'll update my answer with other findings. –  Nils Mar 12 '12 at 11:34
add comment

I ran into a similar problem. I was able to isolate this to another device competing for interrupt servicing time. In my case, my laptop's SD Card Reader was competing for time with my serial device. I disabled the card reader driver (rmmod) and the overruns went away. You can see the devices on the same IRQ using: cat /proc/interrupts

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.