Fritzcard mit Gentoo Linux 2.6.32
Matthias Hanft
ähnliche Fragen kamen letzten Herbst hier schon mal auf; die betreffenden
Threads versandeten dann aber immer mehr oder weniger mit der Fest-
stellung "ISDN unter Linux ging ja noch nie so richtig gut", aber
ohne eine richtige Lösung...
Also jedenfalls: Ich wollte meinen Linux-Kernel von 2.6.30 auf 2.6.32
updaten (Gentoo, ist in anderen Linuxen aber vermutlich genauso).
Habe mit der Fritzcard Anrufbeantworter und Fax- und SMS-Server laufen
(meist Capisuite, gelegentlich Hylafax, yaps für SMS). Bisher hats
bei einem Update genügt, die Datei "fcpci.ko" von /lib/modules/kernel-
<alteversion>/net nach /lib/modules/kernel-<neueversion>/net umzu-
kopieren. lsmod zeigt derzeit (im alten Kernel 2.6.30)
Module Size Used by
capi 13504 10
capifs 3788 2 capi
fcpci 556128 3
kernelcapi 34452 2 capi,fcpci
Jetzt gibts bei 2.6.32 eine neue Kernelconfig CONFIG_MISDN_AVMFRITZ.
Es ist aber egal, ob man die auf N oder Y setzt - capiinfo sagt nach
dem Booten mit 2.6.32 immer "capi not installed" (die lsmod-Ausgabe
habe ich leider nicht aufgeschrieben). Jedenfalls erhält man bei
einem manuellen "modprobe fcpci" die Fehlermeldung "Error inserting
fcpci: Invalid module format". Sind 2.6.30-Module nicht mehr mit
2.6.32 kompatibel?! (Oder muß man fcpci neu compilieren, wenn der
neue Kernel läuft, wie bei den VirtualBox-Modulen? Mußte man bisher
aber auch nie.) Oder braucht man fcpci gar nicht mehr, wenn das jetzt
im Kernel ist? Aber capiinit/capiinfo funktioniert ja auch dann nicht,
wenn fcpci gar nicht geladen ist.
Leider kann ich nicht allzuviel herumprobieren (also z.B. 27mal neu
booten und dabei immer neue Konfigurationen ausprobieren), weil das
eigentlich ein 24/7-Server ist, bei dem die Nutzer schon bei kurzer
Downtime ärgerlich werden. Eine neue Config sollte also eine von
Null deutlich verschiedene Wahrscheinlichkeit besitzen, nach dem
Reboot zu funktionieren :-)
Inzwischen habe ich noch in /usr/portage/net-dialup/fcpci-0.1-r1.ebuild
reingeschaut, und da steht drin
SRC_URI="http://opensuse.foehr-it.de/rpms/10_3/src/${P}-0.src.rpm"
Vielleicht genügt es ja, das durch
SRC_URI="http://opensuse.foehr-it.de/rpms/11_2/src/${P}-0.src.rpm"
zu ersetzen und das ganze neu zu compilieren ("emerge fcpci")?
(Allerdings muß ich dazu noch den dann nötigen "ignore checksums"-Flag
rausfinden, wenn ich von Hand in den Packagefiles rumpfusche.)
Wobei ja ein Fritztreiber direkt per Kernel-Option eigentlich eine
nettere Sache wäre. Aber *wie's* letztendlich funktioniert, ist ja
eigentlich egal, Hauptsache es geht *irgendwie* :-)
Hat jemand Tipps für mich?
Danke & Gruß Matthias.
Oliver Föhr
> Hallo,
>
> �hnliche Fragen kamen letzten Herbst hier schon mal auf; die betreffenden
> Threads versandeten dann aber immer mehr oder weniger mit der Fest-
> stellung "ISDN unter Linux ging ja noch nie so richtig gut", aber
>
> Also jedenfalls: Ich wollte meinen Linux-Kernel von 2.6.30 auf 2.6.32
> updaten (Gentoo, ist in anderen Linuxen aber vermutlich genauso).
> Habe mit der Fritzcard Anrufbeantworter und Fax- und SMS-Server laufen
> bei einem Update gen�gt, die Datei "fcpci.ko" von /lib/modules/kernel-
> <alteversion>/net nach /lib/modules/kernel-<neueversion>/net umzu-
> kopieren. lsmod zeigt derzeit (im alten Kernel 2.6.30)
>
> Module Size Used by
> capi 13504 10
> capifs 3788 2 capi
> fcpci 556128 3
> kernelcapi 34452 2 capi,fcpci
>
> Jetzt gibts bei 2.6.32 eine neue Kernelconfig CONFIG_MISDN_AVMFRITZ.
> Es ist aber egal, ob man die auf N oder Y setzt - capiinfo sagt nach
> dem Booten mit 2.6.32 immer "capi not installed" (die lsmod-Ausgabe
> einem manuellen "modprobe fcpci" die Fehlermeldung "Error inserting
> fcpci: Invalid module format". Sind 2.6.30-Module nicht mehr mit
> neue Kernel l�uft, wie bei den VirtualBox-Modulen? Mu�te man bisher
> aber auch nie.) Oder braucht man fcpci gar nicht mehr, wenn das jetzt
> im Kernel ist? Aber capiinit/capiinfo funktioniert ja auch dann nicht,
> wenn fcpci gar nicht geladen ist.
>
> Leider kann ich nicht allzuviel herumprobieren (also z.B. 27mal neu
> booten und dabei immer neue Konfigurationen ausprobieren), weil das
> eigentlich ein 24/7-Server ist, bei dem die Nutzer schon bei kurzer
> Null deutlich verschiedene Wahrscheinlichkeit besitzen, nach dem
> Reboot zu funktionieren :-)
>
> Inzwischen habe ich noch in /usr/portage/net-dialup/fcpci-0.1-r1.ebuild
> reingeschaut, und da steht drin
> SRC_URI="http://opensuse.foehr-it.de/rpms/10_3/src/${P}-0.src.rpm"
http://opensuse.foehr-it.de/rpms/11_2/src/fcpci-0.1-0.src.rpm
Pack mal das aus und compilier mal mit allen enthaltenen Patches und poste hier
mal die Fehlermeldung beim make Befehl. Das fcpci.ko Modul zu kopieren klappt
nicht immer.
Ich habe bisher noch keine Module f�r den neuen Kernel bei mir �bersetzt, denn
die SuSE 11.3 kommt erst sp�ter.
olly
--
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
Matthias Hanft
>
> http://opensuse.foehr-it.de/rpms/11_2/src/fcpci-0.1-0.src.rpm
>
> Pack mal das aus und compilier mal mit allen enthaltenen Patches und poste hier
> mal die Fehlermeldung beim make Befehl. Das fcpci.ko Modul zu kopieren klappt
> nicht immer.
Ich hab mir jetzt mal den Gentoo-Ebuild in ein lokales Overlay (mit neuer
Versionsnummer 112) umkopiert und die URI des RPMs von 10_3 in 11_2 geändert,
das sollte eigentlich reichen, um das aktuelle RPM einzubinden.
Die relevanten Fehlerstellen beim compile sind vermutlich die hier:
--- schnipp ---
make -C /usr/src/linux M=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src modules
make[1]: Entering directory `/usr/src/linux-2.6.32-gentoo-r7'
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/main.o
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.o
In file included from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/queue.h:27,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tables.h:31,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.h:30,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.c:29:
/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.h:75: error: conflicting types for
'atomic_xchg'
/usr/src/linux-2.6.32-gentoo-r7/arch/x86/include/asm/atomic_32.h:215: error: previous definition of
'atomic_xchg' was here
In file included from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/queue.h:27,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tables.h:31,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.h:30,
from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/main.c:44:
/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.h:75: error: conflicting types for
'atomic_xchg'
/usr/src/linux-2.6.32-gentoo-r7/arch/x86/include/asm/atomic_32.h:215: error: previous definition of
'atomic_xchg' was here
make[2]: *** [/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.o] Error 1
--- schnapp ---
Sagt Dir das was?
> Ich habe bisher noch keine Module für den neuen Kernel bei mir übersetzt, denn
> die SuSE 11.3 kommt erst später.
Gibts eigentlich irgendwo eine Vergleichstabelle "Suse a.b = Kernel x.y.z"?
Gruß Matthias.
Manfred Schmitt
>
> Jetzt gibts bei 2.6.32 eine neue Kernelconfig CONFIG_MISDN_AVMFRITZ.
> Es ist aber egal, ob man die auf N oder Y setzt - capiinfo sagt nach
> dem Booten mit 2.6.32 immer "capi not installed" (die lsmod-Ausgabe
> habe ich leider nicht aufgeschrieben). Jedenfalls erhält man bei
> einem manuellen "modprobe fcpci" die Fehlermeldung "Error inserting
> fcpci: Invalid module format". Sind 2.6.30-Module nicht mehr mit
> 2.6.32 kompatibel?! (Oder muß man fcpci neu compilieren, wenn der
> neue Kernel läuft, wie bei den VirtualBox-Modulen? Mußte man bisher
> aber auch nie.) Oder braucht man fcpci gar nicht mehr, wenn das jetzt
> im Kernel ist? Aber capiinit/capiinfo funktioniert ja auch dann nicht,
> wenn fcpci gar nicht geladen ist.
>
Ob dann die Capi funktioniert weiss ich nicht da ich meine Fritzcard
PCI kurz bevor das neue Modul, nach all den Jahren, im kernel landete
ausgemustert hab ;-/
Aber imo sollte avmfritz ja mit der kernel-capi zusammenlaufen, ansonsten
waere es ja witzlos?
Auf alle Faelle will man endweder fcpci (wenn das denn mit neuen, avmfritz
kerneln wirklich noch zum laufen zu kriegen ist) oder avmfritz, beides
zusammen duerfte nicht funktionieren, eine Hardware, ein Treiber.
Und wech,
Manne
Tilman Schmidt
> Die relevanten Fehlerstellen beim compile sind vermutlich die hier:
>
> --- schnipp ---
>
> make -C /usr/src/linux M=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src modules
> make[1]: Entering directory `/usr/src/linux-2.6.32-gentoo-r7'
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/main.o
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.o
> In file included from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/queue.h:27,
> from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tables.h:31,
> from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.h:30,
> from /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.c:29:
> /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.h:75: error: conflicting types for
> 'atomic_xchg'
> /usr/src/linux-2.6.32-gentoo-r7/arch/x86/include/asm/atomic_32.h:215: error: previous definition of
> 'atomic_xchg' was here
Ja, bekannt. Abhilfe bringt dieser Patch:
--- fritz.orig/src/tools.h 2005-07-07 00:00:00.000000000 +0200
+++ fritz/src/tools.h 2010-04-01 23:16:03.044017700 +0200
@@ -71,15 +71,6 @@ extern void vlprintf (const char *, cons
/*---------------------------------------------------------------------------*\
\*---------------------------------------------------------------------------*/
-static inline unsigned long atomic_xchg (
- volatile atomic_t * v,
- unsigned value
-) {
- return __xchg (value, &v->counter, sizeof (unsigned));
-} /* atomic_xchg */
-
-/*---------------------------------------------------------------------------*\
-\*---------------------------------------------------------------------------*/
#ifndef NDEBUG
extern unsigned hallocated (void);
extern int hvalid (void *);
Also einfach die Definition für atomic_xchg() rauswerfen, diese Funktion hat
der Kernel seit Release 2.6.32 auch für 32 bit Architektur selber definiert.
>> Ich habe bisher noch keine Module für den neuen Kernel bei mir übersetzt, denn
>> die SuSE 11.3 kommt erst später.
>
> Gibts eigentlich irgendwo eine Vergleichstabelle "Suse a.b = Kernel x.y.z"?
Meines Wissens nicht. Würde ich mir auch wünschen. Bisher suche ich das jedesmal
in den Release Notes oder auf irgendeiner Maschine, die mit der fraglichen
Suse-Version läuft.
openSUSE 11.2 hat jedenfalls Kernel 2.6.31.12. Der Kernel von openSUSE 11.3 liegt
wohl noch nicht definitiv fest. Milestone 4 hatte 2.6.33.
HTH
T.
Matthias Hanft
>
> Ja, bekannt. Abhilfe bringt dieser Patch: [...]
> Also einfach die Definition für atomic_xchg() rauswerfen, diese Funktion hat
> der Kernel seit Release 2.6.32 auch für 32 bit Architektur selber definiert.
Ja, das hatte ich inzwischen auch schon herausgefunden, konnte allerdings
mangels hinreichender C-Kenntnisse nicht auf den ersten Blick beurteilen,
ob die beiden Funktionsdeklarationen "vollkompatibel" sind (zumindest rein
optisch sehen die ja völlig unterschiedlich aus).
Habs mal rausgemacht, dann passiert aber immer noch das hier:
* Preparing fcpci module
make -j3 HOSTCC=i486-pc-linux-gnu-gcc CROSS_COMPILE=i486-pc-linux-gnu- LDFLAGS= KDIR=/usr/src/linux
LIBDIR=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src all
make -C /usr/src/linux M=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src modules
make[1]: Entering directory `/usr/src/linux-2.6.32-gentoo-r7'
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/main.o
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o
CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.o
/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c: In function 'reset_ctrl':
/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c:572: error: implicit declaration
of function 'capi_ctr_reseted'
make[2]: *** [/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o] Error 1
Zumindest im src-Verzeichnis ist das anscheinend die einzige Stelle, wo
"capi_ctr_reseted" vorkommt...
Gruß Matthias.
Matthias Hanft
>
> /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c: In function 'reset_ctrl':
> /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c:572: error: implicit declaration
> of function 'capi_ctr_reseted'
> make[2]: *** [/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o] Error 1
Wenn man "capi_ctr_reseted" auskommentiert, gehts (jedenfalls kommt nachher
ohne Fehlermeldung ein "fcpci.ko" raus; obs dann auch läuft, habe ich noch
nicht probiert). Allerdings kann ich jetzt nicht beurteilen, ob das eine
lebenswichtige Funktion gewesen wäre :-)
Gruß Matthias.
Oliver Föhr
> /usr/src/linux-2.6.32-gentoo-r7/arch/x86/include/asm/atomic_32.h:215: error: previous definition of
> 'atomic_xchg' was here
>
Du musst auch *alle* Patches aus meinem RPM anwenden auf den Quellcode los
lassen sonst gibt das bruch.
olly
Matthias Hanft
>
> Du musst auch *alle* Patches aus meinem RPM anwenden auf den Quellcode los
> lassen sonst gibt das bruch.
Uff, ich fürchte, das manuelle Anwenden von Patches übersteigt dann doch
meine linuxtechnischen Kenntnisse :-(
Hatte "einfach" die bisherige Gentoo-.ebuild-Datei dazu hergenommen, da
sieht der entsprechende Abschnitt wie folgt aus:
--- schnipp ---
src_unpack() {
local BIT="" PAT="01234"
if use amd64; then
BIT="64bit-" PAT="1234"
fi
rpm_unpack "${DISTDIR}/${A}" || die "failed to unpack ${A} file"
DISTDIR="${WORKDIR}" unpack ${PN}-suse[0-9][0-9]-${BIT}[0-9].[0-9]*-[0-9]*.tar.gz
cd "${S}"
epatch $(sed -n "s|^Patch[${PAT}]:\s*\(.*\)|../\1|p" ../${PN}.spec)
convert_to_m src/Makefile
for i in lib/*-lib.o; do
einfo "Localize symbols in ${i##*/} ..."
objcopy -L memcmp -L memcpy -L memmove -L memset -L strcat \
-L strcmp -L strcpy -L strlen -L strncmp -L strncpy "${i}"
done
}
--- schnapp ---
und wenn das läuft (mit "ebuild fcpci... unpack"), kommt folgende Ausgabe raus:
--- schnipp ---
[...]
>>> Unpacking source...
>>> Unpacking /var/tmp/portage/net-dialup/fcpci-0.1-r112/distdir/fcpci-0.1-0.src.rpm to
/var/tmp/portage/net-dialup/fcpci-0.1-r112/work
* QA: do not use ${DISTDIR} with rpm_unpack -- it is added for you
>>> Unpacking fcpci-suse93-3.11-07.tar.gz to /var/tmp/portage/net-dialup/fcpci-0.1-r112/work
* Applying fritz-tools.diff ... [ ok ]
* Applying fritz-config.diff ... [ ok ]
* Applying fritz_pci.diff ... [ ok ]
* Applying fritz_irq.diff ... [ ok ]
* Applying fritz_driver_init.diff ... [ ok ]
* Converting src/Makefile to use M= instead of SUBDIRS= ... [ ok ]
* Localize symbols in fcpci-lib.o ...
>>> Source unpacked in /var/tmp/portage/net-dialup/fcpci-0.1-r112/work
[...]
--- schnapp ---
Aber Du hast recht, ich sehe gerade, daß, wenn man das rpm zu einem tar umwandelt,
noch weitere .diff drin sind, z.B. auch "ctr_reset.diff", was vermutlich das letzte
geschilderte Problem behebt. Fragt sich, warum beim "unpack" nur diffs angewendet
werden, die mit "fritz" beginnen?! Muß wohl an diesem "epatch"-Befehl liegen, aber
dazu verstehe ich zu wenig von eBuilds...
Moment... da oben steht ja PAT="01234", das bedeutet vielleicht, daß nur die Patches
0 bis 4 laufen sollen... ich schreib da mal eben PAT="01234567" rein, weil in fcpci.spec
ja die Patches Nr. 0 bis 7 drin sind... nee... wird nicht mehr :-(
Von Hand auf der Befehlszeile wirds von sed aber erkannt:
gentoo files # sed -n "s|^Patch["01234567"]:\s*\(.*\)|../\1|p" fcpci.spec
../fritz-tools.diff
../fritz-config.diff
../fritz_pci.diff
../fritz_irq.diff
../fritz_driver_init.diff
../tools2.diff
../ctr_reset.diff
../strncpy.diff
Ahhh... ich sehe gerade, in /var/tmp/portage/net-dialup/fcpci-0.1-r112/work
wurden die unteren drei .diffs gar nicht entpackt, dann kann er sie natürlich
auch nicht anwenden :-)
Aber *warum* das so ist... das muß ich noch näher untersuchen. Verdächtig ist
ja, daß nur Patches entpackt werden, die mit "fritz" beginnen, aber dafür sehe
ich jetzt auf die Schnelle eigentlich keinen Grund... ah... in dem entpackten
fcpci.spec stehen auch nur die Patches 0 bis 4 drin. Ich vermute, das ist ein
rpm-Dateinamenkonflikt. Ich habe zwar in die .ebuild-Datei geschrieben
SRC_URI="http://opensuse.foehr-it.de/rpms/11_2/src/fcpci-0.1-0.src.rpm"
(statt .../10_3/...), aber da ja alle anderen Versionen auch diesen rpm-
Dateinamen haben, nimmt er da vermutlich irgendeine alte (gleichnamige)
rpm-Datei aus einem Portage-Cache, wo nur die Patches 0 bis 4 drin sind :-(
Entweder ich finde diesen Cache (und seine Config), oder ich lege das 11_2.rpm
einfach unter einem anderen Dateinamen auf einen internen HTTP-Server (z.B.
"localhost") und lasse die URI da drauf zeigen, dann sollte das eigentlich
behoben sein. Aber jetzt muß ich erst mal rasenmähen :-)
Danke jedenfalls für den Tip mit den Patches, das ist auf jeden Fall die Ursache.
Melde mich dann nochmal, wenn ichs probiert habe...
Gruß Matthias.
Matthias Hanft
>
> oder ich lege das 11_2.rpm
> einfach unter einem anderen Dateinamen auf einen internen HTTP-Server (z.B.
> "localhost") und lasse die URI da drauf zeigen, dann sollte das eigentlich
> behoben sein.
Ist es. Alle Patches wurden bearbeitet, und das Compilieren lief ohne
Fehlermeldungen durch. Danke.
Obs dann wirklich funktioniert, probiere ich Sonntagmorgen (da sind grad
die wenigsten Kunden auf dem Server).
Gruß Matthias.
Oliver Föhr
Wäre für Rückmeldung dankbar. Denn die neue SuSE kommt ja auch noch und da will
ich vorher schon wissen ob es läuft. Dann baue ich wieder RPMs.
Tilman Schmidt
> Habs mal rausgemacht, dann passiert aber immer noch das hier:
>
> * Preparing fcpci module
> make -j3 HOSTCC=i486-pc-linux-gnu-gcc CROSS_COMPILE=i486-pc-linux-gnu- LDFLAGS= KDIR=/usr/src/linux
> LIBDIR=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src all
> make -C /usr/src/linux M=/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src modules
> make[1]: Entering directory `/usr/src/linux-2.6.32-gentoo-r7'
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/main.o
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o
> CC [M] /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/tools.o
> /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c: In function 'reset_ctrl':
> /var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.c:572: error: implicit declaration
> of function 'capi_ctr_reseted'
> make[2]: *** [/var/tmp/portage/net-dialup/fcpci-0.1-r112/work/fritz/src/driver.o] Error 1
>
> Zumindest im src-Verzeichnis ist das anscheinend die einzige Stelle, wo
> "capi_ctr_reseted" vorkommt...
Der grausliche Funktionsname capi_ctr_reseted ist seit Kernel Release 2.6.31
in capi_ctr_down umbenannt[1]. Also einfach s/reseted/down/.
HTH
Tilman
[1] Daran bin übrigens ich schuld. :-) Siehe
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4e329972052c3649367b91de783f6293b8653cb2
Tilman Schmidt
> Wenn man "capi_ctr_reseted" auskommentiert, gehts (jedenfalls kommt nachher
> ohne Fehlermeldung ein "fcpci.ko" raus; obs dann auch läuft, habe ich noch
> nicht probiert). Allerdings kann ich jetzt nicht beurteilen, ob das eine
> lebenswichtige Funktion gewesen wäre :-)
Spielt eigentlich nur bei "capiinit stop" eine Rolle. Das wird dann
wahrscheinlich einfach hängenbleiben, weil die Rückmeldung vom Treiber
nicht kommt.
HTH
T.
Matthias Hanft
>
> Der grausliche Funktionsname capi_ctr_reseted ist seit Kernel Release 2.6.31
> in capi_ctr_down umbenannt[1]. Also einfach s/reseted/down/.
Danke, es hat jetzt aber auch mit den "offziellen" Patches geklappt (siehe
Teil-Thread mit Oliver Föhr). Außerdem habe ich dabei viel dazugelernt
bezüglich Gentoo-Ebuilds und Patches :-) (dazu Parallel-Thead in news:ger.ct)
Gruß Matthias.
Matthias Hanft
>
> Wäre für Rückmeldung dankbar. Denn die neue SuSE kommt ja auch noch und da will
> ich vorher schon wissen ob es läuft. Dann baue ich wieder RPMs.
Ja, gerne. Auf meinem virtuellen Herumspiel-Gentoo hat "modprobe fcpci"
mit Kernel 2.6.32 zumindest schon mal funktioniert - so weit war ich
noch nie :-)
Und wenn sichs laden läßt, läufts vermutlich auch. Aber ich melde mich
dann übermorgen nochmal.
Gruß Matthias.
Matthias Hanft
>
> Wäre für Rückmeldung dankbar. Denn die neue SuSE kommt ja auch noch und da will
> ich vorher schon wissen ob es läuft. Dann baue ich wieder RPMs.
So, fertig. Funktioniert perfekt :-) Danke nochmal für die Hilfe!
Gruß Matthias.
Margrit Abend
> Also einfach die Definition für atomic_xchg() rauswerfen, diese Funktion
> hat der Kernel seit Release 2.6.32 auch für 32 bit Architektur selber
> definiert.
Gilt das auch für den Kernel 2.6.31.12-0.2-default denn ich bokomme dort
auch exact den gleichen Fehler bei einem rebuild.
Matthias Hanft
>
> Gilt das auch für den Kernel 2.6.31.12-0.2-default denn ich bokomme dort
> auch exact den gleichen Fehler bei einem rebuild.
IIRC ja (ich bin zwar von 2.6.30 direkt auf 2.6.32 gegangen, glaube mich
aber erinnern zu können, daß diese Definition sich ab 2.6.31 geändert hat).
Gruß Matthias.
Margrit Abend
Matthias Hanft wrote:
> IIRC ja (ich bin zwar von 2.6.30 direkt auf 2.6.32 gegangen, glaube mich
> aber erinnern zu können, daß diese Definition sich ab 2.6.31 geändert
> hat).
>
> Gruß Matthias.
Ich bin leider zu doof für linux, vielleicht will mit hier jemand helfen und
darum schreibe ich mal was ich gemacht habe.
Ich habe keine Erfahrung mit "patch" und so ist es mir nicht gelungen die
Dateien von Oliver auf der Shell ohne Fehler zu patchen, genauer es ist mir
überhaupt nicht gelungen zu patchen. Allerdings scheint ein rebuild genau
das ohne Probleme bis auf das beschriebene zu tun.
Also habe ich mir gedacht folgendes zu machen:
1. rm fcdsl2-0.1-0.src.rpm && cp /fcdsl2-0.1-0.src.rpm
/usr/src/packages/SRPMS && rpm -i fcdsl2-0.1-0.src.rpm && rm
fcdsl2-0.1-0.src.rpm
2. cd /usr/src/packages/SOURCES
3. vi fritz-tools.diff
4. rpmbuild -bs fcdsl2.spec
5. rpmbuild --rebuild fcdsl2-0.1-0.src.rpm
Doch ganz gleich welche Zeilen ich deaktiviere, er liefert mit immer:
/usr/bin/patch: **** malformed patch at line blabla...
Selbst wenn ich nur die Leerzeile wie unten deaktiviere liefert er mir
/usr/bin/patch: **** malformed patch at line 19., deaktiviere ich die Zeilen
wie Du angegeben hast liefert er mir: /usr/bin/patch: **** malformed patch
at line 18. /*---------- gekürzt ------------*\.
Ich bin zu blöd für patch und darum bitte ich mir bei der Fehler Analyse zu
helfen. Kann doch nicht sein das jeder hier ständig irgend etwas patcht und
ich bei einfachsten Sachen versage heul...
Hier mal meine diff:
*** schnipp ***
diff -ur fritz/src/tools.h fritz.new/src/tools.h
--- fritz/src/tools.h 2005-07-07 00:00:00.000000000 +0200
+++ fritz.new/src/tools.h 2006-01-26 17:29:53.000000000 +0100
@@ -71,13 +71,14 @@
-
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
+#ifndef atomic_xchg
static inline unsigned long atomic_xchg (
volatile atomic_t * v,
unsigned value
) {
return __xchg (value, &v->counter, sizeof (unsigned));
} /* atomic_xchg */
-
+#endif
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
#ifndef NDEBUG
*** schnapp ***
Mein Kernel:
2.6.31.12-0.2-default
lspci:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and
Memory Controller Hub (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82815 Chipset Graphics
Controller (CGC) (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 05)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 05)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev
05)
00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev
05)
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 05)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev
05)
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97
Audio Controller (rev 05)
01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet
Controller (rev 03)
01:09.0 Network controller: AVM GmbH Fritz!Card DSL v2.0 (rev 02)
Da ^^^^^ um das letzte Ding geht es mir, das will ich unbedingt wieder
haben. seufz, schon zwei Tage quäle ich mich jetzt...
Margrit Abend
PS.
Ich verstehe die Bedenken der Kernel Entwickler und daher habe ich nichts an
Oliver zu meckern dessen Arbeit ich immer ungefragt nutzte und nun darauf
verzichten muss. Ich bin ja bereit mich selbst zu quälen und ggf. auch
Dokumentation zu wälzen aber hat mal jemand versucht über diesen Fehler bei
Google etwas zu finden das ich nachvollziehen und anwenden kann?.
Ich mach sonst alles selbst doch für eine Karte ohne Alternative ein
Informatik Studium zu absolvieren geht über meine Kräfte, am liebsten wäre
mir der Oliver macht irgendwie weiter... :-).
Sorry und thx an Oliver, danke Matthias
Matthias Hanft
>
> Ich bin leider zu doof für linux, vielleicht will mit hier jemand helfen und
> darum schreibe ich mal was ich gemacht habe.
> Ich habe keine Erfahrung mit "patch" und so ist es mir nicht gelungen die
> Dateien von Oliver auf der Shell ohne Fehler zu patchen, genauer es ist mir
> überhaupt nicht gelungen zu patchen. Allerdings scheint ein rebuild genau
> das ohne Probleme bis auf das beschriebene zu tun.
Leider kann ich hier auch nicht helfen, weil ich fürs Patchen genauso doof
bin wie Du :-) Ich habs lediglich geschafft, ein Gentoo-Linux-"ebuild" (so
heißen da die "Paketsteuerungsdateien") geeignet zu verändern, damit die
neueste Version inkl. allen Patches geladen wurde. Im Prinzip mußte ich
dabei folgendes ändern (für fcpci):
SRC_URI="http://opensuse.foehr-it.de/rpms/11_2/src/fcpci-0.1-0.src.rpm"
also die Adresse, wo's runtergeladen werden soll
und dann gibts da einen Abschnitt
src_unpack() {
local BIT="" PAT="01234567"
if use amd64; then
BIT="64bit-" PAT="1234567"
fi
Die Ziffern geben die Patches an; ursprünglich stand dort glaub ich nur
"012345" (also Patches 0 bis 5), das mußte ich dann noch um "67" erweitern,
damit auch Patches 6 bis 7 angewandt wurden.
Von "patch" und "rpmbuild" etc. hab' ich allerdings leider auch keine Ahnung.
Gibt's bei Dir nicht auch irgendwo so "Paketsteuerungsdateien", wo Du einfach
die paar kleinen Änderungen reinhacken kannst und dann den Rest dem Paket-
verwaltungssystem überläßt?
Gruß Matthias.
Margrit Abend
Matthias Hanft wrote:
Ja, gibt es. Bei mir wäre das die fcdsl2.spec.
Damit kann dann z.B. "rpmbuild" Pakete bauen oder neu bauen doch das ist ja
leider wahrscheinlich nicht mein Problem. Der relevante Abschnitt sieht dann
bei mir so aus:
Patch0: fritz-tools.diff
Patch1: fritz-config.diff
Patch2: fritz_pci.diff
Patch3: fritz_irq.diff
Patch4: fritz_driver_init.diff
Patch5: common.diff
Patch6: mutex.diff
Patch7: task_pid.diff
und dann noch:
%prep
%ifarch x86_64
%setup -n fritz -T -b 1
%patch1 -p1
%patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1
%patch6 -p1
#%patch7 -p1
%else
%setup -n fritz -T -b 0
%patch0 -p1
%patch1 -p1
%patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1
%patch6 -p1
%patch7 -p1
Ich versuche das je schon wie ein Dummie den Paketbuilder machen zu lassen,
ohne Erfolg. Mittlerweile packe ich den Krempel schon aus und versuche es zu
Fuss, etwa so:
#!/bin/bash
datei=fcdsl2-0.1-0.src.rpm
pcks=/usr/src/packages
url=http://opensuse.foehr-it.de/rpms/11_1/src
case $1 in
inst)
find $pcks -type f -exec rm '{}' \;
cd $pcks/SRPMS
wget $url/$datei
rpm -i $datei
;;
copy)
rm -rf $pcks/SOURCES/*
cp -f /$datei $pcks/SRPMS
rpm -i $pcks/SRPMS/$datei
rm $pcks/SRPMS/$datei
cd $pcks/SOURCES
tar xfvz fcdsl2-suse93-3.11-07.tar.gz
cp $pcks/SOURCES/*.diff $pcks/SOURCES/fritz
cp -f /fritz-tools.diff $pcks/SOURCES/fritz
;;
patch)
cd $pcks/SOURCES/fritz
for i in $(ls *.diff)
do /usr/bin/patch -s -p1 --fuzz=2 -i $i
done
;;
*)
echo "Blah..."
;;
esac
damit ich nicht immer alles tausend mal tippen muss.
Mein Problem ist scheinbar die tools.diff selbst. Ich kann Sie editieren wie
ich will, hoch, runter, striche rein, striche raus etc. etc. bla bla.
Es gelingt mir weder mit dem "rpmbuild" noch von Hand dieses Ding zu
patchen.
Das Einzige was mir hervorragend gelingt ist Fehlermeldungen wie diese:
/usr/bin/patch: **** malformed patch at line 19: -extern int hvalid (void
*);
zu produzieren wobei alles was nach "at" kommt in jeder beliebigen
Kombination reproduzierbar ist. Mal hat er kein "End of Line" und mal sind
Ihm die Komentare im Weg. Ich weiß eben nicht genau wie patch arbeitet und
kenne nur seine Optionen, dafür gibt es ja Man-Pages :-).
Der Code der Patches selbst ist für mich sowieso tabu, bin eben kein
Programmierer... doch ich habe es mit "vi" und auch anderen Editoren
versucht, keine störenden Zeichen etc. gefunden.
Er nimmt meine editierten Patches einfach nicht... :-).
Sobald ich die tools.diff anfasse ist essig.
Ach, ich verlier langsam die Geduld... jetzt schon über 5 Stunden daran
vergeudet... ach...
Margrit Abend
Matthias Hanft wrote:
Ach so ja, falls dasbei Dir anders organisiert ist.
Der relevante Abschnitt welche den oben beschriebenen Fehler produziert ist
bei mir in der "tools.h":
*** schnipp ***
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
static inline unsigned long atomic_xchg (
volatile atomic_t * v,
unsigned value
) {
return __xchg (value, &v->counter, sizeof (unsigned));
} /* atomic_xchg */
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
*** schnapp ***
Die Patch Datei dafür dürfte die "fritz-tools.diff" alis Patch0 sein:
*** schnipp ***
diff -ur fritz/src/tools.h fritz.new/src/tools.h
--- fritz/src/tools.h 2005-07-07 00:00:00.000000000 +0200
+++ fritz.new/src/tools.h 2006-01-26 17:29:53.000000000 +0100
@@ -71,13 +71,14 @@
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
+#ifndef atomic_xchg
static inline unsigned long atomic_xchg (
volatile atomic_t * v,
unsigned value
) {
return __xchg (value, &v->counter, sizeof (unsigned));
} /* atomic_xchg */
-
+#endif
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
#ifndef NDEBUG
*** schnapp ***
Die Empfehlung von Tilman lautet:
*** schnipp ***
--- fritz.orig/src/tools.h 2005-07-07 00:00:00.000000000 +0200
+++ fritz/src/tools.h 2010-04-01 23:16:03.044017700 +0200
@@ -71,15 +71,6 @@ extern void vlprintf (const char *, cons
/*---------------------------------------------------------------------------
*\
\*---------------------------------------------------------------------------
*/
-static inline unsigned long atomic_xchg (
- volatile atomic_t * v,
- unsigned value
-) {
- return __xchg (value, &v->counter, sizeof (unsigned));
-} /* atomic_xchg */
-
-/*---------------------------------------------------------------------------
*\
-\*---------------------------------------------------------------------------
*/
#ifndef NDEBUG
extern unsigned hallocated (void);
extern int hvalid (void *);
*** schnapp ***
Und das habe ich jetzt schon an die hundert mal versucht umzusetzen...
Ich bin einfach zu blöd für "patch"... sehe ich da irgend ein Zeichen nicht
oder ne dumme Leerstelle oder weis der Teufel was.
Oliver Föhr
Dumm ich kann hier den ganzen Thread nicht lesen. Wo klemmt was?
Zur not mal eben im Forum posten.