> > 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. \\ [EMAIL PROTECTED]
\\ -- Joseph Merrick \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
