Extreme™

La stranezza è che nella beta 4 con lo stesso kext in uso non avevo nessuna "i" e quando visualizzavo gli slot occupati come nello screen sopra non c'erano anomalie.

RestrictEvents sembra non avere alcun effetto nella beta 5 quanto alla famosa "i" perlomeno qui da me

Se a livello hardware è tutto collegato a regola, il problema potrebbe dipendere da una non corretta mappatura delle porte USB. Se la mappatura invece è corretta potresti provare a cambiare lo slot PCIe - la scheda Wi-Fi è collegata via PCIe? - di collegamento e verificare se il problema si presenta di nuovo. Se non ricordo male tu hai la Fenvi-T919. Ce l'ho anch'io e questo difetto non me lo fa utilizzandola senza nessun Kext aggiuntivo.

Adesso non sono a casa altrimenti avrei guardato la tua EFI. Comunque quando - raramente in realtà- mi capita di aggiornare OC con salti di versione abbastanza evidenti come nel tuo caso preferisco sempre affidarmi alla manina piuttosto che a OCAT. OCAT è un ottimo tool ed io stesso ne faccio uso quotidiano ma il metodo “a mano” resta secondo me quello più affidabile.

Bene!

Questo non è così semplice. Però, se non l’hai già fatto, fossi in te prima farei questa prova: cioè disattiverei il wol e quindi testerei lo sleep: se in questo modo lo sleep funziona a dovere - cioè il sistema non si risveglia a random - allora avresti la certezza che la configurazione OC in uso è apposto. Appurato questo, allora si proverebbe a cercare un rimedio - se esiste - atto ad evitare che la macchina rimanga in stop anche con wol attivo.

La risposta è molto semplice: ogni smbios gestisce l’alimentazione in modo differente. Anch’io con MacPro 7,1 ho le stesse impostazioni del tuo screen.

Occhio all'ultimo commit 083: mi ha fatto innervosire abbastanza perché pensando al solito aggiornamento all'acqua di rose non mi sono letto prima il changelog. Cercavo di correggere gli errori di OC Validate nella sezione Uefi>>Driver ma ovviamente non riuscivo. Perché bisogna aprire il nuovo config.plist dell'ultimo commit prendere la sezione Uefi>>Driver e sostituirla completamente nel vostro config.plist in uso. Infine personalizzarla in base ai drivers che caricate, come sempre. Infine, nella sezione NVRAM hanno tolto LegacyEnable: quindi cancellatelo nel vostro config.plist

Bene! Sì, una mappatura non corretta è la prima causa dei problemi di sleep.

Capito. Ne deduco che in Monterey lo stop ti funzionasse. Se OC è rimasto quello di Monterey quanto alle impostazioni allora probabile che siano subentrati problemi di compatibilità della scheda con Ventura. Non trovo altre cause dal punto di vista logico. Se @Lorys89 non riesce a risolvere credo proprio che dovrai acquistare una nuova scheda Wi-Fi Bluetooth. Se si, non prendere Fenvi T-919: hanno un controllo qualità che non è dei migliori e spesso hanno problemi proprio a livello del BT. Per non parlare di quelli relativi alla ricezione spesso debole del segnale Bt e Wi-Fi.

Ciao! Proprio strano, a meno che non abbia fatto errori nella modifica del SSDT. Ma questa scheda che usi ti aveva dato mai problemi in precedenza? Se no, da quando sono iniziati?

A me è andata liscia anche con lilu, virtualsmc e dipendenze, AppleALC e tutta la pappardella. Aggiorno sempre via: https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

Qui andata alla prima con OC 083 sia in configurazione classica che con FakeSMC.

Giusto una domandina banale @davanros: La mappatura delle porte usb è corretta? In particolare, hai impostato come interna la porta usb 2 a cui è collegato il Fenvi-T919?

Si, quelli che hai inserito sono i valori corretti: anch’io li ho settati uguali. Se li cambi non credo proprio che il sistema si avvii. Ti consiglio di lasciare così.

