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 wrote:

adri,

which leaves a single non overlapping channel for 80MHz and doesn't allow 160MHz at all. Sort of obvious that it needs fixing me thinks.

Sera,

Unfortunately, Yurhaulin seems to think otherwise and does't consider it important, dropping DFS support for 88W8864 and older chips.

@sera,

Before raising my question I'd like to thank you again for your great patches smile
I built my Linux 4.9 based image in January from openwrt trunk with your 2017-01-07 patches, and my Caimen has been running very stable since then. No wifi problem, no reboots. 60 days uptime before I had a power loss at home.

However I attached a 250GB SSD (mx200, if that matters) to the USB3.0 port last night and immediately observed several random reboots when Aria2 downloading torrents to the SSD. I know this could be any party's fault, be it the hard drive enclosure, Caimen HW or the Linux kernel / driver. Are you by any chance aware of any similar issues? The only related reboot report I can find is @doITright mentioning torrents caused reboots right in this thread, and he seemed to have the same issue with 4.11 and your latest patch set.

Thanks a again for you time smile

@rlei Did you check the RAM usage during the transfer(s)?  Running out of RAM due to a transfer would cause the firmware to crash and reboot.  Whenever attaching a HDD, it should have at least a 2GB swap partition.

JW0914 wrote:

@rlei Did you check the RAM usage during the transfer(s)?  Running out of RAM due to a transfer would cause the firmware to crash and reboot.  Whenever attaching a HDD, it should have at least a 2GB swap partition.

Thanks for the heads up. This indeed never occur to me. I checked in "top" and 400MB RAM immediately got allocated for cache after aria2c started downloading, leaving only a few MBs RAM free. Will mount a swap and see.

(Last edited by rlei on 24 May 2017, 15:13)

JW0914 wrote:

@rlei Did you check the RAM usage during the transfer(s)?  Running out of RAM due to a transfer would cause the firmware to crash and reboot.  Whenever attaching a HDD, it should have at least a 2GB swap partition.

OK I did 2 things:

  • Repartitioned/formatted my SSD to ext4 (plus one swap partition); was using exfat in order to share with my Mac

  • Set up an ~1GB swap partition

aria2 seemed to be running fine for a bit longer, but still the router rebooted in less than an hour.

I periodically checked RAM usage and "free" shows that the swap isn't being used at all:

             total       used       free     shared    buffers     cached
Mem:        514100     508468       5632     257048       4620     432736
-/+ buffers/cache:      71112     442988
Swap:       987992          0     987992

(Last edited by rlei on 24 May 2017, 17:35)

rlei,

The reboot issue is exclusive to Mamba. All others are almost the same hardware. Mamba is based on a different and older SoC.

There might be an issue with extfat but more likely as JW0914 stated it's an issue with running out of memory. Usually this isn't an issue as the oom-killer will kick in at some point. Swap will only help to make that happen later. The issue is likely an atomic memory allocation which must succeed immediately and so doesn't allow for swap or oom-killer to free up any memory at all which then would result in a crash.

The default for free memory to keep around for such is a little on the low side in OpenWrt so I suggest to set
"sysctl -w vm.min_free_kbytes=16384" to avoid such issues. Also add it to /etc/sysctl.d/local.conf to preserve the setting over reboots.

sera wrote:

rlei,

The default for free memory to keep around for such is a little on the low side in OpenWrt so I suggest to set
"sysctl -w vm.min_free_kbytes=16384" to avoid such issues. Also add it to /etc/sysctl.d/local.conf to preserve the setting over reboots.

Thank you so much sera. Increasing vm.min_free_kbytes works like a charm, even without swapon. My free RAM is now constantly above 20M and I never had a reboot again (so far smile )

BTW I just realized that by default the aria2 daemon's log level is "debug". It would fill up the whole tmpfs (250MB of RAM) in just seconds. However, fixing the log level alone won't stop OS cache from consuming most available RAM eventually. So the vm.min_free_kbytes setting is still needed.

(Last edited by rlei on 25 May 2017, 15:52)

@rlei Is there a setting option for the log location in the Aria config file(s)?  If so, you could set it to the SSD or a USB drive plugged into the eSATA port.

JW0914 wrote:

@rlei Is there a setting option for the log location in the Aria config file(s)?  If so, you could set it to the SSD or a USB drive plugged into the eSATA port.

Yes there is one. For now I just let it write to /tmp as the "notice" level produces only a few lines a day.

How do you send a PM on this forum?

tapper wrote:

How do you send a PM on this forum?

You can't... only admins appear to be able to utilize the "Send Forum Email" link on a user's profile.

It would be interesting to see if one created a thread about funding a forum upgrade to XenForo, which would cost $310/yr, $390/2yr, would members contribute, and if so, once the price was met, for software and potential hardware upgrades, would the forum admins seriously consider it.

  • A forum upgrade would prevent threads like this one from ballooning to tens of thousands of posts.

  • It would prevent users from having to re-post the same questions every few hundred posts, as the forum search functionality lacks thread search.

  • It would prevent off-topic conversations, that while encompass a thread's subject, don't have a lot to do with the premise of the thread (for example, my question to @sera a few weeks back regarding kernels)

(Last edited by JW0914 on 27 May 2017, 13:02)

JW0914 wrote:

It would be interesting to see if one created a thread about funding a forum upgrade to XenForo, which would cost $310/yr, $390/2yr, would members contribute, and if so, once the price was met, for software and potential hardware upgrades, would the forum admins seriously consider it.

after the openwrt/lede remerge, there will be two active forums, and a desire for there to be only one, so it's very possible to change forums

  • A forum upgrade would prevent threads like this one from ballooning to tens of thousands of posts.

  • It would prevent users from having to re-post the same questions every few hundred posts, as the forum search functionality lacks thread search.

  • It would prevent off-topic conversations, that while encompass a thread's subject, don't have a lot to do with the premise of the thread (for example, my question to @sera a few weeks back regarding kernels)

I have serious doubts if changes to the forum software would do what you are saying.

The only way to prevent super-long threads is to cut them off, which results in lots of shorter threads instead (even harder to search)

people don't use the search functionality in forums, they just re-post

no software can prevent off-topic conversations (until AIs wake up and rule the world anyway), the software can't tell what's on topic and what's not. (and arguably, your post is of topic :-)

dlang wrote:
JW0914 wrote:

It would be interesting to see if one created a thread about funding a forum upgrade to XenForo, which would cost $310/yr, $390/2yr, would members contribute, and if so, once the price was met, for software and potential hardware upgrades, would the forum admins seriously consider it.

after the openwrt/lede remerge, there will be two active forums, and a desire for there to be only one, so it's very possible to change forums

  • A forum upgrade would prevent threads like this one from ballooning to tens of thousands of posts.

  • It would prevent users from having to re-post the same questions every few hundred posts, as the forum search functionality lacks thread search.

  • It would prevent off-topic conversations, that while encompass a thread's subject, don't have a lot to do with the premise of the thread (for example, my question to @sera a few weeks back regarding kernels)

I have serious doubts if changes to the forum software would do what you are saying.

The only way to prevent super-long threads is to cut them off, which results in lots of shorter threads instead (even harder to search)

people don't use the search functionality in forums, they just re-post

no software can prevent off-topic conversations (until AIs wake up and rule the world anyway), the software can't tell what's on topic and what's not. (and arguably, your post is of topic :-)

One has to first consider the reason why this thread in particular is so long, and it comes down to two main reasons:

  • Lack of thread search, which creates two problems:

    1. Prevention of a user to find information relevant to what they need

    2. Re-posting of the same question(s) every 100 - 200 posts, due to an inability to search the thread

  • Slightly off topic conversations due to an inability to privately message the participants

Granted, there's always going to be those users that can't comprehend to utilize thread search and read the last 10 posts prior to posting (a frequent irritating problem on the XDA forums), however, there's no way this thread would have grown to over 5K posts, let alone close to 14,500, if thread search and PM were available.

  • This is always more of an issue with less technical users, and members who refuse to make it known, in a polite manner, not reading or utilizing thread search before posting is not acceptable forum behavior, as this problem does not occur on forums like FreeNAS, FreeBSD, MSFN, or Sophos, all of which are regarding products that require one to actually read documentation to utilize them effectively.

(Last edited by JW0914 on 27 May 2017, 15:20)

JW0914 wrote:

One has to first consider the reason why this thread in particular is so long, and it comes down to two main reasons:

  • Lack of thread search, which creates two problems:

    1. Prevention of a user to find information relevant to what they need

    2. Re-posting of the same question(s) every 100 - 200 posts, due to an inability to search the thread

  • Slightly off topic conversations due to an inability to privately message the participants

Granted, there's always going to be those users that can't comprehend to utilize thread search and read the last 10 posts prior to posting (a frequent irritating problem on the XDA forums), however, there's no way this thread would have grown to over 5K posts, let alone close to 14,500, if thread search and PM were available.

  • This is always more of an issue with less technical users and members who refuse to make it known, in a polite manner, not reading or utilizing thread search before posting is not acceptable forum behavior, as this problem does not occur on forums like FreeNAS, FreeBSD, MSFN, or Sophos.

I think this topic would easily have gotten almost this long, You have a much higher opinion of the benefits of search than I do, especially on a topic like this where the answer changes as time goes on. but if anything, it's a reflection on the community, not the software.

This thread is so long because linksys did such a horrible job with this family of products, leveraging the OpenWRT name while not providing drivers to make the systems actually function. Any topic that is a reverse engineering project that has people thinking they can 'just use it' is going to be a big mess.

I don't think private messages would have helped much, yes there are things that people may have done in private messages, but some of that is really better off in the open (and given the push for doing everything in the open, that's not likely to change post-remerge)

@dlang I understand where you're coming from, however we'll have to agree to disagree.



@All I wanted to verify that the Vcc pin (#6) is not used for TTL communication on any of the boards, as my understanding was it's not utilized, regardless of conversion hardware [USB, RSxxx, etc.).  I could have sworn we had a conversation about this over a year ago, and from schematics I can find online, the only two connections that pass through an IC from TTL -> RSxxx are Rx and Tx (pins 4 & 2) which are passed through to RSxxx pins 2 & 3.  Ground nor the Vcc rail are passed through.

(Last edited by JW0914 on 27 May 2017, 16:17)

@all  The WRT AC Series Wiki has needed an update, since my last major update to it was over a year ago, and I haven't been able to find time to spend the few days it would require to get things added that need to be added.

I encourage any user that wishes to contribute to please do so, as the time consuming portion isn't adding the content, it's the formatting of the content, testing the layouts after any edits by using Preview, making additional changes and repeating until the final product is ready to be saved and posted.

  • Any user wishing to contribute, please follow the formatting already in place, of which will require ~1hr reading through the DokuWiki site, especially the Wrap Plugin, as it's one of the most important and widely used plugins I used in the re-write of the WRT AC Series wiki.

    • Standardization matters, otherwise we end up with the discombobulation found in other wikis where the authors didn't bother with DokuWiki formatting.

  • Please ensure the ToC [Table of Contents] is maintained through the usage of the appropriate Headings

My master list of changes needing to be done are in this post, of which I'll need to update with information from posts I've flagged over the past year should someone wish to contribute to the wiki.

  • Please post any changes made to the wiki in this thread in order to garnish feedback from the community to determine if anything needs to be tweaked, added, or removed.

To edit, or create, wikis, one needs to create a wiki user account, of which the same username used on the forum can be utilized.  There is a bug that causes a null page to be loaded after a wiki login... simply go back a page and you'll be logged in.

(Last edited by JW0914 on 30 May 2017, 06:37)

On the topic of forums. The LEDE forum soft wair is crap to use with a screen reader. If we all have to moov over to the LEDE forum then I will not be able to post any more. Because of the way it puts all posts on one page and makes you scrool down the page it would take me about 3 months of holding down my down arrow key, to get to the end of this thread just to make a reply lol. On this forum I can just press enter on the number of the last page. + each post is marcked with a hedding  tag so I can use the H key to jump from post to post.

tapper wrote:

On the topic of forums. The LEDE forum soft wair is crap to use with a screen reader. If we all have to moov over to the LEDE forum then I will not be able to post any more. Because of the way it puts all posts on one page and makes you scrool down the page it would take me about 3 months of holding down my down arrow key, to get to the end of this thread just to make a reply lol. On this forum I can just press enter on the number of the last page. + each post is marcked with a hedding  tag so I can use the H key to jump from post to post.

nobody is saying that people will be forced to the LEDE forum. nobody is saying that people will be forced to the openwrt forum. Both will be run for some time until some decision can be made, which could be 'neither of them'

for what it's worth, I like the LEDE forum because I can treat it as a mailing list, subscribe to it and then read/respond via e-mail. I would not want to have to use it via a browser, but I say that about all forum software (including the OpenWRT forum software, I just have no choice if I want to follow the information, which means I only follow a few things because it's so painful)

