PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Treiber erstellen funktioniert nicht richtig



WhiteTiger
12.11.03, 11:19
Guten Tag

Nach x FAQ und Anleitungen habe ich es geschaft SuSE 8.2 auf Raid zu installieren. Jetzt wollte ich mir nach der Anleitung bei SuSE.de einen Highpoint treiber basteln.
http://portal.suse.de/sdb/de/2002/07/hmeyer_hpt37x.html

Leider bekomme ich beim erzeugen des Treibers mit "make" ne Latte an Warnungen. Des weiteren motzt Linux bei der Installation des Treibers rum das der Treiber für nen anderen Kernel ist d.h. der Treiber ist für Kernel 2.4.20-4GB und der Kernel der grad läuft ist 2.4.20-4GB-athlon? Habe ja nur die Kernel-Source 2.4.20.SuSE! Was mach ich falsch???
Könnte mal einer so nett sein mir etwas zu helfen bzw. etwas Nachhilfeunterricht in Linux zu geben?

Thanks @all

samy@linux:~> su
Password:
linux:/home/samy # cd Documents
linux:/home/samy/Documents # cd Treiber
linux:/home/samy/Documents/Treiber # tar xzvf hpt3xx-opensource-v131.tgz
Makefile
baseproc.s
hpt.c
hpt.h
hpt37x2lib.o
hptglb.h
hptkern.h
readme.txt
rules.mak
linux:/home/samy/Documents/Treiber # make kerneldir=/usr/src/linux-2.4.20.SuSE athlon=1
gcc -DHIGHPOINT -DDRIVER_VERSION=\"1.31\" -DMODVERSIONS -DMODULE -DLINUX -D__KERNEL__=1 -DCONFIG_PCI -D__BOOT_KERNEL_SMP=0 -D__BOOT_KERNEL_UP=1 -D__MODULE_KERNEL_i686=1 -DDPLL_SWITCH -DFORCE_133 -DDRIVER_REBUILD -DSUPPORT_ARRAY -DSUPPORT_IOCTL -DSUPPORT_ALARM -O2 -I/usr/src/linux/include -I/usr/src/linux/include/asm-i386 -I/usr/src/linux/drivers/scsi -Wall -Wstrict-prototypes -fomit-frame-pointer -c hpt.c
In file included from /usr/src/linux/include/linux/tqueue.h:19,
from /usr/src/linux/include/linux/aio.h:4,
from /usr/src/linux/include/linux/fs.h:201,
from /usr/src/linux/include/linux/capability.h:17,
from /usr/src/linux/include/linux/binfmts.h:5,
from /usr/src/linux/include/linux/sched.h:10,
from hptkern.h:33,
from hpt.c:7:
/usr/src/linux/include/asm/system.h: In function `__set_64bit_var':
/usr/src/linux/include/asm/system.h:189: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/linux/include/asm/system.h:189: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from /usr/src/linux/include/linux/blk.h:4,
from hptkern.h:34,
from hpt.c:7:
/usr/src/linux/include/linux/blkdev.h: In function `blk_queue_bounce':
/usr/src/linux/include/linux/blkdev.h:212: warning: comparison between signed and unsigned
/usr/src/linux/include/linux/blkdev.h: In function `blk_finished_io':
/usr/src/linux/include/linux/blkdev.h:348: warning: comparison between signed and unsigned
hpt.c: In function `hpt_refresh_logical_devices':
hpt.c:253: warning: comparison between signed and unsigned
hpt.c: In function `check_bad_disk':
hpt.c:787: warning: comparison between signed and unsigned
hpt.c: In function `device_rdwr':
hpt.c:2387: warning: comparison between signed and unsigned
hpt.c: In function `hpt_rescan_all_devices':
hpt.c:2833: warning: comparison between signed and unsigned
hpt.c:2837: warning: comparison between signed and unsigned
hpt.c: In function `hpt_copy_array_info':
hpt.c:2948: warning: int format, long unsigned int arg (arg 3)
hpt.c:2948: warning: int format, long unsigned int arg (arg 3)
hpt.c: In function `Irq_Handler':
hpt.c:4093: warning: comparison between signed and unsigned
hpt.c: In function `hpt3xx_init':
hpt.c:4380: warning: comparison between signed and unsigned
hpt.c: In function `hpt3xx_Release':
hpt.c:4684: warning: comparison between signed and unsigned
hpt.c: In function `hpt_set_device_on_offline':
hpt.c:4790: warning: comparison between signed and unsigned
as -o baseproc.o baseproc.s
ld -m elf_i386 -r hpt37x2lib.o hpt.o baseproc.o -o hpt37x2.o
linux:/home/samy/Documents/Treiber # insmod hpt37x2.o
hpt37x2.o: kernel-module version mismatch
hpt37x2.o was compiled for kernel version 2.4.20-4GB
while this kernel is version 2.4.20-4GB-athlon.
linux:/home/samy/Documents/Treiber #

Thomas Engelke
12.11.03, 11:25
Ersteinmal:


Des weiteren motzt Linux bei der Installation des Treibers rum das der Treiber für nen anderen Kernel ist d.h. der Treiber ist für Kernel 2.4.20-4GB und der Kernel der grad läuft ist 2.4.20-4GB-athlon?

Einfach: Ein Schutzmechanismus. Du kompilierst Kernel mit Quellenbaum A. Später möchtest du einen Treiber installieren. Für die Kompilierung braucht dieser die Kernelheaders; weil sie doch gerade da sind, nimmst du die von Quellenbaum B. Das darf nicht funktionieren. Der Kernel, den du läufst, ist mit anderen Kernel-Headers (wichtige Dateien!) (sagt man Kernel Headers oder Kernel Headern?) kompiliert worden als die, gegen den du jetzt den Treiber kompilieren magst - der jedoch mit dem aktuellen Kernel zusammenarbeiten soll. Installiere dir die Kernelquellen für deinen aktuellen Kernel. Die Version sollte 2.4.20-4GB-athlon sein. Das müßte sich in deinem Paketmanager finden lassen.

AD!

WhiteTiger
12.11.03, 15:47
Ich habe nicht einfach Quellenbaum B genommen weil er grad da war sondern weil ich keinen anderen habe (man muss erst mal wissen das nicht nur 2.4.20.. wichtig ist sondern auch alles dahinter). Habe mit dem Paketmanager alles durchsucht. Das einzige was man findet sind Kernel-Sources (2.4.20-SuSE). Ein Paket oder Source für 2.4.20-4GB-athlon Fehlanzeige. Habe noch das Paket k-athlon (Kernel für AMD) gefunden hinter dem ein Kästchen ist mit der Bezeichnung "quellen". Wenn ich es versuche zu installieren passiert nix. Die Quellen sind ja unter usr/src/.... oder?

Sorry für dumme Fragen--> bin halt Neuling!

Thomas Engelke
12.11.03, 15:50
Fakt ist, du mußt für einen reibungslosen Ablauf von Kompilierungen Kernel-Headers und den Kernel selbst auf den selben Stand bringen. Ich vermute, du traust dir keine Kernelkompilierung zu?

AD!

WhiteTiger
12.11.03, 21:19
Das beide die selbe Revision haben müssen ist mir klar. Ich habe halt nur auf die Nummer (2.4.20) geachtet und nett gewusst das das Zeug dahinter auch wichtig ist.
Mit sich nicht trauen hat das nix zu tun sondern mit dem Schönheitsfehler das der Treiber auf den Standartkernel kompiliert werden muss. Es handelt sich um einen Raid Treiber der ganz zum Anfang der Installation eingebunden werden muss da ich sonnst nett auf Platte zugreifen kann. So ich kann mir jetzt Sourcen und nen Kernel runter laden und komplimieren auf mein System, dann den Treiber erstellen --> toll dann kommt bei der Installation auf Raid da ja der Standartkernel installiert wird die schöne Fehlermeldung das der Kernel vom Treiber nett passt.
Es muss doch irgendwo Sourcen für den Standartkernel geben???

Wenn meine Aussagen falsch sind bitte um Aufklärung! Wie gesagt ich fange erst an mit Linux und hab gleich sowas am Hals.

Thomas Engelke
12.11.03, 21:25
Nunja, gerade RAID-Controller sind ja auch nicht "massenkompatibel". Sie sind kompliziert und ein Privatmann benötigt sie bei weitem nicht. Im Endeffekt gilt das Folgende: Dem Kernel ist generell egal, ob es sich dabei tatsächlich um dieselben Quellen handelt, mit denen der Kenel kompiliert wurde. Er will mindestens denselben Namen. Wenn der Kernel also linux-2.4.20-Suse-RAID-ABC heißt, dann sollte das Verzeichnis deiner Kernelquellen denselben Namen tragen also jenes, welches du als /usr/src/linux dagegen linkst). Dann kompilier' das Modul dagegen. Sollte klappen.

AD!

WhiteTiger
12.11.03, 21:37
Dat ging ja schnell. Thanks, werde ich mal testen.

Na ja ob man Raid braucht oder nett lass ich jetzt mal im Dunklen--> wenn ich es nett bräuchte hätte ich es platt gemacht und SuSE installiert ohne mich ne Woche damit zu quällen --> im Moment läuft es mit dem Treiber HPT370 der bei SuSE dabei ist um überhaupt mal ne Plattform zu haben wo man nen Treiber machen kann. Es läuft mehr schlecht wie recht weil der falsche Treiber drauf ist --> ich würde es keinem raten den HPT372 mit dem 370treiber zu betreiben.

WhiteTiger
12.11.03, 21:41
Noch ne Frage.

Hatte vor kurzem RedHat 9.0 in Betrieb. Da waren die Kernel-Sourcen für den Kernel dabei.
Werden die bei SuSE nett mitgeliefert oder liegt es an der ftp-installation bzw. bin ich zu blöde sie zu finden??
Habe mir den KOMPLETTEN Ordner 8.2 gezogen per ftp und auf ein extra Laufwerk gespeichert --> habe mal das Laufwerk durchsucht unter Win (jetzt noch komfortabler für mich) --> da ist nur ein Source Paket (2.4.20.SuSE). Zu 2.4.20-4GB-athlon findet mal null--> komisch!

Thomas Engelke
13.11.03, 07:54
Es mag dir vielleicht nicht gefallen, aber ich sag's mal trotzdem: Du ersparst dir das ganze Geraffel, wenn du "einfach" einen neuen Kernel kompilierst. Das ist nicht ganz trivial, läßt sich aber mittels der hervorragenden Tutorials im Forum sehr gut machen. Zu beachten wäre noch, daß sich in /proc/config meist die alte Kernelkonfiguration befindet und so relativ einfach abzugraben ist. Aber ich will dich nicht mit Bröckchen verwirren. Besorg' dir einen Kernelquellbaum und bau' neu. Mag vielleicht 2 Wochen dauern, bis das läuft, aber ich glaube, du hast Potential.

AD!