From doconnor@cain.gsoft.com.au  Tue Apr 23 01:04:30 2002
Return-Path: <doconnor@cain.gsoft.com.au>
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
	by hub.freebsd.org (Postfix) with ESMTP id 3FBFA37B416
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Apr 2002 01:04:28 -0700 (PDT)
Received: from cain.gsoft.com.au (doconnor@localhost [127.0.0.1])
	by cain.gsoft.com.au (8.12.2/8.12.2) with ESMTP id g3N84Cru094790
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Apr 2002 17:34:24 +0930 (CST)
	(envelope-from doconnor@cain.gsoft.com.au)
Received: (from doconnor@localhost)
	by cain.gsoft.com.au (8.12.2/8.12.2/Submit) id g3N847bg094789;
	Tue, 23 Apr 2002 17:34:07 +0930 (CST)
	(envelope-from doconnor)
Message-Id: <200204230804.g3N847bg094789@cain.gsoft.com.au>
Date: Tue, 23 Apr 2002 17:34:07 +0930 (CST)
From: "Daniel O'Connor" <doconnor@gsoft.com.au>
Reply-To: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Serial drainwait shouldn't be zero (forever) by default
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         37370
>Category:       conf
>Synopsis:       Serial drainwait shouldn't be zero (forever) by default
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 23 01:10:01 PDT 2002
>Closed-Date:    Tue Apr 23 01:28:00 PDT 2002
>Last-Modified:  Tue Apr 23 06:20:01 PDT 2002
>Originator:     Daniel O'Connor
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
>Environment:
System: FreeBSD chowder.gsoft.com.au 4.5-STABLE FreeBSD 4.5-STABLE #0: Wed Mar 27 20:47:35 CST 2002 darius@chowder
.dons.net.au:/usr/obj/usr/src/sys/CHOWDER i386


>Description:
With the default it seems very easy to get a process stuck forever (say connected to a UPS)

>How-To-Repeat:
Not really sure but I have 2 stuck apcsmart processes on machines I would rather not reboot.

>Fix:

Apply http://www.gsoft.com.au/~doconnor/sensible-drainwait.diff
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: sobomax 
State-Changed-When: Tue Apr 23 01:27:27 PDT 2002 
State-Changed-Why:  
Committed, thank you! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=37370 

From: Bruce Evans <bde@zeta.org.au>
To: "Daniel O'Connor" <doconnor@gsoft.com.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: conf/37370: Serial drainwait shouldn't be zero (forever) by
 default
Date: Tue, 23 Apr 2002 22:10:05 +1000 (EST)

 On Tue, 23 Apr 2002, Daniel O'Connor wrote:
 
 > >Description:
 > With the default it seems very easy to get a process stuck forever (say connected to a UPS)
 >
 > >How-To-Repeat:
 > Not really sure but I have 2 stuck apcsmart processes on machines I would rather not reboot.
 >
 > >Fix:
 >
 > Apply http://www.gsoft.com.au/~doconnor/sensible-drainwait.diff
 
 This just breaks default().  From the non-broken rc.serial:
 
 > default() {
 > 	# Reset everything changed by the other functions to initial defaults.
 	                                                     ^^^^^^^
 > ...
 > 		comcontrol /dev/tty${ci}${i} dtrwait 300 drainwait 0
 		                                     ^^^           ^
 
 The initial defaults are determined by the driver, not by rc.serial.  The
 default for drainwait is known to be 0, since any other value would break
 POSIX conformance.  The default for dtrwait is not so well known; the
 value of 300 is just sio's rather arbitrary value.
 
 Actual fix: use values suitable for your application and/or hardware.
 I often use 1 for drainwait to unwedge terminals as fast as possible,
 and notice the problems from the non-POSIX-conformance of this when
 I forget to change it back to a reasonable value.  Any nonzero value
 is just broken if normal draining for some reason takes longer.
 
 Bruce
 

From: Bruce Evans <bde@zeta.org.au>
To: "Daniel O'Connor" <doconnor@gsoft.com.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: conf/37370: Serial drainwait shouldn't be zero (forever) by
 default
Date: Tue, 23 Apr 2002 22:49:51 +1000 (EST)

 On Tue, 23 Apr 2002, Bruce Evans wrote:
 
 > On Tue, 23 Apr 2002, Daniel O'Connor wrote:
 >
 > > >Description:
 > > With the default it seems very easy to get a process stuck forever (say connected to a UPS)
 > >
 > > >How-To-Repeat:
 > > Not really sure but I have 2 stuck apcsmart processes on machines I would rather not reboot.
 > >
 > > >Fix:
 > >
 > > Apply http://www.gsoft.com.au/~doconnor/sensible-drainwait.diff
 >
 > This just breaks default().  From the non-broken rc.serial:
 >
 > > default() {
 > > 	# Reset everything changed by the other functions to initial defaults.
 > 	                                                     ^^^^^^^
 > > ...
 > > 		comcontrol /dev/tty${ci}${i} dtrwait 300 drainwait 0
 > 		                                     ^^^           ^
 >
 > The initial defaults are determined by the driver, not by rc.serial.  The
 > default for drainwait is known to be 0, since any other value would break
 > POSIX conformance.  The default for dtrwait is not so well known; the
 > value of 300 is just sio's rather arbitrary value.
 
 Oops, the change only "breaks" default() in non-current versions of
 FreeBSD.  The initial default is still 0 in RELENG_4, but in -current
 it is 300 at boot time and `sysctl kern.drainwait` after boot time.
 
 This rarely matters, since if you use /etc/rc.serial at all, then you
 should only use default() to restore the initial defaults in preparation
 for changing only some of the defaults using one of the other functions
 in rc.serial or otherwise.  All of the other functions in rc.serial
 except mouse() set drainwait to a more useable value.  A timeout might
 be useful even for mouse(), to recover from the error of setting
 crtscts on the mouse.
 
 Bruce
 

From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: conf/37370: Serial drainwait shouldn't be zero (forever) by
	default
Date: 23 Apr 2002 22:49:29 +0930

 On Tue, 2002-04-23 at 22:19, Bruce Evans wrote: 
 > This rarely matters, since if you use /etc/rc.serial at all, then you
 > should only use default() to restore the initial defaults in preparation
 > for changing only some of the defaults using one of the other functions
 > in rc.serial or otherwise.  All of the other functions in rc.serial
 > except mouse() set drainwait to a more useable value.  A timeout might
 > be useful even for mouse(), to recover from the error of setting
 > crtscts on the mouse.
 > 
 Hmm I see. 
 I didn't actually read all of rc.serial (duh) and assumed that it was
 called by /etc/rc in some fashion :) 
 (Then again, perhaps the comment and the bottom of the file should be at
 the top..) 
 
 My complaint was motivated by a hung process in a remote system with a
 UPS connected. The only thing I could think that was causing it was
 this.. 
    66   271     1   0   3  0   924  260 -      R+   con-  52:12.04 /usr/local/sbin/apcsmart /dev/cuaa0
 I can't kill it, I have now set dtrwait and drainwait to 1 and it still
 persists, so maybe my problem lies elsewhere. 
 
 Regardless the comcontrol man page appears incorrect..
 It specifies that the default for drainwait is 5 minutes, whereas on my
 system (RELENG_4) it is 0. Maybe fix the man page? :)
 
 -- 
 Daniel O'Connor software and network engineer
 for Genesis Software - http://www.gsoft.com.au
 "The nice thing about standards is that there
 are so many of them to choose from."
   -- Andrew Tanenbaum
 GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5
 
>Unformatted:
