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 ...
[ message continues ]

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.
--

[ message continues ]

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
--

[ message continues ]

On Thu, 15 May 2008 20:06:23 +0100 (BST)

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

Jay
--

[ message continues ]

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
--

[ message continues ]

On Sat, 17 May 2008 13:29:31 +0100 (BST)

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

--

[ message continues ]

On Sat, 17 May 2008 08:22:07 -0500

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.
--

[ message continues ]

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
--

[ message continues ]

On Sat, 17 May 2008 15:49:08 +0100 (BST)

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.
--

[ message continues ]

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.
--

[ message continues ]