Re: [Discuss-gnuradio] Windows Port Error - Some Success!

[Martin Dvh]

Robert Roberts wrote:
> Hello!
> 
> 
> 
> The new build works well on the Pentium system I have GNURadio is up 
> and running with the USRP. I now see what was meant with samples being 
> dropped for the USRP. Has anyone made any progress on remeding this?
> 
> 
> For the Opteron System GNURadio still has issues.    Running an 
> example still get the following error.
> 
> 
> C:\gnuradio-examples-0.4\python\audio>mono_tone.py
> gr_vmcircbuf_mmap_createfilemapping: non contiguous mmap - 012D0000 
> 00000000 00040000 01310000
> gr_vmcircbuf_mmap_createfilemapping: non contiguous mmap - 012D0000 
> 00000000 00040000 01310000
> gr_vmcircbuf_sysv_shm: sysv shared memory is not available
> gr_vmcircbuf_mmap_shm_open: mmap or shm_open is not available
> gr_vmcircbuf_mmap_tmpfile: mmap or mkstemp is not available
> gr_vmcircbuf_sysconfig: unable to find a working factory!
> 
> 
> If I run the test program I see:
> 
> C:\Python24\Lib\site-packages\gnuradio\gr>test_vmcircbuf.exe
> Testing gr_vmcircbuf_createfilemapping_factory...
> ....... gr_vmcircbuf_createfilemapping_factory: OK
> Testing gr_vmcircbuf_sysv_shm_factory...
> gr_vmcircbuf_sysv_shm: sysv shared memory is not available
> ....... gr_vmcircbuf_sysv_shm_factory: Doesn't work
> Testing gr_vmcircbuf_mmap_shm_open_factory...
> gr_vmcircbuf_mmap_shm_open: mmap or shm_open is not available
> ....... gr_vmcircbuf_mmap_shm_open_factory: Doesn't work
> Testing gr_vmcircbuf_mmap_tmpfile_factory...
> gr_vmcircbuf_mmap_tmpfile: mmap or mkstemp is not available
> ....... gr_vmcircbuf_mmap_tmpfile_factory: Doesn't work
> test_vmcircbuf: OK.  We've got at least one workable solution
> 
> It says there is one workable solution. How should I go about 
> exploiting this?
I don't know yet, but we will probably figure it out.
The testing code does a limited set of tests, which all seem to succeed.
It tests for the following:

(granualarity is normally 64 kB if I remember well on windows, it might be 
different for an opteron)

  ok &= test_a_bunch (f,   1,   1 * granularity, &start,  v);   //   1 test of  
x   granularity KB

  if (ok){
    ok &= test_a_bunch (f,  64,   4 * granularity, &start, v);  // 64 tests of 
4 x  granularity KB
    ok &= test_a_bunch (f,  32,   4 * (1L << 20),  &start, v);  //  32 tests of 
 4MB
    ok &= test_a_bunch (f, 256, 256 * (1L << 10),  &start, v);  // 256 tests of 
x 256KB    This succeedes
  }

The actual code uses 256 KB  (third number in the error is the hexadecimal 
size: non contiguous mmap - 012D0000  00000000 00040000 01310000)
This has succeeded in the last test of the test_vmcircbuf code so I am lost to 
why this failes now.
The zero in the error tells me that the whole following code failes:
    // NOTE: d_second_copy will be NULL if MapViewFileEx() fails to allocate the
    //       requested address space
    d_second_copy =  MapViewOfFileEx((HANDLE)d_handle,   // handle to map object
                                     FILE_MAP_WRITE,     // read/write 
permission
                                     0,
                                     0,
                                     size,
                                     (char *)d_first_copy + size);//(LPVOID) 
((char *)d_first_copy + size));


The one thing I can come up with is that d_handle is already in use.
This should be prevented by the following code:
  static int s_seg_counter = 0;

  char    seg_name[1024];
  snprintf (seg_name, sizeof (seg_name), "/gnuradio-%d-%d", getpid (), 
s_seg_counter);

  d_handle = CreateFileMapping(INVALID_HANDLE_VALUE,    // use paging file
                               NULL,                    // default security
                               PAGE_READWRITE,          // read/write access
                               0,                       // max. object size
                               size,                    // buffer size
                               seg_name);               // name of mapping 
object

  s_seg_counter++;


Note that s_seg_counter is a static int.
So it should increase with every invocation of gr_vmcircbuf_createfilemapping()
This is only true for a single-treaded case but as far as I know this IS 
singlethreaded.
The same trick is used in for example gr_vmcircbuf_mmap_shm_open()

Could other people with an athlon64/opteron please try the windows-installer 
and see if they get the same results.

Greetings,
Martin
> 
> 
> 
> 
> Thanks!
> ~Chris~
> 
> ----- Original Message -----
> From: Martin Dvh <address@hidden>
> Date: Tuesday, January 24, 2006 10:03 pm
> Subject: Re: [Discuss-gnuradio] Windows Port Error
> 
>>Robert Roberts wrote:
>>
>>>I installed the newest version onto the Pentium D which 
>>
>>previously had
>>
>>>nothing on the system, so no old files existed.  I will do the same
>>>shortly for the original system.
>>
>>I was getting the same error myself (using the binary installer or 
>>just a plain make install from the msys/mingw prompt)
>>And I have been very thorough in removing everything usrp and 
>>gnuradio related.
>>
>>I have tried all kinds of things but I didn't got it to work with 
>>the gnuradio-2.6 sourcetree
>>The good news is that I did get it to work with the current cvs 
>>sourcetree.I rebuilt everything from currentcvs, patched a few 
>>things and now on my machine it is working again.
>>
>>Please try again with this new installer.
>>(please uninstall the old versions first)
>>
>>http://www.olifantasia.com/pub/projects/gnuradio/mdvh/mingw/binary-
>>installer/gnuradio-with-usrp/
>>setup-gnuradio-complete-2.6cvs.exe
>>
>>Greetings,
>>Martin
>>
>>
> 
>