naasking

Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About naasking

  • Rank
    Newbie
  1. 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.
  2. 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.
  3. 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.
  4. Version: 6.1.1-15101-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?
  5. 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...
  6. 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
  7. DSM 6.0 network drops? SMB particularly bad

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

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

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

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

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

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

    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.
  14. 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.