From owner-freebsd-current  Mon Jan 26 22:50:15 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA22662
          for current-outgoing; Mon, 26 Jan 1998 22:50:15 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA22622;
          Mon, 26 Jan 1998 22:50:07 -0800 (PST)
          (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp)
Received: by outmail.utsunomiya-u.ac.jp id AA03783; Tue, 27 Jan 1998 15:49:23 +0900
Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP
	id PAA14809; Tue, 27 Jan 1998 15:56:42 +0900 (JST)
Message-Id: <199801270656.PAA14809@zodiac.mech.utsunomiya-u.ac.jp>
To: Randy Terbush <randy@covalent.net>
Cc: dyson@FreeBSD.ORG, brian@worldcontrol.com, current@FreeBSD.ORG,
        yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: Cyclades/Hylafax/SMP select problems? 
In-Reply-To: Your message of "Mon, 26 Jan 1998 05:20:32 CST."
             <19980126052032B.randy@covalent.net> 
References: <199801261014.FAA00431@dyson.iquest.net>  <19980126052032B.randy@covalent.net> 
Date: Tue, 27 Jan 1998 15:56:41 +0900
From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk


>"John S. Dyson" <dyson@FreeBSD.ORG> wrote:
>> > > The Hylafax faxgetty and faxq processes spin out of control
>> > > chewing up nearly 100% CPU. The same configuration ran without
>> > > problems on a single P5 machine running 2.2-STABLE.
>> > > 
>> > > As I begin to dig deeper into this, are there any know problems
>> > > with this mix?
>> > 
>> > Just thought you'd like to know you are not alone.  faxq on
>> > my SMP system does the same thing.
>> > 
>> Sometimes the output of ktrace or truss can be useful.  Also the
>> contents of /proc/<pid>/map sometimes helps with hints as to
>> what is going on.
>
>Seems that a change to open the FIFO O_RDWR solves the problem.
>Apparently, select() is returning when it should not be. 

Or, select() is returning a wrong value..

Would try the following patch and see if it helps?  It applies to
/sys/kern/sys_generic.c and make select() correctly returns -1 if an
error occurred.

Kazu

Index: sys_generic.c
===================================================================
RCS file: /src/CVS/src/sys/kern/sys_generic.c,v
retrieving revision 1.33
diff -u -r1.33 sys_generic.c
--- sys_generic.c	1997/11/23 10:30:50	1.33
+++ sys_generic.c	1998/01/27 06:38:34
@@ -542,6 +542,7 @@
 	int s, ncoll, error, timo;
 	u_int nbufbytes, ncpbytes, nfdbits;
 
+	p->p_retval[0] = -1;
 	if (uap->nd < 0)
 		return (EINVAL);
 	if (uap->nd > p->p_fd->fd_nfiles)
@@ -673,8 +674,10 @@
 			while ((j = ffs(bits)) && (fd = i + --j) < nfd) {
 				bits &= ~(1 << j);
 				fp = fdp->fd_ofiles[fd];
-				if (fp == NULL)
+				if (fp == NULL) {
+					p->p_retval[0] = -1;
 					return (EBADF);
+				}
 				if ((*fp->f_ops->fo_poll)(fp, flag[msk],
 				    fp->f_cred, p)) {
 					obits[msk][(fd)/NFDBITS] |=