Hi,
I built libosmocore head (commit 84dcf73625513af44e711b2c99e21ee2c33b7eff at that time) on Fedora 43 (rawhide) and on s390x 4 tests failed. Iit's s390x running in qemu on x86_64, but it also fails on native s390 - there I saw failures of tests 25 26 69 90 (unfortunately I don't have the log from the native run). So probably more tests can coredump, to see all the problematic tests, it would probably require running through the valgrind. I am reporting it according to the provided instructions
thanks & regards
Jaroslav
Hi,
=== socket_sctp: ===
osmo_sock_init2_multiaddr() is failing due to:
+unable to bind socket: 0.0.0.0:0: Protocol not available
So sounds like you don't have sctp module enabled in your kernel.
Check with "$ lsmod | grep sctp" before you run the test: sctp 536576 70 ip6_udp_tunnel 16384 1 sctp udp_tunnel 28672 1 sctp libcrc32c 12288 2 btrfs,sctp
AFAIR if it's available it should be loaded automatically. You can try loading it with "sudo modprobe sctp".
=== osmo_io_test: ===
+failure during io_uring_queue_init(): Function not implemented
Which kernel version are you running? An old one? It may not have io_uring support we require from the kernel. Maybe older liburing than expected too?
On Mon, Mar 31, 2025 at 8:42 PM Pau Espin Pedrol pespin@sysmocom.de wrote:
Hi,
=== socket_sctp: ===
osmo_sock_init2_multiaddr() is failing due to:
+unable to bind socket: 0.0.0.0:0: Protocol not available
So sounds like you don't have sctp module enabled in your kernel.
Check with "$ lsmod | grep sctp" before you run the test: sctp 536576 70 ip6_udp_tunnel 16384 1 sctp udp_tunnel 28672 1 sctp libcrc32c 12288 2 btrfs,sctp
AFAIR if it's available it should be loaded automatically. You can try loading it with "sudo modprobe sctp".
=== osmo_io_test: ===
+failure during io_uring_queue_init(): Function not implemented
Which kernel version are you running? An old one? It may not have io_uring support we require from the kernel. Maybe older liburing than expected too?
It's the latest fedora 43 (rawhide), the build kernel is IMHO 6.13.8. Check the full native build and test log on: https://koji.fedoraproject.org/koji/taskinfo?taskID=130969129 Click s390x, then build.log and you will see the full build log with the testsuite.log embedded. It's marked as the passed build, because I bypassed the error code test, but the tests failures are clearly visible in the log
thanks & regards
Jaroslav
Hi,
AFAIK s390x is a big-endian architecture? I don't think we are nowadays supporting officially any big-endian architecture, though imho "patches welcome" (but iirc from previous ML discussions others think we should simply drop all kind of support for it).
I think the errors are related to the fact that some unit tests are not prepared to be run in big-endian architectures.
Test failures that show up in https://kojipkgs.fedoraproject.org//work/tasks/9213/130969213/build.log:
dtx_gsm0503_test: """ Assert failed amr_last_dtx == AMR_OTHER dtx/dtx_gsm0503_test.c:239 """
gsm0808_test: """ <0000> gsm0808/gsm0808_test.c:145 test_create_layer3_aoip() L3 data mismatch: expected 00 17 57 05 08 00 77 62 83 33 66 44 88 17 01 23 7d 07 53 ef cd a2 9f fd c0 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. !! msgb 00 17 57 05 08 00 77 62 83 33 66 44 88 17 01 23 7d 07 53 cd ef a2 9f fd c0 """
sockaddr_str_test (it can be seen it's a endiannes issue in the output: """ - osmo_sockaddr_str_to_32h() rc == 0 uint8_t[4]=[ 04 03 02 01 ] + osmo_sockaddr_str_to_32h() rc == 0 uint8_t[4]=[ 01 02 03 04 ] """
jhash_test: """ add: - adding items[0]#b286bb61 = blob one -- adding items[1]#ad4eb7b = blob two and five are the same +- adding items[1]#2713bb85 = blob two and five are the same - adding items[2]#6b8eae61 = third blob - adding items[3]#24a546dc = fourth blob -- adding items[4]#ad4eb7b = blob two and five are the same +- adding items[4]#2713bb85 = blob two and five are the same """
On Tue, Apr 1, 2025 at 11:10 PM Pau Espin Pedrol pespin@sysmocom.de wrote:
Hi,
AFAIK s390x is a big-endian architecture? I don't think we are nowadays supporting officially any big-endian architecture, though imho "patches welcome" (but iirc from previous ML discussions others think we should simply drop all kind of support for it).
Yes, it's a big endian. It's Fedora officially supported primary arch.
I think the errors are related to the fact that some unit tests are not prepared to be run in big-endian architectures.
Is it only unit tests or is there a problem with the library? In the former case i.e. if most of the library can work normally, I could just disable the tests on s390x. In the latter case, I could exclude the package from the s390x arch as the arch isn't supported upstream
Jaroslav
Hi Jaroslav,
On Mon, Apr 07, 2025 at 04:54:27PM +0200, Jaroslav Škarvada wrote:
On Tue, Apr 1, 2025 at 11:10 PM Pau Espin Pedrol pespin@sysmocom.de wrote:
AFAIK s390x is a big-endian architecture? I don't think we are nowadays supporting officially any big-endian architecture, though imho "patches welcome" (but iirc from previous ML discussions others think we should simply drop all kind of support for it).
Yes, it's a big endian. It's Fedora officially supported primary arch.
Sadly in 2023 we have discontinued supporting BE platforms from Osmocom CNI as there is zero interest from commercial customers of sysmocom nor any volunteers in the community willing to maintain it.
See the thread at https://www.mail-archive.com/openbsc@lists.osmocom.org/msg10730.html
I therefore suggest all distributions to disable building of libosmo* and osmo* packages on big-endian platforms.
Best regards, Harald
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
=== osmo_io_test: ===
+failure during io_uring_queue_init(): Function not implemented
Which kernel version are you running? An old one? It may not have io_uring support we require from the kernel. Maybe older liburing than expected too?
I think the kernel running the tests doesn't have io_uring enabled. see: https://github.com/axboe/liburing/issues/611
Regarding sctp, issue I bet your kernel is also missing sctp built as either builtin or kernel module.
On Tue, Apr 1, 2025 at 11:18 PM Pau Espin Pedrol pespin@sysmocom.de wrote:
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
=== osmo_io_test: ===
+failure during io_uring_queue_init(): Function not implemented
Which kernel version are you running? An old one? It may not have io_uring support we require from the kernel. Maybe older liburing than expected too?
I think the kernel running the tests doesn't have io_uring enabled. see: https://github.com/axboe/liburing/issues/611
Regarding sctp, issue I bet your kernel is also missing sctp built as either builtin or kernel module.
I will check and report back
Jaroslav
On Mon, Apr 7, 2025 at 4:47 PM Jaroslav Škarvada jskarvad@redhat.com wrote:
On Tue, Apr 1, 2025 at 11:18 PM Pau Espin Pedrol pespin@sysmocom.de wrote:
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
=== osmo_io_test: ===
+failure during io_uring_queue_init(): Function not implemented
Which kernel version are you running? An old one? It may not have io_uring support we require from the kernel. Maybe older liburing than expected too?
I think the kernel running the tests doesn't have io_uring enabled. see: https://github.com/axboe/liburing/issues/611
Regarding sctp, issue I bet your kernel is also missing sctp built as either builtin or kernel module.
I will check and report back
Jaroslav
# grep -i 'sctp|uring' /boot/config-6.15.0-0.rc0.20250327git1a9239bb4253.5.fc43.s390x CONFIG_IO_URING=y CONFIG_NF_CT_PROTO_SCTP=y CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_IP_VS_PROTO_SCTP=y CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set CONFIG_SCTP_COOKIE_HMAC_MD5=y CONFIG_SCTP_COOKIE_HMAC_SHA1=y CONFIG_INET_SCTP_DIAG=m CONFIG_FUSE_IO_URING=y
If there is some simple benchmark/test, I can also run it
Jaroslav
-
Harald Welte -
Jaroslav Škarvada -
Pau Espin Pedrol