Hallo Liste, wie ich schon lesen konnte, bin ich mit meinem folgenden Problem offensichtlich nicht allein. Allerdings frage ich mich, ob es noch lohnt, weiter Zeit zu verschwenden. Für jemanden soll ich einen ACER Aspire 1355LC mit Linux bestücken. Mich überraschen hier gleich mehrere Dinge. - die Installation klappt nur mit abgeschaltetem ACPI. Sonst hängt das Ding bereits bei der Aktivierung des PCMCIA-Controllers oder bei der Netzwerkkarte; je nach Laune. - Nach der Installation ist wegen abgeschaltetem ACPI (Kernelparameter acpi=off) keine Anzeige für den Ladezustand oder Restkapazität möglich; beim Shutdown startet die Kiste durch und bootet neu bei eingestecktem Netzteil. Diesen Effekt hat Werner Roth auch unter 9.0 auf seiner Homepage beschrieben. Dies liegt dann offensichtlich an mangelnder APM-Konformität. - SuSE hat so neue schöne Dinge wie einen coldplugmanager erfunden, der ewige Zeit braucht und wenn nichts geändert wird am Gerät auch überflüssig ist. Das lässt sich wiederum mit dem Parameter NOCOLDPLUG=1 abschalten; allerdings wird dann das Modul für die NIC nicht geladen, das vorher noch funktionierende Netzwerk kann nicht gestartet werden. Außerdem lädt X nicht mehr, da gleiches wohl mit dem X-Server schief geht. Ich hatte noch keine Zeit, dem näher auf den Grund zu gehen. Alles in allem hat es -leider nicht reproduzierbar- einmal geklappt, den Laptop _mit_ ACPI zu starten. und zwar nur mit den Modulen AC, BATTERY und BUTTON. Dieser Zustand würde der Anforderung gerecht werden. Ladekontrolle, sauberes Abschalten (sogar durch einfachsten Druck auf den [Netz]schalter) STR oder STD nicht notwendig. Aber leider ist dieser Zustand mit allen im Netz recherchierten Parametern für ACPI nicht reproduzierbar. Ein Ausweichen auf 9.0 geht nicht, da APM ebenfalls mangelhaft umgesetzt ist. Einzig KNOPPIX 3.[4] oder 3.3 mit dem 2.6.1 Testkernel aus der c't läuft problemlos und mit ACPI. Aber einen testkernel auf dem Gerät für Fremde zu installieren widerstrebt mir, zumal ich eine Doku brauche. SuSE wäre optimal, wenn nur die gleiche Sorgfalt wie früher zu merken wäre mit vielleicht mehreren optimierten Kerneln und besseren Tests der neu eingeführten Features. Nun ist die Überlegung, lohnt es sich, einen Kernel zu bauen, wenn ja mit welchen configs u.a. für ACPI? Oder habt ihr andere Erfahrungen / Ideen? Danke. Axel.
Hallo, ich habe einen Aspire 1357LM mit Suse 9.0 Kernel 2.5.617 Am Donnerstag, 3. Juni 2004 10:10 schrieb Axel Ernst:
wie ich schon lesen konnte, bin ich mit meinem folgenden Problem offensichtlich nicht allein. Allerdings frage ich mich, ob es noch lohnt, weiter Zeit zu verschwenden. Für jemanden soll ich einen ACER Aspire 1355LC mit Linux bestücken. Mich überraschen hier gleich mehrere Dinge.
- die Installation klappt nur mit abgeschaltetem ACPI. Sonst hängt das Ding bereits bei der Aktivierung des PCMCIA-Controllers oder bei der Netzwerkkarte; je nach Laune.
Soweit ich weiß haben alle 1350er das gleich Bios, das bei mir kein APM unterstützt keine brauchbaren PSTs enthält und dessen DSDT Macken hat, ich sie aber nicht reparieren konnte. Modem und WLan habe ich noch nicht versucht. Touchpad geht mit Synaptics-Treiber für XFree86 Raden mobility 9200 geht mit ATI-Treiber für XF86
- Nach der Installation ist wegen abgeschaltetem ACPI (Kernelparameter acpi=off) keine Anzeige für den Ladezustand oder Restkapazität möglich;
Das braucht ACPI, APM geht wohl nicht mehr.
beim Shutdown startet die Kiste durch und bootet neu bei eingestecktem Netzteil. Diesen Effekt hat Werner Roth auch unter 9.0 auf seiner Homepage beschrieben. Dies liegt dann offensichtlich an mangelnder APM-Konformität. Steht auch in der Suse-Datenbank. Funktiniert mit ACPI :-)
Aber ACPI geht nur OHNE PCMCIA. Bei Suse 9.0 (Kernel 2.4) reicht es den PCMCIA-Modul im runlevel editor abzustellen. Mit dem neuen (Kernel 2.6..) hot-plugging werden offensichtlich dort viele Module geladen, die wenn man sie nicht will über die Blacklist entfernt werden müssen. Ich habe etliche agp- und PCMCIA- Module blacklisted und jetzt gehts. Da ich keine PCMCIA Karten habe, stört mich das nicht. agp wird durch modprobe geladen.
Ein Ausweichen auf 9.0 geht nicht, da APM ebenfalls mangelhaft umgesetzt ist. Einzig KNOPPIX 3.[4] oder 3.3 mit dem 2.6.1 Testkernel aus der c't läuft problemlos und mit ACPI. Aber einen testkernel auf dem Gerät für Fremde zu installieren widerstrebt mir, zumal ich eine Doku brauche. SuSE wäre optimal, wenn nur die gleiche Sorgfalt wie früher zu merken wäre mit vielleicht mehreren optimierten Kerneln und besseren Tests der neu eingeführten Features.
Nun ist die Überlegung, lohnt es sich, einen Kernel zu bauen, wenn ja mit welchen configs u.a. für ACPI?
Ab kernel 2.6.6 sollte wenigstens das Powernow funktionieren, aber so weit bin ich noch nicht. Es bleibt zu kären wieso PCMCIA und ACPI sich nicht vertragen.
Oder habt ihr andere Erfahrungen / Ideen?
Danke. Axel.
Grüße FUB
FUB schrieb:
Soweit ich weiß haben alle 1350er das gleich Bios, das bei mir kein APM unterstützt keine brauchbaren PSTs enthält und dessen DSDT Macken hat, ich sie aber nicht reparieren konnte. Modem und WLan habe ich noch nicht versucht. Touchpad geht mit Synaptics-Treiber für XFree86 Raden mobility 9200 geht mit ATI-Treiber für XF86 ACK. Der Rest lief recht problemlos Bis auf die Tatsache, dass beim Herunterfahren der Bildschirn entweder schwarz blieb oder nur Mist anzeigte, jedenfalls weder terminal-meldungen noch splash. ich habe hier auch noch keine brauchbare VGA= option gefunden.
acpi=off) keine Anzeige für den Ladezustand oder Restkapazität möglich;
Das braucht ACPI, APM geht wohl nicht mehr. Leider.
beim Shutdown startet die Kiste durch und bootet neu bei eingestecktem
Steht auch in der Suse-Datenbank. Funktiniert mit ACPI :-) Was (ACPI) leider so eben nicht geht, zumindest bislang.
Aber ACPI geht nur OHNE PCMCIA. Bei Suse 9.0 (Kernel 2.4) reicht es den PCMCIA-Modul im runlevel editor abzustellen. Mit dem neuen (Kernel 2.6..) hot-plugging werden offensichtlich dort viele Module geladen, die wenn man sie nicht will über die Blacklist entfernt werden müssen. Ich habe etliche agp- und PCMCIA- Module blacklisted und jetzt gehts. Da ich keine PCMCIA Karten habe, stört mich das nicht. agp wird durch modprobe geladen. OK, das wäre noch mal ein Ansatzpunkt. Wobei dann als Resultat auch wieder nur in Frage kommt, dass SuSE zuviel gebastelt hat. Bisher lud man nur das notwendige pcmcia modul für den controller und der cardmgr lud die Kartenspezifischen Module beim hotplug. Was wird da denn nun schon im Vorwege versaut?
Soll heißen ich werde mal pcmcia abschalten und dann testen. Hat jemand einen Kernel-Parameter zur Hand? Aber da bleibt die Frage offen, warum z.b. das Ding stehen bleibt beim init der NIC (PCMCIA kommt erst später dran)
Ab kernel 2.6.6 sollte wenigstens das Powernow funktionieren, aber so weit bin ich noch nicht. Es bleibt zu kären wieso PCMCIA und ACPI sich nicht vertragen. ACK. Allerdings habe ich nach kernelupdate (SuSE) im Log einige mich verdutzende Meldungen gefunden. Powernow meldete eine CPU mit minfreq irgendwas bei 1000 Mhz und max ~2600 Mhz. Das kann so nicht richtig sein, der XP-Mobile läuft sicher mit weniger als 1000 im Minimum und betimmt keine 2600 real? [Fix me] Grüße FUB
Gruß Axel.
FUB schrieb:
Soweit ich weiß haben alle 1350er das gleich Bios, das bei mir kein APM unterstützt keine brauchbaren PSTs enthält und dessen DSDT Macken hat, ich sie aber nicht reparieren konnte. Modem und WLan habe ich noch nicht versucht. Touchpad geht mit Synaptics-Treiber für XFree86 Raden mobility 9200 geht mit ATI-Treiber für XF86
ACK. Der Rest lief recht problemlos Bis auf die Tatsache, dass beim Herunterfahren der Bildschirn entweder schwarz blieb oder nur Mist anzeigte, jedenfalls weder terminal-meldungen noch splash. ich habe hier auch noch keine brauchbare VGA= option gefunden. Schwarzer Bildschirm nach standby (Suspend to Ram) ist sehr weit verbreitet > 50%. Deshalb auch per default ausgeschaltet. Man kann hier nur auf ordentliche suspend/resume Funktionalität in neuen agp Treibern hoffen (so weit ich weiss sind diese vom ein oder anderen Hersteller angekündigt).
acpi=off) keine Anzeige für den Ladezustand oder Restkapazität möglich; Das braucht ACPI, APM geht wohl nicht mehr. Leider.
beim Shutdown startet die Kiste durch und bootet neu bei eingestecktem Steht auch in der Suse-Datenbank. Funktiniert mit ACPI :-)
Was (ACPI) leider so eben nicht geht, zumindest bislang.
Aber ACPI geht nur OHNE PCMCIA. Bei Suse 9.0 (Kernel 2.4) reicht es den PCMCIA-Modul im runlevel editor abzustellen. Mit dem neuen (Kernel 2.6..) hot-plugging werden offensichtlich dort viele Module geladen, die wenn man sie nicht will über die Blacklist entfernt werden müssen. Ich habe etliche agp- und PCMCIA- Module blacklisted und jetzt gehts. Da ich keine PCMCIA Karten habe, stört mich das nicht. agp wird durch modprobe geladen.
OK, das wäre noch mal ein Ansatzpunkt. Wobei dann als Resultat auch wieder nur in Frage kommt, dass SuSE zuviel gebastelt hat. Bisher lud man nur das notwendige pcmcia modul für den controller und der cardmgr lud die Kartenspezifischen Module beim hotplug. Was wird da denn nun schon im Vorwege versaut?
Soll heißen ich werde mal pcmcia abschalten und dann testen. Hat jemand einen Kernel-Parameter zur Hand? Aber da bleibt die Frage offen, warum z.b. das Ding stehen bleibt beim init der NIC (PCMCIA kommt erst später dran) PCMCIA und NIC geht nicht, ACPI booten bleibt hängen? Da tippe ich sofort auf falsche Interrupt Zuweisungen durch ACPI/APIC. An dieser Stelle solltest Du auf jeden Fall folgende boot-Parameter ausprobieren: noapic
Hallo Ernst, kommentiere mal ein paar Stellen Deiner mail zu denen ich konkret was sagen kann... Axel Ernst wrote: pci=noacpi acpi_irq_balance Am besten in genannter Reihenfolge. Eventuell auch in Kombination Vergleiche /proc/interrupts. Vielleicht bootest Du auch erstmal niedrigere Runlevel (einfach die Zahl als bootparameter mitgeben). Dann kannst Du per Hand Module hinterladen und schauen wo/ob die Kiste einfriert.
Ab kernel 2.6.6 sollte wenigstens das Powernow funktionieren, aber so weit bin ich noch nicht.
Powernow funktioniert 100%ig schon vor SUSE 9.1
Es bleibt zu kären wieso PCMCIA und ACPI sich nicht vertragen. Ich tippe falsche Interrupts...
ACK. Allerdings habe ich nach kernelupdate (SuSE) im Log einige mich verdutzende Meldungen gefunden. Powernow meldete eine CPU mit minfreq irgendwas bei 1000 Mhz und max ~2600 Mhz. Das kann so nicht richtig sein, der XP-Mobile läuft sicher mit weniger als 1000 im Minimum und betimmt keine 2600 real? [Fix me]
Vielleicht werden hier falsche Frequenz/Volt Paar Werte vom BIOS exportiert? Das höre ich allerdings zum ersten mal... Kannst Du mir vielleicht mal (nur an mich) /sys/devices/system/cpu/cpu0/cpufreq/* (powernow-k7 Modul muss geladen sein). und /proc/cpuinfo schicken? Danke, Thomas
Hallo, danke für die Teilnahme. noch ein paar Anmerkungen: Thomas Renninger schrieb:
Schwarzer Bildschirm nach standby (Suspend to Ram) ist sehr weit verbreitet > 50%. Deshalb auch per default ausgeschaltet. Man kann hier nur auf ordentliche suspend/resume Funktionalität in neuen agp Treibern hoffen (so weit ich weiss sind diese vom ein oder anderen Hersteller angekündigt). Dieses Gerät hat noch keinen Standby gesehen. Soll heißen, man bootet z.B. mit VGA = 791. Splash, und native Meldungen ok, X startet. ALT + F[x] bringt z.b. keinen TTY sondern nur schwarzen Bildschirm. Ärgerlich aber nicht wichtig, weil der zukünftige Anwender wird eh' nie auf TTY arbeiten. Aber nach Abmeldung aus X (Rechner soll runterfahren), gibt es ebenfalls nur schwarzen Bildschirm oder völlig Farbverändende streifen auf dem LCD. Ich vermute, dass zwischen den nicht vorhandenen TTY und dem Schwarz-Schirmproblem ein Zusammenhang besteht, da beim Runterfahren ja auf einen TTY geschaltet wird, um entweder splash oder native meldungen auszugeben.[Fix me]
PCMCIA und NIC geht nicht, ACPI booten bleibt hängen? Da tippe ich sofort auf falsche Interrupt Zuweisungen durch ACPI/APIC. An dieser Stelle solltest Du auf jeden Fall folgende boot-Parameter ausprobieren: noapic pci=noacpi acpi_irq_balance
Alle Optionen wie o.g. schon probiert, keine Änderung am Verhalten.
Am besten in genannter Reihenfolge. Eventuell auch in Kombination Vergleiche /proc/interrupts. Vielleicht bootest Du auch erstmal niedrigere Runlevel (einfach die Zahl als bootparameter mitgeben). Dann kannst Du per Hand Module hinterladen und schauen wo/ob die Kiste einfriert. Das hat zumindest auch schon einmal geklappt. Hatte L2 gebootet und dann X gestartet. Da war ich noch auf der Fehlersuche wegen dem o.g. Schwarz-Prob. witzigerweise sind in diesem Fall alle Komponenten ok gewesen.(außer eh' nicht geladene NIC und PCMCIA) auch die TTY waren da, beim Runterfahren anständige Meldungen im Native Mode.
Vielleicht werden hier falsche Frequenz/Volt Paar Werte vom BIOS exportiert?
Das höre ich allerdings zum ersten mal... Kannst Du mir vielleicht mal (nur an mich) /sys/devices/system/cpu/cpu0/cpufreq/* (powernow-k7 Modul muss geladen sein). und /proc/cpuinfo schicken?
Gern, wird allerdings erst heut Abend was.
Danke,
Thomas
Gruß Axel.
Hallo, nachdem ich gestern fast berichten wollte es läuft, kam heute morgen die negative Überraschung. Ohne Änderung der Parameter für ACPI an die ich mich herangetastet hatte, startet das NB von allen (5) Versuchen nicht einmal. Nun wird allerdings der Aufhänger etwas Klarer: coldplug - entweder beim scanning pci oder (in einem Fall) beim usb. Das verstehe ich nun nicht mehr. :-( ca. 10 h vorher hatte ich per Zufall in dem dmesg noch einen Hinweis des Kernels auf pcipirqmask gefunden; dieser Parameter brachte in Kombination mit weiteren ACPIparametern das NB in die Richtung nutzbar. Bei allen Reboots lief das Ding tadellos hoch. Langsam härtet sich der Verdacht, dass SuSE-Kernel und ACER's eigenwillige IRQ-Verteilung sich nicht vertragen. Leider gibt es auch keine Möglichkeit, hierauf im BIOS Einfluss zu nehmen. Als ich noch auf der Suche nach den Parametern zum Booten war, beschwerte sich der Kernel u.a. über völlig chaotische IRQ Zuweisungen und eine in der initrd nicht definierte DSDT table. :-( ACPI abzuschalten ist eine Möglichkeit, mit der _ich_ vielleicht leben könnte, nicht aber der zukünftige Nutzer, der schon fragt wann's denn fertig ist. :-( Gibt's noch Ideen hierzu? Gruß Axel.
On Thu, Jun 03, Axel Ernst wrote:
- SuSE hat so neue schöne Dinge wie einen coldplugmanager erfunden, der ewige Zeit braucht und wenn nichts geändert wird am Gerät auch überflüssig ist. Das lässt sich wiederum mit dem Parameter NOCOLDPLUG=1 abschalten; allerdings wird dann das Modul für die NIC nicht geladen, das vorher noch funktionierende Netzwerk kann nicht gestartet werden. Außerdem lädt X nicht mehr, da gleiches wohl mit dem X-Server schief geht. Ich hatte noch keine Zeit, dem näher auf den Grund zu gehen.
Aha, überflüssig. Geht blos nix mehr danach ... ;) Wie wäre es mit NOCOLDPLUG=1 weglassen? Damit "scanning input" nicht so lange braucht, bitte Zeile 104 (in der der input.agent aufgerufen wird) in /etc/hotplug/input.rc ändern in /sbin/hotplug input < /dev/null > /dev/null 2>&1 & Bis zum nächsten hotplug YOUpdate wird es noch einige Tage dauern. -- ciao, christian
Am Donnerstag, 3. Juni 2004 17:31 schrieb Christian Zoz:
On Thu, Jun 03, Axel Ernst wrote:
- SuSE hat so neue schöne Dinge wie einen coldplugmanager erfunden, der ewige Zeit braucht und wenn nichts geändert wird am Gerät auch überflüssig ist. Das lässt sich wiederum mit dem Parameter NOCOLDPLUG=1 abschalten; allerdings wird dann das Modul für die NIC nicht geladen, das vorher noch funktionierende Netzwerk kann nicht gestartet werden. Außerdem lädt X nicht mehr, da gleiches wohl mit dem X-Server schief geht. Ich hatte noch keine Zeit, dem näher auf den Grund zu gehen.
Aha, überflüssig. Geht blos nix mehr danach ... ;) Wie wäre es mit NOCOLDPLUG=1 weglassen?
Hehe, naja, wenn denn etwas was schon mal da war und nicht nochmal getestet werden soll plötzlich nicht mehr funzt nur weil es nicht getestet wird ... *grübel* oder schmeißen wir jede config nach Neustart über'n Haufen? ;-) Das Abschalten sollte ja nur einer Beschleunigung des Neustarts dienen, da eben keine neue HW dazukommt.
Damit "scanning input" nicht so lange braucht, bitte Zeile 104 (in der der input.agent aufgerufen wird) in /etc/hotplug/input.rc ändern in
/sbin/hotplug input < /dev/null > /dev/null 2>&1 &
Bis zum nächsten hotplug YOUpdate wird es noch einige Tage dauern.
Danke für die Info. ;-)
--
ciao, christian
Gruß Axel. -- den "Designed for XP" Aufkleber hab ich grad abgerissen. Steht wohl eher für "Nahe am Standard" (ist aber auch vorbei!)
Hallo nochmal zusammen, ich habe nun zwischenzeitlich folgendes unternommen: - Kernel mit fest integrierten ACPI Modulen und für AMD Prozessoren selbst gebaut - neue initrd erzeugt - coldplug abgeschaltet (Hardware wird manuell eingebunden, danke für den Hinweis in dieser Liste von Jesko Schneider bzgl. hwup) - Module für usb über boot.local laden Ergebnis: Das ACER läuft einigermaßen stabil, mit ACPI (Ladekontrolle, Lüftersteuerung...), sauberem Abschalten und erzwungenem Shutdown kurz vor Akku-Ende. STD/STR ist nicht notwendig und wird deswegen auch nicht aktiviert. Die Synaptics-Steuerung des Touchpads klappt auch. Verwundert hat mich, dass nach Neuübersetzung des Kernels auch alle externen Module wie die für synaptics, slmodem usw. neu übersetzt werden müssen (Kernel meckert über Modulversion missmatch.) War mein compiler hier zu neu? Mit welchem hat SuSE gearbeitet? Die Fn[] Tasten lassen sich fast alle mit dem acme Paket steuern, es gehen Lautstärke, Mute, Web. Nur bei der Email-Taste friert er noch ein. Die Helligkeitsregelung des ACER geht übrigens auch nur, wenn das OS mit eingeschaltetem ACPI läuft. Ansonsten keine Reaktion. Phänomen Akkubetrieb: Wenn powersaved aktiviert ist, geht die CPU-Last so hoch, dass die Maus nur noch am Stocken ist. :-( Reichweite des Akku: 40 min., vernünftiges Arbeiten ausgeschlossen. Hier habe ich in der /etc/powersave.conf das Programm beim ACPI-Ereignis other="" gesetzt. Erst dann funktioniert der Akkubetrieb mit annähernd 2 Stunden inkl. CD-Laufwerks-Betrieb für Installationsarbeiten. Ein Debug ergab, dass das Bios offensichtlich "leere" Ereignisse produziert, die laut Theorie wohl ignoriert werden sollten. Leider verbrät das Ignorieren die CPU :-( PCMCIA: Speicherbereiche aus /proc/ioports ermitteln und in die /etc/pcmcia/config.opts eintragen. Bei dem vorliegenden ACER werden hohe Speicherbereiche verwendet (IRQ 5), entgegen der Notiz in der Config, wo diese abgeschaltet werden. Also untere Bereiche ausschließen (abschalten) und die hohen Bereiche eintragen. Dann lässt sich rcpcmcia ohne Absturz starten. Ich muss nur noch die Module für Karten neu übersetzen. Warum eigentlich? Die VIA 3d-Treiber für KM400 Chipset habe ich noch nicht am laufen. ;-( Hier hakt es noch. Leider ist die VIA-Seite hier recht unübersichtlich. Und wegen des Zeitdrucks fehlt eben die Zeit, das durch zuarbeiten. Wer hierzu noch einen Hinweis hat? Alles in allem erinnert mich diese Arie an die ersten Installationen, die ich noch in der Konsole gemacht habe. :-( Schade, dass die Version so gepuscht wurde. Ich würde die Probleme leichter akzeptieren können, wenn der VIA-KM400-Chipset nicht schon über 10 Monate (mind.) auf dem Markt wäre (ältere ACER NB haben den auch schon) und auch von MB-Herstellern verbaut werden. Sicher spielt auch die Verarbeitung und die mehr oder weniger gelungene Programmierung des BIOS von ACER eine nicht unerhebliche Rolle, aber wenn ich mir die Unterschiede der Zustände anschaue: SuSE default-installation: unbenutzbar, instabil und nun zumindest mit allen Funktionen die notwendig sind um damit zu arbeiten. ;-) Die Zeit, die ich hier investiert habe, hatte ich eigentlich nicht und das war ich bislang von SuSE so nicht gewohnt. Die alten SuSE-Versionen machten hier einen durchdachteren Eindruck schon allein dadurch, dass verschiedene Kernel angeboten wurden. Ich weiß, hierüber haben sich schon andere ausgelassen, aber ich musste das nochmal loswerden. Übrigens: eine in 20 Minuten durchgeführte Mandrake 9.2 Installation inkl. ACPI-Funktionen lief auf Anhieb (gepatchter 2.4er Kernel). Allerdings ist die Version nicht mehr so frisch. Gruß Axel.
participants (4)
-
Axel Ernst -
Christian Zoz -
FUB -
Thomas Renninger