Jump to content

[Risolto] Sleep/Wake tramite iniezione nel DSDT


mrmojorisin17
 Share

116 posts in this topic

Recommended Posts

Prima prova effettuata in modalità batteria: stesso identico risultato.

Sleep ok, si spengono le spie di wifi e HD (quella del wifi si riaccende subito), ma niente Wake.

Ho provato anche disattivando l'AirPort prima di mandare in Sleep. Stesso risultato.

 

In che senso AppleUSBEHCI.kext è corretto?

 

Seconda prova in modalità corrente. Stessi tests e stessi risultati.

 

Cerco il DSDT col quale avevo il Wake immediato.

 

Edit Ho trovato il DSDT di cui parlavo sopra. Però il Wake non funziona; mi sa che la situazione che descrivevo l'avevo sotto Leopard, non sotto Snow.

Link to comment
Share on other sites

Ho trovato il DSDT col quale ottengo un Wake immediato (circa un paio di secondi) subito dopo la messa in Stop del netbook.

La cosa strana è che il Wake lo ottengo solo se nel BIOS la voce EDB (Execute Disable Bit) è settata su [Enabled].

Se la metto settata su [Disabled] non ho Wake, ma analogo comportamento a quello che ho con il mio DSDT.

Al Wake ho alcuni problemi: c'è un rumoraccio (potrebbe essere l'HD?) e la spia dell'HD lampeggia; inoltre, non appena risvegliato, il Bluetooth non è disponibile, lo diventa dopo qualche secondo.

Ho provato a riavviare per vedere se il Wake era stato un caso oppure no.

Al riavvio niente Wake. Sono entrato nel BIOS e ho visto che la voce EDB era settata su [Disabled]; in poche parole ogni volta che riavviavo o spegnevo il PC avevo il reset del BIOS.

Ho cercato e ho trovato un fix:

 

Device (RTC)
 {
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
   IO (Decode16,
   0x0070,			 // Range Minimum
   0x0070,			 // Range Maximum
   0x00,			   // Alignment
   0x08,			   // Length
   )
 })
 }

 

Ho sostituito 0x008, con 0x002 e adesso il BIOS non si resetta più.

 

Detto questo, mi sono sorti dei dubbi: se con il DSDT in allegato ho il Wake, anche se immediato, vuol dire che c'è una parte di codice che mi determina questo?

Non sono più in alto mare come prima. Il Wake adesso c'è. A cosa può essere dovuto il fatto che non rimane in Stop ma si risveglia subito? C'è qualche valore che determina questo?

 

dsdt_tea.dsl.zip

 

Edit Altro problema riscontrato con il DSDT in allegato: se metto in carica la batteria, nella barra del Finder mi dice che "La batteria non è in carica". Però la batteria è in carica (luce rossa che poi diventa verde). Questo è un piccolo dettaglio che potrei anche trascurare ovviamente!

Link to comment
Share on other sites

beh.. quel fix ce l'avevi già prima!! è il fix necessario per tutti i dsdt sotto snow! a meno che tu non usi un injector tipo elliot rtc etc.

 

altra cosa che non hai scritto è se con quel flag sul bios in enabled e il nostro dsdt elaborato fino a ieri hai o meno il wake. questo non l'hai testato o se l'hai fatto non hai riportato. cioè io continuerei con quel dsdt mettendo le modifiche dell'ultimo allegato

 

ma solo per 2 ragioni ovvero perchè nasce ed è fedele al tuo ultimo bios/hardware quindi è effettivamente meno sbagliato, e perchè ora ha tutte le modifiche propedeutiche e utili .. cioè cose comunque sane

 

unico neo il wake

se poi è una camminata in salita lavoriamo sull'altro

 

per la batteria usa il voodoobattery! cerca di focalizzare il tuo lavoro nel frattempo su un altro punto chiave:

alcuni kext non sono driver ma injectors.. altri sono drivers. in molti casi fanno quello che facciamo col dsdt.. e non so e non saprò mai se e quale priorità hanno gli uni sull'altro etc.

quindi è fondamentale tenersi più 'vanilla' possibile.. ovvero mettere quanto più possibile i kext / disablers / injectors nella Extra/Extensions.. senza ridondanze.. e lasciare quanto più invariata la s/L/E.

ovvio che la s/l/e va toccata.. per esempio i voodoobattery/voodoopower/voodoohda o vattelapesca.. e il hdaenabler se necessita .. e l'eliminazione del applehda originale se necessario.. si sa son da fare. ma per il resto stare sulla Extra.

