From owner-freebsd-hackers  Tue Nov 28 04:50:16 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id EAA03411
          for hackers-outgoing; Tue, 28 Nov 1995 04:50:16 -0800
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA03406
          for <hackers@FreeBSD.ORG>; Tue, 28 Nov 1995 04:50:11 -0800
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id XAA17851; Tue, 28 Nov 1995 23:49:24 +1100
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
Message-Id: <199511281249.XAA17851@rf900.physics.usyd.edu.au>
Subject: Re: Problem with sio probe and Mach64 PCI video card
To: bde@zeta.org.au (Bruce Evans)
Date: Tue, 28 Nov 1995 23:49:24 +1100 (EST)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199511281231.XAA28803@godzilla.zeta.org.au> from "Bruce Evans" at Nov 28, 95 11:31:18 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1930      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

>>I've just installed an ASUS PCI-AV264CT video card, based on the
>>Mach64 "CT" chipset, into an ASUS PCI/I-P54TP4 motherboard with 90MHz
>>Pentium CPU.  I'm planning to do some work on getting Mach64 CT support
>>into XFree86.  When I booted FreeBSD 2.1, the screen went blank fairly
>>early in the boot probe sequence.  When connected to a DPMS monitor,
>>it went into "OFF" mode indicating no sync present.  After a bit of
>>experimentation I found that this problem could be avoided by disabling
>>the two sio devices I had configures (sio0 and sio1).  Enabling either
>>one separately still resulted in the problem.
>
>>I've previously seen the video go blank for a fraction of a second when
>>booting on a similar machine with an S3 964 card installed.  I wondered
>>why this happened, but since it didn't cause any problems I thought nothing
>>more of it.
>
>>My guess is that the sio probe is writing to a Mach64 register.  In the
>>S3 case it is possilbly successfully restoring it too.  I haven't had
>
>sio always writes 0 to port 0x2E8+4 (the modem control reg for the usual
>sio3 address) if >= 1 sio device is configured.  It doesn't attempt to
>restore the original value; however, if sio3 is enabled at port IO_COM4,
>as it is in GENERIC, then other values will be written to 0x2EC and nearby.
>
>The change at the end replaces bogus internal array of ports by the ones
>specified in the config.  This requires the config to specify sio2 and
>sio3 if the ports exist even if they are unusable under FreeBSD due to
>a conflict, and S3 owners to boot with -c and disable sio3 before the
>monitor blows up :-).  sio3 shouldn't be in GENERIC.

The patch fixes the problem -- thanks!  I don't understand why this means
that the config must specify ports that are not usable under FreeBSD.
I think "S3 owners" should be replaced by "IBM8514/A, S3, Mach{8,32,64}
and any chipset with an 8514/A ancestory owners".

David