On 22-11-07 13:41, Sumudu Nishantha wrote:
I am new to this group as well as to the driver development.
I am developing a PCI driver with the following specification.
CPU : Intel celeron M 1.4GHz
memory : 1GB
kernel : kernel 2.6.15-r1
swap : 4GB
my driver works well with 512M RAM but it gives an error when I
use 1GB of RAM. Error occurs at ioremap() function.
*ptr = ioremap(base,length)
length here is 128MB
The error asks to increase kernel memory space with vmalloc.
Then I gave vmalloc as a kernel parameter (vmalloc=256M)
in grub.conf. it went well in this way.
Is this the way to overcome this problem or is it due to some other
problems?(old kernel etc.)
I can't update the kernel since the driver is being developed for a
customer specific machine which is already used.
Basically, the best way to overcome it is start using a 64-bit architecture
but I suppose that's not much of an option either then...
128M is quite a bit, and indeed too much for an untweaked kernel. See, the
4GB 32-bit address-space is shared between user- and kernel-space, and in
the default arrangement, user-space gets the lower 3GB and kernel-space the
top 1GB.
Inside that latter 1G, the kernel first directly maps physical memory and
uses the remaining address-space between 3G+PHYS_MEM and 4G for vmalloc,
ioremap and a few other specialized uses. So, with 512M of physical memory,
the kernel has 512M of address-space left between 3.5G and 4G for
vmalloc/ioremap purposes and everything works out fine with your 128M claim
on it.
However, with 1GB of physical memory you see that isn't going to work. In
fact, you see that without any other special arrangements there would not be
_any_ address-space left for ioremap and that ofcourse won't do.
The kernel therefore reserves some amount of address-space, VMALLOC_RESERVE,
for vmalloc/ioremap and limits the amount of permanently mapped memory (so
called "lowmem") to 1G-VMALLOC_RESERVE and treats the rest as "highmem"
which is mapped and unmapped as needed. And see, VMALLOC_RESERVE by default
is 128M meaning your one 128M claim is just a little too big -- the area is
needed by a few other uses as well as said.
There are a couple of possible solutions. You can first simply increase
VMALLOC_RESERVE (to 256M, say) and recompile the kernel. You then
automatically also increase the percentage of memory that is used as highmem
and whether or not that's important is specific to your use. Highmem is a
little slower at least and using highmem might require you to look at local
code that might not be prepared to deal with non-permanently mapped memory
at all (you need highmem to have all of the 1G visible now as well, but
perhaps you hadn't noticed yet).
The second solution is adjusting the VM split down somewhat, from 3G/1G for
user/kernel to say 2.75G/1.25G. You'd then not need highmem and still have
256M left for vmalloc/ioremap.
And in fact, in current kernels, that very split is selectable through the
kernel config to allow people with 1G to use all of their memory without
having to deal with highmem. If I remember correctly, in 2.6.15 you (only)
need to adjust the two PAGE_OFFSET defines in include/asm/page.h (one for
C, one for assembly) from 0xc0000000 to 0xb0000000 and recompile.
Note that given the config choice in later kernels, this should be fairly
well tested on those later kernels at least but that you might still get
into trouble if your use involves running things such as VMWARE that aren't
prepared to deal with the non-standard split. If it breaks, you get to keep
the pieces...
So VMALLOC_RESERVE++ or PAGE_OFFSET-- or/and best of all, make sure everyone
knows 32-bit architectures stopped being a good idea once physical memory
went over 768M or so.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
