Elad,

what is the best way to increase the initial heap size of the prozess manager in an generic x86_64 buildfile??

My suspicion is that the size of the initial heap - managed by the prozess manager - is too small!

> System:: X68_64, Intel CPU, 
> 
> definition of BAR ->  void * BAR[6]  ... it' just a typless pointer array
> 
> And please ....  avoid killing arguements against this problem. There is a 
> failure.!
> 
> The same code for mapping of 4096 byte is working already since more than 1 
> year at customer sites.

Hi Armin,

Sorry. I use this function with the RocketPort x86_64 driver under 7.04 driver and it works fine for me using the 
address from the PCI (IRQ's from the PCI is a different story! :_) )

I have yet to build this driver on 7.1 (hoping to soon)

There must be some simple explanation for what you are describing.

Can you please provide a simple snippet of code that can be used to verify this behaviour you are experiencing?

I would be very concerned if there is something lurking in this and especially if it were to happen on the ARM platforms
.

Feel free to email directly if you want.

Cheers,

Geoff.

I'm using as a test system the generic x86_64 BSP. No changes made

Are there any restrictions in usage of memory?  

Nobody is trying to kill anything here. We are asking questions so that we can help.
The initial code snippet does not provide all of the information, as it does not show the type of BAR[1] and it doesn't 
show where you determine that BAR[1] is NULL. Lichun and I thought that perhaps you are truncating a 64-bit virtual 
address to a 32-bit value.

I have been working with (and on) this memory manager for the past 8 years and I can assure you that it doesn't return a
 virtual address of 0 unless you specify MAP_FIXED. The code very clearly restricts user addresses to 4K-512GB. As 
Lichun pointed out, if mmap() were ever to return NULL then many things would not work.

mmap() has nothing to do with the heap, either of your user process or of the process manager.

Just to be absolutely sure, can you add some debugging to the code immediately after mmap() returns that prints the 
virtual address as a 64-bit pointer?

@Geoff - this cannot have anything to do with the hardware. No matter what the hardware does, the selection of a virtual
 address is purely a software mechanism. The memory manager just finds a hole in the virtual address space of the 
appropriate size and uses it. Any failure of mmap(), for whatever reason, should result in the function returning 
MAP_FAILED.

I'm more than happy to help you find the problem. Let's keep things friendly ;-)

--Elad