questo perchè magari alcune cose che vogliamo fare sul dsdt magari non hanno effetto per via di eventuali altri driver.. capisci?

ordine e pulizia.

sul leo la modificha del appleehci era fontamentale.. non so su snow.

lo sleepenabler.kext per snow è comunque un elemento di disturbo.. che potrebbe influenzare gli esperimenti.

togliere anche quello se ce l'hai.. solo temporaneamente.

togli anche il cpupowermanagementdisabler.. perchè non ne hai più bisogno con il mio dsdt

 

ora studio su

Link to comment
Share on other sites

comparando i 2 dsdt vedo tante cose molto diverse.. ma l'altro è della tua stessa marca e modello???

 

ho trovato un difetto nel dsdt_wake.. il metodo DTGP che si inserisce e si invoca in tutti gli injectors.. l'hai messo alla fine del dsdt.. mentre va rigorosamente all'inizio.. tipicamente prima del WAK o comunque subitissimo

..

andando avanti..

...

allora leggendo il dsdt di questo TEA vedo che è nato e deriva da un samsung NC10.. quindi okkio.. io ci proverei.. ma okkio.

 

dunque facciamo così

prendiamo il dsdt_wake.. e ci sostituiamo il _WAK dell'altro .. e iniziamo a vedere come gira.

 

..

..

ho beccato una mia dimenticanza.. i punti in cui inserire il codice da iniettare sulla base del sistema (linux.windows.mac) nel tuo dsdt è duplice.. un pò fuori standard.. così forse avrai altre sorprese! ora ho inserito la seconda modifica

..

..

finito:

ho letto le differenze e sono tantissime.. ma non cambierei la parte hardware in toto ma affronterei appunto solo certe parti

 

ho solo un dubbio sul metodo che hai fatto SLPB

sul tuo è

Device (SLPB)

{

Name (_HID, EisaId ("PNP0C0E"))

Method (_PRW, 0, NotSerialized)

{

Return (Package (0x02)

{

0x18,

0x03

})

}

}

 

sul suo è

 

Device (SLPB)

{

Name (_HID, EisaId ("PNP0C0E"))

Name (_STA, 0x0B)

}

 

a questo punto prova con il tuo.. e ti allego una versione col suo

 

naturalmente i dsdt.aml 1 e 2 vanno rinominati

Link to comment
Share on other sites

Eccomi!

Allora per prima cosa ecco i miei kexts.

 

/Extra/Extensions:

fakesmc.kext

PlatformUUID.kext

TotallyFixStillWaiting.kext

 

/S/L/E:

AppleACPIPS2Nub.kext

AppleIntelGMA950.kext

AppleIntelIntegratedFramebuffer.kext

IO80211Family.kext

RealtekR1000.kext

VoodooBattery.kext

VoodooHDA.kext

VoodooMonitor.kext

VoodooPs2Controller.kext

 

Seguo il tuo consiglio e lascio in /S/L/E solo:

AppleACPIPS2Nub.kext

VoodooBattery.kext

VoodooHDA.kext

VoodooMonitor.kext

VoodooPS2Controller.kext

 

Gli altri 4 li metto in /E/E.

Come puoi vedere non ho né SleepEnabler.kext né NullCPUPowerManagement.kext.

Provo a testare il "nostro" DSDT con EDB [Enabled]. Volevo farlo oggi ma non ho avuto tempo.

 

Allora, il DSDT di tea è per un Samsung NC10, infatti non voglio usarlo, l'ho solo usato come spunto per le modifiche fatte al mio. Il mio obiettivo è quello di crearne uno mio, estratto da DSDTSE o preso da Ubuntu, ma che sia del mio hardware, non di un altro.

Grazie per l'immenso lavoro che stai facendo!! :)

 

Allora mettendo i 4 kexts suddetti in /E/E il SO non me li carica (avevo già provato a tempo debito quando avevo problemi con la wireless; messo tutto in /S/L/E e problemi risolti).

Perdo QE/CI e risoluzione, nonché wireless ed ethernet.

Ho rimesso tutto in /S/L/E.

