* [ath9k-devel] AR9260 hang during connection to AP @ 2009-02-11 14:17 Alex Williams 2009-02-11 14:38 ` Sujith 0 siblings, 1 reply; 15+ messages in thread From: Alex Williams @ 2009-02-11 14:17 UTC (permalink / raw) To: ath9k-devel Hello! My kernel version - 2.6.29-rc4-wl - from wireless testing git repository. My card mini PCI, based on AR9260 chipset. 00:05.0 Network controller: Atheros Communications Inc. Device 0027 (rev 01) If I setting "iwconfig wlan1 essid id" then system is hangs and stop reacting on keyboard and other devices... 0) insmod ath9k.ko debug=0xFFFFFFFF 1) ifconfig wlan1 up [ 161.141947] [ 161.143586] [ 161.170654] ADDRCONF(NETDEV_UP): wlan1: link is not ready 2) iwconfig wlan1 essid zx ... < many empty kernel printk mesasges > [ 181.659150] [ 181.690218] queue 3 [ 181.755139] [ 181.849091] ... < many empty kernel printk mesasges during several seconds> [ 187.071684] [ 187.165765] [ 187.259766] [ 194.891316] Clocksource tsc unstable (delta = 4687389681 ns) <and there system is totally hangs...> //------------------------- I have questions: 1) How to fix this problem? Did ath9k ever work with AR9260? 2) Where I can get documentation for AR5*** and AR9*** chipsets? Does it released for public access? ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 14:17 [ath9k-devel] AR9260 hang during connection to AP Alex Williams @ 2009-02-11 14:38 ` Sujith 2009-02-11 16:05 ` Alex Williams 0 siblings, 1 reply; 15+ messages in thread From: Sujith @ 2009-02-11 14:38 UTC (permalink / raw) To: ath9k-devel Alex Williams wrote: > Hello! My kernel version - 2.6.29-rc4-wl - from wireless testing git repository. > My card mini PCI, based on AR9260 chipset. > 00:05.0 Network controller: Atheros Communications Inc. Device 0027 (rev 01) I think you mean AR9160. To confirm, can you post the output of sudo lspci -v ? > If I setting "iwconfig wlan1 essid id" then system is hangs and stop > reacting on keyboard and other devices... > > 0) insmod ath9k.ko debug=0xFFFFFFFF 0xFFFFFFFF is probably overkill. You can modprobe with debug=0x2000, which will produce a reasonable debug output. Also can you post the dmesg immediately after loading ath9k with this debug mask ? > 1) ifconfig wlan1 up > [ 161.141947] > [ 161.143586] > [ 161.170654] ADDRCONF(NETDEV_UP): wlan1: link is not ready > > 2) iwconfig wlan1 essid zx > ... < many empty kernel printk mesasges > > [ 181.659150] > [ 181.690218] queue 3 > [ 181.755139] > [ 181.849091] > ... < many empty kernel printk mesasges during several seconds> > [ 187.071684] > [ 187.165765] > [ 187.259766] > [ 194.891316] Clocksource tsc unstable (delta = 4687389681 ns) > <and there system is totally hangs...> Are you able to at least scan, before trying to associate with an AP ? If so, then switch to a VT and try to associate and see if the kernel panics. A digital photograph of the panic (if one occurs) would be great. > 1) How to fix this problem? Did ath9k ever work with AR9260? I haven't tried ath9k with any mini-PCI card so far, will dig around to see if I can find one. > 2) Where I can get documentation for AR5*** and AR9*** chipsets? Does > it released for public access? The code is the documentation. :) Sujith -- http://sujith-m.blogspot.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 14:38 ` Sujith @ 2009-02-11 16:05 ` Alex Williams 2009-02-11 16:49 ` Sujith 0 siblings, 1 reply; 15+ messages in thread From: Alex Williams @ 2009-02-11 16:05 UTC (permalink / raw) To: ath9k-devel Thank you for reply! Please, tell me: did you saw working card on ar9160 ever??? May be with other interfaces, such as PCI or USB? Is support for ar9160 finished? Or it's now unusable? > I think you mean AR9160. > To confirm, can you post the output of sudo lspci -v ? 00:05.0 Network controller: Atheros Communications Inc. Device 0027 (rev 01) Subsystem: Atheros Communications Inc. Device 2082 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10 Memory at e1020000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 I can read mark on the chip - ar9160-bc1a - you right. > 0xFFFFFFFF is probably overkill. > You can modprobe with debug=0x2000, which will produce a reasonable debug output. > Also can you post the dmesg immediately after loading ath9k with this debug mask ? insmod ath9k.ko debug=0x2000 [ 121.839737] ath9k 0000:00:05.0: PCI INT A -> Link[LN_B] -> GSI 10 (level, low) -> IRQ 10 modprobe: FATAL: Could not load /lib/modules/2.6.29-rc4-wl/modules.dep: No such file or directory [ 123.479199] cfg80211: Calling CRDA for country: US [ 123.507201] udev: renamed network interface wlan0 to wlan1 [ 123.512965] Registered led device: ath9k-phy0::radio [ 123.546520] Registered led device: ath9k-phy0::assoc [ 123.589623] Registered led device: ath9k-phy0::tx [ 123.614561] cfg80211: Regulatory domain changed to country: US [ 123.620474] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 123.628382] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) [ 123.635228] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) [ 123.642074] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 123.648921] (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 123.655907] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 123.685508] Registered led device: ath9k-phy0::rx [ 123.727397] phy0: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0: mem=0xcf520000, irq=10 insert ath9k.ko [ 124.070622] ADDRCONF(NETDEV_UP): wlan1: link is not ready > Are you able to at least scan, before trying to associate with an AP ? > If so, then switch to a VT and try to associate and see if the kernel panics. > A digital photograph of the panic (if one occurs) would be great. To perform scan, we need to "up" interface. Strange, but now, after ifconfig wlan1 up - system hang deadly without any explanations! T_T But sometimes it continue work after module load... >> 1) How to fix this problem? Did ath9k ever work with AR9260? > I haven't tried ath9k with any mini-PCI card so far, will dig around to see > if I can find one. OK >> 2) Where I can get documentation for AR5*** and AR9*** chipsets? Does >> it released for public access? > The code is the documentation. :) Really??? ^_^ It's impossible! Is there some datasheet on ar9160??? How about register addresses and their purpose? How can you write driver for device if you do not know how it actually works? Writing drivers it's like an embedded programming on microcontrolles without OS - you should know every register and it's purpose. And even this knowledge not guarantee errors proof... Sorry, I'm just wondering how this possible... I heards that for ath9k Atheros released specifications, or they writing in-house driver?.. Please, more info, how it's really developing... =) P.S. How to enable additional debug info? Can I use KDBG + /dev/ttyS0 to search for the problem? :) P.P.S. Please, give me a link to git tutorial. I want to modifi some wireless files, but keep ability to update them by "git pull"... Sorry, I'm newbie... ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 16:05 ` Alex Williams @ 2009-02-11 16:49 ` Sujith 2009-02-11 21:00 ` Alex Williams ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Sujith @ 2009-02-11 16:49 UTC (permalink / raw) To: ath9k-devel Alex Williams wrote: > Thank you for reply! > Please, tell me: did you saw working card on ar9160 ever??? May be > with other interfaces, such as PCI or USB? Is support for ar9160 > finished? Or it's now unusable? No idea. But I found a mini-PCI AR9160 card and it works fine here. > insmod ath9k.ko debug=0x2000 > [ 121.839737] ath9k 0000:00:05.0: PCI INT A -> Link[LN_B] -> GSI 10 > (level, low) -> IRQ 10 > modprobe: FATAL: Could not load > /lib/modules/2.6.29-rc4-wl/modules.dep: No such file or directory > [ 123.479199] cfg80211: Calling CRDA for country: US > [ 123.507201] udev: renamed network interface wlan0 to wlan1 > [ 123.512965] Registered led device: ath9k-phy0::radio > [ 123.546520] Registered led device: ath9k-phy0::assoc > [ 123.589623] Registered led device: ath9k-phy0::tx > [ 123.614561] cfg80211: Regulatory domain changed to country: US > [ 123.620474] (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > [ 123.628382] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) > [ 123.635228] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) > [ 123.642074] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > [ 123.648921] (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) > [ 123.655907] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) > [ 123.685508] Registered led device: ath9k-phy0::rx > [ 123.727397] phy0: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0: > mem=0xcf520000, irq=10 > insert ath9k.ko > [ 124.070622] ADDRCONF(NETDEV_UP): wlan1: link is not ready CONFIG_ATH9K_DEBUG should be enabled in your kernel .config to enable debugging. See: http://wireless.kernel.org/en/users/Drivers/ath9k > > Are you able to at least scan, before trying to associate with an AP ? > > If so, then switch to a VT and try to associate and see if the kernel panics. > > A digital photograph of the panic (if one occurs) would be great. > > To perform scan, we need to "up" interface. Strange, but now, after > ifconfig wlan1 up - system hang deadly without any explanations! T_T > But sometimes it continue work after module load... Did you switch to a VT to see if a panic happens on bringing up the interface ? > Really??? ^_^ It's impossible! Is there some datasheet on ar9160??? > How about register addresses and their purpose? How can you write > driver for device if you do not know how it actually works? Writing > drivers it's like an embedded programming on microcontrolles without > OS - you should know every register and it's purpose. And even this > knowledge not guarantee errors proof... Sorry, I'm just wondering how > this possible... I heards that for ath9k Atheros released > specifications, or they writing in-house driver?.. Please, more info, > how it's really developing... =) > AR9160 is supported by ath9k, so no worries here. > How to enable additional debug info? Can I use KDBG + /dev/ttyS0 to > search for the problem? :) Search for serial console / netconsole debugging guides on the net. > Please, give me a link to git tutorial. I want to modifi some wireless > files, but keep ability to update them by "git pull"... Sorry, I'm > newbie... http://wireless.kernel.org/en/developers/Documentation/git-guide Sujith -- http://sujith-m.blogspot.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 16:49 ` Sujith @ 2009-02-11 21:00 ` Alex Williams 2009-02-13 12:02 ` Alex Williams ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Alex Williams @ 2009-02-11 21:00 UTC (permalink / raw) To: ath9k-devel > No idea. But I found a mini-PCI AR9160 card and it works fine here. Thanks! This is a very important information! I think I should try other hardware and mini-PCI card... Can you tell model and manufacturer of your card? Are you using wireless-testing git? > CONFIG_ATH9K_DEBUG should be enabled in your kernel .config to enable debugging. > See: http://wireless.kernel.org/en/users/Drivers/ath9k Yes, I'm already have this option enabled this in my kernel config... > Did you switch to a VT to see if a panic happens on bringing up the interface ? Yes, I using serial port connection to "target" (x86 SBC) with miniCPI card installed + minicom software in VT102 mode on the "host"... Usually, when kernel panic happening, I see it on serial port console. But in this situation I did not see kernel panic message - system just hang up silently... =( > AR9160 is supported by ath9k, so no worries here. OK, I understand ;) > Search for serial console / netconsole debugging guides on the net. > http://wireless.kernel.org/en/developers/Documentation/git-guide OK, I'll search. Thank you for the link :) ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 16:49 ` Sujith 2009-02-11 21:00 ` Alex Williams @ 2009-02-13 12:02 ` Alex Williams 2009-02-19 19:19 ` Steve Brown 2009-02-20 16:16 ` Steve Brown 3 siblings, 0 replies; 15+ messages in thread From: Alex Williams @ 2009-02-13 12:02 UTC (permalink / raw) To: ath9k-devel > No idea. But I found a mini-PCI AR9160 card and it works fine here. Thanks again! My problem solved. I'm just switched to single board computer from other manufacturer and now my AR9160 card works just fine on all allowed frequencies, even > 5.8 GHz :) ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 16:49 ` Sujith 2009-02-11 21:00 ` Alex Williams 2009-02-13 12:02 ` Alex Williams @ 2009-02-19 19:19 ` Steve Brown 2009-02-20 16:16 ` Steve Brown 3 siblings, 0 replies; 15+ messages in thread From: Steve Brown @ 2009-02-19 19:19 UTC (permalink / raw) To: ath9k-devel (forgot to cc the list) Sujith wrote: > Alex Williams wrote: > >> Thank you for reply! >> Please, tell me: did you saw working card on ar9160 ever??? May be >> with other interfaces, such as PCI or USB? Is support for ar9160 >> finished? Or it's now unusable? >> > > No idea. But I found a mini-PCI AR9160 card and it works fine here. > > >> insmod ath9k.ko debug=0x2000 >> [ 121.839737] ath9k 0000:00:05.0: PCI INT A -> Link[LN_B] -> GSI 10 >> (level, low) -> IRQ 10 >> modprobe: FATAL: Could not load >> /lib/modules/2.6.29-rc4-wl/modules.dep: No such file or directory >> [ 123.479199] cfg80211: Calling CRDA for country: US >> [ 123.507201] udev: renamed network interface wlan0 to wlan1 >> [ 123.512965] Registered led device: ath9k-phy0::radio >> [ 123.546520] Registered led device: ath9k-phy0::assoc >> [ 123.589623] Registered led device: ath9k-phy0::tx >> [ 123.614561] cfg80211: Regulatory domain changed to country: US >> [ 123.620474] (start_freq - end_freq @ bandwidth), >> (max_antenna_gain, max_eirp) >> [ 123.628382] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) >> [ 123.635228] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) >> [ 123.642074] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> [ 123.648921] (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> [ 123.655907] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) >> [ 123.685508] Registered led device: ath9k-phy0::rx >> [ 123.727397] phy0: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0: >> mem=0xcf520000, irq=10 >> insert ath9k.ko >> [ 124.070622] ADDRCONF(NETDEV_UP): wlan1: link is not ready >> > > CONFIG_ATH9K_DEBUG should be enabled in your kernel .config to enable debugging. > See: http://wireless.kernel.org/en/users/Drivers/ath9k > > >>> Are you able to at least scan, before trying to associate with an AP ? >>> If so, then switch to a VT and try to associate and see if the kernel panics. >>> A digital photograph of the panic (if one occurs) would be great. >>> >> To perform scan, we need to "up" interface. Strange, but now, after >> ifconfig wlan1 up - system hang deadly without any explanations! T_T >> But sometimes it continue work after module load... >> > > Did you switch to a VT to see if a panic happens on bringing up the interface ? > > >> Really??? ^_^ It's impossible! Is there some datasheet on ar9160??? >> How about register addresses and their purpose? How can you write >> driver for device if you do not know how it actually works? Writing >> drivers it's like an embedded programming on microcontrolles without >> OS - you should know every register and it's purpose. And even this >> knowledge not guarantee errors proof... Sorry, I'm just wondering how >> this possible... I heards that for ath9k Atheros released >> specifications, or they writing in-house driver?.. Please, more info, >> how it's really developing... =) >> >> > > AR9160 is supported by ath9k, so no worries here. > > >> How to enable additional debug info? Can I use KDBG + /dev/ttyS0 to >> search for the problem? :) >> > > Search for serial console / netconsole debugging guides on the net. > > >> Please, give me a link to git tutorial. I want to modifi some wireless >> files, but keep ability to update them by "git pull"... Sorry, I'm >> newbie... >> > > http://wireless.kernel.org/en/developers/Documentation/git-guide > > Sujith > I'm having the same problem. The driver loads and the device scans. The oops happens while networkmanager is trying to associate with an AP. 01:0b.0 Network controller: Atheros Communications Inc. AR9160 802.11abgn Wireless PCI Adapter (rev 01) 01:0b.0 0280: 168c:0027 (rev 01) Subsystem: 168c:2082 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5 Memory at fe5e0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 Kernel modules: ath9k The card is a Sparklan WMIA-199N. The machine is a P4 2.80GHz running ubuntu and v2.6.29-rc5-14641-g562bdf5 The driver on loading: Feb 19 09:16:23 ubuntu kernel: [ 4676.662134] ath9k 0000:01:0b.0: PCI INT A -> Link[LNKG] -> GSI 5 (level, low) -> IRQ 5 Feb 19 09:16:24 ubuntu kernel: [ 4679.635453] phy2: Selected rate control algorithm 'ath9k_rate_control' Feb 19 09:16:24 ubuntu kernel: [ 4679.676985] cfg80211: Calling CRDA for country: AM Feb 19 09:16:24 ubuntu kernel: [ 4679.677041] Registered led device: ath9k-phy2::radio Feb 19 09:16:24 ubuntu kernel: [ 4679.677060] Registered led device: ath9k-phy2::assoc Feb 19 09:16:24 ubuntu kernel: [ 4679.677078] Registered led device: ath9k-phy2::tx Feb 19 09:16:24 ubuntu kernel: [ 4679.677103] Registered led device: ath9k-phy2::rx Feb 19 09:16:24 ubuntu kernel: [ 4679.677113] phy2: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0: mem=0xf80c0000, irq=5 Feb 19 09:16:24 ubuntu kernel: [ 4679.701984] udev: renamed network interface wlan0 to wlan2 The netconsole output is attached. Hope I haven't missed anything. Steve ------------------------------------------------------------------------ Feb 19 12:51:12 192.168.1.7 [ 307.761386] ------------[ cut here ]------------ Feb 19 12:51:12 192.168.1.7 [ 307.761399] kernel BUG at drivers/net/wireless/ath9k/rc.c:745! Feb 19 12:51:12 192.168.1.7 [ 307.761404] invalid opcode: 0000 [#1] Feb 19 12:51:12 192.168.1.7 Feb 19 12:51:12 192.168.1.7 [ 307.761411] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:01:0b.0/net/wlan2/flags Feb 19 12:51:12 192.168.1.7 [ 307.761417] Modules linked in: Feb 19 12:51:12 arc4 Feb 19 12:51:12 ecb Feb 19 12:51:12 ath9k Feb 19 12:51:12 mac80211 Feb 19 12:51:12 rfkill Feb 19 12:51:12 cfg80211 Feb 19 12:51:12 led_class Feb 19 12:51:12 netconsole Feb 19 12:51:12 configfs Feb 19 12:51:12 i915 Feb 19 12:51:12 drm Feb 19 12:51:12 i2c_algo_bit Feb 19 12:51:12 i2c_core Feb 19 12:51:12 af_packet Feb 19 12:51:12 ppdev Feb 19 12:51:12 speedstep_lib Feb 19 12:51:12 cpufreq_conservative Feb 19 12:51:12 cpufreq_powersave Feb 19 12:51:12 cpufreq_userspace Feb 19 12:51:12 cpufreq_ondemand Feb 19 12:51:12 cpufreq_stats Feb 19 12:51:12 freq_table Feb 19 12:51:13 rfcomm Feb 19 12:51:13 sco Feb 19 12:51:13 bridge Feb 19 12:51:13 stp Feb 19 12:51:13 bnep Feb 19 12:51:13 l2cap Feb 19 12:51:13 bluetooth Feb 19 12:51:13 binfmt_misc Feb 19 12:51:13 ipv6 Feb 19 12:51:13 battery Feb 19 12:51:13 sbs Feb 19 12:51:13 sbshc Feb 19 12:51:13 video Feb 19 12:51:13 output Feb 19 12:51:13 container Feb 19 12:51:13 pci_slot Feb 19 12:51:13 snd_intel8x0 Feb 19 12:51:13 snd_ac97_codec Feb 19 12:51:13 ac97_bus Feb 19 12:51:13 snd_pcm_oss Feb 19 12:51:13 snd_mixer_oss Feb 19 12:51:13 snd_pcm Feb 19 12:51:13 snd_seq_dummy Feb 19 12:51:13 snd_seq_oss Feb 19 12:51:13 snd_seq_midi Feb 19 12:51:13 snd_rawmidi Feb 19 12:51:13 snd_seq_midi_event Feb 19 12:51:13 snd_seq Feb 19 12:51:13 snd_timer Feb 19 12:51:13 snd_seq_device Feb 19 12:51:13 snd Feb 19 12:51:13 psmouse Feb 19 12:51:14 serio_raw Feb 19 12:51:14 pcspkr Feb 19 12:51:14 soundcore Feb 19 12:51:14 snd_page_alloc Feb 19 12:51:14 evdev Feb 19 12:51:14 iTCO_wdt Feb 19 12:51:14 iTCO_vendor_support Feb 19 12:51:14 button Feb 19 12:51:14 shpchp Feb 19 12:51:14 pci_hotplug Feb 19 12:51:14 intel_agp Feb 19 12:51:14 agpgart Feb 19 12:51:14 parport_pc Feb 19 12:51:14 lp Feb 19 12:51:14 parport Feb 19 12:51:14 ac Feb 19 12:51:14 iptable_filter Feb 19 12:51:14 ip_tables Feb 19 12:51:14 x_tables Feb 19 12:51:14 ext3 Feb 19 12:51:14 jbd Feb 19 12:51:14 mbcache Feb 19 12:51:14 usbhid Feb 19 12:51:14 hid Feb 19 12:51:14 sr_mod Feb 19 12:51:14 cdrom Feb 19 12:51:14 sd_mod Feb 19 12:51:14 crc_t10dif Feb 19 12:51:14 sg Feb 19 12:51:14 ata_piix Feb 19 12:51:14 pata_acpi Feb 19 12:51:14 ata_generic Feb 19 12:51:14 libata Feb 19 12:51:15 scsi_mod Feb 19 12:51:15 ehci_hcd Feb 19 12:51:15 uhci_hcd Feb 19 12:51:15 e100 Feb 19 12:51:15 mii Feb 19 12:51:15 usbcore Feb 19 12:51:15 thermal Feb 19 12:51:15 processor Feb 19 12:51:15 fan Feb 19 12:51:15 fuse Feb 19 12:51:15 192.168.1.7 Feb 19 12:51:15 192.168.1.7 [ 307.761748] Feb 19 12:51:15 192.168.1.7 [ 307.761753] Pid: 5611, comm: phy0 Not tainted (2.6.29-rc5-wl #6) To Be Filled By O.E.M. Feb 19 12:51:15 192.168.1.7 [ 307.761758] EIP: 0060:[<f87a7bcf>] EFLAGS: 00010246 CPU: 0 Feb 19 12:51:15 192.168.1.7 [ 307.761771] EIP is at ath_get_rate+0x28f/0x620 [ath9k] Feb 19 12:51:15 192.168.1.7 [ 307.761776] EAX: 00000000 EBX: 0000001c ECX: 00000000 EDX: f87c4980 Feb 19 12:51:15 192.168.1.7 [ 307.761780] ESI: 0000001c EDI: f87c4980 EBP: dfeb7d2c ESP: dfeb7cdc Feb 19 12:51:15 192.168.1.7 [ 307.761786] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Feb 19 12:51:15 192.168.1.7 [ 307.761792] Process phy0 (pid: 5611, ti=dfeb6000 task=dfd63cf0 task.ti=dfeb6000) Feb 19 12:51:15 192.168.1.7 [ 307.761795] Stack: Feb 19 12:51:15 192.168.1.7 [ 307.761799] df307d08 Feb 19 12:51:15 c013fcc3 Feb 19 12:51:15 ee059860 Feb 19 12:51:15 dfeb7d08 Feb 19 12:51:15 00000046 Feb 19 12:51:15 2aeb7d20 Feb 19 12:51:15 dfd32800 Feb 19 12:51:15 d870eb00 Feb 19 12:51:15 192.168.1.7 Feb 19 12:51:15 192.168.1.7 [ 307.761824] Feb 19 12:51:15 00000148 Feb 19 12:51:15 ee14fe00 Feb 19 12:51:16 e7dda410 Feb 19 12:51:16 ee14fe20 Feb 19 12:51:16 00002863 Feb 19 12:51:16 00001e50 Feb 19 12:51:16 f87c4980 Feb 19 12:51:16 0000001c Feb 19 12:51:16 192.168.1.7 Feb 19 12:51:16 192.168.1.7 [ 307.761931] Feb 19 12:51:16 1d1c000a Feb 19 12:51:16 f87c3500 Feb 19 12:51:16 ee14fe20 Feb 19 12:51:16 ee1b0b80 Feb 19 12:51:16 dfeb7d50 Feb 19 12:51:16 f845d82d Feb 19 12:51:16 dfeb7ddc Feb 19 12:51:16 f87c3500 Feb 19 12:51:16 192.168.1.7 Feb 19 12:51:16 192.168.1.7 [ 307.761964] Call Trace: Feb 19 12:51:16 192.168.1.7 [ 307.761968] Feb 19 12:51:16 [<c013fcc3>] ? getnstimeofday+0x53/0x110 Feb 19 12:51:16 192.168.1.7 [ 307.761986] Feb 19 12:51:16 [<f845d82d>] ? rate_control_get_rate+0xbd/0xd0 [mac80211] Feb 19 12:51:16 192.168.1.7 [ 307.762011] Feb 19 12:51:16 [<f8464d38>] ? invoke_tx_handlers+0x648/0x10b0 [mac80211] Feb 19 12:51:16 192.168.1.7 [ 307.762029] Feb 19 12:51:16 [<c0199043>] ? __slab_alloc+0xb3/0x4f0 Feb 19 12:51:16 192.168.1.7 [ 307.762040] Feb 19 12:51:16 [<c02ce4f8>] ? skb_release_data+0x68/0xa0 Feb 19 12:51:16 192.168.1.7 [ 307.762048] Feb 19 12:51:17 [<f8464184>] ? __ieee80211_tx_prepare+0x184/0x340 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762068] Feb 19 12:51:17 [<f8466cac>] ? ieee80211_master_start_xmit+0x24c/0x550 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762091] Feb 19 12:51:17 [<c02d797b>] ? dev_hard_start_xmit+0x25b/0x2f0 Feb 19 12:51:17 192.168.1.7 [ 307.762102] Feb 19 12:51:17 [<c02e8bd4>] ? __qdisc_run+0x194/0x1f0 Feb 19 12:51:17 192.168.1.7 [ 307.762174] Feb 19 12:51:17 [<c01023f4>] ? __switch_to+0xa4/0x190 Feb 19 12:51:17 192.168.1.7 [ 307.762180] Feb 19 12:51:17 [<c02d89ff>] ? dev_queue_xmit+0x32f/0x580 Feb 19 12:51:17 192.168.1.7 [ 307.762187] Feb 19 12:51:17 [<c02ced2d>] ? __alloc_skb+0x4d/0x110 Feb 19 12:51:17 192.168.1.7 [ 307.762195] Feb 19 12:51:17 [<f84689c2>] ? ieee80211_tx_skb+0x52/0x60 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762212] Feb 19 12:51:17 [<f8458ded>] ? ieee80211_send_nullfunc+0xbd/0x100 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762227] Feb 19 12:51:17 [<c01209cb>] ? __cond_resched+0x1b/0x40 Feb 19 12:51:17 192.168.1.7 [ 307.762235] Feb 19 12:51:17 [<f8455b2a>] ? ieee80211_scan_completed+0x2da/0x360 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762251] Feb 19 12:51:17 [<f8455bb0>] ? ieee80211_scan_work+0x0/0x190 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762266] Feb 19 12:51:17 [<f8455d09>] ? ieee80211_scan_work+0x159/0x190 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762287] Feb 19 12:51:17 [<c0356f8b>] ? schedule+0x31b/0x4a0 Feb 19 12:51:17 192.168.1.7 [ 307.762297] Feb 19 12:51:17 [<f8455bb0>] ? ieee80211_scan_work+0x0/0x190 [mac80211] Feb 19 12:51:17 192.168.1.7 [ 307.762318] Feb 19 12:51:18 [<c013460b>] ? run_workqueue+0x5b/0x110 Feb 19 12:51:18 192.168.1.7 [ 307.762387] Feb 19 12:51:18 [<c0134adf>] ? worker_thread+0x7f/0xe0 Feb 19 12:51:18 192.168.1.7 [ 307.762394] Feb 19 12:51:18 [<c0138150>] ? autoremove_wake_function+0x0/0x50 Feb 19 12:51:18 192.168.1.7 [ 307.762402] Feb 19 12:51:18 [<c0134a60>] ? worker_thread+0x0/0xe0 Feb 19 12:51:18 192.168.1.7 [ 307.762407] Feb 19 12:51:18 [<c0137c6a>] ? kthread+0x3a/0x70 Feb 19 12:51:18 192.168.1.7 [ 307.762416] Feb 19 12:51:18 [<c0137c30>] ? kthread+0x0/0x70 Feb 19 12:51:18 192.168.1.7 [ 307.762422] Feb 19 12:51:18 [<c0103d27>] ? kernel_thread_helper+0x7/0x10 Feb 19 12:51:18 192.168.1.7 [ 307.762430] Code: Feb 19 12:51:18 192.168.1.7 8b Feb 19 12:51:18 192.168.1.7 44 Feb 19 12:51:18 192.168.1.7 c2 Feb 19 12:51:18 192.168.1.7 04 Feb 19 12:51:18 192.168.1.7 85 Feb 19 12:51:18 192.168.1.7 c0 Feb 19 12:51:18 192.168.1.7 74 Feb 19 12:51:18 192.168.1.7 09 Feb 19 12:51:18 192.168.1.7 8b Feb 19 12:51:18 192.168.1.7 5d Feb 19 12:51:18 192.168.1.7 c8 Feb 19 12:51:18 192.168.1.7 80 Feb 19 12:51:18 192.168.1.7 7b Feb 19 12:51:18 192.168.1.7 55 Feb 19 12:51:18 192.168.1.7 00 Message from syslogd at 192.168.1.7 at Feb 19 12:51:24 ... f> Feb 19 12:51:24 192.168.1.7 74 Feb 19 12:51:24 192.168.1.7 38 Feb 19 12:51:24 192.168.1.7 8b Feb 19 12:51:24 192.168.1.7 75 Feb 19 12:51:24 192.168.1.7 ec Feb 19 12:51:24 192.168.1.7 8b Feb 19 12:51:24 192.168.1.7 7d Feb 19 12:51:24 192.168.1.7 e8 Feb 19 12:51:24 192.168.1.7 8d Feb 19 12:51:24 192.168.1.7 04 Feb 19 12:51:24 192.168.1.7 b6 Feb 19 12:51:24 192.168.1.7 8b Feb 19 12:51:24 192.168.1.7 44 Feb 19 12:51:24 192.168.1.7 c7 Feb 19 12:51:24 192.168.1.7 08 Feb 19 12:51:24 192.168.1.7 85 Feb 19 12:51:24 192.168.1.7 c0 Feb 19 12:51:24 192.168.1.7 74 Feb 19 12:51:24 192.168.1.7 09 Feb 19 12:51:24 192.168.1.7 8b Feb 19 12:51:24 192.168.1.7 45 Feb 19 12:51:24 192.168.1.7 c8 Feb 19 12:51:24 192.168.1.7 80 Feb 19 12:51:24 192.168.1.7 78 Feb 19 12:51:24 192.168.1.7 55 Feb 19 12:51:24 192.168.1.7 00 Feb 19 12:51:24 192.168.1.7 75 Feb 19 12:51:24 192.168.1.7 1e Feb 19 12:51:24 192.168.1.7 f> Feb 19 12:51:24 192.168.1.7 0b Feb 19 12:51:24 192.168.1.7 eb Feb 19 12:51:24 192.168.1.7 fe Feb 19 12:51:25 192.168.1.7 90 Feb 19 12:51:25 192.168.1.7 8d Feb 19 12:51:25 192.168.1.7 74 Feb 19 12:51:25 192.168.1.7 26 Feb 19 12:51:25 192.168.1.7 00 Feb 19 12:51:25 192.168.1.7 38 Feb 19 12:51:25 192.168.1.7 d3 Feb 19 12:51:25 192.168.1.7 0f Feb 19 12:51:25 192.168.1.7 8e Feb 19 12:51:25 192.168.1.7 5e Feb 19 12:51:25 192.168.1.7 fe Feb 19 12:51:25 192.168.1.7 ff Feb 19 12:51:25 192.168.1.7 ff Feb 19 12:51:25 192.168.1.7 89 Feb 19 12:51:25 192.168.1.7 d3 Feb 19 12:51:25 192.168.1.7 8d Feb 19 12:51:25 192.168.1.7 b6 Feb 19 12:51:25 192.168.1.7 Feb 19 12:51:25 192.168.1.7 [ 307.763062] EIP: [<f87a7bcf>] Feb 19 12:51:25 192.168.1.7 ath_get_rate+0x28f/0x620 [ath9k] Feb 19 12:51:25 SS: ESP 0068:dfeb7cdc Feb 19 12:51:25 192.168.1.7 [ 307.763091] ---[ end trace fdaf4ee84daa2dc6 ]--- ======================================= messages ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-11 16:49 ` Sujith ` (2 preceding siblings ...) 2009-02-19 19:19 ` Steve Brown @ 2009-02-20 16:16 ` Steve Brown 2009-02-23 15:36 ` Sujith 2009-02-24 4:42 ` Sujith 3 siblings, 2 replies; 15+ messages in thread From: Steve Brown @ 2009-02-20 16:16 UTC (permalink / raw) To: ath9k-devel Sujith wrote: > Alex Williams wrote: > >> Thank you for reply! >> Please, tell me: did you saw working card on ar9160 ever??? May be >> with other interfaces, such as PCI or USB? Is support for ar9160 >> finished? Or it's now unusable? >> > > No idea. But I found a mini-PCI AR9160 card and it works fine here. > > >> insmod ath9k.ko debug=0x2000 >> [ 121.839737] ath9k 0000:00:05.0: PCI INT A -> Link[LN_B] -> GSI 10 >> (level, low) -> IRQ 10 >> modprobe: FATAL: Could not load >> /lib/modules/2.6.29-rc4-wl/modules.dep: No such file or directory >> [ 123.479199] cfg80211: Calling CRDA for country: US >> [ 123.507201] udev: renamed network interface wlan0 to wlan1 >> [ 123.512965] Registered led device: ath9k-phy0::radio >> [ 123.546520] Registered led device: ath9k-phy0::assoc >> [ 123.589623] Registered led device: ath9k-phy0::tx >> [ 123.614561] cfg80211: Regulatory domain changed to country: US >> [ 123.620474] (start_freq - end_freq @ bandwidth), >> (max_antenna_gain, max_eirp) >> [ 123.628382] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) >> [ 123.635228] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) >> [ 123.642074] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> [ 123.648921] (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) >> [ 123.655907] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) >> [ 123.685508] Registered led device: ath9k-phy0::rx >> [ 123.727397] phy0: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0: >> mem=0xcf520000, irq=10 >> insert ath9k.ko >> [ 124.070622] ADDRCONF(NETDEV_UP): wlan1: link is not ready >> > > CONFIG_ATH9K_DEBUG should be enabled in your kernel .config to enable debugging. > See: http://wireless.kernel.org/en/users/Drivers/ath9k > > >>> Are you able to at least scan, before trying to associate with an AP ? >>> If so, then switch to a VT and try to associate and see if the kernel panics. >>> A digital photograph of the panic (if one occurs) would be great. >>> >> To perform scan, we need to "up" interface. Strange, but now, after >> ifconfig wlan1 up - system hang deadly without any explanations! T_T >> But sometimes it continue work after module load... >> > > Did you switch to a VT to see if a panic happens on bringing up the interface ? > > >> Really??? ^_^ It's impossible! Is there some datasheet on ar9160??? >> How about register addresses and their purpose? How can you write >> driver for device if you do not know how it actually works? Writing >> drivers it's like an embedded programming on microcontrolles without >> OS - you should know every register and it's purpose. And even this >> knowledge not guarantee errors proof... Sorry, I'm just wondering how >> this possible... I heards that for ath9k Atheros released >> specifications, or they writing in-house driver?.. Please, more info, >> how it's really developing... =) >> >> > > AR9160 is supported by ath9k, so no worries here. > > >> How to enable additional debug info? Can I use KDBG + /dev/ttyS0 to >> search for the problem? :) >> > > Search for serial console / netconsole debugging guides on the net. > > >> Please, give me a link to git tutorial. I want to modifi some wireless >> files, but keep ability to update them by "git pull"... Sorry, I'm >> newbie... >> > > http://wireless.kernel.org/en/developers/Documentation/git-guide > > Sujith > For me, the ASSERT at rc.c:745 goes off. I instrumented it. The results are attached. Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ath9k-rc-assert.txt Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090220/7549cb03/attachment-0001.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-20 16:16 ` Steve Brown @ 2009-02-23 15:36 ` Sujith 2009-02-24 4:42 ` Sujith 1 sibling, 0 replies; 15+ messages in thread From: Sujith @ 2009-02-23 15:36 UTC (permalink / raw) To: ath9k-devel Steve Brown wrote: > For me, the ASSERT at rc.c:745 goes off. > > I instrumented it. The results are attached. Thanks for the trace. We'll work on this. Sujith ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-20 16:16 ` Steve Brown 2009-02-23 15:36 ` Sujith @ 2009-02-24 4:42 ` Sujith 2009-02-24 7:51 ` Steve Brown 1 sibling, 1 reply; 15+ messages in thread From: Sujith @ 2009-02-24 4:42 UTC (permalink / raw) To: ath9k-devel Steve Brown wrote: > Feb 20 11:01:29 ubuntu kernel: [15783.068821] ath9k: Set channel: 2437 MHz > Feb 20 11:01:29 ubuntu kernel: [15783.068825] ath9k: tx chmask: 1, rx chmask: 1 > Feb 20 11:01:29 ubuntu kernel: [15783.068909] ath9k: (2412 MHz) -> (2437 MHz), chanwidth: 0 > Feb 20 11:01:29 ubuntu kernel: [15783.069918] ath9k: RX filter 0x0 bssid 00:0e:8e:1d:f5:5b aid 0x0 > Feb 20 11:01:29 ubuntu kernel: [15783.070935] ath9k: Set channel: 2437 MHz > Feb 20 11:01:29 ubuntu kernel: [15783.070941] ath9k: tx chmask: 1, rx chmask: 1 > Feb 20 11:01:29 ubuntu kernel: [15783.071026] ath9k: (2437 MHz) -> (2437 MHz), chanwidth: 0 Is the AP on channel 6 ? Configured with dynamic 20/40 ? > Feb 20 11:01:29 ubuntu kernel: [15783.074932] ath9k: RX filter 0x0 bssid 00:0e:8e:1d:f5:5b aid 0x0 > Feb 20 11:01:29 ubuntu kernel: [15783.075828] ath9k: Configure tx [queue/halq] [0/3], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 > Feb 20 11:01:29 ubuntu kernel: [15783.075842] ath9k: Configure tx [queue/halq] [1/2], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 > Feb 20 11:01:29 ubuntu kernel: [15783.075853] ath9k: Configure tx [queue/halq] [2/1], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 > Feb 20 11:01:29 ubuntu kernel: [15783.075864] ath9k: Configure tx [queue/halq] [3/0], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 > Feb 20 11:01:29 ubuntu kernel: [15783.075880] wlan2: authenticate with AP 00:0e:8e:1d:f5:5b > Feb 20 11:01:29 ubuntu kernel: [15783.078537] wlan2: authenticated > Feb 20 11:01:29 ubuntu kernel: [15783.078540] wlan2: associate with AP 00:0e:8e:1d:f5:5b > Feb 20 11:01:29 ubuntu kernel: [15783.081874] wlan2: RX AssocResp from 00:0e:8e:1d:f5:5b (capab=0x411 status=0 aid=2) > Feb 20 11:01:29 ubuntu kernel: [15783.081878] wlan2: associated > Feb 20 11:01:29 ubuntu kernel: [15783.081889] ath9k: Choosing rate table for mode: 10 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the bug, the AP advertises 20/40, but sets the operating channel to 20 Mhz, but ath9k chooses the wrong rate table since it doesn't honor the AP's current channel width. Sujith ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-24 4:42 ` Sujith @ 2009-02-24 7:51 ` Steve Brown 2009-02-24 9:52 ` Sujith 2009-02-25 4:13 ` Sujith 0 siblings, 2 replies; 15+ messages in thread From: Steve Brown @ 2009-02-24 7:51 UTC (permalink / raw) To: ath9k-devel Sujith wrote: > Steve Brown wrote: > >> Feb 20 11:01:29 ubuntu kernel: [15783.068821] ath9k: Set channel: 2437 MHz >> Feb 20 11:01:29 ubuntu kernel: [15783.068825] ath9k: tx chmask: 1, rx chmask: 1 >> Feb 20 11:01:29 ubuntu kernel: [15783.068909] ath9k: (2412 MHz) -> (2437 MHz), chanwidth: 0 >> Feb 20 11:01:29 ubuntu kernel: [15783.069918] ath9k: RX filter 0x0 bssid 00:0e:8e:1d:f5:5b aid 0x0 >> Feb 20 11:01:29 ubuntu kernel: [15783.070935] ath9k: Set channel: 2437 MHz >> Feb 20 11:01:29 ubuntu kernel: [15783.070941] ath9k: tx chmask: 1, rx chmask: 1 >> Feb 20 11:01:29 ubuntu kernel: [15783.071026] ath9k: (2437 MHz) -> (2437 MHz), chanwidth: 0 >> > > Is the AP on channel 6 ? Configured with dynamic 20/40 ? > hostapd.conf channel=6 ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40] iw phy phy1 info Wiphy phy1 Band 1: HT capabilities: 0x104e * 20/40 MHz operation * SM PS disabled * 40 MHz short GI * max A-MSDU len 3839 * DSSS/CCK 40 MHz HT A-MPDU factor: 0x0003 (65535 bytes) HT A-MPDU density: 0x0006 (8 usec) HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00 > >> Feb 20 11:01:29 ubuntu kernel: [15783.074932] ath9k: RX filter 0x0 bssid 00:0e:8e:1d:f5:5b aid 0x0 >> Feb 20 11:01:29 ubuntu kernel: [15783.075828] ath9k: Configure tx [queue/halq] [0/3], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 >> Feb 20 11:01:29 ubuntu kernel: [15783.075842] ath9k: Configure tx [queue/halq] [1/2], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 >> Feb 20 11:01:29 ubuntu kernel: [15783.075853] ath9k: Configure tx [queue/halq] [2/1], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 >> Feb 20 11:01:29 ubuntu kernel: [15783.075864] ath9k: Configure tx [queue/halq] [3/0], aifs: 2, cw_min: 15, cw_max: 1023, txop: 0 >> Feb 20 11:01:29 ubuntu kernel: [15783.075880] wlan2: authenticate with AP 00:0e:8e:1d:f5:5b >> Feb 20 11:01:29 ubuntu kernel: [15783.078537] wlan2: authenticated >> Feb 20 11:01:29 ubuntu kernel: [15783.078540] wlan2: associate with AP 00:0e:8e:1d:f5:5b >> Feb 20 11:01:29 ubuntu kernel: [15783.081874] wlan2: RX AssocResp from 00:0e:8e:1d:f5:5b (capab=0x411 status=0 aid=2) >> Feb 20 11:01:29 ubuntu kernel: [15783.081878] wlan2: associated >> Feb 20 11:01:29 ubuntu kernel: [15783.081889] ath9k: Choosing rate table for mode: 10 >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This is the bug, the AP advertises 20/40, but sets the operating channel to 20 Mhz, > but ath9k chooses the wrong rate table since it doesn't honor the AP's current channel width. > > Sujith > Hope this answers your question. Steve ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-24 7:51 ` Steve Brown @ 2009-02-24 9:52 ` Sujith 2009-02-24 18:41 ` Steve Brown 2009-02-25 4:13 ` Sujith 1 sibling, 1 reply; 15+ messages in thread From: Sujith @ 2009-02-24 9:52 UTC (permalink / raw) To: ath9k-devel Steve Brown wrote: > > This is the bug, the AP advertises 20/40, but sets the operating channel to 20 Mhz, > > but ath9k chooses the wrong rate table since it doesn't honor the AP's current channel width. > > Can you try this patch ? This will apply on top of today's wireless-testing. Thanks. diff --git a/drivers/net/wireless/ath9k/rc.c b/drivers/net/wireless/ath9k/rc.c index cf0559f..9ce99e1 100644 --- a/drivers/net/wireless/ath9k/rc.c +++ b/drivers/net/wireless/ath9k/rc.c @@ -1387,42 +1387,18 @@ static struct ath_rate_table *ath_choose_rate_table(struct ath_softc *sc, static void ath_rc_init(struct ath_softc *sc, struct ath_rate_priv *ath_rc_priv, struct ieee80211_supported_band *sband, - struct ieee80211_sta *sta) + struct ieee80211_sta *sta, + struct ath_rate_table *rate_table) { - struct ath_rate_table *rate_table = NULL; struct ath_rateset *rateset = &ath_rc_priv->neg_rates; u8 *ht_mcs = (u8 *)&ath_rc_priv->neg_ht_rates; u8 i, j, k, hi = 0, hthi = 0; - struct ath_hw *ah = sc->sc_ah; - - /* FIXME: Adhoc */ - if ((sc->sc_ah->opmode == NL80211_IFTYPE_STATION) || - (sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC)) { - bool is_cw_40 = sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40; - rate_table = ath_choose_rate_table(sc, sband->band, - sta->ht_cap.ht_supported, - is_cw_40); - } else if (sc->sc_ah->opmode == NL80211_IFTYPE_AP) { - /* cur_rate_table would be set on init through config() */ - rate_table = sc->cur_rate_table; - } if (!rate_table) { DPRINTF(sc, ATH_DBG_FATAL, "Rate table not initialized\n"); return; } - if (sta->ht_cap.ht_supported) { - ath_rc_priv->ht_cap = WLAN_RC_HT_FLAG; - if (sc->sc_ah->caps.tx_chainmask != 1 && - ath9k_hw_getcapability(ah, ATH9K_CAP_DS, 0, NULL)) - ath_rc_priv->ht_cap |= WLAN_RC_DS_FLAG; - if (sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) - ath_rc_priv->ht_cap |= WLAN_RC_40_FLAG; - if (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40) - ath_rc_priv->ht_cap |= WLAN_RC_SGI_FLAG; - } - /* Initial rate table size. Will change depending * on the working rate set */ ath_rc_priv->rate_table_size = RATE_TABLE_SIZE; @@ -1442,7 +1418,7 @@ static void ath_rc_init(struct ath_softc *sc, ath_rc_priv->valid_phy_rateidx[i][j] = 0; ath_rc_priv->valid_phy_ratecnt[i] = 0; } - ath_rc_priv->rc_phy_mode = (ath_rc_priv->ht_cap & WLAN_RC_40_FLAG); + ath_rc_priv->rc_phy_mode = ath_rc_priv->ht_cap & WLAN_RC_40_FLAG; /* Set stream capability */ ath_rc_priv->single_stream = (ath_rc_priv->ht_cap & WLAN_RC_DS_FLAG) ? 0 : 1; @@ -1487,9 +1463,34 @@ static void ath_rc_init(struct ath_softc *sc, ath_rc_sort_validrates(rate_table, ath_rc_priv); ath_rc_priv->rate_max_phy = ath_rc_priv->valid_rate_index[k-4]; sc->cur_rate_table = rate_table; + + DPRINTF(sc, ATH_DBG_CONFIG, "RC Initialized with capabilities: 0x%x\n", + ath_rc_priv->ht_cap); } -/* Rate Control callbacks */ +static u8 ath_rc_build_ht_caps(struct ath_softc *sc, bool is_ht, bool is_cw40, + bool is_sgi40) +{ + u8 caps = 0; + + if (is_ht) { + caps = WLAN_RC_HT_FLAG; + if (sc->sc_ah->caps.tx_chainmask != 1 && + ath9k_hw_getcapability(sc->sc_ah, ATH9K_CAP_DS, 0, NULL)) + caps |= WLAN_RC_DS_FLAG; + if (is_cw40) + caps |= WLAN_RC_40_FLAG; + if (is_sgi40) + caps |= WLAN_RC_SGI_FLAG; + } + + return caps; +} + +/***********************************/ +/* mac80211 Rate Control callbacks */ +/***********************************/ + static void ath_tx_status(void *priv, struct ieee80211_supported_band *sband, struct ieee80211_sta *sta, void *priv_sta, struct sk_buff *skb) @@ -1585,6 +1586,8 @@ static void ath_rate_init(void *priv, struct ieee80211_supported_band *sband, { struct ath_softc *sc = priv; struct ath_rate_priv *ath_rc_priv = priv_sta; + struct ath_rate_table *rate_table = NULL; + bool is_cw40, is_sgi40; int i, j = 0; for (i = 0; i < sband->n_bitrates; i++) { @@ -1606,7 +1609,63 @@ static void ath_rate_init(void *priv, struct ieee80211_supported_band *sband, ath_rc_priv->neg_ht_rates.rs_nrates = j; } - ath_rc_init(sc, priv_sta, sband, sta); + is_cw40 = sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40; + is_sgi40 = sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40; + + /* Choose rate table first */ + + if ((sc->sc_ah->opmode == NL80211_IFTYPE_STATION) || + (sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC)) { + rate_table = ath_choose_rate_table(sc, sband->band, + sta->ht_cap.ht_supported, + is_cw40); + } else if (sc->sc_ah->opmode == NL80211_IFTYPE_AP) { + /* cur_rate_table would be set on init through config() */ + rate_table = sc->cur_rate_table; + } + + ath_rc_priv->ht_cap = ath_rc_build_ht_caps(sc, sta->ht_cap.ht_supported, + is_cw40, is_sgi40); + ath_rc_init(sc, priv_sta, sband, sta, rate_table); +} + +static void ath_rate_update(void *priv, struct ieee80211_supported_band *sband, + struct ieee80211_sta *sta, void *priv_sta, + u32 changed) +{ + struct ath_softc *sc = priv; + struct ath_rate_priv *ath_rc_priv = priv_sta; + struct ath_rate_table *rate_table = NULL; + bool oper_cw40 = false, oper_sgi40; + bool local_cw40 = ((ath_rc_priv->ht_cap & WLAN_RC_40_FLAG) ? 1 : 0); + bool local_sgi40 = ((ath_rc_priv->ht_cap & WLAN_RC_SGI_FLAG) ? 1 : 0); + + /* FIXME: Handle AP mode later when we support CWM */ + + if (changed & IEEE80211_RC_HT_CHANGED) { + if (sc->sc_ah->opmode != NL80211_IFTYPE_STATION) + return; + + if (sc->hw->conf.channel_type == NL80211_CHAN_HT40MINUS || + sc->hw->conf.channel_type == NL80211_CHAN_HT40PLUS) + oper_cw40 = true; + + oper_sgi40 = sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40; + + if ((local_cw40 != oper_cw40) || (local_sgi40 != oper_sgi40)) { + rate_table = ath_choose_rate_table(sc, sband->band, + sta->ht_cap.ht_supported, + oper_cw40); + ath_rc_priv->ht_cap = ath_rc_build_ht_caps(sc, + sta->ht_cap.ht_supported, + oper_cw40, oper_sgi40); + ath_rc_init(sc, priv_sta, sband, sta, rate_table); + + DPRINTF(sc, ATH_DBG_CONFIG, + "Operating HT Bandwidth changed to: %d\n", + sc->hw->conf.channel_type); + } + } } static void *ath_rate_alloc(struct ieee80211_hw *hw, struct dentry *debugfsdir) @@ -1650,6 +1709,7 @@ static struct rate_control_ops ath_rate_ops = { .tx_status = ath_tx_status, .get_rate = ath_get_rate, .rate_init = ath_rate_init, + .rate_update = ath_rate_update, .alloc = ath_rate_alloc, .free = ath_rate_free, .alloc_sta = ath_rate_alloc_sta, ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-24 9:52 ` Sujith @ 2009-02-24 18:41 ` Steve Brown 0 siblings, 0 replies; 15+ messages in thread From: Steve Brown @ 2009-02-24 18:41 UTC (permalink / raw) To: ath9k-devel Sujith wrote: > Steve Brown wrote: > >>> This is the bug, the AP advertises 20/40, but sets the operating channel to 20 Mhz, >>> but ath9k chooses the wrong rate table since it doesn't honor the AP's current channel width. >>> >>> > > Can you try this patch ? This will apply on top of today's wireless-testing. > Thanks. > > Thanks for the patch. I applied it to today's wireless-testing. It didn't solve the problem with the assert at rc.c:745. I put the printk's back in and the attached is what I got. Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ath9k-hang.log Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090224/83accf8f/attachment-0001.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-24 7:51 ` Steve Brown 2009-02-24 9:52 ` Sujith @ 2009-02-25 4:13 ` Sujith 2009-02-25 8:17 ` Steve Brown 1 sibling, 1 reply; 15+ messages in thread From: Sujith @ 2009-02-25 4:13 UTC (permalink / raw) To: ath9k-devel Steve Brown wrote: > hostapd.conf > channel=6 > ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40] > > iw phy phy1 info > Wiphy phy1 > Band 1: > HT capabilities: 0x104e > * 20/40 MHz operation > * SM PS disabled > * 40 MHz short GI > * max A-MSDU len 3839 > * DSSS/CCK 40 MHz > HT A-MPDU factor: 0x0003 (65535 bytes) > HT A-MPDU density: 0x0006 (8 usec) > HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00 > Ah, are you using ath9k as the AP ? Can you paste the hostapd log ? (hostapd -dd) ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ath9k-devel] AR9260 hang during connection to AP 2009-02-25 4:13 ` Sujith @ 2009-02-25 8:17 ` Steve Brown 0 siblings, 0 replies; 15+ messages in thread From: Steve Brown @ 2009-02-25 8:17 UTC (permalink / raw) To: ath9k-devel Sujith wrote: > Steve Brown wrote: > >> hostapd.conf >> channel=6 >> ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40] >> >> iw phy phy1 info >> Wiphy phy1 >> Band 1: >> HT capabilities: 0x104e >> * 20/40 MHz operation >> * SM PS disabled >> * 40 MHz short GI >> * max A-MSDU len 3839 >> * DSSS/CCK 40 MHz >> HT A-MPDU factor: 0x0003 (65535 bytes) >> HT A-MPDU density: 0x0006 (8 usec) >> HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00 >> >> > > Ah, are you using ath9k as the AP ? > Yes, I'm using the same card for the ap. Also, I have no problem w/ g connections. I moved to channel 11. hostapd is today's git. ath9k still has printk's instead of the assert. > Can you paste the hostapd log ? (hostapd -dd) > attached. > From your other mail, the chosen rate table is completely wrong, > am not sure if this is related to AP mode in ath9k. > > Sujith > Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ht.log Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090225/8837c2cc/attachment.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-02-25 8:17 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-02-11 14:17 [ath9k-devel] AR9260 hang during connection to AP Alex Williams 2009-02-11 14:38 ` Sujith 2009-02-11 16:05 ` Alex Williams 2009-02-11 16:49 ` Sujith 2009-02-11 21:00 ` Alex Williams 2009-02-13 12:02 ` Alex Williams 2009-02-19 19:19 ` Steve Brown 2009-02-20 16:16 ` Steve Brown 2009-02-23 15:36 ` Sujith 2009-02-24 4:42 ` Sujith 2009-02-24 7:51 ` Steve Brown 2009-02-24 9:52 ` Sujith 2009-02-24 18:41 ` Steve Brown 2009-02-25 4:13 ` Sujith 2009-02-25 8:17 ` Steve Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.