Re: Strange s390x/x86_64 build failures

2021-11-23 Thread Kevin Fenzi 
On Mon, Nov 22, 2021 at 12:50:06PM -0800, Kevin Fenzi wrote:
> I think there's something deeper going on. ;( 
> 
> That builder has in dmesg: 
> 
> [399371.168000] print_req_error: 2 callbacks suppressed
> [399371.168007] blk_update_request: I/O error, dev vda, sector 174077464 op 
> 0x1:(WRITE) flags 0x10 phys_seg 134 prio class 0
> [399371.168231] blk_update_request: I/O error, dev vda, sector 174079864 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 106 prio class 0
> [399371.168268] blk_update_request: I/O error, dev vda, sector 174082424 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 72 prio class 0
> [399371.168299] blk_update_request: I/O error, dev vda, sector 174084984 op 
> 0x1:(WRITE) flags 0x10 phys_seg 79 prio class 0
> [399371.168334] blk_update_request: I/O error, dev vda, sector 174087264 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 246 prio class 0
> [399371.168364] blk_update_request: I/O error, dev vda, sector 174089824 op 
> 0x1:(WRITE) flags 0x10 phys_seg 11 prio class 0
> [399371.168394] blk_update_request: I/O error, dev vda, sector 174089984 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 232 prio class 0
> [399371.168535] blk_update_request: I/O error, dev vda, sector 174092544 op 
> 0x1:(WRITE) flags 0x10 phys_seg 25 prio class 0
> [399371.168632] blk_update_request: I/O error, dev vda, sector 174092800 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 217 prio class 0
> [399371.168661] blk_update_request: I/O error, dev vda, sector 174095360 op 
> 0x1:(WRITE) flags 0x10 phys_seg 40 prio class 0
> [399371.169478] vda6: writeback error on inode 204925378, offset 0, sector 
> 174074904
> [399371.196642] vda6: writeback error on inode 70353785, offset 0, sector 
> 72333240
> [399371.204462] vda6: writeback error on inode 70353792, offset 0, sector 
> 73328008
> [399371.206361] vda6: writeback error on inode 70353784, offset 0, sector 
> 72295304
> 
> It is running a old kernel tho (it was reinstalled recently).
> Along with 3 others. 
> 
> I have updated them all and rebooted them into the latest kernel. 
> If you see this again, please file a ticket on it and we can dig deeper. 
> 
> I'll also try and keep an eye out on them but I am on PTO this week

So, they all started showing the issues again... 

I have reinstalled them, this time with different (more conservative)
cache settings for the disk. Hopefully this will fix things and the new
mainframe is just more sensitive for i/o than the old one was. 

Will keep watching them.

There is also: 

https://pagure.io/fedora-infrastructure/issue/10362

to report seeing issues now. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange s390x/x86_64 build failures

2021-11-22 Thread Kevin Fenzi 
On Sun, Nov 21, 2021 at 07:51:58PM -0700, Orion Poplawski wrote:
> On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:
> > Just noting that I had a strange one-time s390x and x86_64 build failure.
> 
> More:
> 
> s390x:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231
> 
> libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
> /usr/bin/ranlib: unable to copy file 'liboctave/array/.libs/libarray.a';
> reason: Input/output error
> make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1
> 
> i686:
> 
> virtual memory exhausted: Operation not permitted
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237
> 
> (okay, this is probably your typical out of memory build issue)

I think there's something deeper going on. ;( 

That builder has in dmesg: 

