OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@sera, output:

initramfs: Press any button to enter failsafe
timeout return value 1
initramfs: .. entering failsafe

but, device /dev/input does not exist.

Edit: energetic entropy exchanges engage everyone endlessly

(Last edited by Villeneuve on 27 Apr 2017, 19:13)

Villeneuve,

No /dev/input explains what you see, though why it's missing I have to investigate. The kernel is obviously the same binary for all devices, so this is quite unexpected.

Edit: energetic entropy exchanges engage everyone endlessly

Haha, you made my day!


Edit: Does /sys/class/input/input0 exist and point to /sys/devices/platform/gpio_keys/input/input0? Any mention in dmesg wrt "input" or "gpio_keys"?

(Last edited by sera on 27 Apr 2017, 20:01)

/sys/class/input yes, but it is empty.

root@bsaedgy:/# find . -name input*
./proc/bus/input
./sys/class/input
root@bsaedgy:/# dmesg | grep gpio
[    0.034165] mvebu-gpio: probe of f1018140.gpio failed with error -17

Edit: going to drop:

0util@util0:~/br/openwrt/target/linux/mvebu/patches-4.11$ ls |grep -i pwm
0011-gpio-mvebu-Add-limited-PWM-support.patch
0012-ARM-dts-mvebu-Add-PWM-properties-to-.dtsi-files.patch
0013-ARM-mvebu-Enable-SENSORS_PWM_FAN-in-defconfig.patch
0014-ARM-dts-armada-xp-Use-pwm-fan-rather-than-gpio-fan.patch

(Last edited by Villeneuve on 27 Apr 2017, 20:33)

EEXIST, hm, well at least that should give me the direction to look for, some gpio seems to be used for more than one thing.

Could you test 4.11 without the pwm-fan patches (easy to drop them there), just in case.


Edit: possible fix https://paste.pound-python.org/show/sYW … u6tfNZnpa/

(Last edited by sera on 27 Apr 2017, 20:39)

Nothing like a long lived ISP outage to make one appreciate how we have come to rely upon connectivity as a mandatory service; I was starting to get the shakes.

Neither dropping the patches, nor the DTS patch, gave the desired results.

@doITright, since testing the squashfs is in failsafe mode, wonder if you would experience the same with the UBI image; I would guess yes as this smacks of an mwlwifi issue, but no big deal to give it a try.

Villeneuve wrote:

@Villeneuve and @sera

I just got the last build ... r4042-e5bbead, but i'm with a little problem

http://i.imgur.com/wLckDXm.png

My ISP request PPPoE to connect - with VLAN 10 , even if i'm able to proper find the correct setup on luci screen to make it work, PPPoE is not on this firmware. So i cannot dial.

On Luci screen it request PPP-MOD-PPPOE, to install - and no chance as the screen shows. it does not install, says its not possible bla bla bla ...

I've tested other LEDE customized ( https://davidc502sis.dynamic-dns.net/ ) this one works fine.
http://i.imgur.com/V6cB5rA.png

Also does all Oficial OpenWRT / LEDE.

Isn't it possible to fix this for next releases. Thx guys

(Last edited by ygor.almeida on 28 Apr 2017, 04:32)

Also ... as i said before, my ISP ( Brazil - VIVO ... FTTH ) request PPPoE over VLAN 10 to connect to internet.

I got some help from @JohnFlower at post:

https://forum.openwrt.org/viewtopic.php?pid=357118#p357118

But it didn't worked, with the instructions like this, i loose my connection and dhcp goes down. So i fixed

My Unit is WRT1900AC v1

After playing around with the settings, now it's working proper.

If anyone needs this ( Using Brazil VIVO or GVT - FFTH connection ) that needs PPPoE and VLAN 10 for internet, here it goes the config that worked for me:

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth0'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.10.1'
    option dns '8.8.8.8 8.8.4.4'

config interface 'wan'
    option _orig_ifname 'eth1'
    option _orig_bridge 'false'
    option proto 'pppoe'
    option username 'cliente@cliente'
    option password 'cliente'
    option ifname 'eth0.10'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5'
    option vid '1'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '10'
    option ports '4t 5t 6t'

The user and password for VIVO/GVT in Brazil is default and free so no problem to share.
Just need to replace in /etc/config/network - This works fine for WRT1900AC v1

As you can see with trunk on port 4t 5t 6t - i got both CPU and  WAN port to proper work.

Take a look on screen if anyone wants to do it over LuCI screen:

http://i.imgur.com/ZqrTQ9i.jpg

Even IPv6 ( dhcpv6-pd ) is working proper with this setup

(Last edited by ygor.almeida on 28 Apr 2017, 04:57)

@sera
Thanks for noticing the entropy issue with the new mwlwifi driver. Too bad that the entropy discussion at the mwlwifi repo got sidetracked badly. Hopefully yuhhaurlin keeps the feature in his roadmap of optional features. (Note that due to github formatting, most of your last response is hidden in Github GUI, everything after the first --- )

For others,
please be aware that the new mwlwifi driver decreases the amount of interrupts causing less entropy to be generated for the kernel entropy pool. That may cause scarcity of /dev/random output which may hurt you in case you have lots of entropy-consuming activities like SSL, VPN etc. connections. Not sure about the other devices in the series, but at least in WRT3200ACM the entropy pool is now really empty.

Running haveged package is a good option to keep the kernel entropy pool filled in case there is no natural entropy source.

(Last edited by hnyman on 28 Apr 2017, 08:35)

@ygor.almeida, since your ISP sounds similar to mine, here's my config:

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 'fdca:d797:1164::/48'

config interface 'lan'
    option ifname 'eth0'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'

config interface 'wan'
    option ifname 'eth1'
    option proto 'pppoe'
    option username 'user@snap.co.nz'
    option password 'password'
    option ipv6 '1'

config interface 'wan6'
    option ifname '@wan'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '10'
    option ports '4t 6'

Note how you're setting WAN ifname to eth0.10.
See the wiki wrt switch layout. You only need to tag the WAN port in this case.

hnyman,

@sera
Thanks for noticing the entropy issue with the new mwlwifi driver. Too bad that the entropy discussion at the mwlwifi repo got sidetracked badly. Hopefully yuhhaurlin keeps the feature in his roadmap of optional features. (Note that due to github formatting, most of your last response is hidden in Github GUI, everything after the first --- )

Yeah, too bad. Though I'm fairly sure yuhhaurlin will keep the feature in mind. Dang about the ---, but well, everything after your post is pretty much garbage anyway. Thanks for taking the time to provide such a detailed description of the issue. Makes it hard to say no.

Some people simply don't get hints. The most popular message in issue118 is the one telling everyone to shut up. Even better the one to train people to abuse the tracker then cynically says thanks for closing the entropy bug.

About other devices in the series, my Shelby is perfectly fine with _my_ usage pattern. No need for extra entropy sources. The new driver still generates plenty of interrupts even if idle. On Rango interrupts are correlated to activity. Installing haveged wont hurt anyway, so for those not monitoring such properties and are unsure, just go ahead and install it.

Villeneuve,

Neither dropping the patches, nor the DTS patch, gave the desired results.

Ok, there are hardly any other possible sources for the kernel message you posted than the pinctrl driver. Will dig into it a bit more. Thanks for the tests so far.


Edit: ha, looking at a dump of the Mamba dtb there is no phandle for the sdio-pins node, so the patch ended up as a noop and the conflict between sdio and gpio-keys is just imaginary. However, there is a real conflict between ethernet and spi1.

Possible fix: https://paste.pound-python.org/show/Tey … bPce2WpuN/

(Last edited by sera on 28 Apr 2017, 11:34)

sera wrote:

hnyman,

@sera
(Note that due to github formatting, most of your last response is hidden in Github GUI, everything after the first --- )

Dang about the ---, but well, everything after your post is pretty much garbage anyway. Thanks for taking the time to provide such a detailed description of the issue. Makes it hard to say no.

Note that you can edit your message in github. Removing both --- instances would bring your good summary into daylight. (I only noticed your summary as I got it by email from the thread, and then wondered why it is not visible in the thread.)

Yeah, I thought to write a verbose explanation for yuhhaurlin, as he might come from another context and not be aware of the issue. I know the issue well and have written both rng-tools and haveged package Makefiles in the repo ;-)

I think that as the ath9k solution is not too complex, it might be possible to adapt that to mwlwifi rather easily, but one should first get familiar with the mwlwifi driver internals so that the correct registers would be found. And I have no motivation to start digging quite so deep...

(Last edited by hnyman on 28 Apr 2017, 11:50)

hnyman,

Not that hard to implement but a mathematician should have a look at it nonetheless. My motivation to work on mwlwifi is low as well. Maybe one day ...

Edit: fixed the separator.

(Last edited by sera on 28 Apr 2017, 12:15)

@sera, no joy with the latest DTS patch.

@ygor.almeida, The build to which you refer is the build that I flash, I simply drag&drop to google drive for others to use if so desired. As I have no use for ppp in my environs it will not find its way into the prebuilt image. Other packages are built and available, but you have to install those. If other prebuilt images have what you need OOTB I would suggest one of those; a build is a build... See:

* use stable
* or cybrnook
* or autobuilt
* or current mwlwifi on stable
* or the one that you referenced

I don't use any of those and cannot speak to what is contained.

But first and foremost, I would recommend to anyone that they build their own image suited to their requirements. At any rate, this is not the thread to discuss the image I post, and would ask if you have any further queries to post here, thanks.

I give a big thumbs up to the "autobuilt", Kernel 4.9, nightly builds that pull in the new driver commits as soon as there are any

(Last edited by mojolacerator on 29 Apr 2017, 16:15)

S Pimenta wrote:
davidc502 wrote:

For those testing 3200acm with the new driver...

After restoring configurations from the 1900acm, I couldn't connect any devices to Wifi though the SSID Broadcast was there... However, I could connect to the default "LEDE" on Radio #2.. noticed there was a difference.

config wifi-device 'radio0'
    option  path    'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'

VS.

config wifi-device 'radio2'
    option  path    'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'

I noticed the path "platform" on Radio 2 which was working... So, I edited the wireless config for Radio 0 and 1, inserted platform, and all clients can now connect

If memory serves me correctly we had gotten away from that path because of kernel requirements?

On my WRT3200ACM (Rango) I have no issues connecting, but I try changing the /etc/config/wireless file adding platform/, issues connecting WIFI immediately occur, so don't do in the WRT3200ACM, if it works don't change it.

@davidc502 I'm testing on my Linksys WRT3200ACM-EU (Rango) your last build (from 2017-04-22) using 4.9 kernel, and so far is very stable (tested other builds and not so stable as yours), running some iperf3 tests, and I will report back after tests are finished.

It was removed to allow for greater kernel compatibility across different devices capable of running OpenWrt, however if that issue occurs, or drop down menus are empty on the wireless config page, then it should be added back prior to performing other troubleshooting steps.  See WiFi Troubleshooting in the Wiki.


@davidc502 Could you please post the PCIe paths for all radios on the 1900acm?

  • I think you might have meant the ACS, as I don't think a 1900acm exists


@S Pimenta Could you please post the PCIe paths for all radios on the 3200acm?

@all Is the new WRT 32X [3200 gaming edition] supported on OpenWrt, or is it the same hardware as the 3200acm, just with custom Linksys firmware and a black casing/blue LEDs?

(Last edited by JW0914 on 2 May 2017, 07:13)

JW0914 wrote:
S Pimenta wrote:
davidc502 wrote:

For those testing 3200acm with the new driver...

After restoring configurations from the 1900acm, I couldn't connect any devices to Wifi though the SSID Broadcast was there... However, I could connect to the default "LEDE" on Radio #2.. noticed there was a difference.

config wifi-device 'radio0'
    option  path    'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'

VS.

config wifi-device 'radio2'
    option  path    'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'

I noticed the path "platform" on Radio 2 which was working... So, I edited the wireless config for Radio 0 and 1, inserted platform, and all clients can now connect

If memory serves me correctly we had gotten away from that path because of kernel requirements?

On my WRT3200ACM (Rango) I have no issues connecting, but I try changing the /etc/config/wireless file adding platform/, issues connecting WIFI immediately occur, so don't do in the WRT3200ACM, if it works don't change it.

@davidc502 I'm testing on my Linksys WRT3200ACM-EU (Rango) your last build (from 2017-04-22) using 4.9 kernel, and so far is very stable (tested other builds and not so stable as yours), running some iperf3 tests, and I will report back after tests are finished.

It was removed to allow for greater kernel compatibility across different devices capable of running OpenWrt, however if that issue occurs, or drop down menus are empty on the wireless config page, then it should be added back prior to performing other troubleshooting steps.  See WiFi Troubleshooting in the Wiki.


@davidc502 Could you please post the PCIe paths for all radios on the 1900acm?

  • I think you might have meant the ACS, as I don't think a 1900acm exists


@S Pimenta Could you please post the PCIe paths for all radios on the 3200acm?

@all Is the new WRT 32X [3200 gaming edition] supported on OpenWrt, or is it the same hardware as the 3200acm, just with custom Linksys firmware and a black casing/blue LEDs?

Correct -- I meant 3200acm.

After the last flash, 'platform' was removed from radio0 and radio1. I then deleted the SSID configurations and re-created them, and both radio's came up. Radio2 is disabled, and I left 'platform' in the path.

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.           

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.         

Currently disabled ---
config wifi-device 'radio2'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0                                                                                  /mmc0:0001/mmc0:0001:1'

Is

'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'

a valid paramater?

Villeneuve,

Sorry for the delay, was fighting a cold over the weekend.

so with all variants so far you still see the EEXIST error, that's what I tried to address. Not sure yet it's related to the gpio-keys issue.

Still suspecting a pinctrl issue. Could you please paste the output of

cat /sys/kernel/debug/pinctrl/pinctrl-handles
cat /sys/kernel/debug/pinctrl/<internel-reg>.pinctrl/pinconf-groups

for a start.

I guess I'll have to instrument the gpio-keys driver to figure this one out. Also did the failsafe message appear with a specific linux version? doITright, would you happen to remember?

Did you get a chance to bisect the usb port not having power issue with next?

JW0914,

the WRT 32X is the same as the WRT3200ACM except for the colour for what we know.

There's going to be alot of peeved off gamers if they don't get the wireless drivers figured out.
Or they just won't sell any of them.

(Last edited by mojolacerator on 2 May 2017, 20:00)

JW0914 wrote:

Is

'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'

a valid paramater?

The radio does come up, so I assume?

swrt-2017-05-02
---------------

Linux 4.11 final got released. 4.10 remains default for now and will be
maintained for a bit.

The latest 4.9+ stable releases now have the ubifs fixes so no longer disable
O_TMPFILE support.

The gpio-keys keyboard for Mamba doesn't get setup, don't check for keypress in
initramfs. Needs to be debugged first.

Also bump mwlwifi and mark broken with next due to changes in mac80211. Leaks
memory, so barely usable anyway wink There are other issues with next wrt rcu /
cpu stalls.

* linux-4.10: bump to 4.10.13
* linux-4.11: bump to 4.11
* linux-next: bump to next-20170502

* initramfs: check for the existence of gpio-keys keyboard
* mwlwifi: bump to latest commit
* mwlwifi: mark broken with next

* kernel: 4.10: reenable O_TMPFILE support, fixed upstream.
* kernel: next: drop mvneta patches, fixed upstream.

swrt-2017-05-02.tar.xz: https://gpldr.in/v/3SFH7kpgvO/h6whdhPUEx4h1Sta
sha256sum: 0e9067192bf8ef2c680ef8ddbfe4422128c56af1b7551e13d71fd0ecd44a9f1d

@sera, here is the output. I only noticed it when moving to the squashfs image in an attempt to eliminate any differences between what I was testing, and what @doITright was running.

Have not looked any further at the usb port power issue. I will take another look with your latest patch-set, currently running into an issue in trying to compile; libnl-tiny(wpad).

Edit: Let's not forget those blue LEDs. The only point of interest I noticed in the sales propaganda was some proprietary flavour of bufferbloat. Call me a cynic, but I wonder what the origin of that might be?

(Last edited by Villeneuve on 2 May 2017, 22:02)

Villeneuve,

Thanks for the pinctrl debug info. Looks awfully amiss.

I obviously build wpad myself but haven't seen an issue so far. If you need help, please post the error.

Doesn't sound like the bufferbloat stuff to me, more like the layer7 iptables extension gargoyle is using with some Windows extra.

Sorry, posts 14426 to 14425 are missing from our archive.