From oberman@es.net  Fri Feb 28 13:12:57 2003
Return-Path: <oberman@es.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 36DE537B401; Fri, 28 Feb 2003 13:12:57 -0800 (PST)
Received: from postal1.es.net (postal1.es.net [198.128.3.205])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 35E5943F75; Fri, 28 Feb 2003 13:12:56 -0800 (PST)
	(envelope-from oberman@es.net)
Received: from ptavv.es.net ([198.128.4.29])
        by postal1.es.net (Postal Node 1) with ESMTP id MUA74016;
        Fri, 28 Feb 2003 13:12:50 -0800
Received: from ptavv (localhost [127.0.0.1])
	by ptavv.es.net (Tachyon Server) with ESMTP
	id 84FCA5D04; Fri, 28 Feb 2003 13:12:50 -0800 (PST)
Message-Id: <20030228211250.84FCA5D04@ptavv.es.net>
Date: Fri, 28 Feb 2003 13:12:50 -0800
From: "Kevin Oberman" <oberman@es.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: "Bruce A. Mah" <bmah@freebsd.org>, bde@freebsd.org,
	freebsd-gnats-submit@freebsd.org
In-Reply-To: Your message of "Fri, 28 Feb 2003 22:56:27 +1100."
             <20030228220111.Y22326-100000@gamplex.bde.org> 
Subject: Re: PR bin/33963 

>Number:         48792
>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 13:20:00 PST 2003
>Closed-Date:    Fri Feb 28 16:34:17 PST 2003
>Last-Modified:  Fri Feb 28 16:34:17 PST 2003
>Originator:     oberman@es.net
>Release:        
>Organization:
>Environment:
>Description:
 > Date: Fri, 28 Feb 2003 22:56:27 +1100 (EST)
 > From: Bruce Evans <bde@zeta.org.au>
 > 
 > 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 like this a LOT better than the current verbiage and better than
 mine. Another way to make it clearer that the second line is an
 extension of the first would be:
 printf("      port might not be enabled\n",     device_get_unit(dev));
 
 In the end the appearance of dmesg will always be a bit ugly and oft
 times a bit confusing. Extra line are evil as they leave less data on
 the 24 (or whatever) lines available on the console. (Perhaps it's
 time to think about increasing the default value of SC_HISTORY_SIZE.)
 
 > 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.
 
 ACPI does not run properly on a great many laptops (both if my IBMs
 included) and even PNP can be problematic, although now that we have
 IRQ sharing for PCCARD, it's generally not evil. But there are regular
 messages on questions asking about this message, so people are still
 seeing it a lot in V4.
 
 > > > 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 have a specific case. I maintain (or try to, as it won't work in V5)
 the package to support the mWave modem on some older IBM ThinkPads.
 Since the 16550A is emulated in software, there are cases where
 initialization problems result in the FIFO probe failing and the
 device being identified as an 8250. I know just what this means, but
 it took me a while to figure it out and others have just given up,
 deciding that the port does not work.
 
 R. Kevin Oberman, Network Engineer
 Energy Sciences Network (ESnet)
 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
 E-mail: oberman@es.net			Phone: +1 510 486-8634
>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:41 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:41 PST 2003 
Responsible-Changed-Why:  

Take from gnats-admin. 

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