SATA Karte Marvell 88SE9230 Chipsatz mit 0.9.16

[FrankM]

Ich habe nach langer Zeit vor, mein NAS mal umzubauen, auf andere HDDs usw. Dafür möchte ich nun auf Debian Buster 10.1 wechseln, weil dann habe ich alles gleich

Hardware

• ROCKPro64 2GB RAM
• PCIe SATA-Karte Marvell 88SE9230
• USB3 SSD T5
• 2 * 4TB HDD 3,5Zoll
• Netzteil 5A

Software

• Kamlis 0.9.16 https://github.com/ayufan-rock64/linux-build/releases/tag/0.9.16

Ok, den Nachmittag mit Testen verbracht, aber irgendwie ging nichts.....

Dann habe ich die alten Forenbeiträge überall noch mal nachgelesen und bin fündig geworden.

pci=nomsi

Quelle: https://forum.pine64.org/showthread.php?tid=6496&pid=41068#pid41068

Ok, dann mal

nano /boot/extlinux/extlinux.conf

und den Parameter ergänzen.

 timeout 10
 menu title select kernel
 
 label kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339
     kernel /boot/vmlinuz-4.4.197-1236-rockchip-ayufan-g30faab37e339
     initrd /boot/initrd.img-4.4.197-1236-rockchip-ayufan-g30faab37e339
     devicetreedir /boot/dtbs/4.4.197-1236-rockchip-ayufan-g30faab37e339
     append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 pci=nomsi root=LABEL=linux-root rootwait rootfstype=ext4
 
 label kernel-4.4.197-1236-rockchip-ayufan-g30faab37e339-memtest
     kernel /boot/vmlinuz-4.4.197-1236-rockchip-ayufan-g30faab37e339
     initrd /boot/initrd.img-4.4.197-1236-rockchip-ayufan-g30faab37e339
     devicetreedir /boot/dtbs/4.4.197-1236-rockchip-ayufan-g30faab37e339
     append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 pci=nomsi root=LABEL=linux-root rootwait rootfstype=ext4 memtest

Neustarten und BÄM, da sind die Festplatten.

root@rockpro64:/# blkid
/dev/sda1: UUID="4dd45131-bf78-4a23-ad29-af1b24284ca0" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="e396d30e-9690-4a81-9386-eb2c1e490cbc"
/dev/sda2: UUID="a8234184-3c6a-44d1-a6a3-d06d0baedfcc" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="0736407d-fce2-4b46-b957-a0a472f4ee9b"
/dev/sdb1: UUID="857a73ca-199f-4e04-9651-088963e29fae" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="66b1780d-f9d5-4baa-af96-6a90d3d29a58"
/dev/sdb2: UUID="ed78c5ce-5bc9-49aa-9bc7-000771610940" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="8cc27a88-56f6-4ac3-8d04-78e9917678b7"
/dev/sdc1: PARTLABEL="loader1" PARTUUID="00ceceb1-4785-49c2-aa5e-aff2349ae71c"
/dev/sdc2: PARTLABEL="reserved1" PARTUUID="4eedf41c-4c66-4933-8103-bc0f741df511"
/dev/sdc3: PARTLABEL="reserved2" PARTUUID="b0ac44b9-ecc9-41a5-b631-97f0de390ae8"
/dev/sdc4: PARTLABEL="loader2" PARTUUID="ecd5a0ea-e1ec-4b2f-97c4-8304f1e65d37"
/dev/sdc5: PARTLABEL="atf" PARTUUID="2f1e7f3b-fc55-46de-88c8-874bd5916d6c"
/dev/sdc6: SEC_TYPE="msdos" LABEL_FATBOOT="boot" LABEL="boot" UUID="F2E0-8793" TYPE="vfat" PARTLABEL="boot" PARTUUID="481a9a23-46f1-46fb-a09d-bf97d4fda4df"
/dev/sdc7: LABEL="linux-root" UUID="4e669080-ae10-474e-9e35-208828cca60a" TYPE="ext4" PARTLABEL="root" PARTUUID="736d3075-8cc6-4b21-9e5e-8d67a7d67624"

sda und sdb sind zwei 4TB Platten aus meinem lokalen Proxmox. sdc ist eine T5 SSD an USB3, die das System beeinhaltet. Der uboot ist im SPI.

Vorher hatte ich die ganze Zeit nur den SATA-Adapter gesehen.

root@rockpro64:/# lspci -nn
00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port [1d87:0100]
01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller [1b4b:9230] (rev 11)

Wir können also mittlerweile auch mit dem 4.4er Kernel die SATA-Karte nutzen, vorher ging das ja nur mit dem Mainline!? Übrigens, der letzte Mainlinekernel bootet hier nicht mehr, egal was ich mache!???

[kosmonaut pirx]

@FrankM Mainline hat "damals" vor vier wochen bei mir 5min gebraucht zum booten. Dachte "damals" das board hängt und hatte den versuch bereits abgeschrieben, aber lief dann

[FrankM]

Danke. Ich habe gestern so viel probiert, das ich meine mich erinnern zu können das es von selber neugestartet hat. Ist aber aktuell auch nicht so wichtig für mich. Hab jetzt 4 Platten an dem Adapter. Einmal alt, einmal neu.

Weiter gehts...

[FrankM]

Ich hole mal was aus, bevor sich jemand fragt, wie man 4 HDDs am ROCKPro64 betreiben kann....

HDDS

• 2 * 4TB 3,5 Zoll HDD
• 2 * 1,8 TB 2,5 Zoll HDD

Die 1,8er sind das alte NAS, die 4TB sollen das neue NAS werden. Alle vier hängen am PCIe SATA Adapter

PCIe SATA

root@rockpro64:~# lspci -nn
00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port [1d87:0100]
01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller [1b4b:9230] (rev 11)

HDDs

root@rockpro64:~# blkid
/dev/sda1: UUID="dbbdbbf3-d57a-f8f0-158a-95a090318787" UUID_SUB="f686690c-7820-6177-ff0d-b49d4b6ee162" LABEL="rockpro64:0" TYPE="linux_raid_member" PARTUUID="4969cca5-813b-744b-8be8-267b8dce3a64"
/dev/sdb1: UUID="dbbdbbf3-d57a-f8f0-158a-95a090318787" UUID_SUB="a4e46abc-0745-812d-453a-5900c93be9e6" LABEL="rockpro64:0" TYPE="linux_raid_member" PARTUUID="bad3f3c0-1c93-8c48-a236-2d36f561208d"
/dev/md0: UUID="65d12371-db28-405c-91c7-8ee644e5cbaa" TYPE="ext4"
/dev/sdc6: SEC_TYPE="msdos" LABEL_FATBOOT="boot" LABEL="boot" UUID="F2E0-8793" TYPE="vfat" PARTLABEL="boot" PARTUUID="481a9a23-46f1-46fb-a09d-bf97d4fda4df"
/dev/sdc7: LABEL="linux-root" UUID="4e669080-ae10-474e-9e35-208828cca60a" TYPE="ext4" PARTLABEL="root" PARTUUID="736d3075-8cc6-4b21-9e5e-8d67a7d67624"
/dev/sdd1: UUID="f038170b-1f1c-4155-9986-0375a5a7ba1d" TYPE="crypto_LUKS" PARTUUID="8af0c936-3f0e-bd45-ac79-6008dbec2a5e"
/dev/sde1: UUID="31cfceec-8f5a-4df0-8228-17467035c50b" TYPE="crypto_LUKS" PARTUUID="13a5b880-8c52-004f-bb79-d5075ec71052"
/dev/mapper/raid_pool0: UUID="33ac7964-473f-e590-3682-dd85a979b336" UUID_SUB="7b830f36-7f19-1494-57bb-bcb6f650958f" LABEL="rockpro64v_2_1:0" TYPE="linux_raid_member"
/dev/md127: UUID="722c7c4c-8bfe-4d49-ac10-6b32780cb2e6" TYPE="ext4"
/dev/mapper/raid_pool1: UUID="33ac7964-473f-e590-3682-dd85a979b336" UUID_SUB="7d7714c3-5553-1d84-2b1b-5d9a63470187" LABEL="rockpro64v_2_1:0" TYPE="linux_raid_member"
/dev/sdc1: PARTLABEL="loader1" PARTUUID="00ceceb1-4785-49c2-aa5e-aff2349ae71c"
/dev/sdc2: PARTLABEL="reserved1" PARTUUID="4eedf41c-4c66-4933-8103-bc0f741df511"
/dev/sdc3: PARTLABEL="reserved2" PARTUUID="b0ac44b9-ecc9-41a5-b631-97f0de390ae8"
/dev/sdc4: PARTLABEL="loader2" PARTUUID="ecd5a0ea-e1ec-4b2f-97c4-8304f1e65d37"
/dev/sdc5: PARTLABEL="atf" PARTUUID="2f1e7f3b-fc55-46de-88c8-874bd5916d6c"

Was Wichtiges! Die zwei 4 TB Platten hängen am Netzteil vom ROCKPro64. Die zwei 1,8 TB Platten hängen an einem handelsüblichen PC-Netzteil, was hier für solche Zwecke rumliegt. Ich gehe davon aus, das das 12V/5A Netzteil von Pine64 damit gut ausgelastet ist. Das werde ich nach dem Zusammenbau des NAS in das Gehäuse nochmal messen.

[FrankM]

Und noch was zur Geschwindigkeit.

4 TB WD40EZRZ 3,5 Zoll

root@rockpro64:/mnt/nas# iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 64 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sun Nov  3 09:50:23 2019

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 102400 kB
	Record Size 4 kB
	Record Size 16 kB
	Record Size 512 kB
	Record Size 1024 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    26087    32115    46181    45345     1029     1781                                                          
          102400      16    47864    54219   111342   110764     3948     7042                                                          
          102400     512    87792   102624   146630   158597    61571    99343                                                          
          102400    1024    93089   119904   147041   171560    76250   106159                                                          
          102400   16384   111010   124798   152106   168072   152621   138277  

Soll lt. Datenblatt ca. 150MB/s machen. Sollte passen.

1,8 TB Barracuda 2,5 Zoll (LUKS verschlüsselt)

root@rockpro64:/mnt/nas_alt# iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 64 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sun Nov  3 09:54:58 2019

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 102400 kB
	Record Size 4 kB
	Record Size 16 kB
	Record Size 512 kB
	Record Size 1024 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     8041     7151     9069    18376     1484      675                                                          
          102400      16     6137    10301    40712    61916     5098     4462                                                          
          102400     512    35520    59081     8749    37416    55809    12226                                                          
          102400    1024    31658    40382    50131   105000    60191    51150                                                          
          102400   16384    55941    51903    85128   109118    35358    37658                                                          

iozone test complete.

So mechanische Platten sind ja irgendwie aus einer anderen Welt!? Aber als Datengrab bevorzuge ich im Moment noch mechanische Platten. Das wird sich sicherlich in Zukunft ändern.

[FrankM]

Aktueller Stromverbrauch, nachdem ich das NAS wieder in sein Gehäuse eingebaut habe, so zwischen 15 - 17 Watt.
Wenn die zwei 4TB Platten über hdparm ausgeschaltet sind, liegt der Verbrauch bei 10,8 Watt.

Aktuell mit den 2 * 4TB 3,5Zoll.

[FrankM]

Bei der heutigen Einrichtung des NAS zur Überwachung durch checkmk ist mir ein Fehler aufgefallen.

Man bekommt eine rote Warnung über

CRIT - 85 services in total, 1 service failed (sdio-hciattach)CRIT, Service check_mk@3-192.168.3.207:6556-192.168.3.213:47140 activating for: 0.00 s, 5 disabled services

Wer checkmk nutzt weiß, das rote meldungen nasse Hände produzieren Also, weg damit.

sdio.hciattach sollte der Bluetooth Teil des ROCKPro64 sein, der aktuell nicht verbaut ist. Das WLan/BT Modul beim ROCKPro64 wird ja gesteckt.

Dann schalten wir den Dienst mal aus, kann man ja dann bei Bedarf einfach wieder aktivieren.

 root@rockpro64:/etc/systemd# systemctl disable sdio-hciattach
 Removed /etc/systemd/system/multi-user.target.wants/sdio-hciattach.service.

Rote Meldung weg. Alles wieder gut

[FrankM]

Gestern hat Kamil einen neuen Kernel released, so das ich das heute mal auf dem NAS probiert habe. Durch den Boot von der USB-SSD sollten die Pfade ja alle passen und man problemlos den Kernel updaten können.

 root@rockpro64:/usr/local/sbin# df -h
 Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
 udev            992M       0  992M    0% /dev
 tmpfs           199M    5,5M  194M    3% /run
 /dev/sdc7       459G    3,3G  437G    1% /
 tmpfs           995M       0  995M    0% /dev/shm
 tmpfs           5,0M    4,0K  5,0M    1% /run/lock
 tmpfs           995M       0  995M    0% /sys/fs/cgroup
 /dev/sdc6       112M    4,0K  112M    1% /boot/efi
 /dev/md0        3,6T    485G  3,0T   14% /mnt/nas
 tmpfs           199M       0  199M    0% /run/user/1000

Gut, /boot liegt auf der USB-SSD. Also, wie bekannt, den Kernel heruntergeladen und installiert. Nach dem Neustart geht nix Mittels HDMI Monitor angeschlossen um den Fehler sehen zu können, da macht es auch schon Klick. Der Parameter

pci=nomsi

ist durch das Kernel-Update überschrieben worden. Ich hatte dann die USB-SSD ausgebaut und das Problem am lokalen Rechner gelöst. Aber, man ist ja faul.....;)

Da es überschrieben wird, müssen auch irgendwo die Informationen dazu liegen.......

/usr/local/sbin/update-extlinux.sh

Da ist das File, was Kamil dafür angelegt hat.

#!/bin/bash

TIMEOUT=""
DEFAULT=""
APPEND="rw"
APPEND="$APPEND panic=10"
APPEND="$APPEND init=/sbin/init"
APPEND="$APPEND coherent_pool=1M"
APPEND="$APPEND ethaddr=\${ethaddr} eth1addr=\${eth1addr} serial=\${serial#}"
APPEND="$APPEND cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 pci=nomsi"
[..........gekürzt.........]

Hier seht ihr das File schon mit meiner Änderung, in der Hoffnung das es dann beim nächsten Mal ohne Probleme funktioniert. Bleibt nur noch das Problem, wann ändert Kamil das File, weil dann ist die Änderung wieder weg!?!?