Date: Sat, 29 Jan 2000 10:58:53 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Mike Smith <msmith@freebsd.org> Cc: new-bus@freebsd.org Subject: Re: Some serious problems with ISA and PnP Message-ID: <Pine.BSF.4.10.10001291055430.25770-100000@salmon.nlsystems.com> In-Reply-To: <200001281949.LAA02604@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10001291055430.25770-100000>