Some questions after 5.13 kernel update

Hi Guys.

After updating my NAS326 to kernel 5.13 I have a few questions.

1. The MAC address is still not fixed. In U-boot the variable ethaddr is set (from the sticker under the NAS326), but the kernel log still says "Using random mac address". I have already written the variable in the kernel command line out of desperation, but it is always ignored:

[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=8 mtdparts=pxa3xx_nand-0:2m(u-boot),2m(env),2m(config),15m(kernel1),110m(rootfs1),15m(kernel2),-(rootfs2) earlyprintk=serial ethaddr=5c:6a:80:04:48:7a

[    3.947011] mvneta f1070000.ethernet eth0: Using random mac address c2:c7:99:77:36:a6

Or does my current U-Boot version not support fixed MAC address?:
U-Boot 2013.01-svn48206 (Dec 03 2015 - 02:50:37) Marvell version: 2014_T3.0p6

2. At the moment I boot the NAS326 via a USB stick. I would like to boot via the internal hard drive, is there a trick? The problem is that with the SATA init after the command "scsi init" in U-Boot nothing happens, also ctrl-c does not cancel the command and I have to cold boot the NAS326:

Marvell>> mw.l f1018100 20420000;
Marvell>> mw.l f1018140 003ca800; (after this command I hear the hard disk spinning up)
Marvell>> scsi init
AHCI init for unit0
Target spinup took 0 ms.
Target spinup took 0 ms.

Error: SCSI Controller(s) 1B4B:9215 1B4B:9235 not found
scanning bus for devices...

3. I'm not sure if this was already under the old kernel, but I see constant disk access, every second the HDD LED on the NAS lights up. With iotop I could find out that the following processes are responsible for the access:

kworker/0:2-events_power_efficient
kworker/0:2-events
kworker/0:2-events_freezable_power
kworker/0:2-mm_percpu_wq
jbd2/sda2-8
jbd2/sdc1-8
jbd2/sdd1-8
jbd2/sda3-8
jbd2/sdb1-8

How can I change this? I need a NAS that goes to sleep at night. How can I minimize the hard disk access?

I have attached the bootlog and environment variables to this post.

Thanks for your help in advance!

Regards,
Peter



Edited 1 time(s). Last edit at 08/31/2021 06:35AM by ptosch.

Peter,

1. Yes, it is a know problem with this stock u-boot. In fact, it is for all MVEBU boxes that have similar u-boot (except the Thecus N2350). The MAC address does not get passed to the kernel correctly. So we have a work around, as noted in the release thread.

Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 (10 Sep 2019)

Quote

Note3:

To enable the network dynamic IP to stay consistent after each reboot, and also for faster boot. In this rootfs, a script is executed during kernel booting (in /etc/rc.local), to detect if a local MAC address was assigned during boot, and then set the persistent MAC address to what is currently defined in u-boot env ethaddr.

/root/set_persistent_mac_address

You can also set the MAC address in /etc/network/interfaces. However, this alternative workaround fix it to the rootfs (if you have a 2nd box and clone this rootfs, you will then have to remember to change it, while the script just reads from the env).

2. The HDD LED lights up seems to be a quirk with cpu_frequency governor. This is a way to set the power saving, or performance CPU mode of governor. During power saving governor, the governor sets CPU speed to a lower frequency to save power.

The LED is ligthed up, but there is no actual disk access. As you already can tell, the kworkers are running to monitor the box only. To verify this, run iotop for a while and observe the LED when it lights up.

iotop -o -b -qqq

And as long as you don't see the disk devices /dev/sdax or /dev/sdbx,... appear on the output, then you know there is no disk access. And if you put the HDD to sleep as described here, then you can be sure that it is sleeping when there is no access.

I need to investigate this to see how I can turn off the LED for this activity, and only let the actual disk read/write bink the LEDs.

======

Also, if you run HDD rootfs, then there will be disk access from time to time. The HDD can only sleep when you run USB rootfs. Or if you have 2 HDDs, then you can only make the 2nd one go to sleep if the 1st one is rootfs.

To transition from the USB rootfs to HDD rootfs, clone the rootfs:
https://forum.doozan.com/read.php?2,12096,24034#msg-24034

And then follow the NAS326 installation instruction section C (Instruction for booting the NAS326 with rootfs on internal HDD) to adjust u-boot envs.

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

Hello,

thanks for your hints Bodhi.

I was aware of the solution via /root/set_persistent_mac_address or /etc/network/interfaces, but that means that the random MAC always reports first unfortunately, and then the HW Mac is set. I didn't realize until today that there is no separate U-Boot for NAS326, only the "stock U-Boot". I think I will use macchanger for my existing system, then I do not have to reinstall the rootfs.

About the boot problem over SATA: I tried a total of five 3.0TB HDDs, with none of them "scsi init" works. But all HDDs smaller than 3.0TB are recognized and you can boot via SATA. So the "stock U-Boot" doesn't seem to cope with disks =>3.0TB.

I'll probably use a USB rootfs so the internal HDDs can go to sleep, then there is finally silence in the room.

Anyway: by updating to kernel 5.13 I have a very current system with "Devuan chimaera", that is very nice!

And yet: is there a more modern NAS that is more powerful than NAS326 and works well with Linux?

Peter

Peter,

> I was aware of the solution via
> /root/set_persistent_mac_address or
> /etc/network/interfaces, but that means that the
> random MAC always reports first unfortunately, and
> then the HW Mac is set. I didn't realize until
> today that there is no separate U-Boot for NAS326,
> only the "stock U-Boot". I think I will use
> macchanger for my existing system, then I do not
> have to reinstall the rootfs.

macchanger does not work nicely. I've tried macchanger solution but realized that it it is not as good as the script.


> About the boot problem over SATA: I tried a total
> of five 3.0TB HDDs, with none of them "scsi init"
> works. But all HDDs smaller than 3.0TB are
> recognized and you can boot via SATA. So the
> "stock U-Boot" doesn't seem to cope with disks
> =>3.0TB.

Ah. That is to be expected. I don't recall this stock u-boot can boot 3TB or above.

> I'll probably use a USB rootfs so the internal
> HDDs can go to sleep, then there is finally
> silence in the room.

Make sure you do this to avoid wearing out the USB prematurely.

> Anyway: by updating to kernel 5.13 I have a very
> current system with "Devuan chimaera", that is
> very nice!

I saw that :)

>
> And yet: is there a more modern NAS that is more
> powerful than NAS326 and works well with Linux?
>

As far as low cost NAS is concerned, the Thecus N2350 is a nice box (dual core Armada 385, 1GB RAM, 2 HDD bays). I have this box and support it here.

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