Assuming we are using Thomas' patch that already removed the vm_page_wire()
from the earlier for loop, then at the point of this VM space allocation
failure, we haven't done anything too serious to the vm_page nor to the pmap,
nor are they in any object. We should be able to simply place it back
:
:I have a potentially silly question about contigmalloc1(), if the very
:unlikely occurance that the kernel VM space ran out, (the vm_map_findspace()
:failed) wouldn't we want to return the chunk of contiguous physical space
:back on the free queue before we return an allocation failure?
:
:--m
I have a potentially silly question about contigmalloc1(), if the very
unlikely occurance that the kernel VM space ran out, (the vm_map_findspace()
failed) wouldn't we want to return the chunk of contiguous physical space
back on the free queue before we return an allocation failure?
--mark tingu
:I have also looked into this a while ago, but got stuck at some
:point. I have just looked at it again, and I think I have found a solution.
:
:...
:
:This is probably because the map entries do have a NULL object
:pointer. vm_map_pageable() calls vm_fault_wire(), so this will fail.
:
:I have at
On Fri, 2001/10/12 at 10:07:10 -0700, Matt Dillon wrote:
>
> :Mark,
> :
> :> I also placed some checks on vm_map_delete
> :
> :I did that also, and as far as I understand everything works fine.
> :The only thing I found was the fact that when contigmalloc() grabs the
> :contig pages it sets the v
apologies, as soon as I sent that mail, I realized that I was looking
at the virtual address -- duh, mark.
Patrick was pointed in the right direction that the entry's object is
no longer the kernel_map but is NULL, changing the release path.
--mark tinguely
To Unsubscribe: send mail to [EMAIL
I can allocate the same memory block, back to back by contigmailloc and
contigfree using the same if_xl structures in a PCI probe (actually
I do contigmalloc/contigfree per probe call. The PCI probe
gets called for each PCI device.
I will print up the trace that shows the blocks are freed.
I th
:Mark,
:
:> I also placed some checks on vm_map_delete
:
:I did that also, and as far as I understand everything works fine.
:The only thing I found was the fact that when contigmalloc() grabs the
:contig pages it sets the value of pga[i] (for i in allocated pages)
:note that: vm_page_t pga = vm_
Mark,
> I also placed some checks on vm_map_delete
I did that also, and as far as I understand everything works fine.
The only thing I found was the fact that when contigmalloc() grabs the
contig pages it sets the value of pga[i] (for i in allocated pages)
note that: vm_page_t pga = vm_page_arra
Patrick Cipiere <[EMAIL PROTECTED]> says:
>
> :We are currently working with FreeBSD 4.3 and we found out that
> :kldloading/kldunloading modules working with contigmalloc()/contigfree()
> :like if_xl.ko produces a memory leak.
> :
> :This is due to the contigfree() function which seems to un
:We are currently working with FreeBSD 4.3 and we found out that
:kldloading/kldunloading modules working with contigmalloc()/contigfree()
:like if_xl.ko produces a memory leak.
:
:This is due to the contigfree() function which seems to uncompletely release
:the memory ressource allocated in vm_pa
We are currently working with FreeBSD 4.3 and we found out that
kldloading/kldunloading modules working with contigmalloc()/contigfree()
like if_xl.ko produces a memory leak.
This is due to the contigfree() function which seems to uncompletely release
the memory ressource allocated in vm_page_arr
12 matches
Mail list logo
