Debian on Zyxel NAS326

pengu Wrote:
-------------------------------------------------------
> SAMBA performance .. it needs some tweaking on Kir
> kwood boxes ... here .. one line is enough ...
>
>

> min receivefile size = 128k
>

>
> 103 mb/s read ... 98 mb/s write ... (windows 10)
> a little more on my Gentoo Linux box
>
Unfortunately does not make any difference for me.

sebr Wrote:

> Unfortunately does not make any difference for me.

Then pengu should post his smb.conf.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Johannes,

Let me take a close look later today.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Johannes,

Looks like you've missed several fw_setenv commands:

Instruction:

fw_setenv curr_bootfrom 1
fw_setenv next_bootfrom 1
fw_setenv load_dtb_addr 0x1000000
fw_setenv load_initrd_addr 0x2900000
fw_setenv load_image_addr 0x02000000
fw_setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
fw_setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/zImage; ext2load usb 0:1 $load_dtb_addr /boot/dts/armada-380-zyxel-nas326.dtb; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'
fw_setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
fw_setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
fw_setenv change_boot_part 1

You did not execute these:

fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
fw_setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/zImage; ext2load usb 0:1 $load_dtb_addr /boot/dts/armada-380-zyxel-nas326.dtb; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'

You have 2 options:

1. Connect serial console.

2. Request the FW restore tarball from Zyxel. Hopefully, you can format a USB drive and put the restore script and binaries on that. Power up with the restore USB plugged in. See if this rescue mechanism works. We have not tried this option before, so it is good thing that you can find out one way or the other!

Further thought:

If you can't get a restore USB tarball from Zyxel, and can't connect serial console, I will need to look in to my saved tarball and see if I can find something might perform the rescue.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/09/2017 05:17AM by bodhi.

Hi bodhi!

Thanks, I will try the serial console later on. I have to setup either the Atmel STK500 or my raspberry as UART 3.3V<->Serial converter first but both should work.

And I will try to be more careful with the commands next time...

Regards,
Johannes

> have to setup either the Atmel STK500 or my raspbe
> rry as UART 3.3V<->Serial converter first but both
> should work.

It's the best way to have full control!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Then pengu should post his smb.conf.



as I said .. it only needs that line in the smb.conf:

min receivefile size = 128k

All other stuff makes it worse

pengu,

Please post your smb.conf.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi!

Thanks for your help. I connected the serial console throw the stk500 (be sure to set vtarget to 3.3V) and followed the instructions. Linux is now booting...

Thanks,
Johannes

gonzales Wrote:
-------------------------------------------------------
> Hi bodhi!
>
> Thanks for your help. I connected the serial conso
> le throw the stk500 (be sure to set vtarget to 3.3
> V) and followed the instructions. Linux is now boo
> ting...
>
> Thanks,
> Johannes

Cool :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

pengu Wrote:

> as I said .. it only needs that line in the smb.co
> nf:
>
>

> min receivefile size = 128k
>

>
> All other stuff makes it worse

This option not make much difference in my case. As example I used the trimmed down smb.conf from the wiki.
See the attached screenshots for the results in a usage scenario with my Win8.1 desktop PC and a testfile of 10GB size.



Edited 1 time(s). Last edit at 05/11/2017 06:15PM by sebr.

sebr,

> This option not make much difference in my case. A
> s example I used the trimmed down smb.conf from th
> e wiki.
> See the attached screenshots for the results in a
> usage scenario with my Win8.1 desktop PC and a tes
> tfile of 10GB size.

So using the Wiki simple smb.conf, the xfer speed for 10GB file is 85MB/s and 92MB/s?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Exactly, and the same with some additional Tweaks that I tried while testing

socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
read raw = yes 
write raw = yes 
max xmit = 65535 
dead time = 15
getwd cache = yes

Also very strange that there are frequent heavy drops in the speed while copying the testfile.
bodhi, what speeds do you get?

sebr,

> Also very strange that there are frequent heavy dr
> ops in the speed while copying the testfile.
> bodhi, what speeds do you get?

It's been so long ago since I ran the tests, I can't remmember exactly but somewhat comparable to yours (on NSA325v2 and a quad-core MacBook Pro Windows 7 VM). I have not tested with the NAS326.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi!

I have some more questions:
* How can I bind the power-button to shutdown the NAS? At the moment, if I press the power button nothing happens.
* How can I help with Wake-on-LAN-testing? My AVM Fritzbox seems to have a WOL feature but I have not much idea how to debug it

Thanks,
Johannes

Johannes ,

> I have some more questions:
> * How can I bind the power-button to shutdown the
> NAS? At the moment, if I press the power button no
> thing happens.

See the Wiki thread:
http://forum.doozan.com/read.php?2,23630

Section:

Quote

Key daemon (button control)

Multimedia keyboard daemon for Linux

> * How can I help with Wake-on-LAN-testing? My AVM
> Fritzbox seems to have a WOL feature but I have no
> t much idea how to debug it

- Enable WOL

ethtool -s eth0 wol g

- Shutdown the box ith WOL enable

shutdown -h now

- And then on another Linux box in the network:

etherwake xxxxxxx

where xxxxx is the MAC address of the box

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------

> So using the Wiki simple smb.conf, the xfer speed
> for 10GB file is 85MB/s and 92MB/s?

this were the rates without the mentiond line.
I cannot do more on this atm because my NAS326 is gone ...
After changing the Stick and successfully booting Debian again, I decided to upgrade the kernel as usual.
All good I thought .. but the "beep" seys that ZyXEL OS is up and booting debian was unsuccessful.
So I pressed the power button and wait till it was down ...
since that .. it never comes up ... connecting the serial .. gives me nothing ... only the Power LED is lighting up with full brightness
no U-Boot .. nothing ...

for now .. the J1800 has to to the job ...

pengu Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
>
> > So using the Wiki simple smb.conf, the xfer spee
> d
> > for 10GB file is 85MB/s and 92MB/s?
>
> this were the rates without the mentiond line.
> I cannot do more on this atm because my NAS326 is
> gone ...
> After changing the Stick and successfully booting
> Debian again, I decided to upgrade the kernel as u
> sual.
> All good I thought .. but the "beep" seys that Zy
> XEL OS is up and booting debian was unsuccessful.

So it was booting stock at this point.

> So I pressed the power button and wait till it was
> down ...

Bad move! You should have logged into stock OS first, before doing anything more.


> since that .. it never comes up ... connecting th
> e serial .. gives me nothing ... only the Power LE
> D is lighting up with full brightness
> no U-Boot .. nothing ...
>
> for now .. the J1800 has to to the job ...

Given it is this bad, it's time to try the USB key_func restore approach to see if the original FW can restored.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've had NAS326 for a while now and it's been working quite well
but as it's cumbersome to update stuff on it I've been thinking on
trying to install somekind of own system on it.

So are you guys still trying to figure these things out and if so do
you need more reports on these LED statuses and WOL etc.?
Or is this project 'done?'

It has been released:

http://forum.doozan.com/read.php?2,32146

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi guys,

you all did a great job.
Currently I use a NSA325 on Debian Stretch/ Kirkwood kernel 4.x and want to upgrade to NAS326.
Do you think it is possible to change the kernel to MVEBU, do the installation stuff with kwboot,
change the hdd's and everything is done.
Or is there a reason to setup a completely new System from bodhi's rootfs?

Thx

Otto

Otto,

> Or is there a reason to setup a completely new Sys
> tem from bodhi's rootfs?

You should use the new rootfs. It is armhf, instead of armel like the Kirwood. You could use the Kirkwood rootfs, but performance will be not as good.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi @ All

One question

I build my own Debian RootFS and used bodhi's linux-4.12.4-mvebu-tld-1 package.
All works fine, except for one thing

The ethernet have every boot a different mac-address. Is there a way to fix this?
Except to write an address hardcoded in /etc/network/Interfaces


Thx
Kirsch

Hi Kirsch,

> Except to write an address hardcoded in /etc/network/Interfaces

That's the only way to do it cleanly right now.

You could also use macchanger to change the MAC address to the real one. But the effect is will take longer to get the network connection (almost same as when the MAC is changing at each boot).

Technical explanation:

This is due to the limitation of stock u-boot. I had to set it up so that the DTB was not updated by stock u-boot. Therefore u-boot does not pass the MAC address to the kernel in the updated DTB blob. Stock u-boot uses a much older version of the FDT handling code, so it corrupts the blob if we let it update and pass to the kernel.

EDIT: typo.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 08/18/2017 04:27AM by bodhi.

> The ethernet have every boot a different mac-address. Is there a way to fix this?
> Except to write an address hardcoded in /etc/network/Interfaces

This solution has another downside: In my router appears the NSA as a new device with every new start. When I was playing around with the kernel and had to reboot several times, I had the remove about 20 devices from the recognized devices list in my router. So for me the most suitable solution is to hardcode the mac address into the DTB as described some pages before:

+               internal-regs {
+                       ethernet@70000 {
+                               pinctrl-0 = <&ge0_rgmii_pins>;
+                               pinctrl-names = "default";
+                               status = "okay";
+                               phy = <&phy1>;
+                               phy-mode = "rgmii-id";
+                               mac-address = [ 11 22 33 44 55 66 ];

And to put this additional line into the dts patch before compiling a new kernel isn't much expense.

Another topic:
Which CFlags do you use to compile the system. I extraced march=native and got:

CFLAGS="-Ofast -march=armv7-a -mtune=cortex-a9 -mfpu=neon-fp16 -mtls-dialect=gnu -mfloat-abi=hard -pipe -fomit-frame-pointer -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"
CHOST=armv7a-hardfloat-linux-gnueabi

And the third topic:
Booting the kernel gives me the following message:

Sep 09 07:24:12 nas kernel: zswap: loaded using pool lzo/zbud
Sep 09 07:24:12 nas kernel: v5.0-sata0: supplied by pwr_en_sata0
Sep 09 07:24:12 nas kernel: v12.0-sata0: supplied by pwr_en_sata0
Sep 09 07:24:12 nas kernel: input: gpio-keys as /devices/platform/gpio-keys/input/input0
Sep 09 07:24:12 nas kernel: armada38x-rtc f10a3800.rtc: setting system clock to 2017-09-09 05:24:11 UTC (1504934651)
Sep 09 07:24:12 nas kernel: OF: Duplicate name in testcase-data, renamed to "duplicate-name#1"
Sep 09 07:24:12 nas kernel: ### dt-test ### start of unittest - you will see error messages
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: could not find phandle
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: could not find phandle
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Sep 09 07:24:12 nas kernel: OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
Sep 09 07:24:12 nas kernel: irq: no irq domain found for /testcase-data/interrupts/intc0 !
Sep 09 07:24:12 nas kernel: OF: overlay: overlay_is_topmost: #5 clashes #6 @/testcase-data/overlay-node/test-bus/test-unittest8
Sep 09 07:24:12 nas kernel: OF: overlay: overlay #5 is not topmost
Sep 09 07:24:12 nas kernel: ### dt-test ### FAIL of_unittest_overlay_high_level():2234 Adding overlay 'overlay_bad_phandle' failed
Sep 09 07:24:12 nas kernel: ### dt-test ### end of unittest - 149 passed, 1 failed
Sep 09 07:24:12 nas kernel: v5.0-sata1: supplied by pwr_en_sata1
Sep 09 07:24:12 nas kernel: v12.0-sata1: supplied by pwr_en_sata1
Sep 09 07:24:12 nas kernel: v5.0-sata0: disabling
Sep 09 07:24:12 nas kernel: v12.0-sata0: disabling
Sep 09 07:24:12 nas kernel: v5.0-sata1: disabling
Sep 09 07:24:12 nas kernel: v12.0-sata1: disabling

Not sure about this. But it seems to me like some kernel debugging stuff forgotten to remove. It doesn't hurt anything but looks ugly.

Found a new problem:

Under heavy load I lost the connection to my NAS. However, according to the LEDs it seemed to be still working. So I connected the serial cable and got access without problems. The logfile showed me:

Sep 09 17:18:08 nas kernel: sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) 
Sep 09 17:18:08 nas kernel: sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) 
Sep 09 17:17:59 nas kernel: sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z)

Doesn't look like a kernel panic. It's not really reproducible but occurred today already for the 2nd time. Restarting the network doesn't help. I guess there's still a problem with the network driver. Rebooting helps.

musv,

> This solution has another downside: In my router a
> ppears the NSA as a new device with every new star
> t.

> When I was playing around with the kernel and h
> ad to reboot several times, I had the remove about
> 20 devices from the recognized devices list in my
> router.

This should not happen when you use static IP. And when you use dynamic IP, you can reserve the IP using the MAC address.

> So for me the most suitable solution is to
> hardcode the mac address into the DTB

It is not a very good solution to hardcode MAC address in DTB. Hardcode in the rootfs /etc/network/interfaces is much cleaner and more flexible.

> Sep 09 07:24:12 nas kernel: v5.0-sata0: disabling
> Sep 09 07:24:12 nas kernel: v12.0-sata0: disabling
> Sep 09 07:24:12 nas kernel: v5.0-sata1: disabling
> Sep 09 07:24:12 nas kernel: v12.0-sata1: disabling

> Not sure about this. But it seems to me like some
> kernel debugging stuff forgotten to remove. It doe
> sn't hurt anything but looks ugly.

These are OK.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

To my "new problem", which occurred quite often in the last days:

I've stored some music files on my Zyxel. Via NFSv4 I can access these folders on my desktop machine. Playing this music files caused the Zyxel to freeze. I simply wasn't able to access this thing anymore. The serial console didn't give me access too. For some reason the power button was still working. So I was able to reboot the Zyxel.

I 'm talking especially about the music files, because it doesn't produce any mentionable network traffic. When I transfer bigger files, I couldn't recognize this problem. Other network services than nfsd work without any problems.

Investigating the log file gave me:

Sep 27 17:35:37 nas kernel: rpc-srv/tcp: nfsd: sent only 36488 when sending 65644 bytes - shutting down socket

This problem appeared with the last kernel update. Together with this kernel update I also used the last dts patch you provided. I can't reproduce this problem reliably. It occurs from time to time. For some reason I suspect the ethernet section of the dts file:

		ethernet@70000 {
				pinctrl-0 = <&ge0_rgmii_pins>;
				pinctrl-names = "default";
				status = "okay";
				phy = <&phy1>;
				phy-mode = "rgmii-id";
			};

Previously you had included too:

				fixed-link {
					speed = <1000>;
					full-duplex;
				};

What was the reason to remove this section?

musv,

The fixed link is simply not needed. Usually it is a work around for some problem, or really want that when you connect with Gbits only, e.g. in CPU port of a DSA switch. We'd want autonegotiation when you happen to have only a 100Mbps switch connected to the box.

That said, I think this is another symptom of some regression in the 4.12.x mvneta driver. There are other reports about Samba xfer crashes with very large files.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/27/2017 09:25PM by bodhi.

Thanks. Of course the mvneta driver could also be a source of the problems. Additionally I've noticed:

kernel-4.10.x: works perfectly stable and reliable
kernel-4.11.x: never tested
kernel-4.12.x: In case of the occurrence of the error the network freezes completely. I get the nfs error message and the sysrq messages (4 messages above). Can't access the system via Serial console, but I'm able to shutdown the Zyxel via Power button.
kernel-4.13.x: In case of the error occurrence the network (SSH connection) stays active. NFS stops for a couple of minutes. After that the NFS connection re-establishes and works so far again. But sometimes I get the sensation, the system isn't working reliable anymore. Every network service feels a little bit slower. So I feel better to reboot the device.