From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6F076139083 for ; Mon, 18 Dec 2017 07:33:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 15186E0F24; Mon, 18 Dec 2017 07:33:19 +0000 (UTC) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AA183E0F1C for ; Mon, 18 Dec 2017 07:33:18 +0000 (UTC) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 04D934CB91 for ; Mon, 18 Dec 2017 08:33:15 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id GD_HIPDpBIGb for ; Mon, 18 Dec 2017 08:33:01 +0100 (CET) Date: Mon, 18 Dec 2017 08:33:00 +0100 From: Floyd Anderson To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Loading a Firmware Module By hand? Message-ID: <20171218073300.2e37d75bey4ovalh@31c0.net> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20171217092840.GA1759@starlite> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Archives-Salt: 7cfc389f-db27-40ab-b3f3-8bde7bf0ad67 X-Archives-Hash: 2f8c4151d5f09a323ac09c6546a123bd On Mon, 18 Dec 2017 05:11:20 +0000 Hunter Jozwiak wrote: >On 12/17/17, Andrey Utkin wrote: >> On Sun, Dec 17, 2017 at 12:34:14AM -0500, Hunter Jozwiak wrote: >>> Hi, >>> >>> I have an ath10k_pci device that I'm trying to get hooked to the >>> Internet, but I'm having some strange issues. It is trying to load the >>> 2.1 firmware, but I don't think that is the proper firmware for the >>> interface to have; I think it ought to be loading the 3.0 module, but >>> am not quite sure on that either, or how I could go about injecting >>> that into the modprobe; I wasn't able to pinpoint the firmware blob >>> the ISO was using, so that wasn't much of a pointer in the right >>> direction either. I see that the 3.0 blob does exist in >>> /lib/firmware/ath10k/QCABLEFAGD/HW3.0, but there are many bin files, >> >> I have little to no idea about your actual case... But could it be that >> you have a recent linux-firmware package (which provides /lib/firmware/ >> files) and not recent enough kernel? I think kernel is what decides >> which firmware file to load. >> > !!! rearranged top-posting !!! >Hmm. I have kernel 4.14.7 and linux-firmware 20171206. I tried version >999999999 as well, but that didn't help matters, either. Nor did >compiling the firmware into the kernel; either 4.14 is too old, or it >is too new. I tried copying the firmware my live iso was using, but >that didn't help either. > I think you are a little bit too vague in your given info. If you don’t show your firmware related kernel settings (those lines posted by Mick earlier) nor what dmesg said about the firmware loading success of your specified config, people tends to think you know what you are doing and therefore may eliminate any errors based on syntactical mistakes or similar from their thoughts. For instance, you wrote “It is trying to load the 2.1 firmware” but because trying != loaded successfully, nobody knows if 2.1 works or has been failed (and why), so you have a need to try the 3.0 blob. As Mick pointed out, look what is in your dmesg log and communicate that (not only your own interpretation of it). Maybe there’s another module configured that also supports and loads the 2.1 blob so it must be blacklisted [1] or not built at all. Also the firmware must be available on boot and module load, so a probably used initramfs must include it as long as it is not built into the kernel. [1] -- Regards, floyd