Kernel 2.6.24 mit ACPI plötzlich träge [gelöst]

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Kernel 2.6.24 mit ACPI plötzlich träge [gelöst]

Beitrag von Langly » 18.02.2008 17:40:18

Hallo,

ich habe seit dem Kernelrelease von 2.6.24 ein Problem, ein selbst kompiliertes Kernelimage auf meinem Notebook zu benutzen.
Ich kann den Kernel mit make-kpkg und den gleichen Optionen wie bei 2.6.23 bauen und installieren, aber nach dem Booten ist das ganze System unerklärlich langsam und träge. Die Symptome sind ein wenig schwer zu beschreiben, aber ein treffender Vergleich wäre, wenn man auf einem Pentium 1 mit 32 Mb ein aktuelles KDE installiert.
Der Wechsel der Arbeitsflächen dauert mit dem neuen Kernel mehrere Sekunden, wenn ich im Konqueror ein Verzeichnis mit einer Handvoll Dateien durchscrolle dauert es auch eine gute Sekunde, bis die Vorschau für die jeweiligen Files da ist, Programmstarts dauern ewig, das Kompilieren eines Kernelimages unter einem laufenden Linux-2.6.24 dauert gut fünfmal so lange wie üblich, und ich kann nicht einmal im Iceweasel die Forenansicht heruntersrcollen, ohne dass das Bild ständig hängt.

Nach einigem Herumprobieren bin ich dann darauf gestoßen, dass dieser Fehler nur auftritt, wenn ich die folgenden beiden Optionen aktiviert habe:

Code: Alles auswählen

Power Management Options
     *[ACPI]
          *[Deprected /proc/acpi files]
          *[Deprected power /proc/acpi folders]
Lasse ich die beiden als veraltert gekennzeichneten Punkte weg, läuft das System wieder 1A, nur leider ohne jegliches ACPI, was sich auf einem Notebook nicht sehr gut macht. Ich bin mir nicht ganz sicher, aber ersetzen kann ich diese Funktionen anscheinend nicht, denn obwohl ich die entsprechenden übrigen Kategorien zu ACPI fest einkompiliert habe wird es nicht mehr unterstützt, wenn ich die oben genannten Funktionen aus dem Kernel nehme. Ich denke das liegt wohl daran, dass ich hier ein Etch verwende, dessen Programme noch diese beiden Punkte verwenden und mit einer veränderten ACPI-Funktionalität in einem neuen Kernel nicht umgehen können.

Wäre toll, wenn dazu jemand ein paar Ratschläge liefern kann, ich bin nach mehreren Stunden Kernelbauen echt am Ende.
Zuletzt geändert von Langly am 29.02.2008 18:55:55, insgesamt 1-mal geändert.

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Re: Kernel 2.6.24 mit ACPI plötzlich träge

Beitrag von storm » 19.02.2008 00:10:13

Langly hat geschrieben: Ich bin mir nicht ganz sicher, aber ersetzen kann ich diese Funktionen anscheinend nicht, denn obwohl ich die entsprechenden übrigen Kategorien zu ACPI fest einkompiliert habe wird es nicht mehr unterstützt, wenn ich die oben genannten Funktionen aus dem Kernel nehme. Ich denke das liegt wohl daran, dass ich hier ein Etch verwende, dessen Programme noch diese beiden Punkte verwenden und mit einer veränderten ACPI-Funktionalität in einem neuen Kernel nicht umgehen können.
Das sieht eher nach einem grundlegenden Problem aus als nur fehlende Kernel-Funktionalität. Du möchtest zwar einen aktuellen Kernel und setzt etch ein, das zwar bequem gegenüber sid in Sachen updates ist, aber eben deswegen der Entwicklung beim kernel hinterläuft. Du könntest natürlich versuchen, die entsprechende Software mit moderneren Versionen zu ersetzen oder auch Versionen aus den backports zu nutzen. Das Problem bleibt aber mehr oder weniger bestehen. Was für Software ist das denn, die die alten Schnittstellen haben will? Gibts da vielleicht nicht die Möglichkeit eine andere, gleichwertige zu installieren?

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 19.02.2008 08:44:11

Hallo storm,

es geht vor allem um die in KDE mitgelieferten Pakete, die sich um Powermanagement kümmern, sprich klaptop, kpowersave usw., aber auch der powersaved (ich denke, die KDE-Pakete setzen darauf auf) hat beim Starten eine Fehlermeldung über die fehlende ACPI-Funktionalität gebracht.

Ehrlich gesagt habe ich keine Ahnung, ob es wirklich an der Software liegt, die genau diese Kernelfunktion nutzt, aber zumindest liegt diese Vermutung ja nahe. Andererseits sind die Funktionen ja nach wie vor nach im Kernel vorhanden, nur seit 2.6.24 nicht mehr benutzbar.

Ich sehe jetzt zwei Lösungsmöglichkeiten: Das Aktualisieren des Systems nach Lenny oder ich bleibe bei Kernel 2.6.23. Dramatisch ist das beides nicht, aber trotzdem würde mich interessieren, warum denn jetzt Funktionen, die seit Jahren funktionieren, plötzlich solche Probleme verursachen. Fast sieht mir das nämlich nach einem Bug aus, ich habe allerdings auch keinen Hinweis darauf gefunden, dass es tatsächlich so ist.

Wäre echt toll, wenn wir hier zu einer Erklärung dieses Verhaltes kommen. Mich interessiert jetzt wirklich, woran es hängt :)

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 19.02.2008 18:04:30

Ach, sorry. Ich hab das erst komplett mistverstanden. Die config-Optionen sind noch da, aber das System läuft damit nicht mehr rund.
Kuck mal als erstes, wer denn alles so auf die entsprechenden Dateien zugreift. Die 2 Kernel-Optionen beeinflussen ja nur das Vorhandensein der Dateien in /proc. Eventuell auch wie oft ein Daemon/Programm das tut.

Code: Alles auswählen

lsof | grep '/proc/acpi*'
Wenn das nicht viel ausgibt, beobachte den Befehl mal mit watch weiter. Dann kannst du auch mal nach den Interrupts kucken, ist da irgend etwas auffällig, zB abnormal hohe Rate der Zähler.

Code: Alles auswählen

