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
(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. 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 (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? 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. (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. 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. |