When bringing the interface up, I get an oops. This is with an Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) (168c:0013) BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: f8bd67fe *pde = 66acf067 Oops: 0000 [#1] SMP Modules linked in: iptable_filter ip_tables x_tables autofs4 rfcomm l2cap bluetooth sunrpc cpufreq_ondemand acpi_cpufreq dm_mirror dm_multipath video output sbs dock battery ac ipv6 floppy arc4 ecb blkcipher rc80211_simple snd_hda_intel snd_seq_dummy rt61pci rt2x00pci rt2x00lib rfkill snd_seq_oss ath5k input_polldev snd_seq_midi_event parport_pc i2c_i801 snd_seq mac80211 parport firewire_ohci i2c_core snd_seq_device firewire_core eeprom_93cx6 cfg80211 snd_pcm_oss crc_itu_t snd_mixer_oss rtc_cmos e1000 snd_pcm snd_timer snd soundcore snd_page_alloc i82975x_edac button edac_core sg ext3 jbd mbcache squashfs dm_snapshot dm_mod loop vfat fat sd_mod usb_storage ata_piix pata_marvell ahci ata_generic ehci_hcd libata uhci_hcd sr_mod scsi_mod cdrom CPU: 1 EIP: 0060:[<f8bd67fe>] Not tainted VLI EFLAGS: 00210246 (2.6.23-0.133.rc3.git6.fc8 #1) EIP is at ath5k_hw_reset+0x894/0x114a [ath5k] eax: 00000000 ebx: 00000000 ecx: f59e1228 edx: 00000004 esi: 00000020 edi: 00000000 ebp: f073ae10 esp: f073ab10 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process ifconfig (pid: 4165, ti=f073a000 task=f0780000 task.ti=f073a000) Stack: 00000000 00000000 f0aeb840 000001c3 00000000 f59e1228 c2f32830 f073ab40 00000001 00200246 c08c4498 c2f32910 00000000 00000001 00000001 00000003 00000001 00000002 00000014 f073ab70 00000001 00200046 c08c2e40 f0780000 Call Trace: [<c04063c4>] show_trace_log_lvl+0x1a/0x2f [<c0406474>] show_stack_log_lvl+0x9b/0xa3 [<c0406634>] show_registers+0x1b8/0x289 [<c040681c>] die+0x117/0x24a [<c063514b>] do_page_fault+0x51c/0x5ed [<c063385a>] error_code+0x72/0x78 [<f8bcfa7b>] ath_init+0x74/0xfb [ath5k] [<f8bcfb98>] ath_open+0xb/0xd [ath5k] [<f8b94712>] ieee80211_open+0x259/0x320 [mac80211] [<c05cec2a>] dev_open+0x31/0x6c [<c05ccd81>] dev_change_flags+0xa3/0x156 [<c060d5ed>] devinet_ioctl+0x207/0x50e [<c060dc9b>] inet_ioctl+0x86/0xa4 [<c05c2f62>] sock_ioctl+0x1ac/0x1c9 [<c0493a9a>] do_ioctl+0x22/0x68 [<c0493d29>] vfs_ioctl+0x249/0x25c [<c0493d85>] sys_ioctl+0x49/0x64 [<c0405192>] syscall_call+0x7/0xb ======================= Code: ff 66 0f b6 db 8d 1c 9d 00 87 ff ff 81 e3 fc ff 00 00 e8 2e ba ff ff 8b 95 18 fd ff ff 03 5a 08 0f b7 c0 89 03 ff 85 6c fd ff ff <0f> b7 07 39 85 6c fd ff ff 72 a7 8b 8d 18 fd ff ff 83 79 48 01 EIP: [<f8bd67fe>] ath5k_hw_reset+0x894/0x114a [ath5k] SS:ESP 0068:f073ab10
kernel-2.6.23-0.212.rc8.git2.fc8 contains some ath5k updates. Can you replicate with that kernel?
Still happens with .214
Happens also with 2.6.23-0.218.rc9.git1.fc8 despite update of wireless bits.
With 2.6.23-0.220.rc9.git2.fc8 same probem (toshiba satellite pro laptop) (installed from fc8 test3 and updated to oct 7 stuff) Oct 7 17:08:05 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 Oct 7 17:08:05 localhost kernel: printing eip: e0295331 *pde = 12ec2067 *pte = 00000000 Oct 7 17:08:05 localhost kernel: Oops: 0000 [#1] SMP Oct 7 17:08:05 localhost kernel: Modules linked in: i915 drm rfcomm l2cap bluetooth autofs4 sunrpc nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack nfnetlink xt_tcpudp ip6t_REJECT ip6table_filter ip6_tables x_tables cpufreq_ondemand acpi_cpufreq loop dm_multipath ipv6 arc4 ecb snd_hda_intel blkcipher snd_seq_dummy rc80211_simple sdhci snd_seq_oss mmc_core firewire_ohci firewire_core snd_seq_midi_event tifm_7xx1 tifm_core snd_seq crc_itu_t i2c_i801 i2c_core snd_seq_device serio_raw iTCO_wdt iTCO_vendor_support ath5k snd_pcm_oss mac80211 r8169 cfg80211 snd_mixer_oss snd_pcm ac snd_timer battery snd soundcore snd_page_alloc video output button joydev sg sr_mod cdrom dm_snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Oct 7 17:08:05 localhost kernel: CPU: 0 Oct 7 17:08:05 localhost kernel: EIP: 0060:[<e0295331>] Not tainted VLI Oct 7 17:08:05 localhost kernel: EFLAGS: 00010246 (2.6.23-0.220.rc9.git2.fc8 #1) Oct 7 17:08:05 localhost kernel: EIP is at ath5k_hw_reset+0x39c/0xcd0 [ath5k] Oct 7 17:08:05 localhost kernel: eax: 00000000 ebx: db0b4000 ecx: 00000000 edx: 00000005 Oct 7 17:08:05 localhost kernel: esi: 00000000 edi: 00000000 ebp: d4889e10 esp: d4889dac Oct 7 17:08:05 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Oct 7 17:08:05 localhost kernel: Process ifconfig (pid: 16111, ti=d4889000 task=d5690d60 task.ti=d4889000) Oct 7 17:08:05 localhost kernel: Stack: c0502288 d4889df4 e028f4e0 def890e0 db262830 00000002 def8af4c def8af44 Oct 7 17:08:05 localhost kernel: 00000000 00000000 00000001 e02817d9 00000003 00000001 00000002 00001000 Oct 7 17:08:05 localhost kernel: d4889df4 00000000 00000000 00000000 def88fe0 db0b4600 db0b4000 def88fe0 Oct 7 17:08:05 localhost kernel: Call Trace: Oct 7 17:08:05 localhost kernel: [<c0406463>] show_trace_log_lvl+0x1a/0x2f Oct 7 17:08:05 localhost kernel: [<c0406513>] show_stack_log_lvl+0x9b/0xa3 Oct 7 17:08:05 localhost kernel: [<c04066d3>] show_registers+0x1b8/0x289 Oct 7 17:08:05 localhost kernel: [<c04068af>] die+0x10b/0x23e Oct 7 17:08:05 localhost kernel: [<c0635174>] do_page_fault+0x51c/0x5ed Oct 7 17:08:05 localhost kernel: [<c063389a>] error_code+0x72/0x78 Oct 7 17:08:05 localhost kernel: [<e028fa82>] ath_init+0x74/0xfb [ath5k] Oct 7 17:08:05 localhost kernel: [<e028fb9f>] ath_open+0xb/0xd [ath5k] Oct 7 17:08:05 localhost kernel: [<e026e5d8>] ieee80211_open+0x259/0x320 [mac80211] Oct 7 17:08:05 localhost kernel: [<c05cebca>] dev_open+0x31/0x6c Oct 7 17:08:05 localhost kernel: [<c05ccd21>] dev_change_flags+0xa3/0x156 Oct 7 17:08:05 localhost kernel: [<c060d5f5>] devinet_ioctl+0x207/0x50e Oct 7 17:08:05 localhost kernel: [<c060dca3>] inet_ioctl+0x86/0xa4 Oct 7 17:08:05 localhost kernel: [<c05c2ef6>] sock_ioctl+0x1ac/0x1c9 Oct 7 17:08:05 localhost kernel: [<c04942f2>] do_ioctl+0x22/0x68 Oct 7 17:08:05 localhost kernel: [<c0494581>] vfs_ioctl+0x249/0x25c Oct 7 17:08:05 localhost kernel: [<c04945dd>] sys_ioctl+0x49/0x64 Oct 7 17:08:05 localhost kernel: [<c040522e>] syscall_call+0x7/0xb Oct 7 17:08:05 localhost kernel: ======================= Oct 7 17:08:05 localhost kernel: Code: 00 00 03 5a 08 89 fa c7 44 24 04 00 00 00 00 0f b6 46 1c 89 04 24 8b 45 ac e8 50 cf ff ff 89 da 0f b7 c0 e8 51 ea 26 e0 ff 45 e8 <0f> b7 07 83 c6 14 39 45 e8 72 b0 8b 4d ac 83 79 48 01 76 51 66 Oct 7 17:08:05 localhost kernel: EIP: [<e0295331>] ath5k_hw_reset+0x39c/0xcd0 [ath5k] SS:ESP 0068:d4889dac 04:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01) Subsystem: Askey Computer Corp. Unknown device 7128 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 220 Region 0: Memory at d8000000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41e9 Capabilities: [60] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0 Link: Latency L0s <512ns, L1 <64us Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Vector table: BAR=0 offset=00000000 PBA: BAR=0 offset=00000000 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel
*** Bug 321051 has been marked as a duplicate of this bug. ***
If you have access to the ath_info program from madwifi, please run that (after using lspci to get the right base address -- don't forget the "0x" on the front!) and include the output here.
I ran it on my Fedora 7 installation, I hope that this is ok. -==Device Information==- MAC Version: 5213A(0x70) MAC Revision: 5213A(0x79) PHY Revision: 2112a(0x56) -==EEPROM Information==- EEPROM Version: 5.2 EEPROM Size: 16K Regulatory Domain: 0x0 -==== Capabilities ====- | 802.11a Support: no | | 802.11b Support: yes | | 802.11g Support: yes | | RFKill Support: no | | 32KHz Crystal: no | ======================== GPIO registers: CR 00000000 DO 00000000 DI 00000010
As requested.. [root@localhost tools]# ./ath_info 0xd8000000 Warning: Invalid EEPROM Magic number ! -==Device Information==- MAC Version: 2425 (0xe0) MAC Revision: 2425 (0xe2) PHY Revision: 5110 (0x0) -==EEPROM Information==- EEPROM Version: 5.3 EEPROM Size: 4K Regulatory Domain: 0x65 -==== Capabilities ====- | 802.11a Support: no | | 802.11b Support: no | | 802.11g Support: yes | | RFKill Support: yes | | 32KHz Crystal: no | ======================== GPIO registers: CR 00000000 DO 00000000 DI 00000003
The problem only seems to occur when attempting to configure the device for me, e.g. starting NetworkManager or using ifconfig directly to assign an ip: [root@localhost tools]# modprobe wlan0 [root@localhost tools]# iwconfig wlan0 wlan0 IEEE 802.11g ESSID:"" Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 [root@localhost tools]# ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:1B:9E:3D:C4:AE BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [root@localhost tools]# ifconfig wlan0 192.168.0.23 Segmentation fault Then above message appears in the messages log
FYI I have the same problems with madwifi, I believe this is the ticket in madwifi on it: http://madwifi.org/ticket/1192
I do not run into that problem using Fedora 7 and the Livna Madwifi RPM. My chipset (AR5212) is supported and works fine using madwifi for one year now.
Just updated my bios on my laptop, noted that windows reports the device as an AR5007EG whereas linux as an AR5006EG, don't know whether this is a problem or not. Will update about whether bios update helped once fc8test3 is installed and updated again.
Bios update didn't seem to help :-(
With regards to comments about madwifi, I have three machines working with madwifi and ar5212 fine for a long time. The issue seems to be with certain chipsets, and if you read the madwifi ticket you will see that the issue with madwifi seems to be lack of HAL support for these chipsets. The main issue is that it needs to work with ath5k for two reasons: 1) madwifi is being replaced by ath5k 2) ath5k comes with the linux kernel and with fedora so will work out of the box, Pretty much everything else on my laptop works immediately with fedora 8, it is easier to install than windows, and if all drivers work then it is a real selling point of using linux than windows, rather than the 90% working that used to be the case years ago with linux, which puts a lot of people off.
Malcolm, does the hardware that causes problems using ath5k work for you using madwifi?
The oops posted in bug 321051 is: drivers/net/wiresless/ath5k/hw.c::ath5k_hw_reset() line 703: /* Get rate table for this operation mode */ rt = ath5k_hw_get_rate_table(hal, channel->val & CHANNEL_TURBO ? MODE_ATHEROS_TURBO : MODE_ATHEROS_TURBOG); /* Write rate duration table */ rt is NULL here ==========> for (i = 0; i < rt->rate_count; i++) ath5k_hw_get_rate_table() has returned NULL, probably because of this: if (!test_bit(mode, hal->ah_capabilities.cap_mode)) return NULL;
Martin, It does not work using madwifi either, that was the first thing I tried.
Your problem is slightly different to the one of the original reporter and me then as we both have the same chipset which is supported by madwifi. It is weird that you get the same oops with your unsupported chipset, but I am not very experienced in software development ;)
The kernel updates etc. haven't helped :-( (2.6.23-5) I am guessing that the problem is with most atheros chipsets I am a little concerned that this is marked as severity low, I would have thought not been able to install fedora on a new laptop (as it segfaulted and jammed on my install, so I had to disable wlan0 in init 1, then reboot), or on any machine with an atheros wifi card would constitute more than "low" priority. At least if it isn't going to be fixed it before the release it should be disabled. (IMHO)
I've installed the madwifi driver in order to verify that it still works, and can confirm that it does. I had to rename ath5k.ko to prevent it from being used, though. It wasn't sufficient to remove it from modules.conf, nor to "blacklist" it. I can't figure out why.
The same issue appears with the kernel 2.6.23 package in updates-testing. When running that kernel, it oopses and you can't interact later anymore. I'd suggest not to push it to updates.
kernel-2.6.23-6.fc8 still broken
*** Bug 330621 has been marked as a duplicate of this bug. ***
*** Bug 305381 has been marked as a duplicate of this bug. ***
There are some ath5k updates in the kernels here: http://koji.fedoraproject.org/koji/buildinfo?buildID=21169 YMMV, I get an (apparently) different oops now... Do these kernels make a difference for you?
It's still oopsing at exactly the same place. rt = ath5k_hw_get_rate_table(hal, channel->val & CHANNEL_TURBO ? MODE_ATHEROS_TURBO : MODE_ATHEROS_TURBOG); /* Write rate duration table */ for (i = 0; i < rt->rate_count; i++) rt is NULL, and dereferencing rt->rate_count causes the oops. Can't we at least add a check for NULL after calling ath5k_hw_get_rate_table() and fail gracefully instead of oopsing the kernel??
Created attachment 229891 [details] Oops screen 1
Created attachment 229901 [details] Oops screen 2
(In reply to comment #26) > It's still oopsing at exactly the same place. > > rt = ath5k_hw_get_rate_table(hal, > channel->val & CHANNEL_TURBO ? > MODE_ATHEROS_TURBO : MODE_ATHEROS_TURBOG); > > /* Write rate duration table */ > for (i = 0; i < rt->rate_count; i++) > > rt is NULL, and dereferencing rt->rate_count causes the oops. Can't we at least > add a check for NULL after calling ath5k_hw_get_rate_table() and fail gracefully > instead of oopsing the kernel?? I added something on my own machine like that over the last weekend and had it it return -EINVAL (or something like that). The network didn't come up, but at least it didn't crash. I would like to see the NULL pointer check in the final fix as long as root cause is investigated and fixed.
Should we just disable this driver for release or not? The whole machine locks up on first boot if you have one of the affected chipsets...
*** Bug 302961 has been marked as a duplicate of this bug. ***
Created attachment 230231 [details] linux-2.6-ath5k-fixes.patch Building 2.6.23.1-21.fc8 w/ this patch now...does this eliminate the crashes on insertion?
Regarding comment 30... It is highly unlikely that ath5k will be mature in time for F8's release. Hopefully we can get it to stop crashing upon mere insertion, hopefully w/ just the patch in comment 32. If not, then disabling ath5k is probably the only solution.
It still might be worth pulling the pci ids. That would make the module available for those who want to help test it and get it ready while not having it autoload and cause problems for those less ... "adventurous".
Looks like the latest patch should work, we will know by tomorrow.
Oops is fixed in kernel 2.6.23.1-23
Yippi-Yeah :)
2.6.23.1-23 don't crash now for me too ...but even with an AR5212 chipset (TRENDnet TEW-443PI) who seem to be supported by ath5k, I can't use my device! Oct 18 19:39:09 localhost kernel: ath_pci 0000:01:07.0: can't get channels Oct 18 19:39:09 localhost kernel: ath_pci: probe of 0000:01:07.0 failed with error -22 Any tips ?
FYI, info on how to help the ath5k reverse engineering team: http://marc.info/?l=linux-wireless&m=119282415503974&w=2
Seems fixed for me too now, it no longer recognises my card AR5007EG as compatible and doesn't load the driver so no crash. Guess I'll buy a pcmcia compat. card and see if I can help out getting the ath5k to work. (cheers for the link!) Thanks, Malcolm
Yay, I could log in using the Rawhide LiveCD Jeremy Katz uploaded on the 19th (whereas, it formerly never progressed past GDM Login Manager before). Does this problem mean that people with this card won't have wireless access in F8? Is it only if they try to use the ath5k driver instead of the madwifi one? Cheers.
(In reply to comment #41) 'madwifi' has been available for a while, so why would there be no wireless access in F8? I am using it right now. Only make sure to have downloaded matching 'madwifi' packages before you install F8.
After adding debugging statements to the ath5k driver, I get: ath5k_hw_get_rate_table: mode=0, cap_mode=[1,2,] [<f8a5b07e>] ath5k_hw_get_rate_table+0x5a/0x92 [ath5k] [<f8a58787>] ath_pci_probe+0x4ac/0xf97 [ath5k] [<c04f1fd8>] idr_get_empty_slot+0x11e/0x1ef [<c04b96cc>] sysfs_addrm_finish+0x4a/0x1b4 [<c04ba6b9>] sysfs_create_link+0xf2/0x149 [<c050014b>] pci_device_probe+0x36/0x57 It's trying to use mode 0 but only 1 and 2 are supported. called from base.c line 1945: hw_rates = ath5k_hw_get_rate_table(ah, mode->mode); if (!hw_rates) return -EINVAL; -==Device Information==- MAC Version: 5213A(0x70) MAC Revision: 5213A(0x78) PHY Revision: 2112a(0x56) -==EEPROM Information==- EEPROM Version: 5.2 EEPROM Size: 16K Regulatory Domain: 0x63 -==== Capabilities ====- | 802.11a Support: no | | 802.11b Support: yes | | 802.11g Support: yes | | RFKill Support: yes | | 32KHz Crystal: no | ======================== GPIO registers: CR 00000000 DO 00000000 DI 00000017
(In reply to comment #43) > After adding debugging statements to the ath5k driver, I get: > > ath5k_hw_get_rate_table: mode=0, cap_mode=[1,2,] > [<f8a5b07e>] ath5k_hw_get_rate_table+0x5a/0x92 [ath5k] > [<f8a58787>] ath_pci_probe+0x4ac/0xf97 [ath5k] > [<c04f1fd8>] idr_get_empty_slot+0x11e/0x1ef > [<c04b96cc>] sysfs_addrm_finish+0x4a/0x1b4 > [<c04ba6b9>] sysfs_create_link+0xf2/0x149 > [<c050014b>] pci_device_probe+0x36/0x57 > > > It's trying to use mode 0 but only 1 and 2 are supported. > > called from base.c line 1945: > > hw_rates = ath5k_hw_get_rate_table(ah, mode->mode); > if (!hw_rates) > return -EINVAL; > Hmm, looks like it's okay for ath5k_hw_get_rate_table() to return NULL here?
Yes, I think you're right.
Kernels w/ that little hunk removed available here: http://koji.fedoraproject.org/koji/buildinfo?buildID=22061 Does that help anyone? :-)
After booting kernel 2.6.23.1-33.fc8 and loading kernel module ath5k.ko, 'ifup ath0' returns: 'SIOCSIFFLAGS : Invalid argument'. This happens for an AR5212 based D-Link DWL-G520 WLAN adapter. The relevant part of 'dmesg' reads: ath5k_hw_get_rate_table: mode=5, cap_mode=[1,2,] Call Trace: [<ffffffff8827e7e7>] :ath5k:ath5k_hw_get_rate_table+0x5d/0xa1 [<ffffffff8827fae0>] :ath5k:ath5k_hw_reset+0x366/0xd41 [<ffffffff88279a17>] :ath5k:ath_init+0x74/0x104 [<ffffffff882546a5>] :mac80211:ieee80211_open+0x292/0x376 [<ffffffff811f1235>] dev_open+0x2f/0x6e [<ffffffff811ef345>] dev_change_flags+0xaa/0x168 [<ffffffff81234e95>] devinet_ioctl+0x235/0x597 [<ffffffff810826e3>] free_pgtables+0xae/0xc3 [<ffffffff811e47ef>] sock_ioctl+0x1c8/0x1e5 [<ffffffff810a72c5>] do_ioctl+0x21/0x6b [<ffffffff810a7552>] vfs_ioctl+0x243/0x25c [<ffffffff810a75c4>] sys_ioctl+0x59/0x79 [<ffffffff8100bbce>] system_call+0x7e/0x83 unable to reset hardware: -22
Huh, there is something wrong here. 1. There is a 'hole' in the driver mode numbers, caused by starting one past the last basic mode. 2. The driver supports five modes, not three... I think. Totally untested whitespace-damaged patch below: --- ath5k.h.orig +++ ath5k.h @@ -210,12 +210,12 @@ #define MODULATION_TURBO 0x00000080 enum ath5k_vendor_mode { - MODE_ATHEROS_TURBO = NUM_IEEE80211_MODES+1, + MODE_ATHEROS_TURBO = NUM_IEEE80211_MODES, MODE_ATHEROS_TURBOG +/* Number of supported mac80211 enum ieee80211_phymode modes by this driver */ + NUM_DRIVER_MODES }; -/* Number of supported mac80211 enum ieee80211_phymode modes by this driver */ -#define NUM_DRIVER_MODES 3 /* adding this flag to rate_code enables short preamble, see ar5212_reg.h */ #define AR5K_SET_SHORT_PREAMBLE 0x04
Created attachment 236611 [details] Totally untested patch
Why don't you just disable the ath5k driver untill it is ready (functional)? I run fc7 and after the update to the 2.6.23.1-10 kernel the wireless wasn't detected anymore. I took me half a day to find that the problem is in the ath5k driver. after blacklisting it everything is fine and works with the madwifi. just drop it from the fc8 kernel untill it is ready. you can save the people lots of headaches. my card: 08:04.0 Ethernet controller: Atheros Communications, Inc. AR5005G 802.11abg NIC (rev 01) Subsystem: AMBIT Microsystem Corp. Unknown device 0418 Flags: bus master, medium devsel, latency 168, IRQ 21 Memory at c0200000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 08:04.0 0200: 168c:001a (rev 01)
Just because it doesn't work for you doesn't mean it doesn't work for anyone or that it won't continue to improve. And I know it works for some, because someone complained when I broke it while trying to fix it for someone else... Disabling a driver that works for some just because it may make it 1% harder to get the (unsupported) madwifi driver working for others just doesn't seem worthwhile.
I respect the efforts of all the people trying to make the software free. And i like the idea of having a free atheros driver (not dependend on the closed binary HAL as madwifi). NAd one day this will happen. my point is that the ath5k is still not good enough. therefore i suggest using the madwifi untill ath5k gets better. I appreciate your work on it, but maybe there should be a way to use (as default)the madwifi and extra enable the ath5k. here: http://forums.fedoraforum.org/showthread.php?t=170403 the guy needed almost 2 days to have his atheros card working again and he didn't have any idea, why his newly updated kernel and madwifi didn't recognize his (previously perfekt working) atheros card. Once again, my respect to the developers.
I don't think the patch in comment 49 is the right direction. Most of the driver does not support those ATHEROS_TURBO modes currently. Calling ath5k_hw_get_rate_table with mode 5 for AR5212 is clearly an error. I have added a patch to change that to IEEE80211G for AR5212. Please try the test kernels here: http://koji.fedoraproject.org/koji/taskinfo?taskID=222629 Do these work any better or differently for you?
Created attachment 245521 [details] ar5212.patch
Created attachment 245831 [details] NM output for kernel 2.6.23.1-42.wl.1.fc8 to /var/log/messages No error messages anymore when bringing up the interface via ifcfg-ath0. It simply does not pick up a valid IP address and aborts after a while. NM also works almost perfectly: after setting up a new wireless connection, the keyring manager prompts the user for the pass phrase and tries to connect but simply reasks for the pass phrase after the time-out is reached.
Well, at least that looks like progress... :-)
just upgraded to (what will be) f8 on my desktop with a 01:06.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) It doesn't support it correctly and insists on using the ath5k driver. so currently "find /lib/modules -name ath5k.ko -exec rm {} \;" is my rather nasty solution and use madwifi. Good to know there's no giving up on this! I'll see if I can add more info on the next kernel update. Got the laptop (AR5007EG) working using ndiswrapper, although I admit I feel _very_ dirty
Still no success with kernel 2.6.23.1-58.fc8 in obtaining an IP address via DHCP as reported in comment #55. Here, relevant entries of the outputs of "dmesg" and "lspci": phy0: Selected rate control algorithm 'simple' ath5k_pci 0000:01:0a.0: Atheros AR5213A chip found (MAC: 0x79, PHY: 0x45) ath5k_pci 0000:01:0a.0: RF2112A 2GHz radio found (0x56) net ath0: device_rename: sysfs_create_symlink failed (-17) udev: renamed network interface wlan0 to ath0 01:0a.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5212 802.11abg NIC [168c:0013] (rev 01) Subsystem: D-Link System Inc D-Link AirPlus DWL-G520 Wireless PCI Adapter(rev.B) [1186:3a13] This hardware seems to be a very common one, so I wonder if there is actually -anybody- having success with the current "ath5k" driver ..
"This hardware seems to be a very common one..." You are, of course, free to speculate. FWIW, I have received many reports of people using it successfully. FWIW, the fact that Atheros hardware is very common does not actually imply that your particular card actually is...and even if it is common, that doesn't mean the developers actually have it.
I have a similar problem with SIOCSIFFLAGS as reported in comment #47. My atheros hardware is integrated in my HP compaq nc6000 notebook. I can successfully modprobe the ath5k module and then configure my essid and 64-bit wep key with iwconfig. However iwconfig reports that wlan0 is not associated with an access point. Also when I try to run dhclient I get the following error message: send_packet: Network is down receive_packet failed on wlan0: Network is down
I should have mentioned in my previous comment that I installed kernel package kernel-2.6.23.1-42.fc8 from rawhide on my F7 system.
Bryan, please be sure to try -58.fc8, as it is somewhat more up-to-date.
Please try 2.6.23.8-62.fc8
I tried kernel-2.6.24-0.41.rc3.git1.fc9 with no luck. Same problem--no access point association. However, no error about "network down".
*** Bug 292191 has been marked as a duplicate of this bug. ***
Retested with kernel-2.6.24-0.73.rc4.git1.fc9 with no improvement. Results the same as mentioned in comment #64.
I'm also getting "SIOCSIFFLAGS: Invalid argument" * Model: Toshiba Satellite A135-S7404 * Chipset: Atheros AR5006EG # lspci | grep -i ath 04:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01) with atheros * OS: Fedora 8 * Kernel: 2.6.23.1-42.fc8
I have an interesting new Information. Just a curiocity, I installed back the orignial factory image (Win Vista Home) for Toshiba Satellite A135-S1704. When I opened Device Manager, it reports I have Atheros AR5007EG not AR5006EG as reported in Linux side. I'm not sure which is correct. Assuming the Windows's report is correct then it seems we have a bug in the utility or incorrect database for this wireless device.
I'm also having the problem with the ath5k driver. SIOCSIFFLAGS: invalid argument and clashing with madwifi. I tried renaming the ath5k module to xath5k but lsmod shows it is still loaded. And I added ath5k to /etc/modprobe.d/blacklist and lsmod shows it is still loaded. So how do I get rid of the thing, and where is it hiding?
(In reply to comment #69) This sounds strange as whenever the right madwifi kernel module and madwifi packages are installed, then madwifi goes first [at least in my case]. You should check this first. If nothing helps, you can still decide to go berserk and brutally remove /lib/modules/`uname -r`/kernel/drivers/net/wireless/ath5k/ath5k.ko or move it out of place followed by a system reboot. The SIOCSIFFLAGS looks as if you were using a rather old kernel. Install the latest update kernel kernel-2.6.23.8-63.fc8. The SIOCSIFFLAGS problem got fixed post kernel-2.6.23.1-42.fc8.
I moved the (renamed) ath5k module clear out of the /lib tree, and that succeeds in keeping it from being loaded, as shown by lsmod. Now things look more promising - will have to wait until I get to a place where there is a working wlan to check it out further, but ath0 is coming up now and is able to do a scan and find there is nothing to connect to. I'm using the 2.6.23.1-21.fc7 kernel since that is the latest one in the official updates for F7.
After the update to kernel 2.6.23.8-63.fc8, my Atheros AR5212 802.11abg NIC (rev 01) is now functional with the ath5k driver. Some weeks ago, I'd followed the directions linked to in comment #39. It looks like that paid off for me. ;) It's notable, I think, that the ath5k driver now works better than the madwifi driver, on account of its actually working after suspend. madwifi needed to be removed and reloaded.
re: comment 72, Gordon, that's great! Thanks for helping the ath5k team! re: comment 68, the AR5007 is just not supported yet -- the reverse engineering guys seemed to think it will be soon. Keep hoping! :-) re: comment 71, if you are using F7 you might want to try 2.6.23.9-45.fc7: http://koji.fedoraproject.org/koji/buildinfo?buildID=26993 As for the madwifi/"how do I remove ath5k" talk, I would appreciate it if you could take that elsewhere. It is not relevant to this bug.
Most devices reported above [ath_info] are concerned by the restrictions pointed out by the ath5k developers [provided the info is still up to date]: http://www.linuxwireless.org/en/users/Drivers/ath5k#supportedchips Notes on supported devices Please note that 001c is an 802.11bg device. As you can see from above the current driver design is for 802.11a, 802.11ab, or 802.11abg. We'll probably need a new device type in the driver for this device to pass only bg initial register writes and baseband gain settings.
After the update to kernel 2.6.23.8-63.fc8, i386, my Atheros AR5005G 802.11abg NIC (rev 01) was NOT functional with the ath5k driver. WLAssistant gave "No networks found!" Joseph Roy D. North E: joseph.north (In reply to comment #33) > Regarding comment 30... > > It is highly unlikely that ath5k will be mature in time for F8's release. > Hopefully we can get it to stop crashing upon mere insertion, hopefully w/ > just the patch in comment 32. If not, then disabling ath5k is probably the > only solution.
I set up my laptop with dual boot. One partition has a Fedora 7 system, with all updates through 18 Dec applied, and with madwifi installed and the ath5k module blacklisted. The other partition has the same system, but madwifi never installed and running kernel 2.6.23.9-45.fc7. The wifi card is a D-Link WNA2330. Booting up with the card installed and the madwifi system everything seems to work. iwlist ath0 scan reports five or six wireless access things. Booting up with the 2.6.23.9-45 system it creates wlan0 and at the point where it is determining IP information for wlan0 it fails. ifconfig shows wlan0 is up. iwlist wlan0 scan returns no scan results. lsmod shows that ath5k and mac80211 modules are loaded. What tests should I run or what results should I report to help those who are working in this area?
Jim, please see comment 39...thanks!
(In reply to comment #77) > Jim, please see comment 39...thanks! But that seems to be talking about madwifi - and it is not madwifi but ath5k that I am trying to use.
(In reply to comment #78) > But that seems to be talking about madwifi - and it is not madwifi > but ath5k that I am trying to use. It's about ath5k but debugging essentially relies on information gathered by means of the madwifi driver and tools. If you post the output of ath_info to the ath5k-devel list, the developers will be able to tell you about the status for device. No scan results indicate missing support for yor device [similarly to bug 420041] which is clearly an upstream issue. By providing register dumps to the developers you would help them to add it which is exactly why John pointed you to comment #39.
Let's consolidate all of these "ath5k doesn't work on my hardware" bugs into one place... If you are new to the party, please see comment 6. Also, for info on how to help the ath5k reverse engineering team: http://marc.info/?l=linux-wireless&m=119282415503974&w=2 Please attach ath_info and/or PCI ID information for any new unsupported cards here...thanks!
*** Bug 331151 has been marked as a duplicate of this bug. ***
*** Bug 383431 has been marked as a duplicate of this bug. ***
*** Bug 392561 has been marked as a duplicate of this bug. ***
*** Bug 428476 has been marked as a duplicate of this bug. ***
Still no scan results with 2.6.23.14-115: -==Device Information==- MAC Version: 5213A(0x70) MAC Revision: 5213A(0x78) PHY Revision: 2112a(0x56) -==EEPROM Information==- EEPROM Version: 5.2 EEPROM Size: 16K Regulatory Domain: 0x63 -==== Capabilities ====- | 802.11a Support: no | | 802.11b Support: yes | | 802.11g Support: yes | | RFKill Support: yes | | 32KHz Crystal: no | ======================== GPIO registers: CR 00000000 DO 00000000 DI 00000017
(In reply to comment #85) > Still no scan results with 2.6.23.14-115: I have been able to obtain scan results using a preview tarball by N. Kossifidis with my D-Link DWL-G520 rev. B4, see bug 420041, but these modifications have not even reached wireless upstream yet. -==Device Information==- MAC Version: 5213A (0x70) MAC Revision: 5213A (0x79) PHY Revision: 2112a (0x56) -==EEPROM Information==- EEPROM Version: 5.1 EEPROM Size: 16K Regulatory Domain: 0x30 -==== Capabilities ====- | 802.11a Support: no | | 802.11b Support: yes | | 802.11g Support: yes | | RFKill Support: no | | 32KHz Crystal: no | ======================== GPIO registers: CR 00000000 DO 00000000 DI 00000010 However, even for an unencrypted AP, no data is actually transmitted. Hopefully more luck with the next driver update discussed at https://lists.ath5k.org/pipermail/ath5k-devel/2008-January/000500.html
Hello ppl ;-) Currently unsupported ath5k chips: a) 5210 - only scan is supported (pci_id = 168c:0007) b) 2413 - working on RF initialization (pci_id = 168c:001a) Thanx to Joachim i managed to fix scaning but it still needs some work to transmit, Compex has donated a 2414 card to MadWiFi project, Mike already mailed it to me and i hope i'll get my hands on it soon. To identify your card check out radio revision, if it's 0x56 then you have a 2413/2414 (btw updated ath_info tool can be found in the madwifi-trace branch, ath_info found in trunk is obsolete right now -it's just that we are also using ath_info tool to rev. engineer eeprom-). c) 5424/2424/2425 - No tx/rx (pci_id = 168c:001c) These are some newer PCI-E cards we don't know much about, thanx to Sergei Litvinenko i managed to fix nic_wakeup that was causing card's pci unit to hang and always return 0xff.. (even madwifi can't work after that) but no tx/rx at all yet. Also Atheros has posted a patch for MadWiFi (HAL update for x86 platforms) to support newer 2425 (5007EG) parts (see http://madwifi.org/ticket/1679) so you don't need to use ndiswrapper (this is also useful if you want to provide us with regdumps with madwifi-trace -just apply the patch on madwifi-trace branch). d) 5416/5418 - Unsupported (pci_id = 168c:0023/0024) These are the newer 802.11n parts found on new Macbook Pros (3.1) etc, we are not currently working on those (we are trying to fix 5212-combatible cards above first) but we will in the future. Currently MadWiFi trunk supports these cards (i'd also suggest to use 2425 patch mentioned above since it updates HAL and fixes stability/connectivity on 5416/5418 too). Also if you want to help us improve ath5k, there are updated instructions here-> http://madwifi.org/wiki/DevDocs/MadwifiTrace (we are mostly looking from dumps for 5424/2424/2425 cards since we don't have such cards to test) Thanx a lot for your support !!!
*** Bug 432204 has been marked as a duplicate of this bug. ***
I just got RF2413 to associate but seems it has some trouble acking packets (gets deauthenticated and reports many tx errors). It'll need some more testing before a patch is ready. I hope i'll have something by the end of the week ;-)
*** Bug 433732 has been marked as a duplicate of this bug. ***
The latest ath5k snapshot provided by N. Kossifidis at: ftp://www.kernel.org/pub/linux/kernel/people/mickflemm/ provides full network connectivity for my D-Link DWL-G520 Rev. B4 for which the device information is given in comment #86. Great job !!!
(prompted by to comment 91) Is there a fedora 8 test kernel with the latest snapshot patches?
(In reply to comment #92) > (prompted by to comment 91) > Is there a fedora 8 test kernel with the latest snapshot patches? 2.6.24.3-12 is in the updates-testing repository.
Still not working for my in 2.6.24.3-12 ath5k_pci 0000:05:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of 0000:05:00.0 failed with error -5 Card Atheros AR5006EG in BenQ P52EG notebook 05:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01) Subsystem: Unknown device 1a32:0100 Flags: fast devsel, IRQ 20 Memory at c0300000 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Kernel modules: ath5k
Comment #27 From Stephen (sdeasey) on 2008-03-02 18:25 EST [reply]01 Private ath5k fails to load on my Z60t: $ dmesg ... ACPI: PCI Interrupt 0000:13:00.0[A] -> GSI 19 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:13:00.0 to 64 ath5k_pci 0000:13:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ACPI: PCI interrupt for device 0000:13:00.0 disabled ath5k_pci: probe of 0000:13:00.0 failed with error -5 ... $ lspci -nvv 13:00.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5212 802.11abg NIC [168c:1014] (rev 01) Subsystem: IBM ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (AR5BXB6) [1014:058a] Flags: fast devsel, IRQ 21 Memory at a7f00000 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: <access denied> Kernel modules: ath_pci, ath5k madwifi from livna works on this machine. It looks like this: $ modprobe ath_pci ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) wlan: 0.8.4.2 (0.9.3.3) ath_pci: 0.9.4.5 (0.9.3.3) ACPI: PCI Interrupt 0000:13:00.0[A] -> GSI 19 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:13:00.0 to 64 ath_rate_sample: 1.2 (0.9.3.3) wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 10.3 phy 6.1 radio 10.2 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0xa7f00000, irq=21 $ sudo ./ath_info 0xa7f00000 Warning: Invalid EEPROM Magic number! -==Device Information==- MAC Version: 2424 (0xa0) MAC Revision: 5424 (0xa3) 5Ghz PHY Revision: SChip (0xa2) 2Ghz PHY Revision: SChip (0xa2) -==EEPROM Information==- EEPROM Version: 5.3 EEPROM Size: 4K Regulatory Domain: 0x62 -==== Capabilities ====- | 802.11a Support: yes | | 802.11b Support: yes | | 802.11g Support: yes | | RFKill Support: yes | | 32KHz Crystal: no | ======================== GPIO registers: CR 0001800f DO 00000003 DI 0000000b $ rpm -q kernel kernel-2.6.23.14-115.fc8
Above is copied from bug 279471 coment 27...
kernel-2.6.25-0.105.rc5.fc9 now provides full connectivity for the D-Link DWL-G520 Rev. B4 introduced in comment #86 effectively resolving bug 420041.
With the latest stable kernel available via yum on F8 this works for me with the integrated wireless on the HP Compaq nc6000 notebook. Thanks to all the hardworking developers on this!
Its little better but still not working on kernel 2.6.24.3-34.fc8 on BenQ P52EG notebook. Its initializing during boot correctly this time: [root@nightchill ~]# dmesg | grep ath ath5k_pci 0000:05:00.0: registered as 'phy0' ath5k phy0: Atheros AR2424 chip found (MAC: 0xa0, PHY: 0x61) and I can see wifi0 interface [root@nightchill ~]# iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wifi0 IEEE 802.11 ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 but I cannot make it up [root@nightchill ~]# ifconfig wifi0 up SIOCSIFFLAGS: Resource temporarily unavailable ifconfig makes this logs in dmesg ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: unable to reset hardware: -11
*** Bug 442220 has been marked as a duplicate of this bug. ***
(In reply to comment #99) > Its little better but still not working on kernel 2.6.24.3-34.fc8 on BenQ P52EG > notebook. > > Its initializing during boot correctly this time: > > [root@nightchill ~]# dmesg | grep ath > ath5k_pci 0000:05:00.0: registered as 'phy0' > ath5k phy0: Atheros AR2424 chip found (MAC: 0xa0, PHY: 0x61) > > and I can see wifi0 interface > > [root@nightchill ~]# iwconfig > lo no wireless extensions. > > eth0 no wireless extensions. > > wmaster0 no wireless extensions. > > wifi0 IEEE 802.11 ESSID:"" > Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated > Tx-Power=0 dBm > Retry min limit:7 RTS thr:off Fragment thr=2352 B > Encryption key:off > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > but I cannot make it up > > [root@nightchill ~]# ifconfig wifi0 up > SIOCSIFFLAGS: Resource temporarily unavailable > > ifconfig makes this logs in dmesg > > ath5k phy0: noise floor calibration timeout (2412MHz) > ath5k phy0: unable to reset hardware: -11 > Interesting, plz try the following... edit hw.c (found inside drivers/net/wireless/ath5k/ -you may also try compat-wireless package from http://www.linuxwireless.org/en/users/Download) on ath5k_hw_attach find... ah->ah_radio = AR5K_RF5413; and change it with ah->ah_radio = AR5K_RF2413; recompile and see if it works ;-)
Unfortunately I don't have time to prepare kernel and compile it. If you can provide .rpm package with kernel I can test it
(In reply to comment #102) > Unfortunately I don't have time to prepare kernel and compile it. If you can > provide .rpm package with kernel I can test it You don't need to build a kernel. Just compile the module sources after you have modified them against the one which is installed [make sure you have installed kernel-devel and kernel-headers] and put ath5k.ko into /lib/modules/../updates plus 'depmod -a' and reboot.
You can also download compat-wireless tarball from here -> http://www.linuxwireless.org/en/users/Download modify drivers/net/wireless/ath5k/hw.c make make install load
Hi, a number of bug reports (including bug 442220) have been folded into this one. Pardon my cluelessness, but it's not clear whether to start at the top and try every suggestion and post all the output, or start somewhere in the middle, and if so, precisely where. Is the last comment an alternative to the ideal solution, or the ideal solution? It has a link which includes http://www.linuxwireless.org/en/users/Download#DoIneedthisonFedora.3F which says that "Therefore you really only need compat-wireless-2.6 package on Fedora if you are using a really old kernel and you can't upgrade for some reason. Note that yum update is reasonably useful, although it can be weeks behind. If you want to be sure to get the latest Fedora kernels which have wireless-testing.git code in you can get them here: http://koji.fedoraproject.org/koji/userinfo?userID=388" so is then http://koji.fedoraproject.org/koji/userinfo?userID=388 the recommended place to start for fedora users?
The driver is not yet completly reverse engineered. That's in most cases the reason why it does not work. On http://marc.info/?l=linux-wireless&m=119282415503974&w=2 you can find information how to help the devs reverse engineer your device.
Yup that's why i ask for your help, i don't have a AR2424 card to test so i need to know if it's radio is like RF2413 (as AR5424 which has RF5413 radio). Also documentation for register dumps is here -> http://madwifi.org/wiki/DevDocs/MadwifiTrace
P V, the koji link is the right place to start if you know nothing else. In this case, we know the device is not supported so Nick asked for some help in debugging the issue. The compat-wireless-2.6 stuff is suggested as an alternative to building a complete kernel. Hth!
Seems like no changes :( ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:05:00.0 to 64 ath5k_pci 0000:05:00.0: registered as 'phy0' phy0: Selected rate control algorithm 'pid' ath5k phy0: Atheros AR2424 chip found (MAC: 0xa0, PHY: 0x61) udev: renamed network interface wlan0 to wifi0 ath5k phy0: invalid phy radio: 0 ath5k phy0: unable to reset hardware: -22 ath5k phy0: invalid phy radio: 0 ath5k phy0: unable to reset hardware: -22 ath5k phy0: invalid phy radio: 0 ath5k phy0: unable to reset hardware: -22 ath5k phy0: invalid phy radio: 0 ath5k phy0: unable to reset hardware: -22 ath5k phy0: invalid phy radio: 0 [root@nightchill rt2x00]# iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. wifi0 IEEE 802.11 ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 [root@nightchill rt2x00]# ifconfig wifi0 up SIOCSIFFLAGS: Invalid argument ath5k phy0: invalid phy radio: 0 ath5k phy0: unable to reset hardware: -22 Tested with latest compat-wireless
*** Bug 443727 has been marked as a duplicate of this bug. ***
Just tried to install a fedora live and got into trrouble wuith my wireles card 3Com 3crdag675. This is the oputput for the card under core 6, core 8 juast keeps reporting a link quality of 0/0 ath0 IEEE 802.11g ESSID:"XXXXXXXXXX" Nickname:"localhost.localdomain" Mode:Managed Frequency:2.412 GHz Access Point: YY:YY:YY:YY:YY:YY Bit Rate:6 Mb/s Tx-Power:15 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=11/94 Signal level=-82 dBm Noise level=-93 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Should this card already work, or back to madwifi for Core 8
As of kernel version: kernel-2.6.25-8.fc9.i686, my Macbook Pro (intel) laptop started seeing the wireless network (previously had to use madwifi). It mostly works - however, it once froze the whole system while switching to another wireless network and sometimes it fails to connect. In the latter case, I see in dmesg: ath0: CTS protection enabled (BSSID=00:02:8a:3c:27:2b) ath0: CTS protection disabled (BSSID=00:02:8a:3c:27:2b) ath0: No ProbeResp from current AP 00:02:8a:3c:27:2b - assume out of range ath5k phy0: calibration timeout (2417MHz) ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz) ath5k phy0: noise floor calibration failed (2417MHz) ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz) ath0: failed to restore operational channel after scan ath0: Initial auth_alg=0 ath0: authenticate with AP 00:02:8a:42:1d:6f ath0: authenticate with AP 00:02:8a:42:1d:6f ath5k phy0: calibration timeout (2417MHz) ath5k phy0: can't reset hardware (-11) ath0: Failed to config new BSSID to the low-level driver ath0: authenticate with AP 00:02:8a:42:1d:6f ath0: authentication with AP 00:02:8a:42:1d:6f timed out ath5k phy0: noise floor calibration timeout (2417MHz) ath0: Initial auth_alg=0 ath0: authenticate with AP 00:02:8a:42:1d:6f ath0: authenticate with AP 00:02:8a:42:1d:6f ath0: authenticate with AP 00:02:8a:42:1d:6f ath0: authentication with AP 00:02:8a:42:1d:6f timed out ath5k phy0: calibration timeout (2412MHz) ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz) ath0: failed to set freq to 2412 MHz for scan ath5k phy0: calibration timeout (2417MHz) ath5k phy0: ath5k_chan_set: unable to reset channel (2417 Mhz) ath0: failed to set freq to 2417 MHz for scan ath5k phy0: calibration timeout (2422MHz) ath5k phy0: ath5k_chan_set: unable to reset channel (2422 Mhz) ath0: failed to set freq to 2422 MHz for scan ath0: failed to set freq to 2427 MHz for scan ath0: failed to set freq to 2432 MHz for scan ath0: failed to set freq to 2437 MHz for scan ath0: failed to set freq to 2442 MHz for scan ath0: failed to set freq to 2447 MHz for scan printk: 10 messages suppressed. ath5k phy0: noise floor calibration timeout (2452MHz) ath0: failed to set freq to 2452 MHz for scan ath0: failed to set freq to 2457 MHz for scan ath0: failed to set freq to 2462 MHz for scan ath0: failed to set freq to 5180 MHz for scan ath0: failed to set freq to 5200 MHz for scan ath0: failed to set freq to 5220 MHz for scan ath0: failed to set freq to 5240 MHz for scan ath0: failed to set freq to 5245 MHz for scan printk: 16 messages suppressed. Sometimes I also see: ath5k_hw_set_txpower_limit: changing txpower to 100 ath5k_hw_txpower: invalid tx power: 100 lspci -v reports the following on this machine: 03:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) Subsystem: Apple Computer Inc. Unknown device 0086 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at 90100000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Capabilities: [100] Advanced Error Reporting <?> Capabilities: [140] Virtual Channel <?> Kernel driver in use: ath5k_pci Kernel modules: ath5k and lspci -n 03:00.0 0200: 168c:001c (rev 01) --------- It also seems to work to on Intel Mac mini. However, once NetworkManager connects to any wireless network, scanning stops working. lspci reports the same info as above. I don't exactly know why the scanning issue appears only on this machine.
That's interesting it's the first report of RF242* working, can you plz post dmesg output on module load (when it says the mac/phy revision of your card) ?
Few things: 1) Scanning fails on both systems while connected to any wireless network (so no difference between the computers as I said above). 2) It would be great if the network configuration GUI programs would list these Atheros cards as options. Couldn't find it from the list... Created ifcfg-ath0 by hand. 3) When I load the module, I just see the following: ath5k_pci 0000:03:00.0: registered as 'phy0' ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61) udev: renamed network interface wlan0 to ath0 ADDRCONF(NETDEV_UP): ath0: link is not ready ath0: Initial auth_alg=0 ath0: authenticate with AP 00:1c:f0:49:f8:e5 ath0: authenticate with AP 00:1c:f0:49:f8:e5 ath0: authenticate with AP 00:1c:f0:49:f8:e5 ath0: authentication with AP 00:1c:f0:49:f8:e5 timed out .etc. 4) Got my system to freeze the 2nd time now. Again when switching to another wireless network. Had to do hard reboot (keyboard dead as seen by caps lock led stopped responding..) 5) I noticed that at some point the automatic rate negotiation went crazy. By looking at the interface with iwconfig, I could see that the transfer rate kept changing rapidly even when I am connected to a base station right next to me (= no signal strength problems). This resulted in very low transfer rates. If I issued iwconfig ath0 rate 11M, for example, the transfer rates went back up and iwconfig showed 11M rate all the time. So I guess there are some problems with rate autoneg (BTW this used to be the case with madwifi too, I would have to set the rate manually).
3) O.K. you have AR54242, that makes sense as it has a RF5413 phy which is supported. We need to update pci-id -> name mapping. 5) That's because we still haven't fixed txpower support and there are still some missing bits on phy calibration. This results failed tx / rx packets that affect rate control algorithm. I suggest you lock your card to b rates to avoid most of these bugs (b rates don't have problem because they use CCK modulation that doesn't have calibration problems). Also have in mind that if you are too close to AP you'll have noise problems (we don't support ANI -adaptive noise immunity- etc yet and madwifi's HAL had a bug on ANI). In my tests when AP was next to my laptop i couldn't get above 18M, on another setup i could get up to 54M (27M measured with iperf).
As of kernel-2.6.25-14.fc9.x86_64.rpm on mac mini: 02:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01) I get the hardware recognized but every time I try to connect with NetworkManager or play with iwconfig to set to 11M, I see this in the log: ath5k phy0: calibration timeout (2412MHz) ath5k phy0: unable to reset hardware: -11
RE: comment #116 that chipset may work with the upstream madwifi ath_pci module if you get it from svn, that works for my macbook's a/b/g/n AR5618 chipset. info on using svn trunk for madwifi here (this is what works for me) http://www.thinkwiki.org/wiki/How_to_checkout_and_install_madwifi_experimental_driver_for_ar5008
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 448651 has been marked as a duplicate of this bug. ***
*** Bug 443176 has been marked as a duplicate of this bug. ***
Similar problem here. Sometimes the wireless card works but most times don't. Wireless card: Encore ENLWI-SG lspci -v: 00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01) Subsystem: Atheros Communications Inc. Unknown device 2011 Flags: medium devsel, IRQ 17 Memory at b5800000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 Kernel modules: ath5k /var/log/messages: Jul 12 16:41:11 axp2600 kernel: PCI: Enabling device 0000:00:0e.0 (0014 -> 0016) Jul 12 16:41:11 axp2600 kernel: ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 17 (level, low) -> IRQ 17 Jul 12 16:41:11 axp2600 kernel: ath5k_pci 0000:00:0e.0: registered as 'phy0' Jul 12 16:41:11 axp2600 kernel: ath5k phy0: failed to resume the MAC Chip Jul 12 16:41:11 axp2600 kernel: ACPI: PCI interrupt for device 0000:00:0e.0 disabled Jul 12 16:41:11 axp2600 kernel: ath5k_pci: probe of 0000:00:0e.0 failed with error -5 kernel: 2.6.25.6-55.fc9.i686
(In reply to comment #121) > kernel: 2.6.25.6-55.fc9.i686 Before reporting problems here, make sure that your issue still applies to the latest koji build. Currently, this is kernel-2.6.25.10-91.fc9 which is significantly newer than the package that you are using. http://koji.fedoraproject.org/koji/buildinfo?buildID=55587
Yep, happens the same with kernel-2.6.25.10-91.fc9.i686. Same errors, same messages.
*** Bug 457553 has been marked as a duplicate of this bug. ***
Just curious how many people are still in this situation? If ath5k is not working for you in F9, can you try a late rawhide kernel? Does that work any better? Please post a few results here...thanks!
AR5212 works great here and has done so for all F9 and the latter part of F8.
I have no success with the 2.6.26.3-29 kernel on my HP Pavillion dv9000 with the AR242x 802.11abg PCE express adapter.
(In reply to comment #126) > AR5212 works great here and has done so for all F9 and the latter part of F8. Spoke too soon. After about 20 minutes use, speed drops to nothing and I get the following in /var/log/messages: ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) ath5k phy0: noise floor calibration timeout (2412MHz) etc. Let me know if there's anything I can do to help debug this.
I think this blanket bug has served its purpose. I'm going to close it. Please open new bugs for any specific problems with remain in 2.6.27 or later kernels.