summaryrefslogtreecommitdiffstats
path: root/sys/dev
diff options
context:
space:
mode:
authorimp <imp@FreeBSD.org>2005-10-29 05:52:17 +0000
committerimp <imp@FreeBSD.org>2005-10-29 05:52:17 +0000
commita8ba39ce7d43c9ec7fe12eab3f6ab51f81ecc04f (patch)
tree3cac9ba52ed540830e703c0b1bad2d99041a03ef /sys/dev
parente1cda542a5cb7ef1bd5e3a31a89ea45973d58c19 (diff)
downloadFreeBSD-src-a8ba39ce7d43c9ec7fe12eab3f6ab51f81ecc04f.zip
FreeBSD-src-a8ba39ce7d43c9ec7fe12eab3f6ab51f81ecc04f.tar.gz
MFp4: When doing lazy allocation, it turns out that we need to record the
actual resource values we received from the system rather than the range we requested. Since we request a range starting at 0, we would record that number. Later, since this == 0, we'd allocate again. However, we wouldn't write the new resource into the BAR. This resulted in a resource leak as well as a BAR that couldn't access the resource at all since rman_get_start, et al, were wrong. MFC After: 1 week (assuming RELENG_6 is open for business)
Diffstat (limited to 'sys/dev')
-rw-r--r--sys/dev/pci/pci.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 1b3a385..d79b20f 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -1749,6 +1749,9 @@ pci_alloc_map(device_t dev, device_t child, int type, int *rid,
if (rle == NULL)
panic("pci_alloc_map: unexpectedly can't find resource.");
rle->res = res;
+ rle->start = rman_get_start(res);
+ rle->end = rman_get_end(res);
+ rle->count = count;
if (bootverbose)
device_printf(child,
"Lazy allocation of %#lx bytes rid %#x type %d at %#lx\n",
OpenPOWER on IntegriCloud