Bugzilla – Bug 934
firmware error when transfer mode b/g to a mode in ad-hoc mode
Last modified: 2006-04-25 20:19:18
You need to log in before you can comment on or make changes to this bug.
In ad-hoc mode, first set channel to 4 or another b or g channel. then set to a band, it will cause firmware error and the driver could never be loaded. ipw3945: 3946ABG card ucode DOWNLOAD FAILED ipw3945: Unable to load firmware: -110 ipw3945: I ipw_net_hard_start_xmit Tx attempt while not associated. ipw3945: 3946ABG card ucode DOWNLOAD FAILED ipw3945: Unable to load firmware: -110 ipw3945: 3946ABG card ucode DOWNLOAD FAILED ipw3945: Unable to load firmware: -110 ipw3945: I ipw_net_hard_start_xmit Tx attempt while not associated Reproduce steps: #./load #iwconfig eth1 mode ad-hoc essid ipwadhoc channel 4 #iwconfig eth1 channel 48 #iwconfig =>shows nothing for eth1. #dmesg => find Microcode SW error detected. Restarting. and Unable to load firmware: -110. Then need to reload the driver manually.
Created an attachment (id=701) [details] dmesg caught by "./load debug=0x43fff"
The SYSASSERT that happens repeatedly on ucode line 1211 is a result of trying to *modify* a non-existant entry in the ucode's STA table. There's been some recent driver work in this regard ... I suggest assigning this bug to James or Mohammed.
I guess the problem we did reset the stations between resets which caused to insert the adhoc station in the wrong slot. I am currently testing a patch for adhoc enhancement that will take care of this, you can assigned this to me
Created an attachment (id=705) [details] Modified ad-hoc channel selection to pick a valid channel This patch is actually from Mohamed, but he didn't attach it so I am :)
Bumped to P1.
(In reply to comment #4) > Created an attachment (id=705) [edit] [details] > Modified ad-hoc channel selection to pick a valid channel > > This patch is actually from Mohamed, but he didn't attach it so I am :) This attachment was actually for a different ad-hoc related problem seen when switching from BG mode to A mode via 'iwpriv set_mode' when the first available A channel was not a valid channel for an ad-hoc network.
Created an attachment (id=721) [details] fix this bug and more apply against 0.70. this patch include what the previous patch has and more feature added to ad-hoc mode please try it out and let me know if does fix your problem.
fix and add new ad-hoc enhancement
(In reply to comment #8) > fix and add new ad-hoc enhancement Can you provide a patch that *just* fixes the problem causing the microcode error and a separate patch for the per station rate scaling (as a new bug filed as a feature enhancement?) We need to have the problem isolated in its code change so we can apply that to a stable tree. The per-station rate scaling needs to go into our unstable tree. Thanks, James
Created an attachment (id=764) [details] fix adhoc switch to a-band channel apply against 0.74
this patch only take care of fixing the Firmware issues instead of the huge patch
Merged for 1.0.1. Setting to Fixed.
Created an attachment (id=784) [details] debug=0x43fff Environment: ipw3945-1.0.2 ieee-1.1.13,ucode-1.13,deamon-1.7.18 kernel-2.6.15.3 When switched the channel from 4 to 48 dmesg log showed: "ipw_download_ucode 3945ABG card ucode DOWNLOAD is good" and no other FW error occurrd. But ad-hoc host can't be set up with a-band though 48 is an active channel .
In comment #13, >But ad-hoc host can't be set up with a-band though 48 is an active channel . I double checked 48 is not active in IBSS mode. verify this bug. In ad-hoc mode, there is no firmware error when transfer mode b/g to a mode. And the ad-hoc network can setup with a band such as band 149.