Kompilierfehler Bristuff-0.3.0-PRE-1f angepasster Florz 10

[milamber]

Hi Leute,

ich bin nach dem HowTo von Britzelfix vorgegangen, um Asterisk mit Bristuff zu installieren. Zusätzlich habe ich noch den auf die aktuelle Bristuff Version angepasste Variante des Florz 10 Patchs benutzt.
Leider gibt es mit Florz Patch ein Problem beim Kompilieren des zaphfc Treibers. Der Link auf die Kernelheaders ist korrekt gesetzt.
Die komplette Logausgabe bis nach dem Auftreten des Fehlers ist in der angehängten Log Datei enthalten.

ls -l /usr/src
drwxrwxr-x 5 server server 4096 2006-01-06 00:13 asterisk
lrwxrwxrwx 1 root src 28 2005-12-28 00:54 linux-2.6 -> linux-headers-2.6.12-10-686/
drwxr-xr-x 18 root root 4096 2005-12-26 23:01 linux-headers-2.6.12-10
drwxr-xr-x 4 root root 4096 2005-12-28 01:04 linux-headers-2.6.12-10-686
drwxr-xr-x 20 root root 4096 2005-12-27 00:45 linux-source-2.6.12
lrwxrwxrwx 1 root src 19 2005-12-27 00:17 linux-source-2.6.12-10-686 -> linux-source-2.6.12
-rw-r--r-- 1 root root 40349575 2005-12-22 14:09 linux-source-2.6.12.tar.bz2

Vielen Dank für eure Hilfe.

Gruss
milamber

 

[cibi]

Bristuff 0.3.0-PRE-1f geht ohne Probleme mit dem angepassten Florz patch.

Überprüfe mal auf was /lib/modules/<version>/build bzw. source zeigt

Edit:
bei mir sieht das ganze so aus

kernel-source-2.6.12-ct-1
linux -> /usr/src/kernel-source-2.6.12-ct-1
linux-2.6 -> /usr/src/kernel-source-2.6.12-ct-1
linux-2.6.12 -> /usr/src/kernel-source-2.6.12-ct-1

/lib/modules/<version>/build -> /usr/src/kernel-source-2.6.12-ct-1
/lib/modules/<version>/source -> /usr/src/kernel-source-2.6.12-ct-1

Hattest du bisher probleme beim Kompilieren?
- Eventuell mal den Kernel übersetzen: mit make cloneconfig falls vorhanden, wenn nicht .config auf /boot nach /usr/src/linux kompieren und make menuconfig + make (als Notlösung, da es eine Weile dauert... )

- Patch falsch angepasst?

 

[TomS]

Du mußt linux-2.6 auf den Kernel-Source, nicht auf die headers linken

 

[cibi]

Du mußt linux-2.6 auf den Kernel-Source, nicht auf die headers linken

Hatte ich vergessen zu erwähnen - sonst macht das Übersetzen den Kernels auch keinen Sinn
Es ist eventuell nicht nötig den kompletten Kernel zu kompilieren, die ersten paar Schritte sollten i.d.R. genügen, also make und dann nach einiger Zeit abbrechen. (ohne Gewähr ...)

 

[milamber]

Vielen Dank für eure Hilfe. Kompilieren funktioniert jetzt einwandfrei.

Den Florz Patch hatte ich selbst "angepasst". War aber das selbe, wie in deinem Link.

/lib/modules/<version>/build zeigte noch auf die Kernelheader. Der ist wahrscheinlich bei der Package Installation angelegt worden. Ich wusste gar nicht, dass man da auch noch Links setzen muss. /lib/modules/<version>/Source gab es noch nicht.

Die Links unter /usr/src/ hab ich so angelegt wie in deinem Beispiel. Den Kernel hab ich zur Sicherheit letzte Nacht kompiliert. Zuerst die .config rein kopiert und dann make. Hat ca. 6 Stunden gedauert. Das ist wahre PII Power.

Wenn das Linken der Kernelheader definitiv falsch ist (mit Florz Patch), könnte man Britzelfix mal Bescheid sagen, dass er das im HowTo ergänzt. Was meint ihr?
Nochmals Danke.

Gruss
milamber

 

[TomS]

Wenn das Linken der Kernelheader definitiv falsch ist (mit Florz Patch), könnte man Britzelfix mal Bescheid sagen, dass er das im HowTo ergänzt

Leider kenne ich Britzlefix' Anleitung noch nicht. Ich werd sie mir gleich mal anschauen. Ich nutze selber den Florz-Patch auch nicht, daher kann ich auch nicht beantworten, ob dafür ggf. bes. Headers benötigt werden.
Folgendes ist jedenfalls direkt aus der bristuff-Anleitung:

Compiling/installing:
+ Make sure you have configured kernel sources installed!
(this can be done by make menuconfig (save kernel configuration) and then make dep)
if you are running a 2.6 kernel, make sure you have the /usr/src/linux-2.6 symlink
pointing to your 2.6 kernel sources

Mit dem entspr. Link (z.B. linux-2.6 -> linux-2.6.8-24) auf die Sourcen des vorher kompilieren Kernels hatte ich bisher noch keine Probleme beim Kompilieren.

 

[ogir]

Die Kernel-Source muss er nur verlinken wenn er wirklich nen eigenen Kernel gebaut hat, ansonsten sind die Headers ausreichend.

Was ich jedoch schon hatte:

mach mal:
uname -a
und dann vergleiche die Kernelversion mit den installierten kernel-headers.

 

[milamber]

Bei mir hat das Kompilieren ohne Florz Patch auch nur mit Kernel Headern funktioniert(lt. HowTo von Britzelfix). Allerdings bin ich dann wegen nicht vorhandenem RTAI auf Florz umgestiegen. Für Florz braucht man aber definitv die Kernel Sourcen.
Kann das jemand bestätigen?

@ TomS
Mich haben die anders lautenten Anleitungen aus den verschiedenen Quellen etwas überfordert. Deshalb dieser Thread.


@ ogir
Bei mir sind die Versionen alle gleich, weil ich alles zusammen installiert habe. Benutzt du den Florz Patch?

Gruss
milamber

 

[ogir]

Auf nem Kundenserver, ja. Bei mir privat daheim nein, obwohl ich 3x HFC drin habe... funktioniert auch ohne den Patch.

Habe eben nochmal auf dem Server nachgeschaut: definitiv nur Kernel-Header installiert.


Ups, sorry, habe dort ebenfalls keinen Florz installiert.

Frage: Was meinst du mit nicht vorhandenem RTAI? Bei der Florz beschreibung steht doch:

What about RTAI?

Bristuff 0.2.0-RC7h introduced the use of RTAI for b channel timing purposes. This also greatly reduces the CPU IRQ load since an RTAI timer of only 1 kHz is used, instead of the card's 8 kHz clock, plus only a single such timer is used for all cards, much like this patch uses only the clock of a single card for servicing all cards in the system.

However, the way the RTAI code in the original bristuff zaphfc driver is constructed causes some problems: It potentially leads to buffer over- and underruns. RTAI is clocked by some computer-internal clock source that runs completely unsynchronized to the card's clock and that thus probably will deviate from it, depending on the clock source's manufacturing tolerance as well as its temperature and other environmental factors. Now, when this unsynchronized clock causes the card's FIFOs to be filled and emptied by the driver at the computer's side at a rate that is different from the rate at which the card's logic is filling and emptying them at the line interface side, that will cause the FIFOs to run empty and full, respectively, at times.

This problem in principle could be worked around—however, I don't see any major advantages inherent in the use of RTAI over the way the patch currently works, as CPU utilisation is pretty low with recent versions anyway. Considering that the use of RTAI also makes the installation more complicated (needs an RTAI enabled kernel as opposed to the driver patched with this patch which should work with any vanilla 2.4 or 2.6 series kernel), that's why I'll stay away from RTAI for now—this patch removes all RTAI code from the zaphfc driver!

Also dürfte danach doch kein RTAI mehr im zaphfc Treiber vorhanden sein?!

 

[milamber]

@ ogir

Sorry. War etwas unklar formuliert. Ich meinte in meinem Kernel ist kein RTAI vorhanden. Deshalb bin ich auf Florz umgestiegen, weil man RTAI Unterstützung im Kernel da nicht braucht. Ich dachte das sei einfacher :gruebel:

 

[Boje]

Für den bristuff-0.3.0-PRE-1f existiert auf zaphfc.florz.dyndns.org ein passender Florz-Patch 11.

 

[ogir]

@ ogir

Sorry. War etwas unklar formuliert. Ich meinte in meinem Kernel ist kein RTAI vorhanden. Deshalb bin ich auf Florz umgestiegen, weil man RTAI Unterstützung im Kernel da nicht braucht. Ich dachte das sei einfacher :gruebel:

Hast du's schonmal ohne Florzpatch versucht?