Subject: kern/4263: com driver race condition
To: None <gnats-bugs@gnats.netbsd.org>
From: None <dms@celtech.com>
List: netbsd-bugs
Date: 10/11/1997 08:16:11
>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: