Jump to content

Hack Check 1.0.2


Recommended Posts

  • 1 month later...

@Gengik84Nel ringraziarti per HC, ti segnalo che nella sezione USB potrebbe non visualizzare correttamente i power supply limit.

 

Come vedi le proprietà sono presenti

943455942_Schermata2021-04-06alle20_16_52.thumb.png.b9fe360d31082c0dae40774e5d660482.png

 

Chi non usa il metodo ACPI per creare un device USBX e come me usa l'injecting tramite USBPorts.kexts (o simile...),

361868082_Schermata2021-04-06alle20_24_39.png.330e5b3033109e821951b798da4c39da.png

si trova che queste proprietà non vengano visualizzate

1274654131_Schermata2021-04-06alle20_17_34.thumb.png.9df3342b099a51bbfa55566c4c518040.png

 

Non è un grande problema, lo segnalo in quanto potrebbe essere d'aiuto e anche per indicare un metodo alternativo per aggiungerle e per verificarne la presenza...

 

Un caro saluto a tutti.

  • Thanks 1
Link to post
Share on other sites
  • Administrators

Ciao, grazie per l'osservazione

Si hai ragione, di fatto si basa come nei veri mac ossia legge il tutto da acpi di fatto quindi del relativo Device USBX

Comunque vediamo in caso di implementare la lettura da XHC quando USBX non è presente

  • +1 1
Link to post
Share on other sites
4 minuti fa, Gengik84 ha scritto:

come nei veri mac

In realtà anche nei veri mac non sono tutte presenti.

Di seguito un estratto DSDT originale da un MacBookPro14,1

Spoiler

        Device (USBX)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                Store (Package (0x04)
                    {
                        "kUSBSleepPortCurrentLimit", 
                        0x0BB8, 
                        "kUSBWakePortCurrentLimit", 
                        0x0BB8
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }
 

 

  • Like 1
Link to post
Share on other sites
  • Administrators

@FreeJHack

riguardo poi a MBP14 e successivi a essere pignoli la configurazione non è quella che mette Hackintool su usbport.kext

quella di fatto è desktop e non su tutti

la corretta sarebbe così

"kUSBSleepPortCurrentLimit", 
0x0BB8, 
"kUSBWakePortCurrentLimit", 
0x0BB8


 

Esatto, abbiamo postato insieme 🙂

 

Se guardi per esempio il codice https://www.macos86.it/files/file/84-ssdt-basic/

Applica dinamicamente il tutto a differenza tra desktop o laptop

  • Like 1
Link to post
Share on other sites
  • 2 months later...

Ciao @Gengik84! Scusa per il ritardo della risposta.

 

Si, HC va in crash pochi secondi dopo aver avviato l'applicazione. Ho notato che altri hanno visto questo comportamento e che, nelle risposte precedenti, si fosse imputato il problema alla presenza del lettore dvd o di un hub usb.

Fatalità, li ho tutti e due. Ma ho staccato l'hub (presente nel monitor) e il crash si presenta comunque. Quindi, a quel punto, ho pensato di mandare anche il mio feedback in merito ad HC

Link to post
Share on other sites
  • 4 months later...

Visto che ho smontato tutto il pc e rimontato ex novo ho evitato di rimettere il masterizzatore, ma purtroppo sulla z370 continua ad andare in crash lo stesso , sulla z77 invece è perfetto. 

Link to post
Share on other sites

Ho messo su un altro pc con mobo Asus z97-P ed un I7 4970 , anche questo ha il masterizzatore ma HackCheck non fa una piega e funziona benissimo,  a questo punto credo che il problema non dipenda dal masterizzatore/lettore , magari è l'accoppiata di questo con un altro problema che fa insorgere il crash ....

Link to post
Share on other sites

@Eniacdipende dal controller SATA specifico, per alcuni crasha, per altri no. Sul ex-mio HP 2072NL che aveva anche un controller SATA (8086,a282) che per essere supportato su macOS aveva bisogno di un device-id (il driver lo supportava, ma non caricava il kext AppleAHCIPort) macOS andava benissimo ma HackCheck crashava

On 6/30/2021 at 8:33 AM, acquarius.13 said:

il problema alla presenza del lettore dvd

Anche se dovesse essere scollegato, il percorso a PciRoot(0x0)/PCI(0x17,0x0) che è appunto il controller SATA (SAT0/SAT1) rimane, quindi per fare un test uno dovrebbe mettere su DeviceProperties la proprietà class-code FFFFFFFF su 0x17,0x0 e vedere se HackCheck crasha dopo aver riavviato

Edited by A23SS4NDRO
Link to post
Share on other sites

La scheda madre che crea il problema è una Z370 , ti posto il resoconto di sistema e lo screen di DPCI manager , vedi un po se si riesce a capire se il controller in questione è uno "strano" ? 

Nel caso volessi tentare la prova che suggerisci è corretta questa l'impostazione che dovrei inserire in OC ?  Intanto grazie per gli input @A23SS4NDRO

Schermata 2021-11-30 alle 15.30.40.png

Schermata 2021-11-30 alle 15.30.45.png

Schermata 2021-11-30 alle 15.37.48.png

Link to post
Share on other sites

Si ci avevo pensato, ma forse sono revisioni diverse ed a volte anche una piccola differenza potrebbe influire , d'altra parte se passo la mia EFI a Perdu lui con questa non riesce ad avviare , ovviamente ho considerato la diversità della GPU e l'avevo sistemata di conseguenza...eppure non avvia , sicuramente mi sbaglio ma qualcosa di diverso ci sta.....

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   1 member

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.