From owner-freebsd-bugs@FreeBSD.ORG Mon Jan 13 06:20:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 184A4C9 for ; Mon, 13 Jan 2014 06:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6AC216F9 for ; Mon, 13 Jan 2014 06:20:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0D6K0NT018342 for ; Mon, 13 Jan 2014 06:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0D6K0gr018341; Mon, 13 Jan 2014 06:20:00 GMT (envelope-from gnats) Resent-Date: Mon, 13 Jan 2014 06:20:00 GMT Resent-Message-Id: <201401130620.s0D6K0gr018341@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ralph Becker-Szendy Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE694F39 for ; Mon, 13 Jan 2014 06:17:41 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9962416D6 for ; Mon, 13 Jan 2014 06:17:41 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id s0D6Hf0r025570 for ; Mon, 13 Jan 2014 06:17:41 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id s0D6HftP025559; Mon, 13 Jan 2014 06:17:41 GMT (envelope-from nobody) Message-Id: <201401130617.s0D6HftP025559@oldred.freebsd.org> Date: Mon, 13 Jan 2014 06:17:41 GMT From: Ralph Becker-Szendy To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/185732: Serial port broken on Atom-based Jetway NF99FL motherboard X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 06:20:01 -0000 >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 = ; eol2 = ; 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: