mgutt

You quoted already one: Marvell 88SE9172 chip But its only for the back panel regarding the description. And regarding your question: Tools > System Devices.

These Kernel settings are needed to get NVMe / U.2 Hotplug Support: CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_HOTPLUG_PCI=y At the moment Unraid does not support Hotplug: root@Tower:~# grep HOT /usr/src/linux-*/.config CONFIG_TICK_ONESHOT=y CONFIG_HOTPLUG_CPU=y # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set # CONFIG_DEBUG_HOTPLUG_CPU0 is not set CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_HOTPLUG_MEMORY=y CONFIG_ACPI_HOTPLUG_IOAPIC=y CONFIG_HOTPLUG_SMT=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_MEMORY_HOTPLUG=y # CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set CONFIG_MEMORY_HOTREMOVE=y # CONFIG_HOTPLUG_PCI is not set CONFIG_DM_SNAPSHOT=m # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y CONFIG_XEN_MEMORY_HOTPLUG_LIMIT=512 # CONFIG_WIRELESS_HOTKEY is not set # CONFIG_SURFACE_HOTPLUG is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set # CONFIG_TRACER_SNAPSHOT is not set Maybe this allows dGPU Hotplugging, too 🤷‍♂️

Ne, leider bekomme ich das mit dem PCI Hot-Plug nicht hin. Ich habe noch versucht die Devices einzeln zu entfernen: root@Tower:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/remove root@Tower:~# Jan 1 20:56:05 Tower kernel: pci 0000:01:00.1: Removing from iommu group 1 root@Tower:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/remove root@Tower:~# Jan 1 20:56:23 Tower kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=none,decodes=io+mem:owns=io+mem Jan 1 20:56:23 Tower kernel: pci 0000:01:00.0: Removing from iommu group 1 root@Tower:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/remove root@Tower:~# Jan 1 20:56:41 Tower kernel: pci_bus 0000:01: busn_res: [bus 01] is released Jan 1 20:56:41 Tower kernel: pci 0000:00:01.0: Removing from iommu group 1 aber nach Aus- und Einstecken des Stromkabels und rescan: echo 1 > /sys/bus/pci/rescan Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: [8086:1901] type 01 class 0x060400 Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: PME# supported from D0 D3hot D3cold Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: Adding to iommu group 1 Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: [10de:2507] type 00 class 0x030000 Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00ffffff] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x14: [mem 0x00000000-0x0fffffff 64bit pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x01ffffff 64bit pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x24: [io 0x0000-0x007f] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256) Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: PME# supported from D0 D3hot Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x8 link at 0000:00:01.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link) Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: vgaarb: bridge control possible Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none Jan 1 21:00:40 Tower kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: Adding to iommu group 1 Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: [10de:228e] type 00 class 0x040300 Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: reg 0x10: [mem 0x00000000-0x00003fff] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: Max Payload Size set to 256 (was 128, max 256) Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: Adding to iommu group 1 Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: ASPM: current common clock configuration is inconsistent, reconfiguring Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: PCI bridge to [bus 01] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [io 0x3000-0x3fff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [mem 0x63000000-0x640fffff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [mem 0x50000000-0x61ffffff 64bit pref] Jan 1 21:00:40 Tower kernel: clipped [mem size 0x00000000 64bit pref] to [mem size 0xfffffffffffa0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: clipped [mem size 0xfffffffffffc0000 64bit pref] to [mem size 0xfffffffffffa0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: clipped [mem size 0x00020000 64bit pref] to [mem size 0xfffffffffffc0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: clipped [mem size 0x00010000 64bit pref] to [mem size 0xffffffffffff0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 15: assigned [mem 0x68000000-0x7fffffff 64bit pref] Jan 1 21:00:40 Tower kernel: clipped [mem size 0x00020000] to [mem size 0xfffffffffffc0000] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: clipped [mem size 0x00010000] to [mem size 0xffffffffffff0000] for e820 entry [mem 0x0009f000-0x000fffff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 14: assigned [mem 0x50000000-0x517fffff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 13: assigned [io 0x3000-0x3fff] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 1: assigned [mem 0x70000000-0x7fffffff 64bit pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 3: assigned [mem 0x68000000-0x69ffffff 64bit pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 0: assigned [mem 0x50000000-0x50ffffff] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 6: assigned [mem 0x51000000-0x5107ffff pref] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: BAR 0: assigned [mem 0x51080000-0x51083fff] Jan 1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 5: assigned [io 0x3000-0x307f] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: PCI bridge to [bus 01] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [io 0x3000-0x3fff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [mem 0x50000000-0x517fffff] Jan 1 21:00:40 Tower kernel: pci 0000:00:01.0: bridge window [mem 0x68000000-0x7fffffff 64bit pref] Jan 1 21:00:40 Tower kernel: pcieport 0000:00:01.0: AER: enabled with IRQ 122 Jan 1 21:00:40 Tower kernel: pci 0000:01:00.1: D0 power state depends on 0000:01:00.0 kommt es zum selben Fehler: root@Tower:~# virsh start Ubuntu22 Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none Jan 1 21:02:10 Tower kernel: br0: port 2(vnet1) entered blocking state Jan 1 21:02:10 Tower kernel: br0: port 2(vnet1) entered disabled state Jan 1 21:02:10 Tower kernel: device vnet1 entered promiscuous mode Jan 1 21:02:10 Tower kernel: br0: port 2(vnet1) entered blocking state Jan 1 21:02:10 Tower kernel: br0: port 2(vnet1) entered forwarding state Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003) Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x26@0xc1c Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x27@0xd00 Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x25@0xe00 Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e Jan 1 21:02:10 Tower kernel: vfio-pci 0000:01:00.1: enabling device (0000 -> 0002) Jan 1 21:02:11 Tower kernel: vfio-pci 0000:01:00.1: vfio_ecap_init: hiding ecap 0x25@0x160 Domain 'Ubuntu22' started root@Tower:~# Jan 1 21:02:11 Tower avahi-daemon[3680]: Joining mDNS multicast group on interface vnet1.IPv6 with address fe80::fc54:ff:fee3:8fe8. Jan 1 21:02:11 Tower avahi-daemon[3680]: New relevant interface vnet1.IPv6 for mDNS. Jan 1 21:02:11 Tower avahi-daemon[3680]: Registering new address record for fe80::fc54:ff:fee3:8fe8 on vnet1.*. Jan 1 21:02:11 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e Message from syslogd@Tower at Jan 1 21:02:16 ... kernel:Disabling IRQ #17 Jan 1 21:02:16 Tower kernel: irq 17: nobody cared (try booting with the "irqpoll" option) Jan 1 21:02:16 Tower kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.19.17-Unraid #2 Jan 1 21:02:16 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. C246M-WU4/C246M-WU4-CF, BIOS F4 02/03/2021 Jan 1 21:02:16 Tower kernel: Call Trace: Jan 1 21:02:16 Tower kernel: <IRQ> Jan 1 21:02:16 Tower kernel: dump_stack_lvl+0x44/0x5c Jan 1 21:02:16 Tower kernel: __report_bad_irq+0x35/0xaa Jan 1 21:02:16 Tower kernel: note_interrupt+0x1f6/0x24d Jan 1 21:02:16 Tower kernel: handle_irq_event_percpu+0x2c/0x35 Jan 1 21:02:16 Tower kernel: handle_irq_event+0x37/0x56 Jan 1 21:02:16 Tower kernel: handle_fasteoi_irq+0x99/0x113 Jan 1 21:02:16 Tower kernel: __common_interrupt+0x9b/0xaa Jan 1 21:02:16 Tower kernel: common_interrupt+0x96/0xc1 Jan 1 21:02:16 Tower kernel: </IRQ> Jan 1 21:02:16 Tower kernel: <TASK> Jan 1 21:02:16 Tower kernel: asm_common_interrupt+0x22/0x40 Jan 1 21:02:16 Tower kernel: RIP: 0010:cpuidle_enter_state+0x11b/0x1e4 Jan 1 21:02:16 Tower kernel: Code: 5b fa a1 ff 45 84 ff 74 1b 9c 58 0f 1f 40 00 0f ba e0 09 73 08 0f 0b fa 0f 1f 44 00 00 31 ff e8 9d a9 a6 ff fb 0f 1f 44 00 00 <45> 85 ed 0f 88 9e 00 00 00 48 8b 04 24 49 63 cd 48 6b d1 68 49 29 Jan 1 21:02:16 Tower kernel: RSP: 0018:ffffc9000011fe98 EFLAGS: 00000246 Jan 1 21:02:16 Tower kernel: RAX: ffff8884ac4c0000 RBX: 0000000000000001 RCX: 0000000000000000 Jan 1 21:02:16 Tower kernel: RDX: ffffe8ff00000000 RSI: ffffffff820d7be1 RDI: ffffffff820d80c1 Jan 1 21:02:16 Tower kernel: RBP: ffff8884ac4f5420 R08: 0000000000000002 R09: 0000000000000002 Jan 1 21:02:16 Tower kernel: R10: 00000000000000f1 R11: 0000000000000008 R12: ffffffff82315740 Jan 1 21:02:16 Tower kernel: R13: 0000000000000001 R14: 0000013681b08cc0 R15: 0000000000000000 Jan 1 21:02:16 Tower kernel: ? cpuidle_enter_state+0xf5/0x1e4 Jan 1 21:02:16 Tower kernel: cpuidle_enter+0x2a/0x38 Jan 1 21:02:16 Tower kernel: do_idle+0x187/0x1f5 Jan 1 21:02:16 Tower kernel: cpu_startup_entry+0x1d/0x1f Jan 1 21:02:16 Tower kernel: start_secondary+0xeb/0xeb Jan 1 21:02:16 Tower kernel: secondary_startup_64_no_verify+0xce/0xdb Jan 1 21:02:16 Tower kernel: </TASK> Jan 1 21:02:16 Tower kernel: handlers: Jan 1 21:02:16 Tower kernel: [<00000000476faa67>] vfio_intx_handler Jan 1 21:02:16 Tower kernel: Disabling IRQ #17 EDIT1: Demnach dürfte "remove" nicht ausreichend sein: https://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt The 'remove' file is used to remove the PCI device, by writing a non-zero integer to the file. This does not involve any kind of hot-plug functionality, e.g. powering off the device. The device is removed from the kernel's list of PCI devices, the sysfs directory for it is removed, and the device will be removed from any drivers attached to it. Removal of PCI root buses is disallowed. Und wenn ich diese Präsentation richtig verstehe, dann kann Unraid kein Hot-Plug, weil es schlicht nicht aktiv ist: root@Tower:~# grep HOT /usr/src/linux-*/.config CONFIG_TICK_ONESHOT=y CONFIG_HOTPLUG_CPU=y # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set # CONFIG_DEBUG_HOTPLUG_CPU0 is not set CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_HOTPLUG_MEMORY=y CONFIG_ACPI_HOTPLUG_IOAPIC=y CONFIG_HOTPLUG_SMT=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_MEMORY_HOTPLUG=y # CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set CONFIG_MEMORY_HOTREMOVE=y # CONFIG_HOTPLUG_PCI is not set CONFIG_DM_SNAPSHOT=m # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y CONFIG_XEN_MEMORY_HOTPLUG_LIMIT=512 # CONFIG_WIRELESS_HOTKEY is not set # CONFIG_SURFACE_HOTPLUG is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set # CONFIG_TRACER_SNAPSHOT is not set Laut der Präsentation braucht es dafür nämlich die Kernel Configs: CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_HOTPLUG_PCI=y Ich probiere jetzt schon mal diese Kernel Flags, vielleicht hilft es ja: pci=realloc,assign-busses,use_crs EDIT2: Nein, hilft leider auch nicht. Ich denke die Rahmenbedingungen erlauben das einfach nicht.

The only Synology NAS which supported sleep + wake-up on access was the DS213+/DS413. It was called "Deep Sleep" and this feature was canceled as it was unreliable. And even if you have QNAP NAS which supports S3, it will never wake up on "drive access". S3 means dead/offline. So "every other OS" is simply false. If you want S3, you MUST wake up the server through WoL or similar.

Ok, dann öffnet mal bitte Powershell und führe folgendes aus: curl.exe -sLk https://deine.domain.de | findstr title Laut deiner Aussage wird das nun fehlschlagen. Also probieren wir es mal mit der lokalen IP des Proxies: curl.exe -sLk --header "Host: deine.domain.de" https://192.168.123.50/ | findstr title gerne kannst du das dann auch noch mal parallel mit deiner öffentlichen IP probieren: curl.exe -sLk --header "Host: deine.domain.de" https://<public_ip>/ | findstr title

Es gibt nicht "deine IPv6". Es gibt nur deinen IPv6 Prefix. Mit IPv6 hat jeder Client, jeder Container und auch dein Router eine eigene IPv6, daher muss, wenn man IPv6 verwendet, auch die richtige bei der Domain hinterlegt sein. Hat man zb die vom Router hinterlegt, kann man nur die GUI vom Router erreichen und sonst nichts. Der kann den Traffic auch nicht wie bei IPv4 weiterleiten, weil bei IPv6 standardmäßig kein NAT vorgesehen ist. Wenn du ping deinedomain machst, bekommst du dann ebenfalls die IPv6 zurück? Dann nutzt dieser mit hoher Wahrscheinlichkeit nach IPv6. Dann müssten wir prüfen, ob die IPv6 auf das richtige Ziel zeigt. Wenn es eine IPv4 ist und da deine öffentliche, dann ist die Wahrscheinlichkeit hoch, dass bei dir NAT Loopback vom Router unterbunden wird.

Do you? Can't see your (better) result from a different Linux distribution?!

Korrekt. Im Skript gibt es dafür diese Einstellung: notification_backup_older_days=30 Man könnte nun für diesen einen Client, den du da hast diese Einstellung zB auf 100 stellen, damit er nur bei 100 Tage alten Backups warnt oder eben 99999, wenn du es gar nicht sehen willst. Sollte ich den Text anpassen? Eher so?

Danke, das probiere ich in jedem Fall auch aus! EDIT1: Die Karte habe ich NICHT an VFIO gebunden und bei einer neuen Ubuntu22 VM durchgeschliffen: Die VM startet problemlos und ich kann Ubuntu auf dem angeschlossenen Monitor sehen. Kurz gewartet und der Verbrauch pendelte sich bei 26,8W (C3) ein. Ubuntu ist aber noch nicht installiert. Bei der Installation habe ich dann Drittanbieter für Grafik ausgewählt, da ich annehme, dass dadurch erst die Nvidia Treiber installiert werden: EDIT2: Ubuntu bootet nicht wegen diesem Bug: https://askubuntu.com/questions/1417618/mtd-device-must-be-supplied-device-name-is-empty Ich lade dann mal Ubuntu 20 🤪 EDIT3: Ubuntu20 ist installiert. Allerdings sehe ich auf der dGPU nur die Meldung "BdsDxe loading/starting Boot004 ubuntu from HD"?! Mag der das nicht, wenn man VNC + dGPU hat 🤨Die dGPU ist auch nicht nach längerer Zeit in den Standby gegangen. Also Bild ist durchgehend zu sehen. EDIT4: Noch mal neu installiert und versehentlich die Sprache bei VNC auf Englisch gestellt. Dann nach der Installation auf Deutsch. Jetzt kann ich mich nicht mehr anmelden, weil das Passwort Buchstaben enthält, die nun völlig anders sind 😅 EDIT5: Noch mal Ubuntu22 installiert und diesmal hat es geklappt. Ich vermute, weil ich nach "Remove the boot medium" die VM erzwungen gestoppt habe, hatte ich irgendwas gekillt. Jedenfalls habe ich nun die ISO drin gelassen und konnte ganz normal rebooten. Diesmal habe ich minimale Installation und ohne Drittanbieter gewählt. Stattdessen installiere ich den Nvidia Treiber über "Aktualisierungen": EDIT6: Den "open Kernel" Treiber hätte ich nicht nehmen dürfen: https://forums.developer.nvidia.com/t/nvidia-smi-no-devices-were-found-on-ubuntu-22-04-lts-dual-boot-with-windows-10-geforce-rtx-3060-intel-corei7/232516 Daher habe ich nun den ohne "open" genommen: EDIT7: Nach Reboot der VM geht der Monitor nun aus. Aber in den Ubuntu Einstellungen kann ich nach wie vor keinen zweiten Monitor sehen 🤨 EDIT8: Über nvidia-smi kann ich aber nun im Gegensatz zu vorher die Karten-Informationen sehen: In den Nvidia Settings zeigt er auch bei "Screens" eine 1: Keine Ahnung wie das hier aussehen muss?! EDIT9: Da ich ja über die virtuelle GPU verbunden bin, frage ich mich gerade, ob man auf diesem Weg überhaupt den Nvidia Monitor aktivieren kann. Ich habe ja die Session an die VNC GPU gebunden... hmmm 🤔 Verbrauchen tut der Server jetzt übrigens 17W. Also der Treiber scheint in jedem Fall aktiv zu sein. Wobei 9W nur für die Karte ohne Ausgabe am Monitor schon hart ist. EDIT10: Also das ist echt unnötig kompliziert. Ich musste jetzt erst mal lernen, dass VNC nicht gleich VNC ist. Also was ich zuerst dachte: Installiere irgendeinen VNC Server und verbinde dich einfach über VNC auf die Ubuntu VM und du siehst das was du auch über Unraids virtuelle VNC GPU siehst. Denkste. Nur bestimmte VNC Server zeigen auch das an, was der User sieht. Die meisten machen eine komplett neue Session auf und man hat quasi einen leeren Desktop und der Bildschirm vom User ist "aus". Nur x11vnc oder RealVNC scheinen es so zu machen, wie man es auch von Teamviewer usw her kennt. x11vnc habe ich nicht zum Laufen gebracht. Der bemängelte ständig, dass display :0 nicht existieren würde. xrandr fand dann plötzlich auch gar keine Displays mehr... also RealVNC installiert und läuft wunderbar. Aber auch hier nur die Verbindung zur virtuellen VNC GPU. Nvidia bliebt tot. Also habe ich die VM heruntergefahren, die VNC GPU entfernt, Nvidia wieder ausgewählt und neu gestartet. Und tada. Jetzt sehe ich auf dem Monitor ein Signal und in den Nvidia Settings ist auch ein "X Screen 0" aufgetaucht: Kann Ubuntu nicht damit umgehen, wenn man zwei Grafikkarten "verbaut" hat?! Weil schlussendlich habe ich doch nichts anderes, wenn man eine vGPU und Nvidia dGPU mitgibt. Wirklich verstehen tue ich das nicht. Jedenfalls ist der Monitor nach 5 Minuten eingeschlafen und der Verbrauch steht bei 17W. EDIT11: Wie alturismo empfahl, habe ich erst das PCI Device rausgeworfen, was auch direkt die Soundkarte rauswirft: Der Verbrauch sinkt dadurch zwar auf 9,8W, aber leider bleibt der C-State bei C3 hängen. Also die PCI-Verbindung scheint weiterhin aktiv zu sein. Dann habe ich den rescan gemacht und die Karte ist wieder da: Leider kommt es aber zu einem Fehler, wenn man die Ubuntu VM startet: Jan 1 20:34:59 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e Message from syslogd@Tower at Jan 1 20:35:04 ... kernel:Disabling IRQ #17 Jan 1 20:35:04 Tower kernel: irq 17: nobody cared (try booting with the "irqpoll" option) Jan 1 20:35:04 Tower kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.19.17-Unraid #2 Jan 1 20:35:04 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. C246M-WU4/C246M-WU4-CF, BIOS F4 02/03/2021 Jan 1 20:35:04 Tower kernel: Call Trace: Jan 1 20:35:04 Tower kernel: <IRQ> Jan 1 20:35:04 Tower kernel: dump_stack_lvl+0x44/0x5c Jan 1 20:35:04 Tower kernel: __report_bad_irq+0x35/0xaa Jan 1 20:35:04 Tower kernel: note_interrupt+0x1f6/0x24d Jan 1 20:35:04 Tower kernel: handle_irq_event_percpu+0x2c/0x35 Jan 1 20:35:04 Tower kernel: handle_irq_event+0x37/0x56 Jan 1 20:35:04 Tower kernel: handle_fasteoi_irq+0x99/0x113 Jan 1 20:35:04 Tower kernel: __common_interrupt+0x9b/0xaa Jan 1 20:35:04 Tower kernel: common_interrupt+0x96/0xc1 Jan 1 20:35:04 Tower kernel: </IRQ> Jan 1 20:35:04 Tower kernel: <TASK> Jan 1 20:35:04 Tower kernel: asm_common_interrupt+0x22/0x40 Jan 1 20:35:04 Tower kernel: RIP: 0010:cpuidle_enter_state+0x11b/0x1e4 Jan 1 20:35:04 Tower kernel: Code: 5b fa a1 ff 45 84 ff 74 1b 9c 58 0f 1f 40 00 0f ba e0 09 73 08 0f 0b fa 0f 1f 44 00 00 31 ff e8 9d a9 a6 ff fb 0f 1f 44 00 00 <45> 85 ed 0f 88 9e 00 00 00 48 8b 04 24 49 63 cd 48 6b d1 68 49 29 Jan 1 20:35:04 Tower kernel: RSP: 0018:ffffc9000011fe98 EFLAGS: 00000246 Jan 1 20:35:04 Tower kernel: RAX: ffff8884ac4c0000 RBX: 0000000000000001 RCX: 0000000000000000 Jan 1 20:35:04 Tower kernel: RDX: ffffe8ff00000000 RSI: ffffffff820d7be1 RDI: ffffffff820d80c1 Jan 1 20:35:04 Tower kernel: RBP: ffff8884ac4f5420 R08: 0000000000000002 R09: 0000000000000002 Jan 1 20:35:04 Tower kernel: R10: 00000000000000f1 R11: 0000000000000008 R12: ffffffff82315740 Jan 1 20:35:04 Tower kernel: R13: 0000000000000001 R14: 000011e4ebf799e9 R15: 0000000000000000 Jan 1 20:35:04 Tower kernel: ? cpuidle_enter_state+0xf5/0x1e4 Jan 1 20:35:04 Tower kernel: cpuidle_enter+0x2a/0x38 Jan 1 20:35:04 Tower kernel: do_idle+0x187/0x1f5 Jan 1 20:35:04 Tower kernel: cpu_startup_entry+0x1d/0x1f Jan 1 20:35:04 Tower kernel: start_secondary+0xeb/0xeb Jan 1 20:35:04 Tower kernel: secondary_startup_64_no_verify+0xce/0xdb Jan 1 20:35:04 Tower kernel: </TASK> Jan 1 20:35:04 Tower kernel: handlers: Jan 1 20:35:04 Tower kernel: [<00000000fa6cd887>] vfio_intx_handler Jan 1 20:35:04 Tower kernel: Disabling IRQ #17 Interrupt 17 ist die Soundkarte. Muss man evtl die Soundkarte erst rauswerfen und dann die Grafikkarte?! root@Tower:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 8: 0 0 0 0 0 1 IR-IO-APIC 8-edge rtc0 9: 0 1845 0 0 0 0 IR-IO-APIC 9-fasteoi acpi 16: 6 0 0 0 0 0 IR-IO-APIC 16-fasteoi i801_smbus, vfio-intx(0000:01:00.0) 17: 0 0 0 203571 0 0 IR-IO-APIC 17-fasteoi vfio-intx(0000:01:00.1) Ich starte mal neu...

Es läuft ein Balance. Den würde ich erstmal abwarten. Kann gut sein, dass BTRFS noch Daten von A nach B verschiebt und daher mehrere Partitionen vorhanden sind.

If you can't boot, this is the only option 😉 They aren't in tmp. They are in /extra. And as I said. I don't think this is your problem. I'm using the package since 6.10 and now with the most recent version without problems.

Ich habe noch eine RTX3050 rumfliegen und nutze die jetzt mal für einen Verbrauchstest beim C246M. Ohne GPU komme ich bekanntlich auf unter 8W. Bei einem ersten Test wollte ich wissen, ob man die GPU nachträglich erst mit dem 8 Pin mit Strom versorgen kann und dann mit folgendem Befehl "zum Leben" erwecken kann, was aber leider nicht funktioniert hat: echo 1 > /sys/bus/pci/rescan Die Idee wäre dann gewesen die dGPU nur bei Bedarf mit Strom zu versorgen und solange zB eine Gaming VM aus ist, überhaupt nicht mit Strom zu versorgen. Dann habe ich mit der dGPU neu gestartet. Das BIOS wählte sie direkt als primäre GPU aus. Das habe ich dann auf die iGPU geändert. Nach dem Booten und ohne Nvidia Treiber sah der Verbrauch dann so aus: Also knapp 25W. Ein HDMI Kabel ist verbunden, aber das Bild bleibt wie erwartet schwarz. Angezeigt wird mir die Karte in IOMMU Gruppe 1 Mehr als C3 ist nicht drin: EDIT1: Ich habe dann den 8-Pin im laufenden Betrieb gezogen. Wieder um zu sehen was passiert. Der Verbrauch sank dadurch auf 9,6W. In der IOMMU Liste ist die Karte nach wie vor zu sehen. Allerdings gibt es diverse Fehler im syslog: EDIT2: Der 8-Pin wurde wieder verbunden. Der Verbrauch des Systems steigt auf gerade mal 10,5W an. Neue Logeinträge gibt es nicht. Ob die Karte funktioniert? Ich habe mal zum Test einen rescan ausgelöst. Die Karte bleibt in der Geräteliste stehen (ich hätte erwartet, dass die jetzt rausfliegt). Update folgt...

Ok wunderbar. Also deine duckdns Domain hat keine IPv6. Also wie du es haben willst. Nun ändere einfach die Kommunikation zwischen NPM und dem Ziel-Container auf http und dann sollte auch der Fehler 500 nicht mehr auftauchen. Der Zugriff auf deine Domain über https sollte ja schon gehen, weil du ja das Let's Encrypt Zertifikat laut NPM schon erfolgreich beantragt hast.

Wenn man googelt, findet man exakt Null zum Vergleich von PCIe 3.0, 4.0 und 5.0, wenn es um "Standardlast" geht. Zwar findet man viel von angeblich gestiegener Effizienz, aber die bezieht sich IMMER auf die schnell erledigte Arbeit bei voller Auslastung. Und ich denke, wenn zB eine Hand voll Docker immer wieder Logs schreiben usw und die SSD dadurch immer mal wieder lesen/schreibend aktiv ist, dass PCIe 3.0 im Vergleich zu 4.0 sparsamer ist, weil eben in beiden Fällen die Lanes komplett aktiv sind, während 3.0 aber dabei weniger Strom zieht. Aber wie gesagt ist das mehr eine Vermutung als ein belegbarer Fakt. Den einzigen Test, den ich kenne, der jemals 3.0 und 4.0 verglichen hat, ist dieser: https://www.anandtech.com/show/16087/the-samsung-980-pro-pcie-4-ssd-review/8 Und tatsächlich war da die 980 Pro bei 3.0 knapp 40% sparsamer im Leerlauf. Wir sprechen da zwar nur von 0,3 W, aber bekanntlich macht es ja die Summe und wer weiß was der Controller mehr zieht, wenn er im 4.0 Modus "etwas arbeitet". Das nun 4.0 NVMe technisch besser sind als reine 3.0 NVMe ist ja nicht verwunderlich, weil die neuen Controller ja nur noch mit 4.0 Support kommen. Aber sie sind eben abwärtskompatibel und am Ende zählt für einen Unraid Server eh mehr wie kompatibel sie ist. Bekanntlich hat sich die Samsung 970 Evo Plus ja sehr bewährt. Wir hatten ja schon Modelle mit ASPM Problemen und welche die komplette C-States verhindert haben. Und wieder andere booten gar nicht bei bestimmten Boards. Daher werde ich auch weiter die 970 Evo Plus kaufen. Zumindest so lange bis sich die 980/990 Evo Plus bewährt hat, sofern sie denn jemals auf den Markt kommt 😅 Ich sehe Samsung jedenfalls im Bereich Linux ziemlich weit vorne, da sie ja die selben NVMes auch als Enterprise Versionen verkaufen. Ich denke die achten daher auf größtmöglichen Linux-Support. Und ansonsten nutzt man im Enterprise Bereich vorrangig Micron und WD, wo es aber Micron nicht als günstige Consumer-Varianten gibt und WD hat meine ich keine Enterprise M.2 Modelle, sondern nur U.2. Das sieht man ganz gut, wenn man nach 1.92 TB filtert: https://geizhals.de/?cat=hdssd&xf=18284_1920~5940_NVMe

Dann tippe ich darauf, dass die Firewall von deinem Arbeitgeber eins von dem macht: - erkennt, dass deine Domain eine private IP verwendet, teste mal in dem du temporär deinen DNS Eintrag über Cloudflare laufen lässt - erkennt, dass du Dateien irgendwo hochladen willst (kannst du auf der Arbeit zB https://filebin.net/ nutzen?) - erkennt, dass du das WebDAV Protokoll nutzen willst. WebDAV nutzt nicht nur die Standard-Methoden POST und GET, sondern auch viele weitere: https://wiki.selfhtml.org/wiki/HTTP/WebDAV, wenn du magst kann ich dir einen Account bei https://gutt.owncube.com/ einrichten. Ich nutze das eh nicht, weil das mega unzuverlässig bei denen funktioniert, aber die hätten eine "normale" IP und sonst ist eben auch eine normale Nextcloud-Installation

Das sind SMR Platten, also bei gemischten Zugriffen super lahm. Aus dem Grund sind die auch so schlecht bewertet. Achte auf CMR. Man kann zwar auch CMR in Betracht ziehen, dann aber nur im Array, niemals als Parität und sie sollte eben echt günstig sein. Bedenke, dass CMR Platten manchmal auch sehr günstig zu bekommen sind: https://www.mydealz.de/deals/wd-elements-desktop-8tb-fur-12510eur-1601eurtb-cmr-2002235 https://www.mydealz.de/deals/sandisk-ultra-nvme-500gb-m2-ssd-1960310 Wobei in letzter Zeit eher noch größere Modelle im Angebot waren. Rein vom Gefühl her würde ich sagen, dass aber noch viele Angebote kommen. Die haben ja alle aktuell massive Absatzprobleme. Bei Shucking einfach das entsprechende Modell + Shucking googlen. Bei Seagate ist bei 8TB meine ich auch nur eine Barracuda verbaut. Kommt also auf das jeweilige Modell an.

Geht es per Mobilfunk? Wenn ja, dann kann es ja nur die Firewall der er Arbeit sein.

Dann läuft der normalerweise einfach non-ECC. Ich würde aber um ganz sicher zu sein, erst das Board liefern lassen und danach den RAM, falls man doch zurücksenden muss.

Mit dem Befehl kann man prüfen, ob eine Domain einen IPv6 DNS Eintrag besitzt: dig AAAA deine.domain.de +short Keine Antwort = hat keinen.

Remove the file from /boot/extra. But note: Maybe you misunderstood how Unraid works. Every reboot is a fresh Unraid installation. This means every application which is not installed on reboot, is not present anymore. And you should know that most of the applications (like powertop) do not run in the background. So it does not influence your system having additional applications or not (its "only" wasting space).

Pakete in extra werden erst bei einem Neustart installiert 😉

Deswegen sollst du dir ja den Inhalt anschauen. Entweder rechts bei jeder Disk in der Übersicht oder bei den Shares rechts. Jo kann man machen Klar. Cache Einstellung des Shares auf only setzen. Dann existiert der Share nur auf dem SSD Pool. Du kannst auch zwei einzelne Pools haben mit jeweils einer SSD und zwei Shares verschiedene Cache Pools zuordnen. Man kann sogar das Array mit einem leeren USB Stick starten und ausschließlich mit Pools arbeiten.

Was auch völlig korrekt so ist, weil NPM mit Containern wenn möglich niemals per https kommunizieren sollte. Das passiert ja lokal direkt zwischen den Containern. Wenn man den Traffic noch mal extra verschlüsselt, ist das schlicht Verschwendung von CPU Ressourcen. Übrigens hättest du genau das auch mit dem curl Befehl herausgefunden. Da hast du aber http eingegeben und nicht https. Ich mein wenn du etwas prüfst, was du gar nicht in NPM eingestellt hast, kannst du schlecht Das selbe Ergebnis erzielen. Mit https wäre nämlich ein Timeout gekommen. Schlussendlich fehlt jetzt aber noch eine Info: dig AAAA deine.duckdns.org +short Kommt da was zurück oder nicht? Zum Vergleich kannst du zb die IPv6 von Google ermitteln: dig AAAA google.de +short In deinem Fall darf nichts zurückkommen, weil du IPv6 deaktiviert hast.

Nein ich meine data. Steht auf RAID1. Also alles gut. Ja. unRAID unterstützt aktuell nur BTRFS bei RAID Pools. Bald soll ZFS folgen. Das ist nicht so. Pools und Array haben vom Prinzip rein gar nichts miteinander zu tun. unRAID steuert das nur so, dass zb beim Hochladen von Dateien, diese auf dem Pool erstellt werden. Der Mover verschiebt die Dateien dann später auf das Array. Und je nach Cache Einstellung des Shares, werden die Dateien in die eine oder andere oder gar nicht verschoben. Aber selbst im Array ist das Dateisystem egal. Man kann dort zb auch XFS und BTRFS mischen, weil die Parität einfach nur die "Quersumme" aus den Bits aller Platten enthält. Das Dateisystem spielt dabei keine Rolle.