adamantinum

Ciao, grazie della risposta. Sì, tutte le altre macchine virtuali partono, anche la recovery di Monterey, e IOMMU è abilitato.

Buonasera a tutti, Sto provando a far girare Monterey su qemu, usando la configurazione di OpenCore di https://github.com/kholia/OSX-KVM, che in passato avevo visto funzionare. Il processo di installazione da recovery funziona, anche il primo riavvio, al successivo (dove immagino dovrebbe entrare nel sistema per la configurazione finale) si blocca alla schermata seguente: https://ibb.co/DbwVKjd Guardando nella sezione di risoluzione problemi di dortania ho provato quanto propone, fra cui abilitare SetupVirtualMap per le VM: https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#stuck-on-eb-log-exitbs-start Ho provato anche ad aggiornare OC e il plist (https://pastebin.com/XzsrXC79) all'ultima versione, ma il problema si presenta comunque. Spero qualcuno sappia consigliarmi, grazie in anticipo.

Grazie, speriamo nei successivi rilasci torni il classico DMG...

Scusa se rispondo a un messaggio di qualche giorno fa, ma oggi stavo guardando proprio quelle immagini dmg. Sarebbero l'equivalente di BaseSystem.dmg? Perché provando a convertirle in iso da Linux (sia con qemu-img che con dmg2iso) mi dice che il file è corrotto e non trova qualche cosa specifica UDIF, mentre se uso una recovery di Big Sur riesco a convertire tranquillamente il "vecchio" BaseSystem.dmg.

@xballox piccola correzione: mi è stato fatto notare che VoodooTSCSync non è più aggiornato, tuttavia esiste un plugin di Lilu, CpuTscSync, che dovrebbe svolgere la medesima funzione. Non l'ho ancora provato, ma tienilo comunque presente nel caso volessi aggiornare.

A me fortunatamente era bastato quello, però ho usato le beta, non le ultime release... Puoi trovarle sul sito di dortania oppure provare a compilare da te.

Ho ricompilato Lilu e Whatevergreen agli ultimi commit e pare sia stato sufficiente per risolvere.

Grazie per il suggerimento, ma purtroppo il problema persiste sia provando il boot arg, che provando il plugin...

Buonasera, Ho aggiornato da un po'a Big Sur e ho notato molti miglioramenti rispetto a Catalina. L'unico problema creatosi è l'impossibilità di risvegliare il monitor del laptop dopo la messa in stop del sistema (qualsiasi sia l'hibernatemode: 0, 3 oppure 25): resta soltanto lo schermo nero illuminato, pur "funzionando" premendo i tasti sento i suoni di sistema. Provando tuttavia a collegare un monitor esterno VGA si risveglia anche lo schermo interno e posso usare il sistema senza problemi (oltre a vedere gli effetti dei tasti premuti a schermo nero illuminato). È un problema di iGPU come credo? Esistono solzioni? Oppure posso crercare file di log per riportare un issue, a Lilu o Whatevergreen suppongo? La EFI è quella in firma, OpenCore versione 0.6.1, il problema avviene per qualunque versione di BS. Grazie in anticipo a tutti.

Figurati! Sono stato un anno con un sistema inutilizzabile perché non sapevo come risolvere, ora non posso che aiutare chi è nello stesso problema 🙂

Avevo problemi con glitch simili dopo l'aggiornamento del firmware UEFI di ASUS, ho risolto col kext VoodooTSCSync. Prova, magari funziona anche per te.

Breve aggiornamento, forse ho capito dove sia il problema (o parte di esso): se nel config abilito come satelliti sia ELAN che HID, indipendente dall'ordine con cui i kext sono dichiarati, per qualche motivo viene caricato solo ELAN e il touchpad non va. Se abilito solo HID il touchpad non è riconosciuto dalle impostazioni, ma funziona per spostare il cursore e per cliccare, mentre le gesture a più dita non vanno. Considerando che dà questo problema anche con versioni più vecchie di I2C che in passato mi funzionavano mi verrebbe da pensare sia cambiato qualcosa nella gestione dei kext...

Ecco qui, non vedo dove possa essere la differenza rispetto a quando qualche mese fa funzionava tutto, prima di rifare la EFI. archivio.zip

Allora non ho capito di quale Darwin parli, ho presente solo quello del controllo.

No, il Darwin adesso non c'è. Il Kernel Panic avveniva con Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { GPEN = One SBRG = One } If ((SBRG == Zero)) { Return (Zero) } If ((GPEN == Zero)) { Return (Zero) } Return (0x0F) } Invece boota riducendo il tutto a Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } Ioreg è il seguente... All'avvio il touchpad dovrebbe essere riconosciuto e pinnato senza problemi, se sapessi come controllare i blog di boot verificherei. ioreg.zip

0x0f, ho sbagliato a scrivere nel post.

OK, il problema era proprio Return (0x0f). Seguendo la guida su dortania avevo aggiunto un if (_OSI("Darwin")) che rendeva alcuni oggetti col valore giusto LER far ritornare 0x0f a _STA. Non perché ma dava panic. Sostituendo tutto con solo Return (0x04) boota senza problemi. Il touchpad però non va 😂

L'avevo già fatto con SSDT, ora ho provato anche direttamente in DSDT ma va comunque in panic... Mi è stato consigliato di chiedere direttamente sul supporto di VoodooI2C, magari sanno se il panic è colpa del kext (credo proprio di sì dato che riporta VoodooGPIO nel backtrace). Al limite rifaccio la EFI da capo quando esce OC 0.6 😄

Purtroppo sono ancora qui 🙁 Dopo aver patchato il DSDT (allego se qualcuno vuole controllare), al remoto va in Kernel Panic a VoodooGPIO, eppure mi pare di aver seguito correttamente l'ordine dei plugin suggerito dalla documentazione VoodooI2C (Services, GPIO, I2C) e la guida per il GPIO pinning: dispositivo ETPD, pinning eseguito manualmente. Codice apice 0x6d, quindi il pin decimale è 85 e quello hey 0x0055. Qui una foto del Panic, se può servire: https://ibb.co/9WjVwk5 Grazie per la pazienza 😅 DSDT.aml.zip

Parte, grazie mille! Ora ho applicato le patch e devo solo trovare l'ordine corretto dei kext per evitare vada in panic ahah. Ma a cosa serieve la patch per la batteria che hai messo? Dovrebbe influire sulla durata? Perché ho notato che il PC si scarica in fretta.

Patchato in che senso? Indicatore e percentuale di batteria funzionano, usando solo SMCBatteryManager

Questo sembra proprio qualcosa del DSDT...

Va bene, provo. Input l'avevo messo perché adesso è incluso tra i plugin di I2C

Senza boota normalemente. L'ordine dei miei kext è il seguente: Lilu VoodooTSCSync VoodooInput VoodooI2CServices VoodooGPIO VoodooI2C VoodooI2CELAN VoodooI2CHID VoodooPS2Controller VoodooPS2Keyboard VirtualSMC.kext SMCBatteryManager SMCSuperIO WhateverGreen AppleALC USBInjectAll

Purtroppo si blocca sempre a questo punto e poi dà il simbolo di divieto.