Entferne vorübergehend mal alle nicht notwendigen Geräte (USB, Festplatten, PCI Karten). Wenn der Fehler weiterhin besteht ist der Fehler wahrscheinlich im Bios zu suchen.

ggf. vorher noch ein NVRam reset durchführen…

Ansonsten die Peripherie nach und nach wieder hinzufügen, bis der Boothänger wieder auftritt.

Bei einer RX 580 dürfte die 8x PCIE Anbindung mehr Datendurchsatz zur Verfügung stellen als die Karte überhaupt ausspucken kann.

Ich hatte das Thema gerade mit einer MSI 5700 XT.

Torpor woran erkennst du den Leistungsverlust? Benchmark mit Luxmark oder Valley? Getestet nach reboot oder sleep?

(Nachtag: hatte übersehen, das du geekbench genutzt hast. Das hätte in meinem sleep/wake Fall aber wahrscheinlich das selbe Fehlerbild ergeben)

Ich hatte das Problem mit einer Reference RX 480 8GB. Nach dem Sleep “stotterte“ Open GL und die betreffenden Benchmarks waren im Keller. Mir ist das auch eher durch Zufall aufgefallen. Die Lösung für mein Problem ist im folgenden Thread dokumentiert. Vielleicht trifft das bei dir ja auch zu:

RADEON AMD RX 480 8GB UND HP RX 580 4GB | NACH RUHEZUSTAND STOTTERNDES OPENGL

ok, danke für den follow up. Wenn ich den Artikel von PC Games Hardware zu dem screenshot richtig verstehe sind das synthetische, also simulierte Werte. Und die Sagen nicht wirklich etwas über die realen Nutzungsbedingungen aus.

Ich fand da diesen Artikel von Pudget Systems durchaus einleuchtend. Nun ist dieser Artikel von 2018 und bezieht sich ausschliesslich auf PCIE 3.0. Wie dem auch sei. x16 scheint erste Wahl zu sein. x8 scheint aber auch, wenn überhaupt, nur einen marginal Nachteil mit sich zu bringen.

Im Anschluss daran gibt es noch einen rezenten Artikel bei Pudget Systems der die Anbindung der GPU via PCIE 3.0 oder PCIE 4.0 für Video Editing testet. Egebniss: Kein messbarer Unterschied.

Donald Duck: "You shouldn't notice to much of a performance hit by using X8. In general "communication" is not a big part of a job run time and X8 is still a lot of bandwidth on PCIe 3.0. Most GPU codes are well buffered too so latency is pretty much hidden. (This is part of the reason you want to have, at least, twice as much system memory as total GPU mem ... buffering and pinning ...)"

Bob-Schmu Wie gesagt, der Lüfter und das Z490 Vision sind schon im Bestand. Meiner Recherche nach kann die XT5700 ohne Leistungsverlust via PCIEx8 betrieben werden. Du sagtest „das wird mal nichts“. Ich würde gerne wissen warum.

Zitat von Bob-Schmu

Das wird mal nichts, der obere Slot hat x16 der untere nur x8.

Wird das tatsächlich nichts? Ich konnte zu dem Thema PCIE 3.0 vs 4.0 im Zusammenspiel mit einer XT5700 bis jetzt keine verlässliche Antwort recherchieren. Bzw. scheinen die Meinungen dazu geradewegs gegenteilig.

Ein Kollege von mir hat einen NH-D15 für seinen Rechner eingekauft. Die MSI XT5700 passt mit diesem Kühler aber nicht mehr entspannt in den x16 PCIE slot. Daher die Nachfrage...

Gestern wurde in Luxemburg entschieden, das die Schulen nächste Woche zu bleiben. Und die Lehrerin hat Karneval auf heute vorverlegt. #Bastelsprint

Du kannst dir auch einen “persistent” linux stick erstellen. Dabei bleiben geladene Daten, tools, Skripte (z.B. SSDTTime), etc. erhalten. Ich bin nach dieser Anleitung vorgegangen:

How to Create a Live Ubuntu USB Drive With Persistent Storage

Dabei hast du dann auch eine Ntfs Partition um Daten später auf ein anderes System zu übertragen, das mit ext4 nichts anfangen kann.

In dem followup bei Dortania zu USB Wake Issues ist ein Artikel verlinkt der Darkwake behandelt:

DarkWake on macOS Catalina

So im groben:

Zitat

As flags are used for bitwise operations, then we can easily notice that combinations 10 and 8 are for sure invalid now. darkwake=8 equals actually to darkwake=0 and darkwake=10 equals to darkwake=2.

Ich werde Darkwake auch noch testen, aber man verliert damit anscheinend die Power Nap Funktion.

Der RAM Takt liegt mit 2600MHz in etwa bei dem des originalen iMacPro1,1.

Da scheint jedenfalls ein Zusammenhang mit der sleep/wake Funktionalität und der RAM Taktung zu bestehen.

RAM Type: DDR4 ECC SDRAM*

Min. RAM Speed: 2666 MHz

Details: Uses "2666 MHz DDR4 ECC memory" (PC4-21300) modules.

Unter Mojave gab es noch einen anderen Fehler durch den höher getakteten RAM:

Nach dem Aufwachen wurde eine Fehlermeldung ausgegeben, das die USB-Laufwerke bzw. Sticks nicht korrekt ausgeworfen wurden.

Wenn man den Takt auf 2600MHz reduzierte verschwand auch dieser Fehler.

Bootloader: opencore-version REL-065-2021-01-04

Betriebssystem: 10.11.1

Mainboard: Gigabyte Z390 I AORUS PRO WiFi

Prozessor: Intel Core i9-9900

Grafikkarte: Radeon AMD RX 480 8GB

RAM: Corsair Vengeance LPX 2x16GB, DDR4, 3000MHz

Folgendes Fehlerbild

DDR4 Ram auf 3000MHz (System Memory Multiplier -> Auto):

Wenn ich meinen Hackintosh via USB Tastatur aufwecken möchte, "wacht" zuerst der Rechner aber nicht der Bildschirm auf.

Erst bei einem zweiten Klick zeigt der Bildschirm dann den Login screen an.

DDR4 Ram auf 2400MHz (System Memory Multiplier -> 2400):

Rechner und Bildschirm wachen mit einem Tastaturanschlag auf.

Folgende Lösungsvorschläge habe ich umgesetzt

Dortania Guide:

Method 1 - Add Wake Type Property

Method 2 - Create a fake ACPI Device

Beide Methoden ändern nichts daran, das ich den zweiten Klick für den Wake benötige, wenn ich den RAM auf 3000MHz laufen lassen möchte. Dieser "Fehler" zeigte sich auch schon auf Mojave. Es ist, wie so häufig, ein Luxus Problem aber vielleicht hat ja jemand noch eine Idee wie man das lösen könnte.

Geekbench 5

Ich habe meine EFI mit Methode2 noch angehängt.

Grüße,

HDRI

ok - diese Nummer läuft auf zwei verschiedene Hardware Probleme heraus die komplett unabhängig von dem OS oder dem Bootloader sind.

Ich habe den Hackintosh SE unter Windows nativ gebootet und mit USB Device Tree Viewer das selbe Problem auf dem internal Header (HS09 und HS10 only) festgestellt.

Ich nehme an das dass Verbindungskabel nicht richtig im Header drin sitzt, bzw. die Toleranzen für das Kabel ziemlich beschissen sind.

Ich kann das gerade nicht ganz so einfach überprüfen, da die Position von dem Internal USB Header für mich derzeit ziemlich schlecht zu erreichen ist. Das werde ich aber noch nachreichen.

Bei dem USB-C Hub ist es weniger ein Hardware Problem als eine Design Nachlässigkeit meinerseits. Ich habe mir mal genauer angesehen, wie eine USB3.0 Steckverbindung zwichen HS und SS hardwareseitig Zustande kommt:

Im vorderen Teil des Steckers sitzen die Pins für die USB 2.0 Verbindung, im hinteren die Pins fürdie USB 3.0 Verbindung. Die USB 3.0 Flashspeicher die ich zum Testen benutzt habe waren neu (die alten waren, wie so häufig, irgendwann nicht mehr auffindbar). Diese Stecker stellten an dem USB-C Hub immer nur die USB 2.0 Verbindung her. Da der Hub ein Stück tiefer im Schacht sitzt haben diese USB Stick knapp 2mm zu "kurz" im Port gesteckt und damit konnten die "hinteren" USB 3.0 Pins nicht kontaktieren.

Ich habe das Plastikgehäuse entfernt und siehe da --> SS05

Ich hatte die Vorderseite von dem USB-C hub schon umlaufend abgefräst, damit die Ports weiter nach vorne rücken können. Bis jetzt hatte das auch immer gereicht. Wenn ich mich um den internen USB 3.0 Header kümmere werde ich mir das auch noch einmal anschauen.

Apropos Kümmern - danke hackmac für Deine Anteilnahme in diesem Thread.

griven da meine Fehlerquelle so gänzlich OC unrelated ist hänge ich hier in der falschen Abteilung rum - Bitte verschieben (z.B. Design Modifikationen) - Danke.

Soll ich den Titel des Threads nachträglich ändern?

ja - genau - so sieht mein Problem dann im Hackintool aus.

Wenn die Verbindung aber richtig erkannt wird, ist auch die Übertragungsrate in Ordnung. Nur bekomme am internen USB 3.1 Header überhaupt keine SS Verbindungen zustande.

sehr Aufmerksam - ich hatte im Hackintool nur den Controller gecheckt - wenn ich die USB Ports mit dem Besen bereinige und dann neu lade sieht das bei mir so aus:

Ich habe die "unzugänglichen" Ports HS03-SS03,HS04-SS04,HS05-SS05 mit angebunden. Am zugänglichen Port HS10-SS10 ist derzeit nichts angeschlossen und Port HS09 läuft mit Keyboard und Mouse auf USB2.0, daher bleibt SS09 auch ungenutzt...

korrekt - ist wieder enabled - obwohl im OC manual steht das dass nur nötig ist wenn man ansonsten einen “halt” im boot process hat.

Danke - guter Punkt - leider nein:

Cannon Lake PCh USB 3.1 xHCI Host Controller

Mein Port Mapping ist in Ordnung.

Ich nehme an ich habe zwei Probleme gleichzeitig, die zusammen ein unklares Fehlerbild erzeugen. Ob die beiden Probleme mit meinem Update auf OC und 10.11.1 in Verbindung stehen kann ich derzeit noch nicht sagen.

Da mein Hackintosh in einem alten Macintosh SE Case sitzt, ist mein Zugang zu den USB Ports im geschlossen Zustand auf zwei Schnittstellen beschränkt:

Die hinteren beiden Ports gehen an den internal Connector F_USB30 - USB 3.1 Gen1 support - Header (HS09-SS09 und HS10-SS10).

Die vorderen USB Ports gehören zu einem USB-C Hub mit Card Reader (Aukey USB-C Hub) der an den Back Panel Connector USB Type-C Port - USB 3.1 Gen2 support) angeschlossen ist (HS05-SS05).

Die restlichen USB Ports sind nicht zugänglich.

Feststellung:

• Die USB Ports am internen USB 3.1 Header werden ausschliesslich mit HS09 bzw. HS10 verhandelt. Hier bekomme ich keine SS09 oder SS10 Verbindungen zustande
• Die USB Ports am USB-C Hub wechseln die verhandelte Übertragungsart zwischen HS und SS. Meine NVME externe USB Platte wird in der Mehrzahl der Fällen (4/5) als SS05 angezeigt. Meine USB 3.0 Flash Speicher werden dagegen fast immer (14/15) unter HS05 eingebunden.
• An den anderen Ports (HS03-SS03, HS04-SS04, HS06-SS06, HS07-SS07, HS08-SS08) erfolgen die Zuweisungen korrekt. Die USB 3.0 Flash Speicher werden als solche erkannt und eingebunden.

Ich werde als nächstes noch einmal von meinem alten System booten, das auf der externen NVME ausgelagert ist um Clover/Mojave vs OC/BigSur als Fehlerquelle ausschliessen zukönnen. Ggf. habe ich hier auch ein Hardware Fehler.

Sollte das Fehlerbild unter Clover/Mojave identisch sein könnte ich vom Internen Header zu den externen Ports wechseln und der USB-C Hub gegen einen anderen austauschen (davor graut es mir, da ich mit diesem eigentlich sehr zufrieden war und ich auf der Suche nach einem vernünftig funktionierenden HUB einiges an Lehrgeld bezahlt habe).

Wer noch brauchbare Tips hat, bitte unbedingt melden...

Danke hackmac004 - ich hatte schon vorher nach dieser Anleitung (bzw. damals nach der von RehabMan) meine USB Mappings vorgenommen.

Der Tipp mit dem USBINjectAll und XhciPortLimit war gut, das wusste ich nicht.

• Ich habe noch einmal eine absolut generische EFI erstellt.
• Die ACPI´s durch Dortania Fallback ersetzt.
• Meine Patches nicht eingefügt (HPET _CRS to XCRS Rename, RTC IRQ 8 Patch, TIMR IRQ 0 Patch).
• Alle USB bezogenen Renames überprüft - kein Return:
  ioreg -l -p IOService -w0 | grep -i XHC1
  ioreg -l -p IOService -w0 | grep -i EHC1
  ioreg -l -p IOService -w0 | grep -i EHC2
• Alle Einstellungen via Clover Reference Manual 0.6.6 auf Abweichungen oder Fehler überprüft
• XHCI Hand-off deaktiviert im BIOS (testweise - läuft unproblematisch
• XhciPortLimit -> true

Ich sehe alle Ports HS wie SS (wie vorher auch, wenn ich XhciPortLimit auf true gesetzt und meinen USBMap.kext entfernt hatte). Aber egal welches USB 3.0 Device ich einstecke, es wird immer nur der HS speed ausgehandelt.

Devices sind verschiedene USB3.0 Sticks und ein NVME USB Adapter. Alle diese Devices liefen auf meiner Clover Mojave Installation und wurden bei SS angezeigt und hatten die volle Transfer Geschwindigkeit.

Vielleicht ist es noch von Bedeutung was bei mir wo hängt:

HS06/SS06 -> USBC HUB -> USB Arduino Serial connection

HS09/SS09 -> Keyboard/Bluetooth Logitech Dongle

HS11 -> BRCM20702 Bluetooth USB Controller Internal

HS13 -> ITE Device(8595)

Ich packe meine generische Dortania EFI noch mit rein.

Bin ratlos...

Bootloader: opencore-version REL-065-2021-01-04

Betriebssystem: 10.11.1

Mainboard: Gigabyte Z390 I AORUS PRO WiFi

Prozessor: Intel Core i9-9900

Grafikkarte: Radeon AMD RX 480 8GB

Der Wechsel von Clover auf OpenCore lief glatt.

Setup von OC via dortania, SSDTs via SSDTTime

OSX 10.11.1 frisch installiert.

Der einzige Hänger den ich nicht gelöst bekomme sind meine USB Verbindungen.

Alle USB Devices sind ausschliesslich via USB2 verbunden und laufen nicht via USB3. An dem USBC Port hängt ein Hub, der als SS erkannt wird, aber auch darüber werden USB3 Devices nur via HS angebunden (HS6, SS6).

In Clover waren die USB Ports via Kext problemlos gemapped und eingebunden - in OpenCore habe ich erstmal den selben Kext verwendet.

Recap:

• Alle Einträge in ACPI auf den generischen Zustand laut Dortania versetzt
  (SSDT-PLUG-DRTNIA, SSDT-EC-USBX-DESKTOP, SSDT-AWAC, SSDT-PMC)
• USBinjectAll.kext anstelle des USBMap.kext und das ganze Prozedere des USBMap.kext erstellen frisch durchlaufen
• BIOS überprüft (dortania/coffee-lake/intel bios settings)
• USBMap.kext via USBMap.command neu erstellt mit den Portmappings meines Boards
  (SS Devices wurde nicht als aktiv angezeigt, ich habe diese demnach manuell eingerichtet und typisiert)
• Sanity Checker der config.plist
  (einziger hickup: SystemProductName = iMacPro1,1 this is not a suggested SMBIOS for Coffee Lake Desktop systems)

Screenshot USBMap.command:

Screenshot IOReg:

Hat jemand eine Tipp was ich da übersehen habe?

Danke,

HDRI

ja, mit einem Kabel.

helmutmoling Vielleicht ist die Versorgungsspannung für die CPU zu niedrig, bzw. grenzwertig. Ich hatte vor kurzem einen i9900 (ohne K) eingesetzt und die BIOS Werte zurückgesetzt. Die eingetragenen Vcore Spannung war minimal zu niedrig und führte zu ähnlichen Fehlerbildern wie bei Dir. Ausgeführte Programme stürzten ab, ohne das der Rechner einfror, dann aber stürzte der Rechner ohne Last zu einem anderen Zeitpunkt komplett ab.

Ein Anheben des Vcore um 50mV von 1,200 V auf 1,250 V hat mein System stabilisiert. Eine erhöhte Vcore Spannung erzeugt natürlich auch mehr Wärme. Es ist also wichtig die Temperaturen der CPU im Auge zu behalten. Die Veränderung des Vcores solltest du in kleinen Schritten machen. Zum Testen kannst du aber durchaus den Vcore wert um 100mV anheben. Wenn Dein Problem sich damit verabschiedet hat würde ich die Spannung in 20mv Schritten wieder reduzieren bis die Fehler erneut auftreten. Auf diesen erreichten Grenzwert kannst du dann nochmal z.B. 20mV aufschlagen um stabil zu sein.

Normalerweise sollten diese Fehler bei Rechen intensiven Prozessen auftreten, wie sie zu Beispiel Benchmarktests simulieren. Interessanterweise stürzte Geekbench immer bei den gleichen Operationen (speech recognition) ab, ohne das ich eine besonders hohe CPU Auslastung erkennen konnte. Es scheint also unabhängig von der Auslastung der CPU bestimmte Rechen Operationen zu geben die eine höhere Vcore Spannung benötigen um Stabil zu arbeiten...

Sascha Ich verstehe wie sehr so etwas nerven kann. Die Reizung kommt aber auch aus der Perspektive, das die respektlos sind und dich, bzw. Ihre Umwelt nicht achten. Wahrscheinlich läuft das auch umgekehrt genauso, dein Nachbar empfindet den Beschwerdeführer vielleicht als spießigen Mitbürger der ihm nichts gönnt.

Ich würde zumindest einmal vorher anklingeln und sachlich klären das Musik aus zweiter Hand nicht zum einschlafen taugt.

Respekt erzeugt Gegenrespekt oder so ähnlich.

Wenn das nichts hilft, nun gut, dann wohl mit der Polizei.

Aber wenn möglich erstmal das gemeinsame Gespräch suchen.

Evtl. auch am Tag danach, zum Beispiel heute Abend.

Meine 2 Cent...