cat /proc/interrupts
Wahlweise kannst du das auch wieder mit watch machen und mal etwas länger draufkucken. Normal sollten da die timer, der Interrupts für die Grafik und andere IO-Geschichten mit _moderater_ Geschwindigkeit hochzählen. (Da gab's mal einen Bug, vielleicht hat der entsprechende Fix bei dir genau das Verkehrte bewirkt). Und im bootlog/syslog findet sich nichts auffälliges?

Als letztes, aber auf jeden Fall wirksames Mittel zur Aufklärung könntest du auch mal einen Kernel mit CONFIG_ACPI_DEBUG [1] bauen, das macht den Kernel etwas dicker und sicher auch langsamer, wobei letzteres bei dir eh unerheblich ist, da der ja schon langsam vor sich hintrottelt.

ciao, storm

[1] Power management options -> ACPI -> [ ] Debug Statements
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 20.02.2008 10:34:20

Danke für die Anregungen!

Im Syslog ist tatsächlich ein Eintrag, der mir aufgefallen ist:

Code: Alles auswählen

Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
sd ist wohl ein Treiber für meine Festplatte, was sr macht, kann ich nicht sagen. Sinn machen würde es schon, ein Fehlverhalten dort zu suchen. Andererseits habe ich schon direkt als die Probleme auftraten die Durchsatzrate der Platte geprüft, ohne dass mir Fehler aufgefallen wären. Ich beobachte das mal weiter und schaue mal, ob die Meldung auch mit dem alten Kernel auftaucht.

Das einzige, was auf /proc/acpi zugreift, ist nicht sehr überraschend der acpid. Der Output von lsof sieht so aus:

Code: Alles auswählen

acpid     3018       root    3r      REG        0,3        0 4026531939 /proc/acpi/event
Auffällig ist dabei lediglich der hohe Node-Wert, aber ich habe ehrlich gesagt keine Ahnung,ob das etwas zu bedeuten hat oder nicht.

Auch an den Interrupts kann ich mit meinem beschränkten Wissen zu dem Thema nicht viel sagen, für mich sieht es alles normal aus: http://nopaste.debianforum.de/7512

Ich baue heute Nachmittag dann nochmal den Kernel mit der Debuggingoption. Vielleicht bringt das ja ein paar eindeutige Ergebnisse ans Tageslicht. Hoffentlich kannst du mit den Angaben mehr anfangen als ich.

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 20.02.2008 16:08:44

So, jetzt kam ich endlich dazu, etwas ausführlicher zu testen.

Das Problem mit dem Syslogeintrag hat sich wohl erledigt. Nach [1] zu urteilen handelt es sich bei der Meldung um den Nebeneffekt irgendeines Patches, der in den Kernel eingeflossen ist und soll keinen Effekt haben. sd ist hierbei die Festplatte und sr das DVD-Laufwerk, falls es noch jemanden interessiert.

Den neuen Kernel mit Debugging habe ich gebaut und laufen lassen. In den Logs taucht allerdings nicht viel auf, was mir besonderes auffallen würde. Das einzige was bisher einer Fehlermeldung gleicht ist das:

Code: Alles auswählen

system 00:00: iomem range 0x9fc00-0x9ffff could not be reserved
Diese Zeile taucht in meheren Varianten auf, ist aber bei einer Googlesuche auch in vielen anderen Logs zu finden, ohne dass sich jemand daran stört. Scheint also harmlos zu sein.

Wirklich schlau werde ich daraus leider nicht.

[1] http://lkml.org/lkml/2008/1/10/47

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 20.02.2008 17:39:05

Deine interrupt-Ausgabe sieht imo etwas komisch aus (nur der obere Teil):

Code: Alles auswählen

cat /proc/interrupts 
           CPU0       CPU1       
  0:     587036          0   IO-APIC-edge      timer
  1:       3230          0   IO-APIC-edge      i8042
  8:          3          0   IO-APIC-edge      rtc
  9:          1          0   IO-APIC-fasteoi   acpi
 12:       1399          0   IO-APIC-edge      i8042
 14:      14729          0   IO-APIC-edge      libata
 15:      11762          0   IO-APIC-edge      libata
 18:        937          0   IO-APIC-fasteoi   eth0
 19:          2          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 20:       3398          0   IO-APIC-fasteoi   HDA Intel, uhci_hcd:usb3
 21:      20216          0   IO-APIC-fasteoi   uhci_hcd:usb4
 22:          0          0   IO-APIC-fasteoi   uhci_hcd:usb5
220:         13          0   PCI-MSI-edge      iwl3945
NMI:          0          0   Non-maskable interrupts
...
zum, Vergleich mal die Ausgabe von meiner Box:

Code: Alles auswählen

cat /proc/interrupts 
           CPU0       CPU1       
  0:         86          1   IO-APIC-edge      timer
  1:     211261          9   IO-APIC-edge      i8042
  4:          3          1   IO-APIC-edge    
  6:          2          1   IO-APIC-edge      floppy
  7:          0          0   IO-APIC-edge      parport0
  8:          0          0   IO-APIC-edge      rtc0
  9:          0          2   IO-APIC-fasteoi   acpi
 12:    2005272         67   IO-APIC-edge      i8042
 14:          1          1   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 16:    5119897          1   IO-APIC-fasteoi   ohci_hcd:usb2, HDA Intel
 17:   16814805          2   IO-APIC-fasteoi   ohci_hcd:usb4, ohci_hcd:usb6, nvidia
 18:      71006     993877   IO-APIC-fasteoi   ahci
 19:       8071      10204   IO-APIC-fasteoi   ehci_hcd:usb1
 20:          0          0   IO-APIC-fasteoi   ohci_hcd:usb3, ohci_hcd:usb5
 21:   11169191          1   IO-APIC-fasteoi   cx88[0], cx88[0]
219:     170116      69919   PCI-MSI-edge      eth1
220:    1144284     948943   PCI-MSI-edge      eth0
NMI:          0          0   Non-maskable interrupts
...
Selbst wenn man jetzt sagt, das ist kurz nach dem Start 'geknippst', fällt doch auf, dass bei deiner Ausgabe in der 2. Spalte nur 0 steht, und das trotz der hohen Anzahl von Interrupts auf der cpu0. Das wäre der Ansatzpunkt zum Nachhaken. Jetzt ist die Frage, wie rausbekommen, warum das so ist. Da das mit debugging-Optionen in acpi nix weiter gebracht hat, würd ich mal vorschlagen, einen defconfig-Kernel (make defconfig - wenn nötig um eigene Angaben zu ergänzen, zB spezifische Hardware) zu bauen und mit dem mal zu booten. Was für ne cpu hast du eigentlich? Im Falle von Intel könntest du auch mal powertop versuchen, vielleicht zeigt das ja den Schuldigen. Apropos powertop, das normale top zeigt auch nix Ungewöhnliches? Die .config von deinem kernel kannst du auch mal in's nopaste stellen.

ciao, storm

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 21.02.2008 11:37:48

Das System ist ein älterer Core Duo.

Ein frischer Kernel mit defconfig hat auch keine wesentliche Änderung gebracht. Genauso übrigens ein Kernelimage 2.6.24-1-686 aus Sid, das ich kurzerhand mal installiert habe, um einen Configurationsfehler hunderprozentig auszuschließen. Die Probleme bleiben nach wie vor bestehen.

Top zeigt nichts, worüber ich mir jetzt Sorgen machen würde. Speicherverbrauch und CPUbelastung sehen normal aus, ebenso wie die einzelnen Prozesse. Mit powertop kenne ich mich nicht besonders aus. Ich habe die neuste Version eben mal ausprobiert, aber es scheint ja nur um Übeltäter in Sachen Energiesparen zu gehen.

Meine alte Kernelconfig habe ich hier hochgeladen: http://rapidshare.com/files/93638813/co ... .24.2.html
Wundere dich nicht, wenn ein paar Optionen recht chaotisch aussehen, das kommt größtenteils vom vielen Probieren mit dem neuen Kernel.

/proc/interrupts sieht mit dem Sidkernel übrigens so aus:

Code: Alles auswählen

  0:      38875          0   IO-APIC-edge      timer
  1:        115          0   IO-APIC-edge      i8042
  8:          0          0   IO-APIC-edge      rtc
  9:          2          0   IO-APIC-fasteoi   acpi
 12:        123          0   IO-APIC-edge      i8042
 14:       8491          0   IO-APIC-edge      libata
 15:       1229          0   IO-APIC-edge      libata
 17:          3          0   IO-APIC-fasteoi   firewire_ohci
 18:        359          0   IO-APIC-fasteoi   eth0
 19:          2          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 20:        351          0   IO-APIC-fasteoi   uhci_hcd:usb2, HDA Intel
 21:       4582          0   IO-APIC-fasteoi   uhci_hcd:usb3
 22:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:          0          0   IO-APIC-fasteoi   sdhci:slot0
220:         13          0   PCI-MSI-edge      iwl3945
NMI:          0          0   Non-maskable interrupts

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 21.02.2008 19:08:21

Hmm, seltsam, ich find auch keine Berichte im Netz, dass es anderen auch so geht.
Langly hat geschrieben:Mit powertop kenne ich mich nicht besonders aus. Ich habe die neuste Version eben mal ausprobiert, aber es scheint ja nur um Übeltäter in Sachen Energiesparen zu gehen.
Nicht so schnell, junger Padawan. *g
Powertop zeigt eben auch die Programme/syscalls an, die die CPU am häufigsten aus der Ruhe bringen und ich denk, dass ist bei dir das Problem. Deswegen (vielleicht) auch der hohe interrupt-Wert bei cpu#0.
Meine alte Kernelconfig habe ich hier hochgeladen: http://rapidshare.com/files/93638813/co ... .24.2.html
Wundere dich nicht, wenn ein paar Optionen recht chaotisch aussehen, das kommt größtenteils vom vielen Probieren mit dem neuen Kernel.
Hab ich mir angekuckt, da ist erstmal auch nichts ungewöhnliches dabei, aber das kann man mit draufschauen auch nicht wirklich sehen. Einzig: da schwirren alle möglichen Optionen und Module drin rum, aber kernel hacking hast du nur zum Teil drin, da kannst du mal aktivieren (und natütlich einen neuen Kernel bauen *g):

Code: Alles auswählen

[*] kernel debugging
[*]   Debug shared IRQ handlers
[*]   Detect Soft Lockups
[*]   Collect scheduler debugging info
Die erste Option wirft 'unechte' Interrupts, wenn ein Treiber mit shared interrupts nicht zurecht kommt (-> syslog), die zweite Option erzeugt ebenfalls Einträge im syslog wenn ein zB Treiber mehr als 10 s den kernel nicht freigibt. Die letzte Option erzeugt nur die Datei /proc/sched_debug, die aber zur Auswertung der scheduler-Beanspruchung ganz gut ist. Dafür geb ich dir mal ein Skript von mir: http://nopaste.debianforum.de/get/7521 - aber Achtung: das kann sein, dass es bei dir nicht läuft (braucht zB python-curses). Falls du es in einen editor lädst, musst du auch aufpassen, weil das python ist, da müssen die Einrückungen auf alle Fälle so bleiben und dürfen auch nicht in tabs umgewandelt werden. Es läuft auch so noch nicht astrein, weil curses die Ausgabe nicht zuverlässig erneuert (alte Zahlen bleiben manchmal stehen). Falls da irgendwas arg komisch aussieht, berichte es mal.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 22.02.2008 13:28:09

Mir ist gerade etwas seltsames passiert: Ich habe den Kernel nochmal mit den von dir genannten Optionen gebaut, rebootet und anschließend war die Kiste statt zu langsam viel zu schnell. Die Taskleiste wurde nicht mehr eingeblendet sondern eingeschossen und ich hatte auf einmal Mühe, grafische Anwendungen noch gezielt unter Kontrolle zu halten.
Einen reboot später war die Kiste wieder so langsam wie vorher :?

Ich liefere mal ein paar Logs:
syslog: http://nopaste.debianforum.de/7533
/proc/sched_debug: http://nopaste.debianforum.de/7534
Und powertop:

Code: Alles auswählen

Cn                 Verweildauer       P-States (Frequenzen)
C0 (Prozessor läuft)    (15,8%)         2,00 GHz     0,0%
C1                0,0ms ( 0,0%)         1,67 GHz     0,0%
C2                0,1ms ( 0,5%)         1333 MHz     0,0%
C3                2,7ms (83,8%)         1000 MHz   100,0%


Aufwachen pro Sekunde : 342,8   Intervall: 5,0s
Keine ACPI Stromverbrauch-Schätzung verfügbar

Häufigste Ursachen für das Aufwachen:
  38,6% (232,6)       <interrupt> : extra timer interrupt 
  34,1% (205,6)      <kernel IPI> : Rescheduling interrupts 
   5,2% ( 31,6)       firefox-bin : futex_wait (hrtimer_wakeup) 
   4,1% ( 24,8)              Xorg : do_setitimer (it_real_fn) 
   4,0% ( 24,0)       <interrupt> : uhci_hcd:usb4 
   4,0% ( 24,0)   USB Gerät  4-1 : USB-PS/2 Optical Mouse (Logitech) 
Vielleicht fällt dir ja mehr auf als mir.

Sei mir bitte nicht böse wenn ich dein Script nicht ausprobieren möchte. Das ist ein für mich wichtiges System, und deshalb möchte ich es vermeiden, Programme und Scripts, die ich nicht vollständig durchblicke, aus fremder Quelle zu benutzten. Ich möchte dir keinesfalls etwas unterstellen, aber ich hoffe du verstehtst meine Beweggründe, mit so etwas ein wenig vorsichtig zu sein.

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 22.02.2008 20:05:27

Langly hat geschrieben:Mir ist gerade etwas seltsames passiert: Ich habe den Kernel nochmal mit den von dir genannten Optionen gebaut, rebootet und anschließend war die Kiste statt zu langsam viel zu schnell. Die Taskleiste wurde nicht mehr eingeblendet sondern eingeschossen und ich hatte auf einmal Mühe, grafische Anwendungen noch gezielt unter Kontrolle zu halten.
Meinst du das jetzt spöttisch? Also der Rechner hat normal (wie vor dem Auftreten des Bugs) gearbeitet? Das klingt irgendwie absurd.
Ich liefere mal ein paar Logs:
syslog: ...

Code: Alles auswählen

Feb 22 13:00:39 Laptop powersaved: CPU frequency scaling is not supported by your processor.
Feb 22 13:00:39 Laptop powersaved: enter 'CPUFREQD_MODULE=off' in /etc/powersave/cpufreq to avoid this warning.
Feb 22 13:00:39 Laptop powersaved: Starting powersaved with ACPI support
Das erscheint mir irgendwie bedenklich. Die Ausgabe kann zwar auch irreführend (also unerheblich) sein, aber einen Versuch ist's wert. Du hast den Kernel mit den folgenden Optionen gebaut:

Code: Alles auswählen

CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
Die solltest du mal rauswerfen, CENTRINO ist auf jeden Fall veraltet und ACPI_CPUFREQ bringt die Funktionalität auch mit. Ich hab diverse [1] Bugs gefunden, die bei ähnlicher Hardware vorkamen, bei deinem Schleppi ist die Ursache in dieser Ecke zu suchen. Möglicherweise hat ein Fix für anderes Problem deins erst getriggert und als Ursache zwingt sich fast ACPI (wie so oft) auf.
Falls obige Ratschläge immernoch keine Abhilfe liefern, bleibt nur weiter im Nebel zu stochern, so bitter das auch sein kann. Ein paar Ideen hab ich ja noch. *g
Du könntest zB selektive Test machen, also beispielsweise bestimmte Module (außer die wirklich wichtigen!) beim booten per kernel-commandline abschalten und beobachten, ob sich etwas an dem Verhalten ändert. Aber möglichst immer nur eins. Du kannst beim nächsten Mal kernelbauen die Option NOHZ weglassen und es stattdessen mal mit HIGH_RES versuchen, oder beide Optionen zusammen. Hast du eigentlich immer gleich den XServer an nach dem Booten? Wie sieht das aus, wenn du nur auf Konsole-Betrieb schaltest, also init 2 beim booten?

OT: dein Kernel warnt beim booten, dass er nur 896MB Speicher verwendet, wie viel sind denn verbaut? Die entsprechende Option wäre HIGHMEM4G.

Code: Alles auswählen

Laptop kernel: Warning only 896MB will be used.
Laptop kernel: Use a HIGHMEM enabled kernel.
Und weiter gehts...

Code: Alles auswählen

Cn                 Verweildauer       P-States (Frequenzen)
C0 (Prozessor läuft)    (15,8%)         2,00 GHz     0,0%
C1                0,0ms ( 0,0%)         1,67 GHz     0,0%
C2                0,1ms ( 0,5%)         1333 MHz     0,0%
C3                2,7ms (83,8%)         1000 MHz   100,0%
Seltsame erste Zeile, oder nicht!? Das kann natürlich auch nur eine fehlerhafte Ausgabe sein, genauso gut aber auch mit dem oben Beschriebenen zusammenhängen (zB: inkorrekte ACPI-Tabelle).

Code: Alles auswählen

Aufwachen pro Sekunde : 342,8   Intervall: 5,0s
Keine ACPI Stromverbrauch-Schätzung verfügbar

Häufigste Ursachen für das Aufwachen:
  38,6% (232,6)       <interrupt> : extra timer interrupt 
...
AFAIR sind das eindeutig zu viele Wakeups.

/Edit: Nein, die Ausgabe von powertop scheint wohl weitestgehend normal zu sein. [2]
Sei mir bitte nicht böse wenn ich dein Script nicht ausprobieren möchte. Das ist ein für mich wichtiges System, und deshalb möchte ich es vermeiden, Programme und Scripts, die ich nicht vollständig durchblicke, aus fremder Quelle zu benutzten. Ich möchte dir keinesfalls etwas unterstellen, aber ich hoffe du verstehtst meine Beweggründe, mit so etwas ein wenig vorsichtig zu sein.
Ach iwo, ist kein Problem. Ich hätte vermutlich genauso reagiert, wenn ich nicht durchblicken würde. Das Skript macht wie gesagt nix anderes, als nur den Inhalt von sched_debug anders formatiert und fortlaufend auszugeben, insofern hast du da nix verpasst und weiterbringen tuts uns auch nicht, da deine Ausgabe von sched_debug normal aussieht.


ciao, storm


[1] http://bugzilla.kernel.org/show_bug.cgi?id=9014
https://bugs.launchpad.net/moblin-kernel/+bug/154076
http://www.mail-archive.com/debian-lapt ... 49701.html
[2] http://www.smop.co.uk/mediawiki/index.p ... g_on_Linux
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 23.02.2008 11:45:06

Noch was: der wifi-Adapter funktioniert bei dir? Hab gelesen, dass bis vor kurzem der entsprechende microcode für den Adapter gefehlt hat.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 23.02.2008 11:46:12

storm hat geschrieben:
Langly hat geschrieben:Mir ist gerade etwas seltsames passiert: Ich habe den Kernel nochmal mit den von dir genannten Optionen gebaut, rebootet und anschließend war die Kiste statt zu langsam viel zu schnell. Die Taskleiste wurde nicht mehr eingeblendet sondern eingeschossen und ich hatte auf einmal Mühe, grafische Anwendungen noch gezielt unter Kontrolle zu halten.
Meinst du das jetzt spöttisch? Also der Rechner hat normal (wie vor dem Auftreten des Bugs) gearbeitet? Das klingt irgendwie absurd.
Es geht sogar noch eine Nummer absurder: Ich meinte das wirklich wörtlich. Das System war plötzlich so schnell geworden dass ich so gut wie nichts mehr unter Kontrolle hatte. Keine Ahnung, woran das gelegen hat. Der erste Gedanke war bei mir wieder ACPI. Zum Testen ob ACPI funktioniert habe ich kurzerhand mal den Deckel geschlossen und wollte ausprobieren, ob suspend noch geht. Tja, eingeschlafen ist er, aber leider nicht aufgewacht, was so schon ewig nicht mehr passiert ist. Danach konnte ich weiteres Testen vergessen, weil nach einem reboot alles wieder zu langsam war.

Die Module für Centrino habe ich rausgeworfen und den Kernel ohne NOHZ und ohne den neuen Scheduler aber mit HIGH_RES gebaut, aber das hat auch nicht bewirkt. An Modulen wird außer i2c nichts geladen, was ich entbehren könnte. Nach einem Blacklisten davon war ich genauso weit wie vorher. Eine Fehlconfiguration im Kernel würde ich aber fast ausschließen wollen, sonst müsste das ja auch im Sidkernel so sein, über den sich ja noch niemand beschwert hat.

Gestern habe ich mit dem gleichen Ergebnis wie sonst probiert, die RC2 von 2.6.25 zu bauen. Irgendwie bringt es das alles nicht. Ganz interessant ist aber, dass beim Starten von KDE ab und an eine Fehlermeldung kommt, dass dbus nicht aktiv ist. Wenn ich dann ein /etc/init.d/dbus start probiere läuft dieser aber schon. Übrigens spielt es keine Rolle, ob ich in X arbeite oder direkt auf der Konsole, es ist einfach immer viel zu langsam.
OT: dein Kernel warnt beim booten, dass er nur 896MB Speicher verwendet, wie viel sind denn verbaut? Die entsprechende Option wäre HIGHMEM4G.
Ich weiß, ich weiß. Das hatte ich zwischenzeitlich sogar mal (neben einigen anderen Dingen) ausgebessert, aber wenn man mit einem Haufen Kernelconfigs hantiert ist es schwer durchzublicken, in welcher das nun war :)