[399371.168000] print_req_error: 2 callbacks suppressed
[399371.168007] blk_update_request: I/O error, dev vda, sector 174077464 op 
0x1:(WRITE) flags 0x10 phys_seg 134 prio class 0
[399371.168231] blk_update_request: I/O error, dev vda, sector 174079864 op 
0x1:(WRITE) flags 0x104000 phys_seg 106 prio class 0
[399371.168268] blk_update_request: I/O error, dev vda, sector 174082424 op 
0x1:(WRITE) flags 0x104000 phys_seg 72 prio class 0
[399371.168299] blk_update_request: I/O error, dev vda, sector 174084984 op 
0x1:(WRITE) flags 0x10 phys_seg 79 prio class 0
[399371.168334] blk_update_request: I/O error, dev vda, sector 174087264 op 
0x1:(WRITE) flags 0x104000 phys_seg 246 prio class 0
[399371.168364] blk_update_request: I/O error, dev vda, sector 174089824 op 
0x1:(WRITE) flags 0x10 phys_seg 11 prio class 0
[399371.168394] blk_update_request: I/O error, dev vda, sector 174089984 op 
0x1:(WRITE) flags 0x104000 phys_seg 232 prio class 0
[399371.168535] blk_update_request: I/O error, dev vda, sector 174092544 op 
0x1:(WRITE) flags 0x10 phys_seg 25 prio class 0
[399371.168632] blk_update_request: I/O error, dev vda, sector 174092800 op 
0x1:(WRITE) flags 0x104000 phys_seg 217 prio class 0
[399371.168661] blk_update_request: I/O error, dev vda, sector 174095360 op 
0x1:(WRITE) flags 0x10 phys_seg 40 prio class 0
[399371.169478] vda6: writeback error on inode 204925378, offset 0, sector 
174074904
[399371.196642] vda6: writeback error on inode 70353785, offset 0, sector 
72333240
[399371.204462] vda6: writeback error on inode 70353792, offset 0, sector 
73328008
[399371.206361] vda6: writeback error on inode 70353784, offset 0, sector 
72295304

It is running a old kernel tho (it was reinstalled recently).
Along with 3 others. 

I have updated them all and rebooted them into the latest kernel. 
If you see this again, please file a ticket on it and we can dig deeper. 

I'll also try and keep an eye out on them but I am on PTO this week

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange s390x/x86_64 build failures

2021-11-21 Thread Vitaly Zaitsev via devel 

On 22/11/2021 03:51, Orion Poplawski wrote:

i686:
virtual memory exhausted: Operation not permitted


Memory limit of the 32-bit address space (2 GB) has been reached. Try 
reducing the debuginfo level.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange s390x/x86_64 build failures

2021-11-21 Thread Luya Tshimbalanga 


On 2021-11-21 18:51, Orion Poplawski wrote:

On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:
Just noting that I had a strange one-time s390x and x86_64 build 
failure.


More:

s390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231

libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
/usr/bin/ranlib: unable to copy file 
'liboctave/array/.libs/libarray.a'; reason: Input/output error

make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1

i686:

virtual memory exhausted: Operation not permitted

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237

(okay, this is probably your typical out of memory build issue)

I also hit similar issue with arm architecture with scratch build result 
of OpenVDB:


https://koji.fedoraproject.org/koji/taskinfo?taskID=79142031

---

cd /builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb && 
/usr/bin/g++ -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB 
-I/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/.. 
-I/builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb 
-I/builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb/openvdb 
-I/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/. -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong   
-march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux 
-mfloat-abi=hard -Wl,--as-needed -DNDEBUG -std=c++14 -MD -MT 
openvdb/openvdb/CMakeFiles/openvdb_static.dir/io/Archive.cc.o -MF 
CMakeFiles/openvdb_static.dir/io/Archive.cc.o.d -o 
CMakeFiles/openvdb_static.dir/io/Archive.cc.o -c 
/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/io/Archive.cc
virtual memory exhausted: Operation not permitted
gmake[2]: *** [openvdb/openvdb/CMakeFiles/openvdb_static.dir/build.make:625: 
openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/GridOperators.cc.o]
 Error 1
---

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Strange s390x/x86_64 build failures

2021-11-21 Thread Orion Poplawski 

On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:

Just noting that I had a strange one-time s390x and x86_64 build failure.


More:

s390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231

libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
/usr/bin/ranlib: unable to copy file 'liboctave/array/.libs/libarray.a'; 
reason: Input/output error

make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1

i686:

virtual memory exhausted: Operation not permitted

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237

(okay, this is probably your typical out of memory build issue)


--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Strange s390x/x86_64 build failures

2021-11-21 Thread Orion Poplawski 

Just noting that I had a strange one-time s390x and x86_64 build failure.

s390x:

/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=zEC12 -mtune=z13 
-fasynchronous-unwind-tables -fstack-clash-protection -DH5_USE_110_API 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -shared 
-Wl,-soname,libField3D.so.1.7 -o libField3D.so.1.7.3 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o 
CMakeFiles/Field3D.dir/src/DenseFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/Field3DFile.cpp.o 
CMakeFiles/Field3D.dir/src/Field3DFileHDF5.cpp.o 
CMakeFiles/Field3D.dir/src/FieldCache.cpp.o 
CMakeFiles/Field3D.dir/src/Field.cpp.o 
CMakeFiles/Field3D.dir/src/FieldInterp.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMapping.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMappingIO.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMetadata.cpp.o 
CMakeFiles/Field3D.dir/src/FileSequence.cpp.o 
CMakeFiles/Field3D.dir/src/Hdf5Util.cpp.o 
CMakeFiles/Field3D.dir/src/IArchive.cpp.o 
CMakeFiles/Field3D.dir/src/IData.cpp.o 
CMakeFiles/Field3D.dir/src/IGroup.cpp.o 
CMakeFiles/Field3D.dir/src/InitIO.cpp.o 
CMakeFiles/Field3D.dir/src/IStreams.cpp.o 
CMakeFiles/Field3D.dir/src/Log.cpp.o 
CMakeFiles/Field3D.dir/src/MACFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/MIPFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/MIPUtil.cpp.o 
CMakeFiles/Field3D.dir/src/OArchive.cpp.o 
CMakeFiles/Field3D.dir/src/OData.cpp.o 
CMakeFiles/Field3D.dir/src/OgIGroup.cpp.o 
CMakeFiles/Field3D.dir/src/OGroup.cpp.o 
CMakeFiles/Field3D.dir/src/OgUtil.cpp.o 
CMakeFiles/Field3D.dir/src/OStream.cpp.o 
CMakeFiles/Field3D.dir/src/PatternMatch.cpp.o 
CMakeFiles/Field3D.dir/src/PluginLoader.cpp.o 
CMakeFiles/Field3D.dir/src/ProceduralField.cpp.o 
CMakeFiles/Field3D.dir/src/Resample.cpp.o 
CMakeFiles/Field3D.dir/src/SparseFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/SparseFile.cpp.o  -lhdf5 
/usr/lib64/libOpenEXR-3_1.so.30.3.0 /usr/lib64/libImath-3_1.so.29.2.0 
-lpthread -ldl -lz -lboost_regex -lboost_thread -lboost_program_options 
-lboost_system -lboost_chrono -lboost_date_time -lboost_atomic -lm 
/usr/lib64/libIlmThread-3_1.so.30.3.0 /usr/lib64/libIex-3_1.so.30.3.0 
/usr/lib64/libz.so
/usr/lib/gcc/s390x-redhat-linux/11/../../../../lib64/libhdf5.so: file 
not recognized: file format not recognized

collect2: error: ld returned 1 exit status

https://koji.fedoraproject.org/koji/taskinfo?taskID=79141528

a rebuild worked fine.

Also this on x86_64:

cd /builddir/build/BUILD/alembic-1.8.3/redhat-linux-build/lib/Alembic && 
/usr/bin/g++ -DALEMBIC_EXPORTS -DPLATFORM=LINUX -DPLATFORM_LINUX 
-I/builddir/build/BUILD/alembic-1.8.3/lib 
-I/builddir/build/BUILD/alembic-1.8.3/redhat-linux-build/lib -isystem 
/usr/include/Imath -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wl,--as-needed -fvisibility=hidden -DH5_USE_18_API -fPIC   -fPIC -MD 
-MT lib/Alembic/CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o -MF 
CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o.d -o 
CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o -c 
/builddir/build/BUILD/alembic-1.8.3/lib/Alembic/Abc/OScalarProperty.cpp
*** WARNING *** there are active plugins, do not report this as a bug 
unless you can reproduce it without enabling any plugins.

Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
symbols

during IPA pass: modref
/builddir/build/BUILD/alembic-1.8.3/lib/Alembic/Abc/OScalarProperty.cpp:181:1: 
internal compiler error: Section already exists: 
'.gnu.lto__ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE12_M_drop_nodeEPSt13_Rb_tree_nodeIS8_E.9135.b09fa84751fd815e'

  181 | } // End namespace Alembic
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
gmake[2]: *** [lib/Alembic/CMakeFiles/Alembic.dir/build.make:1171: 
lib/Alembic/CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o] Error 1


https://koji.fedoraproject.org/koji/taskinfo?taskID=79141572

a rebuild worked fine.

Are we having any issues with the builders?

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane