BIOS/Acpi DSDT-Tabelle editieren
BIOS/Acpi DSDT-Tabelle editieren
Hi,
an meinem Notebook klappt es trotz 2.6.9 Kernel nicht den Akkuladezustand auszulesen.
Acpi und Acpid etc sind drauf. APM wird von meinem BIOS nicht unterstützt.
Ok, da Battery und ac_adapter nicht gelesen werden können, wird wohl die DSDT-Tabelle des BIOS einen Schuss haben. Update vom BIOS kann ich nicht machen, da der Acer keine neuere Version anbietet.
Mein Notebook: Acer Extensa 3001 WMLi
Mein OS: Mepis Linux 2004.3 (100%Debian-Kind )
Habe mir den Intel Interpreter für die DSDT-Tab gezogen, nur leider sind das tausende Zeilen.
Eine Runde googeln konnte mir nicht wirklich helfen. Zwar fand ich ein Tutorial, jedoch beschränkt sich dieses auf ASUS-Notebooks und ist somit für mich unbrauchbar.
Hat von Euch jemand Quellen dazu?
Wäre für jeden Tipp dankbar.
MfG
an meinem Notebook klappt es trotz 2.6.9 Kernel nicht den Akkuladezustand auszulesen.
Acpi und Acpid etc sind drauf. APM wird von meinem BIOS nicht unterstützt.
Ok, da Battery und ac_adapter nicht gelesen werden können, wird wohl die DSDT-Tabelle des BIOS einen Schuss haben. Update vom BIOS kann ich nicht machen, da der Acer keine neuere Version anbietet.
Mein Notebook: Acer Extensa 3001 WMLi
Mein OS: Mepis Linux 2004.3 (100%Debian-Kind )
Habe mir den Intel Interpreter für die DSDT-Tab gezogen, nur leider sind das tausende Zeilen.
Eine Runde googeln konnte mir nicht wirklich helfen. Zwar fand ich ein Tutorial, jedoch beschränkt sich dieses auf ASUS-Notebooks und ist somit für mich unbrauchbar.
Hat von Euch jemand Quellen dazu?
Wäre für jeden Tipp dankbar.
MfG
Bei gentoo gibt es ein gutes HowTo, aber einfach wird es trotzdem nicht
http://forums.gentoo.org/viewtopic.php?t=122145
http://forums.gentoo.org/viewtopic.php?t=122145
Ich hoffe mal du hast dich nicht allzu sehr in dieses Thema reingesteigert. Dieses Problem hab ich bei meinem Travelmate 4001WMLi auch. Es liegt allerdings nicht an einer fehlerhaften DSDT, sondern an der mangelnden Unterstützung der Smartbattery-Technologie durch Linux. Ich hoffe dass sich das schnell ändert, ansonsten ist Linux auf diesem Notebook mehr oder weniger unbrauchbar.
kann mir einer erklären, was es mit diesen ominösen tabellen auf sich hat?
immer wird darauf hingewiesen, dass diese tabellen "buggy" oder "defekt" seien und daher das powermanagement oder sonst was nicht funktioniert - aber unter windows tut es das doch auch, trotz des "defektes".
was verstehe ich da falsch?
immer wird darauf hingewiesen, dass diese tabellen "buggy" oder "defekt" seien und daher das powermanagement oder sonst was nicht funktioniert - aber unter windows tut es das doch auch, trotz des "defektes".
was verstehe ich da falsch?
"In den reichen Ländern hat die Freiheit gesiegt - mit all den schrecklichen Folgen, die das für die anderen mit sich bringt und noch bringen wird. Die Demokratie ist auf andere Epochen verschoben." (L. Canfora)
Hi,
verständlich, dass DSDT einem nicht viel sagt auf Anhieb.
Ich sehe das so und werde es mit einem kleinen Fallbeispiel erklären:
Wenn Du einen Spanischkurs besuchst, der 150€ kostet und 2 Wochen geht, dann kannst Du mittemäßiges Spanisch.
Wenn Du einen Kurs besuchst, der 1000€ kostet und 8 Wochen geht, dann kannst Du gut Spanisch.
Wenn Du mit schlechtem Spanisch in Provinzen gehst, dann verstehst nicht viel. Mit gutem Spanisch schon.
So auch hier: Wenn Du ein finanziel starkes Unternehmen bist, dann kannst Du Deine ACPI-Programme sehr flexibel programmieren.
Wenn Du eine Community mit begrenzten finanziellen MItteln bist, dann kannst du dich nur auf Standard konzentrieren. Die DSDT-Bios-Tabellen sind fast alle fehlerhaft und schlecht vom Coding. Microsoft ist hier sehr flexibel im Vergleich zu Linux, sodass es mit MS geht.
Das Powermanagement unter Linux ist offen gesagt weit hinter dem Windowsstandard. Würde hier für Entwicklung und mehr Programmierer mehr Kohle bereit stehen, dann würde das alles auch unter Linux sauber laufen.
Ich hoffe, dass ich Dir das etwas verständlicher machen konnte.
verständlich, dass DSDT einem nicht viel sagt auf Anhieb.
Ich sehe das so und werde es mit einem kleinen Fallbeispiel erklären:
Wenn Du einen Spanischkurs besuchst, der 150€ kostet und 2 Wochen geht, dann kannst Du mittemäßiges Spanisch.
Wenn Du einen Kurs besuchst, der 1000€ kostet und 8 Wochen geht, dann kannst Du gut Spanisch.
Wenn Du mit schlechtem Spanisch in Provinzen gehst, dann verstehst nicht viel. Mit gutem Spanisch schon.
So auch hier: Wenn Du ein finanziel starkes Unternehmen bist, dann kannst Du Deine ACPI-Programme sehr flexibel programmieren.
Wenn Du eine Community mit begrenzten finanziellen MItteln bist, dann kannst du dich nur auf Standard konzentrieren. Die DSDT-Bios-Tabellen sind fast alle fehlerhaft und schlecht vom Coding. Microsoft ist hier sehr flexibel im Vergleich zu Linux, sodass es mit MS geht.
Das Powermanagement unter Linux ist offen gesagt weit hinter dem Windowsstandard. Würde hier für Entwicklung und mehr Programmierer mehr Kohle bereit stehen, dann würde das alles auch unter Linux sauber laufen.
Ich hoffe, dass ich Dir das etwas verständlicher machen konnte.
ok, dass die community nicht so viele ressourcen aufbringen kann, leuchtet mir ein.
ich hoffe, ich habe das so richtig verstanden: die hardwarehersteller haben einen standard fehlerhaft implementiert und dass es MS quasi dennoch gelingt, daraus etwas funktionierendes herzustellen.
aber (etwas naiv gefragt): acpi ist ja ein einsehbarer standard, dessen spezifikation ich mir ja herunterladen kann (sagt zumindest ein kurzer blick auf acpi.info). wo liegt der sinn darin, so etwas als hardwarehersteller zu fördern und gleichzeitig offenbar nur verbuggtes zeuch unter die leute zu bringen?!!!? gnaaaa :-/
thanx!
ich hoffe, ich habe das so richtig verstanden: die hardwarehersteller haben einen standard fehlerhaft implementiert und dass es MS quasi dennoch gelingt, daraus etwas funktionierendes herzustellen.
aber (etwas naiv gefragt): acpi ist ja ein einsehbarer standard, dessen spezifikation ich mir ja herunterladen kann (sagt zumindest ein kurzer blick auf acpi.info). wo liegt der sinn darin, so etwas als hardwarehersteller zu fördern und gleichzeitig offenbar nur verbuggtes zeuch unter die leute zu bringen?!!!? gnaaaa :-/
thanx!
"In den reichen Ländern hat die Freiheit gesiegt - mit all den schrecklichen Folgen, die das für die anderen mit sich bringt und noch bringen wird. Die Demokratie ist auf andere Epochen verschoben." (L. Canfora)
Unter Windows ist es ja IMO nicht M$, die trotz standardinkonformer ACPI Implementierung die Funktionen möglich machen, sondern eben die Hersteller selbst, mit der Software, die idR bei den Laptops beiliegt und auch unter Windows installiert werden muss, um alle Funktionen zu aktivieren. Installier mal ein ganz normales Windows XP auf Deinem Laptop und Du wirst schnell merken, dass damit auch nicht alles geht.....
Ich bin kein Experte bzgl. DSDT allerdings auch ein Linux-User der damit Probleme hatte. So wie ich das verstehe, steht in der DSDT eine Beschreibung der Hardware des Geräts. Für Windows schreibt der Hersteller, da er die HW genau kennt, seine WIndowstreiber entsprechend. Unter Linux gibts es halt _eine_ Implementierung für alle Geräte und das führt zwangsweise (da die Hersteller den Standard nicht 100% folgen) zu Problemen.
Du musst also diese Beschreibungstabelle für Dein Gerät mit einer korrigierten ersetzen. Dies kann man mit Hilfe von HOWTOs, Google, Foren etc auf eigene Faust versuchen aber auch mal auf http://acpi.sf.net/ im DSDT Repository nach einer passenden DSDT fürs eigene Laptop suchen. Dabei muss man allerdings aufpassen, dass man wirklch die richtige findet. Hersteller und Modell reichen da nicht. Die DSDT unterscheidet sich auch zB bei verschiedenem Hauptspeicher (RAM) Ausbau. Ich konnte gottseidank damals in diesem Repository gleich eine funktionierende DSDT für mein Laptop finden und dadurch die meisten Probleme beheben. Ein paar (zB ACPI S3 resume) gibt es aber nachwievor....
Ich bin kein Experte bzgl. DSDT allerdings auch ein Linux-User der damit Probleme hatte. So wie ich das verstehe, steht in der DSDT eine Beschreibung der Hardware des Geräts. Für Windows schreibt der Hersteller, da er die HW genau kennt, seine WIndowstreiber entsprechend. Unter Linux gibts es halt _eine_ Implementierung für alle Geräte und das führt zwangsweise (da die Hersteller den Standard nicht 100% folgen) zu Problemen.
Du musst also diese Beschreibungstabelle für Dein Gerät mit einer korrigierten ersetzen. Dies kann man mit Hilfe von HOWTOs, Google, Foren etc auf eigene Faust versuchen aber auch mal auf http://acpi.sf.net/ im DSDT Repository nach einer passenden DSDT fürs eigene Laptop suchen. Dabei muss man allerdings aufpassen, dass man wirklch die richtige findet. Hersteller und Modell reichen da nicht. Die DSDT unterscheidet sich auch zB bei verschiedenem Hauptspeicher (RAM) Ausbau. Ich konnte gottseidank damals in diesem Repository gleich eine funktionierende DSDT für mein Laptop finden und dadurch die meisten Probleme beheben. Ein paar (zB ACPI S3 resume) gibt es aber nachwievor....
Das bezieht sich nicht auf den einen Akku. SmartBattery ist eine intelligente Batterie.DaBomb hat geschrieben:Hi,
bezieht sich die Definition von Smartbattery-Technologie auf Akkus mit 2200 mAh?
Oder wie ist das genau zu verstehen?
Ich habe mich bisher mehr auf die DSDT fixiert, jedoch ohne Resultat.
Von daher finde ich Deinen Ansatz sehr interessant.
Zur DSDT: bei den Acer-Modellen Travelmate 4000 und Extensa 3000 (beide baugleich) ist die DSDT vollkommen in Ordnung. Daher braucht man sich um die nicht mehr zu kümmern.
Hab zum Auslesen des Batteriestatus was gefunden:
http://www.squirrel.nl/people/jvromans/ ... ttery.html
Hab ich selber noch nicht ausprobiert, aber immerhin wird an einer Lösung gearbeitet.
EDIT:
Hab gerade einen Schnellversuch unter SuSE 9.2 gestartet: ES KLAPPT!
Den SBS ACPI Driver gibts hier:
http://shayol.bartol.udel.edu/~rhdt/dow ... 114.tar.gz
Infos:
http://sourceforge.net/mailarchive/foru ... um_id=6102
Das Smartbattery-Tool:
http://www.poupinou.org/acpi/smartbatt/
Dort gibt es auch den Kernel-Patch damit der SBS ACPI Driver beim Laden keinen Fehler ausspuckt.
Vorgehensweise:
- Kernel patchen und neu übersetzen
- SBS ACPI Driver übersetzen und als Modul laden
Das wars auch schon. Danach ist unter /proc/acpi/battery/ auch endlich ein Eintrag. Der Batteriestatus lässt sich auslesen.
EDIT 2:
Werd demnächst das ganze unter Ubuntu und Knoppix ausprobieren, mit Debian dürfte alles genauso laufen.
Hi,
habe davon auch schon gelesen und getestet.
Ich habe auf meinem Notebook neben Mepis z. Zt auch SuSE 9.2 mit Kernel 2.6.8 und 2.6.10
Bei beiden hat es nicht geklappt das i2c-acpi-ec Modul zu laden.
Bei 2.6.8 kommt ne Meldung, dass das Modul nicht von SuSE unterstützt wird, bei 2.6.10 kommt, dass keine Temperaturanzeige vorhanden ist, warum auch immer.
Könntest Du mal näher auf Deins eingehen?
Welchen Kernel hast Du?
Ich habe in der Kernel-Konfig also /usr/src/linux/.konfig BATTERY und AC auf n gestellt, brachte leider nix.
Oder seh ich jetzt den Wald vor lauter Bäumen nimmer?
habe davon auch schon gelesen und getestet.
Ich habe auf meinem Notebook neben Mepis z. Zt auch SuSE 9.2 mit Kernel 2.6.8 und 2.6.10
Bei beiden hat es nicht geklappt das i2c-acpi-ec Modul zu laden.
Bei 2.6.8 kommt ne Meldung, dass das Modul nicht von SuSE unterstützt wird, bei 2.6.10 kommt, dass keine Temperaturanzeige vorhanden ist, warum auch immer.
Könntest Du mal näher auf Deins eingehen?
Welchen Kernel hast Du?
Ich habe in der Kernel-Konfig also /usr/src/linux/.konfig BATTERY und AC auf n gestellt, brachte leider nix.
Oder seh ich jetzt den Wald vor lauter Bäumen nimmer?
Ich hab den SuSE eigenen Kernel genommen, den ACPI-EC Patch eingespielt (wird nur eine Datei verändert) und ansonsten alles so belassen. Danach neu kompiliert. Per Hand hab ich dann das Battery-Modul entladen (rmmod battery) und die beiden Modules geladen (i2c-apci-ec und acpi-sbs). Jetzt war /proc/acpi/battery nicht mehr leer. Der Batteriestatus kann ausgelesen werden. Fehlermeldungen dass das Modul nicht unterstützt wird, hab ich keine bekommen.DaBomb hat geschrieben:Hi,
habe davon auch schon gelesen und getestet.
Ich habe auf meinem Notebook neben Mepis z. Zt auch SuSE 9.2 mit Kernel 2.6.8 und 2.6.10
Bei beiden hat es nicht geklappt das i2c-acpi-ec Modul zu laden.
Bei 2.6.8 kommt ne Meldung, dass das Modul nicht von SuSE unterstützt wird, bei 2.6.10 kommt, dass keine Temperaturanzeige vorhanden ist, warum auch immer.
Könntest Du mal näher auf Deins eingehen?
Welchen Kernel hast Du?
Ich habe in der Kernel-Konfig also /usr/src/linux/.konfig BATTERY und AC auf n gestellt, brachte leider nix.
Oder seh ich jetzt den Wald vor lauter Bäumen nimmer?
Ich teste jetzt aber nicht mehr mit SuSE weiter, ich bin grad dabei alles auf Gentoo umzustellen.
Ok, vielleicht scheitert es bei mir an einer Kleinigkeit:
Kernel unter SusE: 2.6.8-24.10-default
Als ACPI-EC Patch hast Du welchen genommen? Den acpi-ec-2.6.10.diff oder?
Den habe ich so gepatched:
acer:/usr/src/linux # patch -p1 < /usr/src/linux/smartbatt/acpi-ec-2.6.10.diff
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 135 (offset -2 lines).
Hunk #2 succeeded at 185 (offset -2 lines).
Hunk #3 succeeded at 237 (offset -2 lines).
Ging ja auch scheinbar durch.
Danach habe ich den Treiber in dem Paket geholt:
acpi_sbs-20040114
und ich habe auch den probiert
acpi_sbs-20050116
Bei beiden ging´s mit "make" und "make install" sauber durch.
Jedoch habe ich bei beiden wenn ich (Battery ist nicht geladen!)
modprobe i2c-acpi-ec
eintippe, die Fehlermeldung
FATAL: Error inserting i2c_acpi_ec (/lib/modules/2.6.8-24.10-default/i2c/i2c-acpi-ec.ko): Unknown symbol in module, or unknown parameter (see dmesg)
dmesg sagt:
module i2c_acpi_ec unsupported by SUSE/Novell, tainting kernel.
i2c_acpi_ec: Unknown symbol acpi_ec_write
i2c_acpi_ec: Unknown symbol acpi_ec_read
Jetzt weis ich gerade nicht mehr weiter.
Welchen ACPI-EC-Patch hast Du eingespielt und welches Treibermodul hast Du genommen?
Danke schonmal.
Kernel unter SusE: 2.6.8-24.10-default
Als ACPI-EC Patch hast Du welchen genommen? Den acpi-ec-2.6.10.diff oder?
Den habe ich so gepatched:
acer:/usr/src/linux # patch -p1 < /usr/src/linux/smartbatt/acpi-ec-2.6.10.diff
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 135 (offset -2 lines).
Hunk #2 succeeded at 185 (offset -2 lines).
Hunk #3 succeeded at 237 (offset -2 lines).
Ging ja auch scheinbar durch.
Danach habe ich den Treiber in dem Paket geholt:
acpi_sbs-20040114
und ich habe auch den probiert
acpi_sbs-20050116
Bei beiden ging´s mit "make" und "make install" sauber durch.
Jedoch habe ich bei beiden wenn ich (Battery ist nicht geladen!)
modprobe i2c-acpi-ec
eintippe, die Fehlermeldung
FATAL: Error inserting i2c_acpi_ec (/lib/modules/2.6.8-24.10-default/i2c/i2c-acpi-ec.ko): Unknown symbol in module, or unknown parameter (see dmesg)
dmesg sagt:
module i2c_acpi_ec unsupported by SUSE/Novell, tainting kernel.
i2c_acpi_ec: Unknown symbol acpi_ec_write
i2c_acpi_ec: Unknown symbol acpi_ec_read
Jetzt weis ich gerade nicht mehr weiter.
Welchen ACPI-EC-Patch hast Du eingespielt und welches Treibermodul hast Du genommen?
Danke schonmal.
Das stimmt, kpowersave hat anscheinend Probleme. Allerding hab ich mich damit nicht weiter beschäftigt, ich hab SuSE nicht mehr drauf, bin grad am Gentoo installieren.DaBomb hat geschrieben:Eine Frage habe ich.
Wird die Batterieanzeige bei mir mit kpowersave, bzw. klaptop ausgelesen?
Bei 9.2 rauch kpowersave nach dem Start gleich ab. ??!?!?
Fällt dir dazu was ein?
wacpi kann die Batterie aulsesen, hat allerdings keine Batterieanzeige in der Kontrollleiste.
wie hast Du das gelöst?
So, um das lange Werk gut zu machen:
Hier mit neu gepflegter Anleitung zum Erfolg:
http://www.flashlightz-forum.de/post-10845.html#10845
Hier mit neu gepflegter Anleitung zum Erfolg:
http://www.flashlightz-forum.de/post-10845.html#10845
Hallo Leute, .... hätte eine einfachere Lösung
Acer Travelmate 661 LCI
Weiss ja nicht ob das Modell abhängig ist aber ich hab den Batterystatus-Fehler dadurch gelöst, in dem ich den ACPI-Patch von http://acpi.sourceforge.net/ im Kernel eingabut habe.
Nur so gepatcht wie angegeben war:
Patch the kernel
$ cd <path to unpacked linux sources> (e.g. /usr/src/linux)
$ bunzip2 -c <path to acpi-patch>/acpi-<version>.diff.bz2 | patch -p1
und danach normal kompiliert. Bei den Punkt General Setup - > ACPI Support musst natürlich [Y] stehen. Support fix im Kernel einbiden und die anderen Sachen als Modul (battery, fan, ...).
Das wars schon. Nun wäre ACPI Unterstützung auf dem neusten Stand (der Kernel hinkt da anscheinend immer hinter her).
Nur noch im Gnome-Panel die Statusanzeige für Batterieanzeige hinzufügen, das wars (bei mir)
HABE FERTIG
Grüße
Markus
Weiss ja nicht ob das Modell abhängig ist aber ich hab den Batterystatus-Fehler dadurch gelöst, in dem ich den ACPI-Patch von http://acpi.sourceforge.net/ im Kernel eingabut habe.
Nur so gepatcht wie angegeben war:
Patch the kernel
$ cd <path to unpacked linux sources> (e.g. /usr/src/linux)
$ bunzip2 -c <path to acpi-patch>/acpi-<version>.diff.bz2 | patch -p1
und danach normal kompiliert. Bei den Punkt General Setup - > ACPI Support musst natürlich [Y] stehen. Support fix im Kernel einbiden und die anderen Sachen als Modul (battery, fan, ...).
Das wars schon. Nun wäre ACPI Unterstützung auf dem neusten Stand (der Kernel hinkt da anscheinend immer hinter her).
Nur noch im Gnome-Panel die Statusanzeige für Batterieanzeige hinzufügen, das wars (bei mir)
HABE FERTIG
Grüße
Markus
Re: Hallo Leute, .... hätte eine einfachere Lösung
Der ACPI-Patch reicht in dem Fall nicht, es liegt beim TM4000 an der Batterie, die wird nicht wie üblich ausgelesen, sondern per SMBus. Und die Unterstützung dazu fehlt im Kernel noch.mafrae hat geschrieben:Acer Travelmate 661 LCI
Weiss ja nicht ob das Modell abhängig ist aber ich hab den Batterystatus-Fehler dadurch gelöst, in dem ich den ACPI-Patch von http://acpi.sourceforge.net/ im Kernel eingabut habe.
Nur so gepatcht wie angegeben war:
Patch the kernel
$ cd <path to unpacked linux sources> (e.g. /usr/src/linux)
$ bunzip2 -c <path to acpi-patch>/acpi-<version>.diff.bz2 | patch -p1
und danach normal kompiliert. Bei den Punkt General Setup - > ACPI Support musst natürlich [Y] stehen. Support fix im Kernel einbiden und die anderen Sachen als Modul (battery, fan, ...).
Das wars schon. Nun wäre ACPI Unterstützung auf dem neusten Stand (der Kernel hinkt da anscheinend immer hinter her).
Nur noch im Gnome-Panel die Statusanzeige für Batterieanzeige hinzufügen, das wars (bei mir)
HABE FERTIG
Grüße
Markus
Hi, ist kein Problem.
Tutorial dafür gibt es hier:
Ausser Scripte, WLAN Tutorials für Linux, einer Linksammlung findet Ihr seit neuesten das Tutorial von mir.
Ihr könnt dieses Tutorial unter http://www.sligger.de --> Tutorials --> Linux
finden.
Tutorial dafür gibt es hier:
Ausser Scripte, WLAN Tutorials für Linux, einer Linksammlung findet Ihr seit neuesten das Tutorial von mir.
Ihr könnt dieses Tutorial unter http://www.sligger.de --> Tutorials --> Linux
finden.
hi, würde das thema nochmal gerne aufleben lassen
ich hab auch diesen sbs driver installiert. kernel patch draugespielt, neu übersetzt, i2c aktiviert und danach gebootet und den treiber kompiliert und installiert. auch beim modproben von beiden modulen erscheint kein fehler, auch nicht bei dmesg.
trotzdem bleibt mein /proc/acpi/battery einfach leer!
ich hab auch ac und battery ausm kernel rausgenommen, hat nicht geholfen.
vielleicht weiss ja einer von euch weiter, bin echt am verzweifeln!
ich hab auch diesen sbs driver installiert. kernel patch draugespielt, neu übersetzt, i2c aktiviert und danach gebootet und den treiber kompiliert und installiert. auch beim modproben von beiden modulen erscheint kein fehler, auch nicht bei dmesg.
trotzdem bleibt mein /proc/acpi/battery einfach leer!
ich hab auch ac und battery ausm kernel rausgenommen, hat nicht geholfen.
vielleicht weiss ja einer von euch weiter, bin echt am verzweifeln!
Hallo,
ich wollte auch mal probieren, den Batteriestand von meinem Acer Extensa 3001 auslesbar zu machen. Allerdings bin ich schon beim compilieren des iasl compilers gescheitert. Wenn ich make eingebe kommen folgende Fehler:
root@knife:/home/temp/acpica-unix-20050513/compiler# make
cc -Wall -O2 -Wstrict-prototypes -D_LINUX -D_ACPI_ASL_COMPILER -I../include -c -o aslcompilerlex.o aslcompilerlex.c
aslcompiler.l: In function `comment':
aslcompiler.l:847: error: `yytext_ptr' undeclared (first use in this function)
aslcompiler.l:847: error: (Each undeclared identifier is reported only once
aslcompiler.l:847: error: for each function it appears in.)
make: *** [aslcompilerlex.o] Error 1
Was kann da los sein? Kann jemand helfen?
mfg
kent
ich wollte auch mal probieren, den Batteriestand von meinem Acer Extensa 3001 auslesbar zu machen. Allerdings bin ich schon beim compilieren des iasl compilers gescheitert. Wenn ich make eingebe kommen folgende Fehler:
root@knife:/home/temp/acpica-unix-20050513/compiler# make
cc -Wall -O2 -Wstrict-prototypes -D_LINUX -D_ACPI_ASL_COMPILER -I../include -c -o aslcompilerlex.o aslcompilerlex.c
aslcompiler.l: In function `comment':
aslcompiler.l:847: error: `yytext_ptr' undeclared (first use in this function)
aslcompiler.l:847: error: (Each undeclared identifier is reported only once
aslcompiler.l:847: error: for each function it appears in.)
make: *** [aslcompilerlex.o] Error 1
Was kann da los sein? Kann jemand helfen?
mfg
kent