Created an attachment (id=844) [details]
Detailed dmesg output

Hi,

The firmware restarts occur even if I am not browsing the net. I loaded the 
driver and associated with my AP and did nothing else (that is, I didn't 
request an IP address via dhcp-client) and yet after about 10 minutes the same 
errors start showing up and my computer response becomes very sluggish. 

Shreyas. 

Any progress on this? I have tried versions from 1.0.3 till 1.1.0 and have the
same problem with all versions. The led blinks and then the whole computer
freezes up until I disable wireless with the Fn+F2 button on the laptop. I tried
changing routers, default channel settings on the routers etc. but the problem
persists. 

I would gladly try any patches that you suggest. 

It looks like it's having a problem in tuning to a channel, and I'm wondering 
if there's a hardware problem.

Can you dual boot to Windows?  If so, does it work okay?

-- Ben --

I only have linux installed on this machine, so cannot test the wireless card
under windows unfortunately. 

However, I tried using the ndiswrapper+windows driver available at the intel
site and it works fine as long 
as there is no encryption. Doesn't connect when I enable encryption. The
ndiswrapper website had 
suggestions of enabling 16K stacks in the linux kernel. I haven't done that, so
I am not sure if that is why I 
am unable to connect with encryption. 

Also everytime the wireless starts blinking I also see error messsages in the
syslog related to touchpad. 
Would it be some sort of IRQ conflict? 

Shreyas. 

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

This bug is *not* related to Bug 1090, but is the *same* as Bug 1091.

The SYSASSERT on line 204 (shown in both Bug 1085 and Bug 1091) is because the 
tuner is failing to tune to a channel in time.  The reporter for Bug 1091 
showed it might be hardware specific, i.e. it occurred on only one platform.

However, Shreyas tried the NDIS wrapper on his machine (that I suspected might 
have a hardware problem), and it worked.  So maybe it's not the 3945 itself.

Shreyas suspects some IRQ interaction, which is a possibility (I'm mystified 
how it might affect tuning to a channel!).  Shreyas, have you been able to 
play with IRQ assignments or anything?

-- Ben --

(In reply to comment #7)
> The SYSASSERT on line 204 (shown in both Bug 1085 and Bug 1091) is because the 
> tuner is failing to tune to a channel in time.  The reporter for Bug 1091 
> showed it might be hardware specific, i.e. it occurred on only one platform.

Can you explain this? Do you mean just the 3945 card or the motherboard+3945
combination? Michal has an Asus laptop while I have a Dell 6400. Lonny has a
Dell too but it is D620 (I think). So it seems to me that the problem is
something specific to the 3945 card (hardware or driver). 


> Shreyas suspects some IRQ interaction, which is a possibility (I'm mystified 
> how it might affect tuning to a channel!).  Shreyas, have you been able to 
> play with IRQ assignments or anything?

I haven't had a chance to fiddle around with this issue. I will try and post the
error messages I get from the touchpad so that others can verify if they are
seeing this error too. Meanwhile, if someone can give me some pointers on IRQ
assignments I will gladly try them out. 

Shreyas. 

Just to recap:

Michal reported that two "identical" Asus machines behaved differently using 
Linux native driver, and thought it might be the 3945 hardware causing the 
difference/problem.

Shreyas reported that he tried two different drivers on same Dell machine; 
Linux native had problems, while NDIS wrapper with Win driver worked.  This 
seems to indicate that the hardware is okay, assuming that the NDIS wrapper is 
really working better than Linux native (Win driver doesn't seem to report 
errors so performance may be the only indicator).

Just curious, were there any temperature differences between trials?  (Just 
wondering if, especially during the summer, the tuning speed/success might be 
affected by temperature).

I don't know how to advise you about any IRQ experiments ... probably 
shouldn't attempt anything unless you know what you're doing.

-- Ben --

(In reply to comment #9)

> Just curious, were there any temperature differences between trials?  (Just 
> wondering if, especially during the summer, the tuning speed/success might be 
> affected by temperature).

I don't know the exact numbers. However, I have always tried to load ipw3945
when I switch on the laptop in the evenings (after it has been off all day) and
have had to disable it within minutes. So it was always operating while the
laptop was "cooler" (will provide acpi temperature readings this evening if you
want). 

Shreyas. 

I'm not sure of my exact temperatures (though nothing flagged with my sensors in
karamba) but I do know this laptop is currently kept in a basement which is
always around 22c degrees right now (71.6f).

I'm guessing this doesn't help much. I'll try tracking this better if it's a
suggested avenue to explore.

(In reply to comment #8)

> Can you explain this? Do you mean just the 3945 card or the motherboard+3945
> combination? Michal has an Asus laptop while I have a Dell 6400. Lonny has a
> Dell too but it is D620 (I think). So it seems to me that the problem is
> something specific to the 3945 card (hardware or driver). 

To confirm, my laptop is a D620. I was going to try NDIS wrapper but it looked
like you need a Windows machine to extract the file to use (I do not have any
Windows machines). There was a suggestion on the site to use and exe extractor
to grab the file but I couldn't get the one they listed to work.

I know this isn't the correct forum but I'd be willing to try NDIS wrapper and
see if that yields different results. Does anyone have a better method for
extracting the required files to use the wrapper?

(In reply to comment #12)
> To confirm, my laptop is a D620. I was going to try NDIS wrapper but it looked
> like you need a Windows machine to extract the file to use (I do not have any
> Windows machines). There was a suggestion on the site to use and exe extractor
> to grab the file but I couldn't get the one they listed to work.

You can get the windows version of the Intel driver at http://www.intel.com/support/wireless/wlan/sb/
cs-010623.htm You will need cabextract to extract the files out of this exe file. Once you have it 
extracted you will have to find the .inf file (there are three inf files in it because it has drivers for 2100, 
2200 and 3945). I think it is called NETw39x5.inf. Then follow the instructions at the ndiswrapper wiki 
to install it and configure it to associate with the router. 

Shreyas. 

Sounds like temperature is probably not a problem ... thanks for the reports.

-- Ben --

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

Hi, 

Couple of updates: 

1. ACPI reported a temperature of 35C-37C throught the period when ipw3945
driver was loaded and started spewing out microcode errors. 

2. I think I was wrong to suspect an IRQ conflict. All my previous observations,
I was actively using the keyboard and mouse when the microcode errors started
showing up in the logs. So yesterday I tried monitoring the logs via ssh instead
of sitting at the console and the microcode errors started showing up and this
time there were no errors in the logs from the touchpad driver. So I think we
can safely rule out the IRQ conflict problem. It seems that the monetary system
freezes interfere with the touchpad driver. 

3. Yesterday, I also got the ndiswrapper+windows driver setup to connect to the
router with WEP. The connection was up all night and it didn't go out even once.
So it seems to me that the hardware is OK or the ndiswrapper+windows setup is
good at hiding errors and recovering from it. Also I don't see any messages in
the logs from the touchpad driver, so I guess there probably isn't any IRQ
conflict. 

Shreyas. 

(In reply to comment #13)
> You can get the windows version of the Intel driver at
http://www.intel.com/support/wireless/wlan/sb/
> cs-010623.htm You will need cabextract to extract the files out of this exe
file. Once you have it 
> extracted you will have to find the .inf file (there are three inf files in it
because it has drivers for 2100, 
> 2200 and 3945). I think it is called NETw39x5.inf. Then follow the
instructions at the ndiswrapper wiki 
> to install it and configure it to associate with the router. 
> 
> Shreyas. 

Thanks Shreyas, I'm going to try this and test today. I had grabbed the files
previously but thought that cabextract was *just* for win CAB files. There was a
link to an exe extractor but when I tried it originally (this was a little hwile
back) the link was dead. Either way I will try this and report back with my results.

--
Lonny

-=UPDATE=-

Ok so after playing with dkms in Mandriva I finally got ndiswrapper working with
the Windows driver ... so far I'm at about 2.5 hours I'm sitting around 48
degrees (acpi value). I've dissabled my cabled line so the only interface I have
active is the 3945 from time to time the WiFi light was blinking but the machine
never slowed down at all or reported an issue ... after checking some logs I
found that it only happens when I try to check with an ntp server and has
nothing to do with this problem.

So with ndiswrapper and the win drivers, everything works fine with ONE
exception ... running kwifimanager shows my connected speed but will not show my
signall strength :(  ... other then that the connection so far has been solid
(I'm using it as I type now with not one hicup).

Either way I'd still much rather run a Linux native driver so I'm willing to
test anything you may have as suggestions or patches etc.

--
Lonny

MORE INFO

Ok I know what happened with the ntpd thing and it is related ... kind of. The
error I got was a result of me switching interfaces as a primary ... I had to
restart ntpd with the new wlan0 interface being the only active one and the
errors stopped. The WiFi light still blinks once in a while (4-5 times very
systematic, not like traffic based) but it doesn't affect the connection or
system at all and now ... no logs are being generated at all regarding
networking using the ndiswrapper and win driver.

I had this running in the background (pinging my default gw):
34091 packets transmitted, 34091 received, 0% packet loss

Okay, thanks for all that ... now we'll need some time on our end to try to 
figure out what's going on.  Sounds like a problem in our driver.

Really appreciate your investigation.

-- Ben --

(In reply to comment #20)

> Really appreciate your investigation.

well we really appreciate your guys' work on this ... the least we can do is
help however we can. Thanks for all the effort!!

--
Lonny

I noticed that the logs show that a scan is in progress when the ucode error 
occurs ... maybe we're not asking for enough dwell time on each channel, that 
is maybe we're asking the radio to tune *too often* to a new channel.

Could you guys experiment with the following in ipw3945.c??

First, try disabling the "quiet" scan feature by setting the following to 0 
(see comments in code):

IPW_PLCP_QUIET_THRESH

If that doesn't fix it, try experimenting with the following, making them 
longer (and keep IPW_PLCP_QUIET_THRESH 0):

IPW_ACTIVE_DWELL_TIME_24 (20)
IPW_ACTIVE_DWELL_TIME_52 (10)

If you look in the logs, there is an indication of how long the 3945 stays 
("dwells") on the channel (search for "usec").  "ms" shows a similar thing, 
but it is the time between scan *starts*.  Your goal is to get those numbers 
*larger*, so we're not asking the radio to tune as quickly from channel to 
channel:

ipw3945: I ipw_rx_handle Scan start: 1 [802.11bg] (TSF: 0x00000000:00000A7C) - 
1 (beacon timer 99716)
ipw3945: I ipw_rx_handle Scan ch.res: 1 [802.11bg] (TSF: 0x00000000:000023FF) -
 0 elapsed=6531 usec (3256ms since last)
ipw3945: I ipw_rx_handle Scan start: 2 [802.11bg] (TSF: 0x00000000:000027B9) - 
1 (beacon timer 92231)
ipw3945: I ipw_rx_handle Scan ch.res: 2 [802.11bg] (TSF: 0x00000000:00004185) -
 0 elapsed=6604 usec (8ms since last)
ipw3945: Microcode SW error detected.  Restarting.


This is just a hunch ... I don't have the same problem on my platform, so it's 
difficult for me to experiment.  I appreciate your help.

-- Ben --

(In reply to comment #22)
> First, try disabling the "quiet" scan feature by setting the following to 0 
> (see comments in code):
> 
> IPW_PLCP_QUIET_THRESH
> 
> If that doesn't fix it, try experimenting with the following, making them 
> longer (and keep IPW_PLCP_QUIET_THRESH 0):
> 
> IPW_ACTIVE_DWELL_TIME_24 (20)
> IPW_ACTIVE_DWELL_TIME_52 (10)

Both suggestions don't seem to work for me. I changed IPW_PLCP_QUIET_THRESH from
(1) to (0) and then increased the IPW_ACTIVE_DWELL_TIME_24 and
IPW_ACTIVE_DWELL_TIME_52 from 20-2000 and 10-1000 respectively with various
intermediate values. So far I haven't hit any magic combination that works. At
around 2000/1000 combination, the wireless wouldn't associate with the router
(both with and without encryption). 

Also in the comments in ipw3945.c, it says that the IPW_PASSIVE_DWELL_TIME
should be longer than the active dwell time. Is that something that could be the
problem? I did try increasing the passive dwell time to be the same as active
dewll time for the combination 24/52->200/100 msec. But that didn't help, the
same microcode errors show up. I am attaching the dmesg output for this case.

Let me know if you want dmesg output for other dwell time combinations.

Shreyas. 

Created an attachment (id=916) [details]
ipw3945 dmesg output for modified dwell time 

dmesg output for the following combination of dwell times. 

#define IPW_ACTIVE_DWELL_TIME_24    (200)	/* all times in msec */
#define IPW_ACTIVE_DWELL_TIME_52    (100)

/* For faster active scanning, scan will move to the next channel if fewer than

 * PLCP_QUIET_THRESH packets are heard on this channel within
 * ACTIVE_QUIET_TIME after sending probe request.  This shortens the dwell
 * time if it's a quiet channel (nothing responded to our probe, and there's
 * no other traffic).
 * Disable "quiet" feature by setting PLCP_QUIET_THRESH to 0. */
#define IPW_PLCP_QUIET_THRESH	    (0) /* packets */
#define IPW_ACTIVE_QUIET_TIME	    (5) /* msec */

/* For passive scan, listen PASSIVE_DWELL_TIME (msec) on each channel.
 * Must be set longer than active dwell time.
 * For the most reliable scan, set > AP beacon interval (typically 100msec). */

#define IPW_PASSIVE_DWELL_TIME_24   (200)	/* all times in msec */
#define IPW_PASSIVE_DWELL_TIME_52   (100)
#define IPW_PASSIVE_DWELL_BASE	    (100)
#define IPW_CHANNEL_TUNE_TIME	    5

bummer, I was hoping that would be the magic ... thanks for the excellent 
experimentation and reporting.

I'll need to do some more investigation.

-- Ben --

I don't know if this will help, but I've seen other reports that seem very
similar. Example:
https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/48395

Common threads seem to be Core Duo and SMP kernels.

(In reply to comment #26)

> Common threads seem to be Core Duo and SMP kernels.

Thanks for the information. I have only used the ipw3945 driver with an SMP
kernel, so don't know if the problem exists in a non-smp kernel. However, the
ndiswrapper+windows driver seems to work fine with the smp kernel. 

Ben: Any ideas if an SMP kernel (dual core) would cause issues with ipw3945? I
can test the theory by running a non-smp kernel, but just want to know if it
would be a worthwhile test. 

Shreyas. 

Thanks for the tip, James.

Shreyas, if it's not too much trouble, that sounds like a very interesting 
experiment.  Thanks.

-- Ben --

(In reply to comment #28)
> Thanks for the tip, James.
> 
> Shreyas, if it's not too much trouble, that sounds like a very interesting 
> experiment.  Thanks.

OK. Will try to do this by this weekend and post the results.

Shreyas. 

Created an attachment (id=922) [details]
dmesg output for non-smp kernel with Microcode SW errors

Hi Ben,

I compiled linux 2.6.17.11 (vanilla from kernel.org), disabled SMP and used the
in-kernel IEEE80211 to compile ipw3945.1.1.0. 

#uname -a 
Linux dhruva 2.6.17.11 #1 Sun Sep 3 10:54:41 EDT 2006 i686 GNU/Linux

The errors still show up. I have attached the dmesg output with debug=0x43fff.
Let me know if there is any other test you would want me to try out. 

The dmesg output I have attached here is for settings

#define IPW_ACTIVE_DWELL_TIME_24    (20)	/* all times in msec */
#define IPW_ACTIVE_DWELL_TIME_52    (10)

/* For faster active scanning, scan will move to the next channel if fewer than


 * PLCP_QUIET_THRESH packets are heard on this channel within
 * ACTIVE_QUIET_TIME after sending probe request.  This shortens the dwell
 * time if it's a quiet channel (nothing responded to our probe, and there's
 * no other traffic).
 * Disable "quiet" feature by setting PLCP_QUIET_THRESH to 0. */
#define IPW_PLCP_QUIET_THRESH	    (0) /* packets */
#define IPW_ACTIVE_QUIET_TIME	    (5) /* msec */

/* For passive scan, listen PASSIVE_DWELL_TIME (msec) on each channel.
 * Must be set longer than active dwell time.
 * For the most reliable scan, set > AP beacon interval (typically 100msec). */


#define IPW_PASSIVE_DWELL_TIME_24   (20)	/* all times in msec */
#define IPW_PASSIVE_DWELL_TIME_52   (10)
#define IPW_PASSIVE_DWELL_BASE	    (100)
#define IPW_CHANNEL_TUNE_TIME	    5


I also tried using the driver with settings 200/100 for both active and passive
dwell times (24/52), and the Microcode SW errors show up. 

Let me know if you have any other tests that I can run for you.

Shreyas. 

Thanks, Shreyas, for all that ... very helpful to narrow things down a bit ... 
this is a tough one.

-- Ben --

Just an update ... I think we'll need firmware/ucode with a working event log to
really chase this one down (current ucode's event log is broken, unfortunately)
... it may be a while before we can get that out, sorry to say.  Keep using the
NDIS wrapper workaround for now, and thanks again for your help.

-- Ben --

I can report that I am having the exact same problems on a Sony VGN-TXN15P
laptop with Mandriva 2007.0.  After a while, one will see the wireless light
blink and the network connection will be lost, “Microcode SW error detected. 
Restarting.” will appear in /var/log/messages.  Often followed by ifplugd
stopping and restarting the interface.  All the while, the machine will have
very noticeable freezes and pauses... lasting for a few seconds.  If long
enough, KDE might also report a loss in network connection, then reestablishment.

Sorry that I can't add any new insight or useful information.  But the problem
is wide-spread.

Hi, 

I was wondering if there was any progress on this issue. While, the ndiswrapper workaround works, it is 
not satisfactory. I still haven't been able to get WPA working on it, and also it doesn't play with with 
suspends. 

Shreyas. 

We are making good progress on getting new uCode out that will support the 
Event Log, so we'll (hopefully) be able to see what's going on in your 
situation.

Thanks for your patience.

-- Ben --

I'd just like to confirm this bug, on a Lenovo Thinkpad z61t, with Core 2 Duo. 
Microcode version 1.13, Ubuntu Edgy.

I did some experimentation with the IRQ assignment.  First, I booted Windows to
see what it was doing with the IRQ and it was assigning it to 17 (and no
sharing).  Then I booted Linux and checked /proc/interrupts

66:      27486          0   IO-APIC-level  uhci_hcd:usb2, ohci1394, ipw3945, HD
Audio

My other laptop, also with the ipw3945 but without this behavior:
217:   73760852          0   IO-APIC-level  uhci_hcd:usb4, ipw3945

I removed the modules related to uhci_hcd, ohci1394, and HD Audio.  Since then
(roughly two hours), while there have been three cases of a microcode error,
they only happened once and everything was working again. No lagging, no jagged
mouse movement, etc.  If it wasn't for watching syslog I wouldn't have known it
reset.

I'm wondering if anyone else who's experiencing this bug could see if this also
helped them.  I haven't looked to see how to assign the ipw3945 to its own IRQ
yet, but so far this seems much better.

>I did some experimentation with the IRQ assignment.

I am not sure that is relevant.  I can often go hours with only minor firmware
errors (sometimes none).  Other times, the machine is completely unusable there
are so many errors.  I never change or try to configure the IRQ assignments.  It
seems much more upset at home, in managed mode than it does at dinner playing
Monopoly against another laptop in Ad-Hoc mode.

I have tried for weeks to find some reason for why it goes crazy sometimes and
not others with no success.... but on mine, it is not IRQ related.

Created an attachment (id=960) [details]
Preliminary uCode to fix tuner problem

Attached is new uCode that will hopefully clear up this tuner problem (and it
has the Event Log enabled).

Please try it and let me know how it works for you.

Thanks!

-- Ben --

BTW, please don't redistribute the attached uCode ... it is preliminary 
stuff.  If it works out, we'll post it in the usual place.

-- Ben --

(In reply to comment #40)
> BTW, please don't redistribute the attached uCode ... it is preliminary 
> stuff.  If it works out, we'll post it in the usual place.
> 
> -- Ben --

Consider it not distributed ... and so far ... it's looking stable! I'll test
heavier tomorrow but I've had it running now for a while with no locks at all.
The wifi light went crazy a couple of times but previously that would make my
machine unuseable and lock up my mouse and keyboard ... so far not a flutter!!

I'll keep you posted on any changes but right now it's looking good. Thanks for
all your work.

Will need more time to test it, but I have been using it for a while now and it
hasn't gone crazy like it usually does.

I am going to a TWUUG (TideWater Unix User's Group) meeting tonight, and last
time I tried to connect to the wireless there it went instantly and continuously
insane.  Will let you know after more testing.  So far so good.

Thank you so much for addressing these issues!

So far 5 hours and not one issue!! I think whatever it was, you've nailed it.
I'll keep everything running for a while but I'm thinking this bug has been
squashed.  Thanks again everyone!!

Lonny

Hi,

The preliminary uCode seems to work. The wifi led remains solid and there are no
errors showing up in dmesg despite heavy network activity. The connection has
been stable for about an hour now. I will keep monitoring it over the weekend
and report back again next week. 

Thanks for the fix. 

Shreyas

Thanks for the reports!

We'll get new uCode posted as soon as we can.

-- Ben --

The new ucode fixes this problem on my laptop as well. Specs:

HP nc6320
T7400 Core2 Duo
2G RAM
Ubuntu 7.04 (feisty development release)
2.6.19
ipw3945 1.1.2
ieee80211 git-1.1.13

I've been using the new microcode for about a week or so now.  It's been
absolutely flawless at home.  It's been mostly flawless while on the road and
using WEP.  No idea if WEP is a factor or not, but I have had periods of
multiple resets, ranging from 10 seconds to 30 seconds.  They're not happening
often, maybe a half-dozen times in the span of three hours.

I'm not sure how the new event log in the microcode works, if there's a log it's
creating or if I need to enable that explicitly, but if there is I can post
what's happening when it does reset.


Great works guys!

Thanks for the report.

The uCode Event Log appears in the regular driver log (./load debug=0x43fff) 
when a uCode error occurs.

You can also dump it at will via:

cd /sys/bus/pci/drivers/ipw3945/0  (press Tab to fill in the rest)
echo 1 > dump_events  (or something quite similar)

... But you shouldn't really need to do that.

Use dmesg (or look in /var/log/messages) to view the driver log.

-- Ben --

For whatever reason, it's gotten bad over the last 24 hours, where it had been
solid for a week.  I enabled the event log, and here's the output after a few
restart cycles:

[17252642.948000] ipw3945: Start IPW Event Log Dump: count 256 type 0x00
[17252642.948000] ipw3945: 0x00000001   0x0000016d
[17252642.948000] ipw3945: 0x00000001   0x008056e0
[17252642.948000] ipw3945: 0x00000001   0x008056fc
[17252642.948000] ipw3945: 0x00000001   0x00000000
[17252642.948000] ipw3945: 0x00000001   0x00000177
[17252642.948000] ipw3945: 0x00000001   0x008056e0
[17252642.948000] ipw3945: 0x00000001   0x00805704
[17252642.948000] ipw3945: 0x00000001   0x00000000
[17252698.400000] ipw3945: Microcode SW error detected.  Restarting.
[17252698.400000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252698.400000] ipw3945: Can't stop Rx DMA.
[17252699.772000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252700.116000] ipw3945: Microcode SW error detected.  Restarting.
[17252700.116000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252700.116000] ipw3945: Can't stop Rx DMA.
[17252701.488000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252705.968000] ipw3945: Microcode SW error detected.  Restarting.
[17252705.968000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252705.968000] ipw3945: Can't stop Rx DMA.
[17252707.340000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252707.772000] ipw3945: Microcode SW error detected.  Restarting.
[17252707.772000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252707.772000] ipw3945: Can't stop Rx DMA.
[17252709.144000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252711.104000] ipw3945: Microcode SW error detected.  Restarting.
[17252711.104000] ipw3945: Error Reply type 0x000000FF cmd DAEMON (0x10) seq
0x040D ser 0x00030000
[17252711.596000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[17252711.596000] ipw3945: Can't stop Rx DMA.
[17252712.964000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252819.056000] ipw3945: Desc       Time       asrtPC     const      ilink1  
  nmiPC      Line
[17252831.452000] ipw3945: Microcode SW error detected.  Restarting.
[17252831.452000] ipw3945: Error Reply type 0x000000FF cmd DAEMON (0x80) seq
0x441A ser 0x00030000
[17252831.452000] ipw3945: Can't stop Rx DMA.
[17252832.824000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252833.172000] ipw3945: Microcode SW error detected.  Restarting.
[17252833.172000] ipw3945: Error Reply type 0x000000FF cmd LEDS_CMD (0x48) seq
0x040A ser 0x00030000
[17252833.172000] ipw3945: Can't stop Rx DMA.
[17252834.164000] psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 4 bytes away.
[17252834.536000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252834.896000] ipw3945: Microcode SW error detected.  Restarting.
[17252834.896000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252834.900000] ipw3945: Can't stop Rx DMA.
[17252836.268000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252836.604000] ipw3945: Microcode SW error detected.  Restarting.
[17252836.604000] ipw3945: Error Reply type 0x000000FF cmd LEDS_CMD (0x48) seq
0x040A ser 0x00030000
[17252836.604000] ipw3945: Can't stop Rx DMA.
[17252837.976000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252839.916000] ipw3945: Microcode SW error detected.  Restarting.
[17252839.916000] ipw3945: Error Reply type 0x000000FF cmd DAEMON (0x10) seq
0x040D ser 0x00030000
[17252840.408000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[17252840.408000] ipw3945: Can't stop Rx DMA.
[17252841.776000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252842.168000] ipw3945: Microcode SW error detected.  Restarting.
[17252842.168000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252842.168000] ipw3945: Can't stop Rx DMA.
[17252843.164000] psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 5 bytes away.
[17252843.540000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252843.900000] ipw3945: Microcode SW error detected.  Restarting.
[17252843.900000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252843.900000] ipw3945: Can't stop Rx DMA.
[17252845.268000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252845.608000] ipw3945: Microcode SW error detected.  Restarting.
[17252845.608000] ipw3945: Error Reply type 0x000000FF cmd LEDS_CMD (0x48) seq
0x040A ser 0x00030000
[17252845.612000] ipw3945: Can't stop Rx DMA.
[17252846.980000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252851.432000] ipw3945: Microcode SW error detected.  Restarting.
[17252851.432000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252851.432000] ipw3945: Can't stop Rx DMA.
[17252852.804000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252853.140000] ipw3945: Microcode SW error detected.  Restarting.
[17252853.140000] ipw3945: Error Reply type 0x000000FF cmd LEDS_CMD (0x48) seq
0x040A ser 0x00030000
[17252853.140000] ipw3945: Can't stop Rx DMA.
[17252854.512000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252854.872000] ipw3945: Microcode SW error detected.  Restarting.
[17252854.872000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252854.872000] ipw3945: Can't stop Rx DMA.
[17252856.244000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252856.616000] ipw3945: Microcode SW error detected.  Restarting.
[17252856.616000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252856.616000] ipw3945: Can't stop Rx DMA.
[17252857.988000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252866.652000] ipw3945: Microcode SW error detected.  Restarting.
[17252866.652000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252866.652000] ipw3945: Can't stop Rx DMA.
[17252868.020000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252869.964000] ipw3945: Microcode SW error detected.  Restarting.
[17252869.964000] ipw3945: Error Reply type 0x000000FF cmd DAEMON (0x10) seq
0x040D ser 0x00030000
[17252870.456000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[17252870.456000] ipw3945: Can't stop Rx DMA.
[17252871.824000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)
[17252872.204000] ipw3945: Microcode SW error detected.  Restarting.
[17252872.204000] ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000
ser 0x00030000
[17252872.204000] ipw3945: Can't stop Rx DMA.
[17252873.572000] ipw3945: Detected geography ABG (11 802.11bg channels, 13
802.11a channels)

This actually looks like output from the *old* uCode (evidenced by mere 8-
entry Event Log that always shows the same stuff).  Make sure that you're 
using the new uCode ... I hope that clears it up.

-- Ben --

BTW, next time you send a log, please "Create a New Attachment" ... this bug 
entry is already mighty long.  Thanks.  :-)

Alright, I feel completely foolish.  There was a kernel update (Ubuntu) the
other day and it overwrote the new microcode.  Sorry for the noise (and I'll
create an attachment next time)

Thanks Ben

Thanks for the report, Adam, glad to know what happened.

-- Ben --

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

I was seeing the same issue on a dell e1705 with the 3945. The new microcode
fixed it. I've been rsyncing a multigigabyte vorbis & mp3 collection for over an
hour without issues.

Fixed for me as well. Dell e1705 running Ubuntu 6.10 (Edgy).

I have the same problems with 1.2.0 and ucode 1.14.2.
----
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Error Reply type 0x00000005 cmd DAEMON (0x80) seq 0x440A ser 0x004A0000
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Error Reply type 0x00000005 cmd LEDS_CMD (0x48) seq 0x040A ser 0x004A0000
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Error Reply type 0x00000005 cmd LEDS_CMD (0x48) seq 0x0408 ser 0x004A0000
ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Error Reply type 0x00000005 cmd LEDS_CMD (0x48) seq 0x0409 ser 0x004A0000
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Error Reply type 0x00000005 cmd DAEMON (0x10) seq 0x0406 ser 0x004A0000
ipw3945: Error sending LEDS_CMD: time out after 500ms.
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
------
wasn't this supposed to fix this? :(
any idea/solution or any info that I can provide to help?

There are many reasons that a uCode error can occur.  The new uCode fixed a 
few that were related to the tolerances of hardware components on the board.

Try starting your driver using:

./load debug=0x43fff

That should give us a lot more information about the problem.  Please *do* use 
the new 1.14.2 ... it emits an event log that we can look at to help diagnose.

Please open a new bug for this, and attach your log as an attachment (not 
within the body of your comments).

-- Ben --

This seems to be the same as bug #1260

Have you given up on fixing this bug? It's very annoying.

I have a Dell 640m Laptop with a Core 1 Duo CPU. When I connect to an encrypted
wireless (not sure if the encryption is required) and do a fast data transfer
(my 2 mBit DSL line won't trigger it, but transferring some 10 mBit from a
computer in the local network will), this happens for me as well.

Some of the changes (maybe the firmware update, maybe a driver version update)
have made the effects less bad, but it still disconnects and it takes some 30
seconds to reconnect.

I have however (due to a post in bug report #1260) now built my kernel WITH FULL
PREEMPTION. This seems to have made the problem occur much less often.

My best guess is that something is locking and the driver runs into a timeout
(most people have reported other interruption effects such as drivers losing
synchronization or sound being disrupted), causing the restart. And with
preemption, the kernel probably reacts earlier.

Note that this might be related to Dell Bios. Before enabling preemption,
dellWirelessCtl was causing a similar system interruption if I recall correctly.
So you might want to get hold of a Dell system showing these symptoms for
testing. Common features seem to be SMP, non-preempt kernel. You might want to
try Debian, the stock kernel is reported to show this problem.

The AP seems to be pretty irrelevant. I've seen it with AVM Fritz!Box and some
Cisco APs at the university, reports here are with Linksys

See bug #1260.

-- Ben --

Oooops, Yi's work is with 2200, not 3945!

But there sure are a lot of the spin_lock_irqsave()s in 3945/4965, too.

-- Ben --

ipw3945 as a driver has been replaced by iwl3945 in official kernel for a long
time. We suggest to use iwl3945 driver instead of the obsolete ipw3945 driver.
If you have bug, please report it with product=iwlwifi and platform="Intel(R)
Wifi Link 3945". Thanks so much!