Ho fatto anche le prove col DSDT con le ultime modifiche (DSDT_prova Post #48).

Questi i risultati.

In modalità corrente lo Sleep è perfettamente funzionante, così come il Wake :D , che però è immediato (come accade col DSDT di tea) :( .

Stessi problemi riscontrati, ovvero HD che fa un "rumoraccio" (credo sia lui): potrebbe essere la testina?

Inoltre il trackpad fa ciò che vuole; ho un'HD perennemente selezionato. Insomma, il trackpad ha preso in mano le redini del gioco!

Dopo un pò tutto torna normale.

In modalità batteria stessi identici risultati.

Ho notato, inoltre, che l'HD fa il "rumoraccio" solo al primo Wake, ai successivi no.

Quindi direi che dobbiamo concentrarci su questo DSDT.

Adesso il Wake c'è, se pur immediato.

Il problema è capire come mai è immediato.

Link to comment
Share on other sites

tutto ok allora

ma io lascerei la video 950 e la realtek as is!

 

domanda.. immagino ma vorrei delucidazioni sul

TotallyFixStillWaiting.kext

Link to comment
Share on other sites

ho trovato un difetto nel dsdt_wake.. il metodo DTGP che si inserisce e si invoca in tutti gli injectors.. l'hai messo alla fine del dsdt.. mentre va rigorosamente all'inizio.. tipicamente prima del WAK o comunque subitissimo

1 e 2 vanno rinominati

 

 

E' una grandissima boutade. Sia per quel metodo sia per altri con la STESSA funzione. Quel metodo puoi inserirlo dove vuoi, e' importante che la "locazione" in cui lo inserisci ti permetta di riprenderlo OVUNQUE. Chiedi a MasterChief :)

 

domanda.. immagino ma vorrei delucidazioni sul

TotallyFixStillWaiting.kext

 

Puoi eliminarlo, io lo inserisco a priori di ogni installazione e a priori non te ne accorgi;)

 

Ci sono diversi errori nel dsdt di tea che dopo le prove andrebbero corretti: il sun sulla rete interna va tolto, e' interna non pci, cosi' come il built-in in quest'ultima dev'essere 00 non 01, in quanto e' interna di primo tipo. Il "device-type" va tolto, e' un'aggiunta sbagliata. Come prova ci sta per vedere se compare e viene vista, era un dubbio anche mio ma dopo va cambiato, cosa facciamo la rendiamo prima esterna e poi interna di nuovo?

 

Il wake istantaneo che hai e' un MANCATO SLEEP, non considerarlo come soltanto un wake "veloce". Avevo questo problema sul vaio, era dovuto al sun sulla firewire.

Quella opzione che hai in bios deve essere abilitata, sui desktop e' abilitata, sulla deluxe se disattivo quella opzione snow non si avvia;)

 

In questo caso non puoi partire da un dsdt diverso, non estratto dal bios della tua piastra e provare, non ha nessun senso logico. Devi utilizzare quello che hai estratto e li' intervenire, SOLO LI'.

 

Ancora: sbus e lpcb vengono correttamente caricati?

 

Buon lavoro

Link to comment
Share on other sites

Avevo intuito che potessi eliminarlo. Però non si sa mai, meglio lasciarlo lì. ;)

 

Ripeto, il mio obiettivo è modificare il mio DSDT, non quello di tea. L'ho solo usato per prove (per quanto insensate siano state) e confronti (in certi casi rilevati utili).

Quindi, secondo te, sono passato dall'avere uno Sleep funzionante, ad avere uno Sleep non perfettamente funzionante? Seppur adesso il Wake ci sia?

 

Come faccio a controllare che SBUS e LPCB siano caricati all'avvio?

 

Grazie a te :)

Link to comment
Share on other sites

mojo hai tentato di spostare il dtgp sull'allegato che ti avevo mandato? avevo già spostato io

 

mi dai un feedback sui miei 2 allegai?

Link to comment
Share on other sites

a questo punto prova con il tuo.. e ti allego una versione col suo

 

naturalmente i dsdt.aml 1 e 2 vanno rinominati

 

Ti sei dimenticato di allegare mi sa...

 

ioreg

 

1tolls.png

 

15gp452.png

 

Caricati correttamente o no?

 

mojo hai tentato di spostare il dtgp sull'allegato che ti avevo mandato? avevo già spostato io

 

mi dai un feedback sui miei 2 allegai?

 

L'ultimo allegato che mi hai inviato è il DSDT_prova.

Link to comment
Share on other sites

Devo utilizzare questi due "Hack" di DSDTSE?

 

SBUS Hack

This hack will properly load SBUS device onto your registry.

Simply locate SBUS device by name or by adress (0x001F0003), then add this code:


		Method (_DSM, 4, NotSerialized)
		{
			Store (Package (0x04)
				{
					"name", 
					"pci8086,3a30", 
					"device-id", 
					Buffer (0x04)
					{
						0x30, 0x3A, 0x00, 0x00
					}
				}, Local0)
			DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
			Return (Local0)
		}



Example:


Device (SBUS)
	{
		Name (_ADR, 0x001F0003)
		Method (_DSM, 4, NotSerialized)
		{
			Store (Package (0x04)
				{
					"name", 
					"pci8086,3a30", 
					"device-id", 
					Buffer (0x04)
					{
						0x30, 0x3A, 0x00, 0x00
					}
				}, Local0)
			DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
			Return (Local0)
		}

		OperationRegion (SMBP, PCI_Config, 0x40, 0xC0)
		Field (SMBP, DWordAcc, NoLock, Preserve)
		{
				,   2, 
			I2CE,   1
		}

		OperationRegion (SMBI, SystemIO, 0x1C00, 0x10)
		Field (SMBI, ByteAcc, NoLock, Preserve)
		{
			HSTS,   8,

 

Lower temperatures SBRG/LPCB hack


This will allow you to have a proper LPC device registered under OSX.
It will lower your CPU temperature when using Native speedstep. (Appleintelcpupowermanagement).

Be sure to add your hardware´s LPC id to AppleLPC.kext and add this code into your DSDT.

If you get audio stuttering or audio glitches with this fix, then You have also to remove the IRQ to
Device (TMR)/(TIMR) and Device (PIC)/(IPIC)




Locate Device (SBRG) or Device (LPCB) and add the hacked id:


Device (SBRG) /* Also known as  Device (LPCB) */
		{
			Name (_ADR, 0x001F0000)
			Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x02)
					{
						"device-id",
						Buffer (0x04)
						{
							0x18, 0x3A, 0x00, 0x00 /* hack the ID.. */
						}
					}, Local0)
				DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				Return (Local0)
			}

Link to comment
Share on other sites

Sì, l'SBUS ho visto che l'avevi già inserito te, il problema è che il SO, come si può vedere da IoReg, non lo carica.

Per quanto riguarda invece l'LPCB l'ID che devo inserire è questo?

 

b9 27 00 00

 

Provo questi due e ti faccio sapere.

 

Aggiornamento

Provati entrambi i DSDT.

Con tutti e due c'è il Wake immediato e il problema del trackpad "impazzito".

Sia SBUS che LPCB non vengono caricati.

Link to comment
Share on other sites

Io ho fatto questo ragionamento: lo Sleep sembra essere funzionante, però il Wake è immediato.

Quindi, o lo Sleep non è così funzionante come sembra, oppure è il Wake che non è corretto.

Poi la cosa strana è quel fatto del trackpad che non riesco a controllarlo per un pò; invece, il rumoraccio dell'HD è sparito.

Per quanto riguarda invece l'SBUS e LPCB. Il fatto che non vengano caricati può incidere sul problema?

Domani mattina provo a stilare un DSDT definitivo. Ho fatto talmente tante prove e ho così tanti DSDT sparsi per il PC che non ci capisco più nulla!

Link to comment
Share on other sites

Buondì ;)

 

Ho ricompilato il DSDT.

Forse però mi sono perso qualche pezzo per strada, infatti c'è il rumoraccio dell'HD (Sleep/Wake come sempre).

Per quanto riguarda SBUS e LPCB nulla da fare, il SO non li carica.

Ho provato anche con i due injector di smith@@ in /E/E.

 

Rido una controllata al DSDT.

 

DSDT.dsl.zip

 

Aggiornamento

Niente, ho provato quasi una decina di DSDT, ho modificato la parte di codice relativa al Wak, all'SBUS e all'LPCB, con OSYS senza OSYS, modalità batteria, modalità coorente, Speedstep Vanilla e non, etc. etc.

Penso che mi terrò il mio Samsung N140 senza Sleep/Wake e senza che SBUS e LPCB vengano caricati all'avvio.

Ringrazio tutti per la collaborazione e gli aiuti/consigli.

 

A presto. ;)

Link to comment
Share on other sites

Sarebbe troppo bello!!!

Comunque per il momento mi arrendo, ho anche poco tempo, causa università, per mettermi a fare test e approfondire le mie conoscenze.

Eppure mi pare così strano che su due hardware così simili ci siano differenze abissali come queste.

La cosa che mi più mi fa i*******e è che c'ero così vicino...

Ora si è aggiunta anche questa cosa dell'SBUS e dell'LPCB. A quanto pare non sono così fondamentali (il SO non li carica all'avvio, però il PC si comporta bene), ma non sarebbe meglio se venissero caricati?

Link to comment
Share on other sites

 Share

×
×
  • Create New...