Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Ok,
das aus mit der Länderkennung geht auch über Clover, das finde ich aber aktuell nicht.
ich schaue morgen früh nochmal nach dem genauen Eintrag und poste ihn dann.
damit sollten beide Log-Meldungen beseitigt werden.
ansonsten wie du gesagt hast... Warten ob es wieder Auftritt... 
Hallo und 
!
Müsste man als quick'n'dirty-Hack nicht einfach
Im KextToPatch-Array der config.plist einfügen können?
Jup,
@YogiBear hat Recht...
Der Eintrag sollte helfen.
Da es sich um der reinen XML-Code handelt, muss der über einen Text-Editor wie TextMate eingebaut werden, da der Clover Configurator nur als GUI dient.
Warum zeigt es in deinem zweiten Screenshot die "Airport Extreme (0x168v, 0x8f)" an?
Hattest du bereits einen anderen Kext installiert oder eine andere "Umbiege"-Variante aktiviert?
Wenn ja, muss entweder der Kext wieder auf das Original von Apple oder der umgesetzte Patch zurückgebaut werden, da ja laut PCI-List vom DPCI-Manager eine 0x168c,0x2e verbaut ist.
Feierabend und weiter geht es
Ich versuche es nochmal vollständig zu beschreiben, wo ich gerade stehe:
Wenn ich es richtig verstehe, so ist damit gemäß der Anleitung von toleda die Karte trotzdem prinzipiell betriebsbereit. Sie hat aber noch die oben beschriebene Probleme.
Also wieder zurück zur vorherigen Methode
Danach hatte ich gemäß Clover-Wiki verstanden, dass ich die nunmehr erkannte WIFI-Karte auf eine nativ unterstütze Variante per FakeID umschießen kann. Hier bin ich mir aber nicht so sicher ...
Alternativ kann ich auch das kext oder DSDT patchen. kext würde ich aber gerne wegen Systemupdates vermeiden.
"Was nun?", sprach Zeus, äh Crom, also ich
Hi Crom,
Also ich würde an dieser Stelle den DSDT-Patch vorziehen, da der Update unabhängig ist.
EDIT:
Wenn du beim Starten, im Clover Bootmenü, die F4-Taste drückst, wird die Original DSDT aus dem BIOS in den Ordner /CLOVER/Acpi/Origin abgelegt und du kannst sie, als ZIP gepackt, hier posten.
Dann kann ich dir den DSDT-Patch einbauen...
Da komme ich doch gerne gleich drauf zurück. In der Zwischenzeit hat sich ein Erkenntnisgewinn eingestellt den ich erstmal verprobe.
Ich habe nochmal von vorn bzgl. des KextsToPatch den Boot-Prozess mit allen Debug-Optionen durchlaufen lassen:
Der Fehler an dieser Stelle war, dass im aktuellen Clover Configurator am Ende der Zeile noch von STRING auf DATA umgestellt werden kann. Die Version im Video hatte diese Einstellung aber gar nicht Nun steht im debug.log
Im Ergebnis kann ich nun mit Hilfe des IORegistryExplorer unter der Section IO80211Plane -> AirPort_ArtherosNewma40 den hübschen Eintrag pci168c,2e lesen. Vorher stand da natürlich der falsche pci168c,2a drin (Siehe Screenshot)
Ein Schritt in die richtige Richtung Jetzt warte ich mal ab, ob sich was verändert hat ...
EDIT und Update:
Und im Anhang habe ich jetzt mal alles aus dem origin-Ordner verpackt. Zusätzlich dazu noch die aktuelle config.plist, damit man sich dazu mal ein Bild machen kann.
Das sieht doch schon mal gut aus...
Die Meldungen sind an sich nicht schlimm, solange das WLAN selbst stabil läuft.
Ich bin gerade am Patchen der DSDT, aber mir fehlt noch eine kleine Information.
Würdest du bitte mal den IORegistryExplorer herunterladen, ausführen und über "File"->"Save" die aktuellen Angaben als .ioreg-Datei sichern?
Danach bitte als ZIP hier hochladen.
Der Grund liegt darin, dass ich in der DSDT selbst nicht sehen kann, an welchem Bus die WLAN-Karte hängt und somit auch den Inject nicht machen kann.
Ok...
hier wäre die DSDT.aml...
in Ausgepackter Form muss sie in den Ordner /CLOVER/Acpi/patched.
Deinen Clover Inject musst du aber deaktivieren, da sich beide Teile beissen werden.
Viel Erfolg
Hallo nochmal,
eigentlich wollte ich erst morgen weiter machen. Aber die Neugier ..
Ich habe die DSDT nun in Benutzung. Vielen Dank dafür erstmal.
Moin,
wie bereits gesagt...
Die Meldungen sind an sich nicht schlimm, solange das WLAN selbst stabil läuft.
Ich drück mal die Daumen, dass die Verbindung durchhält... 
Weiter geht die Tour mit WLAN und einen erneuten Fortschritt gibt es auch.
Der "Atheros Locale Fix" von oben fixed ja nicht mein Problem, sondern die Fehlermeldung ATHR: unknown locale: 21.
Um nun die Fehlermeldung ATHR: unknown locale: 809c zu fixen, gibt es bereits einen config.plist patch zu finden auf insanelymac.com:
Faktisch wird also der HEX-String 0FB787DC040000 (BASE64: D7eH3AQAAA==) durch B8640000009090 (BASE64: uGQAAACQkA==) ersetzt. Die 64 in letzterem HEX-String ist nix anderes als die regulatory domain WOR4_WORLD für den amerikanischen Raum und definiert damit die locale: FCC. Nachlesen kann man das gut bei linuxwireless.org.
Und da wir hier in Europa sind, kann man an der Stelle auch z.B. die regulatory pair group 37 wählen. raus kommt dann die locale: ETSI und der patch sieht dann also so aus:
Ich hoffe, dass hilft mal jemandem. Mir hat es zumindest Ruhe im wifi-log, eine bisher stabile WLAN-Verbindung und eine vernünftige locale für WLAN im Systembericht gebracht.
Vielen Dank für die tolle Erklärung...
Ich frag mich ob wir dir noch helfen können ... Du hast grade etwas als Anfänger ganz allein geschafft ... Die frage ist lernen wir jetzt noch mehr von dir ? 
