Wireless firmware errors from ipw2x00

[Martin Willemoes Hansen]

Installed daily build 20050831 and during install I choose to use the wireless NIC.

During install the wireless had problems failing on and off and spitting out
error messages like this:
305.250000 Firmware error detected. Restarting.

[Christian Elkjaer (c.elkjaer)]

I had the same error message with my ipw2100 firmware in Ubuntu Hoary recently.
However, not during install but during normal bootup. The firmware did
eventually get loaded and I did not care about the error message.

I have not seen the error message in Ubuntu Breezy (therefore leaving this bug
as unconfirmed).

Christian
https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT41

[Matt Zimmerman (mdz)]

*** Bug 20860 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

I also see these errors on my T42 with ipw2200

[Rolf Offermanns (rolf-offermanns)]

I also see this bug on my Maxdata Pro 8100IS. There are several entries in the ipw2200 bug database for this
(http://www.bughost.org/bugzilla/show_bug.cgi?id=649, http://www.bughost.org/bugzilla/show_bug.cgi?id=697). Some users reported,
that "modprobe ipw2200 hwcrypto=0" fixes the problem for them. For me, it does not. The problem occurs less often when I am in
near distance to my AP, it gets worse if I am at a "critical distance".

[Martin Willemoes Hansen (mwh)]

As of daily build 20050924, I do not get this error anymore.

[DanH (holmsand-gmail)]

I'm still seeing a lot of these with ipw2200 1.0.6 on Breezy, with kernel
2.6.12-9.19.

1.0.6 seems very unstable, overall - and even causes the entire system to hang,
with blinking capslock LED as the only life-sign.

For more on problems with ipw2200 1.0.6, see for example

http://www.bughost.org/bugzilla/show_bug.cgi?id=690
http://www.bughost.org/bugzilla/show_bug.cgi?id=778
http://www.ubuntuforums.org/showthread.php?t=70764&highlight=ipw2200

Even when not hanging, 1.0.6 frequently drops packages and connections.

1.0.3 is has been a lot more stable for me (using Hoary's kernel, but still).

[Matt Zimmerman (mdz)]

*** Bug 23071 has been marked as a duplicate of this bug. ***

[DanH (holmsand-gmail)]

ipw2200 1.0.3 is a lot more stable using Breezy's kernel as well.

[Ben Collins (ben-collins)]

Ok, I will back down to 1.0.3 for breezy.

[DanH (holmsand-gmail)]

(In reply to comment #9)
> Ok, I will back down to 1.0.3 for breezy.

Has this one been forgotten...?

[Matt Zimmerman (mdz)]

(In reply to comment #10)
> (In reply to comment #9)
> > Ok, I will back down to 1.0.3 for breezy.
>
> Has this one been forgotten...?

It is too late to make this kind of intrusive change; the 5.10 release is
practicall upon us.

[DanH (holmsand-gmail)]

(In reply to comment #11)
> It is too late to make this kind of intrusive change; the 5.10 release is
> practicall upon us.

So this is a WONTFIX then, which is a bit unfortunate (it's sort of a pain
to remove old modules, and compile and install working driver every time
the kernel is upgraded).

It might be a good idea to ship Dapper with a stable release of ipw2200,
rather than a (very) flaky "development snapshot".

[Matt Zimmerman (mdz)]

(In reply to comment #12)
> (In reply to comment #11)
> > It is too late to make this kind of intrusive change; the 5.10 release is
> > practicall upon us.
>
> So this is a WONTFIX then

No, it's Target Milestone: Ubuntu 6.04

>, which is a bit unfortunate (it's sort of a pain
> to remove old modules, and compile and install working driver every time
> the kernel is upgraded).
>
> It might be a good idea to ship Dapper with a stable release of ipw2200,
> rather than a (very) flaky "development snapshot".

Yes, I thought we had learned our lesson with this already. odd-numbered
releases are proper releases, while even-numbered ones are development
snapshots, or something of that nature?

[DanH (holmsand-gmail)]

(In reply to comment #13)
> Yes, I thought we had learned our lesson with this already. odd-numbered
> releases are proper releases, while even-numbered ones are development
> snapshots, or something of that nature?

Almost:

"Stable versions can be identified by the last digit of the version number
being a 0 (zero). All other releases are development snapshots."

according to http://ipw2200.sourceforge.net/

[Matt Zimmerman (mdz)]

(In reply to comment #14)
> (In reply to comment #13)
> > Yes, I thought we had learned our lesson with this already. odd-numbered
> > releases are proper releases, while even-numbered ones are development
> > snapshots, or something of that nature?
>
> Almost:
>
> "Stable versions can be identified by the last digit of the version number
> being a 0 (zero). All other releases are development snapshots."
>
> according to http://ipw2200.sourceforge.net/

In that case, there hasn't been a stable release since 1.0.0, which was pretty
badly broken for us, so taking the latest development snapshot wasn't
unreasonable...

[DanH (holmsand-gmail)]

(In reply to comment #15)
> In that case, there hasn't been a stable release since 1.0.0, which was pretty
> badly broken for us, so taking the latest development snapshot wasn't
> unreasonable...

It could be argued that 1.0.6 is even more broken, of course...

I'm not saying that development snapshotd, betas and whatnot shouldn't be
tested, as long as you're prepared to back down when serious issues arise.

A quick search of the breezy forum at ubuntuforums.org reveals that lots of people
will be breaking their kernels by attempting to install 1.0.0 by hand. That should
be fun to watch...

[Matt Zimmerman (mdz)]

(In reply to comment #16)
> It could be argued that 1.0.6 is even more broken, of course...

It could be argued, though it's not entirely clear. It's far better than 1.0.0
on my T42, for example. I saw these errors under 1.0.0 as well, but there I
frequently had to reload the driver in order to get it working again, while in
1.0.6 it works continuously without any fiddling.

> I'm not saying that development snapshotd, betas and whatnot shouldn't be
> tested, as long as you're prepared to back down when serious issues arise.

They are, and we are. This driver was updated to 1.0.6 in July. In September,
this bug was filed, and then later in September it was reported to be no longer
happening to the original reporter. In October you reconfirmed it and stated
that 1.0.3 fixed the problem for you. It would have been irresponsible to
revert the driver a few days before release based on the information available.

If the situation becomes more concrete after release, we can consider
backporting an update.

[Gregory P Smith (gpshead)]

I used my own 1.0.3 compile on warty and was quite happy. breezy's 1.0.6 is
giving me the "ipw2200: Firmware error detected. Restarting." all the time when
there is any significant traffic. its unusable. disappointing to see this in a
release. better luck next time.

i second the revert to 1.0.3 suggestion.

[Gregory P Smith (gpshead)]

bug 23587 points to a possible solution to this problem:

http://bugzilla.ubuntu.com/show_bug.cgi?id=17416

 -> http://bughost.org/bugzilla/show_bug.cgi?id=727

[Gregory P Smith (gpshead)]

The patch linked to in my comment #19 does not solve the problem. with it
applied I still see the

ipw2200: Firmware error detected. Restarting.

errors with associated drop in connectivity whenever there is heavy traffic.

[Andreas Schildbach (schildbach)]

I also frequently have this on a Dell Latitude X1, running Breezy release.

The only fix to this seems to be rebooting, which is very uncomfortable.

[Greg Taylor (gtaylor)]

Also an issue on the Toshiba Tecra A4. Showstopper for wireless college students.

[Ben Collins (ben-collins)]

Can I get some confirmation of this bug on dapper's 2.6.15 kernel, please?

[Chuck Short (zulcss)]

I can confirm this works properly under dapper.

[Greg Taylor (gtaylor)]

New issue at install with this driver. Improved over the previous but still
unusable. http://bugzilla.ubuntu.com/show_bug.cgi?id=21688

[Ovidiu Constantin (ovidiu-mybox)]

I get this all the time in dapper. Kernel 2.6.15-19-686. I did manage to make it work 2 time in about 15 tries. The connection was stable and I tested it for about 3 hours each time.