Re: [Discuss-gnuradio] shmat issue
On 10/25/2010 07:36 PM, Joshua Lackey wrote: Quoting Philip Balister (phi...@balister.org): On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: On 10/19/2010 10:51 PM, Eric Blossom wrote: OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. OK. What's PAGE_SIZE on arm? PAGE_SIZE is still 4096, there is an additional restriction on the address passed to shmat(). Is the additional restriction '4 * PAGE_SIZE'? If so, look in the circular_buffer.cc for kalibrate and change the line that reads: m_pagesize = getpagesize(); to m_pagesize = 4 * getpagesize(); It may be that easy. The rest of the logic should work. Basically, yes. Unfortunately, this didn't work. I'll double check when I get back from ELCE. It seems like the shm code returns an address that is not valid for using as an address you pass to shmat :( Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) I'll check this when I get home. Email me with your results and I'll add some code to make arm work in the next version of kal. Thanks! Could we use the mmap code from gnuradio? That is what ends up being used there I think. I skimmed the shm code while working on this problem, and it looks like it used mmap internally :) Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
Quoting Philip Balister (phi...@balister.org): [...] Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) I'll check this when I get home. Email me with your results and I'll add some code to make arm work in the next version of kal. Thanks! Could we use the mmap code from gnuradio? That is what ends up being used there I think. I skimmed the shm code while working on this problem, and it looks like it used mmap internally :) mmap is the Posix shared memory method. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
Quoting Philip Balister (phi...@balister.org): On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: On 10/19/2010 10:51 PM, Eric Blossom wrote: OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. OK. What's PAGE_SIZE on arm? PAGE_SIZE is still 4096, there is an additional restriction on the address passed to shmat(). Is the additional restriction '4 * PAGE_SIZE'? If so, look in the circular_buffer.cc for kalibrate and change the line that reads: m_pagesize = getpagesize(); to m_pagesize = 4 * getpagesize(); It may be that easy. The rest of the logic should work. Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) Email me with your results and I'll add some code to make arm work in the next version of kal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On 10/19/2010 10:51 PM, Eric Blossom wrote: On Tue, Oct 19, 2010 at 08:34:40PM -0400, Philip Balister wrote: I'm seeing this issue on my omap3 install with the dialtone flowgraph: # python /usr/share/gnuradio/examples/audio/dial_tone.py gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument l# python /usr/share/gnuradio/examples/audio/dial_tone.py From $ man shmat EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and SHM_RND was not speci- fied) or invalid shmaddr value, or can’t attach segment at shmaddr, or SHM_REMAP was specified and shmaddr was NULL. I hate system calls that have one error code for several errors. In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. You should see it only once ever, if the program can write to ~/.gnuradio/prefs. Generally this gets written during make check. Does make check work? Insert whining about make check for the cross compiled case :) Why are you running as root? I am lazy :) It looks like gnuradio falls back to another method of creating the shared segment. Yes it does. I'd like to resolve the shmat issue though, Set a breakpoint with gdb, or add printfs. OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. Philip because I am also trying to run the kalibrate program and have the same shmat issue there, but it does not have a fall back method. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: On 10/19/2010 10:51 PM, Eric Blossom wrote: In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. You should see it only once ever, if the program can write to ~/.gnuradio/prefs. Generally this gets written during make check. Does make check work? Insert whining about make check for the cross compiled case :) Why are you running as root? I am lazy :) And foolish :) It looks like gnuradio falls back to another method of creating the shared segment. Yes it does. I'd like to resolve the shmat issue though, Set a breakpoint with gdb, or add printfs. OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. OK. What's PAGE_SIZE on arm? I wonder how we can determine the actual value of SHMLBA at runtime? We currently use the result of gr_pagesize() as the required alignment value. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On 10/20/2010 01:49 PM, Eric Blossom wrote: On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: On 10/19/2010 10:51 PM, Eric Blossom wrote: OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. OK. What's PAGE_SIZE on arm? PAGE_SIZE is still 4096, there is an additional restriction on the address passed to shmat(). I wonder how we can determine the actual value of SHMLBA at runtime? We currently use the result of gr_pagesize() as the required alignment value. It looks to me like the there are several shm sections created, with varying access rights. Then shmat is used to reserve a chunk of memory. Then the sections created first are attached to with addresses based on the result of the shmat used to get the address space. The weird thing on arm, the shmat returns a page aligned section, but if you pass that address back to shmat it fails, because that address needs to be aligned to SHMLBA (found in arch/arm|x86/include/asm/shmparam.h. What does it mean? Well gnuradio falls back to a mmap approach to get the circular buffer. It is a bigger problem for kalibrate, which just fails. I'm not sure who is to blame :) Is there another way to get reserve the memory on you process to use when you attach the shared memory segments? Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] shmat issue
I'm seeing this issue on my omap3 install with the dialtone flowgraph: # python /usr/share/gnuradio/examples/audio/dial_tone.py gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument l# python /usr/share/gnuradio/examples/audio/dial_tone.py In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. It looks like gnuradio falls back to another method of creating the shared segment. I'd like to resolve the shmat issue though, because I am also trying to run the kalibrate program and have the same shmat issue there, but it does not have a fall back method. Thanks, Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On Tue, Oct 19, 2010 at 08:34:40PM -0400, Philip Balister wrote: I'm seeing this issue on my omap3 install with the dialtone flowgraph: # python /usr/share/gnuradio/examples/audio/dial_tone.py gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument l# python /usr/share/gnuradio/examples/audio/dial_tone.py From $ man shmat EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and SHM_RND was not speci- fied) or invalid shmaddr value, or can’t attach segment at shmaddr, or SHM_REMAP was specified and shmaddr was NULL. In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. You should see it only once ever, if the program can write to ~/.gnuradio/prefs. Generally this gets written during make check. Does make check work? Why are you running as root? It looks like gnuradio falls back to another method of creating the shared segment. Yes it does. I'd like to resolve the shmat issue though, Set a breakpoint with gdb, or add printfs. because I am also trying to run the kalibrate program and have the same shmat issue there, but it does not have a fall back method. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
