From nobody  Sun Nov  2 15:19:25 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA17433;
          Sun, 2 Nov 1997 15:19:25 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199711022319.PAA17433@hub.freebsd.org>
Date: Sun, 2 Nov 1997 15:19:25 -0800 (PST)
From: cjafe@tin.it
To: freebsd-gnats-submit@freebsd.org
Subject: sio0/sio1 not found - probe test 5 and 8 failed
X-Send-Pr-Version: www-1.0

>Number:         4921
>Category:       kern
>Synopsis:       sio0/sio1 not found - probe test 5 and 8 failed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov  2 15:20:01 PST 1997
>Closed-Date:    Sun Apr 19 10:39:35 PDT 1998
>Last-Modified:  Sun Apr 19 10:40:00 PDT 1998
>Originator:     Stefano Briganti
>Release:        2.2.2
>Organization:
none
>Environment:
>Description:
Totem motherboard TX1, bios 1.2N, Award Bios 4.51PG, chipset 430Tx, ALI 5135, AMD K6 166Mhz. 
during boot i receive this message:

sio0 not found
probe test 5 failed
sio1 not found
probe test 8 failed

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

From: j@uriah.heep.sax.de (J Wunsch)
To: cjafe@tin.it
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/4921: sio0/sio1 not found - probe test 5 and 8 failed
Date: Wed, 5 Nov 1997 08:03:24 +0100

 As cjafe@tin.it wrote:
 
 > >Description:
 > Totem motherboard TX1, bios 1.2N, Award Bios 4.51PG, chipset 430Tx, ALI 5135, AMD K6 166Mhz. 
 > during boot i receive this message:
 > 
 > sio0 not found
 > probe test 5 failed
 > sio1 not found
 > probe test 8 failed
 
 Odd.  What are they using for the UART chip?  Right now, only some
 (crappy) internal modems were known to be slow in responding in their
 interrupt logic.  This was somewhat understandable, since these modems
 don't have real UARTs, but emulate the UART with an ASIC.
 
 But in your case, it seems to happen with the UART chip on the mother-
 board (which is supposed to be a real UART).  Would increasing the
 1 ms timeout right before tests 5 and 8 help?  I still agree with Bruce
 though that 1 ms is fairly long in order to allow a chip to clear its
 interrupt request.  Remember, 1 ms is a single character at the
 nowadays awfully slow speed of 9600 Bd.  It means the UART doesn't
 clear the interrupt after about 100 other characters were flowing in
 at 115 kBaud...
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From: Bruce Evans <bde@zeta.org.au>
To: cjafe@tin.it, freebsd-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: kern/4921: sio0/sio1 not found - probe test 5 and 8 failed
Date: Mon, 10 Nov 1997 17:10:04 +1100

 >>Description:
 >Totem motherboard TX1, bios 1.2N, Award Bios 4.51PG, chipset 430Tx, ALI 5135, AMD K6 166Mhz. 
 >during boot i receive this message:
 >
 >sio0 not found
 >probe test 5 failed
 >sio1 not found
 >probe test 8 failed
 
 This is probably caused by nonstandard hardware configuration of the IRQs.
 I get similar failures if I swap the IRQs using userconfig.  The above
 messages can't happen (please be careful transcribing error messages),
 but the asymmetry of the failures suggests that sio0 is getting in the
 way of sio1, so I was able to debug this quickly.  I get the following
 messages:
 
 sio0: probe test 3 failed
 sio0: not found at 0x3f8
 sio1: probe test 5 failed
 sio1: probe test 8 failed
 sio1: not found at 0x2f8
 
 With the IRQs swapped, test 3 on sio0 normally fails because it tests
 the wrong IRQ and sio1 has not been initialized enough to confuse the
 issue.  But sometimes, sio1 will be driving the IRQ _low_ at boot time.
 Then partial initalization of sio1 will float the IRQ high and cause a
 false positive for test 3 on sio0.  The error will be detected later
 because the IRQ won't go away so tests 5 and 8 on sio0 will fail.
 This behaviour is surprising.  I would have expected the floating IRQ
 to cause a false positive for test 3 on sio0 in all (IRQ swapped) cases.
 It doesn't because the interrupt controller (ICU) loses track of the
 IRQ state when the ICU is reset.
 
 With the IRQs swapped, tests 5 and 8 on sio1 always fail because sio0
 _has_ been initialized enough to confuse the issue.  sio0's IRQ is
 driven low and high during the sio0 probe and floats high at the end
 of the probe, so the behaviour is the same as in the "sometimes" case
 above (with the sio's swapped).
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sun Apr 19 10:39:35 PDT 1998 
State-Changed-Why:  
timed out, hardware problem. 
>Unformatted:
