On 22-11-07 17:08, Rene Herman 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.
Oh and I should add that passing the vmalloc command line option is ofcourse
basically the same as increasing VMALLOC_RESERVE at compile time, so instead
of doing that, you might as well keep passing it. The PAGE_OFFSET tweaks are
the meat of the reply though.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
