The KM_NOSLEEP is contributing to this, but the path forward from there has pitfalls. Under the KM_NOSLEEP option the kernel is not allowed to shuffle the page table because that would require a sleep.
One possibility is to try what you are doing fresh after a reboot. It's a kludge, but might work.
Your call is similar to the lis_alloc_atomic() function. You could try using lis_alloc_kernel() as a substitute. However, depending upon the context of the call you could run into trouble in LiS-2.16.x. The problem is that the kernel may need to sleep to fiddle with the page table to satisfy your request, and in LiS-2.16.x you will be implicitly holding a spin lock when you make that call. This could lead to trouble.
If you use LiS-2.17.x (numbered, not lettered, version) that same context will be holding a semaphore instead of a spin lock and you will be safe to use lis_alloc_kernel(). You will need to recompile your driver in the context of LiS-2.17 headers if you want to try this.
Maybe someone else has a more elegant idea.
-- Dave
At 07:09 PM 5/3/2004, Gurol Akman wrote:
kmem_zalloc(size, KM_NOSLEEP) call from within my driver fails under LiS-2.16.18 and the following info gets printed:
__alloc_pages: 8-order allocation failed (gfp=0x20/0)
lis_get_free_pages: called from .... #...: nbytes=631396 order=8 total=1048576 allocation failed
when i check on /proc/meminfo, i see the following:
MemFree: 20752 kB
which suggests that there is sufficient memory on the system.
what may be causing the kmem_zalloc failure? could KM_NOSLEEP be the cause?
thanks & regards -- GA
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004
