Skip to content

SATA Karte Marvell 88SE9230 Chipsatz

Angeheftet Hardware
  • SATA Karte mit Marvell 88SE9230 Chipsatz.

    Warum poste ich das hier? Nein, es ist keine Werbung 😉 Im Forum berichtet ein User, das er die o.g. Karte zum Laufen bekommen hat.

    Was ist der Unterschied zu der Karte, die pine64 anbietet?

    Als erstes mal der Preis. 9,99$ (zuzüglich Steuern, Versand usw.) gegen ca. 59€. Aber das ist ja nicht alles, für den höheren Preis muss es auch einen Grund geben.

    • Hardware RAID 0/1/10
    • 4 SATA Anschlüsse 6 Gbit/s
    • SATA Port Multiplex fähig bis zu 7 HDD's

    Für den, der vielleicht die ein oder andere HDD mehr braucht in seinem NAS, ist das vielleicht interessant!?

    Wie hat der User die Karte zum Laufen bekommen?

    The trick was to put pci=nomsi into the kernel boot parameters in /boot/extlinux/extlinux.conf

    Ok, das bekommen wir auch noch hin 😉

    Ich habe diese Karte nicht und kann somit auch nicht bestätigen, das die Karte läuft. Bin aber an einem Testbericht interessiert, vielleicht hat ein User hier so ein Ding am Laufen!?

    Hersteller-Link

  • Re: SATA Karte Marvell 88SE9230 Chipsatz

    Ich habe eine "delock 88SE9230" Sata Karte mit 4 Ports und besagtem Chipsatz unter OMV im Einsatz. Daran hängen 2 x 3.5 HDD und 2 x 2.5 SSD.

    Dazu musste ich den mainline-kernel installieren und die Tips aus folgendem Thread beherzigen: https://forum.pine64.org/showthread.php?tid=6459&pid=43881#pid43881 .

    Zusammengefasst:

    1. Mainline Kernel installieren (bei mir: Linux rockpro64 4.20.0-rc6-1075-ayufan-g6b3dd2a83c96 #ayufan SMP PREEMPT Tue Dec 11 11:45:20 UTC 2018 aarch64 GNU/Linux)

    2. Eine Datei z.B. /etc/udev/rules.d/99-****.rules erstellen mit folgendem Inhalt:

    ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b4b", ATTR{device}=="0x9230", RUN+="/bin/bash -c 'echo %k > /sys/bus/pci/drivers/ahci/bind'"
    
    1. Neustart

    Danach sollte folgende Ausgaben zu finden sein:

    xx@rockpro64:~$ sudo lspci -vv
    00:00.0 PCI bridge: Device 1d87:0100 (prog-if 00 [Normal decode])
            Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
            Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Latency: 0
            Interrupt: pin A routed to IRQ 255
            Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
            I/O behind bridge: 00000000-00000fff
            Memory behind bridge: fa000000-fa0fffff
            Prefetchable memory behind bridge: 00000000-000fffff
            Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
            BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
                    PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
            Capabilities: [80] Power Management version 3
                    Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
                    Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
            Capabilities: [90] MSI: Enable- Count=1/1 Maskable+ 64bit+
                    Address: 0000000000000000  Data: 0000
                    Masking: 00000000  Pending: 00000000
            Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
                    Vector table: BAR=0 offset=00000000
                    PBA: BAR=0 offset=00000008
            Capabilities: [c0] Express (v2) Root Port (Slot+), MSI 00
                    DevCap: MaxPayload 256 bytes, PhantFunc 0
                            ExtTag- RBE+
                    DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                            MaxPayload 256 bytes, MaxReadReq 512 bytes
                    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                    LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L1, Exit Latency L0s <256ns, L1 <8us
                            ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
                    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-
                            ExtSynch- ClockPM- AutWidDis- BWInt+ AutBWInt+
                    LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                    SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                            Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
                    SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                            Control: AttnInd Off, PwrInd Off, Power+ Interlock-
                    SltSta: Status: AttnBtn- PowerFlt- MRL+ CmdCplt- PresDet- Interlock-
                            Changed: MRL- PresDet- LinkState-
                    RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
                    RootCap: CRSVisible-
                    RootSta: PME ReqID 0000, PMEStatus- PMEPending-
                    DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via message ARIFwd+
                    DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
                    LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                             Compliance De-emphasis: -6dB
                    LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
            Capabilities: [100 v2] Advanced Error Reporting
                    UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                    UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                    UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                    CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                    CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                    AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
            Capabilities: [274 v1] Transaction Processing Hints
                    Interrupt vector mode supported
                    Device specific mode supported
                    Steering table in TPH capability structure
    
    01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) (prog-if 01 [AHCI 1.0])
            Subsystem: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller
            Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
            Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Latency: 0
            Interrupt: pin A routed to IRQ 231
            Region 0: I/O ports at 0000
            Region 1: I/O ports at 0000
            Region 2: I/O ports at 0000
            Region 3: I/O ports at 0000
            Region 4: I/O ports at 0000
            Region 5: Memory at fa010000 (32-bit, non-prefetchable) [size=2K]
            Expansion ROM at fa000000 [disabled] [size=64K]
            Capabilities: [40] Power Management version 3
                    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
                    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
            Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
                    Address: fee30040  Data: 0000
            Capabilities: [70] Express (v2) Legacy Endpoint, MSI 00
                    DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
                            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                    DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                            MaxPayload 256 bytes, MaxReadReq 512 bytes
                    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend+
                    LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
                            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                    LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                    LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                    DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
                    DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                    LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                             Compliance De-emphasis: -6dB
                    LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
            Capabilities: [e0] SATA HBA v0.0 BAR4 Offset=00000004
            Capabilities: [100 v1] Advanced Error Reporting
                    UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                    UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                    UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                    CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                    CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                    AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
            Kernel driver in use: ahci
    

    und

    xx@rockpro64:~$ lsblk -S
    NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
    sda  0:0:0:0    disk ATA      Samsung SSD 850  2B6Q sata
    sdb  1:0:0:0    disk ATA      WDC WD60EFRX-68L 0A82 sata
    sdc  2:0:0:0    disk ATA      KINGSTON SUV400S D6SD sata
    sdd  3:0:0:0    disk ATA      WDC WD60EFRX-68L 0A82 sata
    

    Btw.: Danke für Deine Arbeit, Frank.

    Grüße

  • Hey Frank, bitte entschuldige.
    Dieses Thema hier sollte eigentlich eine Antwort auf deinen Thread "SATA Karte Marvell 88SE9230 Chipsatz" sein. Die Forensoftware hat mich scheinbar etwas verwirrt.
    Sorry nochmal.

  • Hallo @flockeee und Danke für deinen Beitrag. Ich habe das von dir schon woanders gelesen 😉 Die Karte würde mich evt. auch interessieren.

    Hast du schon mal ordentlich Daten hin und her geschaufelt!?

    Mal sehen, ob ich die Themen zusammenlegen kann.

  • Ich bin gerade dabei ein Raid zu erstellen (dauert noch etwas). Danach wollen rund 3 TB darauf kopiert werden. Mal gucken was sich danach so in dmesg findet. Das sollte aus erster Stabilitätstest genügen.

    Geschwindigkeitstests werden im Anschluß folgen.

    Grüße

  • Ich bin sehr gespannt auf deine Ergebnisse.

  • Ich habe die Themen zusammengeführt.

  • @FrankM :
    Leider werden die Ergebnisse noch etwas dauern. Das Raid1 wurde problemlos erstellt, allerdings ist das System nach einem Neustart nicht mehr administrierbar. Siehe https://forum.frank-mankel.org/topic/445/emmc-boot-stuck-after-reboot .

    Grüße,
    Florian

    EDIT:
    Das System ist wieder administrierbar (siehe verlinkten Thread).
    Als Stabilitätstest werden jetzt per RSync 3.8TB Daten aufs SW-Raid1 kopiert.
    Mal schauen wie die Sata Karte sich macht und was dmesg sagt.
    Ich werde berichten.

    EDIT2:
    Der Stabilitätstest ist durch. Die 3.8TB Daten wurde ohne Fehlermeldungen in dmesg kopiert.

    Speedtest:

    SW-RAID1 (2xWD-RED 6TB):

    dd:

    pi@rockpro64:/srv/dev-disk-by-label-Raid1Storage$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync
    4096+0 records in
    4096+0 records out
    4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.6309 s, 111 MB/s
    

    iozone:

    pi@rockpro64:/srv/dev-disk-by-label-Raid1Storage$ sudo 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: Wed Jan 30 19:53:19 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    25464    36685    50427    49394      888     1729                                       
              102400      16    40165    58097    68316    91524     3412     6889                                       
              102400     512    95485    99343   107161   131298    52080    78677                                       
              102400    1024    81958    91971   104137   128435    73100    80979                                       
              102400   16384    89566   102283   102792   140921   144198   100731                                       
    
    iozone test complete.
    

    SSD1 (Kingston SSDNow 500GB)

    dd:

    pi@rockpro64:/srv/dev-disk-by-label-Export$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync         4096+0 records in
    4096+0 records out
    4294967296 bytes (4.3 GB, 4.0 GiB) copied, 16.2036 s, 265 MB/s
    

    iozone:

    pi@rockpro64:/srv/dev-disk-by-label-Export$ sudo 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: Wed Jan 30 20:09:46 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    45141    66137    69723    70946    21840    63277                                       
              102400      16   136172   140168   154485   183570    55734   146870                                       
              102400     512   388396   361469   298032   306411   272152   360291                                       
              102400    1024   395404   379891   336627   335560   326960   387305                                       
              102400   16384   150878   170563   133750   147378   116889   484788                                       
    
    iozone test complete.
    

    SSD2 (Samsung SSD850 500GB):

    dd:

    pi@rockpro64:/srv/dev-disk-by-label-SSD850$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync         4096+0 records in
    4096+0 records out
    4294967296 bytes (4.3 GB, 4.0 GiB) copied, 13.6532 s, 315 MB/s
    

    iozone:

    pi@rockpro64:/srv/dev-disk-by-label-SSD850$ sudo 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: Wed Jan 30 20:13:46 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    40543    70208    73986    73104    30564    68626                                       
              102400      16   118034   156574   173566   190123    91171   156537                                       
              102400     512   393457   364015   360967   355865   332180   359108                                       
              102400    1024   410187   393582   401007   391708   368777   401934                                       
              102400   16384   414139   486653   484318   487278   483865   479006                                       
    
    iozone test complete.
    

    Während der Tests wurden keinerlei Fehlermeldungen in dmesg erzeugt.

    Grüße.

  • Leider sind beim Stress Testen des Controllers (kopieren von 500GB vom SW-RAID1 parallel auf beide SSDs)
    wiederholt folgende Fehler in dmesg aufgetaucht:

    [177554.379675] ata3.00: exception Emask 0x0 SAct 0x1f000000 SErr 0x0 action 0x6 frozen
    [177554.382198] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.384513] ata3.00: cmd 61/08:c0:00:09:80/00:00:16:00:00/40 tag 24 ncq dma 4096 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.389434] ata3.00: status: { DRDY }
    [177554.391423] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.393559] ata3.00: cmd 61/10:c8:10:09:81/00:00:16:00:00/40 tag 25 ncq dma 8192 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.398530] ata3.00: status: { DRDY }
    [177554.400704] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.402878] ata3.00: cmd 61/08:d0:38:45:86/00:00:16:00:00/40 tag 26 ncq dma 4096 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.407762] ata3.00: status: { DRDY }
    [177554.409759] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.411909] ata3.00: cmd 61/08:d8:b8:08:00/00:00:00:00:00/40 tag 27 ncq dma 4096 out
                             res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.416582] ata3.00: status: { DRDY }
    [177554.418559] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.420735] ata3.00: cmd 61/28:e0:38:08:00/00:00:0b:00:00/40 tag 28 ncq dma 20480 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.425796] ata3.00: status: { DRDY }
    [177554.428043] ata3: hard resetting link
    [177554.748386] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    [177554.752956] ata3.00: configured for UDMA/133
    [177554.755160] ata3: EH complete
    [177677.262098] ata3.00: NCQ disabled due to excessive errors
    

    Der Kopierprozess auf die jeweilige SSD welche dann resetet stockt dann einige Sekunden und wird dann fortgesetzt. Dies passiert bisher nur bei den SSDs und nicht parallel.
    Die Lesegeschwindigkeit vom RAID1 sind meiner Meinung nach gut und begrenzt natürlich die Schreibgeschwindigkeiten auf die SSDs:

    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               0.47    0.00   27.39   26.88    0.00   45.26
    
    Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
    mtdblock0         0.00         0.00         0.00          0          0
    mtdblock1         0.00         0.00         0.00          0          0
    mtdblock2         0.00         0.00         0.00          0          0
    mmcblk1          16.40         0.06         0.00          0          0
    mmcblk1boot1      0.00         0.00         0.00          0          0
    mmcblk1boot0      0.00         0.00         0.00          0          0
    mmcblk0           0.00         0.00         0.00          0          0
    sdc             197.40         0.00       101.42          0        507
    sdd             467.60       116.38         0.01        581          0
    sdb             476.60       118.60         0.01        592          0
    sda             345.60         0.00       116.34          0        581
    md0             942.40       235.03         0.00       1175          0
    

    Viele Grüße

  • Da ich nun etwas neugierig geworden bin auf die Karte, habe ich mir diese mal besorgt.

    IMG_20190201_150932_ergebnis.jpg

    Hier mal der Vergleich mit der PCIe-SATA Karte, die von Pine64 vertrieben wird. (Pine64-Karte ist links im Bild)

    IMG_20190201_151325_ergebnis.jpg

    Die 9230 hat vier SATA-Anschlüsse. Außerdem hat die Karte zwei Stiftleisten, wo man was anschließen kann. Dazu später mehr.

    Als erstes teste ich einfach mal meine vorhandene NAS-Installation, also alte Karte raus, die Neue rein und neustarten.

    System

    rock64@rockpro64v_2_1:~$ uname -a
    Linux rockpro64v_2_1 4.20.0-1083-ayufan-g686e1f1aa461 #ayufan SMP PREEMPT Sun Dec 30 13:42:26 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Nachsehen, ob der Controller erkannt wird.

    lspci

    rock64@rockpro64v_2_1:~$ sudo lspci -vvv
    00:00.0 PCI bridge: Rockchip Inc. RK3399 PCI Express Root Port Device 0100 (prog-if 00 [Normal decode])
    	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    	Latency: 0
    	Interrupt: pin A routed to IRQ 255
    	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
    	I/O behind bridge: 00000000-00000fff
    	Memory behind bridge: fa000000-fa0fffff
    	Prefetchable memory behind bridge: 00000000-000fffff
    	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
    	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
    		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
    	Capabilities: [80] Power Management version 3
    		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
    		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
    	Capabilities: [90] MSI: Enable- Count=1/1 Maskable+ 64bit+
    		Address: 0000000000000000  Data: 0000
    		Masking: 00000000  Pending: 00000000
    	Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
    		Vector table: BAR=0 offset=00000000
    		PBA: BAR=0 offset=00000008
    	Capabilities: [c0] Express (v2) Root Port (Slot+), MSI 00
    		DevCap:	MaxPayload 256 bytes, PhantFunc 0
    			ExtTag- RBE+
    		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
    			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
    			MaxPayload 256 bytes, MaxReadReq 512 bytes
    		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
    		LnkCap:	Port #0, Speed 5GT/s, Width x4, ASPM L1, Exit Latency L0s <256ns, L1 <8us
    			ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
    		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- CommClk-
    			ExtSynch- ClockPM- AutWidDis- BWInt+ AutBWInt+
    		LnkSta:	Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
    		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
    			Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
    		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
    			Control: AttnInd Off, PwrInd Off, Power+ Interlock-
    		SltSta:	Status: AttnBtn- PowerFlt- MRL+ CmdCplt- PresDet- Interlock-
    			Changed: MRL- PresDet- LinkState-
    		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
    		RootCap: CRSVisible-
    		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
    		DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via message ARIFwd+
    		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
    		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
    			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
    			 Compliance De-emphasis: -6dB
    		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
    			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    	Capabilities: [100 v2] Advanced Error Reporting
    		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
    		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
    		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
    		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
    	Capabilities: [274 v1] Transaction Processing Hints
    		Interrupt vector mode supported
    		Device specific mode supported
    		Steering table in TPH capability structure
    
    01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) (prog-if 01 [AHCI 1.0])
    	Subsystem: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller
    	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    	Interrupt: pin A routed to IRQ 230
    	Region 0: I/O ports at 0000
    	Region 1: I/O ports at 0000
    	Region 2: I/O ports at 0000
    	Region 3: I/O ports at 0000
    	Region 4: I/O ports at 0000
    	Region 5: Memory at fa010000 (32-bit, non-prefetchable) [size=2K]
    	Expansion ROM at fa000000 [disabled] [size=64K]
    	Capabilities: [40] Power Management version 3
    		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
    		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
    	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
    		Address: fee30040  Data: 0000
    	Capabilities: [70] Express (v2) Legacy Endpoint, MSI 00
    		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
    			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
    		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
    			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
    			MaxPayload 256 bytes, MaxReadReq 512 bytes
    		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
    		LnkCap:	Port #0, Speed 5GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
    			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
    		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
    			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
    		LnkSta:	Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
    		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
    		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
    		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
    			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
    			 Compliance De-emphasis: -6dB
    		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
    			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    	Capabilities: [e0] SATA HBA v0.0 BAR4 Offset=00000004
    	Capabilities: [100 v1] Advanced Error Reporting
    		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
    		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
    		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
    		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
    

    Ok, der Controller wird einwandfrei erkannt. Eine Suche nach den Festplatten war dann leider erfolglos. Diese wurden nicht erkannt. Aber dafür gibt es ja im Internet viele Menschen, die an einer gemeinsamen Sache arbeiten und @flockeee hat die Lösung ja in diesem Thread schon gepostet. Danke dafür!!

    /etc/udev/rules.d

    Wir erstellen in /etc/udev/rules.d eine Datei mit dem Namen 99-9230.rules. Die 99 besagt aus, das diese Datei als letztes ausgeführt wird (wenn ich mich nicht irre), das 9230 kann man frei wählen.

    cd /etc/udev/rules.d
    sudo nano 99-9230.rules
    

    Der Inhalt der Datei

    ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b4b", ATTR{device}=="0x9230", RUN+="/bin/bash -c 'echo %k > /sys/bus/pci/drivers/ahci/bind'"
    

    Dazu kann ich leider nicht so viel schreiben. Zum Nachlesen -> udev

    Danach Neustarten!

    HDD Check

    Danach findet man die HDD's 🙂

    rock64@rockpro64v_2_1:/etc/udev/rules.d$ lsblk -S
    NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
    sda  0:0:0:0    disk ATA      ST2000LM015-2E81 SDM1 sata
    sdb  2:0:0:0    disk ATA      ST2000LM015-2E81 SDM1 sata
    

    Mit fdisk -l

    Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: ECA86F86-787E-483F-BD79-DC980BCA9447
    
    Device     Start        End    Sectors  Size Type
    /dev/sda1   2048 3907029134 3907027087  1,8T Linux filesystem
    
    
    Disk /dev/sdb: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: gpt
    Disk identifier: 1978A3C9-E914-41FB-8788-5518DBB77B2F
    
    Device     Start        End    Sectors  Size Type
    /dev/sdb1   2048 3907029134 3907027087  1,8T Linux filesystem
    

    Ok, alles da. Dann rufe ich mal mein Script auf und hänge die verschlüsselten Platten als RAID1 ein.

    Fertig!

    Kontrolle

    rock64@rockpro64v_2_1:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            980M     0  980M   0% /dev
    tmpfs           199M  640K  198M   1% /run
    /dev/mmcblk0p7   29G   15G   13G  55% /
    tmpfs           992M     0  992M   0% /dev/shm
    tmpfs           5,0M     0  5,0M   0% /run/lock
    tmpfs           992M     0  992M   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4,0K  112M   1% /boot/efi
    tmpfs           199M     0  199M   0% /run/user/1000
    /dev/md0        1,8T  645G  1,1T  38% /mnt/raid
    

    Status RAID1

    rock64@rockpro64v_2_1:~$ cat /proc/mdstat 
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
    md0 : active raid1 dm-1[2] dm-0[1]
          1953379392 blocks super 1.2 [2/2] [UU]
          bitmap: 0/15 pages [0KB], 65536KB chunk
    
    unused devices: <none>
    

    So weit sieht alles gut aus, dann machen wir mal was Stress! 🙂

    Steckanschlüsse

    IMG_20190201_155415_ergebnis.jpg

    Die blaue LED ist dauernd an und fängt bei Schreib-/Lesezugriffen an zu blinken. Was der andere Anschluss macht, habe ich noch nicht raus. Beide Pfostenstecker sind für PWR LED. Siehe -> Klick Ich habe nur an einem Pfostenstecker die LED zum Leuchten bekommen (siehe Bild).

    Fazit

    Danke @flockeee , ich halte Dich auf dem Laufenden was die Stabilität angeht. Ich hoffe, das ich jetzt wieder ein stabiles NAS habe. Ich bin gespannt 😉

    Zum Schluß noch die Ausgabe von dmesg

  • Erster Stresstest erfolgreich. 🙂

    Hardware

    • ROCKPro64 v2.1 2GB RAM
    • SD-Karte (als System)
    • PCIe SATA-Karte 88SE9230
    • 2 * 2TB HDD's als RAID1
    • 1 * 1TB HDD (USB3)

    Software

    rock64@rockpro64v_2_1:~$ uname -a
    Linux rockpro64v_2_1 4.20.0-1083-ayufan-g686e1f1aa461 #ayufan SMP PREEMPT Sun Dec 30 13:42:26 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Speedtest USB3-HDD

     rock64@rockpro64v_2_1:/media$ 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, 44,7297 s, 96,0 MB/s
    

    Die HDD hat ein btrfs Filesystem

    rock64@rockpro64v_2_1:~$ sudo blkid /dev/sdc1
    /dev/sdc1: LABEL="1TB" UUID="99950e1f-5637-4cb8-9985-e9deea6c8f96" UUID_SUB="48ae2955-33d1-46a6-9067-afd65a04de2b" TYPE="btrfs" PARTUUID="b9aa5cfb-01"
    

    Backup Job

    Die Aufgabe ist es, mein RAID1 mittels Restic auf die angeschlossene USB HDD zu sichern. Also etwas Stress für den ROCKPro64, da die Daten alle verschlüsselt werden. Und lesender Stress auf das RAID1.

    rock64@rockpro64v_2_1:~$ sudo ./backup.sh 
    open repository
    repository bad662c2 opened successfully, password is correct
    created new cache in /home/rock64/.cache/restic
    found 1 old cache directories in /home/rock64/.cache/restic, pass --cleanup-cache to remove them
    
    Files:       558914 new,     0 changed,     0 unmodified
    Dirs:            1 new,     0 changed,     0 unmodified
    Added to the repo: 285.754 GiB
    
    processed 558914 files, 648.243 GiB in 3:17:41
    snapshot 19c4ea75 saved
    

    DMESG

    pastebin

    Fazit

    Der Lesetest war erfolgreich, keine Probleme festgestellt. Das die HDD am USB3 ein btrfs Filesystem hat ist Zufall, das ist mir erst hinterher aufgefallen. Meine früheren Erfahrungen mit btrfs auf einem ROCKPro64 waren nicht so positiv. Produktiv würde ich eher ext4 einsetzen.

    Als nächstes brauchen wir mal richtig Stress beim Schreiben auf das RAID1 😉

  • Alles so wie oben, nun der Schreibtest.

    Job

    Wir ziehen mal von einem anderen NAS ein paar Daten

    sshpass -p "password" rsync -vraze 'ssh' --exclude-from "excludes.txt" root@192.168.3.243:/mnt/nas/ /mnt/raid/write_test/
    

    Ergebnis

    sent 909,539 bytes  received 208,162,189,243 bytes  20,487,485.73 bytes/sec
    total size is 222,765,913,987  speedup is 1.07
    

    DMESG

    Kein besonderer Eintrag, alles sauber.

    Fazit

    Scheint so, als wenn man mit dieser PCIe SATA-Karte die bessere Lösung, zu der preiswerten Pine64-Karte hat. Evt. sind auch nur die Treiber der Marvell Karte besser. Im Moment, von mir eine Kaufempfehlung!

  • @flockeee sagte in SATA Karte Marvell 88SE9230 Chipsatz:

    Leider sind beim Stress Testen des Controllers (kopieren von 500GB vom SW-RAID1 parallel auf beide SSDs)
    wiederholt folgende Fehler in dmesg aufgetaucht:

    [177554.379675] ata3.00: exception Emask 0x0 SAct 0x1f000000 SErr 0x0 action 0x6 frozen
    [177554.382198] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.384513] ata3.00: cmd 61/08:c0:00:09:80/00:00:16:00:00/40 tag 24 ncq dma 4096 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.389434] ata3.00: status: { DRDY }
    [177554.391423] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.393559] ata3.00: cmd 61/10:c8:10:09:81/00:00:16:00:00/40 tag 25 ncq dma 8192 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.398530] ata3.00: status: { DRDY }
    [177554.400704] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.402878] ata3.00: cmd 61/08:d0:38:45:86/00:00:16:00:00/40 tag 26 ncq dma 4096 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.407762] ata3.00: status: { DRDY }
    [177554.409759] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.411909] ata3.00: cmd 61/08:d8:b8:08:00/00:00:00:00:00/40 tag 27 ncq dma 4096 out
                             res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.416582] ata3.00: status: { DRDY }
    [177554.418559] ata3.00: failed command: WRITE FPDMA QUEUED
    [177554.420735] ata3.00: cmd 61/28:e0:38:08:00/00:00:0b:00:00/40 tag 28 ncq dma 20480 out
                             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
    [177554.425796] ata3.00: status: { DRDY }
    [177554.428043] ata3: hard resetting link
    [177554.748386] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    [177554.752956] ata3.00: configured for UDMA/133
    [177554.755160] ata3: EH complete
    [177677.262098] ata3.00: NCQ disabled due to excessive errors
    

    Der Kopierprozess auf die jeweilige SSD welche dann resetet stockt dann einige Sekunden und wird dann fortgesetzt. >Dies passiert bisher nur bei den SSDs und nicht parallel.
    ...

    Ich habe oben genannte Probleme mit einem Firmwareupdate* des 88SE9230 in den Griff bekommen. Ein erneuter Stresstest produziert keine der obengenannten Fehlermeldungen mehr bei gleichem Testmuster.

    Zum Flashen des Controllers bin ich folgendermaßen vorgegangen:

    1. Sata Controller (hier: DeLOCK 89395) in ein x64/x86 system stecken
    2. Bootbaren USB Stick mit FreeDos präparieren und Dateien aus obengenanntem Archiv ins Hauptverzeichnis legen
    3. Vom USB Stick ins FreeDos booten
    4. In der Kommandozeile "go.bat -y" ausführen
    5. Warten bis der Flash vollständig ist
    6. Neustart

    ACHTUNG: DIESE METHODE BEINHALTET KEIN (FUNKTIONIERENDES) BACKUP DER VORHANDENEN FIRMWARE DES CONTROLLERS! FLASHEN AUF EIGENES RISIKO!

    Ich habe zuerst die allerneuste Version 1.0.0.1028 bios + 2.3.0.1078 fw geflasht. Mit dieser Version gab es Fehlermeldungen in dmesg über den controller init und die angeschlossenen Platten wurden nicht angezeigt. Ein Downgrade auf obengenannte Version löste das Problem.

    Viele Grüße,
    Florian

  • Als kleine Ergänzung.

    @flockeee benutzt 4 Festplatten an seiner Karte 2 * HDD (SW-Raid) & 2 * SSD, ich benutze nur 2 * HDD als RAID1. Bei seinem Stresstest werden wohl alle 4 Platten gleichzeitig genutzt, was wohl zu den Fehlern führt mit der alten Firmware Version.

    Ich konnte mit meiner Konfiguration, bis jetzt, keine Fehler feststellen.

    Danke für den konstruktiven Beitrag. Vielleicht wage ich mich da auch mal ran.

    FreeDOS -> http://www.freedos.org/download/

  • Kurz als Hinweis, Kernel 5.0.0 crasht bei mir.

    Das oben geschriebene muss ich revidieren. Heute nochmal in Ruhe getestet - funktioniert!!

    rock64@rp64v_2_1_NAS:~$ uname -a
    Linux rp64v_2_1_NAS 5.0.0-1101-ayufan-g41eeb7cd789e #ayufan SMP PREEMPT Fri Mar 8 22:14:59 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
    
  • Der LAN-Fix im 1011er bringt ganz gute Raten. Lesend, ein par Filme kopieren.

    bfd247ba-5e1b-424d-affb-4f682ebc6f54-grafik.png

  • Mal kurz was an Infos vom heutigen Tag aus dem IRC.

    Ein User(Linu) hatte dort massive Probleme mit der SATA-Karte, konnte aber schon nicht vernünftig booten. 4.4er Kernel ging, alle anderen Kernel verursachten Probleme.

    Der User bootete von der eMMC-Karte! Das Bootproblem lies sich mit folgendem Befehl beheben

    mmc_cmdqueue=off
    

    Danke an den User nuumio für den Tipp.

    Die SATA-Karte funktioniert aber nur mit einem Mainline-Kernel vom Kamil. Nix neues für uns 😉

    Und wieder ein glücklicher ROCKPro64 User mit NAS 🙂

  • Heute mal mit dem neuen Release 0.10.x von Kamil testen. u-boot im SPI!

    Mit pci=nomsi geht es nicht. Die Karte wird zwar erkannt, aber keine angeschlossenen Laufwerke.

    Mit

    cd /etc/udev/rules.d
    

    dann

    nano 98-sata.rules
    

    und

    ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b4b", ATTR{device}=="0x9230", RUN+="/bin/bash -c 'echo %k > /sys/bus/pci/drivers/ahci/bind'"
    

    kann ich die Platte sehen.

    root@rockpro64:~# blkid
    /dev/sda1: PARTLABEL="loader1" PARTUUID="37466429-e4a4-495c-b9a1-3f74625a3cae"
    /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="ABCD-FC7D" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="72e36967-4050-4bb3-8f8f-bf6755c38f28"
    /dev/sda3: LABEL="linux-boot" UUID="8e289a3e-0f9b-4da1-a147-51e03390637c" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="fe944fd2-3e42-4202-8a95-656e9bdb4be6"
    /dev/sda4: LABEL="linux-root" UUID="3e9513c6-dfd1-48c9-bee2-04bb5a153056" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="d2d1dd88-030d-4f74-998f-7c9ce7d385d0"
    /dev/sdb1: PARTLABEL="loader1" PARTUUID="615d1c43-7774-43eb-b31f-b586ed7c8af4"
    /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="E616-9C0A" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="8b62024d-dd94-4022-a43f-dc91766cd611"
    /dev/sdb3: LABEL="linux-boot" UUID="d1a97607-270c-494b-a360-9231b52fd7ef" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="e1c825e9-60f1-479d-9ab4-0a853a5da9f2"
    /dev/sdb4: LABEL="linux-root" UUID="1ada358f-1688-4557-ae4e-2942db99a0ff" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="e07545eb-3cf2-4814-8985-728554cd20ae"
    

    Aber von der Karte wird nicht gebootet 😞

  • Ok, es gibt noch eine andere Möglichkeit.

    Kamil hat mir noch ein wenig geholfen. Mit folgender Änderung werden die Platten gefunden.

    hmm, I had to add /etc/default/extlinuxlibahci.skip_host_reset=1

    Sieht dann so aus.

    # Configure timeout to choose the kernel
    # TIMEOUT="10"
    
    # Configure default kernel to boot: check all kernels in `/boot/extlinux/extlinux.conf`
    # DEFAULT="kernel-4.4.126-rockchip-ayufan-253"
    
    # Configure additional kernel configuration options
    APPEND="$APPEND root=LABEL=linux-root rootwait rootfstype=ext4 libahci.skip_host_reset=1"
    

    Danach waren die Platten zu sehen.

    root@rockpro64:/tmp/etc/default# blkid
    /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="ABCD-FC7D" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="72e36967-4050-4bb3-8f8f-bf6755c38f28"
    /dev/sda3: LABEL="linux-boot" UUID="8e289a3e-0f9b-4da1-a147-51e03390637c" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="fe944fd2-3e42-4202-8a95-656e9bdb4be6"
    /dev/sda4: LABEL="linux-root" UUID="3e9513c6-dfd1-48c9-bee2-04bb5a153056" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="d2d1dd88-030d-4f74-998f-7c9ce7d385d0"
    /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="56C9-F745" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="919c8f73-5f25-4a01-9072-3a5ed9a88ff2"
    /dev/sdb3: LABEL="linux-boot" UUID="23c19647-f4a1-4197-a877-f1bb03456bef" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="093d0cc0-d122-4dce-aeb5-4e266b4b7d9d"
    /dev/sdb4: LABEL="linux-root" UUID="f1c74331-8318-4ee8-a4f7-f0c169fb9944" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="964ab457-58d5-40c4-bb02-dfd37bd2f0da"
    /dev/sda1: PARTLABEL="loader1" PARTUUID="37466429-e4a4-495c-b9a1-3f74625a3cae"
    /dev/sdb1: PARTLABEL="loader1" PARTUUID="33f692b3-54cb-4a37-b602-21a2baf32fa0"
    

    Aber auch hiermit ist ein Boot von der SATA Platte nicht möglich.

    Ich möchte hier noch was vom kamil zitieren.

    (11:44:09) ayufanWithPM: will look later, but this controller is tricky, also on x86 as well
    (11:44:16) ayufanWithPM: jms585 seems to be significantly more stable

    Evt. bekommt er das gefixt 😉

  • ROCKPro64 - Debian Bullseye Teil 3

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    312 Aufrufe
    Niemand hat geantwortet
  • Mainline 4.20.0-rc6

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    414 Aufrufe
    Niemand hat geantwortet
  • Image 0.7.8 - Latest release

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    543 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - kein WLan-Modul möglich?

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    2k Aufrufe
    FrankMF

    Heute, 5 Monate später, kann ich bestätigen das WLan möglich ist 🙂 Getestet auf einem ROCKPro64 v2.1 mit 2GB RAM.

    Eine Vorabversion von Recalbox machte es das erste Mal für mich möglich das WLan zu benutzen. Bericht

    Und PCIe ist abgeschaltet im dts File.

    pcie-phy { compatible = "rockchip,rk3399-pcie-phy"; #phy-cells = <0x0>; rockchip,grf = <0x15>; clocks = <0x8 0x8a>; clock-names = "refclk"; resets = <0x8 0x87>; reset-names = "phy"; status = "disabled"; phandle = <0x8b>; }; pcie@f8000000 { compatible = "rockchip,rk3399-pcie"; #address-cells = <0x3>; #size-cells = <0x2>; aspm-no-l0s; clocks = <0x8 0xc5 0x8 0xc4 0x8 0x147 0x8 0xa0>; clock-names = "aclk", "aclk-perf", "hclk", "pm"; bus-range = <0x0 0x1f>; max-link-speed = <0x2>; linux,pci-domain = <0x0>; msi-map = <0x0 0x89 0x0 0x1000>; interrupts = <0x0 0x31 0x4 0x0 0x0 0x32 0x4 0x0 0x0 0x33 0x4 0x0>; interrupt-names = "sys", "legacy", "client"; #interrupt-cells = <0x1>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 0x8a 0x0 0x0 0x0 0x0 0x2 0x8a 0x1 0x0 0x0 0x0 0x3 0x8a 0x2 0x0 0x0 0x0 0x4 0x8a 0x3>; phys = <0x8b>; phy-names = "pcie-phy"; ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x1e00000 0x81000000 0x0 0xfbe00000 0x0 0xfbe00000 0x0 0x100000>; reg = <0x0 0xf8000000 0x0 0x2000000 0x0 0xfd000000 0x0 0x1000000>; reg-names = "axi-base", "apb-base"; resets = <0x8 0x82 0x8 0x83 0x8 0x84 0x8 0x85 0x8 0x86 0x8 0x81 0x8 0x80>; reset-names = "core", "mgmt", "mgmt-sticky", "pipe", "pm", "pclk", "aclk"; status = "disabled";

    Also bleibt weiterhin ungeklärt, ob auch beides zusammen möglich ist. Also gleichzeitig das WLan-Modul und eine PCIe Karte.

  • Mainline Kernel 4.18.0-rc3

    Linux
    1
    0 Stimmen
    1 Beiträge
    961 Aufrufe
    Niemand hat geantwortet
  • [HOWTO] ROCKPro64 - Boot

    Verschoben Hardware
    5
    0 Stimmen
    5 Beiträge
    4k Aufrufe
    FrankMF

    Das Problem sollte mit Kernel 4.19.0-rc4-1069-ayufan behoben sein.

  • stretch-minimal-rockpro64

    Verschoben Linux
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF

    Mal ein Test was der Speicher so kann.

    rock64@rockpro64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 2812.7 MB/s C copy backwards (32 byte blocks) : 2811.9 MB/s C copy backwards (64 byte blocks) : 2632.8 MB/s C copy : 2667.2 MB/s C copy prefetched (32 bytes step) : 2633.5 MB/s C copy prefetched (64 bytes step) : 2640.8 MB/s C 2-pass copy : 2509.8 MB/s C 2-pass copy prefetched (32 bytes step) : 2431.6 MB/s C 2-pass copy prefetched (64 bytes step) : 2424.1 MB/s C fill : 4887.7 MB/s (0.5%) C fill (shuffle within 16 byte blocks) : 4883.0 MB/s C fill (shuffle within 32 byte blocks) : 4889.3 MB/s C fill (shuffle within 64 byte blocks) : 4889.2 MB/s --- standard memcpy : 2807.3 MB/s standard memset : 4890.4 MB/s (0.3%) --- NEON LDP/STP copy : 2803.7 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 2802.1 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 2800.7 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 2745.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2745.8 MB/s NEON LD1/ST1 copy : 2801.9 MB/s NEON STP fill : 4888.9 MB/s (0.3%) NEON STNP fill : 4850.1 MB/s ARM LDP/STP copy : 2803.8 MB/s ARM STP fill : 4893.0 MB/s (0.5%) ARM STNP fill : 4851.7 MB/s ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 602.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 551.6 MB/s NEON LD1/ST1 copy (from framebuffer) : 667.1 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 605.6 MB/s ARM LDP/STP copy (from framebuffer) : 445.3 MB/s ARM LDP/STP 2-pass copy (from framebuffer) : 428.8 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 4.5 ns / 7.2 ns 131072 : 6.8 ns / 9.7 ns 262144 : 9.8 ns / 12.8 ns 524288 : 11.4 ns / 14.7 ns 1048576 : 16.0 ns / 22.6 ns 2097152 : 114.0 ns / 175.3 ns 4194304 : 161.7 ns / 219.9 ns 8388608 : 190.7 ns / 241.5 ns 16777216 : 205.3 ns / 250.5 ns 33554432 : 212.9 ns / 255.5 ns 67108864 : 222.3 ns / 271.1 ns
  • Links

    Angeheftet Linux
    1
    0 Stimmen
    1 Beiträge
    771 Aufrufe
    Niemand hat geantwortet