I believe that I had hard freezes on latest (non-pre) . I see this in my kernel
logs:

Jul  6 20:24:37 laptux usbcore: registered new driver hiddev
Jul  6 20:24:37 laptux usbcore: registered new driver usbhid
Jul  6 20:24:37 laptux drivers/usb/input/hid-core.c: v2.6:USB HID core driver

This is using gentoo, kernel gentoo sources 2.6.16-r12 and 1.1.14 of ieee80211
of the wireless subsystem. Ironically, although that I don't know that this is
related, I am having the version problems every-other reboot, and I'm about to
try that patch, which doesn't work on the latest, which is another bug I will
eventually report. 

I had the freezed on the gentoo supplied ebuilds. Installing with these above
mentioned versions fixed that, but no joy on the connection.

Can you help to provide the debug info with loading the driver ./load 
debug=0x43fff? It can help us to fix bugs.

-Jun

(In reply to comment #3)
> Can you help to provide the debug info with loading the driver ./load 
> debug=0x43fff? It can help us to fix bugs.
> 
> -Jun
I'll give you more information if you give me more info on how to do it. I've
got no program called load.

You can go to ipw3945.sf.net to download the latest version of ipw3945, 
compile it and use this command "./load debug=0x43fff". After the problem 
occurs, run this command "dmesg >output", the output file is what we want.

Thanks,
-Jun

Created an attachment (id=886) [details]
original dmesg errors

Created an attachment (id=887) [details]
after load debug=...

Created an attachment (id=888) [details]
after 1st ifup attempt (failure)

Created an attachment (id=889) [details]
after iwconfig eth1 essid...

Created an attachment (id=890) [details]
after 2nd ifup (success)

Created an attachment (id=891) [details]
using associate=1 in modprobe

sorry for all the seperate attachments. I thought bugzilla would let me add them
all at once. guess not!

I believe I am seeing the same error. I too am using a M1710 with Fedora Core 5.
I have a bit of a hackish workaround and some debug output as requested by Jun.

versions:
ieee80211-1.1.14-11
ipw3945-1.1.0-12_pre2
ipw3945d-1.17.19-2
ipw3945-ucode-1.13-1

First the workaround:
  Add the following modprobe.conf setup
>>    install ipw3945 /sbin/modprobe -i ipw3945 associate=1 $CMDLINE_OPTS
>>    remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r -i ipw3945
$CMDLINE_OPTS

  and the following to rc.local
>>    /sbin/ipw3945d --quiet

Explanation:
The associate=1 seems to be the magic bullet.
I haven't been able to get any modprobe install combination to bring up the
ipw3945d daemon (even using the timeout options). Simply loading it later in the
boot cycle seems to work okay however.

Attachements and painful details:
 origDMESG - The relevant dmesg lines for a stock install (bringing up the
ipw3945d manually). These are the lines I believe to be similar to original posting.
 loadDMESG - the 'dmesg -c' immediately after running './load debug...'
 ifup1DMESG - after an /sbin/ifup eth1 command
 essidDMESG - after an /sbin/iwconfig eth1 essid ...
 ifup2DMESG - after ifdown then ifup on eth1

As you can see from the DMESGs setting the essid allowed the card to
(re)associate [The wireless LED above the keybord went solid]. The subsequent
ifup was then succesfull. The prior ifup (ifup1) had failed.

This led me to the associate module parameter and appears to be a temporary
solution. I say temporary because if you notice in the hackDMESG the driver
still threw a microcode error. A quick check of dmesg (I've been using the
wireless to access this webpage) shows that no more errors have been reported.

Hope this helps ----

I am not sure how gentoo configure the wirelesss interface.
Can you remove setting rate when loading the driver? 
Brix, how does gentoo implement it?

We don't set the rate unless the user has specified a rate setting. All wireless
configuration is done in /etc/conf.d/net and/or /etc/conf.d/wireless.

(In reply to comment #14)
> We don't set the rate unless the user has specified a rate setting. All wireless
> configuration is done in /etc/conf.d/net and/or /etc/conf.d/wireless.

ipw3945: U ipw_wx_set_rate Setting rate mask to 0x00000800 [fixed]

This is what we found in the debug log, it sets the rate to 54Mbps only.

Thanks,
Hong

(In reply to comment #15)

Sorry for the confusion. 

Let me clear this up a little. I'm running Fedora core 5 (not gentoo), and the
fixed 54Mbs is in my ifcfg-eth1 file as well as the channel=6 parameters. For
some reason system-config-network set this by default (all the networks I attach
to currently are Gs). I just switched these to auto and I'm updating the debug logs.

Okay, very interesting!

Without the fixed rate (but with a fixed channel=11) the card/drivers now seem
to work fine without needing the associate=1 added in!  

Without a fixed channel (channel=Auto) in ifcfg-eth1 I can't pick up an
association. BUMMER!

So maybe the associate=1 trick will work now? KINDA! It seems to have associated
for me but 'ifup eth1' always returns -- Error for wireless request "Set
Frequency" (8B04)--. But then it goes ahead an gets an IP through DHCP and seems
to work fine.

With the wrong channel (I use 6 at home, work is mainly 11) all the APs are
excluded except one very slow one.

I'll add debug logs for the above 3 cases.

So here's the wrap up for my cases.

If (FIXED RATE)
  install -i ipw3945 associate=1 $CMDLINE_OPTS [Needed in modprobe.conf]
If (RATE=Auto,Channel=#)
  standard modprobe.conf works fine [Your stuck on this channel though!]
If (RATE=Auto,Channel=Auto)
  install -i ipw3945 associate=1 $CMDLINE_OPTS [Needed in modprobe.conf]
  * ifup gives error warning (might be able to ignore)


So are the settings in ifcfg-eth1 suppose to have this much effect on the
card/driver prior to initializing it with 'ifup'??

Are these settings saved in cache on the card from one load to the next??

Created an attachment (id=892) [details]
RATE=Auto, CHANNEL=11

Created an attachment (id=893) [details]
RATE=Auto, CHANNEL=Auto

Created an attachment (id=894) [details]
RATE=Auto, CHANNEL=6

Created an attachment (id=895) [details]
RATE=Auto,CHANNEL=Auto, associate=1 (modprobe.conf)

Usually you don't need to specify the rate and channel in your config file.
The driver will do rate adjusting automatically according to the channel
environment. 


The only thing you should specify is the essid of your wireless network. After
you configure your essid, the driver will perform a scan and it will try to
associate with the network with the essid you set.

Thanks,
Hong

Chris:
Can you follow hong's last comment to only set the essid in the cfg file and 
see what happens?

Jun

The SYSASSERT on line 58 occurs when host sends an RXON_ASSOCIATED command, 
but the most recent RXON command did not have the "associated" bit set.

RXON and RXON_ASSOCIATED are two different commands (the ASSOCIATIED one just 
updates a few parameters without leaving the association).  uCode doesn't 
allow the ASSOCIATED command unless the previous RXON has "associated" set.

This bug is *not* related to 1085.

-- Ben --

Created an attachment (id=914) [details]
patch to try

(In reply to comment #23)
> The SYSASSERT on line 58 occurs when host sends an RXON_ASSOCIATED command, 
> but the most recent RXON command did not have the "associated" bit set.
> 
> RXON and RXON_ASSOCIATED are two different commands (the ASSOCIATIED one just 
> updates a few parameters without leaving the association).  uCode doesn't 
> allow the ASSOCIATED command unless the previous RXON has "associated" set.

Attached patch fixed this firmware error.

Thanks,
Hong

Patch merged for 1.1.2

Chris, can you help to verify this bug on the latest release?

Bests,
-Jun

Not found in latest 1.2.1. So verified it.

--Songbo