dlang wrote:
tapper wrote:

On the topic of forums. The LEDE forum soft wair is crap to use with a screen reader. If we all have to moov over to the LEDE forum then I will not be able to post any more. Because of the way it puts all posts on one page and makes you scrool down the page it would take me about 3 months of holding down my down arrow key, to get to the end of this thread just to make a reply lol. On this forum I can just press enter on the number of the last page. + each post is marcked with a hedding  tag so I can use the H key to jump from post to post.

nobody is saying that people will be forced to the LEDE forum. nobody is saying that people will be forced to the openwrt forum. Both will be run for some time until some decision can be made, which could be 'neither of them'

for what it's worth, I like the LEDE forum because I can treat it as a mailing list, subscribe to it and then read/respond via e-mail. I would not want to have to use it via a browser, but I say that about all forum software (including the OpenWRT forum software, I just have no choice if I want to follow the information, which means I only follow a few things because it's so painful)

Yeah sorry I didn't mien to imply that people will be forced to the LEDE forum. I need to think about how I word things some times. :$ lol

Maybe someone can help me a bit.

My WRT1900ACS seems bricked. Some questions.

1. Does OpenWRT image for WRT1900ACx supports failsafe mode? I tried to follow the instruction. It doesn't seem having failsafe mode and while listen to the broadcast message, there is no message at all.

2. I tried serial port but almost always that the power led and SATA led are lit and nothing happen. Only once, it seems I got serial output to console but the freeze.

Does anyone know what does that mean for both SATA and Power LED lit when connecting to ust to ttl adapter and connect to serial console.

Thanks.

LogicoZone wrote:

1. Does OpenWRT image for WRT1900ACx supports failsafe mode? I tried to follow the instruction. It doesn't seem having failsafe mode and while listen to the broadcast message, there is no message at all.

Should work but have never tried myself. Not needed to debrick at all.

LogicoZone wrote:

2. I tried serial port but almost always that the power led and SATA led are lit and nothing happen. Only once, it seems I got serial output to console but the freeze.

I don't understand what exactly you are doing. Did you ever connect the usb2tll cable before and had proper console output? Ie. you actually know how to do it and confirmed it was working?

@LogicoZone It's physically impossible to "brick" any of the WRT AC Series routers, as they can be reflashed directly via serial [port] using a USB-TTL cable/Arduino/RS232-TTL converter, and even if one fully corrupts the bootloader, that can also be rebuilt thanks to nitroshift's work with Stefan Roese of U-boot.

(Last edited by JW0914 on 30 May 2017, 05:13)

swrt-2017-05-29
---------------

4.10 became EOL as anticipated, change default kernel to 4.11. Also drop unused
kmod-ledtrig-usbdev and kmod-gpio-button-hotplug from default packages for
mvebu. Degarde 4.10 support to a minimum as done with other old kernels.

About the Rango series, an upstream developer commented on the CPU frequency
patch to also check the ddr and l2 clocks for sane values. Indeed those need
adjusting as well. Update the clocking patch accordingly. Then all but the
clocking patch got applied already and will be in 4.13. The clocking patch will
need to enter through a different tree.

Then backport the Rango series to 4.11, so both 4.11 and 4.12 in swrt use the
new dts for all models. This bloats 4.11 a bit but well.

There was also a bump of firmware and a bugfix for mwlwifi. One issue less for
Rango users.

Todays next needs two new patches, one for a missing config dependency the
other is a revert of a stricter type check which breaks building mwlwifi.


* linux-4.4: bump to 4.4.70
* linux-4.9: bump to 4.9.30
* linux-4.11: bump to 4.11.3, make default
* linux-4.12: bump to 4.12-rc3
* linux-next: bump to next-20170515

* mwlwifi-firmware: bump (Rango)
* kmod-mwlwifi-nocompat: bump

* linux 4.10: degrade to minimal support / vanillify as far as possible
* linux 4.11: backport Rango series
* linux 4.12: update clocking patch
* linux next: drop 15 patches already upstream, revert stricter typecheck,
  patch missing config dep.

swrt-2017-05-29.tar.xz: https://gpldr.in/v/6Wp7an5kWu/VU9D313KWc4iN6uh
sha256sum: fab3853cd3db5a67faef7fdd8208b78601b065dafd783b02fde3d538600e013c