Hi in the last few builder there seem to be a issue with the Traffic Analyzer - Statistic
Traffic history location = Custom Location
Save frequency = Every 1 Hour
Save history location = /mnt/SYSTEM/Logs (Front USB port)
Seem be failing to write data on USB stick after about 3 to 4 days and of one core has High CPU usage
I have a similar problem like the above, but the difference is that I have portable two USB hard disk drives plugged into both USB 2.0 and 3.0 ports. Just yesterday, the Western Digital (WD) HDD can be read from, but any time I try to write something to the WD, Windows 7 Explorer would lock up and I see that core 1 CPU of the router is at 100%, until I end the write transfer, then would the core 1 CPU drop back down to 0%. I rebooted the Asus RT-AC68U router. Still wouldn't solve it. I had WD scanned using the built in health scanner on the front page of the router web screen. The router failed to fix allocation problem, so I took the WD and plugged it into my Windows computer, scanned the WD and fixed some errors. I replugged it in and it was okay to write to the WD HDD again, no more core 1 CPU running at a high 100% utilization. I then noticed my other USB portable HDD, Seagate, after scanning with the built in health scanner, the Seagate developed a red ring around the USB icon. I took the Seagate and scanned it from my Windows computer and it was fine. Still, the router thinks that the Seagate has a problem after being plugged back in.
Fast forward to today, about 16 hours later, both cores 1 and 2 CPUs are running at 100%, slowed down my network response, and crashed my Wi-Fi such that another device trying to log into the Wi-Fi, failed to connect. I decided to downgrade the firmware from 380.65 back down to 380.64_2. So far, everything works fine. One thing I like to note is that I have not done a full default wipe/reset for the last few firmware upgrades. I'll probably try to upgrade the firmware back to 380.65 with a reset and configure everything back. But as of right now, it seems that 380.65 has an issue with USB writing similar to the poster above.
Update 3/7/17: After downgrading to 380.64_2, read and writing to the Seagate and WD HDDs were fine. But when I used MiBox (Android TV box) with Kodi v17 to access Seagate HDD, something was wrong. Kodi wasn't able to read from the Seagate HDD. I rebooted the router many times because CPU utilization shot up to 100% and made the router unresponsive, and also Kodi was unresponsive, so the MiBox was restarted many times. I decided to test the Seagate HDD (model # STEA4000400, 4 TB USB 3.0 portable HDD) with SeaTools for Windows. I did the basic test, such as Short Drive Self Test. It passed. I then moved onto Short Generic. That's when it failed constantly. The Seagate failed at the inner test. I checked the warranty and I have about 3 months of warranty left on the 1 year warranty. BTW, the Seagate HDD was assembled and product of China. I don't know if country plays a role, but just throwing it out there for the record of where the Seagate HDD came from. This will probably be my first and last purchase of Seagate HDD. They're notorious for failures, especially some reviews have already noted this type of model drive is questionable in reliability. I've had many WD HDDs that lasted much longer, even though 1 died out of the many I have. I will update the router back to 380.65 and observe if the router's CPU is abnormally very high. I highly suspect that it was because the Seagate HDD was failing and causing the router to get locked up communicating with a dying HDD. BTW, WD HDD (My Passport 2 TB USB 3.0) tested fine through the two tests that I've put the Seagate HDD through. System log shows a lot of this:
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592
Mar 7 03:00:47 kernel: b_state=0x00000020, b_size=512
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592
Mar 7 03:00:47 kernel: b_state=0x00000020, b_size=512
Mar 7 03:00:47 kernel: device blocksize: 512
Mar 7 03:00:47 kernel: __find_get_block_slow() failed. block=4841037888, b_blocknr=546070592
Update 3/13/17: Looks like the Seagate HDD was the culprit, the router is running just fine with 380.65. I used the SeaTools and ran through the "Fix All Long", it finished with a "Pass" (success), then I run "Short Generic" test, and it failed. So off for warranty processing it is for the Seagate HDD.
Update 3/18/2017: Looks like the WD HDD also exhibited similar situation where 1 of the 2 core CPU was near 100% (it was hovering around 80%) when I tried to transfer files to it over the wireless network. I decided to scan it with WD Drive Utilities, it passed all checks (Drive Status Check, Quick Drive Test, and Complete Drive Test). The Complete Drive Test is basically fix any bad sectors while testing. I viewed previous Chkdsk results from within Windows and I see that WD HDD lost one allocation unit (4096 KB) when I ran a Chkdsk in 2016. Jumping back to the Seagate HDD, I didn't process the Seagate HDD for warranty given how Seagate explained on their website that they would just do a low level format and fix bad sectors, when I have access to fixing bad sectors tool. I ran SeaTools and chose Fix All Long (also fixes bad sectors). The Seagate HDD passed. Of course, it failed the Short Generic Test again after that. So I now see that the Short Generic Test is unreliable. I also compared Chkdsk results and I see that Seagate lost over 1,000 allocation units. Both drives are now accessible and do not create anymore surge in CPU usage on the Asus router and transfer data fine. It seems that since both USB HDD had bad sectors, I suspect that power must have disrupted and cause the HDD to shutdown improperly. Therefore, I would like to conclude that if your Asus router has a constant surge in CPU usage and there is a USB drive attached to the router, run Chkdsk or similar utility to scan for bad sectors and fix them.