[patch #4818] Dynamic memory allocation for Linux Device drivers in glue.

[Thomas Schwinge]

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/