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
Hi Larry,
> 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.
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 Tue, 2012-08-21 at 00:14 -0500, Larry Finger wrote:
> >> 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.
> > 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.
>
> 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 :-)
> 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.
> 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
On 08/20/2012 11:55 PM, G?bor Stefanik wrote:
> On Mon, Aug 20, 2012 at 6:01 PM, Johannes Berg
> <[email protected]> wrote:
>> On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:
>>
>>> 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
>
> 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.
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
16.08.2012 18:06, Larry Finger skrev:
> 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.
>
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
On Mon, Aug 20, 2012 at 6:01 PM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:
>
>> 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
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.
On 08/20/2012 05:45 AM, Johannes Berg wrote:
Johannes,
> 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
On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:
> 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
> > 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
>
> > 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.
>
> > 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> 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]/
--
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