Thanks.  Sera also suggest that.

Anyway just update the wifi driver only in the 15.05.1 version?

BTW, any idea how to log if the USB (3.0 or 2.0) may be the culprit?

(I just let the logd export the log file to an external USB flash (SD) so that I can check closely what may have happened)

Kaloz's build is on 15.05.1 and the latest driver relevant for the 1900 models. He also offers a build for the 3200, but the driver there is a little outdated now as there have been some commits over the past two weeks which he has not added in yet into his releases.

(Last edited by cybrnook2002 on 27 Nov 2016, 18:36)

can you share samba config? don't get it whats wrong whit the speed.

Nice, thanks davidc502

without security related options:
------
[global]
    deadtime = 30
    domain master = yes
    encrypt passwords = true
    enable core files = no
    local master = no
    load printers = no
    max protocol = SMB2
    min receivefile size = 16384
    os level = 20
    preferred master = yes
    printable = no
    smb encrypt = disabled
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=1048576
    syslog = 10
    use sendfile = yes
    writeable = yes
   
        large readwrite = yes
aio read size = 16384
read raw = yes
write raw = yes
getwd cache = yes
oplocks = yes
--------------------

These options are the result of a lot of experiments and may contain a lot of cargo cult code. In case you find errors please feed back!

Drive is on usb3 on the same bus where "Linux Foundation 3.0 root hub" is shown.
Drive format is ext4.

Hope it helps.

robd

On the latest wifi driver I've had a few drop outs with the following in the log.

This appears to happen under a little bit of load.

[61054.184304] ieee80211 phy0: cmd 0x9125=BAStream timed out
[61054.189743] ieee80211 phy0: return code: 0x1125
[61054.194292] ieee80211 phy0: timeout: 0x1125
[61054.198503] ieee80211 phy0: destroy ba failed execution
[61178.090217] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[61178.096086] ieee80211 phy0: return code: 0x001d
[61178.100634] ieee80211 phy0: timeout: 0x001d
[61178.104839] ieee80211 phy0: failed execution
[61182.128148] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[61182.134032] ieee80211 phy0: return code: 0x001d
[61182.138618] ieee80211 phy0: timeout: 0x001d
[61182.142828] ieee80211 phy0: failed execution
[61186.148064] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
[61186.153935] ieee80211 phy0: return code: 0x001d
[61186.158483] ieee80211 phy0: timeout: 0x001d
[61186.162690] ieee80211 phy0: failed execution

Think it could be related?
https://github.com/kaloz/mwlwifi/commit … bde95f3cde

Hi Everyone
Slightly off topic question. Currently i can build a full openwrt image for the 1900AC router.
How do i go about compiling a single package that is compatible with my kernel?

e.g im looking to get two packages:  pptpd, kmod-mppe

Thanks

How to Build a Single Package

That makes sense. 

My only point was it's not logical or rational to bring all routers on a 385 SoC inline with the only router on an XP SoC, even more so when all devices going forward in the WRT Series are going to fall in line with the 385 SoC, not the XP SoC. 

• Generally speaking, we move forward not backward, and while this may simply be illogical now, it'll create problems as the WRT line grows if every new device is going to be made to fall in line with the only device on an XP SoC... it's a recipe for user problems in the future.

Have you verified you're getting the same 20MB/s on other devices while connected to the 5gHz network?  It would be helpful to rule out the device you're using, simply to ensure this is an issue with the router and not the PC.

1. Is the only network activity during the file transfer the file transfer? 
   

   • This includes Game Systems and PCs in StandBy, as both can/will still download updates, or games, while in StandBy.

2. What channel are you using for the 5gHz network... if it's not in the 150's try a channel in the 150's to see if that helps.
   

   • Do you have the same issue on the 2.4gHz network?

3. Have you verified you have the optimal settings set for the WiFi card on your PC?  Have you verified your WiFi card drivers are up to date?

Also, please utilize code brackets for code & log output.

(Last edited by JW0914 on 30 Nov 2016, 18:04)

@anyone

Could someone help me out with this:

[  740.435229] ata1: exception Emask 0x10 SAct 0x0 SErr 0x180000 action 0x6 frozen
[  740.442629] ata1: edma_err_cause=02000020 pp_flags=00000003, SError=00180000
[  740.449782] ata1: hard resetting link
[  740.797013] ata1: SATA link down (SStatus 0 SControl F310)
[  742.520158] ata1: hard resetting link
[  745.267084] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl F310)
[  745.467237] ata1.00: configured for UDMA/133
[  745.471562] ata1: EH complete

This started happening sometime after the kernel 4.4.32 was merged to LEDE. At first I thought it might be the HDD but SMART + badblock -wsv showed no problems (I still have 1 year left on the warranty). Then I suspected the enclosure but I tried with another enclosure and another drive and the issue persists (Should the kernel only be built with one fs module?). Despite this i went out and bought a new esata cable and formatted the drive in ext4 yet the errors seems to persist, so I am left wondering if maybe the issue is the esata controller on my WRT1900AC or the code in the kernel (any changes made between .32 and .35?) I'll build an openwrt imgage and test just in case.

Update: some more output

[  289.793929] ------------[ cut here ]------------
[  289.798609] WARNING: CPU: 1 PID: 659 at drivers/ata/libata-sff.c:1048 ata_sff_hsm_move+0x54/0x750()
[  289.807691] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY 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 ipt_ECN ip_tables crc_ccitt sch_teql em_nbyte sch_codel sch_dsmark sch_prio sch_pie act_ipt em_meta sch_gred sch_htb cls_basic em_text sch_tbf sch_sfq act_police sch_fq em_cmp sch_red act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress mwlwifi mac80211 cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ifb sd_mod gpio_button_hotplug xfs libcrc32c btrfs xor xor_neon raid6_pq exportfs
[  289.909288] CPU: 1 PID: 659 Comm: kworker/1:3 Not tainted 4.4.35 #0
[  289.915590] Hardware name: Marvell Armada 370/XP (Device Tree)
[  289.921468] Workqueue: ata_sff ata_sff_pio_task
[  289.926075] [<c0027ce8>] (unwind_backtrace) from [<c0024468>] (show_stack+0x10/0x14)
[  289.933883] [<c0024468>] (show_stack) from [<c021745c>] (dump_stack+0x8c/0xa0)
[  289.941164] [<c021745c>] (dump_stack) from [<c0034dbc>] (warn_slowpath_common+0x94/0xb0)
[  289.949311] [<c0034dbc>] (warn_slowpath_common) from [<c0034e74>] (warn_slowpath_null+0x1c/0x24)
[  289.958156] [<c0034e74>] (warn_slowpath_null) from [<c02c1b38>] (ata_sff_hsm_move+0x54/0x750)
[  289.966741] [<c02c1b38>] (ata_sff_hsm_move) from [<c02c23e4>] (ata_sff_pio_task+0x1b0/0x1e8)
[  289.975244] [<c02c23e4>] (ata_sff_pio_task) from [<c0049404>] (process_one_work+0x228/0x3bc)
[  289.983741] [<c0049404>] (process_one_work) from [<c00498a8>] (worker_thread+0x310/0x504)
[  289.991980] [<c00498a8>] (worker_thread) from [<c004e5bc>] (kthread+0xf0/0xf8)
[  289.999259] [<c004e5bc>] (kthread) from [<c0009d38>] (ret_from_fork+0x14/0x3c)
[  290.006524] ---[ end trace b6e15b82a9ea9780 ]---

Update 2: Connecting a USB to the esata port on the wrt works fine no errors (same enclosures limited to usb 2.0) and USB 3.0 works fine. So right now the only culprit is the esata driver or connections, I have tried both esata enclosures with my laptop esata port and the devices can be read and written to with no problem (Arch linux kernel 4.8)

(Last edited by lifehacksback on 1 Dec 2016, 03:45)

Hi
i have the feeling since the introduction of the fq_codel or tx reorder patch wlan is slower then before?
For example when i browse the web with my mobile device webpages load quite fine but it takes quite sometime until the load to 100%. Over 5Ghz.
Over LTE the pages are loading instantly.

you can disable fq_codel and test it.

David Lang

By removing the patch file or is there some other way?

@lifehacksback

i have the same issue with sata hdd connected through esata/usb adapter/splitter, changed esata cable, change splitter but it is the same, usb3.0 works fine...  and i have this issue from the begining of LEDE, also on openwrt builds....

what can cause this?

Ok, after 2 days 3 enclosures 3 esata cables different LEDE/Openwrt images and my esata port on my computer i have come up with this:

1) Linux uses libata to check connection with the esata drive, this will negotiate a speed and continuously check the connection.
2) Connecting the esata drive directly to my Arch machine yielded the same error, interestingly enough it only had this error once, when first plugged in.
3) I wanted to see if checking hot-swappable in BIOS would help clear the warnings (Dang you American Megatrends) alas there was no bios option. However my sata drive was being seen by bios as a internal drive (makes sense)
4) I continued to boot up my PC and alas journald -rk showed no error (as it initialized the libata and negotiated the speed all at boot along with the other ssd's and hdd's). Continued to use the drive with no problem and the error would not show up again until i purposefully unplugged and replugged the esata from the port (all of this on an Arch kernel 4.8) then the error would show up when unplugged and show up again when i replugged but only once per action!!!! I'm assuming the bios is not set so the esata port is hot-swappable or libata is not used to removable sata drives.
5) did the same thing on the router and poof the error disappeared from the first 20 seconds on the boot and the drive seems to have initialized correctly. But after the 30 second mark more of the errors showed up culminatting on a negotiation speed of 1.5 Gbps and so far no other error message.

[   31.696706] ata1: exception Emask 0x10 SAct 0x0 SErr 0x100000 action 0x6 frozen
[   31.704300] ata1: edma_err_cause=00000020 pp_flags=00000003, SError=00100000
[   31.711420] ata1: hard resetting link
[   32.222592] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[   32.262907] ata1.00: configured for UDMA/133
[   32.267236] ata1: EH complete
[   34.973424] ata1: exception Emask 0x10 SAct 0x0 SErr 0x100000 action 0x6 frozen
[   34.980910] ata1: edma_err_cause=00000020 pp_flags=00000000, SError=00100000
[   34.988095] ata1: hard resetting link
[   35.492564] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[   35.532954] ata1.00: configured for UDMA/133
[   35.537271] ata1: EH complete
[   42.653220] ata1: exception Emask 0x10 SAct 0x0 SErr 0x100000 action 0x6 frozen
[   42.660679] ata1: edma_err_cause=00000020 pp_flags=00000000, SError=00100000
[   42.667866] ata1: hard resetting link
[   43.172593] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[   43.212949] ata1.00: configured for UDMA/133
[   43.217266] ata1: EH complete
[   62.315050] ata1: limiting SATA link speed to 1.5 Gbps
[   62.320352] ata1: exception Emask 0x10 SAct 0x0 SErr 0x100000 action 0x6 frozen
[   62.327795] ata1: edma_err_cause=00000020 pp_flags=00000000, SError=00100000
[   62.334951] ata1: hard resetting link
[   62.842508] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl F310)
[   62.882788] ata1.00: configured for UDMA/133
[   62.887112] ata1: EH complete

Seems like maybe there was a regression on libata? Arch was using libata 3.0. Right now I can't tell for sure But I know the hdd or the enclosures are not the problem (again I have used 3 diffrent enclosures and 3 different esata cables on the wrt and on my esata port with 3 different hdd all passing smartctl test and dd zeroing all the drives)

update: apparently lede has libata 3.0 too... Just got an Anker esata+usb3 "enclosure" and the error is gone. I am simply lost for words, how do 2 enclosures fail almost at the same time?

Big update: Seems the error is normal for eSata drives when plugging and unplugging the connections (since this enclosure made the same error but only once when i unplugged it and once when I plugged it back in seems the "errors" are just warning about the connection but since this is a new enclosure and another drive seems like it's ok as long as they only happen when connecting or disconnecting [my other enclosure seemed to have a bad controller since it would continually search get "disconnected"])

(Last edited by lifehacksback on 2 Dec 2016, 05:55)

@lifehacksback please give as a link for this "Anker esata+usb3 "enclosure"".

What encloser? why didn't you directly connect with esata to sata cable router with HDD,(use separate USB-not from router to give power to HDD with USB to 15-pin power cable)

I have this re connection, not only when i connect and disconnect my HD. I set HDD spindown for 10 minutes or so from luci..

(Last edited by gsustek on 2 Dec 2016, 08:15)

The /proc/cpuinfo of this router shows "vfp*" features. Did anyone confirm if OpenWRT will run without software floating point compiled (unset CONFIG_SOFT_FLOAT) and if it makes any performance difference?

Have you tried connecting the disk to a desktop and running smartctl (smartmontools) to check if the disk is dead or alive? Maybe a esata cable that fit more snuggle

Here is the link for the enclosure https://smile.amazon.com/gp/product/B00 … &psc=1

seems like esata was bad since the new esata that came with the case made good contact and is correctly negotiating speed to the previous case! Lose cable would be problem (also I don't think hd-idle is for sata more for ide read ther webpage)

(Last edited by lifehacksback on 2 Dec 2016, 08:53)

I see your point but upstream unified it in 4.6 the other way around, so following suite would be the right choice. Then it also works for Rango . A documentation issue with have either way.

No issues here using hardfloat. Disable softfloat and see if it makes a difference for the metric you care about.

Thanks for the confirmation. I didn't want create an exception crash that requires manually switching firmware with the power button. I found some context here on flags used by OpenWRT for both options:

http://trac.gateworks.com/wiki/floatingpoint#OpenWrt

I believe smartctl is available on openwrt, although I can't remember if it's a package or part of busybox's build options.

Just an FYI about eSATA:  I tend to avoid using eSATA cables whenever possible as they're extremely fragile and prone to causing data corruption.  If one is looking to buy an enclosure, and wants eSATA, it's better in the long run to buy a USB 3/eSATA combo casing, or just as USB 3 casing. 

• Does anyone know what the SATA version is for the eSATA port?

(Last edited by JW0914 on 2 Dec 2016, 16:31)

This is interesting,  V2 flavours.

Could a kind Mamba user post the output of "lsusb -t" so I can configure the new usbport led trigger in 4.9 correctly. You may have to install usbutils first.

Thanks
---

JW0914,

SATA 3