Bug 509 - ipw2200: failed to send tx_power
: ipw2200: failed to send tx_power
Status: VERIFIED FIXED
: IPW2200
IBSS
: 0.19
: All All
: P2 minor
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-12-21 06:41 by
Modified: 2005-10-05 14:22 (History)


Attachments
error_failed_sending_txpower.txt (24.62 KB, text/plain)
2004-12-21 06:41, Michał Świrydczuk
Details
error_log (25.39 KB, text/plain)
2005-01-14 07:18, Michał Świrydczuk
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-12-21 06:41:17
While creating IBSS network - execution of command: ./load; iwconfig eth1 essid 
test mode ad-hoc key off

such message can be seen:

ipw2200: Already sending a command
ipw2200: failed to send TX_POWER command

Few seconds later another message is displayed:

ipw2200: Overriding invalid channel

Execution of "iwconfig eth1 channel 1" creates IBSS network without any 
problems.
------- Comment #1 From 2004-12-21 06:41:39 -------
Created an attachment (id=199) [details]
error_failed_sending_txpower.txt
------- Comment #2 From 2004-12-21 07:47:02 -------
In Fedora2 IBSS network can be created as said above but in SuSE execution 
of ./load; iwconfig eth1 essid test mode ad-hoc key off 
cause mode to change for a while to ad-hoc and after half a second back to 
managed so IBSS network cant be created. 

The same situation occurs if command is separated to two commands, executed 
very quickly after each other:
./load
iwconfig eth1 essid test mode ad-hoc key off 
------- Comment #3 From 2005-01-01 09:00:27 -------
I get the same error after resuming from hibernate (S4) on a IBM Thinkpad X40. 
I need to reboot the machine to get the card working again: 
 
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 0.19 
ipw2200: Copyright(c) 2003-2004 Intel Corporation 
ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection 
ipw2200: failed to send TX_POWER command 
ipw2200: failed to send TX_POWER command 
ipw2200: failed to send TX_POWER command 
ipw2200: failed to send TX_POWER command 
ipw2200: failed to send TX_POWER command 
ipw2200: Unable to initialize device after 5 attempts. 
ipw2200: failed to register network device 
ipw2200: probe of 0000:02:02.0 failed with error -5 
 
 
------- Comment #4 From 2005-01-13 04:33:31 -------
Comment #3 is talking about a different bug. See bug 363.
------- Comment #5 From 2005-01-13 08:34:00 -------
Request from the bug scrub was to re-test this will distro network scripts 
disabled. Log:

logics	problem is two fold
logics	1) the distribution is setting the mode to managed
logics	2) while it is resetting the device back to managed, additional 
commands are coming in at the request of the user, which can not be executed 
due to concurrency issues, and so the messages are displayed
|<--	cis_ has left irc.freenode.net ("ChatZilla 0.9.61 [Mozilla 
rv:1.7.2/20040803]")
logics	we need a retest with all network configuration scripts disabled
soopel	ok
rustyl_	I susupect the correct way to test with Suse, is to use the tools they 
provide (GUI tools) instead of directly calling the command line tools
------- Comment #6 From 2005-01-14 07:18:24 -------
Retested with disabled network configuration scripts.
Attachment of dmesg output below (debug = 0xffff).

The problem with changing mode back to managed doesnt exist anymore but 
messages like below still are displayed:

ipw2200: Already sending a command
ipw2200: failed to send TX_POWER command

Few seconds later another message is displayed:

ipw2200: Overriding invalid channel


Repro:

./load debug=0xffff; iwconfig eth1 essid lala mode ad-hoc key off
------- Comment #7 From 2005-01-14 07:18:50 -------
Created an attachment (id=221) [details]
error_log
------- Comment #8 From 2005-01-15 21:51:00 -------
You may still see the messages relating to attempts to send a command while one
is active, but the driver should recover.  There was a race condition that could
occur that would result in the driver entering a state where it thought a
command was being sent during a NIC reset (as occurs during mode change)
------- Comment #9 From 2005-01-17 00:59:27 -------
verified