>Number:         4263
>Category:       kern
>Synopsis:       com driver can hang when used as serial console
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 11 14:50:01 1997
>Last-Modified:
>Originator:     David M. Stanhope Dms
>Organization:
cts
	
>Release:        current
>Environment:
netbsd-i386
	
System: NetBSD bsdpc.celtech.com 1.2G NetBSD 1.2G (NETBSD) #1: Sun Oct 5 07:56:36 PDT 1997 dms@bsdpc.celtech.com:/usr4/netbsd/src/sys/arch/i386/compile/NETBSD i386


>Description:
        when using the com.c driver as a serial console, a race condition
        exist that can easily hang the console.  The problem occurs
        when there are lots of kernal printf's occuring and at the same
        time normal console output activity is also occuring. The problem
        happens when there is pending data in the normal serial output queue
        in the device driver, it has output a character, and is waiting for a
        tranmit interrupt before outputing another character. If while
        waiting for the transmit interrupt, a kernal printf call is made to
        'com_common_putc', this function disables the serial interrupts,
        waits for the transmit register to come free, outputs its character,
        and then again waits for the transmit register to come free,
        then it insures any pending interrupt is cleared, re-enables
        interrupts and returns. Since all pending interrupts for this port
        were cleared, the rest of the com driver never get an interrupt to
        say that it can continue output, so normal output hangs, while
        kernal console output can still happen.
>How-To-Repeat:
        on a serial console enabled machine (using mi com.c), try to use
        the console while kernal output occurs, there is a high probability
        that you will hang the console.
>Fix:
        remove the 'bus_space_read' at the end of 'com_common_putc' which 
        clears the interrupts, let the interrupts occur and let the normal
        part of the device driver handle them, even if no normal output
        is occuring, the driver will just ignore the interrupts and these
        extra interrupts only occur when kernal printf's are happening so
        this should not be a loss. This has worked well on older com.c
        drivers, looks the same in current but not tested locally yet.



>Audit-Trail:
>Unformatted: