OpenWrt Forum Archive

Topic: Netgear R8000 support?

The content of this topic has been archived between 23 Mar 2018 and 5 May 2018. Unfortunately there are posts – most likely complete pages – missing.

in the past, i have gotten my image from here:
https://downloads.openwrt.org/chaos_cal … x/generic/
I have been having weird issues where my router needs to be rebooted, so i decided to see if there was an update.
this time, i went to the wiki, and found this:
https://downloads.openwrt.org/snapshots … x/generic/
i didnt realize it was different, but i did see it was more recent, so i gave it a shot.

my router came back up, but with no web gui (just like last upgrade) so i ran:
opkg update
opkg install luci-ssl
/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

but unfortunately, i get:
"Bad Gateway
The process did not produce any response"

it was at this point that i realized it was a different build...
after a little research, i tried:
sysupgrade -v https://downloads.openwrt.org/chaos_cal … uashfs.chk
but got: Invalid image type. Please use only .trx files
Image check 'platform_check_image' failed.

wifi is currently barely working (only 5ghz, and only on one device, although i have multiple with 5ghz capability.

can someone point me in the right direction?

thanks!

adamaze wrote:

in the past, i have gotten my image from here:
https://downloads.openwrt.org/chaos_cal … x/generic/
I have been having weird issues where my router needs to be rebooted, so i decided to see if there was an update.
this time, i went to the wiki, and found this:
https://downloads.openwrt.org/snapshots … x/generic/
i didnt realize it was different, but i did see it was more recent, so i gave it a shot.

my router came back up, but with no web gui (just like last upgrade) so i ran:
opkg update
opkg install luci-ssl
/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

but unfortunately, i get:
"Bad Gateway
The process did not produce any response"

it was at this point that i realized it was a different build...
after a little research, i tried:
sysupgrade -v https://downloads.openwrt.org/chaos_cal … uashfs.chk
but got: Invalid image type. Please use only .trx files
Image check 'platform_check_image' failed.

wifi is currently barely working (only 5ghz, and only on one device, although i have multiple with 5ghz capability.

can someone point me in the right direction?

thanks!


Single WiFi working is a known issue in Trunk. Regarding sysupgrade try downloading the firmware file and uploading to /tmp of the router and then try sysupgrade /tmp/openwrt-15.05-bcm53xx-netgear-r8000-squashfs.chk thats how i got out of it.

adityaxavier wrote:

Thanks for the reply !

1. Am using OpenWrt CC build :- r46450
2. Am using 5G (radio0) - AC Band for testing.
3. Distance between Client and Router is around 8ft apart ( Clear view of sight )
4. Client is MacBook Pro 2015
5. Am testing using the drop down details of Wifi attaching images for reference.
6. I can't test using iPerf cause somehow it keeps hanging at 13 bits ( possibly OSX Issue )
7. Same router, at same distance using same client, using stock Firmware am getting between 1053-1300Mbps (UI)
8. Am only testing LAN Speeds.

Stock Firmware :- http://picpaste.com/Screen_Shot_2016-01 … ajTNia.png
OpenWrt :- http://picpaste.com/Screen_Shot_2016-01 … s1lasR.png

OpenWrt Config :-

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option path '18000000.axi/bcma0:7/pci0000:00/0000:00:00.0/0000:01:00.0'
    option htmode 'VHT80'
    option channel '40'
    option txpower '20'
    option country '00'

config wifi-iface
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'AdityaXavier5G1'
    option encryption 'psk2'

I think i have found another issue.. Something which doesn't make much sense.

You can see in the configuration i have set it to be at Channel 40. But i see that the signal is at Channel 48 !

dmesg :- http://pastebin.com/rxvmgctK
nvram :- http://pastebin.com/bcchQLd9

Apart from this please do let me know if you need anymore data.

Please read post 157, but there are some more posts in this thread where I state this also. The HW design of the R8000 requires that the first 5G device (radio0) is to be used on higher bands only. If you use lower bands it will work,  but not very well. The second 5G device (radio2) is to be used with lower bands only.

meuleman wrote:

You can see in the configuration i have set it to be at Channel 40. But i see that the signal is at Channel 48 !

Please read post 157, but there are some more posts in this thread where I state this also. The HW design of the R8000 requires that the first 5G device (radio0) is to be used on higher bands only. If you use lower bands it will work,  but not very well. The second 5G device (radio2) is to be used with lower bands only.

Sorry my bad, i remembered it the other way around till now. Btw, do you suppose the issue of wrong Channel (48) even though configured as (40) is due to that ?

1. Can you please help me as to what differences are there in terms of filesystem implementation between Asus AC56U and R8000 ? Is the problem due to Netgear specific implementation ?

2. GPIO LED is still a problem? I thought it was patched already.. but in my case they don't light up.

adityaxavier wrote:

Regarding 5:
Please do let me know if you need any help testing the same. Promise i'll be quick smile
Or better yet, you can ssh into my router and try whatever you need to wink

If you can test few images for me, I think I should be able to fix this problem.

adityaxavier wrote:

3. GPIO LEDS not working.
    ( Would http://svn.dd-wrt.com/browser/src/route … ?rev=28812 be of any help ?)
    Am planning on spending more time on it this weekend.

Fixed in trunk: https://dev.openwrt.org/changeset/47282/
Fixed in chaos_calmer: https://dev.openwrt.org/changeset/47400/ (you'll have to wait for & install 15.05.1)

adityaxavier wrote:

4. Regarding cannot open "ubi0:rootfs", error -19, as per the ticket and your previous Message it exists in both trunk and CC, but i find this happening only using Trunk.

Please provide a boot log, this issue should really be fixed already.

Zajec wrote:
adityaxavier wrote:

Regarding 5:
Please do let me know if you need any help testing the same. Promise i'll be quick smile
Or better yet, you can ssh into my router and try whatever you need to wink

If you can test few images for me, I think I should be able to fix this problem.

adityaxavier wrote:

3. GPIO LEDS not working.
    ( Would http://svn.dd-wrt.com/browser/src/route … ?rev=28812 be of any help ?)
    Am planning on spending more time on it this weekend.

Fixed in trunk: https://dev.openwrt.org/changeset/47282/
Fixed in chaos_calmer: https://dev.openwrt.org/changeset/47400/ (you'll have to wait for & install 15.05.1)

adityaxavier wrote:

4. Regarding cannot open "ubi0:rootfs", error -19, as per the ticket and your previous Message it exists in both trunk and CC, but i find this happening only using Trunk.

Please provide a boot log, this issue should really be fixed already.

Sure, would be more than happy to help you test.

Regarding the "ubi0:rootfs", error -19" i'll post the logs as soon as am back home. BTW, as i said this is happening only in trunk. I don't see this error in CC.

adityaxavier wrote:

Sure, would be more than happy to help you test.

Thanks! I'll e-mail you some images to test.

adityaxavier wrote:

Regarding the "ubi0:rootfs", error -19" i'll post the logs as soon as am back home. BTW, as i said this is happening only in trunk. I don't see this error in CC.

As commented in https://dev.openwrt.org/ticket/20731, this issue should be fixed:

Trunk fixed in r48061, chaos_calmer in r48140.

. If you're using trunk r48061 or newer & you can still see this problem, I'm really interested in the boot log.

Zajec wrote:
adityaxavier wrote:

Sure, would be more than happy to help you test.

Thanks! I'll e-mail you some images to test.

adityaxavier wrote:

Regarding the "ubi0:rootfs", error -19" i'll post the logs as soon as am back home. BTW, as i said this is happening only in trunk. I don't see this error in CC.

As commented in https://dev.openwrt.org/ticket/20731, this issue should be fixed:

Trunk fixed in r48061, chaos_calmer in r48140.

. If you're using trunk r48061 or newer & you can still see this problem, I'm really interested in the boot log.

Sure, i'll be waiting for your email.

I am fairly positive i was using the latest build, however i would recheck it and send the logs if its newer than r48061.

Is the Netgear R8000 currently supported by OpenWrt? This router looks pretty bad ass, but I notice that the versions and current releases aren't populated in the table of supported hardware on the OpenWrt site

thanks adityaxavier, that did the trick!

adityaxavier wrote:
adamaze wrote:

in the past, i have gotten my image from here:
https://downloads.openwrt.org/chaos_cal … x/generic/
I have been having weird issues where my router needs to be rebooted, so i decided to see if there was an update.
this time, i went to the wiki, and found this:
https://downloads.openwrt.org/snapshots … x/generic/
i didnt realize it was different, but i did see it was more recent, so i gave it a shot.

my router came back up, but with no web gui (just like last upgrade) so i ran:
opkg update
opkg install luci-ssl
/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

but unfortunately, i get:
"Bad Gateway
The process did not produce any response"

it was at this point that i realized it was a different build...
after a little research, i tried:
sysupgrade -v https://downloads.openwrt.org/chaos_cal … uashfs.chk
but got: Invalid image type. Please use only .trx files
Image check 'platform_check_image' failed.

wifi is currently barely working (only 5ghz, and only on one device, although i have multiple with 5ghz capability.

can someone point me in the right direction?

thanks!


Single WiFi working is a known issue in Trunk. Regarding sysupgrade try downloading the firmware file and uploading to /tmp of the router and then try sysupgrade /tmp/openwrt-15.05-bcm53xx-netgear-r8000-squashfs.chk thats how i got out of it.

pahht wrote:

Is the Netgear R8000 currently supported by OpenWrt? This router looks pretty bad ass, but I notice that the versions and current releases aren't populated in the table of supported hardware on the OpenWrt site

I'd suggest reading the first post here : https://forum.openwrt.org/viewtopic.php?id=50914

And trying the image posted by Arokh. He refreshes every couple of days, and it is a full image
Working beautifully on my R8000(access point) and my WRT1900ACv2(main gateway).

mojolacerator wrote:
pahht wrote:

Is the Netgear R8000 currently supported by OpenWrt? This router looks pretty bad ass, but I notice that the versions and current releases aren't populated in the table of supported hardware on the OpenWrt site

I'd suggest reading the first post here : https://forum.openwrt.org/viewtopic.php?id=50914

And trying the image posted by Arokh. He refreshes every couple of days, and it is a full image
Working beautifully on my R8000(access point) and my WRT1900ACv2(main gateway).

So, just to make sure the wireless is working fine with 3 devices instead of one from trunk build?

LogicoZone wrote:

So, just to make sure the wireless is working fine with 3 devices instead of one from trunk build?

(this question/problem isn't related to arokh builds you're referencing by your quote)

For detecting 3 devices by trunk (snapshots) builds please follow:
https://dev.openwrt.org/ticket/21393
Yes, there is some progress.

I just tried r48147 and r48259 from arokh, and it seems like neither gave me 3 devices...
i see radio0/wlan0, but nothing else... am I missing something?

adamaze wrote:

I just tried r48147 and r48259 from arokh, and it seems like neither gave me 3 devices...
i see radio0/wlan0, but nothing else... am I missing something?

Please check the ticket again. It is clearly written Rafal has fixed it in r48382. Either wait for Arokh to update his builds or use the latest trunk, once its built.

Thanks Rafal for fixing all the show stoppers !

pahht wrote:

Is the Netgear R8000 currently supported by OpenWrt? This router looks pretty bad ass, but I notice that the versions and current releases aren't populated in the table of supported hardware on the OpenWrt site

There you go https://wiki.openwrt.org/toh/netgear/r8000

adamaze wrote:

I just tried r48147 and r48259 from arokh, and it seems like neither gave me 3 devices...
i see radio0/wlan0, but nothing else... am I missing something?

I am running arokh's Dec 21 image on my R8000(didn't see a need to change it) - it has 3 radios, no problem. I did not realize things had not continued along that way.....glad to see things are getting fixed up again.

Hi Rafal,

I just had a crash in the logs. Was not there to check the effect, but i there is some problem with the Wireless driver.

[ 1909.984570] br-lan: port 3(wlan2) entered forwarding state
[ 1910.164831] br-lan: port 4(wlan0) entered forwarding state
[92513.717481] ------------[ cut here ]------------
[92513.723313] WARNING: CPU: 1 PID: 2520 at /home/zajec/openwrt/openwrt-arm.git/build_dir/target-arm_cortex-a9_musl-1.1.11_eabi/linux-bcm53xx/compat-wireless-2016-01-10/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:1287 brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac]()
[92513.754140] Modules linked in: pppoe ppp_async iptable_nat brcmfmac b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt compat brcmutil ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio gpio_button_hotplug usbcore nls_base usb_common
[92513.832986] CPU: 1 PID: 2520 Comm: hostapd Not tainted 4.1.15 #3
[92513.840521] Hardware name: BCM5301X
[92513.844890] Backtrace: 
[92513.848012] [<c0016734>] (dump_backtrace) from [<c0016958>] (show_stack+0x18/0x1c)
[92513.857517]  r7:00000507 r6:bf22a295 r5:00000009 r4:00000000
[92513.864662] [<c0016940>] (show_stack) from [<c016d2d0>] (dump_stack+0x78/0x94)
[92513.873743] [<c016d258>] (dump_stack) from [<c00209dc>] (warn_slowpath_common+0x8c/0xb8)
[92513.883888]  r5:00000009 r4:00000000
[92513.888416] [<c0020950>] (warn_slowpath_common) from [<c0020aac>] (warn_slowpath_null+0x24/0x2c)
[92513.899433]  r8:00000148 r7:c66b1b54 r6:c7334480 r5:c7334524 r4:00000001
[92513.907935] [<c0020a88>] (warn_slowpath_null) from [<bf21d5a8>] (brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac])
[92513.921048] [<bf21d4b8>] (brcmf_netdev_wait_pend8021x [brcmfmac]) from [<bf20d744>] (brcmf_cfg80211_leave_ibss+0xe0/0x2e0 [brcmfmac])
[92513.936089]  r7:c66b1ca8 r6:c78db3b0 r5:c7334480 r4:c0408408
[92513.943260] [<bf20d6a4>] (brcmf_cfg80211_leave_ibss [brcmfmac]) from [<bf20f7c0>] (brcmf_cfg80211_add_key+0x214/0x2d8 [brcmfmac])
[92513.957867]  r6:c7334480 r5:00000004 r4:c78db148
[92513.963728] [<bf20f5ac>] (brcmf_cfg80211_add_key [brcmfmac]) from [<bf11164c>] (nl80211_new_key+0xfc/0x128 [cfg80211])
[92513.977140]  r10:00000014 r9:c73ba400 r8:c66b1ca8 r7:c7334000 r6:c6440000 r5:00000000
[92513.987026]  r4:bf20f5ac
[92513.990250] [<bf111550>] (nl80211_new_key [cfg80211]) from [<c026a0f4>] (genl_rcv_msg+0x260/0x2e0)
[92514.001489]  r8:c6191700 r7:c5c18e14 r6:bf120664 r5:bf128ef4 r4:00000000
[92514.009961] [<c0269e94>] (genl_rcv_msg) from [<c0269428>] (netlink_rcv_skb+0x60/0xbc)
[92514.019773]  r10:00000000 r9:00000000 r8:c66b1d8c r7:c7952c00 r6:c0269e94 r5:c6191700
[92514.029643]  r4:c5c18e00
[92514.032829] [<c02693c8>] (netlink_rcv_skb) from [<c0269e80>] (genl_rcv+0x28/0x3c)
[92514.042217]  r7:c7952c00 r6:c6191700 r5:c6191700 r4:c041b3e8
[92514.049368] [<c0269e58>] (genl_rcv) from [<c0268e08>] (netlink_unicast+0x138/0x1f4)
[92514.058964]  r5:00000048 r4:c79e1400
[92514.063467] [<c0268cd0>] (netlink_unicast) from [<c02692b0>] (netlink_sendmsg+0x328/0x344)
[92514.073828]  r9:00000048 r8:c66b1f4c r7:c7952c00 r6:00000000 r5:00000000 r4:c6191700
[92514.083625] [<c0268f88>] (netlink_sendmsg) from [<c022faa8>] (sock_sendmsg+0x1c/0x2c)
[92514.093444]  r10:00000000 r9:c0408408 r8:c7514200 r7:c66b1e64 r6:00000000 r5:00000000
[92514.103311]  r4:c66b1f4c
[92514.106500] [<c022fa8c>] (sock_sendmsg) from [<c022ff14>] (___sys_sendmsg+0x178/0x200)
[92514.116453] [<c022fd9c>] (___sys_sendmsg) from [<c0230cd4>] (__sys_sendmsg+0x44/0x68)
[92514.126276]  r10:00000000 r9:c66b0000 r8:c0009824 r7:00000128 r6:00000000 r5:be8f8040
[92514.136158]  r4:c7514200
[92514.139362] [<c0230c90>] (__sys_sendmsg) from [<c0230d08>] (SyS_sendmsg+0x10/0x14)
[92514.148859]  r6:b6f841d8 r5:00000000 r4:00000000
[92514.154689] [<c0230cf8>] (SyS_sendmsg) from [<c0009680>] (ret_fast_syscall+0x0/0x3c)
[92514.164407] ---[ end trace 10b1f7965c83243e ]---
[92514.217480] ------------[ cut here ]------------
[92514.223313] WARNING: CPU: 1 PID: 2520 at /home/zajec/openwrt/openwrt-arm.git/build_dir/target-arm_cortex-a9_musl-1.1.11_eabi/linux-bcm53xx/compat-wireless-2016-01-10/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:1287 brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac]()
[92514.254137] Modules linked in: pppoe ppp_async iptable_nat brcmfmac b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt compat brcmutil ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio gpio_button_hotplug usbcore nls_base usb_common
[92514.333020] CPU: 1 PID: 2520 Comm: hostapd Tainted: G        W       4.1.15 #3
[92514.342076] Hardware name: BCM5301X
[92514.346447] Backtrace: 
[92514.349565] [<c0016734>] (dump_backtrace) from [<c0016958>] (show_stack+0x18/0x1c)
[92514.359062]  r7:00000507 r6:bf22a295 r5:00000009 r4:00000000
[92514.366209] [<c0016940>] (show_stack) from [<c016d2d0>] (dump_stack+0x78/0x94)
[92514.375291] [<c016d258>] (dump_stack) from [<c00209dc>] (warn_slowpath_common+0x8c/0xb8)
[92514.385444]  r5:00000009 r4:00000000
[92514.389971] [<c0020950>] (warn_slowpath_common) from [<c0020aac>] (warn_slowpath_null+0x24/0x2c)
[92514.400987]  r8:c5c42040 r7:c66b1ae4 r6:c7334480 r5:c7334524 r4:00000001
[92514.409476] [<c0020a88>] (warn_slowpath_null) from [<bf21d5a8>] (brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac])
[92514.422591] [<bf21d4b8>] (brcmf_netdev_wait_pend8021x [brcmfmac]) from [<bf20d744>] (brcmf_cfg80211_leave_ibss+0xe0/0x2e0 [brcmfmac])
[92514.437638]  r7:c6440000 r6:c66b1c08 r5:c7334480 r4:c0408408
[92514.444795] [<bf20d6a4>] (brcmf_cfg80211_leave_ibss [brcmfmac]) from [<bf20d9b4>] (brcmf_cfg80211_del_key+0x70/0x90 [brcmfmac])
[92514.459185]  r6:c7334480 r5:00000000 r4:c0408408
[92514.465045] [<bf20d944>] (brcmf_cfg80211_del_key [brcmfmac]) from [<bf1113bc>] (nl80211_del_key+0xf4/0x148 [cfg80211])
[92514.478464]  r6:c7334000 r5:c70c7220 r4:bf20d944
[92514.484309] [<bf1112c8>] (nl80211_del_key [cfg80211]) from [<c026a0f4>] (genl_rcv_msg+0x260/0x2e0)
[92514.495553]  r7:c70c7214 r6:bf120678 r5:bf128ef4 r4:00000000
[92514.502717] [<c0269e94>] (genl_rcv_msg) from [<c0269428>] (netlink_rcv_skb+0x60/0xbc)
[92514.512531]  r10:00000000 r9:00000000 r8:c66b1d8c r7:c7952c00 r6:c0269e94 r5:c5c42040
[92514.522398]  r4:c70c7200
[92514.525584] [<c02693c8>] (netlink_rcv_skb) from [<c0269e80>] (genl_rcv+0x28/0x3c)
[92514.534963]  r7:c7952c00 r6:c5c42040 r5:c5c42040 r4:c041b3e8
[92514.542110] [<c0269e58>] (genl_rcv) from [<c0268e08>] (netlink_unicast+0x138/0x1f4)
[92514.551709]  r5:00000030 r4:c79e1400
[92514.556210] [<c0268cd0>] (netlink_unicast) from [<c02692b0>] (netlink_sendmsg+0x328/0x344)
[92514.566572]  r9:00000030 r8:c66b1f4c r7:c7952c00 r6:00000000 r5:00000000 r4:c5c42040
[92514.576345] [<c0268f88>] (netlink_sendmsg) from [<c022faa8>] (sock_sendmsg+0x1c/0x2c)
[92514.586165]  r10:00000000 r9:c0408408 r8:c7514200 r7:c66b1e64 r6:00000000 r5:00000000
[92514.596034]  r4:c66b1f4c
[92514.599236] [<c022fa8c>] (sock_sendmsg) from [<c022ff14>] (___sys_sendmsg+0x178/0x200)
[92514.609183] [<c022fd9c>] (___sys_sendmsg) from [<c0230cd4>] (__sys_sendmsg+0x44/0x68)
[92514.619003]  r10:00000000 r9:c66b0000 r8:c0009824 r7:00000128 r6:00000000 r5:be8f8010
[92514.628878]  r4:c7514200
[92514.632070] [<c0230c90>] (__sys_sendmsg) from [<c0230d08>] (SyS_sendmsg+0x10/0x14)
[92514.641555]  r6:b6f841d8 r5:00000000 r4:00000000
[92514.647378] [<c0230cf8>] (SyS_sendmsg) from [<c0009680>] (ret_fast_syscall+0x0/0x3c)
[92514.657088] ---[ end trace 10b1f7965c83243f ]---
[94508.810549] pppoe-wan: renamed from ppp0
[94510.645646] pppoe-wan: renamed from ppp0

