From nobody Fri Dec 27 17:51:32 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YKY3571PQz5j632 for ; Fri, 27 Dec 2024 17:51:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YKY355Kyfz4DTJ for ; Fri, 27 Dec 2024 17:51:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2ee51f8c47dso7203100a91.1 for ; Fri, 27 Dec 2024 09:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1735321904; x=1735926704; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=D+bG6yl9iyCwpSUxvHCIIqyDE0Vf9oCARo1P86g91ic=; b=kme9EULWOlpPTBOGBC5wUa6ukVGEwZL3Vk8/gPr8hI82hbhlQsZFvODmmh/5SLs6cP Q9Y9O18aROn4YOFycjqweXmQ+RnTJUE8quvxoKN5o5ZoCO8WmH1gu1Fw1x1LIMRsLu0d g+0596tNQQ7UCgLkTKauHVH+NYDYzbjPfh7mv14K4vOfCMUtsKDpMnr8H/jH3Rew8z/n UMQ1sbnrMWAfAiV2DXhRm/fx+qBL6bsiSdIkJRw3P6ytMKFd2ZvrxCY7NbsRCpTt8C4u 3hHwo0cgcE6RBMnMsBbTbqIeOWIuXIafJSnpCcyTlXysKnM0K/yOvwKf3EWedwEbHmcZ zSpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735321904; x=1735926704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D+bG6yl9iyCwpSUxvHCIIqyDE0Vf9oCARo1P86g91ic=; b=f8MhZVn0VWvKR1YC6qtlaeYmypM5sAh0Z00Uj/oDrYFOniPGoghWMc14JlVJv69lIT LwpK60l2Mvk/FT/FYsu6kzkSW3JLCQT3K+UQSwFb0gGu+62DwUtMzM9IS0jmtKbMQ67c J6XLxvkLci28wCWLDy8vt7Jo9O+v7G56WT2ZJUrgVy7UVbKVqCJCipca9HYWmJHGp16U aTIvdROYRCPsjysZE3tDIMhQv96T+QiVdTOBEuLH8acbaC1QfCMenDoEx3jNsJpYvNI9 EHEc3KuU4zzc4EvMvKB+IEqXJJDRjPSpoCChlOSIjwWjr/nZpDf2BHDxVutroq9CLKAa LTYg== X-Forwarded-Encrypted: i=1; AJvYcCUCEzRt7WkxoQwswnhcmtYrjIoGTOw54U77+pb+d6bGm3ssrz4ac0zT/lWL7nnRXVQo80KxVX946aAUtmSs9ic=@freebsd.org X-Gm-Message-State: AOJu0YxQDUkbb2OfgjUjs5MD+O3G9kmqtohwI3w1lmnd0hVU9p9Rr8K7 2LKViSKTIrp321J1MogEfx81KjKmvsx6LYJnYpDz1Ud7SoVf6PLtrZotublqhbdTnn89EMZK/2M 5jst2/cJ+lba+qQtRzfncrc1dqZxQ2lbIDIxOMg== X-Gm-Gg: ASbGncsveu3PMNA0cu97CxGsU/TL1M0RnZTo2a92xtAGkmUwc2F1ydBbfxOr76fMzrG +CwKJDIGyNErJkxAqZB0Z6n03JUgGmJht09SP/UvYUbYQUEuuMWISr9/LGN5BnoXOJrq9 X-Google-Smtp-Source: AGHT+IE9iqNkFmJqUSufcXpExvWa9Oj3MbdYInzEFbeCRroaop8r90jZKBegGi6aIgbVLzODjvuAhCNBGwXM8DZ2KuM= X-Received: by 2002:a17:90b:54cb:b0:2ee:96a5:721e with SMTP id 98e67ed59e1d1-2f452e1cacamr52219781a91.12.1735321904519; Fri, 27 Dec 2024 09:51:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <20241227094322.64a88d47bc806904f40a51d3@bidouilliste.com> <20241227095321.a8309bd2512b9d43f944e530@bidouilliste.com> <20241228024117.183fcc3c7efd8cd64e086e3b@dec.sakura.ne.jp> In-Reply-To: <20241228024117.183fcc3c7efd8cd64e086e3b@dec.sakura.ne.jp> From: Warner Losh Date: Fri, 27 Dec 2024 10:51:32 -0700 Message-ID: Subject: Re: No iwm interface in current. To: Tomoaki AOKI Cc: Emmanuel Vadot , =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000b0b6fe062a441d41" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4YKY355Kyfz4DTJ X-Spamd-Bar: ---- --000000000000b0b6fe062a441d41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 27, 2024, 10:41=E2=80=AFAM Tomoaki AOKI wrote: > On Fri, 27 Dec 2024 06:59:53 -0700 > Warner Losh wrote: > > > On Fri, Dec 27, 2024, 1:53=E2=80=AFAM Emmanuel Vadot > wrote: > > > > > On Fri, 27 Dec 2024 09:43:22 +0100 > > > Emmanuel Vadot wrote: > > > > > > > > > > > Hi, > > > > > > > > On Thu, 26 Dec 2024 23:55:24 +0100 > > > > Fernando Apestegu=C3=ADa wrote: > > > > > > > > > I updated to today's current from a version from Nov 18th. > > > > > > > > > > I had these lines in loader.conf: > > > > > > > > > > iwm7265Dfw_load=3D"YES" > > > > > if_iwm_load=3D"YES" > > > > > > > > > > And with those the kernel panics. Then I saw the entry 20241216 i= n > > > > > 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=3D"YES" > > > > iwm7265Dfw_name=3D"/boot/firmware/iwm7265Dfw" > > > > iwm7265Dfw_type=3D"firmware" > > > > > > > > Cheers, > > > > > > > > -- > > > > Emmanuel Vadot > > > > > > > > > > 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 th= e > > 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 > > > -- > Tomoaki AOKI > --000000000000b0b6fe062a441d41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 27, 2024, 10:41=E2= =80=AFAM Tomoaki AOKI <junc= hoon@dec.sakura.ne.jp> wrote:
imp@bsdimp.com> wrote:

