Hi,
while debugging a reported rtw89 issue
https://bugzilla.suse.com/show_bug.cgi?id=1212808
we noticed that rtw89 driver didn't load the firmware properly.
And, this turned out that it's because the driver uses
request_partial_firmware_into_buf() function with the combination of
compressed firmware files (that are standard on some distros like
openSUSE).
It's a known limitation of the request_partial_firmware_into_buf() API
function itself; it won't load compressed files, because otherwise
it'd have to read the full data. That said, the use of
request_partial_*() should be only for very limited use cases, and
this doesn't look fitting well for rtw89.
(And, as usual, the information is missing in the documentation :-<
The API document should state it clearly; I'm going to submit a patch
to add the information.)
There was already a workaround for CONFIG_SECURIY_LOADPIN_ENFORCE for
a similar problem, but such a fallback is required in general for all
cases, as it seems.
I can cook a hackish patch for the fallback, but I wonder whether it
still makes sense to keep the use of that API function. rtw89 is the
only driver except for bcm-vk (where the API was introduced just for
this driver), after all...
thanks,
Takashi
On 7/17/23 10:02, Takashi Iwai wrote:
> Hi,
>
> while debugging a reported rtw89 issue
> https://bugzilla.suse.com/show_bug.cgi?id=1212808
> we noticed that rtw89 driver didn't load the firmware properly.
>
> And, this turned out that it's because the driver uses
> request_partial_firmware_into_buf() function with the combination of
> compressed firmware files (that are standard on some distros like
> openSUSE).
> It's a known limitation of the request_partial_firmware_into_buf() API
> function itself; it won't load compressed files, because otherwise
> it'd have to read the full data. That said, the use of
> request_partial_*() should be only for very limited use cases, and
> this doesn't look fitting well for rtw89.
> (And, as usual, the information is missing in the documentation :-<
> The API document should state it clearly; I'm going to submit a patch
> to add the information.)
>
> There was already a workaround for CONFIG_SECURIY_LOADPIN_ENFORCE for
> a similar problem, but such a fallback is required in general for all
> cases, as it seems.
>
> I can cook a hackish patch for the fallback, but I wonder whether it
> still makes sense to keep the use of that API function. rtw89 is the
> only driver except for bcm-vk (where the API was introduced just for
> this driver), after all...
Takashi,
I am trying to duplicate the OPs problem in boo#1212808. I am currently running
with an RTW8851BE, thus I must use kernel 6.5-rc2, or the repo at
https://github.com/lwfinger/rtw89.git, which is the source for the Hardware
entry at openSUSE. The firmware loading code is common for my chip and the
RTW8852BE in the bugzilla entry. In my dmesg output, I see the following:
[ 160.142412] rtw89_8851be 0000:02:00.0: Direct firmware load for
rtw89/rtw8851b_fw.bin failed with error -2
[ 160.142418] rtw89_8851be 0000:02:00.0: failed to early request firmware: -2
[ 160.170098] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd
version 0, type 5
[ 160.170103] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd
version 0, type 3
[ 160.505451] rtw89_8851be 0000:02:00.0: chip rfe_type is 1
[ 160.551131] rtw89_8851be 0000:02:00.0 wls1: renamed from wlan0
The first attempt fails, but the second works. The firmware file in question is
xz compressed. This result was obtained with the in-kernel version of the driver.
All of this was done using Tumbleweed. My next step will be to try Leap 15.5 and
Leap 15.4. I will report those tests later.
Larry
On 7/17/23 10:02, Takashi Iwai wrote:
> Hi,
>
> while debugging a reported rtw89 issue
> https://bugzilla.suse.com/show_bug.cgi?id=1212808
> we noticed that rtw89 driver didn't load the firmware properly.
>
> And, this turned out that it's because the driver uses
> request_partial_firmware_into_buf() function with the combination of
> compressed firmware files (that are standard on some distros like
> openSUSE).
> It's a known limitation of the request_partial_firmware_into_buf() API
> function itself; it won't load compressed files, because otherwise
> it'd have to read the full data. That said, the use of
> request_partial_*() should be only for very limited use cases, and
> this doesn't look fitting well for rtw89.
> (And, as usual, the information is missing in the documentation :-<
> The API document should state it clearly; I'm going to submit a patch
> to add the information.)
>
> There was already a workaround for CONFIG_SECURIY_LOADPIN_ENFORCE for
> a similar problem, but such a fallback is required in general for all
> cases, as it seems.
>
> I can cook a hackish patch for the fallback, but I wonder whether it
> still makes sense to keep the use of that API function. rtw89 is the
> only driver except for bcm-vk (where the API was introduced just for
> this driver), after all...
Takashi,
I have completed my tests of Leap 15.5. I had to manually copy the firmware for
the 8851BE to /lib/firmware/rtw89, but once I did that, the following was logged:
[ 1572.450392] rtw89_8851be 0000:02:00.0: Direct firmware load for
rtw89/rtw8851b_fw.bin failed with error -2
[ 1572.450397] rtw89_8851be 0000:02:00.0: failed to early request firmware: -2
[ 1572.470196] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd
version 0, type 5
[ 1572.470204] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0, cmd
version 0, type 3
[ 1572.801867] rtw89_8851be 0000:02:00.0: chip rfe_type is 1
[ 1572.842343] rtw89_8851be 0000:02:00.0 wlan2: renamed from wlan1
This result was obtained with kernel 5.14.21-150500.53-default.
Yes, the request_partial_firmware_into_buf() failed, but the next attempt
succeeded. The firmware in question was xz-compressed.
I cannot duplicate the OP's result. I will try next with Leap 15.4, but I do not
expect a different result.
Larry
On Mon, 17 Jul 2023 22:25:34 +0200,
Larry Finger wrote:
>
> On 7/17/23 10:02, Takashi Iwai wrote:
> > Hi,
> >
> > while debugging a reported rtw89 issue
> > https://bugzilla.suse.com/show_bug.cgi?id=1212808
> > we noticed that rtw89 driver didn't load the firmware properly.
> >
> > And, this turned out that it's because the driver uses
> > request_partial_firmware_into_buf() function with the combination of
> > compressed firmware files (that are standard on some distros like
> > openSUSE).
> > It's a known limitation of the request_partial_firmware_into_buf() API
> > function itself; it won't load compressed files, because otherwise
> > it'd have to read the full data. That said, the use of
> > request_partial_*() should be only for very limited use cases, and
> > this doesn't look fitting well for rtw89.
> > (And, as usual, the information is missing in the documentation :-<
> > The API document should state it clearly; I'm going to submit a patch
> > to add the information.)
> >
> > There was already a workaround for CONFIG_SECURIY_LOADPIN_ENFORCE for
> > a similar problem, but such a fallback is required in general for all
> > cases, as it seems.
> >
> > I can cook a hackish patch for the fallback, but I wonder whether it
> > still makes sense to keep the use of that API function. rtw89 is the
> > only driver except for bcm-vk (where the API was introduced just for
> > this driver), after all...
>
> Takashi,
>
> I am trying to duplicate the OPs problem in boo#1212808. I am
> currently running with an RTW8851BE, thus I must use kernel 6.5-rc2,
> or the repo at https://github.com/lwfinger/rtw89.git, which is the
> source for the Hardware entry at openSUSE. The firmware loading code
> is common for my chip and the RTW8852BE in the bugzilla entry. In my
> dmesg output, I see the following:
>
> [ 160.142412] rtw89_8851be 0000:02:00.0: Direct firmware load for
> rtw89/rtw8851b_fw.bin failed with error -2
> [ 160.142418] rtw89_8851be 0000:02:00.0: failed to early request firmware: -2
> [ 160.170098] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0,
> cmd version 0, type 5
> [ 160.170103] rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.0,
> cmd version 0, type 3
> [ 160.505451] rtw89_8851be 0000:02:00.0: chip rfe_type is 1
> [ 160.551131] rtw89_8851be 0000:02:00.0 wls1: renamed from wlan0
>
> The first attempt fails, but the second works. The firmware file in
> question is xz compressed. This result was obtained with the in-kernel
> version of the driver.
Thanks Larry, but I guess that it happens only for multi versions such
as rtw8852b that have rtw8852a_fw.bin and rtw8852a_fw-1.bin, while
yours is rtw8851b that has only one firmware version.
And, the driver might look as if still "working". IIUC, it's only
that the new firmware version won't be used as long as the firmware
files are compressed.
You can see more details by passing firmware_class.dyndbg=+p boot
option.
> All of this was done using Tumbleweed. My next step will be to try
> Leap 15.5 and Leap 15.4. I will report those tests later.
Note that the problem of the firmware loader is likely irrelevant with
the actual issue in the bugzilla entry above; I only gave as a
reference.
It seems that the bug there was due to the error:
rtw89_8852be 0000:02:00.0: [ERR]pci config read 719
rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22
rtw89_8852be 0000:02:00.0: failed to setup chip information
Since reloading the module works, this might be related with the PCI
power state or something else. But it's a different topic from this
thread, which is about the firmware loader problem.
Takashi
On 7/18/23 00:33, Takashi Iwai wrote:
>
> Thanks Larry, but I guess that it happens only for multi versions such
> as rtw8852b that have rtw8852a_fw.bin and rtw8852a_fw-1.bin, while
> yours is rtw8851b that has only one firmware version.
>
> And, the driver might look as if still "working". IIUC, it's only
> that the new firmware version won't be used as long as the firmware
> files are compressed.
>
> You can see more details by passing firmware_class.dyndbg=+p boot
> option.
>
>> All of this was done using Tumbleweed. My next step will be to try
>> Leap 15.5 and Leap 15.4. I will report those tests later.
>
> Note that the problem of the firmware loader is likely irrelevant with
> the actual issue in the bugzilla entry above; I only gave as a
> reference.
>
> It seems that the bug there was due to the error:
>
> rtw89_8852be 0000:02:00.0: [ERR]pci config read 719
> rtw89_8852be 0000:02:00.0: [ERR] pcie autok fail -22
> rtw89_8852be 0000:02:00.0: failed to setup chip information
>
> Since reloading the module works, this might be related with the PCI
> power state or something else. But it's a different topic from this
> thread, which is about the firmware loader problem.
Takashi,
When I switched my NIC to an RTW8852BE, which does have 2 versions of the
firmware, I still got a successful firmware load for Tumbleweed running the new
kernel 6.4.3-1, on Leap 15.5, and on Leap 15.4. The only problem was that file
rtw8852b_fw.bin.xz is loaded, and not the newer rtw8852b_fw-1.bin.xz, which is
preferable. This was try for the drivers in kernel 6.4.3, 6.5.0-rc2, and in the
GitHub repo.
When I stripped the code in rtw89_early_fw_feature_recognize() to never try to
run request_partial_firmware_into_buf(), then the newest firmware is loaded. The
logs showed the following:
[ 834.438601] firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw.bin
fw_priv=000000000849addc data=00000000fd3cabe2 size=1035232
[ 834.438658] firmware_class: fw_name_devm_release:
fw_name-rtw89/rtw8852b_fw.bin devm-000000002d8c3343 released
[ 846.992333] firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw-1.bin
fw_priv=000000009e1a6364
[ 846.992352] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such
file or directory.
[ 846.992357] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/rtw89/rtw8852b_fw-1.bin failed for no such file or directory.
[ 846.992361] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such file or
directory.
[ 846.992366] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/rtw89/rtw8852b_fw-1.bin failed for no such file or directory.
[ 846.992371] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no
such file or directory.
[ 846.992375] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or
directory.
[ 846.992378] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no such
file or directory.
[ 846.992391] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory.
[ 846.992396] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no
such file or directory.
[ 846.992399] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or
directory.
[ 846.992402] rtw89_8852be 0000:02:00.0: loading
/lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no such file
or directory.
[ 846.997453] rtw89_8852be 0000:02:00.0: Loading firmware from
/lib/firmware/rtw89/rtw8852b_fw-1.bin.xz
[ 846.997456] rtw89_8852be 0000:02:00.0: f/w decompressing rtw89/rtw8852b_fw-1.bin
[ 847.014261] firmware_class: fw_set_page_data: fw-rtw89/rtw8852b_fw-1.bin
fw_priv=000000009e1a6364 data=00000000fd3cabe2 size=1184992
[ 847.019276] rtw89_8852be 0000:02:00.0: Loaded FW: rtw89/rtw8852b_fw-1.bin,
sha256: 8539efc75f513f4585cf0cd6e79e6507da47fce87225f2d0de391a03aefe9ac8
[ 847.019280] rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
[ 847.021436] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd
version 0, type 5
[ 847.021442] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd
version 0, type 3
[ 847.362658] rtw89_8852be 0000:02:00.0: chip rfe_type is 1
[ 847.397754] rtw89_8852be 0000:02:00.0 wls1: renamed from wlan0
I want Ping-Ke to look at my patch. If he agrees, I will push it to GitHub, and
it will be picked up in the openSUSE repos for 15.4 and 15.5.
Larry