A+ bufferbloat scores with or without the net-next patch.

@sera
but i have esata device, but what bugging me is there is no sata dev under devices...
how would configuration looks for esata?

@gsustek

root@wrt1900acs:/sys/class/leds# cat shelby:white:sata/trigger
[none] nand-disk timer default-on netdev usbdev phy0rx phy0tx phy0assoc phy0radio phy1rx phy1tx phy1assoc phy1radio

Doesn't look like I have a suitable trigger for sata available. Have to look into it and worst case write one.

Can I assume the sata disk works, just the led is always off.

May take a while as reading up on what is currently going on takes quite a chunk out off the time I'm willing to spend on openwrt.

yes, sata disk works, bet there isn't light:-)

@Davidc502

Any news about compiling the kernel dependent packets to your latest build?

I´m specially interested in any of the QoS packages. I tried installing MrFreeze:s compiled LuCi QoS-script with force-depends and ended up with a complete reinstall. -So trying to be more careful this time.

When having performance problems using 15.05 earlier and then installing the QoS-script, it really did an amazing job. All lagg was gone and the kids were happy - also start of streaming got a lot faster and worked great overall.

When I´m at it, wishing things - Strongswan for latest build would also be great! :-)

Cheers! :-)

Has anyone cross-compiled netdata for OpenWRT?

(Last edited by JW0914 on 6 May 2016, 15:58)

@gsustek and other who want to test

There is no sata trigger in Linus kernel. The triggers usbdev and netdev are openwrt additions so the same can be done for sata.

Reuse what you can. https://github.com/ebbes/linux-kirkwood … gger.patch basically implements the ide-bus activity led behaviour we know from long ago. Guess this is the desired behaviour.

Had to fix the patch so it would apply again and added some openwrt integration. The resulting patch can be found here: https://gist.github.com/anonymous/57f0a … cbbb595727

howto:
- apply patch
- run "make defconfig"
- enable the sata ledtrigger in menuconfig
- build and flash image
- add sata led config to /etc/config/system
- report back

A configuration example for the acs/shelby

config led 'sata'
        option name 'SATA'
        option sysfs 'shelby:white:sata'
        option trigger 'sata-disk'

I have not.  However, this looks pretty darn sweet.  I may have to load this on my Linux boxes. 

Thanks for sharing

(Last edited by kirkgbr on 6 May 2016, 17:19)

I thought that as well =]  Another forum member [@miguipda] submitted the dev request about a month ago, but I finally had time to sit down and learn how to cross compile so I figured I'd give it a shot

I haven't been able to get it to compile correctly, so if you are able to, could you send me an email with instructions on how you were able to do so, as it appears the cross compiler openwrt wiki is incomplete.

(Last edited by JW0914 on 6 May 2016, 19:02)

I've never cross compiled. 

The usb2 port fix is in linux-4.4.9

Anyone had luck compiling 4.4.8/4.4.9? This is what I get when I try:

CC [M]  net/ipv6/ip6_tunnel.o
In file included from include/linux/swab.h:4:0,
                 from include/uapi/linux/byteorder/little_endian.h:12,
                 from include/linux/byteorder/little_endian.h:4,
                 from ./arch/arm/include/uapi/asm/byteorder.h:21,
                 from include/asm-generic/bitops/le.h:5,
                 from ./arch/arm/include/asm/bitops.h:340,
                 from include/linux/bitops.h:36,
                 from include/linux/kernel.h:10,
                 from include/linux/list.h:8,
                 from include/linux/module.h:9,
                 from net/ipv6/ip6_tunnel.c:25:
net/ipv6/ip6_tunnel.c: In function 'ip6ip6_tnl_xmit':
net/ipv6/ip6_tunnel.c:1399:11: error: 'iph' undeclared (first use in this function)
     ntohl(iph->daddr) >> mshift)

Have compiled and run both with no issues.

anything you do in particular to achieve this?

@xhemp - I compiled 4.4.8 about 90 min ago without issue.

The error seems like a text error within a config... did you by chance edit any build files/configs in windows?

Okay, I'm seeing the same problem I saw last time I flashed an openWRT firmware build. I'm using davidc502 May 1 build, and when I go to edit the wireless radios to set up the wireless, all I see are the labels for the settings all on one line; e.g. "Mode Band Channel Width", with an empty drop-down box under each one. So the drop down boxes for each setting are also all in one line, nicely lined up vertically with the label above it.

I'm not sure why Luci isn't picking things up, I see /etc/config/network and /etc/config/wireless, and those files look normal to me.

Any ideas of why Luci isn't able to use the wireless configuration files from the firmware, or what I should be looking for? The wired connections are fine (of course). This worked for me in older openWRT builds, but the last couple that I've tried I've not been able to configure the wireless.

I should add that this works fine, I can configure the wireless settings without a problem, on the arokh "optimized" openWRT firmware builds. Have no idea where to start troubleshooting this one.

Thanks!

(Last edited by RogerSC on 6 May 2016, 23:42)

nice one, it works for me

btw. lsusb doesn't work

https://jpst.it/Iek7
i had to install version
Package: usbutils
Version: 007-2

Thnx.

(Last edited by gsustek on 6 May 2016, 23:59)

Tell me what you need, and I'll put them out there.

**EDIT** -- I see you probably just want all QoS.. Will take a look at the package options.

I see QoS Scripts?

2nd EDIT

QoS scripts has been uploaded to the server.

Best Regards,

(Last edited by davidc502 on 7 May 2016, 02:56)

This is a common problem if bouncing around between OpenWrt builds.

What's the output of your /etc/config/wireless

The problem is the consistency in the option path. Take a look at my paths, and see if they are the same.

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option channel '1'
        option country 'US'
        option txpower '30'
        option htmode 'HT40'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2+ccmp'
        option key 'OMIT'
        option ssid 'MYSSID'
        option macaddr 'OMIT'

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11a'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option country 'US'
        option distance '10'
        option txpower '27'
        option channel '161'
        option htmode 'VHT80'

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option ssid 'MYSSID'
        option network 'lan'
        option encryption 'psk2+ccmp'
        option key 'OMIT'
        option macaddr 'OMIT'

Interesting, the paths that I have are:

option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'

which are missing the first directory component. When I did a "find" for "wireless", I see that the path does include the "platform" component for:

/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan0/wireless
/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0/net/wlan1/wireless

So if I change these paths by hand in /etc/config/wireless and reboot, is that all that I need to do as far as you're aware? I'm a little leery, since I don't know why these paths would not be correct if generated by the firmware...

Update: Doh! Should have known better.../etc/config/wireless is regenerated without the "platform" component by a reboot. I apparently need to do something about how these paths are generated in the first place?

Update 1: Changed /etc/config/wireless, used "wifi" command to restart wifi, and voila! Luci looking much better. How do I make this permanent across reboots? And again, how can this happen if the firmware generates these paths, and this is a whole new firmware flash? Hmmm...got nothing, here *smile*.

(Last edited by RogerSC on 7 May 2016, 00:57)

When replying to quotes, please either remove the quoted code entirely, or only leave in relevant parts... this helps to prevent exponential page real estate

The change made should be permanent across reboots.

If flashing different firmware... Example going back to 15.05, you may see this problem again. I've seen 4 Radios after a flash from one version to another, and the solution was to delete the "extra" radios in that case.

Many many pages back, in this thread, someone explained why it happens, but I just documented in case it happened again.

Glad it's working again for you.

I'm glad, too. Thanks much! I'll see if I can find the explanation...if it's in this thread, I've got a shot *smile*. Found this very surprising.

And sorry for all the quoting, I'll watch it in the future. Just wasn't being careful enough.

(Last edited by RogerSC on 7 May 2016, 01:24)

As a consequence to the talks with Kaloz, I have decided to switch to LTSI kernel (4.1 at the moment, will change in 2017). Although I will compile test firmware based on 4.4 / 4.6, I will also backport and commit relevant changes for 4.1 to be included upstream in the following days / weeks.

nitroshift

(Last edited by nitroshift on 7 May 2016, 13:28)

May I ask what in your talks with Kaloz caused you to switch?