From owner-freebsd-hardware Wed May 21 02:54:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA01378 for hardware-outgoing; Wed, 21 May 1997 02:54:58 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA01373 for ; Wed, 21 May 1997 02:54:55 -0700 (PDT) Date: Wed, 21 May 1997 5:54:55 -0400 From: Dan Welch To: "TRUTH::WELCHDW"@wofford.edu CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970521055455.22a210ad@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I/O ports 0x278-0x27F are standard for an LPT (parallel) port. Yes, that was my first thought, too, but the systems all have only lpt0 (at 0x378) as far as I can tell. > In addition, port 0x279 is used for Plug-N-Play setup. Thanks for that address. I didn't know it, so my approach was to move the board to a system older than p-n-p motherboards and non-pci for same reason: I don't know all addresses used by pci. The problem persisted in altered form on the older system. > And, IRQ 12 is used for PS/2 mouse ports built into motherboards. I used the cmos setup to turn that off. Is that reliable? I was unsure, so I tested at a couple other free irq's just in case. The "bad" ports do change with these alterations, supporting the contention hypothesis, but also consistent with a bus timing problem, I think. Those tests all have the shortcoming of having been at irq>9 since all irq<9 are busy. Guess I'll free an irq<9 and try the 0x100 range again with that.