[Bug 281600] lang/rust failing to build on risc-v (again)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281600

--- Comment #68 from Dennis Clarke <dclarke@blastwave.org> ---
(In reply to Dennis Clarke from comment #56)


Reply to myself because today is the 12 of September 2025 and that marks
about twelve days into this process. This morning I hit CTRL-t and see
poudriere claims :

 ID  TOTAL           ORIGIN   PKGNAME      PHASE PHASE   TMPFS CPU% MEM%
[01] 5D:20:44:05  lang/rust | rust-1.89.0  stage 00:07:24       57%   0%

Which seems to indicate that the build stage has been passed. I go look into
the logs and find : 

.
.
.
Build completed successfully in 5 days, 20:16:07
===========================================================================
=>> Checking for filesystem violations... done
=======================<phase: run-depends    >============================
===== env: DEVELOPER_MODE=yes USE_PACKAGE_DEPENDS_ONLY=1 USER=root UID=0 GID=0
===========================================================================
=>> Recording filesystem state for prestage... done
=======================<phase: stage          >============================
===== env: DEVELOPER_MODE=yes STRICT_DEPENDS=yes USER=root UID=0 GID=0
===>  Staging for rust-1.89.0
===>   Generating temporary packing list
.
.
.


So this machine is the SiFive UnMatched RevB RISC-V board and I did not
make any changes to the source : 

enceladus# 
enceladus# uname -apKU 
FreeBSD enceladus 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE
main-n279980-004ce88ad1ef GENERIC riscv riscv64 1500063 1500063
enceladus# 
enceladus# cd /usr/src

enceladus# 
enceladus# git --no-pager log -n 1
commit 004ce88ad1efd42a1d7d5692849b4aa6906178fc (HEAD -> main, origin/main,
origin/HEAD)
Author: Peter Eriksson <pen@lysator.liu.se>
Date:   Sun Aug 31 12:58:56 2025 -0600

    mpr: Add workaround for too few slots being automatically scanned

    This patch adds a /boot/loader.conf setting that makes it possibly to
    override the detected number of slots in storage enclosures. Some (yes
    I'm looking at you HPE D6020!) reports less available slots that there
    actually are (the D6020 seems to report 18 but actually has 35 per
    drawer). This causes the mpr driver to have problems detecting/managing
    all drives in a multienclosure setting. For the D6020 this occurs when
    connecting two or more fully equipped (140 drives) enclosures to one
    controller...

    This problem can be "fixed" by adding the following to /boot/loader.conf
    and rebooting:
        hw.mpr.encl_min_slots="35"

    Note: I (Warner) don't have this hardware to see if there's some way to
    fix the detection, so I'm committing this as a stop-gap. It's a no-op if
    no tunable is set.

    PR: 271238
    Reivewed by: imp
enceladus# 
enceladus# 

With a bit more time there may be a valid package later today.


-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

-- 
You are receiving this mail because:
You are on the CC list for the bug.