Two new versions of 3945 uCode is now available for download from
http://intellinuxwireless.org/?n=Downloads. Two versions are available
as we have updated the API version of the uCode and included pending
fixes in both API versions.
Version 15.28.1.8 supports API v1 and can be used with most current 3945
drivers. Version 15.28.2.8 (API v2) is required when you start using the
latest 3945 driver from wireless-testing at the time it includes the
patch "iwl3945 : Fix a-band association for passive channels".
Changes:
Version 15.28.1.8
- Allow full active dwell time after scan auto-switches from passive to
active scan
- Allow direct probes on passive-scan channels (after auto-switch)
- Expand coverage in Event Log
Version 15.28.2.8
- Allow full active dwell time after scan auto-switches from passive to
active scan
- Allow direct probes on passive-scan channels (after auto-switch)
- Expand coverage in Event Log
Reinette
Hi Johannes,
> > I do not believe our request is unreasonable. If a user runs a new
> > kernel the log will print a message that the firmware is incorrect ...
> > all the user needs to do is go to
> > http://intellinuxwireless.org/?n=Downloads and download the latest
> > firmware.
>
> And that exactly _is_ a problem, the user may be relying on wireless
> connectivity. And they won't know up-front they need new firmware. Since
> firmware is loaded from userspace, you're breaking userspace/kernel ABI,
> it's pretty simple really.
I talked to David Woodhouse and we plan to add a big warning to
modules_install when MODULE_FIRMWARE is not present on the filesystem.
> I really don't know why we let you get away with this and bitch
> endlessly when b43 does such a change, to the point where we finally
> cave in and support both versions. Why should a community-supported
> driver be held to higher standards?
If in any way possible, we should support both versions of the firmware.
Regards
Marcel
On Wed, 2008-10-22 at 16:14 -0700, reinette chatre wrote:
> In this firmware case we do not have "an id" (we have one
> file that is loaded by firmware loader so we cannot know what we get
> just by "looking at it" unless we enforce a version number in the
> filename as we currently do in our driver) and the firmware can change,
> potentially frequently, with the consequence of many "quirks" that need
> to be maintained.
But so you do know which firmware it is. Also, the driver looks into the
firmware after loading it to see which version it has, no? At least
there seemed to be a printout like that.
b43 for example has a few dynamic function pointers that are assigned
depending on the firmware. It even supports two completely different
hardware-transmit-header layouts.
> > It all depends on how much the ucode API changes and sometimes we really
> > wanna cleanup the driver and remove the old code, but in that case we
> > have to tell the users via modules_install that this kernel will break
> > or we have to keep the old driver around. Breaking it from one kernel
> > version to the next one without the user noticing only after reboot is
> > just not good enough.
>
> I agree with you and Johannes in this regard and look forward to the
> modules_install solution. I do hope this will be acceptable to
> everybody.
I think even in that case there should be one kernel version that warns
and accepts both, and then the next one that requires the newer version.
b43, for example, will print out a warning every time it loads old
microcode and the kernel tells you which URL to go to to download new
firmware that will no longer warn. The code has been in there for more
than a kernel version because we aren't changing that, but thanks to
this we can now rip out the old code should we implement new features
that absolutely require the new firmware. The transition should be more
gradual. Module install time in particular is quite late, at that point
I might already have installed the kernel. And if you're anything like
me, you install new kernels while sitting on a train for hours and hours
after downloading the git tree at home ;)
The patch Tomas identified doesn't look so extensive. Mind you, I don't
even see how it causes a microcode error, must be your policy of
aborting the microcode when it detects a regulatory violation?
johannes
On Tue, 2008-10-21 at 15:13 -0700, Marcel Holtmann wrote:
> Hi Tomas,
>
> > >> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> > >> > >> Two new versions of 3945 uCode is now available for download from
> > >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> > >> > >> as we have updated the API version of the uCode and included pending
> > >> > >> fixes in both API versions.
> > >> > >>
> > >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> > >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> > >> > >> latest 3945 driver from wireless-testing at the time it includes the
> > >> > >> patch "iwl3945 : Fix a-band association for passive channels".
> > >> > >
> > >> > > Can you make the driver work with the old ucode? We even do that for
> > >> > > drivers where we don't control the ucode like b43...
> > >> >
> > >> > What for?
> > >>
> > >> Well, so that installing a new kernel doesn't suddenly break your
> > >> network connection and ability to download the firmware, for instance.
> > >> If you want more arguments you can go read all the "b43 sucks" threads
> > >> about it.
> > >
> > > Johnannes has a point, that is a lot nicer to users...
> >
> > Maybe, but it will complicate the code beyond good taste to just
> > satisfy the single moment when kernel is upgraded. I don't mean in
> > general I mean in this particular case when API changes.
> > Anyhow a good distro shell deal with this in packaging dependencies
> > and normal person will keep old kernel around when compiling new one.
> > Both ucodes can be present on the file system at the same time so I
> > hope the risk is low.
>
> it is the same argument as for everything else. We should be able to run
> a new kernel with old userspace.
I do not believe our request is unreasonable. If a user runs a new
kernel the log will print a message that the firmware is incorrect ...
all the user needs to do is go to
http://intellinuxwireless.org/?n=Downloads and download the latest
firmware. This does not require any subtle changes that may affect other
aspects of the system ... just the firmware file that is only used by
the driver.
We are focused on upstream development. If there is a need to support
older ucode then we face a similar challenge as was solved through the
compat-wireless project for the driver self.
Reinette
On Wed, Oct 22, 2008 at 11:14 AM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2008-10-22 at 11:10 +0200, Tomas Winkler wrote:
>
>> > I really don't know why we let you get away with this and bitch
>> > endlessly when b43 does such a change, to the point where we finally
>> > cave in and support both versions. Why should a community-supported
>> > driver be held to higher standards?
>>
>> Patches that we'll support both firmwares from the cummutiy will be
>> welcome, as always.
>
> So you're saying we should let you get away with it and just fix it
> ourselves... How about you identify which patch broke it so we stand a
> chance?
01f9a21af3644224ecc899adeea31dc00418ddae
f93b673fcfe2670ccb22434d2ec7660b9f1c3fb8
But if then we decide the breakage is worse than the new
> feature, and revert the patch, you'll scream bloody murder anyway
Revert anything you want.
so why
> do I even bother?
Don't now
Clearly, so far there's no attempt to hold you to the
> same standards we hold community drivers to, and you are in no way
> motivated to improve our opinion of you by doing something voluntarily.
Your militant language is under my standards
Tomas
On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> Two new versions of 3945 uCode is now available for download from
> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> as we have updated the API version of the uCode and included pending
> fixes in both API versions.
>
> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> latest 3945 driver from wireless-testing at the time it includes the
> patch "iwl3945 : Fix a-band association for passive channels".
Can you make the driver work with the old ucode? We even do that for
drivers where we don't control the ucode like b43...
johannes
On Tue, Oct 21, 2008 at 4:31 PM, Marcel Holtmann
<[email protected]> wrote:
> Hi Luis,
>
>> >> > as long as the firmware is a file on the filesystem, it is the old
>> >> > userspace. It is simpler to update a firmware file (in this case
>> >> > installing a new one) then installing additional software, but that
>> >> > doesn't change anything.
>> >> >
>> >> > Our current problem is that our firmware is still not part of the
>> >> > firmware tree David Woodhouse is maintaining. Then we could link it
>> >> > together with the kernel tree. And yes, that is license issue, but it is
>> >> > one that can be solved.
>> >>
>> >> What license issue BTW?
>> >
>> > about putting our ucode into the linux-firmware.git tree?
>>
>> Yeah, what's wrong with the license used right now?
>
> this is not my authority, but as far as I understand it, it is fine, but
> someone inside Intel actually has to give green lights for it. And that
> is neither David or me.
Ah ok :) thanks for the clarification, red tape then.
Luis
On Tue, Oct 21, 2008 at 11:38 PM, John W. Linville
<[email protected]> wrote:
> On Tue, Oct 21, 2008 at 11:34:59PM +0200, Johannes Berg wrote:
>> On Tue, 2008-10-21 at 23:33 +0200, Tomas Winkler wrote:
>> > On Tue, Oct 21, 2008 at 11:25 PM, Johannes Berg
>> > <[email protected]> wrote:
>> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
>> > >> Two new versions of 3945 uCode is now available for download from
>> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
>> > >> as we have updated the API version of the uCode and included pending
>> > >> fixes in both API versions.
>> > >>
>> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
>> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
>> > >> latest 3945 driver from wireless-testing at the time it includes the
>> > >> patch "iwl3945 : Fix a-band association for passive channels".
>> > >
>> > > Can you make the driver work with the old ucode? We even do that for
>> > > drivers where we don't control the ucode like b43...
>> >
>> > What for?
>>
>> Well, so that installing a new kernel doesn't suddenly break your
>> network connection and ability to download the firmware, for instance.
>> If you want more arguments you can go read all the "b43 sucks" threads
>> about it.
>
> Johnannes has a point, that is a lot nicer to users...
Maybe, but it will complicate the code beyond good taste to just
satisfy the single moment when kernel is upgraded. I don't mean in
general I mean in this particular case when API changes.
Anyhow a good distro shell deal with this in packaging dependencies
and normal person will keep old kernel around when compiling new one.
Both ucodes can be present on the file system at the same time so I
hope the risk is low.
Tomas
>
> --
> John W. Linville Linux should be at the core
> [email protected] of your literate lifestyle.
>
On Wed, Oct 22, 2008 at 1:06 AM, Marcel Holtmann
<[email protected]> wrote:
> Hi Reinette,
>
>> > > >> > >> Two new versions of 3945 uCode is now available for download from
>> > > >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
>> > > >> > >> as we have updated the API version of the uCode and included pending
>> > > >> > >> fixes in both API versions.
>> > > >> > >>
>> > > >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
>> > > >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
>> > > >> > >> latest 3945 driver from wireless-testing at the time it includes the
>> > > >> > >> patch "iwl3945 : Fix a-band association for passive channels".
>> > > >> > >
>> > > >> > > Can you make the driver work with the old ucode? We even do that for
>> > > >> > > drivers where we don't control the ucode like b43...
>> > > >> >
>> > > >> > What for?
>> > > >>
>> > > >> Well, so that installing a new kernel doesn't suddenly break your
>> > > >> network connection and ability to download the firmware, for instance.
>> > > >> If you want more arguments you can go read all the "b43 sucks" threads
>> > > >> about it.
>> > > >
>> > > > Johnannes has a point, that is a lot nicer to users...
>> > >
>> > > Maybe, but it will complicate the code beyond good taste to just
>> > > satisfy the single moment when kernel is upgraded. I don't mean in
>> > > general I mean in this particular case when API changes.
>> > > Anyhow a good distro shell deal with this in packaging dependencies
>> > > and normal person will keep old kernel around when compiling new one.
>> > > Both ucodes can be present on the file system at the same time so I
>> > > hope the risk is low.
>> >
>> > it is the same argument as for everything else. We should be able to run
>> > a new kernel with old userspace.
>>
>> I do not believe our request is unreasonable. If a user runs a new
>> kernel the log will print a message that the firmware is incorrect ...
>> all the user needs to do is go to
>> http://intellinuxwireless.org/?n=Downloads and download the latest
>> firmware. This does not require any subtle changes that may affect other
>> aspects of the system ... just the firmware file that is only used by
>> the driver.
>>
>> We are focused on upstream development. If there is a need to support
>> older ucode then we face a similar challenge as was solved through the
>> compat-wireless project for the driver self.
>
> I haven't checked this particular case, but in some cases it is simple
> to keep backward compatible code around that would let us support the
> old firmware for a few releases. In other cases the driver and firmware
> interface might have evolved too much to do so. In these cases we might
> wanna keep the old drivers around so users can have a choice.
If it wasn't so awkward in this case I wouldn't mind to support old firmware.
Second when we touch firmware especially for old HW it means that it
solves a bug so why ones would use old driver for something else then
to download the new firmware.
> We do have something like drivers/staging/ now. It might make sense to
> have introduce drivers/deprecated/ for old drivers that we just keep
> around for a few releases to ease a transition. Just thinking out loud.
Sounds like good idea... need some configuration tricks tough unlike
staging here we have 2 drivers for the same hw
> And I have been bitten by ucode API changes in the past. It is just not
> clear when actually compiling the new kernel. We could also have compile
> time checks that check the new firmware file is actually present at the
> compile time of the new kernel. The driver should have a MODULE_FIRMWARE
> tag and we could process it and match it to /lib/firmware.
It has MODULE_FIRMWARE already
Tomas
Hi Luis,
> >> > as long as the firmware is a file on the filesystem, it is the old
> >> > userspace. It is simpler to update a firmware file (in this case
> >> > installing a new one) then installing additional software, but that
> >> > doesn't change anything.
> >> >
> >> > Our current problem is that our firmware is still not part of the
> >> > firmware tree David Woodhouse is maintaining. Then we could link it
> >> > together with the kernel tree. And yes, that is license issue, but it is
> >> > one that can be solved.
> >>
> >> What license issue BTW?
> >
> > about putting our ucode into the linux-firmware.git tree?
>
> Yeah, what's wrong with the license used right now?
this is not my authority, but as far as I understand it, it is fine, but
someone inside Intel actually has to give green lights for it. And that
is neither David or me.
Regards
Marcel
Hi Tomas,
> >> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> >> > >> Two new versions of 3945 uCode is now available for download from
> >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> >> > >> as we have updated the API version of the uCode and included pending
> >> > >> fixes in both API versions.
> >> > >>
> >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> >> > >> latest 3945 driver from wireless-testing at the time it includes the
> >> > >> patch "iwl3945 : Fix a-band association for passive channels".
> >> > >
> >> > > Can you make the driver work with the old ucode? We even do that for
> >> > > drivers where we don't control the ucode like b43...
> >> >
> >> > What for?
> >>
> >> Well, so that installing a new kernel doesn't suddenly break your
> >> network connection and ability to download the firmware, for instance.
> >> If you want more arguments you can go read all the "b43 sucks" threads
> >> about it.
> >
> > Johnannes has a point, that is a lot nicer to users...
>
> Maybe, but it will complicate the code beyond good taste to just
> satisfy the single moment when kernel is upgraded. I don't mean in
> general I mean in this particular case when API changes.
> Anyhow a good distro shell deal with this in packaging dependencies
> and normal person will keep old kernel around when compiling new one.
> Both ucodes can be present on the file system at the same time so I
> hope the risk is low.
it is the same argument as for everything else. We should be able to run
a new kernel with old userspace.
Regards
Marcel
On Wed, Oct 22, 2008 at 12:13 AM, Marcel Holtmann
<[email protected]> wrote:
> Hi Tomas,
>
>> >> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
>> >> > >> Two new versions of 3945 uCode is now available for download from
>> >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
>> >> > >> as we have updated the API version of the uCode and included pending
>> >> > >> fixes in both API versions.
>> >> > >>
>> >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
>> >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
>> >> > >> latest 3945 driver from wireless-testing at the time it includes the
>> >> > >> patch "iwl3945 : Fix a-band association for passive channels".
>> >> > >
>> >> > > Can you make the driver work with the old ucode? We even do that for
>> >> > > drivers where we don't control the ucode like b43...
>> >> >
>> >> > What for?
>> >>
>> >> Well, so that installing a new kernel doesn't suddenly break your
>> >> network connection and ability to download the firmware, for instance.
>> >> If you want more arguments you can go read all the "b43 sucks" threads
>> >> about it.
>> >
>> > Johnannes has a point, that is a lot nicer to users...
>>
>> Maybe, but it will complicate the code beyond good taste to just
>> satisfy the single moment when kernel is upgraded. I don't mean in
>> general I mean in this particular case when API changes.
>> Anyhow a good distro shell deal with this in packaging dependencies
>> and normal person will keep old kernel around when compiling new one.
>> Both ucodes can be present on the file system at the same time so I
>> hope the risk is low.
>
> it is the same argument as for everything else. We should be able to run
> a new kernel with old userspace.
Yet this is not user space, if there won't be a little :) license
issue this will integral part of the driver.
Tomas
On Wed, 2008-10-22 at 00:56 -0700, Marcel Holtmann wrote:
> Hi Johannes,
>
> > > I do not believe our request is unreasonable. If a user runs a new
> > > kernel the log will print a message that the firmware is incorrect ...
> > > all the user needs to do is go to
> > > http://intellinuxwireless.org/?n=Downloads and download the latest
> > > firmware.
> >
> > And that exactly _is_ a problem, the user may be relying on wireless
> > connectivity. And they won't know up-front they need new firmware. Since
> > firmware is loaded from userspace, you're breaking userspace/kernel ABI,
> > it's pretty simple really.
>
> I talked to David Woodhouse and we plan to add a big warning to
> modules_install when MODULE_FIRMWARE is not present on the filesystem.
Thank you very much. This appears to address the problem. That is, a
user trying to run a new kernel with old userspace will now get a
warning while internet access is still available. Thus enabling them to
update firmware. Is this solution acceptable to everybody?
>
> > I really don't know why we let you get away with this and bitch
> > endlessly when b43 does such a change, to the point where we finally
> > cave in and support both versions. Why should a community-supported
> > driver be held to higher standards?
>
> If in any way possible, we should support both versions of the firmware.
I would like to hear some suggestions on how we can do this as I am not
familiar with the other drivers. The driver is closely tied to the
firmware ... and I am actually tempted to draw an analogy between the
interface between the driver and mac80211 here. From what I understand,
for the driver to support many versions of the firmware it dynamically
needs to detect which features are supported at runtime and act
accordingly. This is a hard problem. What am I missing?
Reinette
Hi Reinette,
> > in some cases it might be possible with a set of quirks or special
> > functions that can be switched at runtime. Check the whole bunch of USB
> > drivers that have special handling depending on what hardware it finds.
> > We could do the same. In some cases this effort might be too much, but
> > if possible we should at least try.
>
> I don't think we can easily apply the hardware quirk solution here. This
> is because hardware can be identified by id that does not change and the
> hardware self does not really change (unless it has firmware that
> changes ...). In this firmware case we do not have "an id" (we have one
> file that is loaded by firmware loader so we cannot know what we get
> just by "looking at it" unless we enforce a version number in the
> filename as we currently do in our driver) and the firmware can change,
> potentially frequently, with the consequence of many "quirks" that need
> to be maintained.
we have the API version of the firmware file. If the new one can't be
found, then load the old one via request_firmware() and we know that we
have to use the old API. We can program our hardware only with one
firmware at a time anyway and we know which one we loaded.
We already apply the rules that if the firmware changes the API in an
incompatible way, we have to change the firmware filename.
Regards
Marcel
On Tue, 2008-10-21 at 14:34 -0700, Johannes Berg wrote:
> On Tue, 2008-10-21 at 23:33 +0200, Tomas Winkler wrote:
> > On Tue, Oct 21, 2008 at 11:25 PM, Johannes Berg
> > <[email protected]> wrote:
> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> > >> Two new versions of 3945 uCode is now available for download from
> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> > >> as we have updated the API version of the uCode and included pending
> > >> fixes in both API versions.
> > >>
> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> > >> latest 3945 driver from wireless-testing at the time it includes the
> > >> patch "iwl3945 : Fix a-band association for passive channels".
> > >
> > > Can you make the driver work with the old ucode? We even do that for
> > > drivers where we don't control the ucode like b43...
> >
> > What for?
>
> Well, so that installing a new kernel doesn't suddenly break your
> network connection and ability to download the firmware, for instance.
> If you want more arguments you can go read all the "b43 sucks" threads
> about it.
Using the new driver (with patch
http://marc.info/?l=linux-wireless&m=122401294318415&w=2 ) on current
(v1 API) uCode will cause a firmware error. The log message should be
clear that a newer ucode is required.
Reinette
On Wed, Oct 22, 2008 at 12:07 PM, Christoph Hellwig <[email protected]> wrote:
> On Tue, Oct 21, 2008 at 03:28:08PM -0700, reinette chatre wrote:
>> I do not believe our request is unreasonable. If a user runs a new
>> kernel the log will print a message that the firmware is incorrect ...
>> all the user needs to do is go to
>> http://intellinuxwireless.org/?n=Downloads and download the latest
>> firmware. This does not require any subtle changes that may affect other
>> aspects of the system ... just the firmware file that is only used by
>> the driver.
>
> with the wireless that doesn't work. Nice. Sorry guys, but requiring
> a new firmware version for a new driver release is completely
> unreasonable. You can drop support for older firmware ABIs after a few
> years,but not immediately.
Years.. this HW will be obsolete in year or two, hopefully recycled.
I personally don't want people using this buggy firmware for years.
This is development branch after all, it's not even scheduled for 2.6.28.
Ucode API for 4965 was changed to -2 without much pain, So there is a
precedence this work quite well. This time there were some hiccups in
handling this since the API version wasn't updated it as should be.
really our fault. But I don't think this situation is so dramatic as
you describe it.
The objective of the objections is not that we want to immensely hurt
users but rather the trade off between maintain even uglier code and
users running buggy firmware versus logging into older kernel and
downloading new firmware in 5 minutes looks to me not proportional.
Distro users that pull updates won't even notice. I might be wrong
though.
Tomas
Hi Tomas,
> >> > > >> > >> Two new versions of 3945 uCode is now available for download from
> >> > > >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> >> > > >> > >> as we have updated the API version of the uCode and included pending
> >> > > >> > >> fixes in both API versions.
> >> > > >> > >>
> >> > > >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> >> > > >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> >> > > >> > >> latest 3945 driver from wireless-testing at the time it includes the
> >> > > >> > >> patch "iwl3945 : Fix a-band association for passive channels".
> >> > > >> > >
> >> > > >> > > Can you make the driver work with the old ucode? We even do that for
> >> > > >> > > drivers where we don't control the ucode like b43...
> >> > > >> >
> >> > > >> > What for?
> >> > > >>
> >> > > >> Well, so that installing a new kernel doesn't suddenly break your
> >> > > >> network connection and ability to download the firmware, for instance.
> >> > > >> If you want more arguments you can go read all the "b43 sucks" threads
> >> > > >> about it.
> >> > > >
> >> > > > Johnannes has a point, that is a lot nicer to users...
> >> > >
> >> > > Maybe, but it will complicate the code beyond good taste to just
> >> > > satisfy the single moment when kernel is upgraded. I don't mean in
> >> > > general I mean in this particular case when API changes.
> >> > > Anyhow a good distro shell deal with this in packaging dependencies
> >> > > and normal person will keep old kernel around when compiling new one.
> >> > > Both ucodes can be present on the file system at the same time so I
> >> > > hope the risk is low.
> >> >
> >> > it is the same argument as for everything else. We should be able to run
> >> > a new kernel with old userspace.
> >>
> >> I do not believe our request is unreasonable. If a user runs a new
> >> kernel the log will print a message that the firmware is incorrect ...
> >> all the user needs to do is go to
> >> http://intellinuxwireless.org/?n=Downloads and download the latest
> >> firmware. This does not require any subtle changes that may affect other
> >> aspects of the system ... just the firmware file that is only used by
> >> the driver.
> >>
> >> We are focused on upstream development. If there is a need to support
> >> older ucode then we face a similar challenge as was solved through the
> >> compat-wireless project for the driver self.
> >
> > I haven't checked this particular case, but in some cases it is simple
> > to keep backward compatible code around that would let us support the
> > old firmware for a few releases. In other cases the driver and firmware
> > interface might have evolved too much to do so. In these cases we might
> > wanna keep the old drivers around so users can have a choice.
>
> If it wasn't so awkward in this case I wouldn't mind to support old firmware.
> Second when we touch firmware especially for old HW it means that it
> solves a bug so why ones would use old driver for something else then
> to download the new firmware.
if possible, we should try to support old ucode APIs with the latest
drivers. In some situations that might be not possible, but we should at
least try.
> > We do have something like drivers/staging/ now. It might make sense to
> > have introduce drivers/deprecated/ for old drivers that we just keep
> > around for a few releases to ease a transition. Just thinking out loud.
>
> Sounds like good idea... need some configuration tricks tough unlike
> staging here we have 2 drivers for the same hw
That is just some Kconfig magic :)
> > And I have been bitten by ucode API changes in the past. It is just not
> > clear when actually compiling the new kernel. We could also have compile
> > time checks that check the new firmware file is actually present at the
> > compile time of the new kernel. The driver should have a MODULE_FIRMWARE
> > tag and we could process it and match it to /lib/firmware.
>
> It has MODULE_FIRMWARE already
I know, but we need to actually make better use of this information in a
generic post compile step to check that the firmware is actually in
place and warn if it is not. Then you can go ahead and download it
before actually booting a kernel with a now broken wireless card. This
is not even Intel or wireless specific. We should do this for all kinds
of drivers.
Regards
Marcel
On Wed, 2008-10-22 at 11:10 +0200, Tomas Winkler wrote:
> > I really don't know why we let you get away with this and bitch
> > endlessly when b43 does such a change, to the point where we finally
> > cave in and support both versions. Why should a community-supported
> > driver be held to higher standards?
>
> Patches that we'll support both firmwares from the cummutiy will be
> welcome, as always.
So you're saying we should let you get away with it and just fix it
ourselves... How about you identify which patch broke it so we stand a
chance? But if then we decide the breakage is worse than the new
feature, and revert the patch, you'll scream bloody murder anyway so why
do I even bother? Clearly, so far there's no attempt to hold you to the
same standards we hold community drivers to, and you are in no way
motivated to improve our opinion of you by doing something voluntarily.
johannes
On Wed, Oct 22, 2008 at 04:14:21PM -0700, reinette chatre wrote:
> On Wed, 2008-10-22 at 15:59 -0700, Marcel Holtmann wrote:
>
> > in some cases it might be possible with a set of quirks or special
> > functions that can be switched at runtime. Check the whole bunch of USB
> > drivers that have special handling depending on what hardware it finds.
> > We could do the same. In some cases this effort might be too much, but
> > if possible we should at least try.
>
> I don't think we can easily apply the hardware quirk solution here. This
> is because hardware can be identified by id that does not change and the
> hardware self does not really change (unless it has firmware that
> changes ...). In this firmware case we do not have "an id" (we have one
> file that is loaded by firmware loader so we cannot know what we get
> just by "looking at it" unless we enforce a version number in the
> filename as we currently do in our driver) and the firmware can change,
> potentially frequently, with the consequence of many "quirks" that need
> to be maintained.
You can try to load the new firmware, and if that fails you can try
the older firmware. Whichever one succeeds first can govern the API
you use. In fact, I had a patch like this for Fedora back when you
first added an API version to your firmware. Of course, at that point
there was no need to rememebr what got loaded since there really was
only one API...
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Tue, 2008-10-21 at 23:33 +0200, Tomas Winkler wrote:
> On Tue, Oct 21, 2008 at 11:25 PM, Johannes Berg
> <[email protected]> wrote:
> > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> >> Two new versions of 3945 uCode is now available for download from
> >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> >> as we have updated the API version of the uCode and included pending
> >> fixes in both API versions.
> >>
> >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> >> latest 3945 driver from wireless-testing at the time it includes the
> >> patch "iwl3945 : Fix a-band association for passive channels".
> >
> > Can you make the driver work with the old ucode? We even do that for
> > drivers where we don't control the ucode like b43...
>
> What for?
Well, so that installing a new kernel doesn't suddenly break your
network connection and ability to download the firmware, for instance.
If you want more arguments you can go read all the "b43 sucks" threads
about it.
johannes
On Tue, Oct 21, 2008 at 11:34:59PM +0200, Johannes Berg wrote:
> On Tue, 2008-10-21 at 23:33 +0200, Tomas Winkler wrote:
> > On Tue, Oct 21, 2008 at 11:25 PM, Johannes Berg
> > <[email protected]> wrote:
> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> > >> Two new versions of 3945 uCode is now available for download from
> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> > >> as we have updated the API version of the uCode and included pending
> > >> fixes in both API versions.
> > >>
> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> > >> latest 3945 driver from wireless-testing at the time it includes the
> > >> patch "iwl3945 : Fix a-band association for passive channels".
> > >
> > > Can you make the driver work with the old ucode? We even do that for
> > > drivers where we don't control the ucode like b43...
> >
> > What for?
>
> Well, so that installing a new kernel doesn't suddenly break your
> network connection and ability to download the firmware, for instance.
> If you want more arguments you can go read all the "b43 sucks" threads
> about it.
Johnannes has a point, that is a lot nicer to users...
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Wed, 2008-10-22 at 15:59 -0700, Marcel Holtmann wrote:
> in some cases it might be possible with a set of quirks or special
> functions that can be switched at runtime. Check the whole bunch of USB
> drivers that have special handling depending on what hardware it finds.
> We could do the same. In some cases this effort might be too much, but
> if possible we should at least try.
I don't think we can easily apply the hardware quirk solution here. This
is because hardware can be identified by id that does not change and the
hardware self does not really change (unless it has firmware that
changes ...). In this firmware case we do not have "an id" (we have one
file that is loaded by firmware loader so we cannot know what we get
just by "looking at it" unless we enforce a version number in the
filename as we currently do in our driver) and the firmware can change,
potentially frequently, with the consequence of many "quirks" that need
to be maintained.
> It all depends on how much the ucode API changes and sometimes we really
> wanna cleanup the driver and remove the old code, but in that case we
> have to tell the users via modules_install that this kernel will break
> or we have to keep the old driver around. Breaking it from one kernel
> version to the next one without the user noticing only after reboot is
> just not good enough.
I agree with you and Johannes in this regard and look forward to the
modules_install solution. I do hope this will be acceptable to
everybody.
Reinette
On Tue, Oct 21, 2008 at 03:28:08PM -0700, reinette chatre wrote:
> I do not believe our request is unreasonable. If a user runs a new
> kernel the log will print a message that the firmware is incorrect ...
> all the user needs to do is go to
> http://intellinuxwireless.org/?n=Downloads and download the latest
> firmware. This does not require any subtle changes that may affect other
> aspects of the system ... just the firmware file that is only used by
> the driver.
with the wireless that doesn't work. Nice. Sorry guys, but requiring
a new firmware version for a new driver release is completely
unreasonable. You can drop support for older firmware ABIs after a few
years, but not immediately.
Hi!
I'm a 3945 user and am quite happy with everything. Thx for your good
work! But:
On Wed, 22 Oct 2008 14:28:14 +0200
"Tomas Winkler" <[email protected]> wrote:
>
> The objective of the objections is not that we want to immensely hurt
> users but rather the trade off between maintain even uglier code and
> users running buggy firmware versus logging into older kernel and
> downloading new firmware in 5 minutes looks to me not proportional.
> Distro users that pull updates won't even notice. I might be wrong
> though.
more so like 10 minutes, if you are quick to grasp what happened.
if 1000 encounter this problem, that's 10000 minutes wasted, thats
7*24 hours. That's some annoying big waste of time!
keep in mind that that breakage _will_ waste the time of other people
and that those people are your fellow cutting-edge-kernel testers and
developers!
but then again, if the new firmware is really superior in many cases,
that might be worth it? i mean, if people forget that they are annoyed
because the device now performs super ueber cool... or smth like that..
it might pay off (from a user perspective)...
so my hope: you avoid breakage and keep people happy! That
is also good for your karma (whatever that is)
Sincerely,
Florian
p.s.: if i think more about it: all my non-linux colleagues refer to
such breakages as "the linux-expirience"... my linux friends would refer
to such stuff as "the gentoo-expirience" ... but in my book stuff
like this just sucks...
On Wed, 2008-10-22 at 09:56 +0200, Marcel Holtmann wrote:
> > I really don't know why we let you get away with this and bitch
> > endlessly when b43 does such a change, to the point where we finally
> > cave in and support both versions. Why should a community-supported
> > driver be held to higher standards?
>
> If in any way possible, we should support both versions of the firmware.
It doesn't look to me that the wireless folks will succumb to any
pressure unless John reverts the patches. But they haven't even managed
to identify the patches that caused the breakage...
johannes
Hi Reinette,
> > > I really don't know why we let you get away with this and bitch
> > > endlessly when b43 does such a change, to the point where we finally
> > > cave in and support both versions. Why should a community-supported
> > > driver be held to higher standards?
> >
> > If in any way possible, we should support both versions of the firmware.
>
> I would like to hear some suggestions on how we can do this as I am not
> familiar with the other drivers. The driver is closely tied to the
> firmware ... and I am actually tempted to draw an analogy between the
> interface between the driver and mac80211 here. From what I understand,
> for the driver to support many versions of the firmware it dynamically
> needs to detect which features are supported at runtime and act
> accordingly. This is a hard problem. What am I missing?
in some cases it might be possible with a set of quirks or special
functions that can be switched at runtime. Check the whole bunch of USB
drivers that have special handling depending on what hardware it finds.
We could do the same. In some cases this effort might be too much, but
if possible we should at least try.
It all depends on how much the ucode API changes and sometimes we really
wanna cleanup the driver and remove the old code, but in that case we
have to tell the users via modules_install that this kernel will break
or we have to keep the old driver around. Breaking it from one kernel
version to the next one without the user noticing only after reboot is
just not good enough.
Regards
Marcel
Hi Tomas,
> >> >> > > On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
> >> >> > >> Two new versions of 3945 uCode is now available for download from
> >> >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> >> >> > >> as we have updated the API version of the uCode and included pending
> >> >> > >> fixes in both API versions.
> >> >> > >>
> >> >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> >> >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> >> >> > >> latest 3945 driver from wireless-testing at the time it includes the
> >> >> > >> patch "iwl3945 : Fix a-band association for passive channels".
> >> >> > >
> >> >> > > Can you make the driver work with the old ucode? We even do that for
> >> >> > > drivers where we don't control the ucode like b43...
> >> >> >
> >> >> > What for?
> >> >>
> >> >> Well, so that installing a new kernel doesn't suddenly break your
> >> >> network connection and ability to download the firmware, for instance.
> >> >> If you want more arguments you can go read all the "b43 sucks" threads
> >> >> about it.
> >> >
> >> > Johnannes has a point, that is a lot nicer to users...
> >>
> >> Maybe, but it will complicate the code beyond good taste to just
> >> satisfy the single moment when kernel is upgraded. I don't mean in
> >> general I mean in this particular case when API changes.
> >> Anyhow a good distro shell deal with this in packaging dependencies
> >> and normal person will keep old kernel around when compiling new one.
> >> Both ucodes can be present on the file system at the same time so I
> >> hope the risk is low.
> >
> > it is the same argument as for everything else. We should be able to run
> > a new kernel with old userspace.
>
> Yet this is not user space, if there won't be a little :) license
> issue this will integral part of the driver.
as long as the firmware is a file on the filesystem, it is the old
userspace. It is simpler to update a firmware file (in this case
installing a new one) then installing additional software, but that
doesn't change anything.
Our current problem is that our firmware is still not part of the
firmware tree David Woodhouse is maintaining. Then we could link it
together with the kernel tree. And yes, that is license issue, but it is
one that can be solved.
Regards
Marcel
Hi Tomas,
> >> I do not believe our request is unreasonable. If a user runs a new
> >> kernel the log will print a message that the firmware is incorrect ...
> >> all the user needs to do is go to
> >> http://intellinuxwireless.org/?n=Downloads and download the latest
> >> firmware. This does not require any subtle changes that may affect other
> >> aspects of the system ... just the firmware file that is only used by
> >> the driver.
> >
> > with the wireless that doesn't work. Nice. Sorry guys, but requiring
> > a new firmware version for a new driver release is completely
> > unreasonable. You can drop support for older firmware ABIs after a few
> > years,but not immediately.
>
> Years.. this HW will be obsolete in year or two, hopefully recycled.
> I personally don't want people using this buggy firmware for years.
seems I have to put clearly my community hat on now.
This is not true at all. I am still using a ipw2100 in one of my
machine. So the 3945 and 4965 will be in use for a long time. The
community measurement of obsolete and companies measurement are totally
different. Also don't forget these countries where laptops and
electronics are still expensive. The old Intel wireless cards will still
be used for a long time there.
> This is development branch after all, it's not even scheduled for 2.6.28.
>
> Ucode API for 4965 was changed to -2 without much pain, So there is a
> precedence this work quite well. This time there were some hiccups in
> handling this since the API version wasn't updated it as should be.
> really our fault. But I don't think this situation is so dramatic as
> you describe it.
Actually that is your impression. I was falling over the 4965 ucode API
change twice and it took me longer than 5 minutes to even debug and
understand what went wrong here. Since there is no real warning anywhere
and the wireless device does show up. And I do know how to handle these
things.
> The objective of the objections is not that we want to immensely hurt
> users but rather the trade off between maintain even uglier code and
> users running buggy firmware versus logging into older kernel and
> downloading new firmware in 5 minutes looks to me not proportional.
> Distro users that pull updates won't even notice. I might be wrong
> though.
There will be cases where it is too much of a burden and too complicated
to keep support for both APIs, but in all other cases we should try to
have the driver work with it. I am fully behind Johannes and Christoph
here since that is what the community expects.
So if we ran into a case where we need to abandon the support for the
old API, then we first should make sure that the modules_install will
warn loudly about the missing firmware. And with MODULE_FIRMWARE and the
firmware work from David, we do have everything in place to actually do
this. So lets do it.
An additional option would be to create drivers/deprecated/ and put a
copy of the old driver there and have some Kconfig magic to allow
selecting only one of the drivers.
Regards
Marcel
Hi Reinette,
> > > >> > >> Two new versions of 3945 uCode is now available for download from
> > > >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available
> > > >> > >> as we have updated the API version of the uCode and included pending
> > > >> > >> fixes in both API versions.
> > > >> > >>
> > > >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945
> > > >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the
> > > >> > >> latest 3945 driver from wireless-testing at the time it includes the
> > > >> > >> patch "iwl3945 : Fix a-band association for passive channels".
> > > >> > >
> > > >> > > Can you make the driver work with the old ucode? We even do that for
> > > >> > > drivers where we don't control the ucode like b43...
> > > >> >
> > > >> > What for?
> > > >>
> > > >> Well, so that installing a new kernel doesn't suddenly break your
> > > >> network connection and ability to download the firmware, for instance.
> > > >> If you want more arguments you can go read all the "b43 sucks" threads
> > > >> about it.
> > > >
> > > > Johnannes has a point, that is a lot nicer to users...
> > >
> > > Maybe, but it will complicate the code beyond good taste to just
> > > satisfy the single moment when kernel is upgraded. I don't mean in
> > > general I mean in this particular case when API changes.
> > > Anyhow a good distro shell deal with this in packaging dependencies
> > > and normal person will keep old kernel around when compiling new one.
> > > Both ucodes can be present on the file system at the same time so I
> > > hope the risk is low.
> >
> > it is the same argument as for everything else. We should be able to run
> > a new kernel with old userspace.
>
> I do not believe our request is unreasonable. If a user runs a new
> kernel the log will print a message that the firmware is incorrect ...
> all the user needs to do is go to
> http://intellinuxwireless.org/?n=Downloads and download the latest
> firmware. This does not require any subtle changes that may affect other
> aspects of the system ... just the firmware file that is only used by
> the driver.
>
> We are focused on upstream development. If there is a need to support
> older ucode then we face a similar challenge as was solved through the
> compat-wireless project for the driver self.
I haven't checked this particular case, but in some cases it is simple
to keep backward compatible code around that would let us support the
old firmware for a few releases. In other cases the driver and firmware
interface might have evolved too much to do so. In these cases we might
wanna keep the old drivers around so users can have a choice.
We do have something like drivers/staging/ now. It might make sense to
have introduce drivers/deprecated/ for old drivers that we just keep
around for a few releases to ease a transition. Just thinking out loud.
And I have been bitten by ucode API changes in the past. It is just not
clear when actually compiling the new kernel. We could also have compile
time checks that check the new firmware file is actually present at the
compile time of the new kernel. The driver should have a MODULE_FIRMWARE
tag and we could process it and match it to /lib/firmware.
Regards
Marcel
On Tue, 2008-10-21 at 15:28 -0700, reinette chatre wrote:
> I do not believe our request is unreasonable. If a user runs a new
> kernel the log will print a message that the firmware is incorrect ...
> all the user needs to do is go to
> http://intellinuxwireless.org/?n=Downloads and download the latest
> firmware.
And that exactly _is_ a problem, the user may be relying on wireless
connectivity. And they won't know up-front they need new firmware. Since
firmware is loaded from userspace, you're breaking userspace/kernel ABI,
it's pretty simple really.
I really don't know why we let you get away with this and bitch
endlessly when b43 does such a change, to the point where we finally
cave in and support both versions. Why should a community-supported
driver be held to higher standards?
johannes
Hi Luis,
> > as long as the firmware is a file on the filesystem, it is the old
> > userspace. It is simpler to update a firmware file (in this case
> > installing a new one) then installing additional software, but that
> > doesn't change anything.
> >
> > Our current problem is that our firmware is still not part of the
> > firmware tree David Woodhouse is maintaining. Then we could link it
> > together with the kernel tree. And yes, that is license issue, but it is
> > one that can be solved.
>
> What license issue BTW?
about putting our ucode into the linux-firmware.git tree?
Regards
Marcel
On Tue, Oct 21, 2008 at 11:25 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2008-10-21 at 11:27 -0700, reinette chatre wrote:
>> Two new versions of 3945 uCode is now available for download from
>> http://intellinuxwireless.org/?n=Downloads. Two versions are available
>> as we have updated the API version of the uCode and included pending
>> fixes in both API versions.
>>
>> Version 15.28.1.8 supports API v1 and can be used with most current 3945
>> drivers. Version 15.28.2.8 (API v2) is required when you start using the
>> latest 3945 driver from wireless-testing at the time it includes the
>> patch "iwl3945 : Fix a-band association for passive channels".
>
> Can you make the driver work with the old ucode? We even do that for
> drivers where we don't control the ucode like b43...
What for?
Tomas
On Tue, Oct 21, 2008 at 4:01 PM, Marcel Holtmann
<[email protected]> wrote:
> as long as the firmware is a file on the filesystem, it is the old
> userspace. It is simpler to update a firmware file (in this case
> installing a new one) then installing additional software, but that
> doesn't change anything.
>
> Our current problem is that our firmware is still not part of the
> firmware tree David Woodhouse is maintaining. Then we could link it
> together with the kernel tree. And yes, that is license issue, but it is
> one that can be solved.
What license issue BTW?
On Wed, Oct 22, 2008 at 9:27 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2008-10-21 at 15:28 -0700, reinette chatre wrote:
>
>> I do not believe our request is unreasonable. If a user runs a new
>> kernel the log will print a message that the firmware is incorrect ...
>> all the user needs to do is go to
>> http://intellinuxwireless.org/?n=Downloads and download the latest
>> firmware.
>
> And that exactly _is_ a problem, the user may be relying on wireless
> connectivity. And they won't know up-front they need new firmware. Since
> firmware is loaded from userspace, you're breaking userspace/kernel ABI,
> it's pretty simple really.
>
> I really don't know why we let you get away with this and bitch
> endlessly when b43 does such a change, to the point where we finally
> cave in and support both versions. Why should a community-supported
> driver be held to higher standards?
Patches that we'll support both firmwares from the cummutiy will be
welcome, as always.
Tomas
On Tue, Oct 21, 2008 at 4:11 PM, Marcel Holtmann
<[email protected]> wrote:
> Hi Luis,
>
>> > as long as the firmware is a file on the filesystem, it is the old
>> > userspace. It is simpler to update a firmware file (in this case
>> > installing a new one) then installing additional software, but that
>> > doesn't change anything.
>> >
>> > Our current problem is that our firmware is still not part of the
>> > firmware tree David Woodhouse is maintaining. Then we could link it
>> > together with the kernel tree. And yes, that is license issue, but it is
>> > one that can be solved.
>>
>> What license issue BTW?
>
> about putting our ucode into the linux-firmware.git tree?
Yeah, what's wrong with the license used right now?
Luis