Any information needed ?

adityaxavier wrote:

I just had a crash in the logs. Was not there to check the effect, but i there is some problem with the Wireless driver.

So I can see a WARNING and where is the crash? wink

This problem with brcmf_netdev_wait_pend8021x was happening quite frequently long time ago. It was reported by me in e-mail thread:
WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x
https://marc.info/?t=143646507500003&r=1&w=4
http://comments.gmane.org/gmane.linux.k … ral/139828

It was supposed to be fixed by the following patchset:
[PATCH 00/12] brcmfmac: multiple interface rework and cleanup
https://marc.info/?t=144062024700017&r=1&w=2
http://article.gmane.org/gmane.linux.ke … ral/141389

It appears that fix improved situation a lot but didn't fix all problems related to the brcmf_netdev_wait_pend8021x. You can try reporting this to Broadcom guys.

Got it.. smile Thats what i deserve for jumping the gun !

Thanks for looking into it.

Could you please provide the .config file you use to build the firmware ? Wanted to have a clean base to start on.

adityaxavier wrote:

Got it.. smile Thats what i deserve for jumping the gun !

Thanks for looking into it.

Could you please provide the .config file you use to build the firmware ? Wanted to have a clean base to start on.

I was using default bcm53xx config

> ./scripts/diffconfig.sh 
CONFIG_TARGET_bcm53xx=y
CONFIG_TARGET_bcm53xx_Generic=y
CONFIG_TARGET_BOARD="bcm53xx"
# CONFIG_FEED_luci is not set
# CONFIG_FEED_luxul is not set
# CONFIG_FEED_management is not set
# CONFIG_FEED_packages is not set
# CONFIG_FEED_routing is not set
# CONFIG_FEED_targets is not set
# CONFIG_FEED_telephony is not set

This WARNING may be quite rare, be aware it may take time to reproduce it.

Zajec wrote:
adityaxavier wrote:

Got it.. smile Thats what i deserve for jumping the gun !

Thanks for looking into it.

Could you please provide the .config file you use to build the firmware ? Wanted to have a clean base to start on.

I was using default bcm53xx config

> ./scripts/diffconfig.sh 
CONFIG_TARGET_bcm53xx=y
CONFIG_TARGET_bcm53xx_Generic=y
CONFIG_TARGET_BOARD="bcm53xx"
# CONFIG_FEED_luci is not set
# CONFIG_FEED_luxul is not set
# CONFIG_FEED_management is not set
# CONFIG_FEED_packages is not set
# CONFIG_FEED_routing is not set
# CONFIG_FEED_targets is not set
# CONFIG_FEED_telephony is not set

This WARNING may be quite rare, be aware it may take time to reproduce it.

We have a theory about this problem. In the past there was an issue with accessing the wrong ifp. This has been fixed, but this warning is different. I believe that the device really didn't manage to sent the frame within 50 msec. The most logical reason for this is that the 50 msec timeout is simply not enough. When the client is using powersave then it can take up to a couple of beacons before the AP will be able to transmit the frame. So the timeout should simply be increased to something like 350 msec.

Do you know if this was a new connection or an existing connection? If it is an existing connection which is doing a key refresh that would make it even more likely as that update is AP initiated if I'm not mistaken.

meuleman wrote:

We have a theory about this problem. In the past there was an issue with accessing the wrong ifp. This has been fixed, but this warning is different. I believe that the device really didn't manage to sent the frame within 50 msec. The most logical reason for this is that the 50 msec timeout is simply not enough. When the client is using powersave then it can take up to a couple of beacons before the AP will be able to transmit the frame. So the timeout should simply be increased to something like 350 msec.

Do you know if this was a new connection or an existing connection? If it is an existing connection which is doing a key refresh that would make it even more likely as that update is AP initiated if I'm not mistaken.

Sorry for the late reply. I don't have proper evidence on whether it happened due to a key refresh of an existing connection or it was a new connection. However it is as said quite rare too because am yet to see it happen again.

Regarding issues which i am seeing in the trunk build.

1. USB doesn't seem to work. ( Am assuming because of no power )
2. LEDs are not working. ( I know the patch is already there, but i don't know why they don't seem to work for me, planning to look into it )
3. ubi error's they only seem to come in Trunk releases, and absolutely no sign of them in CC release. ( Is it because they are not in verbose ? )
4. Any reason why OpenWrt doesn't use cpu scaling ?

Sorry, posts 351 to 350 are missing from our archive.