The correct fix would be fixing those drivers to allocate memory for DMA
from the "below4G" pool. It can be done like this:

Dma_fd = posix_typed_mem_open("sysram&below4G", oflag, tflag);
dma_mem = mmap(addr, len, prot, flags, dma_fd, off);

Doing it this way results only the DMA buffer is allocated from the
below4G pool, the rest allocation in the driver can still allocate
memory without restrictions. 

Jerry Sui | Software Developer | jsui@qnx.com
O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
Systems
Cisco Support Team email: cisco_support@qnx.com

-----Original Message-----
From: Lewis Donzis [mailto:community-noreply@qnx.com] 
Sent: February 26, 2011 8:27 AM
To: ostech-core_os
Subject: Re: RE: RE: Can't use more than 3.5GB of RAM

> To my knowledge, it is not possible. The kernel checks flag
> SPAWN_PADDR64_SAFE to decide where to allocate physical memory by
> default when -mP is not enabled. There is no SPAWN_PADDR64_UNSAFE flag
> when -mP is enabled.

I've been doing some more testing with the idea of using
SPAWN_PADDR64_SAFE, and wanted to point out that this is highly
problematic.

The trouble is that from a system perspective, many programs spawn other
programs, and it appears that SPAWN_PADDR64_SAFE does not inherit from
the parent.  Even fixing system() to include the flag on spawn() doesn't
help because it ends up spawning a shell which when spawns the program,
and of course the shell spawns without SPAWN_PADDR64_SAFE.

Because of the nature of the QNX architecture, it seems that every
program is guaranteed to be physaddr-agnostic except for the few drivers
that do DMA, e.g., the disk, network, USB drivers, etc., basically
devx-xxx.  From examining the network drivers, most of the devnp-xxx
ones are already 64-bit physaddr capable, but it appears that devb-eide
may not be.

In retrospect, I think it would have been cleaner to make a
SPAWN_PADDR64_UNSAFE flag (or mark the ELF in some way that the loader
can tell) and load drivers that are not known to be 64-bit physaddr safe
with that flag.  "Everything else," i.e., normal programs, obviously
cannot care about their physaddrs and due to the message passing
architecture, there is never any direct access to their physical memory,
even from drivers.

lew



_______________________________________________

OSTech
http://community.qnx.com/sf/go/post83550

> -----Message d'origine-----
> De : Lewis Donzis [mailto:community-noreply@qnx.com]
> Envoyé : 25 février 2011 14:56
> À : ostech-core_os
> Objet : Re: RE: RE: Can't use more than 3.5GB of RAM
> 
> > A x64 os would make thing (from a user`s perspective) so much nicer
> > ;-) But I know you, the QNX staffer, know ;!
> >
> > If only one car make would be bold enough to label their car 64Bit
> > inside out
> > ;-)
> 
> Yeah, add our vote to having full 64-bit address capability!  That would make
> things so much easier for what we're doing.

Don`t know if that is still true but last I heard, x86 was, for QSSL, at the bottom of the food chain, I`m not expecting
 x64 anytime soon, but would *LOVE* to be showed wrong. I keep a copy of the old QUICS system, just for fun.  In it 
there are strong words coming for senior staff  saying that it would be extremely unlikely QNX would ever be available 
on anything but x86.  Going through the QUICS stuff is quite entertaining !

I know without the -x option of startup-bios we would have probably switch OS by know (some of our system use 24Gig of 
ram...). Multi-core is nice but it increases the need for memory.  We can still deal with the 3.5G per process limit, 
for a while,  but virtual adresses is becoming an issue.

> 
> lew
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post83530
>