From owner-freebsd-new-bus Sat Jan 29 3: 0:32 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 21D6D14F88; Sat, 29 Jan 2000 03:00:19 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12EVby-000G72-0B; Sat, 29 Jan 2000 11:00:15 +0000 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 LAA67033; Sat, 29 Jan 2000 11:03:15 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 29 Jan 2000 10:58:53 +0000 (GMT) From: Doug Rabson To: Mike Smith Cc: new-bus@freebsd.org Subject: Re: Some serious problems with ISA and PnP In-Reply-To: <200001281949.LAA02604@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Jan 2000, Mike Smith wrote: > > I ran into something last night that I think needs some fairly urgent > attention, relating to the handling of resources for ISA PnP devices. > > > /* > * Finally assign resource to pnp devices and probe them. > */ > if (bootverbose) > printf("isa_probe_children: probing PnP devices\n"); > for (i = 0; i < nchildren; i++) { > device_t child = children[i]; > struct isa_device* idev = DEVTOISA(child); > > if (!TAILQ_FIRST(&idev->id_configs)) > continue; > > if (isa_assign_resources(child)) { > struct resource_list *rl = &idev->id_resources; > struct resource_list_entry *rle; > > device_probe_and_attach(child); > > The problem here is that isa_assign_resources() doesn't just find a > viable set of resources for the child, it actually allocates > _and_activates_ them. > > This is bad in a couple of cases. If we don't have a driver for the > device, we never throw the resources away and deconfigure the device, so > we can't reuse them for something else. That's not so good. > > In my case, and making it much worse, I ran into a problem with how this > interacts with the sorts of things that are typically attached to the > PNP0c02 identifier on the i386. When a memory resource is activated, it's > mapped into the kernel's address space by calling pmap_mapdev. > Typically, this is just wasteful if the device isn't going to use the > memory. Unfortunately, it's not uncommon to attach a set of resources to > a PNP0c02 identifier that describe all of the physical memory in a > system. This isn't fatal until you try it on a system with enough memory > to exhaust the kernel's virtual address space, but it does result in > blowing out the kernel's pagetables. > > I think that the only remedy here is to handle ISA PnP resources the same > way that other busses do; make the information on the resources available > to the driver and let _it_ decide how to allocate them. It's definitely > not appropriate for the bus code to be doing it - it simply can't tell > what is the "right" thing to do. > > Interestingly, it seems that many, if not all, of the ISA drivers already > allocate their own resources. How is it that this can work at all if > they're already allocated in the PnP case? If this is the case, how much > would it hurt to simply not reserve/allocate them at all in the ISA bus > code? > > Is there anything else I'm missing here? This code needs to find out where to map the resources for a given PnP device. The only way to decide whether a given range is available is to attempt to allocate that range so that is how the code is written. It does release the resources which it allocated after it finds a place for them and the driver will later allocate them itself using the locations found for them. The simplest fix here is probably to just remove the RF_ACTIVE flag from the calls to bus_alloc_resource(). -- 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-new-bus" in the body of the message