From owner-freebsd-current Sat Sep 4 21:41:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles529.castles.com [208.214.165.93]) by hub.freebsd.org (Postfix) with ESMTP id 60A5A1508C for ; Sat, 4 Sep 1999 21:41:50 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id VAA09257; Sat, 4 Sep 1999 21:34:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199909050434.VAA09257@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: John-Mark Gurney Cc: freebsd-current@freebsd.org Subject: Re: PNP ids missing in sio.c In-reply-to: Your message of "Sat, 04 Sep 1999 19:34:19 PDT." <19990904193419.01873@hydrogen.fircrest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Sep 1999 21:34:09 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is one reason why I think that the PnP scan should be done > > _before_ the legacy scan; there are cases where the legacy scan is > > going to find stuff that the PnP enumerator also knows about. If the > > PnP enumerator has already found it, then the legacy scan aborts; in > > the reverse situation the PnP enumerator has no way of knowing that the > > device has already been claimed. > > ummm... I thought that the plan was to disable all PnP devices, do the > legacy isa probes, and then reenable the PnP devices and probe them... The fact that a device is reported via PnP does not guarantee that you can disable it. Most of the "devices" reported by the PnP BIOS can neither be disabled nor moved. > that way you don't have the problem of legacy probes grabing a card... It doesn't avoid attempting to probe for a legacy device in a region where a fixed but PnP-known device exists. > > Another argument for making the PnP scan first is that the BIOS > > identifies a whole pile of "do not go there" regions which you don't > > want anything, even a legacy device probe, looking at. > > hmmm.... sounds like we need to have a PnP attach routine that will > grab all these resources.... I haven't looked at the latest PnP code, > so I'm not sure exactly how the configure stuff is handled... The enumerator should assign these resources to a placeholder; I was thinking the nexus was as good an owner as any. If there's an "unknown" device that's probably even better. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message