Extreme™

Aggiornato anche qui. Monterey tornato di moda in attesa di nuova beta di Ventura che al momento ho parcheggiato a causa del fastidioso problema dell’elevato e anomalo consumo di CPU in idle. 

La GPU, in condizioni estreme di temperatura esterna ed ambiente, rimane costante in idle a 53 °C. Con RPM Zero invece la tempertura in idle nelle stesse condizioni ambientali oscilla tra i 70 e gli 80 °C

Ecco uno screen:

https://ibb.co/L8bf4jq

3 hours ago, Giaccaz said:

quale dei 3 hai inserito nel framebuffer?

 

framebuffer: ATY,Belknap / ATY,Carswell / ATY,Deepbay

<"ATY,Carswell">

Patch 

13 minutes ago, Ramirez71 said:

@Extreme™

ho letto la guida che hai postato, per curiosità tu hai usato il metodo sppt o la patch framebuffer ? 

Ciao, patch framebuffer…👍

Infatti io non ho scritto di problema gestione temperatura GPU sotto Windows.  

Quanto a macOS invece mi sono accontentato di risolvere come descritto in questa guida: e ha funzionato. 
 

https://github.com/perez987/RX6600XT-on-macOS-Monterey-and-PowerPlayTable

@Giaccaz

In giornate come quella di oggi - e in generale di questa estate  dove fuori ci sono 40 gradi e dentro casa sto sopra i 30 dato che non faccio uso di sistemi di condizionamento - se avvio macOS la temperatura in idle della mia 6900 è subito di 70 gradi: dopo qualche minuto e senza usare il sistema operativo è prossima agli 80 gradi. Capisci bene che in queste condizioni se dovessi lanciare un Geekbench o se dovessi lavorare con Davinci Resolve la situazione si farebbe proibitiva per la GPU.

L’unico modo per ovviare  è quello di  far girare la scheda video senza RPM zero. Così facendo  avrai un pochino di rumore in più dovuto alle ventole sempre in funzione ma da quanto ho rilevato le temperature della video si abbasseranno in media di 10-15 gradi e saranno prossime ai valori di esercizio tipici di Windows. 

Ultimamente preferisco eBay ad AliExpress  per gli ordini dalla Cina. Le spedizioni mi arrivano prima. L’ultima qualche giorno fa è arrivata a casa in 15 giorni esatti. Se poi si tratta di qualcosa di urgente mi calcolano spese di spedizione con DHL e chiedo sempre sconto sul prezzo totale. 😁

La differenza tra la intel e la broadcom è che la broadcom è completamente nativa e non ha bisogno di kext per il funzionamento. C'è l'hanno alcuni amici e si trovano bene. Ovviamente nel caso di collegamento m.2 si perde la possibilità di uscita dallo slep via tastiera o mouse. Ma questo non ha molta importanza alla fine. 

Se non sbaglio, questo è un errore tipico di plistedit pro. Per evitarlo, dovresti trascinare il config.plist fuori dalla EFI, quindi modificarlo, salvarlo e rimetterlo dentro EFI. 

Si, stessa combinazione di kext. 
 

Provo a studiarci un po’. 

Che dire, quando hai a che fare con R-Drive Image ci vuole più a dirlo che a farlo....😁

Ripristinata Beta 4, ecco la situazione con RestrictEvents in uso con la "i" scomparsa come per magia....😱

10 minutes ago, fabiosun said:

Sarebbe interessante di riavere quella situazione, di certo pero' in beta 4 avevi l'errore nella descrizione testuale utilizzando il kext, e senza il kext se la mappatura e' quella della foto un paio di slot gialli e ??? per numero di slot occupati (stesa cosa con mappatura custom disattivata)

 

la cosa interessante e' che e' un problema comune per tutti gli utenti che usano MacPro7.1 Smbios

 

Si, esatto Fabio: avevo quell'errore.

Ho l'immagine della beta 4 salvata nel disco. Più tardi la ripristino e a meno che non abbia preso una possibile cantonata con la mia di memoria posto gli stessi screen allegati sopra. 

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

On 7/29/2022 at 10:29 AM, the77joker said:

ogni tanto quando accendo il computer il wifi é completamente disattivato e non si riattiva. L'icona è grigia anche se è indicato che il wifi è attivo.
l'unico modo che ho per farlo ripartire consiste nel riavviare.

La cosa accade ogni tanto, neanche tanto frequentemente e senza un motivo apparente.

 

il mio config.plist qui:

 

https://github.com/davdenic/i5-10600K-ASUS-Z490m-Vega5664-opencore-hackintosh/blob/master/EFI/OC/config.plist

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. 

38 minutes ago, Giaccaz said:

premesso che ho controllato la mappatura ed e tutto a posto , ho fatto delle prove con due config.plist diversi.

1 - Imac20,2 quello che uso di solito e il risveglio non avviene sempre, ma qualche volta in maniera sporadica avendo wol attivato da bios.

Ho fatto un screenshot di hackintools hibernatemode e proxymitywake sono a 0 sempre , non come in questa immagine.

 

 

 

2 - Macpro7,1 invece si risveglia sempre dallo stop in maniera sistematica , e come si nota dalla schermata mancano delle voci .

 

 

 

sapete dirmi come mai come mai queste diefferenze tra uno e l'altro?

 

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

37 minutes ago, davanros said:

Risolto, grazie a @Extreme™ che mi ha sollecitato ad una verifica apparentemente banale che ha però risolto il problema, ovverossia la corretta configurazione del tipo di porta su tutta la mappatura. Ieri sera avevo provato al volo solo la correzione di quella che mi interessava, adesso ho rifatto con cura tutto il percorso e sistemato ogni porta mappata e finalmente lo stop è perfetto. Un grazie grandissimo anche a @Lorys89 per l'impegno e l'aiuto sempre prezioso e risolutivo, siamo un luogo bello in cui stare.

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

2 minutes ago, davanros said:

La modifica all'SSDT è ridicola, cambiato solo la definizione del connettore, compilata senza errori e salvata, quindi direi di no. I problemi mi sono cominciati con l'aggiornamento di Monterey, dove a causa della ethernet integrata era un delirio. Risolto questo poi ho aggiornato a Ventura e stavo piano piano sistemando tutto, e mi sono imbattuto nel problema dello stop

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. 

13 minutes ago, davanros said:

Ciao Extreme, ho controllato ed effettivamente non era mappata come interna. Ho modificato l'SSDT e adesso non mi va più il BT nelle stesse condizioni, e non và più in stop. Qui la cosa si complica.......

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? 
 

11 minutes ago, carlo_67 said:

consiglio di mettere  il FakeSMC (senza virtual e ne lilu) da subito per evitare quell'errore

dopo istallata se volete li rimettete, non so perche ma cosi è andata subito

AppleALC continua a fare le bizze, provo una versione antecedente... vediamo

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.