From owner-freebsd-current Sat Sep 4 16:14:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 1F819152D6 for ; Sat, 4 Sep 1999 16:14:02 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id AAA46900; Sun, 5 Sep 1999 00:15:20 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 5 Sep 1999 00:15:20 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: John-Mark Gurney , "Zach N. Heilig" , freebsd-current@freebsd.org Subject: Re: PNP ids missing in sio.c In-Reply-To: <19990904190629.898ED1CAA@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Sep 1999, Peter Wemm wrote: > Doug Rabson wrote: > > On Sat, 4 Sep 1999, John-Mark Gurney wrote: > > > > > Doug Rabson scribbled this message on Sep 4: > > > > > This is of course a special case, a cranky network card and a > > > > > non-compiling driver for it. If the new pnp code avoids using resource > s > > > > > hard-wired to non-pnp isa devices (it may, I changed hardware before th > e > > > > > code was fixed), there shouldn't be any problems. It was an excellent > > > > > excuse to boot that nic anyway. > > > > > > > > The trick for this is to make sure that the config file contains accurate > > > > descriptions of all your non-pnp hardware. In this case, if you have: > > > > > > > > device ed0 at isa? port 0x300 irq 5 ... > > > > > > > > then the subsequent pnp probes should avoid those port and irq settings. > > > > > > but the problem is that he couldn't have the line in because the driver > > > wouldn't compile... so are we going to add a dummy isa device that takes > > > up resources so that this won't happen again? maybe the user has some > > > win95 only isa card or something... but this needs to be able to be > > > configured... along w/ doing this at boot -c time too... > > > > We already have a dummy driver (unknown) which can be adapted for this > > purpose. Perhaps this is the best solution. > > I'm curious what can be made of the PNP resource list we get from the BIOS > at boot time... It lists motherboard resources too, we could probably end > up with a fairly complete map of known resources to avoid. I bet we can roll another enumerator similar to pnp.c which takes the bios output and turns it into devices. It would mean removing all the probe hints from your kernel config to avoid confusion but apart from that it should work really well. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message