@Giaccaz Verifica che nel tuo config.plist le voci indicate con freccia rossa negli screen che ti allego siano impostate così come le vedi nelle foto. Se le hai già settate così e ti ta ugualmente il problema allora lascia perdere e avvia windows senza l'ausilio di OC come faccio io.

Nemmeno io mai avuto problemi sia su Windows 10 che adesso su 11. Sempre resize bar attiva. Con I driver, su Windows, ho da sempre queste fisse: 1) non installo mai driver beta 2) Quando esce una nuova versione stabile del driver AMD non eseguo l’aggiornamento via utility AMD ma prima procedo a rimuovere i vecchi driver in ambiente di modalità provvisoria usando o AMDCleanup utility o Display Driver Uninstaller. 3) Quindi riavvio in modalità normale, disattivo completamente sia l’antivirus di terze parti - se presente - sia Microsoft Defender e infine lancio installazione dei nuovi driver al termine della quale riavvio in ogni caso.

Si, può essere proprio quello: prova a disattivarlo e poi disattiva "attiva per l'accesso alla rete" nel menu risparmio energia. Quindi riesegui test e vedi se si sveglia di nuovo non appena entrato in stop.

@davanros Per caso, hai “ trova il mio Mac” attivo?

È vero! A forza di alternare le due efi che uso ho combinato pasticci nella sezione ram di uno dei due config.plist. Quindi grazie per la dritta! 😉

Se questa difformità nella memoria ram segnalata con la "i! risulterà incidere sulla stabilità del sistema non avrò alcun problema a inserire RestrictEvents tra i Kext. Per ora sembra che tutto fili liscio pur trattandosi di una beta. Poi @Giaccaz segua pure il tuo consiglio: mica volevo convincerlo del contrario. 😊

Nel video la situazione memoria nel mio hack con Mac Pro 7,1 ,Ventura B3 e senza RestricEvents Kext

Uso anche io MacPro 7,1 come smbios - anche se chi ne capisce molto più di me mi dice sempre che quello più rispondente alla mia CPU è iMacPro 1,1 - e siccome la mia filosofia è quella di ridurre al minimo indispensabile l’utilizzo di kext dipendenti da LiLu ho eliminato da tempo anche il kext restrictsevents ricorrendo alla mappatura della memoria ram secondo quanto riportato in questa guida: https://dortania.github.io/OpenCore-Post-Install/universal/memory.html#mapping-our-memory Per l’altro problema invece mi suona strano che una porta usb-c della vga possa interferire con la tua attuale mappatura.

Se prima dell’ upgrade di OC non avevi problemi, la prima cosa che mi viene in mente è che l’aggiornamento non sia andato bene. Se lo hai eseguito con OCat specialmente. Se disponi, salvata da qualche parte, della release di OC che non creava noie ti consiglio di cestinare la EFI aggiornata, rimettere la EFI precedente e aggiornarla a mano.

Confermo: mi ero perso quel device ID. Questa nel dettaglio è la procedura consigliata da vit9696 For those who have newest 6900 XT cards with XTXH chips. Please try latest WEG from master. Now it can spoof AMD device-id.Three things you need:1. Latest WhateverGreen.kext build from master2. DeviceProperties fix (use Gfxutil)3. SSDT-BRG0 table with correct path (without it device-id from DeviceProperties will not be injected) Well, gfxutil will show you correct path to GFX0. You have to insert it in DeviceProperties like on my screenshot. Just drag binary file on Terminal and press Return button. SSDT-BRG0 is used to assign bridge name for your card. All Radeon cards starting from Vega works through extra bridge. You can see it in IOReg (PEG1->PEGP->pci-bridge->GFX0). In order to inject DeviceID to GFX0 you need to determine pci-bridge device in ACPI. If you did it correct your IOReg should look like this Without this SSDT your deviceID for GFX0 will not be injected. Also short description of this fix described in SSDT-BRG0 source code.