Bug 1326591

Summary:	iwlwifi wants a newer version of firmware, iwlwifi-7265D-19.ucode
Product:	[Fedora] Fedora	Reporter:	Chris Smart <fedora>
Component:	linux-firmware	Assignee:	David Woodhouse <dwmw2>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	23	CC:	dwmw2, emmanuel.grumbach, jforbes, kernel-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-16 12:03:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Smart 2016-04-13 07:50:14 UTC

Description of problem:

The 4.4.6-300 kernel is actually looking for version iwlwifi-7265D-19.ucode of the firmware, but it doesn't exist. It falls back to version 16.

When connecting to some busy corporate networks I've noticed that wifi gets into a state where no more packets will be sent, although it remains associated.

The wifi device is:

04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

After installing iwlwifi-7265D-19.ucode from upstream linux-firmware the problem seems to disappear.

Given that the kernel module wants version 19, is it possible to update linux-firmware?

How reproducible:
It's hard to re-produce the wifi problem, but the kernel wanting version 19 is easy to see, just check with dmesg on a machine with a 7265 Intel wifi device (or presumably lots of other Intel models).

Steps to Reproduce:
1. dmesg |grep iwlwifi

Actual results:
Kernel looks for latest firmware but fails, falls back to version 16, dmesg:
[   11.925956] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-7265D-19.ucode failed with error -2
[   11.925974] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-7265D-18.ucode failed with error -2
[   11.925987] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-7265D-17.ucode failed with error -2
[   11.989003] iwlwifi 0000:04:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm
[   12.058616] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210

Expected results:
Kernel loads correct firmware version, dmesg:

[160060.229823] Intel(R) Wireless WiFi driver for Linux
[160060.229825] Copyright(c) 2003- 2015 Intel Corporation
[160060.231971] iwlwifi 0000:04:00.0: loaded firmware version 19.313137.0 op_mode iwlmvm
[160060.295444] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210

Comment 1 Josh Boyer 2016-04-13 11:25:29 UTC

(In reply to Chris Smart from comment #0)
> Description of problem:
> 
> The 4.4.6-300 kernel is actually looking for version iwlwifi-7265D-19.ucode
> of the firmware, but it doesn't exist. It falls back to version 16.
> 
> When connecting to some busy corporate networks I've noticed that wifi gets
> into a state where no more packets will be sent, although it remains
> associated.
> 
> The wifi device is:
> 
> 04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
> 
> After installing iwlwifi-7265D-19.ucode from upstream linux-firmware the
> problem seems to disappear.

That file doesn't exist in the upstream linux-firmware repository.  Can you point me to where you got it from?  Upstream has iwlwifi-7265D-16.ucode and iwlwifi-7265D-21.ucode.

> Given that the kernel module wants version 19, is it possible to update
> linux-firmware?

Well, if it was upstream yes.  But it isn't.  We have an updated build that has the latest here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=747195

You could test that.

> How reproducible:
> It's hard to re-produce the wifi problem, but the kernel wanting version 19
> is easy to see, just check with dmesg on a machine with a 7265 Intel wifi
> device (or presumably lots of other Intel models).

Using newer firmware isn't guaranteed to really fix anything, but it is worth trying.  Just don't get your hopes up.

Comment 2 Chris Smart 2016-04-13 11:55:35 UTC

OK, yes I'll see if longer term the problem disappears wit the newer firmware.

I got it from here:

git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git

It has:
iwlwifi-7265-10.ucode
iwlwifi-7265D-12.ucode
iwlwifi-7265D-13.ucode
iwlwifi-7265D-14.ucode
iwlwifi-7265D-15.ucode
iwlwifi-7265D-16.ucode
iwlwifi-7265D-17.ucode
iwlwifi-7265D-18.ucode
iwlwifi-7265D-19.ucode
iwlwifi-7265D-20.ucode
iwlwifi-7265D-21.ucode

Thanks,
-c

Comment 3 Josh Boyer 2016-04-13 12:33:31 UTC

(In reply to Chris Smart from comment #2)
> OK, yes I'll see if longer term the problem disappears wit the newer
> firmware.
> 
> I got it from here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git

Ah, ok.  That's the intel specific tree.  The 'for-kyle' branch in that repo is what gets synced to the upstream linux-firmware repo, which is what Fedora builds from. 

> It has:
> iwlwifi-7265-10.ucode
> iwlwifi-7265D-12.ucode
> iwlwifi-7265D-13.ucode
> iwlwifi-7265D-14.ucode
> iwlwifi-7265D-15.ucode
> iwlwifi-7265D-16.ucode
> iwlwifi-7265D-17.ucode
> iwlwifi-7265D-18.ucode
> iwlwifi-7265D-19.ucode
> iwlwifi-7265D-20.ucode
> iwlwifi-7265D-21.ucode

Right.  However, not all of those are synced upstream.

Emmanuel, seems -19 and -20 were skipped.  Should they have gone to Kyle?

Comment 4 Emmanuel Grumbach 2016-04-13 12:36:07 UTC

No. We release a new firmware every 6 weeks. It makes little sense to deliver a new firmware to Kyle every time.
Indeed, 19 and 20 were skipped. Actually, we jumped from 16 to 21.

Comment 5 Josh Boyer 2016-04-13 13:13:48 UTC

(In reply to Emmanuel Grumbach from comment #4)
> No. We release a new firmware every 6 weeks. It makes little sense to
> deliver a new firmware to Kyle every time.
> Indeed, 19 and 20 were skipped. Actually, we jumped from 16 to 21.

Hm, ok.  That is good to know.  Though it is somewhat misleading users if the kernel is looking for firmware versions that are never "released" upstream.  E.g. 4.4.y kernels start with -19.ucode, and 4.5.y start with -20.ucode.  Neither will ever be available in-distro.

Is it possible to only bump the *_UCODE_API_OK defines in the driver to versions that are actually "upstream"?  My original thought was simply to not emit the printk about it not being found, but that is done by the base firmware driver and the knowledge of what is OK to be missing is driver specific.  Somehow keeping the firmware level in the drive in-sync with the firmware that is shipped might be preferable.

Comment 6 Emmanuel Grumbach 2016-04-13 13:17:39 UTC

We don't know in advance what firmware will be released and the kernel is typically closed for submission way earlier than the firmware release, so that my incentive to have the kernel API number the highest it can cope with so that I have all the options possible.