pccard0: Card has no functions! OR PCI memory range allocation
problem?
Bengt Ahlgren
bengta at sics.se
Tue Mar 8 02:28:41 PST 2005
Warner Losh <imp at bsdimp.com> writes:
> > After unloading the if_ath driver, it says the following instead:
> >
> > pcib1: device pccard0 requested decoded memory range 0xd0200000-0xdfffffff
> > cis mem map 0xd63ab000 (resource: 0xd0200000)
>
> Hmmm, looks like you're the first person to hit this bug. I knew it
> was theoretically possible to provoke it, but never could construct a
> test case locally that would.
>
> > Now to the bottom line: where is the bug?
> >
> > 1) In the if_ath driver module which deallocated a PCI memory range
> > which it didn't allocate (the kernel did at boot).
> >
> > 2) In the PCI memory allocation/deallocation routines which allowed
> > the loadable driver to deallocate a PCI memory range that was
> > allocated at boot.
> >
> > 3) In cbb/pccard which perhaps shouldn't be allowed to use the memory
> > range?
> >
> > 4) Or is the answer that I should not unload drivers for fixed
> > hardware?
>
> 5) On kldunload, the resources shouldn't be freed. Only when then
> child actually goes away should they be freed. I think this is the
> heart of the bug. Once this is fixed, all the down stream badness
> should go away.
Isn't that the same as 1) or 2)? The driver just calls
bus_release_resource(), regardless of whether the hardware or the
driver goes away. In the first case, the resource should be
deallocated. In the second case, the resource should only be handed
to the parent driver, without deallocation.
Cardbus devices usually have the complete opposite situation - the
hardware goes away, but the driver stays. But what happens with the
memory resources in the cardbus case if the driver is unloaded with
the card in place? And if the memory resource is not deallocated
then, who deallocates when the hardware also goes away?
Maybe -stable is a better list for this topic?
Should I file a PR?
Bengt
More information about the freebsd-mobile
mailing list