Missing firmware iwlwifi-2030-5.ucode
Hi,
I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9, who has an Intel 802.11 b/g/n card with Bluetooth mounted in an HP dvdt-7000 Quad Edition Series computer.
The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however, that particular file does not exist in /lib/firmware, nor is in the linux-firmware git repo where only the version 6 firmware exists.
I could find no record of the firmware ever being in the git repo, nor could I find it using a Google search. For users of kernel 3.1, I request that this firmware file be submitted to linux-firmware. In addition, if you send me a copy of the file, I will see that the OP on the openSUSE Forum gets a copy.
Thanks,
Larry
16.08.2012 18:06, Larry Finger skrev:
Quoted 10 lines
Hi,
I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9, who has an Intel 802.11 b/g/n card with Bluetooth mounted in an HP dvdt-7000 Quad Edition Series computer.
The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however, that particular file does not exist in
/lib/firmware, nor is in the linux-firmware git repo where only the version 6 firmware exists.
Quoted 6 lines
I could find no record of the firmware ever being in the git repo, nor could I find it using a Google search. For users of kernel 3.1, I request that this firmware file be submitted to linux-firmware. In addition, if you send me a copy of the file, I will see that the OP on the openSUSE Forum gets a copy.
You need atleast:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=37273f55830f0919d543250d191e1633ff53841c
If this is a distro kernel, you probably need theese too:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=13cb8e3a067538c5aacc846a032985d2b608bccd
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=20d6f19dca576a671ab61403c366c7154f802b36
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=9e8ed57850a9d5157430fb09161a2456171d8684
--
Thomas
Hi Larry,
Quoted 4 lines
I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9, who has an Intel 802.11 b/g/n card with Bluetooth mounted in an HP dvdt-7000 Quad Edition Series computer.
Quoted 8 lines
The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however, that particular file does not exist in
/lib/firmware, nor is in the linux-firmware git repo where only the version 6 firmware exists.I could find no record of the firmware ever being in the git repo, nor could I find it using a Google search. For users of kernel 3.1, I request that this firmware file be submitted to linux-firmware. In addition, if you send me a copy of the file, I will see that the OP on the openSUSE Forum gets a copy.
Unfortunately, I can't just release this firmware, it was mostly internal experimental builds, we released the -6 version later. However, as Thomas pointed out, it should be possible to backport some patches to make the driver in 3.1.9 work with the device, that simply wasn't a concern for us and it's not entirely clear to me that such patches are candidates for stable.
johannes
On 08/20/2012 05:45 AM, Johannes Berg wrote:
Johannes,
Quoted 6 lines
Unfortunately, I can't just release this firmware, it was mostly internal experimental builds, we released the -6 version later. However, as Thomas pointed out, it should be possible to backport some patches to make the driver in 3.1.9 work with the device, that simply wasn't a concern for us and it's not entirely clear to me that such patches are candidates for stable.
The openSUSE user has gotten his system working by installing the compat-wireless package. I do not know if he could patch and compile his own kernel, and I don't have that device in my collection, thus I would be unable to test any such changes.
I'm still concerned about the bigger picture. I can understand that the -5 version was experimental, but why was a driver released that needed a firmware version that could never be obtained? If any driver version needs a particular firmware, the fw must be available as long as anyone might be using that driver. To me, that means forever.
Larry
Quoted 5 lines · Larry Finger
I'm still concerned about the bigger picture. I can understand that the -5 version was experimental, but why was a driver released that needed a firmware version that could never be obtained? If any driver version needs a particular firmware, the fw must be available as long as anyone might be using that driver. To me, that means forever.
Well, yes. That firmware, however, never was never available publicly. The fact that the driver was released anyway is due to us working on the driver upstream while working with the experimental internal firmware.
johannes
Quoted 8 lines · Johannes Berg
Quoted 5 lines · Larry Finger
I'm still concerned about the bigger picture. I can understand that the -5 version was experimental, but why was a driver released that needed a firmware version that could never be obtained? If any driver version needs a particular firmware, the fw must be available as long as anyone might be using that driver. To me, that means forever.
Quoted 5 lines
Well, yes. That firmware, however, never was never available publicly. The fact that the driver was released anyway is due to us working on the driver upstream while working with the experimental internal firmware.
johannes
Perhaps we should add a Kconfig option to disable internal development hardware - with that option unchecked, support for hardware that is not on the market is disabled, with a printk warning to upgrade the driver in case a user tries to use a driver with a card that it thinks is internal-only. This way, users will get a meaningful error message, rather than a misleading "missing firmware" one.
The Kconfig option should also come with a big warning of "Say N unless you are an Intel employee". Maybe it should even be marked BROKEN, like N-PHY was in b43 before it became usable.
Quoted 16 lines · Gábor Stefanik
Quoted 8 lines · Johannes Berg
Quoted 5 lines · Larry Finger
I'm still concerned about the bigger picture. I can understand that the -5 version was experimental, but why was a driver released that needed a firmware version that could never be obtained? If any driver version needs a particular firmware, the fw must be available as long as anyone might be using that driver. To me, that means forever.
Quoted 5 lines
Well, yes. That firmware, however, never was never available publicly. The fact that the driver was released anyway is due to us working on the driver upstream while working with the experimental internal firmware.
johannes
Quoted 9 lines
Perhaps we should add a
Kconfigoption to disable internal development hardware - with that option unchecked, support for hardware that is not on the market is disabled, with a printk warning to upgrade the driver in case a user tries to use a driver with a card that it thinks is internal-only. This way, users will get a meaningful error message, rather than a misleading "missing firmware" one.
TheKconfigoption should also come with a big warning of "Say N unless you are an Intel employee". Maybe it should even be marked BROKEN, like N-PHY was in b43 before it became usable.
Your suggestion would handle the case where hardware that is only supposed to be available internally has somehow been leaked to the public. In the case of the 2030, it is a device that was intended to be available to the public, and I suspect that Windows and OS X drivers were available with built-in firmware.
My feeling is that the reviewers will need to watch the situation. I certainly plan to monitor every Intel patch for a firmware change, and I will NACK every instance for which that firmware file is not already in linux-firmware. John might not honor my NACK; however, I will be on record. At least Ben Hutchings caught the attempt to delete the older version of the firmware for the 6205. His diligence saved some users of older kernels from having to scramble to find firmware not in the firmware repo.
Larry
Quoted 14 lines · Larry Finger
Quoted 4 lines
Quoted 3 lines
Well, yes. That firmware, however, never was never available publicly. The fact that the driver was released anyway is due to us working on the driver upstream while working with the experimental internal firmware.
Quoted 9 lines
Perhaps we should add a
Kconfigoption to disable internal development hardware - with that option unchecked, support for hardware that is not on the market is disabled, with a printk warning to upgrade the driver in case a user tries to use a driver with a card that it thinks is internal-only. This way, users will get a meaningful error message, rather than a misleading "missing firmware" one.
TheKconfigoption should also come with a big warning of "Say N unless you are an Intel employee". Maybe it should even be marked BROKEN, like N-PHY was in b43 before it became usable.
Quoted 4 lines
Your suggestion would handle the case where hardware that is only supposed to be available internally has somehow been leaked to the public. In the case of the 2030, it is a device that was intended to be available to the public, and I suspect that Windows and OS X drivers were available with built-in firmware.
Yes, that was likely the case. Except there are no OS X drivers at all :-)
Quoted 4 lines
My feeling is that the reviewers will need to watch the situation. I certainly plan to monitor every Intel patch for a firmware change, and I will NACK every instance for which that firmware file is not already in linux-firmware. John might not honor my NACK; however, I will be on record.
You're free to, of course, but I don't think we've ever (intentionally) changed the driver from working with a released firmware image to working only with unreleased firmware images. In fact, this is the reason we have firmware versions and try to load multiple versions, so we can begin working on a newer version internally while the driver continues to work with older, released versions.
The situation with 2030 devices was different: we worked on a driver and submitted code into the kernel that given the right firmware could work with the device. I don't remember, but we may even have thought at the time that we'd release the -5 firmware version, but then had to use -6. There was definitely a chance that we could release the right firmware version and thereby make the previously submitted code work. As it turns out, we couldn't or didn't (and that we've released a -6 one I can't just release another one), but that wasn't necessarily something anyone would have known at the time we submitted the code.
So I guess we could simply not submit the code before the firmware was released, but it would really just have the same effect on users that the released code has now -- their old kernel doesn't work with the device. Today, it's because we ended up releasing the wrong firmware, if we didn't release the code before the firmware it would be because they didn't have any driver code at all. I don't see how that would help.
Quoted 4 lines
At least Ben Hutchings
caught the attempt to delete the older version of the firmware for the 6205. His diligence saved some users of older kernels from having to scramble to find firmware not in the firmware repo.
Yes, that was indeed a mistake. I guess I got over-excited with the new firmware being available :-) Different situation though.
johannes
Quoted 1 line
Quoted 1 line
Your suggestion would handle the case where hardware that is only
supposed to be
Quoted 1 line
Quoted 1 line
available internally has somehow been leaked to the public. In the case
of the
Quoted 1 line
Quoted 1 line
2030, it is a device that was intended to be available to the public,
and I
Quoted 1 line
Quoted 1 line
suspect that Windows and OS X drivers were available with built-in
firmware.
Quoted 5 lines
Yes, that was likely the case. Except there are no OS X drivers at all
Quoted 1 line
My feeling is that the reviewers will need to watch the situation. I
certainly
Quoted 1 line
Quoted 1 line
plan to monitor every Intel patch for a firmware change, and I will NACK
every
Quoted 1 line
Quoted 1 line
instance for which that firmware file is not already in linux-firmware.
John
Quoted 19 lines
Quoted 1 line
might not honor my NACK; however, I will be on record.
You're free to, of course, but I don't think we've ever (intentionally) changed the driver from working with a released firmware image to working only with unreleased firmware images. In fact, this is the reason we have firmware versions and try to load multiple versions, so we can begin working on a newer version internally while the driver continues to work with older, released versions.
The situation with 2030 devices was different: we worked on a driver and submitted code into the kernel that given the right firmware could work with the device. I don't remember, but we may even have thought at the time that we'd release the -5 firmware version, but then had to use -6. There was definitely a chance that we could release the right firmware version and thereby make the previously submitted code work. As it turns out, we couldn't or didn't (and that we've released a -6 one I can't just release another one), but that wasn't necessarily something anyone would have known at the time we submitted the code.
Quoted 9 lines
So I guess we could simply not submit the code before the firmware was released, but it would really just have the same effect on users that the released code has now -- their old kernel doesn't work with the device. Today, it's because we ended up releasing the wrong firmware, if we didn't release the code before the firmware it would be because they didn't have any driver code at all. I don't see how that would help.
Quoted 2 lines
At least Ben Hutchings
caught the attempt to delete the older version of the firmware for the
6205. His
Quoted 1 line
Quoted 1 line
diligence saved some users of older kernels from having to scramble to
find
Quoted 9 lines
Quoted 1 line
firmware not in the firmware repo.
Yes, that was indeed a mistake. I guess I got over-excited with the new firmware being available Different situation though.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
Quoted 4 lines
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html
HI,
I am sorry, I cannot really understand why the iwlwifi -2030-5.ucode firmware has been removed, just leave it there along with the -6 version for people that might need it ! I respect your work, but I am loosing my mental health in order to find it and I really need it, I must use MeeGo, a system that I am not familiar with. The driver is asking *strictly* for -5 version and I don't want to fiddle about kernel compilation every damn time for tiny bits of proprietary code, I just want to use as it is (I don't even know if there is a possibility to recompile the kernel in MeeGo, and I am not a developer)
It should have been in the topic of the post really a link to the -5 version if you are the mantainers.
Regards.
Antonio
You are right Antonio, saw your 2013 email[1] which is the same frustration happen to me (in year 2021) to hunt firmware not in the firmware repository.. Ugh why some released driver needed a firmware version that could never be obtained anywhere...
[1] https://lore.kernel.org/linux-wireless/[email protected]/
Signature · 3 lines
Email : Robbi Nespu <robbinespu AT SPAMFREE gmail DOT com> PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA PGP key : https://keybase.io/robbinespu/pgp_keys.asc