configuring ath0 freezes the system
Loading if_ath works, but when configuring the device the system locks up/freezes.
System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.
Running "ifconfig ath0 up" works.
Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.
I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.
I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.
The 3.6-RELEASE have been used successfully with the same hardware.
Here are the ath related snippets from the dmesg output:
wlan: <802.11 Link Layer>
ath_dfs: WTF module
ath_rate: <SampleRate bit-rate selection algorithm>
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at
device 5.0 on pci3
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
ath0: AR2413 mac 7.8 RF2413 phy 4.5
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056
ath0: Use hw queue 1 for WME_AC_BE traffic
ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic
ath0: Use hw queue 3 for WME_AC_VO traffic
ath0: Use hw queue 8 for CAB traffic
ath0: Use hw queue 9 for beacons
ath0: using multicast key search
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at
device 5.0 on pci3
pci3: <ACPI PCI bus> [attached!] on pcib3
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0
#1 Updated by swildner about 1 month ago
Okay, I'm fairly certain that reverting the most recent work on ath(4) (sleep state code synchronization) should fix it. After all, it added the message you see last.
Can you please verify by applying: http://leaf.dragonflybsd.org/~swildner/0001-kernel-ath-Revert-881d974b800-and-d98a0bcf56c.patch
(for example with 'git am <patch>' on the 3.8 branch)
I hope you have some git knowledge to juggle the patches you have locally on your branch.
#3 Updated by swildner about 1 month ago
Can you give us a dump in the failing state?
Backup the working kernel by copying the /boot/kernel directory to /boot/kernel.bak. Then, revert the patch, recompile/install the kernel and bring it to the point where it hangs. Then, hit CTL-ALT-ESC to break into ddb. At the "db>" prompt, do "call dumpsys" (it should dump to disk then and countdown numbers on the console). When it is finished do "reset" to reboot. At the loader menu, it will then give you an option (I think it's "b") to boot the previously backed up working kernel.bak. Upon coming up, it will save the dump to /var/crash. Then, tar/xz the kern.XX and vmcore.XX with the highest number from /var/crash and put it up somewhere from where it can be downloaded.
#4 Updated by xbit about 1 month ago
I would like to provide that crash dump, but unfortunately my USB keyboard stops works as soon as the system freezes. Neither CTRL-ALT-ESC nor using the NUMLOCK key works.
Is there any other way to trigger creating a crash dump? Will a non-USB keyboard (PS/2) work?