Call for testing: GNU Radio 3.9.2.0 on FreeBSD
Just in time for Field Day, here is a call for testing for GNU Radio 3.9.2.0. The patch is available on Phabricator: https://reviews.freebsd.org/D30917 You will also need a newer devel/volk: https://reviews.freebsd.org/D30700 Note that the port is now flavoured like devel/git: there is a default flavour that by default enables everything but GNU Radio Companion (GRC, a GUI tool), grc to explicitly also enable GRC and headless to exclude all GUI-related components, meant for running existing flowgraphs. Patches, comments, etc are welcome! -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: llvm10 build failure on Rpi3
On 2021-Jun-25, at 22:14, Mark Millard wrote: > On 2021-Jun-25, at 20:52, bob prohaska wrote: > >> If you replicate the problem I'll be very pleased. >> And just slightly relieved. > > > No luck on the 1st try: > > [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && > /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel > -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ > lib/Target/AArch64 -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s > rc/lib/Target/AArch64/AArch64.td --write-if-changed -o > lib/Target/AArch64/AArch64GenGlobalISel.inc -d > lib/Target/AArch64/AArch64GenGlobalISel.inc.d > . . . > [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && > /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel > -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td > --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d > > Both finished just fine, indicating that the prior file generations were > okay. > > I'll put the options to be like you are using and try again. No failure. In a faster context with RAM such that there is no reported use of swap in top, I've tried a host kernel that is non-debug and a host kernel that is debug in combinations with host worlds that are non-debug vs. debug in combination with systems for the jail that are non-debug releng/13 based, non-debug main based, and debug main based. So far none of that has failed. On the RPi4B with total_mem=1024 I've only had the non-debug main host kernel and world and a world for jail use that was nondebug. But I've tried with and without junk:true. No failures. For the RPi4B, I've now got a debug host kernel and world and a debug world for jail use. So, by default, junk:true . We will see if it gets a failure or not. It is likely the last of the reproduction attempts based on the information so far. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: llvm10 build failure on Rpi3
[freebsd-arm+owner at FreeBSD.org sent a notice of rejection of the original of the below because, according to it, I was not a subscriber to freebsd-arm. So this is a resend after (re-)subscribing. We will see if it is again rejected.] On 2021-Jun-25, at 22:14, Mark Millard wrote: > On 2021-Jun-25, at 20:52, bob prohaska wrote: > >> If you replicate the problem I'll be very pleased. >> And just slightly relieved. > > > No luck on the 1st try: > > [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && > /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel > -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ > lib/Target/AArch64 -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s > rc/lib/Target/AArch64/AArch64.td --write-if-changed -o > lib/Target/AArch64/AArch64GenGlobalISel.inc -d > lib/Target/AArch64/AArch64GenGlobalISel.inc.d > . . . > [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && > /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel > -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target > /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td > --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d > lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d > > Both finished just fine, indicating that the prior file generations were > okay. > > I'll put the options to be like you are using and try again. No failure. In a faster context with RAM such that there is no reported use of swap in top, I've tried a host kernel that is non-debug and a host kernel that is debug in combinations with host worlds that are non-debug vs. debug in combination with systems for the jail that are non-debug releng/13 based, non-debug main based, and debug main based. So far none of that has failed. On the RPi4B with total_mem=1024 I've only had the non-debug main host kernel and world and a world for jail use that was nondebug. But I've tried with and without junk:true. No failures. For the RPi4B, I've now got a debug host kernel and world and a debug world for jail use. So, by default, junk:true . We will see if it gets a failure or not. It is likely the last of the reproduction attempts based on the information so far. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: llvm10 build failure on Rpi3
On 2021-Jun-26, at 15:29, Mark Millard wrote: > > [freebsd-arm+owner at FreeBSD.org sent a notice of rejection > of the original of the below because, according to it, I was > not a subscriber to freebsd-arm. So this is a resend after > (re-)subscribing. We will see if it is again rejected.] > > On 2021-Jun-25, at 22:14, Mark Millard wrote: > >> On 2021-Jun-25, at 20:52, bob prohaska wrote: >> >>> If you replicate the problem I'll be very pleased. >>> And just slightly relieved. >> >> >> No luck on the 1st try: >> >> [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && >> /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel >> -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ >> lib/Target/AArch64 -I >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s >> rc/lib/Target/AArch64/AArch64.td --write-if-changed -o >> lib/Target/AArch64/AArch64GenGlobalISel.inc -d >> lib/Target/AArch64/AArch64GenGlobalISel.inc.d >> . . . >> [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && >> /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel >> -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td >> --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d >> lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >> >> Both finished just fine, indicating that the prior file generations were >> okay. >> >> I'll put the options to be like you are using and try again. > > No failure. > > In a faster context with RAM such that there is no reported > use of swap in top, I've tried a host kernel that is non-debug > and a host kernel that is debug in combinations with host > worlds that are non-debug vs. debug in combination with systems > for the jail that are non-debug releng/13 based, non-debug > main based, and debug main based. > > So far none of that has failed. > > On the RPi4B with total_mem=1024 I've only had the non-debug > main host kernel and world and a world for jail use that was > nondebug. But I've tried with and without junk:true. > > No failures. > > For the RPi4B, I've now got a debug host kernel and world > and a debug world for jail use. So, by default, junk:true . > > We will see if it gets a failure or not. > > It is likely the last of the reproduction attempts based on > the information so far. No failure. I do not plan on exploring swap/paging space sizes that produce notices about being mistuned. I do not plan on exploring use of spinning rust or powered hubs. Or using USB2 for the SSD. (Use of some vintage of RPi3B would require use of a powered hub, so I'll not be trying that either.) Not having replicated the problem, I'm not trying some official build from expanding the likes of artifacts.ci.freebsd.org materials. RECOMMENDATION: Since you have a failing context, I recommend that you do the test of using expanded materials from artifacts.ci.freebsd.org (so: use an official build) with a swap space size that does not produce the warning: See of the problem goes away vs. repeats with such an "official" context. Either your problem will be solved or you will at least be able to report information about the behavior of official build materials in a context not reporting a mistuning. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
