Re: No iwm interface in current.

On Fri, Dec 27, 2024, 10:41 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
wrote:

> On Fri, 27 Dec 2024 06:59:53 -0700
> Warner Losh <imp@bsdimp.com> wrote:
>
> > On Fri, Dec 27, 2024, 1:53 AM Emmanuel Vadot <manu@bidouilliste.com>
> wrote:
> >
> > > On Fri, 27 Dec 2024 09:43:22 +0100
> > > Emmanuel Vadot <manu@bidouilliste.com> wrote:
> > >
> > > >
> > > >  Hi,
> > > >
> > > > On Thu, 26 Dec 2024 23:55:24 +0100
> > > > Fernando Apesteguía <fernando.apesteguia@gmail.com> wrote:
> > > >
> > > > > I updated to today's current from a version from Nov 18th.
> > > > >
> > > > > I had these lines in loader.conf:
> > > > >
> > > > > iwm7265Dfw_load="YES"
> > > > > if_iwm_load="YES"
> > > > >
> > > > > And with those the kernel panics. Then I saw the entry 20241216 in
> > > > > UPDATING. Can't reproduce it here since I'm writing in my phone,
> but it
> > > > > says the iwm firmwares are now shipped as raw files.
> > > > > So, how can I get the firmware loaded to make my nic work?
> > > > >
> > > > > Cheers
> > > >
> > > >  Without panic trace it's hard to really know what's going on but I
> > > > think that the problem is that the firmware wasn't loaded by loader
> and
> > > > iwm panics since root fs isn't there yet.
> > > >  Just removing those lines will make iwm works again or you can use :
> > > > iwm7265Dfw_load="YES"
> > > > iwm7265Dfw_name="/boot/firmware/iwm7265Dfw"
> > > > iwm7265Dfw_type="firmware"
> > > >
> > > >  Cheers,
> > > >
> > > > --
> > > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
> > > >
> > >
> > >  https://reviews.freebsd.org/D48211 will help too.
> > >
> > >  P.S.: Note that I don't understand why anyone wants to load wifi
> > > driver in loader, was it suggested somewhere at some point ?
> > >
>
> What I can only imagine is that the computer is network-booted and
> doesn't have wired network, thus, need WiFi driver and its firmware
> to mount actual remote root fs (rootfs provided by, i.e, pxe is quite
> minimalistic and need remounting / with actual one).
> But I don't wamt to configure in such a way.
>

That is one scenario...

> Many people want to run minimal + their drivers and load them all from the
> > loader. With the firmware shift, we may need to defer drivers that need
> > firmware until after mountroot generally.
>
> I'm recommending (mostly on forums.freebsd.org) keeping
> /boot/loader.conf as lean as possible (let modules only essential
> to boot kernel and/or mountroot in it) and let other modules to be
> loaded via /etc/rc.conf[.local].
>
> This is because tooooooooooo many panics [on computers and/or users]
> trying to load everything including huge monstors like GPU drivers,
> graphics/drm-*-kmod, x11/nvidia-driver* and graphics/nvidia-drm-*-kmod
> which can easily make staging area overflow especially with zfs.ko.
>

I thought we'd fixed all the overflow issues... I'm generally planning a
more agressive loading of modules as work progresses on loader devmatch.

And another idea for loader only firmwares (in cases loading via
> /etc/rc.conf[.local] is too late), introducng new variable for loader
> such as module_fs could help.
> It shall be any file system that loader can read and specified not
> only with partition/pool but also with directory relative to the fs
> root that contains firmware/ directory.
>
> For example, if
>   Root on ZFS in local diks with pool name zroot,
>   module filesystem dataset is MODULE/default,
>   in MODULE/default, firmwares are in boot/firmware,
> module_fs is set to "zfs:zroot/MODULE/default/boot/", where "firmware/"
> directory exists.
>
> Treating ESP specially would ease UEFI boot, if possible.
> If ESP can be specified with "ESP:" and firmware/ directory is in
> EFI/freebsd/firmware/, mocule_fs could be "ESP:EFI/freebsd/".
>

I'm having trouble understanding what this solves that adding boot/firmware
to the boot path (and changing the default type based on path) gives you.

ESP can be ambiguous in some cases. loaddev isn't,  though. It might be
more helpful to allow a limited set of env vars to be expanded in both the
load path and files to load. Lua lets us have the right kind of filtering
if we want it.

Warner

Not sure if there really be such a need or not.
> And could be difficult for BIOS boots (does size of loader allow?).
> But historically, I haven't heared of such an actual needs in pre-UEFI
> era. So I assume BIOS boots doesn't need such an extentions.
>


Bios loader gets no new features after the stable/14 feature set.

>
> >
> > Warnet
> >
> > --
> > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>
>
> --
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
>