Red Hat Bugzilla – Bug 212735
Fedora Core 6, serial port access problem
Last modified: 2009-12-14 15:39:56 EST
Description of problem: I am using the minicom utility to communicate with my
target board over the serial port. I have been using this utility for years on
Fedora Core 4 & 5 platform with no problem. recently I installed the latest
version Fedora Core 6 and tried to do the same I have not response from my
target, the minicom status bar always indicates the baud rate zero regardless of
the current setings . I am using the same minicom configuration file for both
Core 5 and Core 6 platform; each time when I step back to Fedora Core 5 the
problem goes away.
I believe that the origin of the problem is in the serial port driver ttyS or
system kernel itself, because gterm, another utility that I tried to use, does
not work under Fedora Core 6 either with multiple “Control signals read: Invalid
argument” messages on the screen..
Version-Release number of selected component (if applicable):
Fedora Core 6 2.6.18-1.2798.fc6xen
Please, start the minicom utility and try to communicate with another conputer
over serial port with the following settings: Baud rate: 115200 8N1 xonxoff No.
Steps to Reproduce:
1.minicom -s com0
2.Serial port settings: A - Serial device: /dev/ttyS0
E - Bps/Par/Bits : 115200 8N1
F - Hardwar flow Control: No
E - Sftware Flow Control: No
3.Modem and Dialing ... A - Init string: ~^M~
4.Save settings and restart minicom: minicom com0
No answer from the conterpart device, the staus bar (Ctrl-A) shows baud rate 0.
Comminication with a dvice, the staus bar (Ctrl-A) shows baud rate 115200.
I can't reproduce it on FC6 with kernel 2.6.18-1.2798.fc6.
minicom in FC6 is basically the same as in FC5. Reassigning to kernel component.
Yes, in both packages minicom is the same, in both cases it reports as minicom v
2.1 I took mincom utility as an example, another serial terminal utility for
instance gterm does not work either. My impression that it is the
system/driver problem. Let me explain how I conducted my tests.
I am using two removable hard disks on one of which is recently installed FC6
another with FC5. I switch from one version to another by replacing my hard
drive with no other changes in hardware configuration. I also has copied my old
minirc.com0 configuration file from FC5 to FC6 disk. Each time when I run
minicom in FC6 platform there is no answer from the target and the staus bar
(Ctrl-A) shows baud rate 0.
I have a similar problem in that none of my serial ports are detected in FC6.
I believe that xen has something to do with it. It appears that xen hijacks ttyS0.
I have reassigned the xen tty port but setserial /dev/ttyS0 still doesnt work.
I know for a fact that my serial ports are working, they work fine in Windows
and other versions of linux.
I have managed to get my serial ports working now.
setserial -a /dev/ttyS0 - this confirms it
I had to install the non-xen kernel in order to get linux to find the serial ports
I have the same problem, trying to use a perl-script that talks to my
AcerISDNt50 modem/phonesystem. On Windos and FC3 it works/worked fine. Using
GtkTerm the port doesnt work either. PHP (fopen etc.) doesn't connect as well.
Using setserial -a /dev/ttyS0 as proposed above returns an error
Cannot get serial info: Invalid argument
I seem to have this problem too. The serial port doesn't work on FC6 but does
with FC5, Windows XP, and Solaris Belenix (live CD). I try to use mincom or
kermit and get errors and "ttyS0: LSR safety check engaged" in my messages file.
Kermit says "ttyS0 is not a terminal device". Setserial reports no errors though.
I've discovered the problem crops up between version 2.6.16 and 2.6.17 of the
kernel. I build several kernels obtained from linuxhq.com and tested each of
them. The serial ports work fine on my desktops. This problem appears on my HP
Compaq nc6000 laptop.
I have a problem with my /dev/ttyS1 that usually i use it to console my routers
and switches. I have no problem like this when i used my previous linux (fedora
core 4). It happens when i move to fedora core 6.
I use minicom to console my routers and switches. for temporary the problem can
be solved by using usb-serial adapter (/dev/ttyUSB0). it is rather strange, i
have serial port in my laptop, but i have to use usb-serial adapter to console
my routers and switches.
[root@my-linux01 ~]# setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
[root@my-linux01 ~]# setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
Flags: spd_normal skip_test
[root@my-linux01 ~]# setserial -a /dev/ttyS1
/dev/ttyS1, Line 1, UART: unknown, Port: 0x02f8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
Flags: spd_normal skip_test auto_irq
Please help to solve this problem.
re comment #7: this bug report is specifically for serial port issues when using
the Xen kernel. Are you using xen in this case too?
(In reply to comment #8)
> re comment #7: this bug report is specifically for serial port issues when using
> the Xen kernel. Are you using xen in this case too?
No, i use non-xen kernel. my kernel version is 2.6.20-1.2925_1.fc6
OK --- this bug is against the "kernel-xen" component; if you have a problem
against the base kernel, please open a bug against plain "kernel". Thanks!
Same problem when I try to use a serial mouse attached to /dev/ttyS0 in Fedora 7
test 3 (kernel 2.6.20-1.3023.fc7), /var/log/messages:
kernel: ttyS0: LSR safety check engaged!
This is a biggie for people (like) who still need the serial, e.g. to sync their
re comment #11: is this using the xen kernel or not? Thanks.
I am having the same problem on rhel5, which is close to fc6.
I am using Dell Poweredge 1950 machines. I have a symptom happening earlier,
since I redirect kernel output to the serial console so I can see it using
This works fine with the non-xen kernel, with these grub lines:
title Red Hat Enterprise Linux Server (2.6.18-8.el5)
kernel /vmlinuz-2.6.18-8.el5 ro root=/dev/VolGroup00/LogVol00
I can see the whole boot process, and have agetty connect a terminal.
Doing the same with the xen kernel shows me only part of the boot output:
Booting 'Red Hat Enterprise Linux Server (2.6.18-8.el5xen)'
Filesystem type is ext2fs, partition type 0x83
kernel /xen.gz-2.6.18-8.el5 com2=57600,8n1 sync_console
[Multiboot-elf, <0x100000:0x935f8:0x49a08>, shtab=0x1dd078, entry=0x100000]
module /vmlinuz-2.6.18-8.el5xen roeroot=/dev/VolGroup00/LogVol00 console=ttyS1
[Multiboot-module @ 0x1de000, 0x43f644 bytes]
And this is where it stops.
change QA contact
Well, there are a couple of things to worry about here. The first is that when
you are using com2, you generally have to specify an additional parameter saying
"console=com2L" on the hypervisor command-line. The second problem is that even
when you are using com2, it is passed through as ttyS0 to the dom0 kernel, so
your "module /vmlinuz..." line should have console=ttyS0 at the end, instead of
ttyS1. If you try those two suggestions on RHEL-5, do you get any better
results? FYI, I'm going to close this bug out as WONTFIX because it is against
FC-6, but if you want to continue the discussion, please open a new bug against