Bug 690206 – sys-kernel/linux-firmware-20190712 and sys-kernel/linux-firmware-20190717 and sys-kernel/linux-firmware-20190620 are not compatible with intel wifi a370 (rev 10) wifi network doesn't work

• Status: RESOLVED OBSOLETE
• Product: Gentoo Linux

[Description Silvio 2019-07-19 07:09:09 UTC]

I have this wifi card:

00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)

and with the two firmware:

sys-kernel/linux-firmware-20190712 
sys-kernel/linux-firmware-20190717

it doesn't work. I had to downgrade to older:

sys-kernel/linux-firmware-20190603

and it works fine. I found this on the web:

https://bbs.archlinux.org/viewtopic.php?id=247575

I think these versions have to be set as "testing" and not stable (at least).

[Comment 1 Silvio 2019-07-20 08:40:24 UTC]

Even 

sys-kernel/linux-firmware-20190620

doesn't work. I have to downgrade to:

sys-kernel/linux-firmware-20190603

that work.

Here

https://bugs.archlinux.org/task/63117

there is a bad comment (Comment by loqs (loqs) - Wednesday, 17 July 2019, 19:44 GMT):

"If upstream is not aware of the issue then unless the arch kernel maintainers choose to apply a patch to the kernel locally or the linux-firmware maintainer chooses to revert the firmware update
I would expect the issue to not be resolved until the release of 5.3 which http://phb-crystal-ball.org/ estimates will be Sunday, 2019-09-15.
I lack the hardware to provide any diagnostics upstream might require so I will leave it to those affected.
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging"

[Comment 2 Thomas Deutschmann (RETIRED) 2019-07-23 01:56:46 UTC]

No, this package contains more than just your Wifi firmware. If we would mask we would cut off AMD users from a critical fix for example.

You are experiencing an incompatibility between firmware version and your kernel. Upgrade to latest 5.2.x version and your problem should be resolved.

There's nothing we can do: Like said, we cannot mask because it's not a general problem and other user will require other firmwares only available in recent versions. It's also impossible to restrict package for kernel version because we don't know which kernel version user is running and you can switch to a different version on next boot which could require a newer firmware package.

[Comment 3 Silvio 2019-07-23 12:08:22 UTC]

Two points:

1) I dont' think that is correct to put "resolved" this bug. The bug is still present and could be usefull to other people that have my wifi card (Intel! Very common!)

2) You are wrong, the problem could not be solved putting the new kernal 5.2.x as the problem is present just with the new kernel (you could be aware of it reading link I paste)

So you could workaround this bug in two ways:

1) Using OLD kernel
2) Using OLD linux-firmware

now it appears that someone test the 5.2.2 kernel made the things works.

I'll try and if ok, I'll put this bug as resolved fixed.

regards

[Comment 4 Thomas Deutschmann (RETIRED) 2019-07-23 12:35:46 UTC]

No, resolution is correct: Your reported issue from $summary is wrong. Like shown, the firmware isn't the problem. The firmware works with recent kernels. It's just an incompatibility between the firmware version you are trying to use and the kernel version you are using:

> Comment by Albert Ferrero (aferrero) - Sunday, 21 July 2019, 23:50 GMT
> I can confirm, the linux 5.2.2 kernel that's in testing appears to
> work correctly when paired with the latest firmware package.

Therefore the _reported_ bug is invalid.


I understand that this must be frustrating for you but there is nothing we can do about it. Like said, masking is _not_ an option. And even if this wouldn't work with latest kernel we would just tell you to report upstream because there's nothing we can do about it.

Firmware package is special and because we don't restrict to a specific kernel version like Debian, you are on your own. For example I would recommend to mask newer firmware packages once you found a version working with your system. On the other hand this is a bad recommendation: If you don't follow upstream you will not learn about critical fixes in new firmware versions which could make your system vulnerable. Also, once you switch to a new kernel, you could run into problems because newer kernel might require a newer firmware version...

Again: I understand _your_ problem. But from Gentoo POV there's nothing we can do. If you have an idea how we can improve please share.

I am looking forward for your 5.2.x test results.

[Comment 5 Silvio 2019-07-23 23:10:05 UTC]

(In reply to Thomas Deutschmann from comment #4)
> No, resolution is correct: Your reported issue from $summary is wrong. Like
> shown, the firmware isn't the problem. The firmware works with recent
> kernels. It's just an incompatibility between the firmware version you are
> trying to use and the kernel version you are using:

Wrong.

As I said, this had to be tested.

I tested it on hour ago and this version of firmware (20190717) doesn't work with the latest version of kernel (5.2.2). At least on Gentoo.

The only version of linux-firmware that works is still the old 20190603.

So I think this bug is needed to be left open so that other people could found a workaround (downgrading firmware or kernel).

I'll update this bug as soon as the situation will change.

regards.

Silvio

PS: Moreover I continue to think these versions of firmware has to be set "testing" and not stable, at all.

[Comment 6 Mike Pagano 2019-07-23 23:46:28 UTC]

Created attachment 584256 [details, diff]
patch: don't send GEO_TX_POWER_LIMIT on version < 41

Please apply and test against 5.2.2

[Comment 7 Mike Pagano 2019-07-23 23:48:33 UTC]

gentoo-sources-5.2.2 is what I meant

[Comment 8 Silvio 2019-07-25 20:58:47 UTC]

(In reply to Mike Pagano from comment #6)
> Created attachment 584256 [details, diff] [details, diff]
> patch: don't send GEO_TX_POWER_LIMIT on version < 41
> 
> Please apply and test against 5.2.2

Patches to linux-firmware or linux-kernel?

[Comment 9 Thomas Deutschmann (RETIRED) 2019-07-25 21:05:53 UTC]

Kernel.

[Comment 10 Silvio 2019-07-26 08:59:03 UTC]

(In reply to Thomas Deutschmann from comment #9)
> Kernel.

sys-kernel/linux-firmware-20190717
sys-kernel/gentoo-sources-5.2.2 patched

nothing changes, it doesn't work.

the gentoo-sources-5.2.2 patched with linux-firmware-20190603 works (as wwith the normal kernel)

just to be sure,

1) I put your patch in a new directory: 
/etc/portage/patches/sys-kernel/gentoo-sources-5.2.2/

2) I made:

emerge -1v gentoo-sources

(I got the message that it was using your patch)

3) I went to /usr/src/linux (linked on 5.2.2)

4) I did
make clean
make -j9 all
make modules_install
make install

5) I installed the updated firmare (removing masking)

emerge -1v linux-firmware


6) I rebooted


the system had wifi not working.
As soon as I re-emerged old linux-firmware the wifi began to work without rebooting and I'm here.

Let me know if I have to make more tests.

thanks

[Comment 11 Silvio 2019-08-06 21:38:50 UTC]

I just tried with:
gentoo-sources-5.2.6
sys-kernel/linux-firmware-20190726-r2

and the problem is still there.

I had to mask also this version of linux-firmware to make it works.

In the thread I linked before someone said we have to wait 5.3 kernel in September to remove this bug.

[Comment 12 Georgy Yakovlev 2019-08-06 23:16:46 UTC]

you can use savedconfig flag for linux-firmware and disable installing problematic firmware files altogether.

removing offending lines from /etc/portage/savedconfig/sys-kernel/linux-firmware-xxxxxxx, enabling savedconfig flag for linux-firmware, and re-emerging should do the trick.

you can copy that file to less specific location, for example /etc/portage/savedconfig/sys-kernel/linux-firmware

or other:
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PF}
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PF}
/etc/portage/savedconfig/${CATEGORY}/${PF}
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${P}
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
/etc/portage/savedconfig/${CATEGORY}/${P}
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
/etc/portage/savedconfig/${CATEGORY}/${PN}


and portage will always use that config depending on matching package atom.


that way you still get updates for other firmwares and have your firmware unchanged.

[Comment 13 Silvio 2019-09-09 08:26:27 UTC]

Solved with 20190904 version.