31 Mar
2025
31 Mar
'25
8:19 p.m.
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
31 Mar
31 Mar
8:36 p.m.
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?
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
1 Apr
1 Apr
1:01 p.m.
On Mon, Mar 31, 2025 at 8:42 PM Pau Espin Pedrol <pespin(a)sysmocom.de> wrote:
Hi,
=== socket_sctp: ===
osmo_sock_init2_multiaddr() is failing due to:
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
+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?
11:09 p.m.
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
"""
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
7 Apr
7 Apr
4:54 p.m.
On Tue, Apr 1, 2025 at 11:10 PM Pau Espin Pedrol <pespin(a)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
8 Apr
8 Apr
10:33 a.m.
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(a)sysmocom.de> wrote:
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
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.
1 Apr
1 Apr
11:18 p.m.
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
=== osmo_io_test: ===
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.
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
+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?
7 Apr
7 Apr
4:47 p.m.
On Tue, Apr 1, 2025 at 11:18 PM Pau Espin Pedrol <pespin(a)sysmocom.de> wrote:
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
I will check and report back
Jaroslav
=== osmo_io_test: ===
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.
+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?
5:39 p.m.
On Mon, Apr 7, 2025 at 4:47 PM Jaroslav Škarvada <jskarvad(a)redhat.com> wrote:
On Tue, Apr 1, 2025 at 11:18 PM Pau Espin Pedrol <pespin(a)sysmocom.de> wrote:
# 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
Hi,
On 3/31/25 8:36 PM, Pau Espin Pedrol wrote:
I will check and report back
Jaroslav
=== osmo_io_test: ===
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.
+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?
74
days inactive
82
days old
8 comments
3 participants
participants (3)
-
Harald Welte -
Jaroslav Škarvada -
Pau Espin Pedrol