Update of patch #4818 (project hurd):
Status: In Progress => Postponed
_______________________________________________________
Follow-up Comment #3:
This patch fails to work together with Samuel's patch #7118 which is now
applied to the gnumach-1-branch:
http://lists.gnu.org/archive/html/commit-hurd/2006-05/msg00000.html
The problem occurs with RAM configurations somewhere above 970 MiB. It can
be reproduced in QEMU.
In linux/dev/init/main.c, linux_init(), `__get_free_pages (GFP_ATOMIC,
CONTIG_ALLOC_ORDER, 1)' fails to allocate DMAable memory.
The following backtrace was gathered with printf() debugging:
__get_free_pages(DMAable)
vm_page_grab_contiguous_pages_flags(VM_PAGE_DMA)
vm_page_grab_contiguous_pages_queue(DMA queue) returns 6, which is
`KERN_RESOURCE_SHORTAGE'.
In there, in the ``First loop. Scan the bit array for NPAGES contiguous
bits'' loop, after ``Bitscan this one word'', `if (v)' is never true, as soon
as the machine's memory configuration is somewhere above 970 MiB, so we fall
through to returning KERN_RESOURCE_SHORTAGE. I did further printf()
debugging, tryinto to track this down, but have so far not been able to
interpret my findings in a way to specify the problem. Perhaps all DMAable
is used up for not DMA related things?
Another tiny issue: the only time that vm_page_dma_last is set to
`16*1024*1024' (16 MiB) is when phys_last_addr is exactly `16*1024*1024'. If
it is larger, vm_page_dma_last is set to `16*1024*1024 - 1'. Is this
intended?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/patch/?func=detailitem&item_id=4818>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
