From owner-freebsd-current Sat Sep 2 22:40:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA08733 for current-outgoing; Sat, 2 Sep 1995 22:40:02 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA08715 for ; Sat, 2 Sep 1995 22:39:59 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA16270; Sat, 2 Sep 1995 22:39:20 -0700 From: "Rodney W. Grimes" Message-Id: <199509030539.WAA16270@gndrsh.aac.dev.com> Subject: Re: Getting around conflicts for a driver w/out base address To: deischen@iworks.InterWorks.org (Daniel M. Eischen) Date: Sat, 2 Sep 1995 22:39:20 -0700 (PDT) Cc: FreeBSD-current@FreeBSD.Org (FreeBSD current) In-Reply-To: <9509030255.AA25934@iworks.InterWorks.org> from "Daniel M. Eischen" at Sep 2, 95 09:55:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2395 Sender: current-owner@FreeBSD.Org Precedence: bulk > > >Hum, yea, I think config(8) is doing the wrong thing with null ``port'' > >specifications. What does the ../../compile/KERNEL/ioconf.c file look > >like? [Just the applicable mib0, lpt and ahc lines.] > > I'll have to wait until Tuesday, but the ahc and lpt stuff should be just > the same as configured with a generic kernel - I made no changes to their > configuration. > > { 3, &ahcdriver, 0x0000, 0, -1, C 0x00000, 0, ahcintr, 1, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, > > { 12, &lptdriver, 0xffffffff, IRQ7, -1, C 0x00000, 0, lptintr, 0, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, > { 13, &lptdriver, 0xffffffff, 0, -1, C 0x00000, 0, NULL, 1, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, > { 14, &lptdriver, 0xffffffff, 0, -1, C 0x00000, 0, NULL, 2, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, > Hummm... looks as if config emits 0x0000 for the port address when you have none specified. That is arguably incorrect since address 0x0000 is a valid I/O port address. [And when I wrote the conflict code I was well aware that it was a valid address, but I was not aware that was what config emitted for no specified address :-(]. It looks like config is specifically hacked to emit -1 for port?, which is also arguable incorrect as 0xffffffff is a valid port address internal to the pentium CPU (it will not drive this to the external bus but there are some very special undocumented things in the very high 32 bit port address ranges [Don't ask NDA's prevent discussion beyond what I have already stated]). It looks to me as if the isa_device struct needs another qualifying field for iobase that says it is either wildcarded (port?), unspecified (no port spec at all) or given (port 0xf0f). > The mib driver (MIL-STD-1553B) and board are installed on a machine at > work and one > of those darn firewalls prevents me from getting in from home :(. You mean to tell me the 1553B bus is still alive? I spent 5 years with Rolm Mil-spec computers and use to be around a lot of 1553B based equipment. > Thanks for replying and cc'ing to -current :) No problem, though the thread really should stay on -current, and this reply should have been to current :-(. So I am going to stuff it back onto -current. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD