Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jan 2000 11:49:31 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        new-bus@freebsd.org
Subject:   Some serious problems with ISA and PnP
Message-ID:  <200001281949.LAA02604@mass.cdrom.com>

next in thread | raw e-mail | index | archive | help

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?

Thanks.


-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




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?200001281949.LAA02604>