Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2149 - ar71xx and ATH9k crash after wireless reload ( ath9k ) #7082

Closed
openwrt-bot opened this issue Feb 27, 2019 · 6 comments
Closed

FS#2149 - ar71xx and ATH9k crash after wireless reload ( ath9k ) #7082

openwrt-bot opened this issue Feb 27, 2019 · 6 comments
Labels

Comments

@openwrt-bot
Copy link

DanielRIOT:

  • ar71xx and ATH79 targets ( Arduino Yun / Omega onion )
  • ( 18.06 ) Linux OpenWrt 4.14.101 #0 Mon Feb 25 14:49:16 2019 mips GNU/Linux ( current trunk )
  • Steps to reproduce : change channel frequency or power and reload network

SOC: AR9330 rev. 1
CPU: MIPS 24Kc
RAM: 64 MB DDR2 16-bit CL3-4-4-10
FLASH: 16 MB Winbond W25Q128
CLOCKS: CPU/RAM/AHB/SPI/REF ( 400/400/200/ 25/ 25 MHz )

I've got some strange behavior on both ar71xx and ATH79 targets with the current master build ( porting from generic ar71xx to generic ATH79 ).

Every 3rd or 4th time and sometimes on startup when I call /etc/init.d/network reload after changing txpower or channel the system hangs right after the wireless interface comes back up, sometimes the system hangs, other times I get a kernel dump.

it also happens on boot but the system usually recovers by rebooting and all is well until settings change and interface is taken down/ brought up again - might be related to [[https://bugs.openwrt.org/index.php?do=details&task_id=2143|task_id=2143]] )

at first I thought my VLAN configuration and batman-adv / 802.11 mesh could be contributing but I've removed those from the build and it still happens.
/etc/config/network :
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd1a:dac4:c1f3::/48'

config interface 'lan'
option ifname 'eth0'
option proto 'static'
option ipaddr '10.0.0.1'
option netmask '255.255.255.0'

config interface 'wan'
option proto 'dhcp'

/etc/config/wireless :
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/ahb/18100000.wmac'
option htmode 'HT20'
option disabled '0'
option channel '9'

config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'
option network 'lan wan'

the most recent crash dump [[https://gist.github.com/DanielRIOT/28bd2021a1b73f4de3fcf44de14b656c |at this gist]] ,

dmesg [[https://gist.github.com/DanielRIOT/b15903358324c45e6b56b428ba46b9b7| output Gist ]]

I use the following script to change channels easily: call it by " change 1"

#!/bin/sh

LOWEST=1 # cannot set to channels lower than this
HIGHEST=13 # highest channel

check that we got an input

if [ $# -lt 1 ]
then
echo "Usage: $0 [channel no ($LOWEST .. $HIGHEST]"
exit 1
fi

if [ $1 -lt $LOWEST ];then
>&2 echo "$1 is not a valid channel ($LOWEST .. $HIGHEST)"
elif [ $1 -gt $HIGHEST ];then
>&2 echo "$1 is not a valid channel ($LOWEST .. $HIGHEST)"
else :

uci set wireless.radio0.channel=$1
uci commit
/etc/init.d/network reload
fi

@openwrt-bot
Copy link
Author

ynezz:

Is this reproducible with image from http://downloads.openwrt.org/snapshots/ ? Can you reproduce it also with image from http://downloads.openwrt.org/releases/18.06.2/ ?

@openwrt-bot
Copy link
Author

DanielRIOT:

can recreate the crash with snapshot and 18.06.2 images

crashlog for snapshot image : [[https://gist.github.com/DanielRIOT/56e35f85b42e77531aeff7a616fe57db|gist here ]]

18.06.2 image crashed both times without a kernel dump and rebooted

it can also be triggered by manually issuing channel changes via command each within a minute or so of each other, it happens sporadically - sometimes one can go 7 o 8 channel changes before a crash, other times 1 or 2 will do it

I was doing RF power testing for each channel and picked this up, thus the many channel changes

uci set wireless.radio0.channel=2
uci commit
/etc/init.d/network reload

  • When testing the pre-built images with the Yun, boot seems to fail after a while - it is not the case : the kernel merely reverts to 9600 baud for console as Arduino/Doghunter used 250000 as a console baudrate which is not supported in the Openwrt builds without an arduino specific patch. ( [[https://github.com/difference between this config and OpenWRT18.06 arduino/lede-yun#4| discussion on the Yun fork for those interested ]] )

@openwrt-bot
Copy link
Author

ynezz:

I've just downloaded http://downloads.openwrt.org/snapshots/targets/ar71xx/generic/openwrt-ar71xx-generic-om2p-squashfs-sysupgrade.bin and flashed my om2pv2 which is Atheros AR9330 rev 1 as well, but I'm not able to reproduce the issue you're reporting.

while true; do for chan in $(seq 1 13); do uci set wireless.radio0.channel=$chan; uci commit; wifi; sleep 5; iwinfo | grep Channel sleep 60 done done

It works fine for several minutes already, and doesn't crash the kernel here.

BTW looking at your last gist, it seems like you're having some memory issues (either out of memory or some RAM stability issues).

@openwrt-bot
Copy link
Author

DanielRIOT:

I'm looking into the u-boot RAM configuration now.

I updated u-boot from standard Arduino Yun one to the pepe2k u-boot mod and the DDR registers timings are very different. - this could be where the instability comes from

@openwrt-bot
Copy link
Author

ptpt52:

hi
This similar problem occurs on my ar9344 base board, also using the pepe2k u-boot mod

if u know how to setup the DDR on u-boot, please tell me

@openwrt-bot
Copy link
Author

thornley-pdi:

Chen, what information do you have regarding setting up DDR registers on u-boot? We have DDR stability issues (random page_faults) with WinBond memory and AR9331, also using pepe2k u-boot mod. Also tried many different DDR register settings (returning to original u-boot values) but nothing has stablised, nor do we have a reliable method to reproduce the problem yet. Any information would be great! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant