From owner-freebsd-hackers Sun Dec 3 19:33:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA18384 for hackers-outgoing; Sun, 3 Dec 1995 19:33:01 -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 TAA18377 for ; Sun, 3 Dec 1995 19:32:50 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA18945; Mon, 4 Dec 1995 14:29:56 +1100 Date: Mon, 4 Dec 1995 14:29:56 +1100 From: Bruce Evans Message-Id: <199512040329.OAA18945@godzilla.zeta.org.au> To: andrew@fortress.org, bde@zeta.org.au Subject: Re: Strange Multi-port SIO behaviour Cc: hackers@FreeBSD.org, msmith@atrad.adelaide.edu.au Sender: owner-hackers@FreeBSD.org Precedence: bulk >> If this is the problem, then each board is left in a weird state until >> after all probes and attaches on it have completed. Then its state >> becomes OK. >What would happend if I setup the system like this: >sio4: at 0x1b8-0x1bf flags 0x781 irq 7 (master) >sio5: at 0x1b0-0x1b7 flags 0x781 > . >sio7: at 0x1a0-0x1a7 flags 0x781 >This way the master port would be initialized first and the remaining >ports would come into line? It would make no difference because the master port is already initialized at boot time. Actually, the AST/4 master port probably needs to be initialized in another way for my fix to make a difference. MCR_IENABLE works in a different way on AST/4's after they have been initialized to multiport mode. The driver goes to some trouble to keep it low for AST/4's and high for everything else, and the fix mainly sets it low for all ports. >Does the included diff stand on its own or does it need changes to other >files? It should be complete. Bruce