> On Fri, Dec 27, 2024, 1:53=E2=80=AFAM Emmanuel Vadot <manu@bidou= illiste.com> wrote:
>
> > On Fri, 27 Dec 2024 09:43:22 +0100
> > Emmanuel Vadot <manu@bidouilliste.com> wrote:
> >
> > >
> > >=C2=A0 Hi,
> > >
> > > On Thu, 26 Dec 2024 23:55:24 +0100
> > > Fernando Apestegu=C3=ADa <fernando.apesteguia@= gmail.com> wrote:
> > >
> > > > I updated to today's current from a version from No= v 18th.
> > > >
> > > > I had these lines in loader.conf:
> > > >
> > > > iwm7265Dfw_load=3D"YES"
> > > > if_iwm_load=3D"YES"
> > > >
> > > > And with those the kernel panics. Then I saw the entry = 20241216 in
> > > > UPDATING. Can't reproduce it here since I'm wri= ting 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 wo= rk?
> > > >
> > > > Cheers
> > >
> > >=C2=A0 Without panic trace it's hard to really know what&= #39;s going on but I
> > > think that the problem is that the firmware wasn't loade= d by loader and
> > > iwm panics since root fs isn't there yet.
> > >=C2=A0 Just removing those lines will make iwm works again or= you can use :
> > > iwm7265Dfw_load=3D"YES"
> > > iwm7265Dfw_name=3D"/boot/firmware/iwm7265Dfw"
> > > iwm7265Dfw_type=3D"firmware"
> > >
> > >=C2=A0 Cheers,
> > >
> > > --
> > > Emmanuel Vadot <manu@bidouilliste.com> <manu@f= reebsd.org>
> > >
> >
> >=C2=A0 https://reviews.freebsd.org/D48211 = will help too.
> >
> >=C2=A0 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 nee= d
> firmware until after mountroot generally.

I'm recommending (mostly on forums.freebsd.org) keepin= g
/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 though= t we'd fixed all the overflow issues... I'm generally planning a mo= re 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
=C2=A0 Root on ZFS in local diks with pool name zroot,
=C2=A0 module filesystem dataset is MODULE/default,
=C2=A0 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= 9;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.<= /div>

ESP can be ambiguous in = some cases. loaddev isn't,=C2=A0 though. It might be more helpful to al= low a limited set of env vars to be expanded in both the load path and file= s 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<= br> era. So I assume BIOS boots doesn't need such an extentions.


<= div dir=3D"auto">Bios loader gets no new features after the stable/14 featu= re set.

>
> Warnet
>
> --
> > Emmanuel Vadot <manu@bidouilliste.com> <manu@free= bsd.org>


--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>
--000000000000b0b6fe062a441d41--