Bug 212735 - Fedora Core 6, serial port access problem
Fedora Core 6, serial port access problem
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2006-10-28 11:54 EDT by Alexander
Modified: 2009-12-14 15:39 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 20:24:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander 2006-10-28 11:54:32 EDT
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
minicom 2.1

How reproducible:
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
Actual results:
No answer from the conterpart device, the staus bar (Ctrl-A) shows baud rate 0.  

Expected results:
Comminication with a dvice, the staus bar (Ctrl-A) shows baud rate 115200.  

Additional info:
Comment 1 Miroslav Lichvar 2006-11-01 09:10:56 EST
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.
Comment 2 Alexander 2006-11-01 11:24:40 EST
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. 
Comment 3 Matt Pearce 2006-11-16 13:58:34 EST
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.
Comment 4 Matt Pearce 2006-11-16 14:44:27 EST
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
Comment 5 jpsied 2006-12-02 20:41:23 EST
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
Comment 6 Jim Thorsley 2007-02-19 16:01:10 EST
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.
Comment 7 Ambrusius Widiyatmika 2007-03-24 22:29:09 EDT
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
        closing_wait: 3000
        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
        closing_wait: 3000
        Flags: spd_normal skip_test auto_irq

Please help to solve this problem.

Comment 8 Stephen Tweedie 2007-03-26 09:56:00 EDT
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?
Comment 9 Ambrusius Widiyatmika 2007-03-26 12:15:58 EDT
(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
Comment 10 Stephen Tweedie 2007-03-26 12:35:21 EDT
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!
Comment 11 Eric Maryniak 2007-04-11 06:36:39 EDT
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
(Palm) PDA...
Comment 12 Stephen Tweedie 2007-04-18 07:26:33 EDT
re comment #11: is this using the xen kernel or not?  Thanks.
Comment 13 Thomas Vander Stichele 2007-04-25 14:06:31 EDT
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)
        root (hd0,2)
        kernel /vmlinuz-2.6.18-8.el5 ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.18-8.el5.img

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)'               
root (hd0,2)                                                                
 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
console=tty pnpacpi=off                                                     
   [Multiboot-module @ 0x1de000, 0x43f644 bytes]                            
module /initrd-2.6.18-8.el5xen.img                                          
And this is where it stops.
Comment 14 Red Hat Bugzilla 2007-07-24 21:34:12 EDT
change QA contact
Comment 15 Chris Lalancette 2008-02-26 20:24:03 EST
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

Chris Lalancette

Note You need to log in before you can comment on or make changes to this bug.