From nobody Fri Dec 27 17:41:17 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 4YKXqV2RjNz5j5Gl for ; Fri, 27 Dec 2024 17:41:42 +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 4YKXqT6lWMz48l7 for ; Fri, 27 Dec 2024 17:41:41 +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 4BRHfIIb004883; Sat, 28 Dec 2024 02:41:18 +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=1735321280; bh=1+tpEArqFyN4fdPlJoeE3q5I4gzmFMhQ/+nxy/L/UgQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=P+fRTY9nJKNwCFbhe4uB/Pxkqg/GgvIWrDUjm3unu9HIJDqwgsnWm2jL/GT6km0ri 4+mcPsOlQq7lKjB18fiIR0YKW9tr1mlcTUa1szeoWhavT3H6X7RJEXf+Jkv9hLd/st ePlUuwNektsYlNDow7O+SkHRHAslVlSqivxsdywg= Date: Sat, 28 Dec 2024 02:41:17 +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: <20241228024117.183fcc3c7efd8cd64e086e3b@dec.sakura.ne.jp> In-Reply-To: References: <20241227094322.64a88d47bc806904f40a51d3@bidouilliste.com> <20241227095321.a8309bd2512b9d43f944e530@bidouilliste.com> 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: 4YKXqT6lWMz48l7 X-Spamd-Bar: ---- 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. > 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. 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/". 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. > > Warnet > > -- > > Emmanuel Vadot -- Tomoaki AOKI