From owner-freebsd-hackers  Tue Nov 28 04:34:53 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id EAA02681
          for hackers-outgoing; Tue, 28 Nov 1995 04:34:53 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA02674
          for <hackers@FreeBSD.ORG>; Tue, 28 Nov 1995 04:34:40 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA28803; Tue, 28 Nov 1995 23:31:18 +1100
Date: Tue, 28 Nov 1995 23:31:18 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511281231.XAA28803@godzilla.zeta.org.au>
To: dawes@rf900.physics.usyd.edu.au, hackers@FreeBSD.ORG
Subject: Re: Problem with sio probe and Mach64 PCI video card
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.

If you don't want to recompile, edit the kernel binary: find the address
of _likely_com_ports and replace the 0x2E8 entry by something harmless,
e.g., 0x3F8.

Bruce

*** sio.c~	Wed Nov 22 02:53:12 1995
--- sio.c	Tue Nov 28 23:08:38 1995
***************
*** 332,338 ****
  };
  
- /* XXX - configure this list */
- static Port_t likely_com_ports[] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8, };
- 
  static struct kern_devconf kdc_sio[NSIO] = { {
  	0, 0, 0,		/* filled in by dev_attach */
--- 332,335 ----
***************
*** 495,499 ****
  {
  	static bool_t	already_init;
- 	Port_t		*com_ptr;
  	bool_t		failures[10];
  	int		fn;
--- 492,495 ----
***************
*** 502,505 ****
--- 498,502 ----
  	u_char		mcr_image;
  	int		result;
+ 	struct isa_device	*xdev;
  
  	sioregisterdev(dev);
***************
*** 512,520 ****
  		 * XXX the gate enable is elsewhere for some multiports.
  		 */
! 		for (com_ptr = likely_com_ports;
! 		     com_ptr < &likely_com_ports[sizeof likely_com_ports
! 						 / sizeof likely_com_ports[0]];
! 		     ++com_ptr)
! 			outb(*com_ptr + com_mcr, 0);
  #if NCRD > 0
  /*
--- 509,515 ----
  		 * XXX the gate enable is elsewhere for some multiports.
  		 */
! 		for (xdev = isa_devtab_tty; xdev->id_driver != NULL; xdev++)
! 			if (xdev->id_driver == &siodriver && xdev->id_enabled)
! 				outb(xdev->id_iobase + com_mcr, 0);
  #if NCRD > 0
  /*