From owner-freebsd-current Mon Jan 31 15: 6:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 72F3314E57; Mon, 31 Jan 2000 15:06:43 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12FPu1-000H0o-0A; Mon, 31 Jan 2000 23:06:37 +0000 Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id XAA10836; Mon, 31 Jan 2000 23:10:16 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 31 Jan 2000 23:10:16 +0000 (GMT) From: Doug Rabson To: "Matthew N. Dodd" Cc: Mike Smith , Nikolai Saoukh , freebsd-current@freebsd.org Subject: Re: kldloaded driver not called at load time In-Reply-To: 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 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: 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