Gigabyte MJ11-EC1 NAS Server

@F|Marsman Ja ich denke auch dass das Board hin ist. Ich lasse es jetzt noch mit dem TrueNAS Scale laufen und schauen ob bzw. wie lange die Verbindung stabil bleibt.

Mittlerweile habe ich mal zum Test mit dem Board unter Proxmox ein "virtuelles NAS" gebaut und 2 andere HDDs durchgereicht, was erstaunlicher Weise echt gut klappt. Per virtio NIC bekomme ich von Win 11 aus 98 MB/s rübergeschoben. Das ist gar nicht so schlecht.

Nur blöd dass ich für meine 10 GBit/s jetzt nen anderen Adapter brauche ;) der liegt in NL (kommt aus China) und ist dann hoffentlich die Tage hier. Wäre dann ne Wollmilchsau aus Proxmox mit NAS drin und allen VMs.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ist ja grundsätzlich auch sone Eierlegendewollmilchsau :fresse: wenns denn läuft... also schon sone kleine Zicke
 
das Problem mit den Netzwerkanschlüssen on Board hab ich glaub ich auch. auf einmal keine Verbindung mehr und alle netztlaufwerke melden sich ab. hmmm @F|Marsman vielleicht ist das nicht nur nen RAM Problem. ich hab jetzt mal die NIC Bündelung deaktiviert, aber bringt auch nix. auf einmal nicht mehr erreichbar. Weiß aber nicht ob es wirklich an den NICs liegt. er macht nämlich nen Array Check wo die Festplatte rappeln und auf einmal ist ruhe. wenn ich so drüber nachdenke wahrscheinlich doch die RAMs. hmmm
 
@marco-mh also zum Vergleich, im NAS Board habe ich 2x 16GB ECC 2133er, Samsung. Im Proxmox 4x 32GB ECC Regged und die laufen ganz brav mit 2133. vielleicht ist das Board ja auch zickig mit nicht Regged RAM.

*Edit*
Nevermind, eben gesehen dass dein HMA84GR7AFR4N-UH RAM Regged ist. Dann brauche ich das nicht mit meinem Proxmox RAM testen :/

Aber das Verhalten ist bei mir identisch.

PS ich hatte den schon auf 933 also 1866 im BIOS gesetzt - brachte auch nix.
 
Zuletzt bearbeitet:
ich hab 4 von denen, mom aber nur 2 auf dem Board. Diese Rigel stehen ohne UH in der Liste. die kleinen Details ... hab sie mit Hilfe von @F|Marsman auf 2133 begrenzt. aber so richtig wolle sie noch nicht, nen häufen ECC Fehler und Abstürze. Von was auch immer, NIC Fehler sind auch dabei. So möchte ich das nicht als meinen Unraid Daten, Paperless-ngx und HA Server laufen lassen. Das ist mir zu gefährlich. Ich hab mir das Datenblatt des Herstellers besorgt, mal sehen ob da was geht.


IMG_0080.jpg
 
Die einfachste (ram bezogene) Lösung wäre halt Samsung Riegel zu verwenden. Dieses board ist halt etwas wählerisch bei RAM.

Da scheint hier im Forum ja bis jetzt keiner wirklich Probleme gehabt zu haben.
 
@Paddy600 Wie man es nimmt ;) Ich habe ja 2x Samsung ECCs in dem betroffenen Board -> Samsung 2x16GB (32GB) 2Rx4 PC4-2133P Server RAM ECC DDR4 M393A2G40DB0-CPB0Q

Ok jetzt bin ich verwirrt - der ID des RAMs nach ist das sogar auch ECC Regged (-> Samsung Webseite)

Hier mal aus einem Chat mit ChatGPT was man noch machen könnte:

Da die externe ConnectX-3 SFP+-Karte stabil läuft, scheint das Problem tatsächlich auf die onboard NICs beschränkt zu sein. Hier sind einige weitere Vorschläge:

### 1. **Interrupt-Balancing optimieren**
- Verteile die Interrupts gleichmäßiger, um mögliche Ressourcenprobleme zu minimieren:
Code:
bash
     apt install irqbalance
     systemctl enable irqbalance --now


### 2. **Link-State-Überwachung deaktivieren**
- Die NIC könnte durch fehlerhafte Link-State-Checks in den Ruhezustand wechseln:

Code:
bash
     ethtool -s eth0 wol d


### 3. **Hardware-Fehler ausschließen**
- Teste die onboard NICs unter einem anderen Betriebssystem (z. B. Windows oder einem Linux Live-System), um ein Hardwareproblem sicher auszuschließen.

### 4. **Netzwerkdiagnose erweitern**
- Überwache die onboard NICs mit Tools wie `ip monitor` oder durch Analyse der System-Logs:

Code:
bash
     dmesg | grep -i eth
     journalctl -k | grep e1000e

Falls die onboard NICs trotz aller Tests weiterhin instabil bleiben, könnte es eine Inkompatibilität oder einen Hardware-Defekt geben. In diesem Fall wäre Gigabyte-Support oder ein dauerhafter Wechsel auf die stabile ConnectX-3-Lösung sinnvoll.
Ich mache gerade das Update auf die BMC Version 12.61.21. Vielleicht hilft's ja. F09 haben beide Boards, aber die aktuelle BMC Version nur der Proxmox Server.
 
Zuletzt bearbeitet:
Guten Morgen/Mittag,

ich habe das TrueNAS mit den Änderungen seit gestern durchlaufen lassen, bis 6:00 heute Morgen war alles super, als ich dann gegen 10:30 nochmal nachgeschaut habe, war es dunkel auf der NIC (onboard, unterer Port - das Problem hatte ich aber auch auf dem oberen Port zuvor).

Zum Glück kann ich über die 10G Karte noch per SSH rein. Hier mal der Logauszug:
Code:
Nov 16 10:03:29 truenas kernel: ------------[ cut here ]------------
Nov 16 10:03:29 truenas kernel: NETDEV WATCHDOG: enp5s0 (igb): transmit queue 3 timed out 9248 ms
Nov 16 10:03:29 truenas kernel: WARNING: CPU: 6 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel: Modules linked in: sr_mod(E) cdrom(E) joydev(E) cdc_ether(E) uas(E) usbnet(E) usb_storage(E) mii(E) xt_nat(E) xt_tcpudp(E) veth(E) xt_conntrack(E) nft_chain_nat(E) xt_MASQUERADE(E) nf_nat(E) nf_conntrack_netlink(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) xfrm_user(E) xfrm_algo(E) xt_addrtype(E) nft_compat(E) nf_tables(E) libcrc32c(E) crc32c_generic(E) nfnetlink(E) br_netfilter(E) bridge(E) stp(E) llc(E) nvme_fabrics(E) nvme_core(E) overlay(E) sunrpc(E) binfmt_misc(E) ntb_netdev(E) ntb_transport(E) ntb_split(E) ntb(E) ioatdma(E) ipmi_ssif(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) kvm(E) irqbypass(E) ghash_clmulni_intel(E) sha512_ssse3(E) sha256_ssse3(E) sha1_ssse3(E) aesni_intel(E) crypto_simd(E) cryptd(E) rapl(E) snd_hda_intel(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) evdev(E) ast(E) snd_timer(E) snd(E) drm_shmem_helper(E) acpi_cpufreq(E) pcspkr(E) sp5100_tco(E) soundcore(E) k10temp(E) drm_kms_helper(E) watchdog(E)
Nov 16 10:03:29 truenas kernel:  ccp(E) acpi_ipmi(E) ipmi_si(E) ipmi_devintf(E) ipmi_msghandler(E) button(E) sg(E) loop(E) efi_pstore(E) drm(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) zfs(POE) spl(OE) efivarfs(E) mlx4_ib(E) ib_uverbs(E) ib_core(E) mlx4_en(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) t10_pi(E) crc64_rocksoft(E) crc64(E) crc_t10dif(E) crct10dif_generic(E) ahci(E) ahciem(E) libahci(E) libata(E) xhci_pci(E) crct10dif_pclmul(E) crct10dif_common(E) crc32_pclmul(E) xhci_hcd(E) scsi_mod(E) crc32c_intel(E) i2c_piix4(E) scsi_common(E) igb(E) usbcore(E) usb_common(E) i2c_algo_bit(E) mlx4_core(E) dca(E)
Nov 16 10:03:29 truenas kernel: CPU: 6 PID: 0 Comm: swapper/6 Tainted: P           OE      6.6.44-production+truenas #1
Nov 16 10:03:29 truenas kernel: Hardware name: GIGABYTE G431-MM0-OT/MJ11-EC1-OT, BIOS F09 09/14/2021
Nov 16 10:03:29 truenas kernel: RIP: 0010:dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel: Code: ff ff ff 48 89 df c6 05 b6 26 40 01 01 e8 f3 2c fa ff 45 89 f8 44 89 f1 48 89 de 48 89 c2 48 c7 c7 60 f9 d1 9b e8 cb 16 6b ff <0f> 0b e9 2a ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90
Nov 16 10:03:29 truenas kernel: RSP: 0018:ffffa0b600600e70 EFLAGS: 00010286
Nov 16 10:03:29 truenas kernel: RAX: 0000000000000000 RBX: ffff8fbdea82c000 RCX: 0000000000000000
Nov 16 10:03:29 truenas kernel: RDX: ffff8fc4bd3adb00 RSI: ffff8fc4bd3a13c0 RDI: 00000000000400f6
Nov 16 10:03:29 truenas kernel: RBP: ffff8fbdea82c488 R08: 0000000000000000 R09: ffffa0b600600cf8
Nov 16 10:03:29 truenas kernel: R10: 0000000000000003 R11: ffff8fc4bd1fffe8 R12: ffff8fc1682843c0
Nov 16 10:03:29 truenas kernel: R13: ffff8fbdea82c3dc R14: 0000000000000003 R15: 0000000000002420
Nov 16 10:03:29 truenas kernel: FS:  0000000000000000(0000) GS:ffff8fc4bd380000(0000) knlGS:0000000000000000
Nov 16 10:03:29 truenas kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 16 10:03:29 truenas kernel: CR2: 00007f6aeaffdd58 CR3: 0000000192988000 CR4: 00000000003506e0
Nov 16 10:03:29 truenas kernel: Call Trace:
Nov 16 10:03:29 truenas kernel:  <IRQ>
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? __warn+0x81/0x130
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? report_bug+0x171/0x1a0
Nov 16 10:03:29 truenas kernel:  ? apic_mem_wait_icr_idle+0x14/0x20
Nov 16 10:03:29 truenas kernel:  ? handle_bug+0x41/0x70
Nov 16 10:03:29 truenas kernel:  ? exc_invalid_op+0x17/0x70
Nov 16 10:03:29 truenas kernel:  ? asm_exc_invalid_op+0x1a/0x20
Nov 16 10:03:29 truenas kernel:  ? dev_watchdog+0x235/0x240
Nov 16 10:03:29 truenas kernel:  ? __pfx_dev_watchdog+0x10/0x10
Nov 16 10:03:29 truenas kernel:  call_timer_fn+0x27/0x130
Nov 16 10:03:29 truenas kernel:  ? __pfx_dev_watchdog+0x10/0x10
Nov 16 10:03:29 truenas kernel:  __run_timers+0x222/0x2c0
Nov 16 10:03:29 truenas kernel:  run_timer_softirq+0x1d/0x40
Nov 16 10:03:29 truenas kernel:  handle_softirqs+0xda/0x2c0
Nov 16 10:03:29 truenas kernel:  __irq_exit_rcu+0x98/0xc0
Nov 16 10:03:29 truenas kernel:  sysvec_apic_timer_interrupt+0x72/0x90
Nov 16 10:03:29 truenas kernel:  </IRQ>
Nov 16 10:03:29 truenas kernel:  <TASK>
Nov 16 10:03:29 truenas kernel:  asm_sysvec_apic_timer_interrupt+0x1a/0x20
Nov 16 10:03:29 truenas kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x440
Nov 16 10:03:29 truenas kernel: Code: 8a 7d 53 ff e8 35 f4 ff ff 8b 53 04 49 89 c5 0f 1f 44 00 00 31 ff e8 f3 b9 52 ff 45 84 ff 0f 85 57 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 85 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d
Nov 16 10:03:29 truenas kernel: RSP: 0018:ffffa0b6000f7e90 EFLAGS: 00000246
Nov 16 10:03:29 truenas kernel: RAX: ffff8fc4bd3b3440 RBX: ffff8fbde9f28400 RCX: 000000000000001f
Nov 16 10:03:29 truenas kernel: RDX: 0000000000000006 RSI: 000000002f684d00 RDI: 0000000000000000
Nov 16 10:03:29 truenas kernel: RBP: 0000000000000002 R08: 0000000000000002 R09: 0000000000000501
Nov 16 10:03:29 truenas kernel: R10: 0000000000000018 R11: ffff8fc4bd3b1fe4 R12: ffffffff9c5a6380
Nov 16 10:03:29 truenas kernel: R13: 000041ff1040fd35 R14: 0000000000000002 R15: 0000000000000000
Nov 16 10:03:29 truenas kernel:  cpuidle_enter+0x2d/0x40
Nov 16 10:03:29 truenas kernel:  do_idle+0x20d/0x270
Nov 16 10:03:29 truenas kernel:  cpu_startup_entry+0x2a/0x30
Nov 16 10:03:29 truenas kernel:  start_secondary+0x11e/0x140
Nov 16 10:03:29 truenas kernel:  secondary_startup_64_no_verify+0x18f/0x19b
Nov 16 10:03:29 truenas kernel:  </TASK>
Nov 16 10:03:29 truenas kernel: ---[ end trace 0000000000000000 ]---
Nov 16 10:03:29 truenas kernel: igb 0000:05:00.0 enp5s0: Reset adapter

Klar, ohne Netzwerk kein NTP, was er dann auch beanstandet, zumindest der Plex Container:

Code:
Nov 16 11:00:13 truenas dockerd[4475]: time="2024-11-16T11:00:13.138646511+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.16.1.2:52395" dns-server="udp:10.0.0.1:53" error="read udp 172.16.1.2:52395->10.0.0.1:53: i/o timeout" question=";plex.tv.\tIN\t AAAA"
Nov 16 11:00:13 truenas dockerd[4475]: time="2024-11-16T11:00:13.138630201+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.16.1.2:47939" dns-server="udp:10.0.0.1:53" error="read udp 172.16.1.2:47939->10.0.0.1:53: i/o timeout" question=";plex.tv.\tIN\t A"

Auf 10.0.0.1 läuft bei mir der UniFi Cloud Gateway Ultra auf dem auch DNS und NTP laufen.

Für mich sieht das Log oben irgendwie aus wie nen "kleiner" Kernel Panic, Hardwarefehler würde ich sagen.

Ich glaube mit dem Board bin ich durch. Ich werde heute meine 3x 18TB schnappen und das NAS dann im Proxmox System virtualisieren, wobei ich noch mit mir hadere ob es nun Xpenology (läuft im Test mit meinen 2x 6TB WDs einwandfrei) oder TrueNAS Scale wird (dann bräuchte ich den zpool nur importieren). Ein Fan von TrueNAS bin ich allerdings nicht wirklich, weil ich mich mit den Backups schwer tu, bei DSM steckste ne USB Platte an, Hyper Backup -> da hin. Fertig. Bei TrueNAS geht es wohl ähnlich mit ner Snapshot Replikation - aber da müsste ich mich belesen.

Nochmal zusammengefasst was ich ausprobiert hatte:
  • anderen NIC Port ausprobiert
  • BMC Firmware aktualisiert auf die neuste Version
  • CMOS & BIOS Reset
  • BMC Reset
  • BMC NIC auf "dedicated" gestellt
  • Netzteil Reset
  • RAM auf 933/1866 gedrosselt im BIOS
Ich glaube mehr kann ich jetzt von meiner Seite aus nicht mehr machen. Auch wenn es blöd ist, aber so werde ich das Board dem Händler wohl zurückgeben müssen.

Positiv ist allerdings: das virtualisieren des NAS klappt so wunderbar, dass es mir auch ordentlich Strom sparen wird + ich kann Snapshots vor Updates machen, zumal ich die komplette Perfomance von dem Epyc nicht für nen NAS "vergeude".

Leider hat es die PostNL noch nicht geschafft den 8i auf PCIe x8 Adapter an unsere Post zu übergeben, so dass ich dann wohl ein paar Tage auf die 10G verzichten muss. Ist zum "Betanken" des NAS dann natürlich doof ;) Oder ich gedulde mich bis das hier ist.

---
Als ob der Post noch nicht lang genug wäre, habe ich nochmal alles bei ChatGPT eingeworfen und der hat folgendes empfohlen:
Die Fehlermeldung im Syslog deutet auf einen Timeout der Transmit-Queue und einen Reset des Adapters hin. Es könnte mehrere Ursachen geben, darunter Hardware-Fehler, Firmware-Fehler oder Treiberprobleme. Folgende Ansätze könnten helfen:

---

### **1. Power Management deaktivieren**
Die **igb**-Treiber könnten durch Energiesparfunktionen instabil werden. Deaktiviere Power-Management-Optionen für die betroffenen NICs:

Code:
ethtool -K enp5s0 tx off tso off gso off gro off


Zum Testen kannst du diese Einstellungen in `/etc/network/interfaces` oder in einer anderen netzwerkbezogenen Konfigurationsdatei für den Bootvorgang dauerhaft machen.

---

### **2. Offloading deaktivieren**
Deaktiviere TCP-Offloading, da dies häufig mit NICs wie **igb** Probleme verursacht:

Code:
ethtool -K enp5s0 rx off tx off

---

### **3. Kernel-Parameter anpassen**
Ergänze folgende Parameter beim Bootvorgang in der GRUB-Konfiguration (`/etc/default/grub`):

Code:
GRUB_CMDLINE_LINUX="pci=noaer pcie_aspm=off"


Aktualisiere GRUB anschließend:

Code:
update-grub
reboot

Diese Parameter deaktivieren ASPM (Active State Power Management) und unterdrücken PCI-Fehlermeldungen.

---

### **4. Treiber-Spezifische Einstellungen**
Passe die Interrupt-Moderation für den **igb**-Treiber an, was die Stabilität erhöhen könnte:


Code:
echo "options igb InterruptThrottleRate=1,1" > /etc/modprobe.d/igb.conf
update-initramfs -u
reboot
Anmerkung: Das klappt in TrueNAS Scale nicht:

Code:
root@truenas:~# update-initramfs -u
ln: failed to create hard link '/boot/initrd.img-6.6.44-production+truenas.dpkg-bak': Read-only file system
cp: cannot create regular file '/boot/initrd.img-6.6.44-production+truenas.dpkg-bak': Read-only file system

---

### **5. Test mit anderem Kernel**
Teste einen alternativen Kernel (z. B. einen LTS-Kernel), da Fehler in neuen Kernel-Versionen nicht ausgeschlossen sind. Du kannst dies mit TrueNAS einfach umsetzen, indem du eine andere Version bootest.

---

### **6. Hardware-Überprüfung**
Da der Fehler auch bei anderen Mainboards mit diesem Chipsatz auftritt, könnte es ein spezifisches Problem mit der Hardware sein. Wenn Gigabyte den Fehler nicht beheben kann, bleibt die Nutzung eines externen NICs (z. B. deiner ConnectX-3-Karte) eine stabile Lösung.

