[gelöst]Fehler beim Realtime-Kernel (2.6.19) kompilieren

[mujo]

Hallo Leute,
heute wollte ich den Kernel 2.6.19 samt realtime-Patch (http://people.redhat.com/mingo/realtime ... .6.19-rt15 von Ingo Molnar) kompilieren und installieren. Ohne den RT-patch funktioniert es auch wunderbar. Nur mit dem Patch bricht er beim kompilieren mit folgender Meldung ab:

Code: Alles auswählen

 ...
CC [M]  lib/reed_solomon/reed_solomon.o
  CC [M]  lib/zlib_deflate/deflate.o
  CC [M]  lib/zlib_deflate/deftree.o
  CC [M]  lib/zlib_deflate/deflate_syms.o
  LD [M]  lib/zlib_deflate/zlib_deflate.o
  Building modules, stage 2.
  MODPOST 1519 modules
WARNING: Can't handle masks in drivers/ide/pci/atiixp:FFFF05
WARNING: "pm_send_all" [arch/i386/kernel/apm.ko] undefined!
WARNING: "pm_active" [arch/i386/kernel/apm.ko] undefined!
make[2]: *** [__modpost] Fehler 1
make[1]: *** [modules] Fehler 2
make[1]: Leaving directory `/usr/src/rtkernels/linux-2.6.19'
make: *** [debian/stamp-build-kernel] Fehler 2

Bei der .config handelt es sich um die des lauffähigen nicht RT 2.6.19er Kernel plus folgender Anpassungen:

Code: Alles auswählen

CONFIG_DEBUG_KERNEL=y
CONFIG_RT_MUTEXES=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_RCU=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_RT_MUTEX_TESTER=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
CONFIG_WAKEUP_TIMING=y
CONFIG_WAKEUP_LATENCY_HIST=y

Benutzt habe ich die Etch-Version.
Und falls es etwas Hilft: Mit dem 2.6.18er Kernel hat die ganze Prozedur funktioniert.

Da ich relativ neu in der Linuxwelt bin, kann ich mit der Fehlermeldung nicht viel anfangen. Ich hoffe jemand von euch kann mir weiterhelfen. Falls ihr noch irgendwelche Infos braucht, sagt mir bescheid und gebt mir am besten ne Beschreibung wie ich diese unter Linux bekomme (wie gesagt, bin relativ neu). Versucht habe ich diesen Vorgang sowohl mit VMware als auch mit einem realen System. Beidesmal bekomm ich aber (logischerweise) die selbe Fehlermeldung (ein Versuch wars aber Wert)!

Gruß
Jörg

[Spasswolf]

Wenn du apm und den atiixp Treiber nicht brauchst würde ich beides aus der Konfiguration rausschmeissen.

[mujo]

danke für die schnelle Antwort!
hast mich ja jetzt richtig dumm dastehen lassen!
Hab die Module rausgeschmissen und anschließend hat es funktioniert. Leider dachte ich, dass die Warnungen nichts mit dem Abbruch zu tun haben, sonst wäre ich vielleicht auch selbst drauf gekommen.

Deshalb muss ich jetzt nochmal Fragen was es mit dem "__modpost Fehler 1" und "modules Fehler 2" auf sich hat?
Wäre nett, wenn mir das jemand kurz erklären könnte.
Außerdem hatte ich noch folgedndes seltsames Problem: Beim ersten mal booten bekam ich nen Kernelpanic mit der Bergründung: "IO-APIC doesn´t work " (oder so ähnlich) und noch irgenwas von einem nicht initialisierten timer. Beim zweiten mal booten funktionierte alles wunderbar. Kann mir hier ebenfalls noch mal jemand eine kurze Erklärung abgeben was das sollte bzw. kennt jemand dieses Phänomen ebenfalls?

Auf jeden Fall läuft der Kernel erstmal!

[gms]

Deshalb muss ich jetzt nochmal Fragen was es mit dem "__modpost Fehler 1" und "modules Fehler 2" auf sich hat?

bedeutet nur, daß In den Makefile-Zielen mit der Bezeichnung "__modpost" und "modules" Fehler aufgetreten sind.

Wenn du dir z.B. ein einfaches Makefile anschaust:

Code: Alles auswählen

all:
        @$(MAKE) --no-print-directory do1
        @$(MAKE) --no-print-directory do2

do1:
	true

do2:
        false

Für das Ziel "all" müssen also die Ziele "do1" und "do2" ( über einen rekursiven "make"-Aufruf) erstellt werden. Beim Ziel "do1" wird nur das Kommando "true" aufgerufen, beim Ziel "do2" wird jedoch das Kommando "false" aufgerufen. "make" überprüft nach jedem Kommando den Rückgabewert. Bei "false" ist dieser 1, also schließt "make" daraus, daß hier ein Fehler passiert ist, quitiert dies durch folgende Fehlermeldung:

Code: Alles auswählen

make[1]: *** [do2] Fehler 1

und liefert dem übergeordneten "make" einen Fehlercode zurück. Dieses quitiert dies mit folgender Fehlermeldung:

Code: Alles auswählen

make: *** [all] Fehler 2

und liefert den Fehlercode 2 an die Shell zurück. Solange das Makefile also syntaktisch richtig ist, werden vom "make" Kommando die Fehler nur "weitergegeben" und die Fehlermeldungen sagen nur aus in welchem Teil (Ziel bzw Rekurisionstiefe) des Makefiles diese Fehler aufgetreten sind.

Ich hoffe ich habe das halbwegs vernünftig erklärt

Wegen dem anderem mysteriösen Verhalten beim ersten Reboot:
Ich möchte dich nicht verunsichern, aber wenn der Kernel einmal nicht sauber bootet, hat er (oder allgemein der PC ) auch das Potential, dieses zu wiederholen. Ich hoffe für dich, daß ich dahingehend Unrecht behalte.

Gruß
gms

[mujo]

@gms: Danke für die ausführliche Antwort, hat mir sehr weiter geholfen.

Ich bin zwar neu in diesem Forum, aber irgendwie fühle ich mich hier wohl!!

[Kokopelli]

Hallo!
Sorry, wenn ich mich mal hier einmische, aber da der Thread ja gelöst ist, habe ich dazu mal ein paar Fragen:

Was genau bringt mir ein Echtzeitkernel als Desktop-Anwender? Ist der Latenzzeitunterschied so groß, daß man ihn wirklich bei der Arbeit mit dem System wahrnimmt? Harte Echtzeit ist aber wohl eher nicht gegeben, oder?

Danke!

[goecke]

Hallo!
Sorry, wenn ich mich mal hier einmische, aber da der Thread ja gelöst ist, habe ich dazu mal ein paar Fragen:

Was genau bringt mir ein Echtzeitkernel als Desktop-Anwender? Ist der Latenzzeitunterschied so groß, daß man ihn wirklich bei der Arbeit mit dem System wahrnimmt? Harte Echtzeit ist aber wohl eher nicht gegeben, oder?

Danke!

Ich habe bei Audio-Recordings (88.2 khz 24bit) durchaus schon dropouts bemerkt
und meine, daß der Realtime-Kernel erheblich zuverlässiger läuft.

(es gibt gerade für Audio-Recording sehr viele Einflussfaktoren Chipsatz, PCI-Latenz, etc..
so daß es bei anderr Hardware auch ohne Realtime-Patch gut läuft)

Bitte
Johannes Goecke

[mujo]

Als Desktop-Anwender bringt es dir wahrscheinlich recht wenig! *g*
Aber z.B bei Linux als Maschinensteuerung ist SoftRT und HardRt unerlässlich! Hab ja nie gesagt, dass ich damit meinen Desktop beschleunigen will.
Bei HardRt kommt es darauf an wie du HardRT definierst!

[Kokopelli]

Bei HardRt kommt es darauf an wie du HardRT definierst!

Danke für die Antworten... aber definieren muß ich das nicht, das sind schon wohl-definierte Begriffe.
Ich kann mir halt einfach nicht vorstellen, daß Linux einfach so auf beliebiger Hardware harte Echtzeit schafft... das halte ich für eher utopisch, und in den meisten Fällen reicht soft-realtime ja auch aus.

Ich denke mal, das sich auf diesem Gebiet gerade ab (voraussichtlich) 2.6.20 einiges tun wird, wenn zu den Hrtimern die Dynamic Ticks aufgenommen werden... Für viele Gebiete dürfte die damit gewonnene Präzision schon ausreichen, denke ich.
Ich finde, es wäre wirklich nicht schlecht, auf diesem Gebiet noch ein bisserl im Kernel aufzuräumen, wieviele Timermodelle haben wir jetzt? 3?
Goodbye, Jiffies

[nonoo]

Guten Abend Kokopelli,

auch wenn der Thread gelöst ist.

Die Übersichtlichkeit lleidet Du dein Posting.

Ein eigener Thread wäre doch möglich gewesen?

Was hat dich gehindert?

Ich habe mal eben dein Problem ergoogelt.

Google hätte dir auch weiter geholfen.

Mit der SuFu wärst Du hier nicht weitergekommen.


Ich wünsche dir weiter alles Gute.


MfG

nonoo