kern/185732: Serial port broken on Atom-based Jetway NF99FL

>Number:         185732
>Category:       kern
>Synopsis:       Serial port broken on Atom-based Jetway NF99FL motherboard
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 13 06:20:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator:     Ralph Becker-Szendy
>Release:        9.0-RELEASE
>Organization:
>Environment:
FreeBSD house.lr.los-gatos.ca.us 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
The motherboard is model Jetway NF99FL-525, which uses an Intel D525 Atom CPU, and the Intel ICH9R chipset.  The motherboard has two traditional 9-pin serial ports.  Neither work under FreeBSD.

The hardware itself works fine, verified by booting Knoppix Linux: Under that OS, the serial ports can communicate perfectly.

What do I mean by "the serial ports don't work" ? I have used cu and miniterm.py to drive serial communication, and have directly cat'ed files to/from the serial devices (ttyu0/1 and cuau0/1).  The ports are configured for no flow control, at common baud rates (tested at 1200, 4800 and 9600).  Example:
# stty -a -f /dev/cuau1
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
   -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
   -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
   brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow
   -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
   eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
   lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
   status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

Here is exactly what happens: When cu etc. open the device, the modem control lines are correctly turned on, and turned back off when the device is closed.  No characters are received (on the RD line).  When transmitting characters (on the TD line), the first character per device is transmitted after a reboot of the OS is transmitted over the serial line, after that no more characters are ever transmitted.  To be clear: cuau0 and cuau0 can only transmit one character each after a reboot!  Yet, the TD line can be correctly toggled by transmitting a break over them.  The individual flow control lines can be controlled by ioctls (miniterm.py has that capability).  I have tried using a serial loopback adapter (which bridges RTS-CTS and DTR-DSR-CD), and it doesn't help either (nor should it, as clocal is turned on, and cu etc. configure the port for no hardware flow control).

At the same time, serial communication (using the same cu etc. programs) works fine over another serial port (in my case, I used a no-name brand USB-serial adapter, with a "Prolific Technology" chip), so the problem is not with the test setup.
>How-To-Repeat:
Get one of these motherboards (that is probably the most difficult part).  Plug a serial loopback adapter in, which connects TD to RD (pins 2 and 3), and no other connections.  cu to the port (cuau0 or cuau1), at a baud rate of your choice.  If serial communication worked, everything you type into cu should be echo'ed right back to the screen.  It is not!

To verify that only the first character is transmitted, get a second computer, and connect the serial port under study with a null-modem cable (crossing over pins 2 and 3) to the other computer, and then run cu on both.
>Fix:
None.

>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"