naasking

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

About naasking

  • Rank
    Junior Member
  1. DSM 6.0 network drops? SMB particularly bad

    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.
  2. DSM 6.0 network drops? SMB particularly bad

    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.
  3. DSM 6.0 network drops? SMB particularly bad

    DSM 5.2 was great for over a year. But I need DSM 6.
  4. DSM 6.0 network drops? SMB particularly bad

    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.
  5. DSM 6.0 network drops? SMB particularly bad

    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.
  6. DSM 6.0 network drops? SMB particularly bad

    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.
  7. DSM 6.0 network drops? SMB particularly bad

    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?
  8. DSM 6.0 network drops? SMB particularly bad

    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.
  9. DSM 6.0 network drops? SMB particularly bad

    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?
  10. DSM 6.0 network drops? SMB particularly bad

    Yes, I just swapped the order of the parameters that were already there. NAS no longer booted with network connectivity.
  11. DSM 6.0 network drops? SMB particularly bad

    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.
  12. DSM 6.1.3-15152 Update 4

    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.
  13. DSM 6.1.1-15101 Update 2

    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?
  14. 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...
  15. DSM 6.0 network drops? SMB particularly bad

    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