A23SS4NDRO

2 minutes ago, Gengik84 said:

sulla mappatura in hackintosh? 😂  😂

no su che cosa intende per connector-type, se intende la porta o se intende la funzionalità dentro il metodo

3 minutes ago, Gengik84 said:

poi ahimè, viene pensato nella stragrande maggioranza a windows al quale non frega nulla all'atto pratico

ci credo, windows non ne parliamo va ahahah😂

31 minutes ago, Gengik84 said:

un po' come il bicchiere mezzo pieno o mezzo vuoto 🙂

acpica si esprime a riguardo?

9 minutes ago, Gengik84 said:

l tutto gira sempre a secondo dei punti di vista

non comprendo dove sia la facilità che possa avvantaggiare clover rispetto ad OpenCore...

di certo, se si parla di punti di vista come ad esempio "mi piace più l'arancia rispetto alla pera" ci sta, ma quando si ha a che fare con qualcosa di oggettivo, pratico, è come se uno ora dicesse, mi trovo meglio con Chamelon piuttosto che con Clover

1 minute ago, fabiosun said:

appena ho un attimo provo

grazie, apprezzo molto

1 minute ago, Gengik84 said:

Personalmente sempre avuto interno e 3.0, questo anche tutt'ora

quindi le porte "blu" per capirci vanno sempre intese come 3.0 anche quando si tratta del corrispondente valore della porta in acpi con HS, quindi per HS01 Return ( GENG (One, 0x03)) è quello che usi attualmente e che è corretto o è più corretto definire le HS retrocompatibili come 0x00?

On 2/19/2021 at 1:37 PM, Gengik84 said:

che arrivassero a conteggiare etc... un hub esterno come fossero altre porte singole...sarebbe assurdo

alla fine come avete risolto?

Io e @dreamwhite abbiamo sentito che khronokernel diceva di mappare le porte in maniera diversa da quanto descritto qui (metodo ora in uso)

https://www.macos86.it/topic/1256-post-installazione-su-asus-z370-prime-a-ii/?do=findComment&comment=57816

ma definendo ad esempio come porte interne (0xFF) solo bluetooth o AIO interni, che non scollegheresti mai (che hanno una "higher wake priority" - e che casi come le porte del case perderebbero la funzionalità "hotplug", cosa che, tra l'altro, non mi è mai capitata e vi assicuro che uso al 99.99% delle volte le porte del front panel per collegare eventuali USB per trasferire foto, e non devo riavviare il pc per fare in modo che inserendo la porta la USB compare)

=> questa cosa che ha detto va in confitto con quanto riportato qui:

On 2/18/2020 at 5:28 PM, Gengik84 said:

le usb se intendi quelle per esempio dove è collegato il case..la giusta definizione sarebbe "interna"

Riporta invece di definire le porte come il vero connettore presente fisicamente, quindi una porta 3.0 del case che è retrocompatibile a 2.0, va definita nei corrispondenti campi (ad esempio HS01 e SS01 rispettivamente con Return (GENG (One, 0x03)) sia per HS01 che per SS01, mentre ora per HS01 utilizzo Return (GENG (One, Zero)) - cosa che mi ha stupito un po')

@Gengik84 se puoi farci un po' di chiarezza in merito, ringrazierei molto, su quale sarebbe l'approccio corretto

25 minutes ago, fabiosun said:

su aquantia 10Gigabit cablata

- hai letto anche il topic su bugtracker?

- da quale build è sorto il problema?
- hai provato ad usare una scheda di rete diversa per isolare il problema?

Il 9/2/2021 at 15:58, mac-dev ha scritto:

Non mi è mai capitato. Mi sembra strano sia la chiavetta perchè ha sempre funzionato correttamente.

Ciao, questo comportamento è perfettamente documentato in questa sezione:

https://dortania.github.io/OpenCore-Install-Guide/extras/kaslr-fix.html

Consiglio caldamente di seguire la guida per sistemare - in modo tale che tu riesca anche a capire perché avviene, e associare al problema che hai una causa che hai imparato a riconoscere

https://dortania.github.io/OpenCore-Install-Guide/

On 3/9/2021 at 4:40 PM, dreamwhite said:

Sono su un laptop con scheda WiFi (non penso influisca sul discorso LAN) senza porta LAN

Comunque ho testato a connettermi con la WiFi e il problema non c'era (prima che risolvessi con quello che ho proposto sopra)

Quindi @fabiosun se hai una fenvi in giro prova a vedere se ti torna la sezione Network collegandoti alla stessa rete ma stavolta non per via cablata ma via wireless

Allego qui il comando che ho utilizzato per risolvere:

1) Aprire il finder, e premere CMD + K

2) Dovete conoscere il path remoto dove avete abilitato la condivisione nel caso di SMB, per NFS il comando è leggermente diverso

Digitare:

smb://username:password@192.168.1.x/MyShare

Oppure se si vuole tentare con il login interattivo:

smb://192.168.2.x/MyShare al posto del comando mostrato nello screenshot

Metodo alternativo da terminale:

open 'smb://username:password@server/share'

oppure:

mkdir /Volumes/SMBShare; sudo mount_smbfs //username:password@192.168.1.x/MyShare /Volumes/SMBShare

Alla fine ho risolto con il metodo che ho spiegato in questo issue:

https://github.com/acidanthera/bugtracker/issues/1556

Ma vorrei capirci di più

@iCanaro
te se disattivi wifi etc su 11.2.3 vedi server SMB?

E invece, 2° test, se disattivi schede di rete Intel (mettendo offline l'interfaccia) e usi solo wifi, vedi qualcosa?

48 minutes ago, iCanaro said:

con bug sur la LAN funziona peggio che windows?!

Lato funzionamento standard (internet, ping etc) funziona perfettamente

Il problema ora sta nel fatto che non vi è alcuna possibilità di vedere se ci sono altre macchine sulla rete

Che scatole, ma come fanno a rilasciare delle regression così?

E poi stiamo parlando del release channel stable, non capisco

Sarà che è IntelMausi che deve essere aggiornato per essere compatibile?

Mi sa che Apple ha assunto qualche ingegnere microsoft

Just now, iCanaro said:

ben'arrivato, meglio tardi che mai

fino a quando avevo 11.2.2 non avevo problemi con Lan intel e realtek

Potete verificare (se avete server SMB sulla vostra rete) se dopo l'aggiornamento da 11.2.2 a 11.2.3 vi compaiono gli stessi in Network?

22 minutes ago, Gengik84 said:

Quello che conta è lilu primo

in realtà se mettessi prima qualcosa del tipo prima FakeSMC e poi Lilu non sarebbe errato, addirittura lo stesso vale se metti prima RealtekRTL8111" e poi Lilu

1 minute ago, Gengik84 said:

ma intendevo che puoi in caso vedere e verificare cosa può aver fatto di errato

si certo ma a questo punto conviene direttamente andare a mano piuttosto che aprire un configurator e poi andare a vedere dove eventualmente ha fatto ehm.. "stupidaggini"

1 minute ago, Gengik84 said:

puoi sempre vedere cosa è stato fatto al plist

certo ma devi usare altri tool per farlo

Non è irrilevente che possa corrompere il plist secondo me..

these rarely respect OpenCore's configuration and even some like Mackie's will add Clover properties and corrupt plists!

4 minutes ago, carlo_67 said:

uso anche l'Opencore configurator

diciamo che il problema è che si inserisce in un contesto in cui la documentazione già ci sta, non è come clover che non hai un reference manual scritto come si deve - il config-sample.plist presente nel cloverv2.zip è penoso, etc

personalmente non lo vedo necessario anche perché non vedo cosa sta succedendo "under the hood" con un applicazione che non è opensource, e può fare anche danni

1 minute ago, Gengik84 said:

Quello che conta è lilu primo

Dipende, infatti come avevo citato prima:

3 minutes ago, A23SS4NDRO said:

Lilu being first isn't a requirement - it just needs to load before any of its plugins.

La regola generale de facto è "i plugin vanno dopo"

1 minute ago, Gengik84 said:

trovate WEG prima di AppleALC

si ma non sono dipendenti tra loro quindi non cambia...

On 3/3/2021 at 10:36 PM, damiandrake said:

è bastato mettere VoodooHDA

diciamo che è più una pezza che una soluzione

8 minutes ago, Gengik84 said:

non c'entra nulla..

diciamo che i commenti un po' lo suggeriscono:

Però ho sentito opinioni differenti.. riporto alcune citazioni:

1)

Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended.

2)

Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it.

3)

Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise.

4)

[...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting

8 minutes ago, Gengik84 said:

non c'entra nulla..

diciamo che i commenti un po' lo suggeriscono:

Però ho sentito opinioni differenti.. riporto alcune citazioni:

1)

Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended.

2)

Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it.

3)

Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise.

4)

[...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting

per mappare senza Xhciportlimit, riflettevo, c'è un metodo a parte oppure si mappano prima le prime 15 USB 2.0 che compaiono su ioreg - poi si disattivano tutte le 2.0 manualmente su ssdt originale con GUPC(zero) e si controlla cosa succede alle altre 10 3.0?

Attenzione che RTL8100 di mieze, la V2.1.0 potrebbe dare problemi (almeno quando l'ho testata io su catalina con un Dell inspiron 5570, quando collegavo il cavo di rete non voleva saperne, si assegnava un IP da solo senza contattare il DHCP server - nonostante fosse attivo.) Solo la 1.0.0 release funzionava alla perfezione, dovrebbe essere stata aggiunta da @iCanaro tempo fa