Hence, I can eliminate every config changes. It must be the network driver in the kernel.

bodhi Wrote:
-------------------------------------------------------
> Data point: I've tested a 1GB file xfer with NFS on 4.12.x, and it did not cause me any problem.

It's not caused by a single file. For me the most likely way to reproduce it, is to send files not with full speed over a longer period of time - half an hour up to an hour. That's why I wrote explicitly: listen to music files, that are stored on the nfs device.

musv Wrote:
-------------------------------------------------------
> I tried kernel 4.13.7 today. To get sure the
> problem is not related to my config, I took the
> config of 4.10.10 (the last fully working kernel)
> and used also the dts file from April.
>
> The problem occurred again:
>

>
> Hence, I can eliminate every config changes. It
> must be the network driver in the kernel.
>
> bodhi Wrote:
> -------------------------------------------------------
> > Data point: I've tested a 1GB file xfer with NFS
> on 4.12.x, and it did not cause me any problem.
>
> It's not caused by a single file. For me the most
> likely way to reproduce it, is to send files not
> with full speed over a longer period of time -
> half an hour up to an hour. That's why I wrote
> explicitly: listen to music files, that are stored
> on the nfs device.
>
> So far I downgraded to 4.10.10.

I'm currently in contact with the mvneta developer from free-electrons.com. With their help I'm testing around.

The first step was to take the mvneta driver directory (kernel/driver/net/ethernet/mvneta) from 4.10.10 and replace the driver from 4.13.7. I had to modify a few lines but I got the 4.10.10 driver running in 4.13.7 and it works perfectly without any issues.

In the whole driver update list, they have marked 3 patches as potentially suspicious. So I'll revert those patches and see, which one is the critical one.

I am still at 4.9.5-tld-8 and am planning to upgrade to the latest available kernel soon.
Do I gather correctly from the recent posts that it's better to wait with the upgrade until the mvneta issue is sorted out?

kralan Wrote:
-------------------------------------------------------
> I am still at 4.9.5-tld-8 and am planning to
> upgrade to the latest available kernel soon.
> Do I gather correctly from the recent posts that
> it's better to wait with the upgrade until the
> mvneta issue is sorted out?

It's really up to you. If your use case is similar to musv then I'd say don't upgrade. OTOH, I am not sure when this will be sorted out. If there is no activity upstream for a while, then I would have to repeat musv test and try patching the mvneta driver myself.

I compared the my kernel config in the nand-section with your provided one. But there weren't any noticeable differences. I even activated CONFIG_MTD_AR7_PARTS (didn't find any documentation about this thing) and CONFIG_MTD_CMDLINE_PARTS.

> I need some help with kernel-4.18.x. I don't get
> the mtdparts running.

> What did I miss? 4.16.13 (last update) works fine.

The kernel config did not change. It always has CONFIG_MTD_CMDLINE_PARTS.

The crash happened because you have the DTB appended to uImage. You are not booting with the separate DTB (also not with separate uInitrd, but uInitrd is not the problem). So the bootargs does not have the cmdline mtdparts.

I understood you want to make it simple. But I would recommend setting up booting with separate DTB and with uInitrd. The logistics is too cumbersome when you always need to remember to append the DTB. And the ability to boot with appended DTB will be removed from the mainline kernel eventually.

Please let me know if that was indeed the problem or if it was something else (systemd has some problem lately).

you know, I am quite satisfied with this device. I wish it had dm-cache enabled in the kernel... idk if I can compile the kernel outside of the box and ssh in a .so file and insmod it, but that might be ideal considering my use case. I am just trying to enable a read cache. I would use lvm, but...dm-cache isn't enabled. If I could download a basic toolset (any busy box built cache might do) I might be able to build a cache using a compiled program or something. Any ideas. Otherwise I was going to go down this route to setup a zfs read cache (but no write cache, I'll let the os handle that) from a usb 3.0 either flash (~120MBs read) or a usb 3.0 ssd (~500MBs read)

Do I need usb/serial to apply the alternative kernel? That's why I was leaning towards trying to build the .so file using default latest fw kernel.

Oh yeah, my use case is I'm using iscsi in proxmox using zfs and boy let me tell you, I am getting amazing performance. Although I thought I could do a little better by setting up nas side caching that was larger than my node size caching. Then i'd have a constant buffer on my nas side to make most use of the throughput making up cache hits on a slower disk medium (slower medium's = larger caches).

Installation for NAS326 box can be done with serial console connected (section A), or inside stock OS and without serial console (section B for USB rootfs, section C for SATA rootfs). Note: for section A and B, the USB rootfs must be inserted to the front USB port (USB 2.0).

If I could get either the newer lvm2 with cache support, or zfs, or dm-cache working with that kernel. I'd go for it. Now that I know it's possible. I'm half tempted to just say f it and go for it. If it breaks, I can always serial it afterwards.

omg. I see I can rollback!

"To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line: "

I am owner of 325v1 and 326 boxes.
No issues with 325v1 - WOL works well.
Nowadays I am not sure about nowadays state of WOL of NAS326 box.
326:
- I have succesfully configured USB boot using method B. BTW: Big thanks for Your effort to tune these devices and for documentation and forum replies You made.
- I have connected to serial terminal to check boot process
- using USB rootfs and Your kernel version 4.20 - I think (I am writing now from office without access to NAS326 box)
- succesfully configured esekeyd daemon to enable buttons on box header (configuration example/s posted in this forum are not fully correct) + update of /etc/init.d/esekeyd initscript is needed to make buttons working

Biggest issue was to find out well working config because default config was not working to me.
Combination of

man esekeyd + googling + keytest

helped...

- biggest problem of the NAS326 - is not working WOL (working well for my NSA325v1)

- Bodhi, are You please able to summarize Your statements relating to WOL on 326? Maybe I made some error/missed something to configure. Issues with WOL are not discussed lately, it can mean that it works for others...

Update:

I am going to use stock firmware to test WOL functionality in original firmware

Thanks for the info about the key. It seems esekeyd has some problem and need to be updated to properly recognize standard Linux keys.

> - biggest problem of the NAS326 - is not
> working WOL (working well for my NSA325v1)
> - Bodhi, are You please able to summarize Your
> statements relating to WOL on 326? Maybe I made
> some error/missed something to configure. Issues
> with WOL are not discussed lately, it can mean
> that it works for others...

WOL does not work on NAS326 at this moment. It was still a work in progress and I did not have time to continue the investigation. In theory, it should work. But I think there is some settings that we have not figured out. When we shutdown the NAS326 with poweroff GPIO, the ethernet port was also powered down, but it should not.

If you look at the NSA325 ethernet port during shutdown, it basically goes into a low power saving state and the LED is amber color. That's the proper behavior.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.