On Fri, 2010-06-04 at 09:40 -0700, reinette chatre wrote: > On Thu, 2010-06-03 at 23:48 -0700, Johannes Berg wrote: > > On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote: > > > > > > Maybe try the rfkill tool: > > > > http://wireless.kernel.org/en/users/Documentation/rfkill > > > > > > Yes, it was the rfkill tool that caused my attempts to fail. However, > > > this didn't change my association attempt problems. > > > I also took my time to look at the PCIe port - steady 3.3V on the RFKILL > > > pin, which means "no RFKILL". > > > > > > Any further ideas? > > > > Unfortunately not. It would seem that something is causing your frames > > not to be transmitted correctly, but I see no reason for that right now. > > The logs provided contains a lot of useful information. Among this is > that the device is unable to transmit data with the firmware returning a > "TX_LOCKED" status. From what I understand this is a regulatory check > failure based on the channel type, which does not make sense in this > regard since from what I can tell channel 8, which is an active channel, > is used. I passed this question to our firmware folks and now waiting > for an answer. Unfortunately, since the firmware does not actually assert, the firmware folks are unable to dig into this. I tried to take a second look at your logs and one thing that I was able to see that is interesting is that, when scanning, the device picks up very few frames that are good. I see that there were five scans, none of which contained a since good frame on 5GHz. On 2.4GHz there was a bit better success, but not consistent. In the five scans there was the following on 2.4GHz: 1st scan: one good frame each on channels 5, 7, and 8. 2st scan: one good frame on channel 1 3st scan: one good frame each on channels 2, 7, and 9. 4st scan: one good frame each on channels 3, 5, 7, and 8. 5st scan: one good frame each on channels 1, 8, and 9. If you want to check on this yourself, take a look at the lines: [223263.179493] ieee80211 phy2: I iwl_rx_scan_results_notif Scan ch.res: 2 [802.11bg] (TSF: 0x00000000:05627B90) - 1 elapsed=33837 usec The number before "elapsed" indicates the number of good frames seen while scanning the channel. In the above example there was one. This seems to indicate that there is some trouble on this platform ... and makes me start thinking that this card may not work well on this platform. Some things you can try: - are any APs on A band? If not, can you try to activate an AP on A band to see if you have better success there? - monitor the RX statistics ... (/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_rx_stats) to see if there is an issue with crc checks and perhaps false alarms and plcp also. - something that you could try ... not sure how much it will help if you are having noise issues ... is to vary how you scan. Since you know which AP you are associating with, perhaps you can try to limit your scan to that channel ... and also try passive instead of active. This can be done with iw. These are the only things I can think of. Reinette -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
