lenovo t420, sleep usb acpi undsoweiter

n'abend miteinander

es geht um ein lenovo thinkpad t420 (hardware mit dem x220 in meiner signatur identisch), dem ich gerade mavericks versuche, überzuhelfen.
eckdaten zur Installation: mavericks 10.9.5 ist drauf, gebootet wird mit clover.
zusätzliche/bearbeitete kexts: - acpibatterymanager.kext (zzgl.dsdtpatch von rehabman für x220), eine bearbeitete appleHDA.kext (funzt mit dsdtpatch), intele1000e.kext fürs netzwerk, fakesmc.kext (klar, version 6.14.1364), eine voodoops2.kext sowie (und da klemmts) ein rollback der appleACPIPlatform.kext aktuell auf 10.8.3

in der dsdt hab ich aktuell vid-rename-to-igpu, pnlf für hd3000, batterypatch für x220 (gleiche hardware) und einen patch für den conexant-irgendwas-audiocodec (funzt) zzgl.dtgp-methode (und vorher diverse errors ausgemerzt).

so. mein problem ist, dass es seltsame probleme mit sleep/wake gibt: mit der originalen appleacpifamily.kext geht das Notebook brav in den sleep, die "mond-led" leuchtet und die led im anschalter pulsiert langsam vor sich hin (menue-sleep, fn&f4 und zuklappen das gleiche), also fast alles so, wie es soll.
wenn ich es aber nun wecke, hört die led im anschalter nicht mit dem pulsieren auf, und der mond bleibt an. das notebook funktioniert aber weitgehend normal, ausser, dass sich meistens der bluetooth verabschiedet (hab keine gesetzmässigkeiten ausfindig machen können, meist weg, gelegentlich nicht). beim nächsten sleep hört dann das pulsieren des anschalters auf, auch beim wake bleibt es dann aus (bei sleep nr.3 wird wieder pulsiert, sleep nr.4 nix, etcppppp.....), und der mond leuchtet bis zum nächsten reboot/ausschalten weiter -
mit einem rollback der appleACPIFamily.kext zu der aus 10.8.3 (vom x220 geklaut) benehmen sich die leds wie sie sollen, der anschalter blinkt "aufgeregt", während das sleepfile geschrieben wird (hibernatemode 3), dann pulsieren+mond, was nach dem wecken wieder aufhört. dann sind aber auch alle usb's deaktiviert (der komplette EHC1) bis auf bluetooth und die interne webcam, die hängen am EHC2, der tut weiter.

ich hab fleissig herumexperimentiert, und kann das problem tatsächlich auf die appleACPIFamily.kext eingrenzen, selbst ein tausch der in der kext enthaltenen plugins -> rollback auf 10.8 hat nix gebracht. die plist ist in den unterschiedlichen versionen identisch (bis 10.6 runter)
nun wärs recht schick, wenn ich entweder die acpi.kext von 10.9.x überredet bekäme, die leds anständig zu bedienen, oder aber die acpi.kext aus 10.8 sich dazu herabliesse, auch den EHC2 wieder mit aufzuwecken...

fällt euch was dazu ein?

gruss von grT

ps. der Lüfter wird im hwmonitor auch nur gelegentlich mal angezeigt, das würde ich auch gerne nebenbei noch lösen..

moin fundave!

also usb funktioniert einwandfrei bis zum sleep, bluetooth (und die webcam) hängen am internen EHC2 (usb) und funktionieren auch nach dem aufwachen weiter - bei einsatz der AppleACPIFamily.kext aus 10.8.3. damit funktionieren auch die led's einwandfrei. nur die ports sind nach dem aufwachen tot inkl. der stromversorgung. sie werden allerdings ordnungsgemäss in "über diesen mac" angezeigt - vielleicht ist auch nur die stromversorgung weg (vielleicht sollte ich mal ein usbgerät mit eigener stromversorgung anschliessen? mach ich gleich mal)

mit der originalen AppleACPIFamily.kext spinnen die led's, der bluetooth wacht meist nicht wieder auf, die kamera schon (scheint also ein anderes problem zu sein, das mit dem bluetooth), aber die usbports funktionieren, bis auf eine nervige meldung, dass man die laufwerke doch bitte ordentlich auswerfen möge (wenn ein externes laufwerk beim sleep angeschlossen war)

cmosresets o.ä. gibts nicht, der haken bei rtcpatch ist im clover gesetzt.
wlan gibt es noch nicht, dafür müsste das bios geflasht werden, mit sowas tu ich mich ziemlich schwer

ach ja, die unterschiedlichen bioseinstellungen bzgl. usb hab ich durchprobiert, hat keinen Einfluss.

griven: ja hast recht. und ich bin auch schon etwas weitergekommen - es ist definitiv die acpi.kext, die querschlägt, ich hab mich rückwärts durch die versionen gearbeitet: spinnende led's ab 10.8.5, von 10.7.x - 10.8.3 -> kein usb nach dem aufwachen, aber led's normal, und mit der aus 10.6.? (die alte rollback-kext) -> led's und usb ok., dafür aber kein ton mehr nach dem aufwachen.
inzwischen hab ich auch eine wunderbare dsdt im netz fürs t420 gefunden, in der jede veränderung mit kommentar (was verändert und warum) versehen wurde . bin gerade am vergleichen und stückweisem einbauen.

ergebnis wird mitgeteilt, evtl. mach ich auch gleich noch einen yosemite-test.

EDIT 1:
die verwirrten LED's hab ich zur vernunft gebracht -> anpassung der _WAK-methode.
anscheinend hat sich auch der lüfter mit eingekriegt, seit dem patch wird er zuverlässig im hw-monitor angezeigt und das phänomen, dass er nach dem aufwachen mit höchstgeschwindigkeit dreht, ist auch nicht mehr aufgetreten.

eine macke bleibt bestehen: bluetooth wacht nicht wieder mit auf. am internen usb liegts nicht (also keine "drehung" der vorherigen macke), die webcam wacht auf. deviceID in die plist der broadcom....kext in IOBluetoothFamily.kext einzutragen hat es nicht gebracht, ansonsten fällt mir aktuell nix dazu ein.

griven: ich erinnre mich, dass du das problem mit dem t61 auch hattest, hast du es gelöst?

EDIT 2:
was den lüfter betrifft, hab ich mich zu früh gefreut, die anzeige bleibt unberechenbar, meist ist er nicht da. Konsole sagt: HWMonitor Number of Fans 0. damit könnte ich aber leben.
bzgl. bluetooth ist mir noch aufgefallen, dass er anscheinend kurz mitaufwacht, und erst nach so etwa 1-2 Sekunden verschwindet: die LED geht an, das Symbol in der finderleiste ist schwarz, dann erst geht die led wieder aus, und das Symbol ist grau und durchgestrichen.
seltsam war einmal, dass die LED's sich noch einmal etwas verwirrt benommen haben nach wake - hektisches blinken, so, wie beim hibernatefile schreiben - und da hatte sich bluetooth nicht deaktiviert (und der Lüfter wurde angezeigt)
IOBluetoothFamily-backroll (test mit 10.8.5 -> funktioniert beim w520 mit gleicher konstellation) funktioniert auch nicht.
:lateinEnde:

das ist aber sehr unfein vom t61...
machst du denn aktuell ein rollback vom acpi? - und du hast yosemite am laufen?
also ein tipp für bluetooth wär der, den adapter vom t60 einzubauen. ganz sicher bin ich nicht, ob ich da richtig lieg, aber ich hab ein t61-intel am laufen (t61p hab ich schweren herzens verschenkt ) in dem der bluetooth vom t60 steckt, und der benimmt sich.
wenn ich mehr rausfinde, sag ich bescheid.
und ich werd die tage ein t61 aufsetzen - 10.10 oder 10.9 - besser dann doch 10.9, oder was rätst du?

etwas investieren muss schon noch sein - 1gb geht gar nicht - und das middletonbios muss auch sein, schon wg. wlan. mit dem rest kommen wir klar.
dann lass ich das lieber mit yosemite, vielleicht mal ein test mit einem der anderen. angucken würde ich es ja schon gern mal...

EDIT 1:
bin mit dem bluetooth etwas weiter gekommen, wenigstens hab ich ein paar infos zusammenklauben können:

im systembericht sowie im ioregexplorer wird die "erforderliche Stromstärke" jeweils mit 0 angegeben. bei allen anderen geräten (extern/intern) steht hier was sinnvolles. kommt mir sehr seltsam vor, und könnte ein symptom des problems sein (oder?)

ich nutze rehabmans ahci-patch - dort wird alles was im device EC ist in 8-bit konvertiert:

beispiel (der eintrag ist für bluetooth)

hier werden aus dem einen 16-bit eintrag 2 8-bit Stückchen gemacht, und später wieder zusammengefügt:

die methode (B1B2) wird dazu oben in der dsdt definiert (so wie auch die dtgp).

soweit gut, leuchtet mir ein, aber nun gibt es ausserhalb noch einen Eintrag bzgl. bluetooth:

kann es sein, dass aufgrund der Veränderung im EC diese methode nicht mehr zum Zuge kommt? oder versteh ich da was falsch? in welche richtung funktioniert die b1b2-methode, nach draussen, so dass die zerlegerei für den aufruf der methoden ausserhalb des EC-devices keine folgen hat?
oder andersrum, von "aussen nach innen", dann dürfte das so eigentlich nicht funktionieren ???? grmpff....
:kopfrauch&lateinEnde: