I am writing a linux kernel driver for a custom pci device. I am
developing against the stock fedora 6 kernel on an x86. This device has
512 MB of IO memory reserved by BAR 3. Whenever I try to ioremap this
space I get the error:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase
size.
I think I understand why this is happening. I obviously don't have
enough vmalloc space to map such a large chunk of memory. I have been
using Corbet's et el's "Linux Device Drivers", Love's "Linux Kernel
Development", and many websites as a guide in this development process
but have yet to come across information that will help me.
I'm curious if there is a way around this issue. Or a better way of
handling it so that I can properly map the entire io memory space.
Thanks for any help,
Jon
Jon Dufresne wrote:
> I am writing a linux kernel driver for a custom pci device. I am
> developing against the stock fedora 6 kernel on an x86. This device has
> 512 MB of IO memory reserved by BAR 3. Whenever I try to ioremap this
> space I get the error:
>
> allocation failed: out of vmalloc space - use vmalloc=<size> to increase
> size.
>
> I think I understand why this is happening. I obviously don't have
> enough vmalloc space to map such a large chunk of memory. I have been
> using Corbet's et el's "Linux Device Drivers", Love's "Linux Kernel
> Development", and many websites as a guide in this development process
> but have yet to come across information that will help me.
>
> I'm curious if there is a way around this issue. Or a better way of
> handling it so that I can properly map the entire io memory space.
On an i386 kernel you likely just don't have enough address space
available to map something that big. Your kernel address space is only
1GB (with the standard 3G/1G user/kernel split) and it somehow has to
fit in there along with all the other I/O regions, etc. that are mapped
into kernel address space.
You may just have to remap smaller chunks of the BAR on demand and unmap
them when you're finished with them.
An x86_64 kernel likely would not have this problem..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On 12 Jun, 14:30, Jon Dufresne
<[email protected]> wrote:
> I am writing a linux kernel driver for a custom pci device. I am
> developing against the stock fedora 6 kernel on an x86. This device has
> 512 MB of IO memory reserved by BAR 3. Whenever I try to ioremap this
> space I get the error:
>
> allocation failed: out of vmalloc space - use vmalloc=<size> to increase
> size.
>
> I think I understand why this is happening. I obviously don't have
> enough vmalloc space to map such a large chunk of memory. I have been
> using Corbet's et el's "Linux Device Drivers", Love's "Linux Kernel
> Development", and many websites as a guide in this development process
> but have yet to come across information that will help me.
>
> I'm curious if there is a way around this issue. Or a better way of
> handling it so that I can properly map the entire io memory space.
You can boot with kernel parameter vmalloc=384M or so. I have
experienced problems with booting with other values, but YMMV.
Daniel
> Thanks for any help,
> Jon
--
Daniel J Blueman
Daniel J Blueman wrote:
> On 12 Jun, 14:30, Jon Dufresne
> <[email protected]> wrote:
>> I am writing a linux kernel driver for a custom pci device. I am
>> developing against the stock fedora 6 kernel on an x86. This device has
>> 512 MB of IO memory reserved by BAR 3. Whenever I try to ioremap this
>> space I get the error:
You don't have a prayer mapping 512 MB at once on an x86-32 machine.
The kernel only has 1 GB of address space *total*. You either need to
map it in chunks or restrict yourself to 64-bit machines.
>> allocation failed: out of vmalloc space - use vmalloc=<size> to increase
>> size.
>>
>> I think I understand why this is happening. I obviously don't have
>> enough vmalloc space to map such a large chunk of memory. I have been
>> using Corbet's et el's "Linux Device Drivers", Love's "Linux Kernel
>> Development", and many websites as a guide in this development process
>> but have yet to come across information that will help me.
>>
>> I'm curious if there is a way around this issue. Or a better way of
>> handling it so that I can properly map the entire io memory space.
No chance.
> You can boot with kernel parameter vmalloc=384M or so. I have
> experienced problems with booting with other values, but YMMV.
The vmalloc= option conflicts with the booting protocol, so it's
basically a crapshoot if it's going to work or not, at least if you're
using an initrd, which pretty much everyone does hese days.
-hpa
I wasn't completely honest. It is one bar that has 512 MB, however it is
being mapped at 4 128 MB chunks. However, I would like them all mapped
at once through the lifetime of the driver.
Is there still no chance?
Thanks,
Jon
On Tue, 2007-06-12 at 11:08 -0700, H. Peter Anvin wrote:
> Daniel J Blueman wrote:
> > On 12 Jun, 14:30, Jon Dufresne
> > <[email protected]> wrote:
> >> I am writing a linux kernel driver for a custom pci device. I am
> >> developing against the stock fedora 6 kernel on an x86. This device has
> >> 512 MB of IO memory reserved by BAR 3. Whenever I try to ioremap this
> >> space I get the error:
>
> You don't have a prayer mapping 512 MB at once on an x86-32 machine.
> The kernel only has 1 GB of address space *total*. You either need to
> map it in chunks or restrict yourself to 64-bit machines.
>
> >> allocation failed: out of vmalloc space - use vmalloc=<size> to increase
> >> size.
> >>
> >> I think I understand why this is happening. I obviously don't have
> >> enough vmalloc space to map such a large chunk of memory. I have been
> >> using Corbet's et el's "Linux Device Drivers", Love's "Linux Kernel
> >> Development", and many websites as a guide in this development process
> >> but have yet to come across information that will help me.
> >>
> >> I'm curious if there is a way around this issue. Or a better way of
> >> handling it so that I can properly map the entire io memory space.
>
> No chance.
>
> > You can boot with kernel parameter vmalloc=384M or so. I have
> > experienced problems with booting with other values, but YMMV.
>
> The vmalloc= option conflicts with the booting protocol, so it's
> basically a crapshoot if it's going to work or not, at least if you're
> using an initrd, which pretty much everyone does hese days.
>
> -hpa
Jon Dufresne wrote:
> I wasn't completely honest. It is one bar that has 512 MB, however it is
> being mapped at 4 128 MB chunks. However, I would like them all mapped
> at once through the lifetime of the driver.
>
> Is there still no chance?
128 MB is still definitely on the heavy side. Try 64 MB and you might
be able to get away with it.
-hpa
Ok, thanks for the help.
Now do I actually need to have the memory mapped in kernel space through
ioremap(), in order to have the memory mapped into user space through
remap_pfn_range()? It seems that remap_pfn_range() only requires a
physical address, not a virtual one.
If this is true then I really don't need to map this in kernel space at
all and only in user space, since it will only be manipulated in user
space.
Thanks,
Jon
On Tue, 2007-06-12 at 13:22 -0700, H. Peter Anvin wrote:
> Jon Dufresne wrote:
> > I wasn't completely honest. It is one bar that has 512 MB, however it is
> > being mapped at 4 128 MB chunks. However, I would like them all mapped
> > at once through the lifetime of the driver.
> >
> > Is there still no chance?
>
> 128 MB is still definitely on the heavy side. Try 64 MB and you might
> be able to get away with it.
>
> -hpa
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/