naasking

Just an update, the drops still happen but are much less frequent with the bandwidth limiter.

So here's my partial solution: I noticed that the drops seemed related to burst traffic, so I used the DSM control panel's traffic shaping tab to limit the bandwidth of the problematic network card to less than 95MB/s (you may have to play around with this number). That seems to have eliminated the drops, but I'll keep you posted.

That's a bummer. I was seriously considering replacing the board with something like this, but it too has a Realtek 8111 chipset. It's the H revision though, ie. RTL8111H. I'm gunshy on the 8111 chipset now, but since this problem seems to only have been reported in the E revisions in this thread, maybe it's a hardware bug in that edition alone.

DSM 5.2 was great for over a year. But I need DSM 6.

Machine boots fine, but network drops still occur. I have the same AuthenticAMD unknown vendor error: [ 0.000000] CPU: vendor_id 'AuthenticAMD' unknown, using generic init. CPU: Your system may be unstable. So perhaps it's all related to the spotty AMD support in Jun's current loader. Strange that everything mostly works though, and it's rock solid otherwise.

Machine boots fine, but network drops still occur. I have the same AuthenticAMD unknown vendor error: [ 0.000000] CPU: vendor_id 'AuthenticAMD' unknown, using generic init. CPU: Your system may be unstable. So perhaps it's all related to the spotty AMD support in Jun's current loader. Strange that everything mostly works though, and it's rock solid otherwise.

I also tried swapping the modules and the memory slots, still no dice. It's strange because the ethernet statistics (netstat -i) don't show any packet drops or errors, it just stops responding for a period of time, then starts up again. Some online posts on Windows with this same issue have disabled "energy efficient ethernet" to fix it, but "ethtool --set-eee eth0 eee off" fails as not supported. I wish I could simply install a new ethernet card, but the one slot I have available is taken by an SATA card I use for my storage. Looking into other embedded motherboards, they all seem to have RTL8111 chipsets of various editions (mostly H or G, I have RTL8111E), so just replacing the board might not actually fix this issue. I have no idea what to do now.

I've tried removing a memory module so I only have 2GB of physical memory, but it hasn't improved the situation. However, the BIOS reports 2GB but Synology's info center says the NAS has 4GB of physical memory. Perhaps it's displaying a cached value? Is there some way to refresh this information?

Hmm, a module r8168 is installed and running. The version says 8.044.02, which seems to only be one minor version behind the up to date one on the Realtek site which is 8.045.08. If someone could point me in the right direction to update this module, I could play around with this and hopefully get it working.

The problem seems well-known in every Linux distro. My board has the Realtek 8111E chipset, and along with the 8168, these load the driver for the Realtek 8169. Unfortunately, this driver is known to produce unreliable ethernet connections on these chipsets. Not sure what I can do to remedy this, as all the recommended solutions that I can find suggest building the drivers Realtek provides from source, and I'm not setup to do that with the Synology images. Anyone have any ideas?

Yes, I just swapped the order of the parameters that were already there. NAS no longer booted with network connectivity.

I have not managed to solve this. Flipping the image load order as you suggested makes my NAS inaccessible over the network. It appears to still boot except for the network drivers. Another person suggested restricting the accessible RAM to 2GB which solved it for their AMD box, so I may try that next since I'm currently running with 4GB.

I can confirm that the Jun's 1.02b loader also works on my box running an AMD E-350 dual core CPU. It's an older CPU, so perhaps whatever initialization code is in place works for older AMD processors. I even updated to the latest release DSM 6.1.3-15152 Update 4, with no issues. I've still experienced the same sporadic problem since I updated to the 6.0 series, so that hasn't changed, but it's not any worse either.

I thought the 6.1 series wasn't yet supported using Jun's loader. I saw a number of posts about problems with 6.0.3 and up. Or is this Jun's alpha loader?

Indeed it seems like ntfs is not supported at all. mount -t ntfs always fails with an unknown filesystem error. I actually tried this on actual Synology hardware too, a DS413j running DSM 6.1, and same problem, so it's not an xpenology problem. It have something to do with GPT partitions, but the other partitions mount fine so I don't know...

Unfortunately it's not solved. Network drops are still fairly common over SMB at least. I noticed this sequence of errors in /var/log/synoservice.log right around the time of the network drop: 2017-04-21T09:20:33-04:00 MagiSAN synoservice: service_type_action.c:130 synoservice: Type [LINK_SENS] restart finished 2017-04-21T09:21:07-04:00 MagiSAN synoservice: service_resume_by_reason.c:12 synoservice: resume [avahi] by reason [ipv4_change] ... 2017-04-21T09:21:07-04:00 MagiSAN synoservice: service_restart.c:21 synoservice: restart [synotunnel] ... 2017-04-21T09:21:07-04:00 MagiSAN synoservice: service_restart.c:34 synoservice: [synotunnel] is not enabled, skip restart action ... 2017-04-21T09:21:07-04:00 MagiSAN synoservice: service_restart.c:52 synoservice: finish restart [synotunnel]. 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:69 synoservice: Type [iP_SENS] restarting 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [nmbd] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [ftpd-ssl] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [snmp] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [pppoerelay] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [avahi] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [iscsitrg] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [ssdp] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:69 synoservice: Type [LINK_SENS] restarting 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [nmbd] restart 2017-04-21T09:21:12-04:00 MagiSAN synoservice: service_type_action.c:82 synoservice: service [ssdp] restart 2017-04-21T09:21:14-04:00 MagiSAN synoservice: service_reload.c:20 synoservice: reload [nginx]. 2017-04-21T09:21:14-04:00 MagiSAN synoservice: service_restart.c:21 synoservice: restart [nmbd] ... 2017-04-21T09:21:15-04:00 MagiSAN synoservice: service_restart.c:52 synoservice: finish restart [nmbd]. 2017-04-21T09:21:15-04:00 MagiSAN synoservice: service_restart.c:21 synoservice: restart [avahi] ... 2017-04-21T09:21:15-04:00 MagiSAN synoservice: service_restart.c:52 synoservice: finish restart [avahi]. 2017-04-21T09:21:15-04:00 MagiSAN synoservice: service_reload.c:46 synoservice: finish reload [nginx]. 2017-04-21T09:21:15-04:00 MagiSAN synoservice: service_type_action.c:130 synoservice: Type [LINK_SENS] restart finished 2017-04-21T09:21:20-04:00 MagiSAN synoservice: service_reload.c:20 synoservice: reload [nginx]. 2017-04-21T09:21:20-04:00 MagiSAN synoservice: service_restart.c:21 synoservice: restart [nmbd] ... 2017-04-21T09:21:21-04:00 MagiSAN synoservice: service_restart.c:52 synoservice: finish restart [nmbd]. 2017-04-21T09:21:21-04:00 MagiSAN synoservice: service_restart.c:21 synoservice: restart [avahi] ... 2017-04-21T09:21:22-04:00 MagiSAN synoservice: service_restart.c:52 synoservice: finish restart [avahi]. 2017-04-21T09:21:22-04:00 MagiSAN synoservice: service_reload.c:46 synoservice: finish reload [nginx]. 2017-04-21T09:21:23-04:00 MagiSAN synoservice: service_type_action.c:130 synoservice: Type [iP_SENS] restart finished This repeats many times, and the timing seems roughly correlated with network drops. You can see all the network services restarting (including OpenVPN which shows up on synosys.log), but I don't see any reasons logged. Any thoughts? Some other observations: * Some threads on synology forums[1] report the same log entries as aboe, but I'm not using any of PPTP, IPSEC/L2TP or AFP. * Now that I've been up and running for a good half hour, network drops seem less frequent (could be a coincidence). * The above restart messages occur every time the OpenVPN connection on the NAS connects/disconnects, presumably because the IP changes so all IP services are restarted. Perhaps the problem is ultimately with the OpenVPN connection. [1] https://forum.synology.com/enu/viewtopic.php?t=118970

I confirmed that the default boot selection was not AMD for some reason, which is why I received that AuthenticAMD error in dmesg. When I boot with the correct option I see 3.6 GB of memory instead of the previous 2.5 GB. 500MB would be reserved for onboard devices, like built-in graphics and network, which seems reasonable, so that's solved. I also reset the my BIOS memory timings to auto, and network seems pretty stable so far. So fingers crossed...

Hmm, I just noticed that synology is only recognizing 2.5GB of the 4GB of RAM installed in the NAS. dmesg reports the following error: [Thu Apr 20 18:51:27 2017] SMBIOS 2.6 present. [Thu Apr 20 18:51:27 2017] DMI: System manufacturer System Product Name/E35M1-I DELUXE, BIOS 1501 04/25/2013 [Thu Apr 20 18:51:27 2017] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [Thu Apr 20 18:51:27 2017] e820: remove [mem 0x000a0000-0x000fffff] usable [Thu Apr 20 18:51:27 2017] e820: last_pfn = 0x13f000 max_arch_pfn = 0x400000000 [Thu Apr 20 18:51:27 2017] MTRR default type: uncachable [Thu Apr 20 18:51:27 2017] MTRR fixed ranges enabled: [Thu Apr 20 18:51:27 2017] 00000-9FFFF write-back [Thu Apr 20 18:51:27 2017] A0000-BFFFF write-through [Thu Apr 20 18:51:27 2017] C0000-D1FFF write-protect [Thu Apr 20 18:51:27 2017] D2000-E7FFF uncachable [Thu Apr 20 18:51:27 2017] E8000-FFFFF write-protect [Thu Apr 20 18:51:27 2017] MTRR variable ranges enabled: [Thu Apr 20 18:51:27 2017] 0 base 000000000 mask F00000000 write-back [Thu Apr 20 18:51:27 2017] 1 base 0A7F00000 mask FFFF00000 uncachable [Thu Apr 20 18:51:27 2017] 2 base 0A8000000 mask FF8000000 uncachable [Thu Apr 20 18:51:27 2017] 3 base 0B0000000 mask FF0000000 uncachable [Thu Apr 20 18:51:27 2017] 4 base 0C0000000 mask FC0000000 uncachable [Thu Apr 20 18:51:27 2017] 5 disabled [Thu Apr 20 18:51:27 2017] 6 disabled [Thu Apr 20 18:51:27 2017] 7 disabled [Thu Apr 20 18:51:27 2017] e820: update [mem 0xa7f00000-0x13effffff] usable ==> reserved [Thu Apr 20 18:51:27 2017] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1007MB of RAM. I don't know if this was the case under DSM 5, but it still seems strange that such an old mobo would still have this problem.

It has to be network related. I can't even ping the NAS when the SMB copy halts. Resource monitor and ssh connections also temporarily fail. ssh reconnects when IP comes back up, but the web interface logs me out, so I can't view the resource monitor throughout. ifconfig eth0 reports 0 errors. SMB transfer speed is brutally slow when it reconnects (max 21MB/s vs. typical 100+MB/s), even after I restart smbd, but seems to be a little more reliable. If I switch from SMB 2 with jumbo frames to just SMB 2, transfer speed goes back up to 100+MB/s. This whole thing is just weird.

Still getting network drops. I can reproduce it pretty consistently now, I just have to boot then start a large SMB transfer. SMB quickly fails and I can't ping the server for a minute, then IP connectivity is restored. I can reach SMB by IP, but not by name. Lookup by name still hasn't come back after 5 mins. I usually reboot the samba process and lookup by name works again. No messages in /var/log/messages, no errors in dmesg that I haven't already mentioned. I'm now using the MAC I found and inputted the proper MB serial number, but no dice. I'm out of ideas. Let me know if you have any suggestions for where to look in the logs to diagnose the problem, and thanks for your help!

Leaving mac1 setting blank seems worse. Full network disconnects seem to happen more frequently. The eth0 MAC actually changes on each boot so I think it's random if it's left empty, doesn't actually use the device MAC.

Same problem with the MAC from "ethtool -P eth0" too. NAS is an AMD machine, so dmesg at the beginning reports: [ 0.000000] CPU: vendor_id 'AuthenticAMD' unknown, using generic init. CPU: Your system may be unstable. Pretty sure I specified the correct grub line to boot though, or is that message an indication that I got it wrong? I just saw your other message about the empty line, so I'll try that next.

The DSM install instructions suggested changing the MAC in the grub file, which I did slightly change from the default (changed 2-3 chars), but I didn't think to use the actual NIC MAC. I just tried changing the MAC to a randomly generated one and the problems persist (might actually be worse as transfer speeds are dramatically slower, but that's possibly due to cold caches). The usual methods of checking the MAC address just report the random number I input... Ah, just found ethtool -P eth0 which returned something different, so I will try that.

I recently upgraded from a rock solid DSM 5 to DSM 6 for some much needed features. The upgrade went pretty smoothly, but the network and file services on DSM 6 update 10 seem to periodically drop. A 1GB file transfer over SMB or NFS will be chugging along at 100MB/s and then suddenly drop to zero. It sometimes resumes maybe 30 seconds later. Drops aren't predictable that I can see. Sometimes I won't see one for quite some time, and sometimes it happens repeatedly in the span of 10 mins. I don't see anything in the SMB logs, even if I log in via ssh and inspect them manually. SMB seems to get hit the worst. Right now I'm on the NAS via ssh, but can't load it via Windows explorer over SMB. Usually changing the supported SMB version fixes the issue relatively quickly, because that resets the network configuration thus restarting some services. But not always. About the only error I see in /var/log/messages is the following: 2017-04-20T17:33:14-04:00 MagiSAN synow3: net_get_mac.c:165 ioctl mac failed 2017-04-20T17:33:14-04:00 MagiSAN synow3: net_get_mac.c:63 Failed to get local original mac At this point I'm thinking it might be a network driver issue, but I don't see any issues being logged. Unless I'm missing some log somewhere? Any suggestions would be much appreciated.