PC non va in Standby

[elia_firenze]

dopo aver cliccato su Stop il computer non va in standby ma si riavvia da solo.

 

E' stata disattivata sul BIOS la funzione "onboard WAN device" e "I219 LAN Power on"

 

la mia build è la seguente:

Asrock z490m pro4

i5 10600k (solo gpu integrata)

sabrent 500gb

ballistix 16gb 3000mhz

 

grazie a tutti!!!

Edited February 13, 2021 by elia_firenze

[Jolly]

Qualche aiutino in più? Tipo che bootloader stai usando, magari posta anche la efi, così ci si dà una occhiata. 

[elia_firenze]

1 minuto fa, Jolly ha scritto:

Qualche aiutino in più? Tipo che bootloader stai usando, magari posta anche la efi, così ci si dà una occhiata. 

scusa, comunque Opencore. Ti lascio la EFI in allegato

EFI.zip

[elia_firenze]

perdonami di nuovo ho sbagliato EFI, questa è quella mia attuale

EFI.zip

[Jolly]

Per me il problema è "SSDT-3-xh_cmsd4.aml", non è configurato. Hai messo la patch di gengik, hai rinominato qualcheGUPC e similari ma non tutti e soprattutto  non hai disabilitato neanche una porta USB. Rifatti la mappatura, decidi quali porte tenere e disabilita le altre. Poi secondo me scaricati SSDT-Basic ed elimina tutti gli altri (tranne SSDT-3-xh_cmsd4.aml naturalmente).

Con calma controllerò meglio il config

[dreamwhite]

9 minutes ago, Jolly said:

Per me il problema è "SSDT-3-xh_cmsd4.aml", non è configurato. Hai messo la patch di gengik, hai rinominato qualcheGUPC e similari ma non tutti e soprattutto  non hai disabilitato neanche una porta USB

Buonasera e perdonami l'intrusione. Ho seguito personalmente l'utente in questione e non vedo motivo di dire "non hai disabilitato neanche una porta USB". Dal momento che nella sua tabella ACPI relativa alle USB (per l'appunto SSDT-3-xh_cmsd4) è definito il metodo GUPC, questi consente la disattivazione della porta impostando Arg0 su "Zero".

 

Secondo l’Advanced Configuration and Power Interface (ACPI) Specification, version 6.3, pagina 673, il metodo _UPC ha come valore di ritorno il seguente Package:

 

Return Value Information:
    Package {
    Connectable // Integer (BYTE)
    Type // Integer (BYTE)
    Reserved0 // Integer
    Reserved1 // Integer)
}

 

Se la matematica non è un'opinione e gli array partono da 0, impostando il primo elemento dell'array (di indice 0,  per l'appunto), su Zero, il parametro Connectable, di tipo Integer, disattiva la porta, ergo non è necessario utilizzare il metodo GENG per la disattivazione della porta.

 

Sia chiaro, è pur sempre possibile modificare il metodo _UPC della porta per far si che ritorni "GENG (Zero, Zero)" ma lo vedo solamente uno spreco di righe di codice, dal momento che è gia definito un metodo GUPC all'interno della tabella.

 

13 minutes ago, Jolly said:

Poi secondo me scaricati SSDT-Basic ed elimina tutti gli altri

 

Riguardo ciò, non è sbagliata come idea ma, dal momento che la sua è una scheda madre di 10 generazione Intel con chipset Z490, richiede solamente i seguenti SSDT:

- SSDT-AWAC (dal momento che ha un clock AWAC che va disattivato)

- SSDT-EC-USBX (come tutti gli hackintosh Intel di 6 generazione e successive)
- SSDT-PLUG (come tutti gli hackintosh Intel)

 

Analizzando il log di pmset, tramite il seguente comando, risulta che la causa del wake sia dovuta alla periferica CNVW (che per deduzione penso sia relativo allo slot m.2 WiFi chiave A+E presente sulla motherboard ma non occupato):

 

pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

 

 

Onestamente non so cosa pensare, dal momento che neanche via IORegistryExplorer, la periferica CNVW è presente.
Ho pensato, così su due piedi, di aggiungere un eventuale SSDT-Disable_CNVW ma non so la sua efficacia... Sarebbe da testare

 

Spero di aver chiarito eventuali dubbi e perchè no, se occorre qualche altro chiarimento sono più che disponibile ad aiutarti ^^

A presto

dreamwhite

[Jolly]

@dreamwhite

non sono in grado di controbattere, le mie conoscenze non mi permettono dì argomentare adeguatamente. Tanto per capire, ti chiedo, per favore, di spiegarmi in quel Ssdt quali sono le porte disabilitate. 

[dreamwhite]

34 minutes ago, Jolly said:

@dreamwhite

non sono in grado di controbattere, le mie conoscenze non mi permettono dì argomentare adeguatamente. Tanto per capire, ti chiedo, per favore, di spiegarmi in quel Ssdt quali sono le porte disabilitate. 

Al momento non sono al PC e non credo di accenderlo prima di domattina. Banalmente le porte disattive sono quelle il cui metodo _UPC ritorna "GUPC (Zero)".

Domani ti elenco quali sono le porte e analizziamo insieme il problema 🙂

Buonanotte

[Jolly]

@dreamwhite

Naturalmente hai ragione, penso di aver colto quello che intendi dopo una disamina meno superficiale del SSDT; porte disabilitate tramite GUPC (ZERO) e definite tramite GENG. 

Non avendo dati sulla mappatura e visto che la scelta di cosa abilitare è soggettiva non posso esprimere più di tanto. Quello che ancora non mi torna è che a me sembra che le porte abilitate siano 18. Vorrei anche capire la scelta di disabilitare HS14.

[Gengik84]

@Jolly Ciao, alla fine niente di nuovo

è quello che è scritto nella mia guida da diverso tempo

puoi mettere la patch e usarla anche per disattivare o usare GUPC come appunto scritto nella guida, alla fine non ci sono differenze

Le porte lasciate attive come hai detto giustamente tu, sono in esubero rispetto al limite

 

10 ore fa, dreamwhite ha scritto:

Riguardo ciò, non è sbagliata come idea ma, dal momento che la sua è una scheda madre di 10 generazione Intel con chipset Z490, richiede solamente i seguenti SSDT:

Non hai ben chiaro ciò che Basic fa...

10 ore fa, dreamwhite ha scritto:

- SSDT-AWAC (dal momento che ha un clock AWAC che va disattivato)

 

?

Non è questo di certo

se awac ritorna 0, RTC è disattivo...

quindi deve tornare 1 😉

 

[dreamwhite]

2 hours ago, Gengik84 said:

Non hai ben chiaro ciò che Basic fa...

Dovrei rivedermi meglio SSDT-Basic, ammetto, ma in ogni caso, non penso che sia SSDT-Basic a fare la differenza con lo sleep dal momento che il problema è relativo a questa periferica CNVW 😕 Ma magari mi sbaglio

 

2 hours ago, Gengik84 said:

?

Non è questo di certo

se awac ritorna 0, RTC è disattivo...

quindi deve tornare 1 😉

My bad, In ogni caso basta verificare il metodo _STA delle due periferiche e far si che sia attivo solo RTC, dal momento che macOS è compatibile solo con quello.
A giudicare dalle sue ACPI (e dal fatto che boota anche), SSDT-AWAC è corretto.
Allego foto dei metodi _STA di AWAC e RTC provenienti dal DSDT dell'utente:

 

DEVICE AWAC

 

 

DEVICE RTC

 

 

Per far si che RTC sia attivo e utilizzabile da macOS occorre dunque impostare la variabile STAS su One.

Ergo, va bene SSDT-AWAC presente nella sua EFI.

 

Se ci sono correzioni da apportare, sono più che curioso di testarle, purchè siano in grado di risolvere il problema dello sleep wake. Ne stiamo uscendo pazzi 😢

Grazie a tutti per il contributo

dreamwhite

[dreamwhite]

3 hours ago, Jolly said:

Naturalmente hai ragione, penso di aver colto quello che intendi dopo una disamina meno superficiale del SSDT; porte disabilitate tramite GUPC (ZERO) e definite tramite GENG. 

Non avendo dati sulla mappatura e visto che la scelta di cosa abilitare è soggettiva non posso esprimere più di tanto. Quello che ancora non mi torna è che a me sembra che le porte abilitate siano 18. Vorrei anche capire la scelta di disabilitare HS14.

Buongiorno a tutti (mi ero dimenticato di farlo nella risposta precedente haha).
Dunque, per quanto riguarda la scelta di abilitare 18 porte, mi sono basato principalmente sul fatto che la scheda madre dell'utente, una AsRock Z490M Pro 4, ha queste porte USB nel back-panel:

 

Dunque, partendo da sx verso dx contiamo:

4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili)

2 porte USB-A logiche (1x 3.0 e 1x 2.0 retrocompatibile)

2 porte USB-C logiche (1x 3.0 e 1x 2.0 retrocompatibile)

4 porte USB-A logiche (2x 3.0 e 2x 2.0 retrocompatibili)

 

totale porte: 12 porte USB

Ora, fatta questa considerazione, bisogna includere nella mappatura anche la porta USB dell'header interno a cui è collegata la Fenvi T919 che, stando a quanto ricordi è identificata in HS13, e le porte USB presenti sul front-panel del suo case.

Rieffettuando il calcolo (ossia considerando 2 porte logiche per ogni porta USB 3.1 gen 1) si arriva alla fatidica cifra di 18 porte USB totale, che richiedono per tanto l'attivazione del quirk XhciPortLimit.

 

Sia chiaro, è pur sempre possibile ridurre il numero di porte USB a quelle strettamente necessarie, ma ho preferito (magari sbagliando, non so) attivare tutte le porte USB possibili 😕

Se c'è da rieffettuare la mappatura delle porte USB non c'è alcun problema. Sia @Gengik84 , così come altri staffer di macos86.it, così come tanti altri, sanno come funziona il metodo GENG e per tanto non è un problema disattivare eventuali porte 🙂

Resto in attesa di vostre ^^

dreamwhite

 

[Gengik84]

l'attuale discorso della mappatura è che di fatto supera il limite, quindi 2 opzioni

1. alcune porte in esubero vengono omesse dal sistema o ssdt omesso dal caricamento

2. mantiene la patch per port limit ma in questo caso di fatto ha solo definito i connettori

 

Quindi dovrebbe scegliere quali porte "sacrificare" (qualora fossero appunto 18 quelle totali in uso), per rientrare nel limite

esempio semplice: alcune porte farle lavorare in una sola modalità, tipo due usb posteriori, dove collega mouse e tastiera farle lavorare come sole 2.0 quindi disabilitando le rispettive SSxx

facendo così siamo già a 16, quindi ne rimarrebbe una sola da sacrificare

21 minuti fa, dreamwhite ha scritto:

Dovrei rivedermi meglio SSDT-Basic, ammetto, ma in ogni caso, non penso che sia SSDT-Basic a fare la differenza con lo sleep dal momento che il problema è relativo a questa periferica CNVW 😕 Ma magari mi sbaglio

 

Certo che no, non fa la differenza a quel problema e tanto meno alla mappatura

[dreamwhite]

4 minutes ago, Gengik84 said:

l'attuale discorso della mappatura è che di fatto supera il limite, quindi 2 opzioni

1. alcune porte in esubero vengono omesse dal sistema o ssdt omesso dal caricamento

2. mantiene la patch per port limit ma in questo caso di fatto ha solo definito i connettori

 

Quindi dovrebbe scegliere quali porte "sacrificare" (qualora fossero appunto 18 quelle totali in uso), per rientrare nel limite

esempio semplice: alcune porte farle lavorare in una sola modalità, tipo due usb posteriori, dove collega mouse e tastiera farle lavorare come sole 2.0 quindi disabilitando le rispettive SSxx

facendo così siamo già a 16, quindi ne rimarrebbe una sola da sacrificare

Alright, vedrò se l'utente sarà interessato a "sacrificare" 3 porte USB e nel caso procediamo alla disattivazione delle relative porte USB.
Domanda: in termini di stabiiltà del sistema, con e senza XhciPortLimit, vi è qualche differenza? Magari mi sbaglio, ma in generale il termine patch, mi fa pensare in automatico a qualche problema che potrebbe derivarne. Saresti così gentile da chiarirmi questo stupido dubbio?
Ciao e grazie

[Gengik84]

come sempre è stato, di fatto le patch sono da considerarsi instabili e l'uso dovrebbe essere a breve termine

esempio: ho CFG lock, installo con AppleXcpmCfgLock ma se voglio maggiore "qualità e stabilità", modifico il bios da shell (come anche tu sai) qualora il bios non permettesse la disabilitazione

 

Detto questo, i fix ci sono e ovviamente ognuno è libero di fare quindi può tenere anche la patch a vita

Quello che possiamo fare è dare al prossimo la "conoscenza" minima così che la possa usare per scegliere una strada oppure l'altra com maggiore cognizione

[dreamwhite]

Grazie mille per il chiarimento ^^

A questo punto però mi sorge spontaneo un dubbio:
mettiamo caso che l'utente autore del topic in questione decida di fare un dual boot win/mac o linux/mac e avvia il sistema operativo tramite OpenCore (e che quindi inietta l'ssdt per la mappatura delle USB). Quando il sistema sarà avviato, Linux o Windows rienumereranno (godzilla had a stroke trying to write this and died) le porte USB oppure considereranno solo le porte USB definite nell'SSDT?

[Gengik84]

Windows nella maggior parte dei casi, ignora proprio le acpi

tanto è che per esempio se le considerasse, in molti portatili ci si ritroverebbe senza usb funzionanti perchè definite male oppure disattivate proprio nelle acpi Oem

Windows usa i driver e detto papale papale, se "ne frega" delle acpi

quei driver sono una "sorta" di injectall in hackintosh 😂

Detto questo, se ci fossero seri problemi (non  visti almeno per il momento), nessuno ti vieta, in caso, di aggiungere una condizione nelle varie usb definite per la mappatura, facendo appunto eseguire il codice solo su macOS e lasciando il resto invariato per altri sistemi

Altra cosa: calcola che i drop table non dovrebbero riversarsi su altri sistemi (se non erro), quindi è impossibile che una tabella oem patchata venga caricata senza che l'OEM originale sia bloccata

[Anto65]

Potrebbe tornare uile questo ?

 

Note: remember that, if you boot Windows from OC, to prevent OC from injecting ACPI values you have to act on these keys in config.plist:

• Kernel> Quirks> CustomSMBIOSGuid> True (default is False)
• PlatformInfo> UpdateSMBIOSMode> Custom (default is Create). 
• fonte : https://www.insanelymac.com/forum/topic/346592-opencore-065-066-differences/?tab=comments#comment-2750372

[Gengik84]

codesto più che altro è per abilitare le info OEM, come board-id etc etc

altrimenti per esempio alcuni software che su windows usando questi "valori" originali per funzionare, avrebbero problemi

nello specifico acpi, non ho provato perchè non ho più windows  ma potrebbe anche essere un aiuto 🙂

 

 

[dreamwhite]

8 hours ago, Gengik84 said:

Windows nella maggior parte dei casi, ignora proprio le acpi

tanto è che per esempio se le considerasse, in molti portatili ci si ritroverebbe senza usb funzionanti perchè definite male oppure disattivate proprio nelle acpi Oem

Windows usa i driver e detto papale papale, se "ne frega" delle acpi

quei driver sono una "sorta" di injectall in hackintosh 😂

Detto questo, se ci fossero seri problemi (non  visti almeno per il momento), nessuno ti vieta, in caso, di aggiungere una condizione nelle varie usb definite per la mappatura, facendo appunto eseguire il codice solo su macOS e lasciando il resto invariato per altri sistemi

Altra cosa: calcola che i drop table non dovrebbero riversarsi su altri sistemi (se non erro), quindi è impossibile che una tabella oem patchata venga caricata senza che l'OEM originale sia bloccata

Hahaha benissimo. Grazie mille del chiarimento ^^

 

[elia_firenze]

problema risolto: il tutto era causato da uno stupido cavo USB di tipo A e tipo B che collegava il PC al Monitor per poter far funzionare le periferiche USB di quest'ultimo.

Special thanks guys del supporto!!