---

Falls das Problem weiterhin besteht, könnten Logs von `dmesg` während des Ausfalls helfen, weitere Einblicke zu erhalten.
 
Zuletzt bearbeitet:
Also ich hab das Board jetzt seit mehr als 6 Monaten mit TrueNAS Scale am laufen und hatte nie Probleme mit dem LAN. Ohne irgendwelche Settings etc. Zu ändern.

Wenn es bei Dir also out of the box nicht geht, dann wird wohl einfach dein Board ne Macke haben.

Aber unabhängig davon, würde ich sowieso empfehlen die 10G Karte für das Netzwerk zu nehmen. Die Dinger sind einfach viel zuverlässiger als die internen.
 
Da fehlt mir leider aktuell der 10G Switch für :d

Ich habe aktuell eine Direktverbindung mit nem 30m Kabel von meinem Arbeitszimmer aus in den Keller direkt in die 10G Karte. Da ich vor kurzem erst auf UniFi im ganzen Haus umgestellt habe und in dem Zuge auch den PC meiner Frau und meines Kindes auf 2,5G anheben würde, wäre ich direkt mal eben knappe 480€ für sowas hier los: Ubiquiti UniFiSwitch Enterprise 8 Desktop 2.5G Managed Switch, 8x RJ-45, 2x SFP+, 120W PoE+

Klar, da könnte mal sein einen Zyxel zwischen setzen oder den Mikrotik mit 4x SFP+, aber fände ich dann irgendwie "doof".

---

Ist es nicht "merkwürdig", dass ausgerechnet die Intel Karten (igb Treiber) hier die AER Fehler melden?

1731761072272.png


---
Na immerhin ist die Verbindung zwischen dem nun virtualisierten NAS (TrueNAS Scale) und einer anderen VM (Win Server 2022) recht zügig :oops: (auf dem gleichen Host natürlich)

1731761444550.png
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Ich beiß echt noch in meinen Tisch. Adapter da, läuft, erst mal fliegend getestet. So weit so gut, also ran an den Einbau...
MEIN VERFICKTES NETZTEIL HAT NUR DURCHGEHENDE ODER ZUR FALSCHEN SEITE ABGEWINKELTE SATA STROMSTECKER FFFFFFFFFFFFFFFFFFFSSSSSSSSSSSS FICK DICH DU FICKENDER FICK FICK WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Sorry, das musste jetzt einfach raus. Ich schau dann mal nach ner 20cm Sata Strom Verlängerung...
 
Haste etwa kein Material zum selber Crimpen da oder wat? Wenne so unprofessionell in der Weltgeschichte rumgammelst, darfste Dich aber echt nicht uffrege… ;)
 
Ogott Sata hab ich das letzte mal vor ~8 Jahren gecrimpt, und mein ganzes Crimpzeug ist zusammen mit dem Wakü-Zeugs in den Keller verbannt - dafür ist mir meine Freizeit mittlerweile zu schade. Verlängerung ist schon bestellt.
 
Na bitte. Also hasse NOCH weniger Grund Dich aufzuregen, alles wasse brauchst is im Keller und Du bist nur zu faul, mal die zwei Treppen runterzustiefeln… nähnäh, so jibt dat nix.
 
Noch ein kleines Update von meiner Seite.
Ich habe mir mittlerweile einen anderen RAM Riegel (Samsung M393A4K40BB2-CPB4Q) besorgt. Damit startet das Board ohne Probleme.
Wenn ich beide Riegel verbaue (Samsung + SK Hynix HMA82GR7JJR4N), wird nur der Samsung Riegel erkannt. Die Position der Riegel ist dabei egal.
Wenn man den Bios Jumper im Reset Modus belässt, startet das Board auch mit dem SK Hynix, zumindest in Endlosschleife bis man ins Bios kommt.

@F|Marsman
Das Mod-Bios läuft bei mir problemlos. Danke für die Arbeit.

Kann es sein, das die Einstellung cTDP im Bios keine Auswirkungen hat?

Zunächst mal: erstmal per SSH einen neuen Nutzer anlegen (und die SKU Einträge korrigieren), bevor Du das BMC updatest. Danach ist das schwer bis unmöglich.
Im Update-Wahn habe ich auch das neue BMC geflasht und leider den Hinweis vergessen. Gibt es eine Möglichkeit dies noch zu ändern oder bleibt nur die Variante Y-Adapter für die Lüfter?
 
Ich habe mir die Mühe gemacht und das NAS Board nochmal neu mit TrueNAS Scale installiert und diese beiden Befehle nach dem Installation ausgeführt:

Code:
ethtool -K enp5s0 tx off tso off gso off gro off
ethtool -K enp5s0 rx off tx off

Bis eben lief es (25:30h immerhin!). Dann habe ich eine Datei hingeschoben und schwupps war er offline. Ich habe jetzt den Brei echt auf :cautious: und werde das Teil retournieren. Fernabsatzgesetz lässt grüßen. Das war jetzt jede Menge Zeit die ich dort reininvestiert habe. Virtualisiert mit den Platten durchgereicht auf meinem Proxmox MJ11 läuft Xpenology absolut gut.

---
Update: Bekomme ein "neues" Board als Ersatz von denen. Finde ich nett - unkompliziert. Ich hoffe das läuft dann auch :)
 
Zuletzt bearbeitet:
Moin,

funktionieren bei jemanden der x8 und der x4 als pcie zeitgleich? Ich nutze in meinem PVE die QM2-2P2G2T erfolgreich am x8 Port.
Am x4 Port habe ich vorhin das QDA-U2MP eingebaut, bestückt mit zwei SSDs. Diese werden im BIOS auch erkannt, allerdings wird von der anderen Karte dann nicht mehr die Netzwerkkarte erkannt, zumindest bekommt sie keine IP mehr, von den in der Karte eingebauten SSDs startet der PVE allerdings.

Woran kann so ein Verhalten liegen?
 
Würd mich wundern wenn der 4i nu auch noch Bifurcation könnte, wenn der 8i das schon nicht wirklich will :fresse:
Aber eine PCIe Karte in jedem Slot geht jedenfalls. Wenn ich das aber richtig sehe haben beide QNAP Karten nen PCIe Switch. Was in der Theorie auch funktionieren sollte... allerdings so zickig wie das Board mit PCIe Karten und RAM ist würd ich da nicht meine Hand für ins Feuer legen :shot:
Spaßeshalber mal die Karten getauscht? Könnt auch irgend nen IRQ Problem, bzw. generell eher Software sein.
 
Also die Nic/ssd qnap hatte ich vorher im 4i Anschluss, lief auch ohne Probleme, hatte die nur umgebaut, weil ich diese China sfp+ Karte mir gekauft habe und die ohne m.2 Adapter direkt im 4i nutzen wollte 1 ohne Erfolg. Da das andere keine Karte ist, sondern ein u.2 Gehäuse, muss ich erstmal schauen, wie ich die am besten am 8i testen könnte.
Hab auch schon den Gedanken gehabt, ob das trotz PLX Chips zu viele pcie Geräte sind, auch wenn die mining server ja 10 GPUs am 8i hatten.. Und ja, eine kleine Zicke ist das Biest schon ^^
---
Argh, da hat man eine einfache Idee, wie man es noch testen könnte, und dann, bei all den Bestellungen für dieses Board, bringe ich ausgerechnet genau das wieder zur Post, was ich jetzt bräuchte xD. Nu ja, also erneut bestellt. https://www.amazon.de/gp/product/B0BDZLFHZR/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1, dann werde ich das Teil mal im m.2 Slot testen, da ist nur meine slog optane drin, also simpel zu deaktivieren.
 
Zuletzt bearbeitet:
Argh, da hat man eine einfache Idee, wie man es noch testen könnte, und dann, bei all den Bestellungen für dieses Board, bringe ich ausgerechnet genau das wieder zur Post, was ich jetzt bräuchte xD. Nu ja, also erneut bestellt. https://www.amazon.de/gp/product/B0BDZLFHZR/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1, dann werde ich das Teil mal im m.2 Slot testen, da ist nur meine slog optane drin, also simpel zu deaktivieren.
Was genau tut das Teil? m2 nach m2? Das sieht für mich nach nem Riser aus mit dem man die m2 dann "extern" nutzen kann. hä? :unsure:
 
Was genau tut das Teil?
Im Grunde ist das einfach eine Verlängerung für den m.2 Slot. Kann man z. B. nutzen, falls die SSD zu warm werden sollte am eigentlichen Platz, Kühler zu hoch etc. In meinem Fall geht es darum, dass der m.2 Adapter für das Board den 4i Anschluss hat, und ich so das Qnap Gehäuse mit dem u.2 zu 4i Kabel direkt daran anschließen kann und testen kann, ob da dann auch meine o.g Problematik auftritt oder nicht. Wenn es geht, kann ich mit dem 4i Kabel und der anderen Platine meine m.2 Optane SSD an dem 4i Anschluss testen, ob das dann ggf. auch geht, und am Ende hätte ich alles verbaut, was ich stand, jetzt testen will. Nur eben etwas anders angeschlossen ^^.
 
Zuletzt bearbeitet:
S8B auf 2666 laufen lassen, was ne Verschwendung :shot:
Bei so niedrigem Takt hilft wohl nur Stück für Stück testen was mit den 1,2V möglich ist. Eventuell auch 2933/3200 probieren... Grundsätzlich kann man sich da wohl an die Ryzen RAM OC Anleitung halten. Zen1 ists ja eh.. Würd mich mal interessieren ob die auch so rumzicken dass er die CL immer +1 oder +2 setzt.
Weiß selbst nicht was meine S8B bei so niedrigem Takt und Spannung können, unter 3200CL14 haben die auch nie gesehen.

Kann ich so bestätigen meine Samsung B-Die laufen jetzt im Stock ohne was umzustellen auf CL21-19-19-43. Der hat mein tCL einfach +2 gesetzt.
 
Muss ich im BIOS für den 8i Port irgendwas aktivieren? Ich habe den Adapter aus China von 8i (+ SATA Power) auf PCIe x8 in x16 heute bekommen und meine Mellanox ConnectX-3 eingebaut. Leider bekomme ich die NIC in TrueNAS Scale per "lspci" nicht angezeigt.

Laut Handbuch müsste ich das hier einstellen können (s.o.), leider habe ich die Option mit F09er BIOS gar nicht.

1732187005372.png


Ausprobiert:
- andere NIC (Intel GBit PCIe x1)
- anderen SATA Power Stecker am Netzteil
- Gigabyte 8i Kabel mal gedreht

Bisher alles ohne Erfolg.

---
Ich habe nach dem Tipp von @Ceiber3 in diesem Post hier das BIOS auf F02 geflashed und zumindest im BIOS kann ich nun PCIe einstellen.
Allerdings wird die NIC auch jetzt nicht erkannt. Hmm.
---
So langsam dämmert mir, dass diese Einstellung evtl. nur den 4i Port an den SATA Ports umschaltet, kann das? Mein Adapter hängt aktuell am 8i Port.

@F|Marsman Ich glaube du hast den selben Adapter verwendet - vielleicht kannst du mir was zu evtl. BIOS-Einstellungen sagen :)

Kleine Info noch zu dem "KALEA-INFORMATIQUE Riser-Verlängerung Adapter für M2 PCIe NVMe M Key Port auf PCIe x16" den ich empfohlen hatte. Mir ist jetzt bei dem zweiten Adapter von denen das PCIe-Verbindungskabel direkt an der Platine unten gerissen. Also: Finger weg :/
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh