Subject: kern/461: Possible tty driver bug (breaks UUCP)
To: None <gnats-admin>
From: Giles Lean <>
List: netbsd-bugs
Date: 09/05/1994 13:35:04
>Number:         461
>Category:       kern
>Synopsis:       read(2) on tty with modem control returns 0 with EINTR set
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gnats-admin (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep  5 13:35:03 1994
>Originator:     Giles Lean
Nemeton Pty Ltd
Giles Lean
Nemeton Pty Ltd, 6/111 Flinders Street, Thornbury 3071 AUSTRALIA
<> 			 phone:   +61 3 480 2118
>Release:        NetBSD-current (August 22nd source)
System: NetBSD 1.0_BETA NetBSD 1.0_BETA (MAENOR) #0: Sat Sep 3 14:57:04 EST 1994 i386

The hardware is a 486SX/33 with:
com0 at isa0 port 0x3f8-0x3ff irq 4: ns82450 or ns16450, no fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns82450 or ns16450, no fifo

	With sources from about the 6th of August, I found that uucico
	reported lost carrier while I could see the carrier detect light
	on the modem remained high.  This problem continues in Aug. 22nd

	Checking the uucico source indicated that it would report the
	line had disconnected when it received a return value of zero
	from read(), i.e. end of file.
	[See /usr/src/gnu/libexec/uucp/libunix/serial.c line #2015.]

	The basic problem is that read(2) should return the number of
	characters read for a partial read EXCEPT when the number of
	characters is zero, when -1 must be returned instead else it looks
	like end of file.

	(POSIX handwaves and lets you return -1 instead of the number of
	characters actually read, but I hope nobody would implement that.
	Considering zero characters to be a partial read would presumably
	satisfy the standard, but is too perverse to consider.)

	The problem shows with only one or two uucp links I have.  On
	that link, however, it repeats every time. (The remote end is
	a CISCO terminal server connecting to either a Sun or a Solbourne
	running Taylor UUCP.)
	Requires a kernel hacker.  I had fun looking. :-)

	The workaround for uucico for anyone desparate to get uucp up
	and running again:

*** 1.1	1994/09/03 05:11:09
--- /usr/src/gnu/libexec/uucp/libunix/serial.c	1994/09/05 12:45:16
*** 1997,2003 ****
  	 reduce problems with interrupted system calls.  */
        if (cgot <= 0)
! 	  if (cgot < 0 && errno == EINTR)
  	    cgot = 0;
--- 1997,2003 ----
  	 reduce problems with interrupted system calls.  */
        if (cgot <= 0)
! 	  if (cgot <= 0 && errno == EINTR)
  	    cgot = 0;