Re: No iwm interface in current.

On Fri, 27 Dec 2024 10:51:32 -0700
Warner Losh <imp@bsdimp.com> wrote:

> 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...

Maybe some more.


> > 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.

Of course, only for non-BIOS loaders, right?
And as recently not closely read loader codes, not sure if the staging
area of loader is now dinamically expanded as required (by module size
or info in their headers)? If not, it would overflow again when some
modules (monsters like zfs.ko, nvidia[-modeset].ko and DRM related
ones) become larger again.

And not read UEFI spec cloesly enough to understand dynamic expansions
of already allocated chunks or concatenating newly allocated chunk to
existing chunk are possible or not.


> 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.

The idea is only for the cases that actual root partition/dataset is
hard to be read by loader, not 100% sure such a situations really
exists or not. Otherwise, adding /boot/firmware to module_path would be
sufficient.

Frankly, documenting not to use such a crazy (aka 変態的 in Japanese)
configurations and include all needed modules (including firmwares)
into whichever /boot/kernel, /boot/modules or /boot/firmware of the
(permanent or temporary) root partition/dataset loadec by loader itself
should be sufficient and respected.
This way, my idea is completely useless and meaningless.


> 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.

Would be. Via [ESP]/efi/freebsd/loader.env, right?


> 
> 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>


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>