Re: [USRP-users] gcc5 Error when Rebuilding File System
Internal compiler error says you are running out of memory in most cases. Try
increasing the amount of memory available to the container.
Philip
On July 27, 2017 10:35:53 PM EDT, Alexander Olihovik
wrote:
>Thanks Marcus and Philip. I followed Philip's guide and got much
>further
>with the build than before, but I'm still encountering an error when
>running 'bitbake gnuradio-dev-image' (and for reference, I'm sticking
>with
>running 'export MACHINE="ettus-e3xx-sg1"' as in the previous guide).
>The
>error is as follows:
>| {standard input}: Assembler messages:
>| {standard input}:381928: Warning: end of file not at end of a line;
>newline inserted
>| {standard input}:382724: Error: invalid operands (*UND* and *UND*
>sections) for `-'
>| arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program
>cc1plus)
>| Please submit a full bug report,
>| with preprocessed source if appropriate.
>| See for instructions.
>| swig/CMakeFiles/_mapper_swig.dir/build.make:71: recipe for target
>'swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o' failed
>| make[2]: ***
>[swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o] Error 4
>| make[2]: Leaving directory
>'/home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>| CMakeFiles/Makefile2:201: recipe for target
>'swig/CMakeFiles/_mapper_swig.dir/all' failed
>| make[1]: *** [swig/CMakeFiles/_mapper_swig.dir/all] Error 2
>| make[1]: Leaving directory
>'/home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>| Makefile:141: recipe for target 'all' failed
>| make: *** [all] Error 2
>| WARNING:
>/home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/temp/run.do_compile.63492:1
>exit 1 from
>| exit 1
>| ERROR: oe_runmake failed
>| ERROR: Function failed: do_compile (log file is located at
>/home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/temp/log.do_compile.63492)
>ERROR: Task 2138
>(/home/build/oe-repo/oe-core/../meta-sdr/recipes-support/gr-mapper/
>gr-mapper_git.bb, do_compile) failed with exit code '1'
>NOTE: Tasks Summary: Attempted 5439 tasks of which 5405 didn't need to
>be
>rerun and 1 failed.
>Waiting for 0 running tasks to finish:
>Summary: 1 task failed:
> /home/build/oe-repo/oe-core/../meta-sdr/recipes-support/gr-mapper/
>gr-mapper_git.bb, do_compile
>Summary: There were 2 ERROR messages shown, returning a non-zero exit
>code.
>
>Any ideas on where to go from here?
>
>On Thu, Jul 27, 2017 at 3:36 AM, Philip Balister
>wrote:
>
>> On 07/26/2017 10:05 AM, Marcus Müller via USRP-users wrote:
>> > Dear Alexander,
>> >
>> > ah, thanks for the error report!
>> >
>> > Philip has a nice page on how he circumvents such problems:
>> >
>> > http://www.opensdr.com/posts/using-docker-for-openembedded-builds/
>> >
>> > Basically, he uses a docker container to have a controlled version
>of
>> > his OS, and does the build within. Only thing missing (from top of
>my
>> > head) is that it's possibly a good idea to add a
>> >
>> > RUN git config --set --global user.name "Alexander Olihovik"
>> > RUN git config --set --global user.email "yourm...@virginia.edu"
>> >
>> > so that `repo init` can get right to work.
>>
>> Added to my todo list. I just did these by hand to make it work.
>>
>> Philip
>>
>> >
>> > Best regards,
>> >
>> > Marcus
>> >
>> >
>> > On 26.07.2017 17:11, Alexander Olihovik via USRP-users wrote:
>> >> I've been following the guide for rebuilding the file system at
>> >> https://files.ettus.com/manual/page_usrp_e3x0.html
>> >> .
>> >> When I try to build an image with 'bitbake gnuradio-dev-image', I
>get
>> >> the following error:
>> >> ERROR: Function failed: do_compile (log file is located at
>> >> /home/user/Projects/E310/e300-oe-build/build/tmp-glibc/work/
>> ettus_e3xx_sg1-oe-linux-gnueabi/lttng-modules/2.6.1-
>> r0/temp/log.do_compile.63483)
>> >> After checking the log, I see it's a problem with the kernel
>> >> configuration, and the log recommends running 'make oldconfig &&
>make
>> >> prepare' on kernel src to fix it, which when run yields the
>following
>> >> error: fatal error: linux/compiler-gcc5.h: No such file or
>directory
>> >> I've checked my gcc version (5.4.0), but I've found that gcc5.h
>isn't
>> >> in kernel-source/include/linux. Has anyone encountered this issue
>> before?
>> >>
>> >> I've tried adding in a version of compiler-gcc5.h and this
>particular
>> >> test passes, but I'm now left with a more cryptic error message
>when
>> >> trying to build the image again:
>> >> ERROR: Task 1981
>> >> (/home/user/Projects/E310/e300-oe-build/oe-core/../meta-
>> sdr/recipes-support/gr-mapper/gr-mapper_git.bb
>> >> , do_compile) failed with exit code '1'
Re: [USRP-users] gcc5 Error when Rebuilding File System
Success - the image built! One more semi-related question: If I want to add
a new meta-layer to the image, should the version/commit of the new layer
set in default.xml match up with the jethro branch or the master branch? I
presume I'd have to add one of the following to include the meta-webserver
layer:
http://cgit.openembedded.org/meta-openembedded/commit/meta-webserver?h=jethro
http://cgit.openembedded.org/meta-openembedded/commit/meta-webserver
On Fri, Jul 28, 2017 at 4:44 AM, Philip Balister
wrote:
> Internal compiler error says you are running out of memory in most cases.
> Try increasing the amount of memory available to the container.
>
> Philip
>
>
> On July 27, 2017 10:35:53 PM EDT, Alexander Olihovik
> wrote:
>>
>> Thanks Marcus and Philip. I followed Philip's guide and got much further
>> with the build than before, but I'm still encountering an error when
>> running 'bitbake gnuradio-dev-image' (and for reference, I'm sticking with
>> running 'export MACHINE="ettus-e3xx-sg1"' as in the previous guide). The
>> error is as follows:
>> | {standard input}: Assembler messages:
>> | {standard input}:381928: Warning: end of file not at end of a line;
>> newline inserted
>> | {standard input}:382724: Error: invalid operands (*UND* and *UND*
>> sections) for `-'
>> | arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program
>> cc1plus)
>> | Please submit a full bug report,
>> | with preprocessed source if appropriate.
>> | See for instructions.
>> | swig/CMakeFiles/_mapper_swig.dir/build.make:71: recipe for target
>> 'swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o' failed
>> | make[2]: ***
>> [swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o]
>> Error 4
>> | make[2]: Leaving directory '/home/build/oe-repo/build/
>> tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-
>> mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>> | CMakeFiles/Makefile2:201: recipe for target
>> 'swig/CMakeFiles/_mapper_swig.dir/all' failed
>> | make[1]: *** [swig/CMakeFiles/_mapper_swig.dir/all] Error 2
>> | make[1]: Leaving directory '/home/build/oe-repo/build/
>> tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-
>> mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>> | Makefile:141: recipe for target 'all' failed
>> | make: *** [all] Error 2
>> | WARNING: /home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-
>> oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/temp/run.do_compile.63492:1
>> exit 1 from
>> | exit 1
>> | ERROR: oe_runmake failed
>> | ERROR: Function failed: do_compile (log file is located at
>> /home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-
>> oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/
>> temp/log.do_compile.63492)
>> ERROR: Task 2138 (/home/build/oe-repo/oe-core/.
>> ./meta-sdr/recipes-support/gr-mapper/gr-mapper_git.bb, do_compile)
>> failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 5439 tasks of which 5405 didn't need to be
>> rerun and 1 failed.
>> Waiting for 0 running tasks to finish:
>> Summary: 1 task failed:
>> /home/build/oe-repo/oe-core/../meta-sdr/recipes-support/gr-mapper/
>> gr-mapper_git.bb, do_compile
>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>> code.
>>
>> Any ideas on where to go from here?
>>
>> On Thu, Jul 27, 2017 at 3:36 AM, Philip Balister
>> wrote:
>>
>>> On 07/26/2017 10:05 AM, Marcus Müller via USRP-users wrote:
>>> > Dear Alexander,
>>> >
>>> > ah, thanks for the error report!
>>> >
>>> > Philip has a nice page on how he circumvents such problems:
>>> >
>>> > http://www.opensdr.com/posts/using-docker-for-openembedded-builds/
>>> >
>>> > Basically, he uses a docker container to have a controlled version of
>>> > his OS, and does the build within. Only thing missing (from top of my
>>> > head) is that it's possibly a good idea to add a
>>> >
>>> > RUN git config --set --global user.name "Alexander Olihovik"
>>> > RUN git config --set --global user.email "yourm...@virginia.edu"
>>> >
>>> > so that `repo init` can get right to work.
>>>
>>> Added to my todo list. I just did these by hand to make it work.
>>>
>>> Philip
>>>
>>> >
>>> > Best regards,
>>> >
>>> > Marcus
>>> >
>>> >
>>> > On 26.07.2017 17:11, Alexander Olihovik via USRP-users wrote:
>>> >> I've been following the guide for rebuilding the file system at
>>> >> https://files.ettus.com/manual/page_usrp_e3x0.html
>>> >> .
>>> >> When I try to build an image with 'bitbake gnuradio-dev-image', I get
>>> >> the following error:
>>> >> ERROR: Function failed: do_compile (log file is located at
>>> >> /home/user/Projects/E310/e300-oe-build/build/tmp-glibc/work/
>>> ettus_e3xx_sg1-oe-linux-gnueabi/lttng-modules/2.6.1-r0/temp/
>>> log.do_compile.63483)
>>> >> After checking the log, I see it's a problem with the kernel
>>> >> configuration, and the log recommends running 'make oldconfig && make
>>> >> prepare' on kernel src to f
Re: [USRP-users] gcc5 Error when Rebuilding File System
On 07/28/2017 11:25 AM, Alexander Olihovik via USRP-users wrote:
> Success - the image built! One more semi-related question: If I want to add
> a new meta-layer to the image, should the version/commit of the new layer
> set in default.xml match up with the jethro branch or the master branch? I
> presume I'd have to add one of the following to include the meta-webserver
> layer:
> http://cgit.openembedded.org/meta-openembedded/commit/meta-webserver?h=jethro
> http://cgit.openembedded.org/meta-openembedded/commit/meta-webserver
If you used the manifest from the article, use jethro.
Philip
>
> On Fri, Jul 28, 2017 at 4:44 AM, Philip Balister
> wrote:
>
>> Internal compiler error says you are running out of memory in most cases.
>> Try increasing the amount of memory available to the container.
>>
>> Philip
>>
>>
>> On July 27, 2017 10:35:53 PM EDT, Alexander Olihovik
>> wrote:
>>>
>>> Thanks Marcus and Philip. I followed Philip's guide and got much further
>>> with the build than before, but I'm still encountering an error when
>>> running 'bitbake gnuradio-dev-image' (and for reference, I'm sticking with
>>> running 'export MACHINE="ettus-e3xx-sg1"' as in the previous guide). The
>>> error is as follows:
>>> | {standard input}: Assembler messages:
>>> | {standard input}:381928: Warning: end of file not at end of a line;
>>> newline inserted
>>> | {standard input}:382724: Error: invalid operands (*UND* and *UND*
>>> sections) for `-'
>>> | arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program
>>> cc1plus)
>>> | Please submit a full bug report,
>>> | with preprocessed source if appropriate.
>>> | See for instructions.
>>> | swig/CMakeFiles/_mapper_swig.dir/build.make:71: recipe for target
>>> 'swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o' failed
>>> | make[2]: ***
>>> [swig/CMakeFiles/_mapper_swig.dir/mapper_swigPYTHON_wrap.cxx.o]
>>> Error 4
>>> | make[2]: Leaving directory '/home/build/oe-repo/build/
>>> tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-
>>> mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>>> | CMakeFiles/Makefile2:201: recipe for target
>>> 'swig/CMakeFiles/_mapper_swig.dir/all' failed
>>> | make[1]: *** [swig/CMakeFiles/_mapper_swig.dir/all] Error 2
>>> | make[1]: Leaving directory '/home/build/oe-repo/build/
>>> tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/gr-
>>> mapper/0.0.4+gitAUTOINC+39ebd61140-r0/build'
>>> | Makefile:141: recipe for target 'all' failed
>>> | make: *** [all] Error 2
>>> | WARNING: /home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-
>>> oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/temp/run.do_compile.63492:1
>>> exit 1 from
>>> | exit 1
>>> | ERROR: oe_runmake failed
>>> | ERROR: Function failed: do_compile (log file is located at
>>> /home/build/oe-repo/build/tmp-glibc/work/armv7ahf-vfp-neon-
>>> oe-linux-gnueabi/gr-mapper/0.0.4+gitAUTOINC+39ebd61140-r0/
>>> temp/log.do_compile.63492)
>>> ERROR: Task 2138 (/home/build/oe-repo/oe-core/.
>>> ./meta-sdr/recipes-support/gr-mapper/gr-mapper_git.bb, do_compile)
>>> failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 5439 tasks of which 5405 didn't need to be
>>> rerun and 1 failed.
>>> Waiting for 0 running tasks to finish:
>>> Summary: 1 task failed:
>>> /home/build/oe-repo/oe-core/../meta-sdr/recipes-support/gr-mapper/
>>> gr-mapper_git.bb, do_compile
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>>> code.
>>>
>>> Any ideas on where to go from here?
>>>
>>> On Thu, Jul 27, 2017 at 3:36 AM, Philip Balister
>>> wrote:
>>>
On 07/26/2017 10:05 AM, Marcus Müller via USRP-users wrote:
> Dear Alexander,
>
> ah, thanks for the error report!
>
> Philip has a nice page on how he circumvents such problems:
>
> http://www.opensdr.com/posts/using-docker-for-openembedded-builds/
>
> Basically, he uses a docker container to have a controlled version of
> his OS, and does the build within. Only thing missing (from top of my
> head) is that it's possibly a good idea to add a
>
> RUN git config --set --global user.name "Alexander Olihovik"
> RUN git config --set --global user.email "yourm...@virginia.edu"
>
> so that `repo init` can get right to work.
Added to my todo list. I just did these by hand to make it work.
Philip
>
> Best regards,
>
> Marcus
>
>
> On 26.07.2017 17:11, Alexander Olihovik via USRP-users wrote:
>> I've been following the guide for rebuilding the file system at
>> https://files.ettus.com/manual/page_usrp_e3x0.html
>> .
>> When I try to build an image with 'bitbake gnuradio-dev-image', I get
>> the following error:
>> ERROR: Function failed: do_compile (log file is located at
>> /home/user/Projects/E310/e300-oe-build/build/tmp-glibc/work/
ettus_e3xx_sg1-oe-linux-gnueabi/lttng-mod
Re: [USRP-users] Issues with dual full duplex on x310
With help from Jonathon, this issue has been resolved. The basic steps taken that might assist others: 1) Used 4 RFNoC radio blocks for dual full duplex, used the dma fifo for the tx chains and reduced its size to limit the delay out to the antenna for low sample rates. 2) Implemented part of the tx chains in rfnoc (bpsk modulator + interpolating fir transmit filter) - this eliminated U's but caused packet drops indicated by Doverrun. 3) Running netstat -s before and after running the flowgraph and getting packet drops, check to see if the value of UDP: RcvBufErrors increases. If it does, drops are occurring in the kernel (so maybe host processing speed is an issue) otherwise they are likely occurring in the NIC. Check the NIC's ring buffer descriptor count 'ethtool -g eth0' mine was set for 256 for rx, change this to the max by running 'ethtool -G eth0 rx 4096' (probably good to do on the tx too). Flowgraph now runs without any errors! On Wed, Jul 26, 2017 at 12:54 PM, Michael Carosino wrote: > Jonathon, > > I'm using 1GigE and running at 2Msps (and lower). Unfortunately I cannot > use jumbo frames (9000 mtu) as currently our x310's are on a network not > setup for them (which breaks other things if enabled). The weird thing is > the underruns only occur with the 4 rfnoc radio blocks, they don't occur if > I use a usrp source + sink each with 2 channels. I imagine there must be > some difference in how the data is passed in these two scenarios? Ideally I > would be able to change the dma fifo size directly in the usrp sink block, > however as a workaround, I'm trying to build my own fpga image with a > different default size for the dram tx fifo and hopefully then I can use > the usrp source/sink blocks again. > > The underruns don't happen with only 1 TX radio (assuming you use a usrp > sink or a rfnoc radio + dma fifo). > > thanks, > Michael > > On Jul 26, 2017 12:24 PM, "Jonathon Pendlum" > wrote: > > Hi Mike, > > Make sure your MTU is set to 9000. Are you using 1GigE or 10GigE? Do you > see underruns improve when running with only 1 TX radio? > > Jonathon > > On Tue, Jul 25, 2017 at 2:18 PM, Michael Carosino via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> >> I'm using gnuradio 3.7.12 and rfnoc-devel commit 1908672. >> >> I'm trying to use both daughter boards on the x310 each at full duplex >> (that is, I will have 2 independent tx paths and 2 independent rx paths). >> So far I have accomplished this by using the UHD: USRP Sink/Source blocks >> and setting them to 2 channels, selecting the appropriate antennas, and >> specifying a subdev spec of A:0 B:0. The flowgraph works perfectly sending >> and receiving 2 sets of data simultaneously. >> >> However, I need to have the same capability when using the RFNoC blocks. >> I've attempted to use 2 RFNoC radio blocks, one set to Tx, 2 channels, and >> the other set to Rx, 2 channels, however the block's parameters have only a >> radio select of A or B unlike the usrp source's subdev spec, so this setup >> does not appear to work no matter what configurations I try. Am I mistaken >> about what the 2 channels refers to here? >> >> I did finally get an RFNoC setup that works by using 4 RFNoC radio blocks >> (2 for transmit with radio select A, B respectively, and 2 for receive with >> radio select A, B respectively). However, with this setup I get tons of >> underflow "U" in the console. Curiously this happens even when using the >> DMAFIFO as ettus recommends so I'm not sure what's going on. My flowgraph >> is attached showing this setup. >> >> (A quick note on why I want to use the rfnoc blocks, apparently the uhd >> usrp sink block now automatically includes a DMAFIFO in the tx chain to >> deal with the underflow issue caused by tcp flow control, however for my >> application the depth/size of this fifo is much too large and causing >> massive delays, I've found that by reducing the depth I can minimize my >> delay and I'll only get underflows on flowgraph startup which I assume is >> due to the tcp slow start phase before backoff occurs. All this to say, if >> there is a way to adjust the dma fifo depth from the usrp sink blocks I'd >> gladly use that instead). >> >> >> Thanks, >> Mike >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
