DragonFly commits List (threaded) for 2007-08
cvs commit: src/sys/dev/pccard/pccbb Makefile pccbb_pci.c
sephe 2007/08/14 07:58:44 PDT
DragonFly src repository
sys/dev/pccard/pccbb Makefile pccbb_pci.c
If PCI_MAP_FIXUP is defined, we can no longer do the reallocation magic;
at least it breaks following case:
1) BIOS does not assign cbb IO memory.
2) ipw and cbb are on the same PCI bus.
3) If ipw was loaded, it would use 0xd0000000-0xd0000fff as its IO memory.
4) ipw was not loaded at boot time.
5) At boot time, cbb tried to attach, system assigned IO memory 0xd0000000
-0xd0000fff to it. But later on, due to incorrect IRQ assignment, cbb
attaching failed. The assigned IO memory was freed properly. However,
the resource list entry (rle) was not freed.
6) ipw was loaded after booting and successfully attached. It occupied IO
7) Since ipw and cbb are on the same PCI bus, cbb got a second chance re-
probe and re-attach. But this time, no rle would be allocated by PCI bus
code, since old rle was still there. Old rle had 0xd0000000-0xd0000fff
as start/end, so this allocation failed -- same IO memory segment was
already used by ipw.
8) The reallocation magic was performed then. It succeeded, but this left
cbb's rle in an uninitalized state.
As pointed out in 5), cbb attaching failed again. Reallocated IO memory
was going to be freed: assertion in pci_release_resource(), since cbb's rle
was not initialized in 8).
If PCI_MAP_FIXIP is not defined, we depend on the current mechanism to find
the PCI IO memory for cbb, given some goofy BIOSes do not assign cbb's IO
memory. This seems to be the only way to make things working without
PCI_MAP_FIXUP, though it is vulnerable to the case described above.
Reported-by: Michael Neumann <email@example.com>
Revision Changes Path
1.3 +8 -2 src/sys/dev/pccard/pccbb/Makefile
1.2 +7 -0 src/sys/dev/pccard/pccbb/pccbb_pci.c