On Mon, 31 Jan 2000, Matthew N. Dodd wrote:
> On Mon, 31 Jan 2000, Mike Smith wrote:
> > This is because the unknown driver is never revoked once it owns your
> > device. It's a(nother) bug in the ISA bus code. 8(
>
> Looking at the code in sys/kern/subr_bus.c I'm not sure how any drivers
> are revoked by a higher priority match.
>
> This is probably desirable given the nature of most drivers and one of the
> reasons for letting BUS_PROBE_NOMATCH announce your 'unknown' hardware.
>
> If a driver is attached and providing interfaces to the system (network,
> scsi, what have you.) then loading a higher priority driver shouldn't
> cause that device to detach as it would potentially cause the system to
> become confused.
>
> I never liked the unknown driver. I vote we kill it and let
> isa_probe_nomatch() deal with things. (I'll have to write
> isa_probe_nomatch() but I don't see that as a problem.)
>
> Nikolai, your easy fix is to comment out the relevent module declaration
> for the 'unknown' driver in isa_common.c.
This is probably the right workaround for now.
The unknown driver does serve a purpose. It indirectly allows resources
associated with the device to be allocated so that other PnP devices are
not allocated on top.
On reviewing the code, this seems to happen (in isa_probe_children)
whether or not the preceding call to device_probe_and_attach() succeeded
so removing the unknown driver would mean that resources are allocated for
the un-attached device which is likely to cause trouble.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
