From: Jeff Hartmann <jhartmann@valinux.com>
To: Christophe Beaumont <christophe@paracel.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: HUGE contiguous mem space with 2.4
Date: Wed, 23 May 2001 14:46:35 -0600 [thread overview]
Message-ID: <3B0C21AB.1000800@valinux.com> (raw)
In-Reply-To: <NFBBINOGHMOOBMPNBAHKMEFLCAAA.christophe@paracel.com>
Christophe Beaumont wrote:
> Hi...
>
> I am facing an odd problem here. I have an application here
> that requires a HUGE physically contiguous memory area to
> be locked (yes, I have hardware DMA'ing in and out of that
> area, over the PCI bus). HUGE being like one Gig (could be
> more if needed...)
> I am trying to use the mem=1024M option at boot time (yes,
> the box has 2 Gigs of RAM) and then ioremap() from within
> my module. There I have a couple of issues:
> - if I use high_memory as is, I cannot remap any area
> (high_memory=f800:0000 ???)
> - if I use high_memory thru virt_to_phys, I can then remap...
> up to 64 Megs (maybe a little more, but for sure less than
> 128 Megs) (virt_to_phys(high_mem)=3800:0000)
>
> I tried with other values (like mem=250M 512M 1536M) and could
> NOT remap anything close to the whole amount of "reserved" memory
> (best case being with mem=256M I can remap 512M out of 1.75Gigs)
>
You are running out of virtual address space in the kernel. Either
don't map the whole thing all the time (this is really the best solution
since it works with stock kernels), or hack up your kernel to have more
virtual address space reserved for the kernel. This will have the side
effect of reducing the amount of memory an application can use at one time.
Another solution is to have the driver in user space, were you should be
able to mmap a much larger amount of device memory. If your application
requires no interrupt handling, and can always be run as root, you could
probably get away with no kernel support at all. Just use /dev/mem to
mmap the device and your dma memory.
-Jeff
prev parent reply other threads:[~2001-05-23 20:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-21 22:39 HUGE contiguous mem space with 2.4 Christophe Beaumont
2001-05-23 20:46 ` Jeff Hartmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B0C21AB.1000800@valinux.com \
--to=jhartmann@valinux.com \
--cc=christophe@paracel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox