[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: [patch #4818] Dynamic memory allocation for Linux Device drivers in glue.
Date: Tue, 9 May 2006 19:35:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20060502 Ubuntu/dapper Firefox/

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:

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:
vm_page_grab_contiguous_pages_queue(DMA queue) returns 6, which is
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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]