Gengik84

ripercorri il topic ti passai un injector da installare in L/E e un fixup da mettere in EFI

Ho spostato il topic in una sezione più idonea

stesso hub? con la patch attiva le usb sono tutte diciamo disponibili

allora posso farci poco se in quella porta non funziona comunque a questo punto rimetti il tutto, ultimi allegati, così almeno ti funzionano correttamente tutte le altre porte del case Non vorrei che fosse proprio quell'hub a essere problematico

emoticon_Welc2

mmm allora non dipende dalla mappatura perchè nella configurazione precedente hai la patch per port limit, che ti sblocca quindi ogni possibile porta disponibile nella mobo oltre all'hub, se colleghi altro in quella porta che sia 2.0 o 3.0 funziona? Ha scritto dopo 31 secondi: a questo punto fai anche la prova con hand-off disable

ritorna a questa configurazione https://www.macos86.it/viewtopic.php?p=35097#p35097">viewtopic.php?p=35097#p35097">https://www.macos86.it/viewtopic.php?p=35097#p35097 collega quell'hub in quella determinata porta e dimmi se funziona, se funzionasse allega ioreg Controlla anche sul bios se hai la voce Xhci handoff, e fai sapere

Scusa il ritardo adesso rispetto alla mappatura precedente avevi più usb quelle non in uso sono disattivate, tu hai controllato il tutto?

No perché le ACPI non sono chiamate in causa ancora rimane fermo su boot.efi e kernel

quali driver stai usando?

il kext con il driver efi non ha nulla a che vedere il driver ha funzioni specifiche

A cosa ti serve VitualSMC.efi?

affermazione

Sostituisci,riavvia e posta ioreg Archivio.zip

emoticon_Benv

in quelle due non importa in quanto solo usb 2.0 e già le vedo così su ioreg Ha scritto dopo 37 secondi: Quelle due nere per intendersi nella foto che hai allegato

Figurati :D Sostituisci, rimuovi il dsdt e riavvia ripeti la mappatura ma ricordati che nelle porte usb 3.0 ossia quelle blu devi collegare sia un dispositivo 2.0 sia un uno 3.0 Quanto hai finito su tutte le usb salava IOReg e allegalo config.plist.zip

Per fortuna le cose sono migliorate sia per funzioni del Bootloader stesso sia anche per i bios..come hai detto precedentemente tu

@fabiosun[/mention] lui lo sa bene avendo avuto serie X tra cui X99.. ma diciamo forza maggiore perché KernelPM era nullo a riguardo

Comunque sia anche se ti serve quel fix, ti sconsiglio vivamente da amico di andare a modificare un bios per questa cosa emoticon_sorriso

io per esempio non lo uso in aggiunta non so se gigabyte o comunque il tuo modello esatto può avere opzioni nel bios a riguardo del tipo CFG lock

comunque prova senza quel fix, ho notato che schede che è richiesto lo stesso fix usando clover, con OC c'è una diciamo buona percentuale che nemmeno gli serve

ma poi scusa eh una correzione diretta su bios per cosa poi? quando non c'e bisogno e per non usare kernelPM? ma dai non ha alcuna logica. Ha scritto dopo 11 minuti 8 secondi: Quella cosa è estrema, quando la funzione di KernelPM...definiamola patch al "volo"...patch dinamica o come si vuole chiamare...fallisce allora per ovvi motivi si usa quella modifica, che di fatto è più invasiva... ma quando non se ne può fare a meno... fare una cosa del genere per non usare il fix, per me è illogico ti porto un esempio semplice oggi cè ' AppleALC per l'audio... è come se uno andasse a patchare AppleHDA direttamente e lo rifacesse per ogni aggiornamento del sistema Ha scritto dopo 1 minuto 53 secondi: diciamo è palese che AppleALC è decisamente migliore... Altro esempio al tempo, tu lo ricordi bene senz'altro, lo script di Toleda... che tramite patch sul config e un dummy in EFI faceva funzionare l'audio senza "toccare" in modo invasivo appleHDA

no

No ti sbagli se hai msrE2 locked nemmeno avvii... il Bootloader non riesce nemmeno a leggere il kernel stai fraintendendo proprio il discorso