From nobody Sat Dec 28 03:47:10 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 4YKpGR2hNgz5jrfl for ; Sat, 28 Dec 2024 03:47:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YKpGQ5Pbpz4VBt for ; Sat, 28 Dec 2024 03:47:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4BS3lAfn053208; Sat, 28 Dec 2024 12:47:12 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1735357633; bh=vENb3Ehw+mdNRAs898NIbyAY4kMUuoXZ2+yWmqq9fUI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=cfx8xqx/lz7QuhygSYlUe+7J4RKWPlrqZVPLsIQBq4MvhOLWSiYokb/JcDve6JPVs 0sFJ5iGcBH/+OwsPV1DcycjhG6KadGOXooBl7b4aw3029KUwarCW/z2/WA4RvyN26I gy2UF5nXYH+ZsxrZoTj8JgOAzbVCWNecsgXw6w1E= Date: Sat, 28 Dec 2024 12:47:10 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Emmanuel Vadot , Fernando =?UTF-8?B?QXBlc3Rl?= =?UTF-8?B?Z3XDrWE=?= , FreeBSD Hackers Subject: Re: No iwm interface in current. Message-Id: <20241228124710.03b6ea03756f06008972838f@dec.sakura.ne.jp> In-Reply-To: References: <20241227094322.64a88d47bc806904f40a51d3@bidouilliste.com> <20241227095321.a8309bd2512b9d43f944e530@bidouilliste.com> <20241228024117.183fcc3c7efd8cd64e086e3b@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4YKpGQ5Pbpz4VBt X-Spamd-Bar: ---- On Fri, 27 Dec 2024 10:51:32 -0700 Warner Losh wrote: > On Fri, Dec 27, 2024, 10:41 AM Tomoaki AOKI > wrote: > > > On Fri, 27 Dec 2024 06:59:53 -0700 > > Warner Losh wrote: > > > > > On Fri, Dec 27, 2024, 1:53 AM 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ía 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 > > > > > > > > > > > > > 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 > > > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI