From bde@zeta.org.au  Fri Feb 28 03:55:00 2003
Return-Path: <bde@zeta.org.au>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id E22D537B401; Fri, 28 Feb 2003 03:54:59 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 8097F43F3F; Fri, 28 Feb 2003 03:54:58 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA16331;
	Fri, 28 Feb 2003 22:54:55 +1100
Message-Id: <20030228220111.Y22326-100000@gamplex.bde.org>
Date: Fri, 28 Feb 2003 22:56:27 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
To: "Bruce A. Mah" <bmah@freebsd.org>
Cc: Kevin Oberman <oberman@es.net>, <bde@freebsd.org>,
	<freebsd-gnats-submit@freebsd.org>
In-Reply-To: <20030225184409.GA54634@intruder.bmah.org>
Subject: Re: PR bin/33963

>Number:         48774
>Category:       bin
>Synopsis:       Re: PR bin/33963
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    ceri
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 28 04:00:27 PST 2003
>Closed-Date:    Fri Feb 28 16:33:39 PST 2003
>Last-Modified:  Fri Feb 28 16:33:39 PST 2003
>Originator:     bde@zeta.org.au
>Release:        
>Organization:
>Environment:
>Description:
 On Tue, 25 Feb 2003, Bruce A. Mah wrote:
 
 > If memory serves me right, Kevin Oberman wrote:
 >
 > > imp vetoed the first section of the patch and I agree with his point
 > > in doing so.
 >
 > Heh.  Actually that was the part that got committed to HEAD.  I made
 > an offer to bde to back this out but he didn't take me up on it
 > (yet)...the offer still stands.
 
 I think both parts got committed to HEAD.  I mostly agreed with the
 first part but not with the second part.  All I've done is fix the
 formatting and improve the English of the first part in my version:
 
 %%%
 Index: sio.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
 retrieving revision 1.382
 diff -u -2 -r1.382 sio.c
 --- sio.c	11 Oct 2002 20:22:20 -0000	1.382
 +++ sio.c	23 Feb 2003 13:59:40 -0000
 @@ -766,6 +783,5 @@
  		"sio%d: configured irq %ld not in bitmap of probed irqs %#x\n",
  		    device_get_unit(dev), xirq, irqs);
 -		printf(
 -		"sio%d: port may not be enabled\n",
 +		printf("sio%d: port might not be enabled\n",
  		    device_get_unit(dev));
  	}
 %%%
 
 I think it's worth saying something here to decrypt/disalarm the "not in
 bitmap of probed irqs" message.  The "port might not be enabled" message
 is just to clarify the previous message, but it's hard to write paragraphs
 in boot message so it looks more like a separate message and thus may
 further obscure things.  Some more rewording might help, and it wouldn't
 hurt to put this in the man page.   I rather hoped that you (bmah) would
 handle the doc aspects of this.
 
 This code is only reached in the !noprobe case, which should be only in
 legacy cases where it should not be suprising to get misconfigured irqs,
 but I think pnp and/or acpi are now too successful at finding devices
 (even when you have disabled them in static hints?) so we now get more
 half-working probes.  So the main problems here are:
 - the driver doesn't understand that some hints are better than others
   so it shouldn't attempt to check them.
 - various problems if multiple sio devices share an interrupt (and
   interrupts are ISAish (edge sensitive, etc.) so they can't be shared
   at runtime.  The message is the first hint of such problems.
 
 > > But I think the second half (8250 or not responding) is a
 > > legitimate bug fix as the driver currently implies that it actually
 > > could tell the device is an 8250 when the message is really only an
 > > indication that the driver did not receive a response to its query. It
 > > assumes that this means an 8250 as any flavor of 16550 or any decent
 > > clone will respond in some way.
 >
 > What I was recall being told is that the underlying cause was that the
 > driver shouldn't have been trying to probe the device anyways.  (A
 > separate, but related problem.)
 
 It is in the attach code actually.  I don't understand how the attach
 routine can be called on completely "not responding" devices.  The
 noprobe case makes the probe sloppy but should only be used for pccards
 and certain broken cases where another layer hopefully knows what it's
 doing.  Technically, I think we can do the fifo test first to distinguish
 the >= 16550 UARTs.  Then the scratch register test would only be needed
 to distinguish between ancient UARTs.  NetBSD's com.c doesn't bother
 with it.
 
 > > I can re-submit with only the single line change, but if bde "owns"
 > > the sio driver these days, I'll leave it up to him.
 >
 > Yeah.  I should have done a better job handling this PR.
 
 Me too, sigh.  Now I mostly don't work run anything near a current
 -current, so find it hard to test things for, but I have more interest
 in making -stable work right.  This doesn't extend to large configuration
 changes though.  (I've grown to detest large init/config code.)
 
 Bruce
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: ceri 
State-Changed-When: Fri Feb 28 16:33:05 PST 2003 
State-Changed-Why:  

Misfiled followup to bin/33963 [content migrated]. 


Responsible-Changed-From-To: gnats-admin->ceri 
Responsible-Changed-By: ceri 
Responsible-Changed-When: Fri Feb 28 16:33:05 PST 2003 
Responsible-Changed-Why:  

Take from gnats-admin. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48774 
>Unformatted:
