2.6.25.3: serial problem (minicom)

2.6.25.3: serial problem (minicom)

[Chris Rankin]

Hi,

I have two Linux boxes connected by a null-modem cable between their serial ports; one box exports
a serial console, which the other reads using the minicom program. However, I have noticed that
minicom can no longer use the serial console when it is running on a 2.6.25.3 kernel, although it
works fine running on a 2.6.24.4 kernel.

Specifically, with minicom running on 2.6.25.3, the console does not accept keystrokes although it
does receive the boot log from the remote machine.

The serial console is being exported by a 2.6.25.3 kernel, and appears to be working correctly.

Here is the dmesg log for the kernel hosting minicom, which is using ttyS0:

Linux version 2.6.25.3 (chris@volcano.underworld) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33))
#1 Sat May 10 14:41:58 BST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 0000000000100000 - 0000000004000000 (usable)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
64MB LOWMEM available.
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Entering add_active_range(0, 0, 16384) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    16384
On node 0 totalpages: 16384
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 96 pages used for memmap
  Normal zone: 12192 pages, LIFO batch:1
  Movable zone: 0 pages used for memmap
DMI 2.0 present.
Allocating PCI resources starting at 10000000 (gap: 04000000:fbfc0000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: BOOT_IMAGE=2.6.25.3 ro root=302 mce video=matroxfb:vesa:0x11A
No local APIC present or hardware disabled
mapped APIC to ffffb000 (01081000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0318000 soft=c0317000
PID hash table entries: 256 (order: 8, 1024 bytes)
Detected 199.433 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62272k/65536k available (1376k kernel code, 2852k reserved, 590k data, 156k init, 0k
highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb9000 - 0xfffff000   ( 280 kB)
    vmalloc : 0xc4800000 - 0xfffb7000   ( 951 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
      .init : 0xc02ed000 - 0xc0314000   ( 156 kB)
      .data : 0xc0258156 - 0xc02ebc00   ( 590 kB)
      .text : 0xc0100000 - 0xc0258156   (1376 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 399.42 BogoMIPS (lpj=1997102)
Mount-cache hash table entries: 512
Intel Pentium with F0 0F bug - workaround enabled.

Intel old style machine check architecture supported.
Intel old style machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel Pentium MMX stepping 03
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 0k freed
net_namespace: 536 bytes
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd2c1, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00f9f60
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xa060, dseg 0x400
PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
system 00:08: iomem range 0xe8000-0xfffff could not be reserved
system 00:08: iomem range 0x0-0x9ffff could not be reserved
system 00:08: iomem range 0x100000-0x3ffffff could not be reserved
system 00:08: iomem range 0xfffc0000-0xffffffff could not be reserved
system 00:08: iomem range 0x0-0x0 could not be reserved
system 00:08: iomem range 0x0-0x0 could not be reserved
system 00:08: iomem range 0x0-0x0 could not be reserved
system 00:08: iomem range 0x0-0x0 could not be reserved
system 00:08: iomem range 0x0-0x0 could not be reserved
PCI: Bridge: 0000:00:0e.0
  IO window: f000-ffff
  MEM window: 0xff100000-0xff9fffff
  PREFETCH window: 0x00000000ff000000-0x00000000ff0fffff
PCI: Setting latency timer of device 0000:00:0e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler deadline registered (default)
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:07.0: Activating ISA DMA hang workarounds
pci 0000:00:0d.0: Boot video device
pci 0000:01:05.0: Firmware left e100 interrupts enabled; disabling
pci 0000:01:04.0: Firmware left e100 interrupts enabled; disabling
pci 0000:00:0f.0: Firmware left e100 interrupts enabled; disabling
matroxfb: Matrox Millennium II (PCI) detected
PInS memtype = 0
matroxfb: 1280x1024x16bpp (virtual: 1280x1638)
matroxfb: framebuffer at 0xFB000000, mapped to 0xc4880000, size 4194304
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
isapnp: Scanning for PnP cards...
pnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative ViBRA16C PnP'
isapnp: Card 'U.S. Robotics 56K Voice INT'
isapnp: 2 Plug & Play cards detected total
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial: probe of 00:0d failed with error -16
serial 01:02.00: activated
01:02.00: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX3: IDE controller (0x8086:0x7010 rev 0x00) at  PCI slot 0000:00:07.1
PIIX3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xefa0-0xefa7, BIOS settings: hda:PIO, hdb:PIO
    ide1: BM-DMA at 0xefa8-0xefaf, BIOS settings: hdc:PIO, hdd:PIO
Probing IDE interface ide0...
hda: WDC AC33200L, ATA DISK drive
hdb: WDC AC35100L, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: MWDMA2 mode selected
hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdb: MWDMA2 mode selected
Probing IDE interface ide1...
hdc: TOSHIBA CD-ROM XM-6002B, ATAPI CD/DVD-ROM drive
hdc: applying conservative PIO "downgrade"
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO2
hdc: MWDMA1 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 6346368 sectors (3249 MB) w/256KiB Cache, CHS=6296/16/63
 hda: hda1 hda2 hda3
hdb: max request size: 128KiB
hdb: 10085040 sectors (5163 MB) w/256KiB Cache, CHS=10672/15/63
hdb: cache flushes not supported
 hdb: hdb1 hdb2 hdb3 hdb4
PNP: PS/2 Controller [PNP0303,PNP0f13] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
TCP cubic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input1
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 156k freed
Write protecting the kernel text: 1380k
Write protecting the kernel read-only data: 452k
EXT3 FS on hda2, internal journal
Adding 105832k swap on /dev/hdb3.  Priority:1 extents:1 across:105832k
Adding 105832k swap on /dev/hdb4.  Priority:1 extents:1 across:105832k
Adding 48376k swap on /dev/hda3.  Priority:1 extents:1 across:48376k
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdb2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdb1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 11, io base 0x0000ef80
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100: eth0: e100_probe: addr 0xffbeb000, irq 10, MAC addr 00:90:27:76:d0:ec
e100: eth1: e100_probe: addr 0xff0fe000, irq 11, MAC addr 00:03:47:3b:29:5c
e100: eth2: e100_probe: addr 0xff0ff000, irq 10, MAC addr 00:03:47:3b:29:5d
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
Bridge firewalling registered
br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
device eth1 entered promiscuous mode
device eth2 entered promiscuous mode
br0: port 2(eth2) entering learning state
br0: topology change detected, propagating
br0: port 2(eth2) entering forwarding state
parport_pc 00:0b: reported by Plug and Play BIOS
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
sb16 01:01.00: activated
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ADDRCONF(NETDEV_UP): eth1: link is not ready
ip6_tables: (C) 2000-2006 Netfilter Core Team
prism2usb_init: prism2_usb.o: 0.2.9 Loaded
prism2usb_init: dev_info is: prism2_usb
usbcore: registered new interface driver prism2_usb
process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
warning: `named' uses 32-bit capabilities (legacy support in use)
process `named' is using obsolete setsockopt SO_BSDCOMPAT
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
hdc: ATAPI 16X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
input: PC Speaker as /devices/platform/pcspkr/input/input2

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: 2.6.25.3: serial problem (minicom)

[Andrew Morton]

On Thu, 15 May 2008 20:06:23 +0100 (BST) Chris Rankin <rankincj@yahoo.com> wrote:

> I have two Linux boxes connected by a null-modem cable between their serial ports; one box exports
> a serial console, which the other reads using the minicom program. However, I have noticed that
> minicom can no longer use the serial console when it is running on a 2.6.25.3 kernel, although it
> works fine running on a 2.6.24.4 kernel.
> 
> Specifically, with minicom running on 2.6.25.3, the console does not accept keystrokes although it
> does receive the boot log from the remote machine.
> 
> The serial console is being exported by a 2.6.25.3 kernel, and appears to be working correctly.

We did make some changes to serial_core.c in that timeframe which might
have caused this, such as:

Author: Russell King <rmk+lkml@arm.linux.org.uk>  2008-02-04 22:27:52
Committer: Linus Torvalds <torvalds@woody.linux-foundation.org>  2008-02-05 09:44:10
Parent: 9d778a69370cc1b643b13648df971c83ff5654ef (serial: avoid waking up closed serial ports on resume)
Child:  6d4d67beb963de8865499781b8523e5b683819c3 (serial: speed setup failure reporting)
Branches: many (89)
Follows: v2.6.24
Precedes: v2.6.25-rc1

    serial: avoid stalling suspend if serial port won't drain


Author: Yinghai Lu <Yinghai.Lu@Sun.COM>  2008-02-04 22:27:46
Committer: Linus Torvalds <torvalds@woody.linux-foundation.org>  2008-02-05 09:44:09
Parent: 149b36eae2ab6aa6056664f4bc461f3d3affc9c1 (serial: stop passing NULL to functions that expect data)
Child:  9d778a69370cc1b643b13648df971c83ff5654ef (serial: avoid waking up closed serial ports on resume)
Branches: many (89)
Follows: v2.6.24
Precedes: v2.6.25-rc1

    serial: keep the DTR setting for serial console.
    

But I don't recall seeing any other reports of this and there's not
really anyone who is actively working on the serial drivers.

All of which builds up to the dreaded....  would you be able to perform
a bisection search to work out which commit caused this?
http://www.kernel.org/doc/local/git-quick.html has instructions.

Thanks.

Re: 2.6.25.3: serial problem (minicom)

[Chris Rankin]

--- Andrew Morton <akpm@linux-foundation.org> wrote:
> All of which builds up to the dreaded....  would you be able to perform
> a bisection search to work out which commit caused this?
> http://www.kernel.org/doc/local/git-quick.html has instructions.

Can't you just send me those 4 serial patches instead, and I'll try backing them out one by one?

I have another pair of boxes both running Fedora 8 that I'll try replicating this on, just in case
there's something dodgy about my machine's userspace environment.

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: 2.6.25.3: serial problem (minicom)

[Jay Cliburn]

On Thu, 15 May 2008 20:06:23 +0100 (BST)
Chris Rankin <rankincj@yahoo.com> wrote:

> Specifically, with minicom running on 2.6.25.3, the console does not
> accept keystrokes although it does receive the boot log from the
> remote machine.
> 
> The serial console is being exported by a 2.6.25.3 kernel, and
> appears to be working correctly.

Serial console using minicom works fine for me under 2.6.25 and
2.6.25.4.  Keystrokes are accepted normally.

Jay

Re: 2.6.25.3: serial problem (minicom)

[Chris Rankin]

--- Jay Cliburn <jacliburn@bellsouth.net> wrote:
> Serial console using minicom works fine for me under 2.6.25 and
> 2.6.25.4.  Keystrokes are accepted normally.

I have just replicated this problem between two Fedora 8 boxes; minicom reads the remote serial
console fine, provided it is running on a 2.6.24.x kernel. (The serial console is from a 2.6.25.4
machine.)

My serial console is defined using the kernel parameters "console=ttyS0,115200n8", and my minicom
session as:

pr port             /dev/ttyS1
pu baudrate         115200
pu bits             8
pu parity           N
pu stopbits         1
#pu minit            ^M

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: 2.6.25.3: serial problem (minicom)

[Jay Cliburn]

On Sat, 17 May 2008 13:29:31 +0100 (BST)
Chris Rankin <rankincj@yahoo.com> wrote:

> --- Jay Cliburn <jacliburn@bellsouth.net> wrote:
> > Serial console using minicom works fine for me under 2.6.25 and
> > 2.6.25.4.  Keystrokes are accepted normally.
> 
> I have just replicated this problem between two Fedora 8 boxes;
> minicom reads the remote serial console fine, provided it is running
> on a 2.6.24.x kernel. (The serial console is from a 2.6.25.4 machine.)
> 
> My serial console is defined using the kernel parameters
> "console=ttyS0,115200n8", and my minicom session as:
> 
> pr port             /dev/ttyS1
> pu baudrate         115200
> pu bits             8
> pu parity           N
> pu stopbits         1
> #pu minit            ^M

Mine still works.  I was going to bisect it, but I don't encounter the
problem.

[jcliburn@sparrow ~]$ uname -a
Linux sparrow 2.6.25.4 #1 SMP Fri May 16 11:31:19 CDT 2008 i686 i686 i386 GNU/Linux

[jcliburn@sparrow ~]$ cat /etc/fedora-release 
Fedora release 8 (Werewolf)

[jcliburn@sparrow ~]$ cat /etc/minirc.dfl 
# Machine-generated file - use "minicom -s" to change parameters.
pu port             /dev/ttyS0
pu baudrate         38400
pu bits             8
pu parity           N
pu stopbits         1

jcliburn@sparrow ~]$ grep CONFIG_SERIAL linux-2.6.25.y.git/.config
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m

Re: 2.6.25.3: serial problem (minicom)

[Jay Cliburn]

On Sat, 17 May 2008 08:22:07 -0500
Jay Cliburn <jacliburn@bellsouth.net> wrote:

> On Sat, 17 May 2008 13:29:31 +0100 (BST)
> Chris Rankin <rankincj@yahoo.com> wrote:
> 
> > --- Jay Cliburn <jacliburn@bellsouth.net> wrote:
> > > Serial console using minicom works fine for me under 2.6.25 and
> > > 2.6.25.4.  Keystrokes are accepted normally.
> > 
> > I have just replicated this problem between two Fedora 8 boxes;
> > minicom reads the remote serial console fine, provided it is running
> > on a 2.6.24.x kernel. (The serial console is from a 2.6.25.4
> > machine.)

> Mine still works.  I was going to bisect it, but I don't encounter the
> problem.

Another bit of info, FWIW: unlike your setup, the system at the other
end of my null modem cable is running Fedora 9, not Fedora 8.

Re: 2.6.25.3: serial problem (minicom)

[Chris Rankin]

--- Jay Cliburn <jacliburn@bellsouth.net> wrote:
> Mine still works.  I was going to bisect it, but I don't encounter the
> problem.
> 
> [jcliburn@sparrow ~]$ uname -a
> Linux sparrow 2.6.25.4 #1 SMP Fri May 16 11:31:19 CDT 2008 i686 i686 i386 GNU/Linux
> 
> [jcliburn@sparrow ~]$ cat /etc/fedora-release 
> Fedora release 8 (Werewolf)
> 
> [jcliburn@sparrow ~]$ cat /etc/minirc.dfl 
> # Machine-generated file - use "minicom -s" to change parameters.
> pu port             /dev/ttyS0
> pu baudrate         38400
> pu bits             8
> pu parity           N
> pu stopbits         1
> 
> jcliburn@sparrow ~]$ grep CONFIG_SERIAL linux-2.6.25.y.git/.config
> CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_PNP=y
> CONFIG_SERIAL_8250_CS=m
> CONFIG_SERIAL_8250_NR_UARTS=32
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> # CONFIG_SERIAL_8250_FOURPORT is not set
> # CONFIG_SERIAL_8250_ACCENT is not set
> # CONFIG_SERIAL_8250_BOCA is not set
> # CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
> # CONFIG_SERIAL_8250_HUB6 is not set
> CONFIG_SERIAL_8250_SHARE_IRQ=y
> CONFIG_SERIAL_8250_DETECT_IRQ=y
> CONFIG_SERIAL_8250_RSA=y
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_SERIAL_JSM=m

Does yours still work if you raise the baud rate to 115200? Here's my .config for 2.6.25.x, which
is unchanged since 2.6.24.x:

# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set

Cheers,
Chris



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: 2.6.25.3: serial problem (minicom)

[Jay Cliburn]

On Sat, 17 May 2008 15:49:08 +0100 (BST)
Chris Rankin <rankincj@yahoo.com> wrote:

> Does yours still work if you raise the baud rate to 115200? 

No, but I also get garbage characters and a generally unusable logging
device.  57600 is slightly better, but not much.  I remember going
through this progressive reduction in baud rate a long time ago,
trying to find a speed that works reliably, which is why I settled on
38400. I get unpredictable results for anything higher.

Re: 2.6.25.3: serial problem (minicom)

[Bart Van Assche]

On Sat, May 17, 2008 at 5:10 PM, Jay Cliburn <jacliburn@bellsouth.net> wrote:
> On Sat, 17 May 2008 15:49:08 +0100 (BST)
> Chris Rankin <rankincj@yahoo.com> wrote:
>
>> Does yours still work if you raise the baud rate to 115200?
>
> No, but I also get garbage characters and a generally unusable logging
> device.  57600 is slightly better, but not much.  I remember going
> through this progressive reduction in baud rate a long time ago,
> trying to find a speed that works reliably, which is why I settled on
> 38400. I get unpredictable results for anything higher.

If you have a digital oscilloscope available it would be very
interesting to measure whether the timing of the signals sent out on
the Tx line is correct. Small deviations between the frequency of the
clock crystal that drives a UART and the value configured via
setserial can cause trouble with serial communication (baud_base must
be configured to UART clock crystal frequency / 16).

# setserial -g -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

Bart.

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

This is kind of an old thread, but I'm seeing something similar and, perhaps, 
can throw some light on the subject.

On Fri, 16 May 2008, Andrew Morton wrote:

> On Thu, 15 May 2008 20:06:23 +0100 (BST) Chris Rankin <rankincj@yahoo.com> 
> wrote:

>> I have two Linux boxes connected by a null-modem cable between their serial 
>> ports; one box exports a serial console, which the other reads using the 
>> minicom program. However, I have noticed that minicom can no longer use the 
>> serial console when it is running on a 2.6.25.3 kernel, although it works 
>> fine running on a 2.6.24.4 kernel.

>> Specifically, with minicom running on 2.6.25.3, the console does not accept 
>> keystrokes although it does receive the boot log from the remote machine.

>> The serial console is being exported by a 2.6.25.3 kernel, and appears to be 
>> working correctly.

> We did make some changes to serial_core.c in that timeframe which might have 
> caused this, such as:

...

> Author: Yinghai Lu <Yinghai.Lu@Sun.COM>  2008-02-04 22:27:46
> Committer: Linus Torvalds <torvalds@woody.linux-foundation.org> 2008-02-05 
> 09:44:09
> Parent: 149b36eae2ab6aa6056664f4bc461f3d3affc9c1 (serial: stop passing
>         NULL to functions that expect data)
> Child:  9d778a69370cc1b643b13648df971c83ff5654ef (serial: avoid waking
>         up closed serial ports on resume)
> Branches: many (89)
> Follows: v2.6.24
> Precedes: v2.6.25-rc1
>
>     serial: keep the DTR setting for serial console.

That looks like a possibility.  minicom has a DTR toggle function that drops 
DTR by setting the baud rate to B0 (thereby clearing both DTR and RTS) and then 
restoring the previous rate.  It's called pretty early upon execution.

With kernels prior to 2.6.25 or so, resetting the baud rate would again raise 
DTR and RTS, but I'm not seeing this with the current stable version (2.6.25.6 
as of this writing).

Specifically:

   Opening a serial device (e.g. 16550 as ttyS0) raises DTR and RTS.

   Setting the baud rate to B0 clears both (as per SUS).

   Subsequently setting the baud rate to something other than B0 leaves the
   control lines low.

As it happens, apart from the fact that it breaks minicom, I actually prefer 
this behavior.

Right now I have a patch that will fix minicom and I'm trying to convince the 
maintainers to accept it.  I need a definitive answer, though, as to whether 
I'm seeing a bug or a feature.


If it's not too much trouble, please CC: to my address.  The volume of this 
list is a little overwhelming...

Re: 2.6.25.3: serial problem (minicom)

[Alan Cox]

>    Setting the baud rate to B0 clears both (as per SUS).
> 
>    Subsequently setting the baud rate to something other than B0 leaves the
>    control lines low.
> 
> As it happens, apart from the fact that it breaks minicom, I actually prefer 
> this behavior.

What happens after you go from B0->Banythingelse should depend on the
termios settings at that point. This sounds like a bug therefore.

If you want that behaviour intentionally set B0, after this termios
call then set CLOCAL before changing the baud back.

I'll take a look at this next week.

Alan

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Sat, 14 Jun 2008, Alan Cox wrote:

> What happens after you go from B0->Banythingelse should depend on the
> termios settings at that point. This sounds like a bug therefore.
>
> If you want that behaviour intentionally set B0, after this termios
> call then set CLOCAL before changing the baud back.

I'm not seeing any change in behavior with different combinations of 
CLOCAL.  As it happens, minicom sets CLOCAL first thing so as to keep 
SIGHUP signals from being generated.

But, then, what is the relationship between CLOCAL and DTR/RTS supposed to 
be?  Presumably, it should prevent a SIGHUP from being raised when DSR 
goes low, but beyond that, it all seems rather ill-defined.  Throw in B0, 
which the SUS strongly implies should unconditionally lower DTR and RTS, 
and the CRTSCTS flag, and the waters really get murky.  It looks to me 
like the only thing you can say for certain is that CLOCAL will cause DSR 
to be ignored...and for anything else you're on your own.

Mind you, all this just suggests that POSIX kinda sucks, which is hardly 
an earth-shattering revelation.

> I'll take a look at this next week.

It would be much appreciated.  Thanks.

Re: 2.6.25.3: serial problem (minicom)

[Alan Cox]

> But, then, what is the relationship between CLOCAL and DTR/RTS supposed to 
> be?  Presumably, it should prevent a SIGHUP from being raised when DSR 
> goes low, but beyond that, it all seems rather ill-defined.  Throw in B0, 

CLOCAL is defined to "ignore modem control lines"

> which the SUS strongly implies should unconditionally lower DTR and RTS, 
> and the CRTSCTS flag, and the waters really get murky.  It looks to me 
> like the only thing you can say for certain is that CLOCAL will cause DSR 
> to be ignored...and for anything else you're on your own.

Whatever it implies the behaviour should not have changed between 2.6.24
and 2.6.25. Nobody AFAIK sat down and decided to change it.

> 
> Mind you, all this just suggests that POSIX kinda sucks, which is hardly 
> an earth-shattering revelation.

Standards are part written spec and a large part an existing tradition
around that standard. The tradition is often the most important bit.

Alan

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Mon, 16 Jun 2008, Alan Cox wrote:

> Whatever it implies the behaviour should not have changed between 2.6.24
> and 2.6.25. Nobody AFAIK sat down and decided to change it.

And, besides, I've gotten reports that the usb-serial drivers still behave 
the same as with 2.6.24.

It looks like the call to tty_termios_encode_baud_rate() in 
drivers/serial/8250.c is the culprit.  If I comment it out, everything 
appears to go back to normal (seemingly with no undesired side effects).

Why the call is there (it didn't replace anything else in the 2.6.24.7 
version of 8250.c, though it did in serial_core.c) remains a mystery to 
me.

Re: 2.6.25.3: serial problem (minicom)

[Alan Cox]

On Mon, 16 Jun 2008 23:22:54 -0500 (CDT)
"R.L. Horn" <lists@eastcheap.org> wrote:

> On Mon, 16 Jun 2008, Alan Cox wrote:
> 
> > Whatever it implies the behaviour should not have changed between 2.6.24
> > and 2.6.25. Nobody AFAIK sat down and decided to change it.
> 
> And, besides, I've gotten reports that the usb-serial drivers still behave 
> the same as with 2.6.24.
> 
> It looks like the call to tty_termios_encode_baud_rate() in 
> drivers/serial/8250.c is the culprit.  If I comment it out, everything 
> appears to go back to normal (seemingly with no undesired side effects).
> 
> Why the call is there (it didn't replace anything else in the 2.6.24.7 
> version of 8250.c, though it did in serial_core.c) remains a mystery to 
> me.

Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows

+       /* Don't rewrite B0 */
+       if (tty_termios_baud_rate(termios))
+               tty_termios_encode_baud_rate(termios, baud, baud);
 }
 

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Mon, 16 Jun 2008, Alan Cox wrote:

> Whatever it implies the behaviour should not have changed between 2.6.24 
> and 2.6.25.

Okay, I think I may have figured this out.

serial8250_set_termios() (8250.c) gets a baud rate using 
uart_get_baud_rate() (serial_core.c) which returns 9600 if the termios 
rate is B0.

The function does some stuff.

Right before returning, it calls tty_termios_encode_baud_rate() with the 
abovementioned rate.  That function obediently changes the c_cflag baud 
bits from B0 to B9600.  Presumably, this causes confusion in other 
functions (they never know that B0 was set).

I've now changed:

   tty_termios_encode_baud_rate(termios, baud, baud);

to:

   if ((termios->c_cflag & CBAUD) == B0)
       baud = 0;
   tty_termios_encode_baud_rate(termios, baud, baud);

And everybody's happy, I guess.

It looks like the DECstation DZ driver (drivers/serial/dz.c) will have the 
same problem, but I believe the others are okay (as of 2.6.25.6).

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Tue, 17 Jun 2008, Alan Cox wrote:

> Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows
>
> +       /* Don't rewrite B0 */
> +       if (tty_termios_baud_rate(termios))
> +               tty_termios_encode_baud_rate(termios, baud, baud);
> }

Oh.

Oh well.

I guess I'll just fix it here and wait for the official fix.

Re: 2.6.25.3: serial problem (minicom)

[Hans-Peter Jansen]

Am Dienstag, 17. Juni 2008 schrieb Alan Cox:
> On Mon, 16 Jun 2008 23:22:54 -0500 (CDT)
>
> "R.L. Horn" <lists@eastcheap.org> wrote:
> > On Mon, 16 Jun 2008, Alan Cox wrote:
> > > Whatever it implies the behaviour should not have changed between
> > > 2.6.24 and 2.6.25. Nobody AFAIK sat down and decided to change it.
> >
> > And, besides, I've gotten reports that the usb-serial drivers still
> > behave the same as with 2.6.24.
> >
> > It looks like the call to tty_termios_encode_baud_rate() in
> > drivers/serial/8250.c is the culprit.  If I comment it out, everything
> > appears to go back to normal (seemingly with no undesired side
> > effects).
> >
> > Why the call is there (it didn't replace anything else in the 2.6.24.7
> > version of 8250.c, though it did in serial_core.c) remains a mystery to
> > me.
>
> Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows
>
> +       /* Don't rewrite B0 */
> +       if (tty_termios_baud_rate(termios))
> +               tty_termios_encode_baud_rate(termios, baud, baud);
>  }

Alan, could this issue lead to dysfunctional serial dcf77 receivers, too? 
(and could you point my to the related git changeset?)

I'm using ntpd "127.127.8.0 mode 16" devices since a decade now (RAWDCF 
receiver: DTR=low/RTS=high) and after upgrading to openSUSE 11.0, which is 
using 2.6.25.5, those get no power anymore :-(.

Or do you have another idea? I currently prepare a test system, and would be 
ready for kernel patching tomorrow..

TIA, Pete

Re: 2.6.25.3: serial problem (minicom)

[Alan Cox]

On Wed, 18 Jun 2008 02:15:45 +0200
"Hans-Peter Jansen" <hpj@urpla.net> wrote:

> Am Dienstag, 17. Juni 2008 schrieb Alan Cox:
> > On Mon, 16 Jun 2008 23:22:54 -0500 (CDT)
> >
> > Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows
> >
> > +       /* Don't rewrite B0 */
> > +       if (tty_termios_baud_rate(termios))
> > +               tty_termios_encode_baud_rate(termios, baud, baud);
> >  }
> 
> Alan, could this issue lead to dysfunctional serial dcf77 receivers, too? 
> (and could you point my to the related git changeset?)

I don't generally work via git so I don't offhand know the changeset id.
I guess it could do. If its causing this many actual problem cases it
might also want to go into stable.

Alan

Re: 2.6.25.3: serial problem (minicom)

[Olivier Galibert]

On Wed, Jun 18, 2008 at 06:55:34PM +0100, Alan Cox wrote:
> On Wed, 18 Jun 2008 02:15:45 +0200
> "Hans-Peter Jansen" <hpj@urpla.net> wrote:
> 
> > Am Dienstag, 17. Juni 2008 schrieb Alan Cox:
> > > On Mon, 16 Jun 2008 23:22:54 -0500 (CDT)
> > >
> > > Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows
> > >
> > > +       /* Don't rewrite B0 */
> > > +       if (tty_termios_baud_rate(termios))
> > > +               tty_termios_encode_baud_rate(termios, baud, baud);
> > >  }
> > 
> > Alan, could this issue lead to dysfunctional serial dcf77 receivers, too? 
> > (and could you point my to the related git changeset?)
> 
> I don't generally work via git so I don't offhand know the changeset id.

e991a2bd4fa0b2f475b67dfe8f33e8ecbdcbb40b

git blame drivers/serial/8250.c then look for "rewrite B0" (which gets
you e991a2bd) then git show e991a2bd.

  OG.

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Wed, 18 Jun 2008, Alan Cox wrote:

> I don't generally work via git so I don't offhand know the changeset id.
> I guess it could do. If its causing this many actual problem cases it
> might also want to go into stable.

I vote for nipping it in the bud ASAP.  There are currently eight stable 
kernel versions that exhibit this bug (which I believe is fairly serious, 
in breadth, if not depth), and it already has Adam Lackorzynski and me 
scratching our heads trying to figure out what, if anything, to do with 
minicom to accomodate it.

I would suggest one change to the 26-rc version.  Rather than bypassing 
tty_termios_encode_baud_rate() entirely in the B0 case, why not do 
something like:

     if (tty_termios_baud_rate(termios))
         tty_termios_encode_baud_rate(termios, baud, baud);
     else
         tty_termios_encode_baud_rate(termios, 0, 0);

to ensure that c_ispeed and c_ospeed are set (just for the sake of 
consistency)?

Re: 2.6.25.3: serial problem (minicom)

[Hans-Peter Jansen]

Am Mittwoch, 18. Juni 2008 schrieb Alan Cox:
> On Wed, 18 Jun 2008 02:15:45 +0200
>
> "Hans-Peter Jansen" <hpj@urpla.net> wrote:
> > Am Dienstag, 17. Juni 2008 schrieb Alan Cox:
> > > On Mon, 16 Jun 2008 23:22:54 -0500 (CDT)
> > >
> > > Ah ok I know what the bug is - it was fixed in 2.6.26-rc as follows
> > >
> > > +       /* Don't rewrite B0 */
> > > +       if (tty_termios_baud_rate(termios))
> > > +               tty_termios_encode_baud_rate(termios, baud, baud);
> > >  }
> >
> > Alan, could this issue lead to dysfunctional serial dcf77 receivers,
> > too? (and could you point my to the related git changeset?)
>
> I don't generally work via git so I don't offhand know the changeset id.
> I guess it could do. If its causing this many actual problem cases it
> might also want to go into stable.

Alan, I got to test this by applying the changeset (Olivier, many thanks 
for your valuable hint, I'm sure, I will reuse this knowledge soon), to 
the otherwise unchanged kernel, but unfortunately, it doesn't solve my 
issue.

A different patch must have changed the behavior/state of some RS232 lines  
in the 2.6.25 time frame, since the device still doesn't get any power at 
all. Hopefully I get round bisecting it this weekend, but any hints are 
greatly appreciated.

As another data point: using a usb <-> rs232 converter, the dcf device got 
back to life again. It still doesn't work in its entirety, but at least, 
some data arrives in ntpd. Expected is something similar to:
-#--#-#####-###--D--S124--2-p------p-----21-4-24-----8-- (incomplete)
but it reads:
###############RADMLS1248124P124812P1248121241248112481248P
thus, obviously it doesn't get any 0 values back (displayed as - above).

The setting of the serial interfaces was equivalent, but maybe the usb 
converter cannot handle the rather strange 50 baud setting properly.

~# stty -a < /dev/ttyUSB0 
speed 50 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

Pete

Re: 2.6.25.3: serial problem (minicom)

[R.L. Horn]

On Fri, 20 Jun 2008, Hans-Peter Jansen wrote:

> Alan, I got to test this by applying the changeset (Olivier, many thanks
> for your valuable hint, I'm sure, I will reuse this knowledge soon), to
> the otherwise unchanged kernel, but unfortunately, it doesn't solve my
> issue.
>
> A different patch must have changed the behavior/state of some RS232 lines
> in the 2.6.25 time frame,

There was a deliberate change in DTR behavior, though I'm not up on the 
details.  If you have a copy of 2.6.25.something handy and want to check 
that that's the problem, you might look at drivers/serial/serial_core.c. 
Round about line 2160 (in uart_configure_port()), you'll see:

   /*
    * Ensure that the modem control lines are de-activated.
    * keep the DTR setting that is set in uart_set_options()
    * We probably don't need a spinlock around this, but
    */
   spin_lock_irqsave(&port->lock, flags);
   port->ops->set_mctrl(port, port->mctrl & TIOCM_DTR);

Change the last line to:

   port->ops->set_mctrl(port, 0);

which reverts to 2.6.24 behavior.

If your problem isn't resolved here, please contact me off-list with some 
details about your receiver, ntpd version, etc. and I'll look into it 
further.  I've been thinking about building a WWVB doodad, and a solution 
to this might save me some grief later on.

> As another data point: using a usb <-> rs232 converter, the dcf device 
> got back to life again. It still doesn't work in its entirety, but at 
> least, some data arrives in ntpd. Expected is something similar to:
> -#--#-#####-###--D--S124--2-p------p-----21-4-24-----8-- (incomplete)
> but it reads:
> ###############RADMLS1248124P124812P1248121241248112481248P
> thus, obviously it doesn't get any 0 values back (displayed as - above).

That looks like a hardware problem.  Odds are, something here (and it 
could be the USB<->RS232 converter or the DCF receiver or both) either 
isn't up to RS-232 specs or the receiver is making unfounded assumptions 
about the DTE port.  In particular, I'd want to know the mark/space 
voltages coming out of that USB thingy.