Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/QNX 7.0 invalid behavior of mmap_device_memory/List of Posts
Forum Topic - QNX 7.0 invalid behavior of mmap_device_memory: (19 Items)
   
Update
Armin Steinhoff
02/05/2021 12:10 PM
post121225
QNX 7.0 invalid behavior of mmap_device_memory   
The call mmap_device_memory returns NULL !

   if (ba[1].addr == pci_asType_e_MEM)
    {
           BAR[1]= mmap_device_memory( 0, 0x40000, PROT_READ|PROT_WRITE|PROT_NOCACHE, MAP_PHYS  | MAP_SHARED,  ba[1].
addr );
	   if ( BAR[1] == MAP_FAILED ) 
	   {
		perror( "mmap_device_memory for physical address 0x40000 failed" );
		exit( EXIT_FAILURE );
	  }
     }
     else return(EXIT_FAILURE);

The PCI config space has been correctly read: It schows all data  as shown by the pci-tool!!

Whats the reason for that invalid behavior of mmap_device_memory??

Best Regards
Armin
Elad Lahav
02/05/2021 12:22 PM
post121226
Re: QNX 7.0 invalid behavior of mmap_device_memory   
The only case mmap() returns NULL is with MAP_FIXED, which is not the case here.
What architecture are on? 32-bit or 64-bit?

By the way, mmap_device_memory() is a trivial wrapper around mmap(). There is really no reason to use it (but that has 
nothing to do with this issue).

--Elad
Armin Steinhoff
02/05/2021 5:49 PM
post121228
Re: QNX 7.0 invalid behavior of mmap_device_memory   
Hi,
I used at first mmap and it returns also a NULL Pointer!

Armin
Armin Steinhoff
02/05/2021 6:04 PM
post121230
Re: QNX 7.0 invalid behavior of mmap_device_memory   
            resp = pci_device_map_as(hdl, &ba[1], &xlate);
            if (resp == PCI_ERR_OK)
            {
                BAR[1] = (unsigned char *) mmap64(0, 0x40000, PROT_NOCACHE | PROT_READ | PROT_WRITE, MAP_PHYS | 
MAP_SHARED, NOFD, xlate.addr );
            }
            else return(resp);

            mmap64 returns also a NULL pointer, mapping a smaller size (4096) works for an other driver! 0x40000 ->  ~
250kB physical memory

            Armin
Lichun Zhu
02/05/2021 6:09 PM
post121231
Re: QNX 7.0 invalid behavior of mmap_device_memory   
could you please attach the code here? It's interesting, it is a fundamental piece of code, if this is wrong, I don't 
know how many system can even boot.
Elad Lahav
02/05/2021 6:44 PM
post121232
Re: QNX 7.0 invalid behavior of mmap_device_memory   
Hi Armin,

I didn't receive an answer to the question of which architecture this is on. Also, what is the type of BAR[1]? How do 
you check that mmap() returned NULL, as it doesn't appear in the code.

--Elad
Armin Steinhoff
02/06/2021 5:51 AM
post121237
Re: QNX 7.0 invalid behavior of mmap_device_memory   
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!
Armin Steinhoff
02/06/2021 4:26 AM
post121233
Re: QNX 7.0 invalid behavior of mmap_device_memory   
have a look to my initial posting. It shows 100% of the critical code!
Lichun Zhu
02/05/2021 12:28 PM
post121227
Re: QNX 7.0 invalid behavior of mmap_device_memory   
Is it really return NULL, not MAP_FAILED, the code test MAP_FAILED.
what errno?
Armin Steinhoff
02/05/2021 5:51 PM
post121229
Re: QNX 7.0 invalid behavior of mmap_device_memory   
yes, it returs a NULL pointer and not the error code!

Armin
Armin Steinhoff
02/06/2021 5:12 AM
post121234
Re: QNX 7.0 invalid behavior of mmap_device_memory   
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.
Geoff Roberts
02/06/2021 5:24 AM
post121235
Re: QNX 7.0 invalid behavior of mmap_device_memory   
> 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.
Armin Steinhoff
02/06/2021 5:44 AM
post121236
Re: QNX 7.0 invalid behavior of mmap_device_memory   
I'm using as a test system the generic x86_64 BSP. No changes made

Are there any restrictions in usage of memory?
Geoff Roberts
02/06/2021 5:54 AM
post121238
Re: QNX 7.0 invalid behavior of mmap_device_memory   
> I'm using as a test system the generic x86_64 BSP. No changes made
> 
> Are there any restrictions in usage of memory?  

I'm wondering if there is something else (hardware related?) involved here. I can't remember right now what the 
underlying hardware was that I used (one was a Gigabyte m/board) but like you I used the generic x86_64 BSP.

Like I said I had no problems with either.

Also, the memory I am accessing is not large. As I recall only 128 bytes mapped to an FPGA (also called "dual port 
memory"). Whatever, it all works.

Geoff.
Elad Lahav
02/06/2021 7:04 AM
post121239
Re: QNX 7.0 invalid behavior of mmap_device_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
Geoff Roberts
02/06/2021 8:13 AM
post121240
Re: QNX 7.0 invalid behavior of mmap_device_memory   
[some snipped]

> @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 was grasping! :-)

A lot of this stuff is PFM to me and I'm glad you're dealing with it and I'm not! :-) I just use it...

G.

> I'm more than happy to help you find the problem. Let's keep things friendly ;
> -)
> 
> --Elad
Armin Steinhoff
02/06/2021 10:05 AM
post121241
Re: QNX 7.0 invalid behavior of mmap_device_memory   
Hi Elad,

 mmap_device_memory() and mmap/) are working as expected!
I did a typo and compared a baseregister addr against a baseregister type ... realy stupid.

The resource manager for the fiedlbus called INTERBUS is now working for QNX 7.0

Thanks for your pacience 

Armin
Armin Steinhoff
02/06/2021 10:15 AM
post121242
Re: QNX 7.0 invalid behavior of mmap_device_memory   
BTW. the Interbus adapter is an "old"  PCI 2.1 cardbus adapter :)

Armin
Elad Lahav
02/06/2021 10:17 AM
post121243
Re: QNX 7.0 invalid behavior of mmap_device_memory   
No problem.
I'm glad you found the issue.

--Elad

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems