From owner-freebsd-i386@FreeBSD.ORG Thu Nov 16 20:50:04 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9BE716A625 for ; Thu, 16 Nov 2006 20:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94CA043D5C for ; Thu, 16 Nov 2006 20:50:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAGKo2GI089499 for ; Thu, 16 Nov 2006 20:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAGKo2Pc089498; Thu, 16 Nov 2006 20:50:02 GMT (envelope-from gnats) Resent-Date: Thu, 16 Nov 2006 20:50:02 GMT Resent-Message-Id: <200611162050.kAGKo2Pc089498@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Helge Oldach Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6935D16A47E for ; Thu, 16 Nov 2006 20:47:09 +0000 (UTC) (envelope-from hmo@sep.oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C4843D5F for ; Thu, 16 Nov 2006 20:47:05 +0000 (GMT) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210]) by rigel.oldach.net (8.13.8/8.13.8/hmo30jul04) with ESMTP id kAGKl1WV091679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Nov 2006 21:47:03 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.13.8/8.13.8/hmo26jun05) with ESMTP id kAGKl0GK005859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Nov 2006 21:47:00 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.13.8/8.13.8/Submit/hmo26jun05) id kAGKks7v005850; Thu, 16 Nov 2006 21:46:54 +0100 (CET) (envelope-from hmo) Message-Id: <200611162046.kAGKks7v005850@sep.oldach.net> Date: Thu, 16 Nov 2006 21:46:54 +0100 (CET) From: Helge Oldach To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: i386/105616: UART PCI device just silent... X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Helge Oldach List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 20:50:04 -0000 >Number: 105616 >Category: i386 >Synopsis: UART PCI device just silent... >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 16 20:50:01 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Helge Oldach >Release: FreeBSD 6.2-608 i386 >Organization: >Environment: System: FreeBSD localhost 6.2-608 FreeBSD 6.2-608 #1: Thu Nov 16 06:38:51 CET 2006 toor@localhost:/usr/obj/usr/src/sys/HMO-UART i386 >Description: I own a dual serial PCI board that works just fine with puc(4) & sio(4). No issue at all except occasional FIFO overruns. Unfortunately I cannot make it work with puc(4) & uart(4). I've compiled a kernel with minimal differences: include GENERIC nodevice sio device uart The two on-board UARTs work just fine (after tweaking /boot/device.hints), but the two PCI-based UARTs don't. The PCI device and the UARTs are correctly recognized and properly attached. I can open the devices with cu(1) or whatever application I chose, but there is zero data transfer. Nothing in, nothing out. It appears that carrier and other wires are there and properly recognized, but I can't get a single byte through. A verbose boot goes like this: found-> vendor=0x1409, dev=0x7168, revid=0x01 bus=0, slot=14, func=0 class=07-00-02, hdrtype=0x00, mfdev=0 cmdreg=0x0081, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 4, range 32, base 00002000, size 5, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.LNKB:0) pcib0: slot 14 INTA routed to irq 10 via \\_SB_.LNKB uart0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x2000 puc0: port 0x2000-0x201f irq 10 at device 14.0 on pci0 uart2: <16550 or compatible> on puc0 uart2: fast interrupt uart3: <16550 or compatible> on puc0 uart3: fast interrupt uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: fast interrupt uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: fast interrupt The PCI device is not sharing IRQ 10 with another device. Disabling PUC_FASTINTR does not make a difference. Under both the "sio kernel" and the "uart kernel" pciconf(8) identifies board as puc0@pci0:14:0: class=0x070002 card=0x40371409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = 'SUN 1889 / SUN 1699 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms subclass = UART and devinfo(8) identifies under the uart kernel as puc0 pnpinfo vendor=0x1409 device=0x7168 subvendor=0x1409 subdevice=0x4037 class=0x070002 at slot=14 function=0 uart2 uart3 (similarly with sio device designators under the sio kernel). As this PCI device was not yet properly recognized by 6-STABLE's PCI/UART code, I had applied a minor fix: --- sys/dev/uart/uart_bus_pci.c.ctm Wed Aug 2 16:24:19 2006 +++ sys/dev/uart/uart_bus_pci.c Wed Nov 15 10:18:56 2006 @@ -101,6 +101,8 @@ 8 * DEFAULT_RCLK }, { 0x1409, 0x7168, 0x1409, 0x4028, "Timedia Technology Serial Port", 0x10, 8 * DEFAULT_RCLK }, +{ 0x1409, 0x7168, 0x1409, 0x4037, "Timedia Technology Serial Port", 0x10, + 8 * DEFAULT_RCLK }, { 0x1409, 0x7168, 0x1409, 0x5025, "Timedia Technology Serial Port", 0x10, 8 * DEFAULT_RCLK }, { 0x1409, 0x7168, 0x1409, 0x5027, "Timedia Technology Serial Port", 0x10, The 7-CURRENT code is slightly different as it applies a generic function to Timedia-type devices. From a code walk-through I concluded that this minor patch would be functionally identical. According to http://members.datafast.net.au/dft0802/downloads/pcidevs.txt this subdev should be a 16650 UART. But we recognize it as a 16550 type. Is there a potential issue 16- versus 32-byte FIFO? >How-To-Repeat: >Fix: I have no idea.... sorry. >Release-Note: >Audit-Trail: >Unformatted: