Skip to content

Mainline Kernel 4.17-rc7

Verschoben Archiv
  • Es ist wahrscheinlich bei Euch nicht anders als bei mir, das man einen möglichst aktuellen Kernel benutzen möchte. Hat wahrscheinlich mit den vielen Sicherheitslücken zu tuen, das man sich einfach sicherer fühlt. Außerdem möchte man ja auch immer die neuesten Features ausprobieren. Gut das Kamil an uns denkt 😉

    Aktuell gibt es dort einen 4.17.0-rc6 Zum Zeitpunkt wo ich das hier tippe, gibt es 4.17-rc7 (vom 27.05.2018). Gut, das kann man noch so eben akzeptieren 🙂 Der Mainline-Kernel soll auf dem ROCKPro64 und dem ROCK64 laufen.

    Ich kann das aktuell nicht testen, da ich den ROCKPro64 eingepackt habe, morgen geht es zum Widerstand ziehen (für die Insider) So bald ich den ROCKPro64 wieder in Betrieb habe, werde ich das ausgiebig testen.

    In der Zwischenzeit was zum Lesen -> https://debian-handbook.info/browse/de-DE/stable/sect.kernel-installation.html

  • Ok, ausprobiert.

    rock64@rockpro64:~$ uname -a
    Linux rockpro64 4.17.0-rc6-1014-ayufan-g5183d4fd6b6a #1 SMP PREEMPT Sun Jun 3 20:54:04 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Alle .deb Files runterladen.

    Dann ein

    sudo dpkg -i *.deb
    

    Dann den ROCKPro64 neustarten.

    Sollte der neue Kernel nicht booten oder Probleme machen, kann man den letzten Kernel benutzen. Dazu muss man den U-Boot überwachen

    U-Boot 2017.09-gec1524d (Jun 03 2018 - 14:57:16 +0000), Build: jenkins-linux-build-rock-64-249
    
    
    
    Model: Pine64 RockPro64    
    DRAM:  3.9 GiB    
    MMC:   sdhci@fe330000: 0, dwmmc@fe320000: 1    
    Card did not respond to voltage select!    
    mmc_init: -95, time 21
    
    *** Warning - No block device, using default environment
    
    
    In:    serial@ff1a0000    
    Out:   serial@ff1a0000    
    Err:   serial@ff1a0000    
    Model: Pine64 RockPro64    
    Net:   eth0: ethernet@fe300000    
    Hit any key to stop autoboot:  0
    
    Card did not respond to voltage select!    
    mmc_init: -95, time 21    
    switch to partitions #0, OK    
    mmc1 is current device    
    Scanning mmc 1:6...    
    Found /extlinux/extlinux.conf    
    Retrieving file: /extlinux/extlinux.conf    
    reading /extlinux/extlinux.conf    
    688 bytes read in 3 ms (223.6 KiB/s)
    
    select kernel    
    1:	kernel-latest    
    2:	kernel-previous
    
    Enter choice: 2  
    2:	kernel-previous
    

    Bei select kernel eine "2" eingeben und die Taste "RETURN" betätigen, möglichst zügig 😉 Danach wird der Alte Kernel geladen.

    Leider geht hier auch kein PCIe. USB3 ist bei mir auch extrem lahm. USB3 geht nicht! Also warten....

  • Die CPU Kerne scheinen mit fester Frequenz zu laufen.

    rock64@rockpro64:/usr/local/sbin$ sudo ./armbianmonitor -m
    Stop monitoring using [ctrl]-[c]
    Stop monitoring using [ctrl]-[c]
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    
    19:54:33: 1800/1416MHz  0.54  15%   0%   0%   0%  14%   0% 44.4°C  0/5
    19:54:39: 1800/1416MHz  0.49   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    19:54:44: 1800/1416MHz  0.45   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    19:54:49: 1800/1416MHz  0.42   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    19:54:54: 1800/1416MHz  0.38   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    19:54:59: 1800/1416MHz  0.35   0%   0%   0%   0%   0%   0% 43.9°C  0/5
    19:55:04: 1800/1416MHz  0.32   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    19:55:09: 1800/1416MHz  0.30   0%   0%   0%   0%   0%   0% 45.6°C  0/5
    

    Dadurch auch eine Stromaufnahme von ca. 4,4 Watt.

    Aber freuen wir uns, das es läuft. Und was mir aufgefallen ist, um Längen stabiler als mit 0.6.50 Zur Erinnerung, der lief hier noch einigermaßen stabil, hatte aber beim Booten so seine Macken. Ab und zu wollte der nicht. Den Mainline habe ich jetzt schon einige Male neugestartet, immer erfolgreich.

    Da kommt mir in den Sinn, liegt es an der Regelung der CPU Kerne, das alle Images so fürchterlich unstabil sind?? Ich kann es nicht beantworten. Kamil kann es evt. 😉

    Update

    (12:57:25) ayufan: if you look at used states, any small spike in CPU usage will bump it to max CPU 🙂

    Damit bringt Armbianmonitor die CPU's immer wieder hoch. OK, dann hätten wir das geklärt. Gefällt mir aber auf 4.4. um Längen besser. Ist aber im Moment auch nicht wichtig. Optimierungen werden sowieso noch lange auf sich warten lassen.

  • HDMI Bildschirmausgabe funktioniert.

    Ein Reboot nicht

    sudo shutdown -r now
    
  • 4.17.0-rc6-1017-ayufan released

    Paar Eindrücke

    • kein Kernel-Panic bei gesteckter PCIe NVMe Karte mit SSD
    • USB3 geht aber mit USB2 Geschwindigkeiten
    • LAN Schnittstelle ist immer noch was langsamer als beim 4.4er Kernel

    LAN

    rock64@rockpro64:/mnt$ iperf3 -c 192.168.3.213
    Connecting to host 192.168.3.213, port 5201
    [  4] local 192.168.3.7 port 41270 connected to 192.168.3.213 port 5201
    [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
    [  4]   0.00-1.00   sec  99.3 MBytes   833 Mbits/sec    3    310 KBytes       
    [  4]   1.00-2.00   sec  97.7 MBytes   820 Mbits/sec    1    322 KBytes       
    [  4]   2.00-3.00   sec  97.7 MBytes   820 Mbits/sec    0    328 KBytes       
    [  4]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec    0    338 KBytes       
    [  4]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec    0    345 KBytes       
    [  4]   5.00-6.00   sec  97.8 MBytes   820 Mbits/sec    0    362 KBytes       
    [  4]   6.00-7.00   sec  97.9 MBytes   822 Mbits/sec    0    404 KBytes       
    [  4]   7.00-8.00   sec  97.8 MBytes   820 Mbits/sec    0    404 KBytes       
    [  4]   8.00-9.00   sec  97.7 MBytes   820 Mbits/sec    0    404 KBytes       
    [  4]   9.00-10.00  sec  97.7 MBytes   820 Mbits/sec    0    404 KBytes       
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bandwidth       Retr
    [  4]   0.00-10.00  sec   979 MBytes   821 Mbits/sec    4             sender
    [  4]   0.00-10.00  sec   977 MBytes   820 Mbits/sec                  receiver
    
    iperf Done.
    rock64@rockpro64:/mnt$ iperf3 -s
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    Accepted connection from 192.168.3.213, port 36990
    [  5] local 192.168.3.7 port 5201 connected to 192.168.3.213 port 36992
    [ ID] Interval           Transfer     Bandwidth
    [  5]   0.00-1.00   sec   108 MBytes   908 Mbits/sec                  
    [  5]   1.00-2.00   sec   112 MBytes   938 Mbits/sec                  
    [  5]   2.00-3.00   sec   112 MBytes   942 Mbits/sec                  
    [  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
    [  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
    [  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
    [  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec                  
    [  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
    [  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec                  
    [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
    [  5]  10.00-10.03  sec  3.58 MBytes   937 Mbits/sec                  
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bandwidth
    [  5]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
    [  5]   0.00-10.03  sec  1.10 GBytes   938 Mbits/sec                  receiver
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    

    USB3

    rock64@rockpro64:/mnt$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
    4096+0 records in
    4096+0 records out
    4294967296 bytes (4.3 GB, 4.0 GiB) copied, 145.552 s, 29.5 MB/s
    

    dmesg

    [ 9397.455487] alloc_contig_range: [f711d, f711e) PFNs busy
    [ 9397.455767] alloc_contig_range: [f7122, f7123) PFNs busy
    [ 9397.456041] alloc_contig_range: [f7123, f7124) PFNs busy
    [ 9397.456308] alloc_contig_range: [f7124, f7125) PFNs busy
    [ 9397.456577] alloc_contig_range: [f7125, f7126) PFNs busy
    [ 9397.456849] alloc_contig_range: [f7126, f7127) PFNs busy
    [ 9397.457119] alloc_contig_range: [f7127, f7128) PFNs busy
    [ 9397.457382] alloc_contig_range: [f7128, f7129) PFNs busy
    [ 9397.458157] alloc_contig_range: [f711d, f711e) PFNs busy
    [ 9397.458429] alloc_contig_range: [f7122, f7123) PFNs busy
    [ 9397.599156] usb 7-1: new high-speed USB device number 2 using xhci-hcd
    [ 9397.827180] scsi host0: uas
    [ 9397.847260] scsi 0:0:0:0: Direct-Access     SanDisk  SDSSDA240G       Z320 PQ: 0 ANSI: 6
    [ 9397.848537] usbcore: registered new interface driver uas
    [ 9397.849422] sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
    [ 9397.849582] sd 0:0:0:0: [sda] Write Protect is off
    [ 9397.849587] sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00
    [ 9397.849890] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [ 9397.853951]  sda: sda1
    [ 9397.856234] sd 0:0:0:0: [sda] Attached SCSI disk
    [ 9430.835974] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
    
  • 4.17.0-rc6-1019-ayufan released

    Was ist mir aufgefallen

    • PCIe arbeitet jetzt mit 5GT/s
    • USB3 geht bei mir nicht mehr, keine Ahnung warum!?!?!?
  • Tja, wenn das Bootproblem nicht wäre, könnte man mit dem Mainline schon leben.

    rock64@rockpro64:/$ uname -a
    Linux rockpro64 4.17.0-rc6-1019-ayufan-gfafc3e1c913f #1 SMP PREEMPT Tue Jun 12 19:06:59 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Mal meine Standardinstallation mit nodejs, redis-server und NodeBB drauf gehauen. Das läuft schon richtig rund.

    • Angschlossen sind ein Monitor mittels HDMI - einwandfrei
    • Am USB3-Port ein Keyboard - ok
    • Die NVMe Karte mit SSD ist drin - ok
    • 6 Kerne werden erkannt

    0_1529149482212_hdmi_htop_ergebnis.jpg

    was noch nicht so richtig funktioniert

    • ich kann am USB3 keine HDD/SDD mehr erkennen, drei verschieden Adapter. Keiner geht!
    • Soundkarte nicht gefunden
    • Booten ist Zufall, Reboot geht nicht.

    So weit macht das schon einen sehr guten Eindruck, für diesen frühen Zeitpunkt. Was nervt ist das Bootproblem, das nervt so richtig wenn man testen will und man nie weiß ob das SOC jetzt mal möchte 🙂

    rock64@rockpro64:/$ uptime
     11:41:12 up  5:11,  2 users,  load average: 0.00, 0.00, 0.00
    
  • 4.17.0-rc6-1029-ayufan released

    Seit 1021 funktioniert USB3.

  • Armbian 20.08 (Caple) released

    Armbian
    1
    0 Stimmen
    1 Beiträge
    337 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - RTC

    Hardware
    1
    0 Stimmen
    1 Beiträge
    340 Aufrufe
    Niemand hat geantwortet
  • Mainline 4.20.0-rc6

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    415 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Reset per SSH funktioniert nicht (Kernel 4.4.x)

    ROCKPro64
    14
    0 Stimmen
    14 Beiträge
    2k Aufrufe
    K

    halli hallo & zusammen,
    in Allgemeinen lässt sich selten empfehlen, auf verdacht alles zu updaten, sobald irgend etwas nicht tut. Oftmals holt man sich lediglich neue Ungewissheit ins Boot. Es hilft eher zu wissen, wo es (denn ungefähr) hakt.

    Wie Frank in etwa bereits angesprochen hat ist es ungemein hilfreich zu sehen "was ab geht". Sprich die serielle "Schnitte" anzuklemmen. Das ist wirklich kein Hexenwerk, braucht aber einen Pegelwandler.
    Andernfalls ist die Gefahr hoch, dass man mit Rätselraten einen Abend ohne Ergebnis in den Sand setzt. Hab ich einmal mit diesem Board hinter mir, dann die serielle Komm angeklemmt.
    Ein ResetProb hab ich zumindest mit eMMC noch nicht beobachtet. Dabei habe ich viel Kernel gewechselt (nie den uboot) und 'reboot' getippt. Ab und an hängt er anscheinend bei Initialisierung der tty's, aber ich mag mich irren. Für das Prob von @killlah78 fehlt für mehr einfach ein output
    gruß

  • [HOWTO] Verschlüsseltes NAS aufsetzen

    Verschoben ROCKPro64
    12
    0 Stimmen
    12 Beiträge
    3k Aufrufe
    FrankMF

    Da btrfs bei mir ja nicht so der Bringer war, Fehler im Image vom Kamil?, Fehler in btrfs? Ich weiß es nicht, also weg damit! Da ich das NAS noch richtig produktiv genutzt hatte, waren die Daten schnell gesichert. Danach das NAS neugestartet, nun sind die beiden Platten nicht mehr gemountet und wir können damit arbeiten.

    ACHTUNG! Ich bitte wie immer darum, das Gehirn ab hier einzuschalten! Sonst droht Datenverlust! Aus Sicherheitsgründen gebe ich hier die Laufwerke so an = sdX1 Das X bitte entsprechend austauschen!

    Die beiden Platten mit

    sudo fdisk /dev/sdX

    neu einrichten. Alte Partition weg, neu einrichten usw. Im Detail gehe ich hier jetzt nicht drauf ein. Ich gehe davon aus, das das bekannt ist.

    Der Plan

    raid_pool0 = sdX1 = /dev/mapper/raid_pool0
    raid_pool1 = sdX1 = /dev/mapper/raid_pool1

    Verschlüsseln sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 Platten entschlüsseln sudo cryptsetup open /dev/sdX1 raid_pool0 sudo cryptsetup open /dev/sdX1 raid_pool1 RAID1 anlegen sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/mapper/raid_pool0 /dev/mapper/raid_pool1 sudo mkfs.ext4 /dev/md0 Script zum Entschlüsseln und Mounten crypt.sh #!/bin/bash ###############################################################################$ # Autor: Frank Mankel # Verschlüsseltes Raid1 einbinden! # # Hardware: # ROCKPro64v2.1 # PCIe SATA Karte # 2St. 2,5 Zoll HDD Platten a 2TB # # Software: # bionic-minimal 0.7.9 # Kontakt: frank.mankel@gmail.com # ###############################################################################$ #Passwort abfragen echo "Passwort eingeben!" read -s password echo "Bitte warten......" #Passwörter abfragen echo -n $password | cryptsetup open /dev/sdX1 raid_pool0 -d - echo -n $password | cryptsetup open /dev/sdX1 raid_pool1 -d - #Raid1 mounten mount /dev/md0 /mnt/raid echo "Laufwerke erfolgreich gemountet!"

    Bis jetzt sieht das Raid ok aus, ich werde das die nächsten Tage mal ein wenig im Auge behalten.

    [ 82.430293] device-mapper: uevent: version 1.0.3 [ 82.430430] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com [ 108.196397] md/raid1:md0: not clean -- starting background reconstruction [ 108.196401] md/raid1:md0: active with 2 out of 2 mirrors [ 108.240395] md0: detected capacity change from 0 to 2000260497408 [ 110.076860] md: resync of RAID array md0 [ 110.385099] EXT4-fs (md0): recovery complete [ 110.431715] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [57744.301662] md: md0: resync done.
  • SPI funktioniert

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    876 Aufrufe
    FrankMF

    Wie ich jetzt mehrmals festgestellt habe, ist das System von der USB3 Platte instabil.

    [111985.654653] EXT4-fs error (d4: inode #16354: comm systemd: r[111985.837719] EXT4-fs error

    Das killt dann das komplette System.

    Ob das an meiner Hardware liegt, weiß ich nicht. Also, wer da draußen so ein System einsetzen will, Vorsicht! Die USB3-Schnittstelle scheint noch einige Bugs zu haben!!

    Mein NVMe System dagegen ist absolut stabil!

  • ROCKPro64 - Wo stehen wir?

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    610 Aufrufe
    Niemand hat geantwortet
  • [HOWTO] ROCKPro64 - PCIe NVMe Karte mit Samsung 960 EVO m.2

    Verschoben Hardware
    2
    0 Stimmen
    2 Beiträge
    2k Aufrufe
    FrankMF
    Ergänzung

    Eine andere SATA-Karte und eine Riser-Karte mit angeschlossener GPU startet nicht.

    rock64@rockpro64v2_1:~$ uname -a Linux rockpro64v2_1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux