Latest working kernel version: none Earliest failing kernel version: 2.6.27-rc3 Distribution: Debian Sid (amd64) Hardware Environment: Sony Vaio SR11M, P8400 processor, 4GB RAM, Intel ProWireless 5100AGN Software Environment: Linux 2.6.27-rc5 x86_64, Debian-amd64 Sid, /lib/firmware/iwlwifi-5000-1.ucode Problem Description: Even though the kernel says that the firmware was loaded properly and the Intel 5100AGN card is recognized (iwconfig will show 'fake' info about the ethernet device), the card doesn't associate to any network, it cannot be used to search networks (iwlist wlan0 scan gives: 'No scan results') Steps to reproduce: ~# ifconfig wlan0 up ~# echo "0" > /sys/class/net/wlan0/device/rfkill/rfkill0/state ~# cat /sys/class/net/wlan0/device/version This will show the message: 'fw not loaded' Output of dmesg is the following: iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks iwlagn: Copyright(c) 2003-2008 Intel Corporation iwlagn 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 iwlagn 0000:04:00.0: setting latency timer to 64 iwlagn: Detected Intel Wireless WiFi Link 5100AGN REV=0x54 iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels iwlagn 0000:04:00.0: PCI INT A disabled phy0: Selected rate control algorithm 'iwl-agn-rs' iwlagn 0000:04:00.0: enabling device (0000 -> 0002) iwlagn 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 iwlagn 0000:04:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) iwlagn 0000:04:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xd1900004) iwlagn 0000:04:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) iwlagn 0000:04:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006) firmware: requesting iwlwifi-5000-1.ucode iwlagn: Radio disabled by HW RF Kill switch iwlagn: WARNING: Requesting MAC access during RFKILL wakes up NIC
And if you don't do the "echo 0" line? Then can you read the sysfs version file? The "echo 0" line puts the device in a "software rfkill" state. It looks to me like the driver responds by putting the firmware into disabled state, it stops reply to alive messages, and gets marked as not OK. This eventually results in your 'fw not loaded' message above. I guess what I am saying is that it isn't clear to me that this is a bug. What did you expect the result to be? Why do you need the example to "work"?
bugme-daemon@bugzilla.kernel.org wrote: > And if you don't do the "echo 0" line? Then can you read the sysfs version > file? > > The "echo 0" line puts the device in a "software rfkill" state. It looks to > me > like the driver responds by putting the firmware into disabled state, it > stops > reply to alive messages, and gets marked as not OK. This eventually results > in > your 'fw not loaded' message above. Even not echoing "0", the wireless card doesn't work. Look at the output of dmesg when not having echoed "0" to the rfkill file in /sys: iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks iwlagn: Copyright(c) 2003-2008 Intel Corporation iwlagn 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 iwlagn 0000:04:00.0: setting latency timer to 64 iwlagn: Detected Intel Wireless WiFi Link 5100AGN REV=0x54 iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels iwlagn 0000:04:00.0: PCI INT A disabled phy0: Selected rate control algorithm 'iwl-agn-rs' iwlagn 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 iwlagn 0000:04:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006) firmware: requesting iwlwifi-5000-1.ucode iwlagn: START_ALIVE timeout after 4000ms. iwlagn 0000:04:00.0: PCI INT A disabled In order to avoid the message "iwlagn: START_ALIVE timeout after 4000ms.", echo "0" must be performed to rfkill/state in /sys. However, as I previously exposed in the bug report, if I echo "0" there, the wireless card doesn't work either. Tomas Winkler suggested that the 64bit fix hasn't been included in the linux-2.6.27-rc5.
Ah, well that fix has just been merged. Hopefully it will be in 2.6.27-rc6, if not then -rc7.
commit f0b9f5cb4adcec9424142592ca7bf024fe6c91a9 Author: Tomas Winkler <tomas.winkler@intel.com> Date: Thu Aug 28 17:25:10 2008 +0800 iwlwifi: fix 64bit platform firmware loading This patch fixes loading firmware from memory above 32bit. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Marcel Holtmann <holtmann@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hi John, Tomas Winkler told me that this patch wasn't merged into the 2.6.27-rc5. I guess you mean that it will be merged in rc6 or later, isn't it? At least, I have looked on the online git repositories and I didn't find any clue telling that this patch was in rc5 already.
Correct, it is in the commit listed in comment 4, which is between 2.6.27-rc5 and the forthcoming 2.6.27-rc6.
It works as of 2.6.27-rc5-git5, I have tested it and the following features work: - Mode managed with and without WEP key. - Search for networks (iwlist wlan0 scan). The following features don't work: - Monitor mode - Ad-hoc mode At least I can use my 5100AGN at a basic level, I hope the monitor and ad-hoc mode are coming soon. Thank you all for your great help. If you want me to further test any not-yet-supported feature, please let me know and I will be glad of helping the project.
By the way, I noticed a couple of issues in Managed Mode (using 2.6.27-rc5-git5). First, the Tx power is quite low (15dBm), whereas in very old USB sticks and other Intel ProWireless use to be 27dBm, and even more. Second, and I don't know if it is directly related to the Tx-power, the transmission speed cannot go higher than 600Kbits/s (about 75KB/s is the maximum I get in LAN, using a 802.11g-54Mbps access point). The rest of computers at home reach up to 2MB/s, but with the iwl-5000agn I don't get more than 75KB/s. I checked for a new microcode, but I don't find any new version, I'm still using the iwl-5000.ucode-5.4.A.11-1. Anybody using the Intel 5000AGN has this Tx and speed limitation problem?