Ich wette, du bereust schon, in diesem Thread geantwortet zu haben :D

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 23.02.2008 14:27:40

storm hat geschrieben:Noch was: der wifi-Adapter funktioniert bei dir? Hab gelesen, dass bis vor kurzem der entsprechende microcode für den Adapter gefehlt hat.

ciao, storm
Das hat sich vorher wohl mit meinem letzten Beitrag überschnitten, sorry.

Ehrlich gesagt habe ich keine Ahnung, ob wlan funktioniert. Ich habe schon ewig lange kein Wlan mehr benutzt. Im neuen Kernel ist ja jetzt endlich der Treiber für ipw3945 oder iwl3945, wie der neuerdings heißt. Ich habe den bei ersten Kompilieren mal reingenommen und auch die proprietäre Firmware nach /lib/firmware kopiert, bin dann aber vor lauter Schwierigkeiten gar nicht mehr zum Testen gekommen. Bei den letzten paar Durchläufen ist der Treiber aber auch wieder rausgeflogen, um Schwierigkeiten damit auszuschließen.

Mit den alten Kernelversionen und einem selbst gebauten Treiber hat es bisher jedenfalls immer funktioniert.

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 23.02.2008 15:48:46

Langly hat geschrieben: Ich wette, du bereust schon, in diesem Thread geantwortet zu haben :D
Nee nee, ich fasse das als Herausforderung auf und außerdem lerne ich ja auch weiter dabei. *g Natürlich wär's schön, wenn wir endlich mal eine Lösung finden. Ich werd mal schauen, ob ich jemanden finde, der uns da beistehen kann.
Langly (zum wifi-Treiber) hat geschrieben: Bei den letzten paar Durchläufen ist der Treiber aber auch wieder rausgeflogen, um Schwierigkeiten damit auszuschließen.
Ah gut, das wollte ich nur wissen.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 24.02.2008 11:50:24

Einen Schritt weiter bin ich jetzt doch gekommen.

Die Probleme tauchen nur unter X auf, nicht auf der Konsole. Ich hatte das zwar schon einmal ausprobiert, aber um normal zu laufen darf X noch gar nicht gestartet worden sein. Wenn hier einmal der kdm läuft ist bis zu einem reboot nichts mehr mit der Maschine anzufangen (auf der Konsole und unter X). Als ich das probiert hatte habe ich den kdm nur abgewürgt, weshalb es wohl schief gelaufen ist.

Die grafischen Effekte liegen nach meiner jetzigen Ansicht am fglrx-Treiber. Selbst wenn das Modul überhaupt nicht geladen wird (aber natürlich auch mit geladenem Modul) tauchen hier solche Probleme auf, wie dass die Ordneransichten im Konqueror ewig zum Auftauchen brauchen oder der Browser kaum noch zu gebrauchen ist, weil alles so träge und rucklig wird. Das ist auch erst mit dem neuen Kernel aufgetaucht.

Wenn ich den fglrx mit der Deinstallationsroutine runterschmeiße und vesa verwende kann man bis auf die nicht native Auflösung ganz gut arbeiten. Trotzdem reagiert das System noch nicht wie gewohnt, beispielsweise braucht ein Kompiliervorgang für den neuen Kernel nach wie vor eine halbe Ewigkeit unter X, während er in der Konsole scheinbar normal durchläuft.

Langsam bin ich hier verwirrter als je zuvor. Was das alles mit dem Verzeichnis /proc/acpi zu tun hat ist mir unverständlich genauso wie die Frage warum Zugriffe auf die Platte beim Kompilieren so langsam sind, meine Transferrate aber immer noch so hoch ist wie sonst auch.
Einzelne Partitionen der Platte sind übrigens (per Hand mittels dm_crypt + luks, nicht vom Installer) verschlüsselt, jedoch nicht die Verzeichnisse, in denen die Quellcodedateien liegen.

Ich blicke hier wirklich nicht mehr durch.

Achja, der Kernel läuft übrigens auf einem anderen System mit einigen wenigen veränderten Modulen für die andere Hardware wie gewohnt.

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 24.02.2008 18:19:58

Langly hat geschrieben: Die Probleme tauchen nur unter X auf,
...
Wenn ich den fglrx mit der Deinstallationsroutine runterschmeiße und vesa verwende kann man bis auf die nicht native Auflösung ganz gut arbeiten. Trotzdem reagiert das System noch nicht wie gewohnt,
...
Ok, wieder ein Stück weiter. Ich denk, dass X bzw. fglrx das Problem nur verschärft aber nicht erzeugt.

Noch zwei Fragen bzw. Tests: wenn du den kernel mit acpi=off bootest, ist das Problem zwar weg, aber das power-managment funktioniert dann auch nicht mehr? Und Nummer 2: in deiner kernel-config ist CONFIG_CPU_IDLE angeschaltet, bau bitte mal einen kernel, der ohne diese Option, aber beim Rest gleich mit dem ersten problematischen kernel ist. (Power management options -> [ ] CPU idle PM support)

Falls wir damit immernoch keine Ursache finden, hättest du noch die Möglichkeit, die 2.6.24-rcX kernel zu testen. Da könnte man die Version rausbekommen, bei der dieser Knick in der Funktionalität entstand. Allerdings wird das genaue Rausfinden des problemverursachenden Patches etwas haarig, da AFAIR die Änderungen von 2.6.23 auf 2.6.24 die zahlenmäßig größten in der Entwicklung der 2.6er kernel-Serie waren.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 25.02.2008 15:58:29

Hallo storm,

ich habe mich jetzt doch für einen anderen Weg entschlossen. Ich hatte schon länger vor, auf dem Laptop ein neues System aufzusetzen, sei es, weil die Partitionierung mit den Cryptpartitionen nicht mehr wirklich passend für meine Bedürfnisse ist oder die ganze Installation noch aus der Zeit stammt, als Etch noch testing war und ich entsprechend viele Sachen per Hand geflickt habe, die bis heute irgendwo noch so schlummern und Probleme verursachen mögen. Jetzt habe ich wohl einen Anstoß, die Kiste endlich mal zu erneuern.

Ich könnte nämlich nach wie vor wetten, dass es nicht am Kernel liegt, schließlich geht genau die gleiche Config ja auf einer anderen Maschine. Das ist nur insofern schade weil wir so wahrscheinlich nicht mehr rausfinden werden, woran genau es nun gehangen hat, aber ich denke, wenn es wirklich irgendwo am restlichen System liegt, dann haben wir sowieso schlechte Karten, in absehbarer Zeit das Problem zu finden.

Bis Donnerstag Abend werde ich unterwegs sein und höchstwahrscheinlich keine Gelegenheit haben, hier vorbeizusehen. Danach setze ich mal ein sauberes System auf und sehe, was passiert. Ich werde mich also wahrscheinlich erst so im Laufe des Freitags wieder hier melden können, nur damit du dich nicht wunderst.

Immerhin komme ich wegen dieses Fehlers mal zu einem neuen, sauberen System, bisher war ich immer irgendwie zu faul zum Neuinstallieren :)

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 25.02.2008 20:39:25

Kein Problem, wenn du dir damit die Nerven schonen kannst, hat es ja auch einen Sinn. Hattest du mal meinen Vorschlag "ohne CPU_IDLE" ausprobiert? Falls du noch Nerven/Zeit/Lust hast: 2.6.24.3 ist auch schon in der Röhre, aber die Fixes sind eh die gleichen, wie sie auch bis 25-rc2 drin sind. Und gestern ist auch noch 25-rc3 rausgekommen.

Für den Fall der Neuinstallation: wer weiß, wie lange wir noch gesucht hätten. Wenn man sich mal die Anzahl der gemeldeten Probleme bei kerneloops.org anschaut, kann einem bloß ganz mulmig werden. 8O

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Langly
Beiträge: 262
Registriert: 15.12.2004 17:19:39
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von Langly » 29.02.2008 17:42:54

storm hat geschrieben:Hattest du mal meinen Vorschlag "ohne CPU_IDLE" ausprobiert?
Ja, habe ich, mit dem gleichen Ergebnis wie die ganze Zeit. Ich habe dann heute früh das System neu aufgesetzt, und so wie es aussieht, hat das das Problem gelöst. Ein wenig nervös bin ich noch, aber ehrlich gesagt rennt die Kiste wie noch nie, seit ich sie angeschafft habe. Ich vermute daher das Problem bestand schon die ganze Zeit und ist erst mit einer Änderung von 2.6.23 zu 2.6.24 extrem zutage getreten.

Ich bin auf jeden Fall froh, dass jetzt alles wieder funktioniert. Ich war zwar nicht unbedingt auf den neuen Kernel angewiesen, aber ein gutes Gefühl war es trotzdem nicht, sich in dieser Hinsicht auf eine alte Version beschränken zu müssen.

Was mich angeht, war die ganze Aktion wirklich sehr lehrreich. Ich habe durch das ständige Neukomplieren und Ausprobieren und letztendlich auch durch deine Hilfe so viel gelernt wie schon lange nicht mehr in so kurzer Zeit, deshalb vielen Dank, dass du dir die Zeit genommen und die Mühe gemacht hast, mit mir auf Ursachenforschung zu gehen.

Ist so gesehen ein wenig blöd, weil wir das Problem ja nicht wirklich zuordnen können, aber wenn der Fehler tatsächlich im System lag hätten wir noch ewig erfolglos suchen können, ohne wirklich weiterzukommen. Ich bin auf jeden Fall froh, dass sich das erstmal erledigt hat und alles wieder funktioniert, so blöd diese Einstellung, nur aufs Ergebnis, und nicht auf die Vorgänge unter der Haube zu schauen auch ist.

Nochmal danke für deine Hilfe. Ich kämpfe noch ein wenig mit Supend2Ram, danach dürfte alles wieder eingerichtet sein :)

Benutzeravatar
gOtNoPhEaR
Beiträge: 863
Registriert: 17.04.2004 15:49:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Gau-Algesheim
Kontaktdaten:

Re: Kernel 2.6.24 mit ACPI plötzlich träge [gelöst]

Beitrag von gOtNoPhEaR » 01.04.2008 16:09:57

Gleiches Problem hier.
Wenn ich im Kernel die Optionen rund um ACPI /proc/acpi aktiviere verursachen die Prozesse wie "artsd" recht hohe CPU Last im Leerlauf und das System wird unbenutzbar langsam.
Werde wenn ich zu Hause bin nähere Angaben machen.
Greetz, gOtNoPhEaR

OS: Debian/testing amd64

Benutzeravatar
gOtNoPhEaR
Beiträge: 863
Registriert: 17.04.2004 15:49:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Gau-Algesheim
Kontaktdaten:

Re: Kernel 2.6.24 mit ACPI plötzlich träge [gelöst]

Beitrag von gOtNoPhEaR » 02.04.2008 22:22:13

Habe das Problem Lösen können.

Habe einfach mal den Dienst "acpid" deinstalliert und anschliessen das Paket "acpi-support" installiert mit allen abhängigkeiten und nun funktioniert wieder alles wie gewohnt auch ohne Neuinstallation.
Greetz, gOtNoPhEaR

OS: Debian/testing amd64

Antworten