Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Nov 2009 10:46:26 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-stable@freebsd.org
Subject:   PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
Message-ID:  <4B100262.6000900@denninger.net>

next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------000007000601080802040509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is pretty serious folks - as noted below I have tried several
options including limiting FIFO depth with the flags with no result. 
The PUC-based ports are basically useless under 8.x as a consequence.  I
can reproduce this lockup within 15-30 minutes every time.

>Submitter-Id:  current-users
>Originator:    Karl Denninger
>Organization:  Karls Sushi and Packet Smashers
>Confidential:  no <FreeBSD PRs are public data>
>Synopsis:      Serial I/O is terminally screwed under 8.x.
>Severity:      serious
>Priority:      high
>Category:      i386
>Class:         sw-bug
>Release:       FreeBSD 8.0-STABLE i386
>Environment:
System: FreeBSD FS.denninger.net 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri
Nov 27 08
:32:51 CST 2009 karl@FS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386

puc0: <Oxford Semiconductor OX16PCI954 UARTs> port
0x4060-0x407f,0x4040-0x405f m
em 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3
puc0: [FILTER]
uart2: <16550 or compatible> on puc0
uart2: [FILTER]
uart3: <16550 or compatible> on puc0
uart3: [FILTER]
uart4: <16550 or compatible> on puc0
uart4: [FILTER]
uart5: <16550 or compatible> on puc0
uart5: [FILTER]

puc0@pci0:3:0:0:        class=0x070006 card=0x00001415 chip=0x950a1415
rev=0x00
hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0x4060, size 32, enabled
    bar   [14] = type Memory, range 32, base 0x94503000, size 4096, enabled
    bar   [18] = type I/O Port, range 32, base 0x4040, size 32, enabled
    bar   [1c] = type Memory, range 32, base 0x94502000, size 4096, enabled
    cap 01[40] = powerspec 1  supports D0 D2 D3  current D0


#
# SMP -- Generic kernel configuration file for FreeBSD/i386 SMP
#        Use this for multi-processor machines
#
# $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58 scottl Exp $

include GENERIC

ident           KSD-SMP

# To make an SMP kernel, the next line is needed
#options        SMP                     # Symmetric MultiProcessor Kernel
#
# We also need the firewall, divert, and PPS_SYNC (for the GPS) options
#
options         IPFIREWALL
options         IPDIVERT
options         PPS_SYNC

#
# Rate-shaping requirements
#
options         DUMMYNET
options         HZ=1000

#options                SYSVSHM

#
# Local stuff
#
device          rp              # Comtrol Rocketport Board
device          sound           # Generic sound card drivers

#device         ubsa            # USB Serial Adapters
#device         ucom
#device         uftdi
#device         uplcom

device          umct
device          puc


>Description:
        Serial I/O fails with a lockup after a variable amount of time.
        Modem-controlled ports are succeptible, especially those that
        require tight adherence to that capability.

        There is no reset possible without rebooting the machine.  Attempts
        to "probe" the port by stopping the running process(es) and
        re-initializing them fail.

        This IDENTICAL board in the IDENTICAL machine was functioning
        properly under 7.x over the space of about a year under extremely
        heavy use.  As soon as 8.x-RC2 was loaded, and subsequently with the
        released version (as seen above) it failed and has remained dead.
  
        The custom kernel with "PPS_SYNC" is present as one
        of the ports (on the motherboard) is used for a GPS clock under
ntpd.
        This port is operating fine - it is relatively low-traffic, of
        course, containing only timecode.  Another port used to talk to an
        APC UPS (again, low traffic) is also ok.

        All ports in use for Hylafax, however, lock up as described above.

        Attempting to limit FIFO depth with 0x100 or 0x200 flags on the    
        ports has no effect.

>How-To-Repeat:
        Put a "puc" style board in the machine, set up hylafax, send a few
        dozen faxes.  The driver will wedge.

>Fix:

        <how to correct or work around the problem, if known (multiple
lines)>



--------------000007000601080802040509--





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B100262.6000900>