Nobby42
-
Posts
18 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Nobby42
-
-
Hello,
I found a problem with the CPU GOVERNOR.
ENABLE=true MIN_SPEED=600000 #MAX_SPEED=2016000 MAX_SPEED=1800000 # performance i firefox preferences i 6 # GOVERNOR=conservative # GOVERNOR=ondemand GOVERNOR=performanceWhen I set the GOVERNOR set to "performance" it looks like that the NANOPI run stable.
In MODE "ondemand" and "conservative" the PI crashes after a few hours.
I do not have enough experience to play with the GOVERNOR parameters to get a stable setting in USER mode.
-
Now I have get the next crash processes (see the log).
Kernel 5.4.13
CPU 1,42/1,8Ghz governor is set to "conservative"
What I doing. I open the webgui from a nextcloud (docker) installation.
-
6 hours ago, Noboot said:
I've seem to have the same when copying data.
I was using a sata had with an hdd and a usb3 disk.
When copying files it fails.
Since I'm new to this any help to get this resolved is welcome.
--> Linux nanopim4v2 5.4.7-rockchip64 #19.11.5 SMP PREEMPT Wed Jan 1 09:39:17 CET 2020 aarch64 GNU/Linux
Log that I found
Jan 17 12:54:19 nanopim4v2 kernel: [21912.080372] Modules linked in: hci_uart bluetooth cpufreq_userspace zstd zram dw_hdmi_i2s_audio rockchip_rga brcmfmac brcmutil v4l2_mem2mem videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_common cfg80211 videodev rfkill fusb302 mc tcpm typec panfrost gpu_sched rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi ip_tables ipv6 crc_ccitt uas raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod phy_rockchip_typec phy_rockchip_pcie dwmac_rk stmmac_platform stmmac phylink Jan 17 12:54:19 nanopim4v2 kernel: [21912.088969] CPU: 5 PID: 273 Comm: kswapd0 Not tainted 5.4.7-rockchip64 #19.11.5 Jan 17 12:54:19 nanopim4v2 kernel: [21912.091123] Hardware name: FriendlyElec NanoPi M4 Ver2.0 (DT) Jan 17 12:54:19 nanopim4v2 kernel: [21912.093184] pstate: 40000005 (nZcv daif -PAN -UAO) Jan 17 12:54:19 nanopim4v2 kernel: [21912.095088] pc : __call_rcu+0x2c/0x1c0 Jan 17 12:54:19 nanopim4v2 kernel: [21912.096945] lr : call_rcu+0x10/0x18 Jan 17 12:54:19 nanopim4v2 kernel: [21912.098769] sp : ffff800011e9b8c0 Jan 17 12:54:19 nanopim4v2 kernel: [21912.100562] x29: ffff800011e9b8c0 x28: 00000000000000b2 Jan 17 12:54:19 nanopim4v2 kernel: [21912.102569] x27: ffff0000ee567c40 x26: 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.104553] x25: 0000000000000000 x24: 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.106518] x23: ffff8000105d8618 x22: ffff0000ed9ac1d8 Jan 17 12:54:19 nanopim4v2 kernel: [21912.108482] x21: ffff800010dbfe60 x20: 0000000080000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.110455] x19: 0000000000000000 x18: 0000000000000001 Jan 17 12:54:19 nanopim4v2 kernel: [21912.112396] x17: 0000000000000000 x16: 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.114370] x15: ffffffffffffffff x14: ffff80001135b508 Jan 17 12:54:19 nanopim4v2 kernel: [21912.116348] x13: fffffe0002d60540 x12: 0000000000000001 Jan 17 12:54:19 nanopim4v2 kernel: [21912.118310] x11: 0000000000000000 x10: 00000000000009d0 Jan 17 12:54:19 nanopim4v2 kernel: [21912.120259] x9 : ffff800011e9b8f0 x8 : 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.122214] x7 : 0000000000000001 x6 : 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.124095] x5 : 0000000000000001 x4 : ffff0000ee567800 Jan 17 12:54:19 nanopim4v2 kernel: [21912.125973] x3 : ffff0000edb70c70 x2 : 0000000000000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.127822] x1 : ffff8000105d8618 x0 : 0000000080000000 Jan 17 12:54:19 nanopim4v2 kernel: [21912.129690] Call trace: Jan 17 12:54:19 nanopim4v2 kernel: [21912.131269] __call_rcu+0x2c/0x1c0 Jan 17 12:54:19 nanopim4v2 kernel: [21912.132934] call_rcu+0x10/0x18 Jan 17 12:54:19 nanopim4v2 kernel: [21912.134582] security_inode_free+0x48/0x58 Jan 17 12:54:19 nanopim4v2 kernel: [21912.136306] __destroy_inode+0xb0/0x218 Jan 17 12:54:19 nanopim4v2 kernel: [21912.138016] destroy_inode+0x2c/0x70 Jan 17 12:54:19 nanopim4v2 kernel: [21912.139725] evict+0x104/0x168 Jan 17 12:54:19 nanopim4v2 kernel: [21912.141386] iput+0xd8/0x190 Jan 17 12:54:19 nanopim4v2 kernel: [21912.143010] dentry_unlink_inode+0x114/0x160 Jan 17 12:54:19 nanopim4v2 kernel: [21912.144727] __dentry_kill+0xc0/0x1c0 Jan 17 12:54:19 nanopim4v2 kernel: [21912.146396] shrink_dentry_list+0x7c/0xd8 Jan 17 12:54:19 nanopim4v2 kernel: [21912.148088] prune_dcache_sb+0x5c/0x88 Jan 17 12:54:19 nanopim4v2 kernel: [21912.149767] super_cache_scan+0xcc/0x160 Jan 17 12:54:19 nanopim4v2 kernel: [21912.151433] do_shrink_slab+0x134/0x248 Jan 17 12:54:19 nanopim4v2 kernel: [21912.153082] shrink_slab+0xb4/0x2a8 Jan 17 12:54:19 nanopim4v2 kernel: [21912.154701] shrink_node+0xc0/0x468 Jan 17 12:54:19 nanopim4v2 kernel: [21912.156292] balance_pgdat+0x2c8/0x540 Jan 17 12:54:19 nanopim4v2 kernel: [21912.157926] kswapd+0x1c4/0x370 Jan 17 12:54:19 nanopim4v2 kernel: [21912.159511] kthread+0x120/0x128 Jan 17 12:54:19 nanopim4v2 kernel: [21912.161065] ret_from_fork+0x10/0x18 Jan 17 12:54:19 nanopim4v2 kernel: [21912.164486] ---[ end trace 04aebd1132e57ca5 ]--- root@nanopim4v2:~# ~~~Since I set the CPU frequency to 1.4/1.8Ghz I have no problems.
Look at this topic -
6 hours ago, TCB13 said:
With the 5.x kernel by default the CPU seems to upscale up to 2.02GHz, with the 4.x kernel it only goes up to 1.8Ghz. If I understood you correctly, you think that since my 5.x kernel uses a higher clock it just crashes due to lack of power. That's interesting and would mean that the new kernel isn't broken at all. It would also explain why it reboots without logs.
What power supply are you using? and what would you recommend to run at 2.2 without crashes?
What do you think about this @piter75?
It was the same with me, too. CPU message on the console and nothing works. I use the 5.4.8 kernel.
Currently I use a power supply with 5.3V/4A on pin4/6https://www.amazon.de/gp/product/B01HRR9GY4/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
But I'm not entirely satisfied with that either.
I am currently preparing a rack mounting of the NanoPi and will then use this power supply.
https://www.meanwell.com/webapp/product/search.aspx?prod=RS-25
That's stable at 5A.
-
On 1/16/2020 at 1:58 AM, TCB13 said:
Hello guys,
V2 buster image, kernel 5.4 from an NVMe drive. It works mostly fine but I've been having a consistent issue with copying directories with large files from a USB 3 drive to the internal NVMe. After `cp -r` the green LED of the board stops flashing and it reboots by itself. Unfortunately I can't get logs after the reboot so I don't know how to post more info about this.
I never had this issue with the original board with the same USB3 ASM1051E SATA 6Gb/s bridge.
Hi,
I have had formative experience with the NanoPI M4v2..
First, you need a real power supply. The Rasbberry 4 power supply for example breaks down when using a NMVe and a SSD, at high load, to below 5V (approx. 4.8V - 4.7V).
2. the CPU frequency. I think the 1.5/2Ghz is too much. I have had several crashes. For example the NanoPi crashes when transferring large amounts of data, sometimes processes (kworker, sshd, ...) just crashed and sometimes the NanoPi just stopped. Since I use the frequency to 1.4/1.8Ghz and a similar power supply, it looks like the NanoPI runs stable with NMVe and USB SSD. Currently I am using the NanoPi as a file server, MQTT Broker and nextcloud server and haven't had any crashes for 4 days. -
Hi,
when I used rsync to copy several GB of data from the NMV3 to a USB SSD, the SSHD crashed.
[96500.101926] ------------[ cut here ]------------
[96500.102376] kernel BUG at arch/arm64/kernel/traps.c:405!
[96500.102858] Internal error: Oops - BUG: 0 [#2] PREEMPT SMP
[96500.103343] Modules linked in: sg uas hci_uart bluetooth cpufreq_userspace zstd zram dw_hdmi_i2s_audio rockchip_rga v4l2_mem2mem videobuf2_dma_sg panfrost fusb302 tcpm videobuf2_memops gpu_sched typec videobuf2_v4l2 videobuf2_common videodev mc brcmfmac brcmutil cfg80211 rfkill rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi ip_tables ipv6 crc_ccitt phy_rockchip_typec phy_rockchip_pcie dwmac_rk stmmac_platform stmmac phylink
[96500.106655] CPU: 3 PID: 14434 Comm: sshd Tainted: G D W 5.4.8-rockchip64 #19.11.7
[96500.107413] Hardware name: FriendlyElec NanoPi M4 Ver2.0 (DT)
[96500.107921] pstate: 00000005 (nzcv daif -PAN -UAO)
[96500.108354] pc : do_undefinstr+0x2e4/0x310
[96500.108718] lr : do_undefinstr+0x1dc/0x310
[96500.109081] sp : ffff8000130237d0
[96500.109375] x29: ffff8000130237d0 x28: ffff00003a6ae200
[96500.109846] x27: 00000000327efa40 x26: 000057c3dbe99326
[96500.110315] x25: 0000000000000010 x24: 0000000000000000
[96500.110785] x23: 0000000040000005 x22: ffff800010c89364
[96500.111255] x21: ffff800013023970 x20: ffff800013023830
[96500.111724] x19: ffff80001136b508 x18: 0000000000000000
[96500.112194] x17: 0000000000000000 x16: 0000000000000000
[96500.112664] x15: 0000000000000000 x14: 7f6754efac8b8b63
[96500.113133] x13: 64022bac43b4cbe6 x12: 000000000003d440
[96500.113603] x11: 0000000000000074 x10: 0000000000000001
[96500.114073] x9 : 0000000093637393 x8 : 0000000000000000
[96500.114542] x7 : 0000000000000001 x6 : 0000000000000000
[96500.115012] x5 : 00000000d5300000 x4 : ffff800011381370
[96500.115481] x3 : 0000000000000001 x2 : 0000000000000000
[96500.115951] x1 : ffff00003a6ae200 x0 : 0000000040000005
[96500.116422] Call trace:
[96500.116644] do_undefinstr+0x2e4/0x310
[96500.116978] el1_undef+0x10/0x84
[96500.117272] __ip_queue_xmit+0x3c/0x390
[96500.117615] ip_queue_xmit+0x10/0x18
[96500.117937] __tcp_transmit_skb+0x4b0/0xae0
[96500.118310] tcp_write_xmit+0x39c/0x1080
[96500.118659] __tcp_push_pending_frames+0x38/0xc0
[96500.119067] tcp_push+0x114/0x160
[96500.119364] tcp_sendmsg_locked+0xab4/0xbe8
[96500.119735] tcp_sendmsg+0x34/0x58
[96500.120041] inet_sendmsg+0x40/0x68
[96500.120353] sock_write_iter+0x8c/0xe8
[96500.120689] new_sync_write+0x100/0x180
[96500.121028] __vfs_write+0x2c/0x40
[96500.121332] vfs_write+0xb0/0x1d0
[96500.121627] ksys_write+0x64/0xe8
[96500.121923] __arm64_sys_write+0x18/0x20
[96500.122273] el0_svc_common.constprop.1+0x88/0x178
[96500.122699] el0_svc_handler+0x20/0x80
[96500.123032] el0_svc+0x8/0xc
[96500.123293] Code: f9401bf7 17ffff7d a9025bf5 f9001bf7 (d4210000)
[96500.123833] ---[ end trace 4a19b31e1f6dad94 ]---
It is a kernel problem?
-
On 1/4/2020 at 2:24 PM, Igor said:
@Nobby42 Welcome to add it to our defaults:
https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L299It can take some time before this gets upstream.
Hi,
I have no experience with GitHub, but I'll look into it. It may take a while. -
36 minutes ago, piter75 said:
Case closed... or at least worked around
Yes ;-) Thanks for your support.
-
50 minutes ago, piter75 said:
Do I understand correctly that you first booted from SD with eMMC inserted and then chosen an option "Boot from eMMC - system on SATA" in "nand-sata-install"?
Can you try doing it in two separate steps?
1. Install from SD to eMMC (option "Boot from eMMC - system on eMMC" in nand-sata-install) or write image straight to eMMC with adapter
2. Boot from eMMC (remember to remove SD card ;-)) and move rootfs to SATA (option "Boot from eMMC - system on SATA" in nand-sata-install)
I will verify the SD straight to eMMC with SATA procedure on my side.
Hi piter75,
I think I found the problem. The UAS.
https://unix.stackexchange.com/questions/441668/debian-usb3-hdd-uas-i-o-errors
After I add the USB-ID for my adapter in the armbianEnv.txt the SSD was black list für the UAS and the board booting with the rootfs on the SSD.
[ 56.463044] hub 8-1:1.0: USB hub found
[ 56.463741] hub 8-1:1.0: 4 ports detected
[ 57.026120] usb 8-1.2: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 57.047008] usb 8-1.2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 57.047771] usb 8-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 57.048436] usb 8-1.2: Product: ASM1153USB3.0TOSATA
[ 57.048886] usb 8-1.2: Manufacturer: ASM1153USB3.0TOSATA
[ 57.049374] usb 8-1.2: SerialNumber: 123456789019
[ 57.051688] usb 8-1.2: UAS is blacklisted for this device, using usb-storage instead
[ 57.052403] usb-storage 8-1.2:1.0: USB Mass Storage device detected
[ 57.053572] usb-storage 8-1.2:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 57.054428] scsi host0: usb-storage 8-1.2:1.0
[ 57.060247] usbcore: registered new interface driver uas
[ 58.058774] scsi 0:0:0:0: Direct-Access ASM1153U ASM1153USB3.0TOS 0 PQ: 0 ANSI: 6
[ 58.062417] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[ 58.064363] sd 0:0:0:0: [sda] Write Protect is off
[ 58.065331] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 58.097560] sda: sda1
[ 58.104521] sd 0:0:0:0: [sda] Attached SCSI disk
-
15 hours ago, piter75 said:
Happy New Year to you too!
I see that you used a Armbian's "nand-sata-install" way to install root to SSD. It looks good.
I asked about UUID because I thought that maybe you used some manual steps to do it.
I grabbed old EVO 850 drive and really old 2.5" usb enclosure and did the same procedure.
It works fine:
[ 50.698560] usb 7-1.3: new high-speed USB device number 3 using xhci-hcd [ 50.849750] usb 7-1.3: New USB device found, idVendor=04fc, idProduct=0c25, bcdDevice= 1.03 [ 50.849766] usb 7-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 50.849779] usb 7-1.3: Product: USB to Serial-ATA bridge [ 50.849791] usb 7-1.3: Manufacturer: Sunplus Technology Inc. [ 50.849802] usb 7-1.3: SerialNumber: Samsung XXXXXXXXXXXXX [ 50.854027] usb-storage 7-1.3:1.0: USB Mass Storage device detected [ 50.854825] scsi host0: usb-storage 7-1.3:1.0 [ 50.862064] usbcore: registered new interface driver uas [ 50.974811] usb 8-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 50.996734] usb 8-1: New USB device found, idVendor=2109, idProduct=0817, bcdDevice= 0.50 [ 50.996753] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 50.996768] usb 8-1: Product: USB3.0 Hub [ 50.996783] usb 8-1: Manufacturer: VIA Labs, Inc. [ 51.019993] hub 8-1:1.0: USB hub found [ 51.020208] hub 8-1:1.0: 4 ports detected [ 51.879358] scsi 0:0:0:0: Direct-Access Samsung SSD 850 EVO 500G B PQ: 0 ANSI: 2 [ 51.881411] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) [ 51.883802] sd 0:0:0:0: [sda] Write Protect is off [ 51.883819] sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00 [ 51.885885] sd 0:0:0:0: [sda] No Caching mode page found [ 51.885899] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 51.914578] sda: sda1 [ 51.923484] sd 0:0:0:0: [sda] Attached SCSI disk [ 52.947291] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
root@nanopim4v2:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk └─sda1 8:1 0 24G 0 part / mmcblk1 179:0 0 29.7G 0 disk └─mmcblk1p1 179:1 0 29.4G 0 part /media/mmcboot zram0 253:0 0 50M 0 disk /var/log zram1 253:1 0 1G 0 disk [SWAP]
Of course it does not prove anything as my enclosure is using usb-storage mode and not uas
Hi piter75,
thanks for your support.
I ran some tests yesterday. During the last test I made a mistake and forgot to remove the SD card and the Pi boots with all memory media. After booting I saw that the ROOTFS is on the device /dev/sda1. Why?
It looks like it booted from a mix of SD and EMMC and rootfs on sda1lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
└─sda1 ext4 b1a869c6-23b1-4254-b604-6c8e9abe4440 215.3G 1% /
mmcblk2
└─mmcblk2p1 ext4 71e19ca5-088d-4ecb-aa80-97d8e8445f20 13.3G 1% /media/mmcboot
mmcblk2boot0
mmcblk2boot1
mmcblk1
└─mmcblk1p1 ext4 c2a23e0b-b4a8-475a-a890-a9f2f107f46a 13G 9% /media/sd-card
zram0 39.5M 11% /var/log
zram1 [SWAP]
cat /media/mmcboot/boot/armbianEnv.txt
verbosity=7
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-nanopi-m4v2.dtb
rootdev=UUID=b1a869c6-23b1-4254-b604-6c8e9abe4440
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:ucat /media/sd-card/boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-nanopi-m4v2.dtb
rootdev=UUID=c2a23e0b-b4a8-475a-a890-a9f2f107f46a
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:ucat /media/sd-card/etc/fstab
UUID=c2a23e0b-b4a8-475a-a890-a9f2f107f46a / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0
nobby@Viking:~$ ^C
nobby@Viking:~$cat /boot/armbianEnv.txt
verbosity=7
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-nanopi-m4v2.dtb
rootdev=UUID=b1a869c6-23b1-4254-b604-6c8e9abe4440
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:ucat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs defaults,nosuid 0
UUID=71e19ca5-088d-4ecb-aa80-97d8e8445f20 /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1
/media/mmcboot/boot /boot none bind 0 0
UUID=b1a869c6-23b1-4254-b604-6c8e9abe4440 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1Very mysterious.
Here are the armbianmonitor output.
When I boot from emmc I see this error.
MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **** Unable to read "/boot/boot.env" from mmc0:1 **
Something wrong with the emmc?
I have found this topic and will test it today.
-
On 12/31/2019 at 5:36 PM, piter75 said:
Does the expected root partition (/dev/sda1) have the UUID of aeeacfab-958f-4131-b208-c9a6d1e7f2b7?
You can verify it after attaching the drive to device booted with SD or eMMC and using:
lsblk -f
Happy new year.
UUID looks good.
Here they are from the last test.
lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
└─sda1 ext4 5a664488-9c46-46a8-92a8-73127b19c54b 215.3G 1% /media/ssd
mmcblk2
└─mmcblk2p1 ext4 ddceb71a-f588-4aea-bdb0-2fc352dfef3d 13.3G 1% /media/mmc
mmcblk2boot0
mmcblk2boot1
mmcblk1
└─mmcblk1p1 ext4 6afbab68-85eb-40bf-bb45-e469f4b615f5 13G 9% /
zram0 41.7M 7% /var/log
zram1 [SWAP]
cat /media/mmc/boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-nanopi-m4v2.dtb
rootdev=UUID=5a664488-9c46-46a8-92a8-73127b19c54b
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
cat /media/ssd/etc/fstab
# <file system> <mount point> <type> <options> <dump><pass>
tmpfs /tmp tmpfs defaults,nosuid 0 0
UUID=ddceb71a-f588-4aea-bdb0-2fc352dfef3d /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 1
/media/mmcboot/boot /boot none bind 0 0
UUID=5a664488-9c46-46a8-92a8-73127b19c54b / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 1 -
17 hours ago, Nobby42 said:
I also use the NanoPi as a server. Could it possibly be due to the CPU frequency?
The 5.4.6 kernel use 1,5/2Ghz and the 4.4.192 kernel 1,4/1,8Ghz.
I'll test it tomorrow.
The NanoPi don't boot from emmc with roots on SSD with the 5.4.6 kernel. I have attached the boot log. After the Pi found the ssd they do nothing. I have tested variuos SSD. Booting from only SD or only EMMC works fine.
-
On 12/29/2019 at 9:04 PM, piter75 said:
It was not there on rockchip64-current.
I prepared a PR that adds it: https://github.com/armbian/build/pull/1699
I am using similar setup but with NVMe hat and I would call it very stable.
One thing to mention is that I am using it as a server and not a desktop.
I also use the NanoPi as a server. Could it possibly be due to the CPU frequency?
The 5.4.6 kernel use 1,5/2Ghz and the 4.4.192 kernel 1,4/1,8Ghz.
I'll test it tomorrow.
-
@piter75 Thanks. Now the ethernet workes and I can test the legacy kernel. With the 5.4.6 kernel I have a lot of problems. Sometimes the Pi crashes. I cannot verify the reason. I boot the Pi from emmc and rootfs on a SSD.
Looks like a problem with the USB SSD adapter but I am not shure. I use USB adapters with JM567 and ASM1153 chipset. -
Hi,
I work without WiFi.
Regards
Norbert
-
Hi,
I have testet the image with the 5.4.2 kernel. No problems.
Can anyone reproduce the problem with the 4.4.192 kernel?
Kind regards
Norbert
-
Hi,
I have a problem with my NanoPi M4V2 (with Raspberry Pi 4 power supply) and the new Armbian release 19.11.3 (Buster). I can boot the image from SD, eMMC. But when I connect any USB storage (USB-Stick or SSD with USB to SATA) then I have packet lost on the Ethernet connection. Any idea where the problem is?
On the interface I can't see problems.eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.xx.36 netmask 255.255.255.0 broadcast 192.168.42.255
inet6 fd58:xxxx:xxxx:1::1006 prefixlen 64 scopeid 0x0<global>
inet6 fe80::94ad:f6ff:fe0d:757b prefixlen 64 scopeid 0x20<link>
ether 96:ad:f6:0d:75:7b txqueuelen 1000 (Ethernet)
RX packets 1475 bytes 231894 (226.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1088 bytes 129189 (126.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 24
Thanks for your support and kind regards
Norbert
NanoPi M4V2 randomly crashes
in Rockchip
Posted
I have no crash since 5 days.
Welcome to Armbian 20.08.3 Buster with Linux 5.8.10-rockchip64
No end-user support: built from trunk
System load: 20% Up time: 5 days 1:18
Memory usage: 34% of 3.71G Zram usage: 6% of 1.86G IP: 172.21.0.1 192.168.42.31
CPU temp: 48°C Usage of /: 17% of 458G storage/: 6% of 916G storage temp: Always°C
$ cat /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=600000
MAX_SPEED=1800000
GOVERNOR=performance