Date: Thu, 16 Nov 2006 21:46:54 +0100 (CET) From: Helge Oldach <puc-uart@oldach.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: i386/105616: UART PCI device just silent... Message-ID: <200611162046.kAGKks7v005850@sep.oldach.net> Resent-Message-ID: <200611162050.kAGKo2Pc089498@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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: <Dolphin Peripherals 4036> 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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611162046.kAGKks7v005850>