Is there a ticket up for this? Since the last stable build has been tracked down, I assume that some change has subsequently messed with TCP stability, and hence should be easier to debug?

Yes, here it is: https://dev.openwrt.org/ticket/14020

Not exactly. The problem was introduced with kernel upgrade from 3.8.* to 3.10.*. So, in one changeset in fact there was a huge bunch of changes, and it's not that easy to find which one was the cause.
Also it seems thats no one from the openwrt team is working on this problem.

Just an idea: what if the bug is located at arch/ppc? That's why it is not discovered on "mainstream" platforms yet.

Lastest trunk BB v37937 does sustain high network load without crashing.

test setup via ethernet:
server --> wan@tplink _ routing _ lan@tplink --> laptop

iperf tcp gives about 75 MByte/s over 1 hour without any issue.

Greetings Thomas

Upgrading from a trunk file gets me to r37922. Where did you find *937?

BARRIER BREAKER (Bleeding Edge, r37937)

url = git://nbd.name/openwrt.git
last git commit id: 92c70e62bf62dd51702bd63dcf28fb80cb5ccc2f

Bye Thomas

Someone else confirm that?

I've actually tried compiling and installing 37937+ image, and I can confirm that it has already crashed twice since the last three days. But that probably wasn't directly related to high network usage, i.e one crash happened at late night when network wasn't loaded at all. So, long story short, in my opinion it is still not that stable as it used to be on 3.8 kernel.
Currently I won't revert back to 3.8, a bit interesting to see how often it would crash.

It seems stable for me with latest version built from git. Perhaps I'm not able to put enough load on the router?

Firmware Version OpenWrt Barrier Breaker r37981 / LuCI Trunk (svn-r9902)
Kernel Version 3.10.10

Tested using iperf:
Computer (client) --> (lan) TL-WRD4900 --> (wan) TL-WRD4900 --> Netgear router --> Computer (server)

[ ID] Interval Transfer Bandwidth
[ 3] 0.0-3600.0 sec 232 GBytes 555 Mbits/sec

One hour test, transfer speed between 500-680Mbit/sec during test.

Did a second test, 1.5 hour. vnstat from TL-WRD4900:

eth0 / traffic statistics
rx | tx
bytes 371.10 GiB | 367.93 GiB
max 792.64 Mbit/s | 785.89 Mbit/s
average 576.70 Mbit/s | 571.76 Mbit/s
min 261.78 Mbit/s | 259.50 Mbit/s

packets 283421338 | 283420953
max 71968 p/s | 71969 p/s
average 52504 p/s | 52504 p/s
min 24276 p/s | 24276 p/s

time 89.97 minutes

Kind Regards

eximido: How strange...

Both: Thanks for feedback!

Update: router crashed during no load after about 2 days. Will keep monitoring, and see if it happens again.

Can you please check out one thing? Try sshfs over wan. Think scp will do as well. Transfer some big file.  My router crashes in 2 minutes. Stops responding, wifi get lost. Older version though,  but 100% reproducible. I wonder if new revision is any better.

Yeah, just the same happened with mine. It keeps flashing the LEDs as usual, but stops responding to pings and anything. Btw, at changeset r38000 kernel was upgraded to 3.10.12, but I won't be able to rebuild or reflash anything till the next week. Would anyone check if it will work more reliable?

PS: My WDR4900 at r37951 /w kernel 3.10.10 is working now for 5 days since the last crash. But keeping in mind that it might crash all of sudden at any time is very irritating/

It seems to be stable on my machine as described in the ticket in the bugtracking system. Hasn't crashed in two days and survived a 6h iperf test without any struggle.

--
from the bugtracker:

I used an image from the buildbot, which isn't available anymore. Therefore i've uploaded it to an online-hoster. Feel free to download it from here: https://www.hidrive.strato.com/lnk/y50rt6M8

Some more specs to ensure we are using the same hardware:

# cat /proc/cpuinfo 
processor       : 0
cpu             : e500v2
clock           : 799.999992MHz
revision        : 5.1 (pvr 8021 2151)
bogomips        : 99.99
timebase        : 49999999
platform        : Freescale P1014
model           : TP-Link TL-WDR4900 v1
Memory          : 128 MB

# cat /proc/iomem
00000000-07ffffff : System RAM
80000000-9fffffff : /pcie@ffe0a000
  80000000-9fffffff : PCI Bus 0001:03
    80000000-8001ffff : 0001:03:00.0
      80000000-8001ffff : ath9k
    80020000-8002ffff : 0001:03:00.0
a0000000-bfffffff : /pcie@ffe09000
  a0000000-bfffffff : PCI Bus 0000:01
    a0000000-a001ffff : 0000:01:00.0
      a0000000-a001ffff : ath9k
    a0020000-a002ffff : 0000:01:00.0
ffe04500-ffe04507 : serial
ffe22000-ffe22fff : /soc@ffe00000/usb@22000
  ffe22000-ffe22fff : ehci_hcd]

dmesg-output

Nice! Thanks for doing tests. Sadly I've currently no time to run some on my device.

Hi all. I am a noob in here so excuse me if the question is in wrong topic or it was already answered somewhere.

@Swarley do you think that this firmware will work on wdr4900 v1.3?

All 1.x boards currently have the same hardware, so it will.

Performed a new test now as dalius@... suggested in ticket #14020.

WDR4900 running trunk r37990. Uptime 5 days now. Crashed randomly once since updating to the version I'm running now.

On the router: iperf -s
On the computer connected to router: iperf -c 192.168.1.1 -30 -r

I have run the test multiple times, without crashing once. Tested with the computer running as server and router as client as well, without any problem.

Example, four tests in a row with WDR4900 running as ipref server:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.84 port 57400
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  2.09 GBytes   597 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.84, TCP port 5001
TCP window size: 20.5 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 42891 connected with 192.168.1.84 port 5001
[  4]  0.0-30.0 sec  1.01 GBytes   290 Mbits/sec
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.84 port 57408
[  4]  0.0-30.0 sec  1.96 GBytes   561 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.84, TCP port 5001
TCP window size: 20.5 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 42892 connected with 192.168.1.84 port 5001
[  4]  0.0-30.0 sec  1.01 GBytes   290 Mbits/sec
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.84 port 57422
[  4]  0.0-30.0 sec  2.11 GBytes   605 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.84, TCP port 5001
TCP window size: 20.5 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 42893 connected with 192.168.1.84 port 5001
[  4]  0.0-30.0 sec  1.01 GBytes   290 Mbits/sec
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.84 port 57439
[  4]  0.0-30.0 sec  2.02 GBytes   580 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.84, TCP port 5001
TCP window size: 20.5 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 42894 connected with 192.168.1.84 port 5001
[  4]  0.0-30.0 sec  1.01 GBytes   290 Mbits/sec

Computer is connected directly into the router with a Cat 6 UTP cabel. Not sure why I'm not getting higher speeds, look a bit slow compared to tests performed by Swarley. Perhaps because I'm running the ipref client on an old core2duo desktop computer?

Anyway.. some more router info:

/proc/cpuinfo
processor    : 0
cpu        : e500v2
clock        : 799.999992MHz
revision    : 5.1 (pvr 8021 2151)
bogomips    : 99.99
timebase    : 49999999
platform    : Freescale P1014
model        : TP-Link TL-WDR4900 v1
Memory        : 128 MB

/proc/iomem
00000000-07ffffff : System RAM
80000000-9fffffff : /pcie@ffe0a000
  80000000-9fffffff : PCI Bus 0001:03
    80000000-8001ffff : 0001:03:00.0
      80000000-8001ffff : ath9k
    80020000-8002ffff : 0001:03:00.0
a0000000-bfffffff : /pcie@ffe09000
  a0000000-bfffffff : PCI Bus 0000:01
    a0000000-a001ffff : 0000:01:00.0
      a0000000-a001ffff : ath9k
    a0020000-a002ffff : 0000:01:00.0
ffe04500-ffe04507 : serial
ffe22000-ffe22fff : /soc@ffe00000/usb@22000
  ffe22000-ffe22fff : ehci_hcd

(Last edited by guzzard on 21 Sep 2013, 09:12)

Hey, new around!

Just got the WDR4900. Used to own the WDR3600, added the new device to cover another side of my apartment and to connect 2 printers in that room.

I'm little confused about the right version to use. Currently running "BARRIER BREAKER (Bleeding Edge, r37472)", but unfortunately usb port are not working, a shame

Couldn't understand exactly if Swarley build is definitely stable or not. Should I install it in the new device? Should I wait for more testing? Is there anyway to run the USB ports with 3.8 kernel?

Thanks folks!

what exactly are not working on usb? what are you connecting? show last lines of kernel log after you plug something..

Actually I was wrong: the leds next the usb ports never turned on when connected something, so I assumed it was internally disabled.

root@router:~# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 03f0:2c17 Hewlett-Packard LaserJet 1022

It detects de printer fine. The issue comes to configure CUPS, no USB printer is detected. I guess some modules are missing
Tried to install "kmod-usb-printer", but as reported by 230, it doesn't work for kernel <3.10.

Thanks!

You have to upgrade your firmware  in order to catch up with already upgraded kernel modules in trunk repo. We are using bleeding edge software which  is intensively evolving. As soon as you upgrade, install all the necessary kmods first, that will give you some extra time before the next major upgrade. Apps are less sensitive to kernel version.

And look at lsmod before to check out if kmod-usb-printer is really missing.

Not exactly correct. The problem actually is that EVERY new build is by default assumed incompatible with the previous ones, regardless of were there any changes or not. And trunk is automatically rebuilt every couple days. So... when you're working with trunk snapshots and willing to be able to install something later on, then you should download a copy of all the packages from trunk snapshot you've flashed. And then install em from your local repo copy, not from openwrt trunk repo.

Probably you just need to configure those LEDs in /etc/config/system.

Well, after one more crash on kernel 3.10.10-based firmware, I've tried to upgrade it with the latest trunk's kernel 3.10.12, and yet it crashed again in less then a day. Without network load or anything. I'm really fed up with this, and now I've decided to rebuild latest trunk firmware, but with changesets 37474-37472 reverted. So it is basically the most up to date firmware with all the packages updated, but based on 3.8.13 kernel.
It compiled fine, and reflashed ok as well. The device is working now for about an hour, will keep watching.

(Last edited by eximido on 26 Sep 2013, 19:31)

Sounds nice! Mind sharing?