Bug 233465 - benchmarks/unixbench fails after update to 12-STABLE
Summary: benchmarks/unixbench fails after update to 12-STABLE
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Luca Pizzamiglio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-24 10:57 UTC by jakub_lach
Modified: 2020-09-27 09:17 UTC (History)
0 users

See Also:
pizzamig: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jakub_lach 2018-11-24 10:57:52 UTC
With

1 x Pipe-based Context Switching  1
**********************************************
Run: "Pipe-based Context Switching": slave read failed: Function not implemented; aborting


Any ideas?
Comment 1 Luca Pizzamiglio freebsd_committer 2018-11-27 16:51:42 UTC
mmm, I'm running it on CURRENT without any issue....

1 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: pizzamig: FreeBSD
   OS: FreeBSD -- 13.0-CURRENT -- FreeBSD 13.0-CURRENT #3 r339942M: Wed Oct 31 10:37:37 CET 2018     root@pizzamig:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
   Machine: amd64 (GENERIC-NODEBUG)
   Language: en_US.UTF-8 (charmap="UTF-8")


Did you upgraded all packages? FreeBSD 11 packages should run just fine, packages from BETA could have some issue..

I'll try to reproduce your error on a 12 jail. In the meanwhile, can you provide the output of `pkg info unixbench`, if possible?
Comment 2 jakub_lach 2018-11-27 20:02:53 UTC
System is self-hosted FreeBSD 12.0-PRERELEASE r340918, packages are up to date and built from source.

unixbench-5.1.3_1
Name           : unixbench
Version        : 5.1.3_1
Installed on   : Tue Nov 27 21:01:08 2018 CET
Origin         : benchmarks/unixbench
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : benchmarks
Licenses       : GPLv2
Maintainer     : pizzamig@FreeBSD.org
WWW            : https://github.com/kdlucas/byte-unixbench
Comment        : BYTE magazine's Public Domain benchmark for UNIX
Annotations    :
        FreeBSD_version: 1200500
Flat size      : 1.09MiB
Description    :
UnixBench based on the BYTE UNIX Benchmarks v3.

WWW: https://github.com/kdlucas/byte-unixbench

I will try to reproduce this problem to be 100% sure it still relevant (had some rebuilds since first run).
Comment 3 jakub_lach 2018-12-01 09:13:42 UTC
(In reply to jakub_lach from comment #2)
FYI, it's still the same.

System has custom kernel which I had for quite some time, though I've compared defaults from 11-STABLE to 12-STABLE and made necessary corrections.
Comment 4 Luca Pizzamiglio freebsd_committer 2019-06-17 12:03:54 UTC
Hi Jakub.
I had some spare time to investigate this.

The failing test is: 2 process with 2 pipes that read/write to each others.
The error is happening when the slave want to read from a pipe data written by the master.
The ENOSYS error you receive is documented as (from `man errno`)
78 ENOSYS Function not implemented. Attempted a system call that is not
             available on this system.

It seems to me that your custom kernel is somehow missing some feature related to pipes, even if I'm not able to find how it's possible, pipes are generated, but there is no available read.

Are you maybe using MAC or other security related frameworks that are limiting the access to system calls or other devices?
Comment 5 jakub_lach 2019-06-22 22:59:19 UTC
(In reply to Luca Pizzamiglio from comment #4)

I think I had replicated it with GENERIC since (probably should have check again), regarding security, I didn't have any substantial configuration changes after upgrading to 12.
Comment 6 jakub_lach 2020-09-26 18:44:21 UTC
(In reply to jakub_lach from comment #5)
Cannot replicate anymore. (FreeBSD 12.2-STABLE #0 r366183)
Comment 7 Luca Pizzamiglio freebsd_committer 2020-09-27 09:17:45 UTC
I'm closing this bug:
I'm not able to reproduce the error and the reporter cannot replicate it anymore.

I'm assuming that there has been some sort "glitch" in STABLE-12 that caused it.

If the bug re-appears, it's possible to re-open this PR