Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop"

Reply: Adrian Chadd : "Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop""
In reply to: Mark Millard : "Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop""
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 26 Jan 2025 18:04:23 UTC
On Jan 25, 2025, at 02:24, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 25, 2025, at 02:10, Stefan Esser <se@FreeBSD.org> wrote:
> 
>> Am 25.01.25 um 10:54 schrieb Mark Millard:
>>> Unfortunately, for now my reporting is based on my personal build environment,
>>> not on anofficial FreeBSD build.
>>> Context doing the building:
>> 
>> Hi Mark,
>> 
>> probably an issue due to commit af0a81b6470 from 2024-12-12:
>> 
>> commit af0a81b6470aba4af4a24ae9804053722846ded4
>> Author: Emmanuel Vadot <manu@FreeBSD.org>
>> Date:   Thu Dec 12 17:13:58 2024 +0100
>> 
>>   iwm: Stop shipping firmware as kernel module
>> 
>>   Since we can load raw firmware start shipping them as is.
>>   This also remove the uuencode format that don't add any value and garbage
>>   collect old firmwares version.
>>   For pkgbase users they are now in the FreeBSD-firmware-iwm package.
>> 
>>   Sponsored by:   Beckhoff Automation GmbH & Co. KG
>> 
>> Maybe your sources are out of sync with regard to that commit?
> 
> https://cgit.freebsd.org/src/blame/sys/conf/files shows the lines that
> I quoted that indicate dependencies on various *.fw.uu files.
> 
> It is true that a pre 2024-Dec-12 installation is attempting to
> build what I reported: 2025-01-25 00:07:01 +0000 ( i.e., n275030
> 46a9fb7287f41eedf321d81a68a826f231d11bfe ). I had not updated
> at all between those times and was finally trying to update.
> 

It appears that the following is enough to have the build
failures:

# grep -r iwm /usr/main-src/sys/*/conf*/
/usr/main-src/sys/amd64/conf/GENERIC-NODBG:device iwm
/usr/main-src/sys/amd64/conf/GENERIC-NODBG:device iwmfw
/usr/main-src/sys/amd64/conf/GENERIC-DBG:device iwm
/usr/main-src/sys/amd64/conf/GENERIC-DBG:device iwmfw
/usr/main-src/sys/amd64/conf/GENERIC-NODBG-NONUMA:device iwm
/usr/main-src/sys/amd64/conf/GENERIC-NODBG-NONUMA:device iwmfw

Commenting out the "device iwmfw" lines allowed the build to
complete --but based on my /usr/main-src/ source tree for
what was being built, not on building an official tree.

To my knowledge, the builds shown by the likes of:

https://pkg-status.freebsd.org/builds?type=package&all=1

do not involve "device iwmfw" --and so do not make for
a valid comparison to my context. (I normally check if
I'm getting unusual results vs. official builds.)


Those GENERIC-*DBG* files are based on GENERIC . For example:

# more /usr/main-src/sys/amd64/conf/GENERIC-NODBG
#
# GENERIC -- Custom configuration for the amd64/amd64
#

include "GENERIC"

ident   GENERIC-NODBG

makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols
makeoptions     WITH_CTF=1              # Run ctfconvert(1) for DTrace support

options         NUMA

#options        ALT_BREAK_TO_DEBUGGER

options         KDB                     # Enable kernel debugger support

# For minimum debugger support (stable branch) use:
options         KDB_TRACE               # Print a stack trace for a panic
options         DDB                     # Enable the kernel debugger

# Extra stuff:
#options        VERBOSE_SYSINIT=0       # Enable verbose sysinit messages
#options        BOOTVERBOSE=1
#options        BOOTHOWTO=RB_VERBOSE
#options        KTR
#options        KTR_MASK=KTR_TRAP
##options       KTR_CPUMASK=0xF
#options        KTR_VERBOSE
#options        ACPI_DEBUG

# Disable any extra checking for. . .
nooptions       DEADLKRES               # Would enable the deadlock resolver
nooptions       INVARIANTS              # Would enable calls of extra sanity checking
nooptions       INVARIANT_SUPPORT       # Would enable extra sanity checks of internal structures, required by INVARIANTS
nooptions       WITNESS                 # Would enable checks to detect deadlocks and cycles
nooptions       WITNESS_SKIPSPIN        # Would enable running witness on spinlocks for speed
nooptions       DIAGNOSTIC
nooptions       MALLOC_DEBUG_MAXZONES

# Kernel Sanitizers
nooptions       COVERAGE                # Would enable generic kernel coverage. Used by KCOV
nooptions       KCOV                    # Would enable Kernel Coverage Sanitizer
# Warning: KUBSAN can result in a kernel too large for loader to load
nooptions       KUBSAN                  # Would enable Kernel Undefined Behavior Sanitizer

device  iwm
device  iwmfw


Maybe the IWM(4) man page is out of date and the above need to be
changed in some way and so I should follow updated instructions?

IWM(4)                 FreeBSD Kernel Interfaces Manual                 IWM(4)

NAME
     iwm – Intel IEEE 802.11ac wireless network driver

SYNOPSIS
     To compile this driver into the kernel, include the following lines in
     your kernel configuration file:

           device iwm
           device pci
           device wlan
           device firmware

     You also need to select a firmware for your device.  Choose one from:

           device iwm3160fw
           device iwm3168fw
           device iwm7260fw
           device iwm7265fw
           device iwm7265Dfw
           device iwm8000Cfw
           device iwm8265fw
           device iwm9000fw
           device iwm9260fw

     Or you can use

           device iwmfw

     to include them all.
. . .




Below is an investigative sequence that I did before
reaching the conclusion above. It all predates
commenting out the "device iwmfw" lines indicated
above. I've not adjusted any of it for the above.
The above was based on the new:

/usr/obj/BUILDs/main-amd64-*dbg-clang/usr/

that resulted in the below.

To start to isolate what might be going on, I used
PkgBase to established the context as not running
my personal build any more (both kernel and world):

# uname -apKU
FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT main-n275036-faa845aab611 GENERIC-NODEBUG amd64 amd64 1500030 1500030

I then retied the build ( such that it depends on META_MODE
behavior still and still uses the same source code as
before: my /usr/main-src/ ). It still got the same failures.

That suggested that META_MODE might be reusing something(s)
that need(s) to be rebuilt.

So I've gotten my old builds out of the way via renaming:

# ls -lodT /usr/obj/BUILDs/main-amd64-*dbg-clang/usr-**
drwxrwxr-x  3 root wheel uarch 3 Oct  8 23:57:37 2021 /usr/obj/BUILDs/main-amd64-dbg-clang/usr-OLDER
drwxrwxr-x  3 root wheel uarch 3 Aug 19 02:43:35 2021 /usr/obj/BUILDs/main-amd64-nodbg-clang/usr-OLDER

and started builds that will produce from-scratch:

/usr/obj/BUILDs/main-amd64-dbg-clang/usr/
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/

For now, this is using the same source code (my /usr/main-src/
tree) as was compiled before: not the source from/for the PkgBase
that is installed or any other update. I'm intending a META_MODE
test for this experiment.

We will see what happens for that. . . .

And it still gets the error. So I'll be coming up with
some other test.


===
Mark Millard
marklmi at yahoo.com