FastTrack TX4310 Treiber für Debian kompilieren

[Chip@Debian]

Hallo

Ich habe bis jetzt ohne Erfolg versucht den Treiber zu kompilieren. Hat das schon jemand gemacht? Wenn nein, dann würde ich noch weitere Informationen geben.

Greez Chip

[gms]

Das hat sicher schon jemand gemacht ( zumindest bis zum Kernel 2.6.17 )

Wenn nein, dann würde ich noch weitere Informationen geben.

Nur damit du nicht in das Timeout reinfällst und doch noch weitere Informationen geben mußt

[Chip@Debian]

Also, zu ein paar Infos:

Ich habe Kernel 2.6.18-4-k7. Bis jetzt habe ich nur das Modul linux-source installiert, welche Pakete brauche ich sonst noch? Ich denke ich habe alle Informationen gegeben, die ihr braucht. Wenn das nicht so ist, dann fragt mich bitte danach.

Greez Chip

[Chip@Debian]

Ich habe mir auf der Seite von Promise den Sourcecode geholt und die readme sieht folgendermassen aus:

Code: Alles auswählen

/**********************************************************************************
*   PROMISE FastTrak TX4310/579/779 Series Linux Driver Installation Guide
*
*   PROMISE Linux support team <support@promise.com.tw>   2006/03/30
***********************************************************************************/
	
How to make driver  for FastTrak & load it?

1.) Please ensure cc, the source compiler , version is above 3 by issuing Linux command :
    	# gcc -v
     If you do not install the compiler, you will not be able to built Promise driver. 
    
2.) Please ensure linux kernel source directory is "/usr/src/linux". 
	For SuSE EL9 platform, it always release its kernel source in /usr/src/linux-2.6.7-97.
		Please make a link to the appropriate directory, for example:
			# ln -s /usr/src/linux-2.6.7-97 /usr/src/linux
			
	For RHEL4 platform, it always release its kernel source in /usr/src/kernels/2.6.9-5.EL.??? which ??? means various kernel images.

3.) Setup Kernel Compile Environment
	For SuSE EL9, SuSE 10:
    		# cd /usr/src/linux/
   		# make mrproper
   		# cp arch/$(ARCH)/defconfig.??? .config
   		# Execute 'make' for a while about 5 sec. and then stop its execution. (Avoid below  make menuconfig fail...)
    		# Execute 'make menuconfig' & exit with configuration save.
    		# Execute 'make' for a while about 10 sec. and then stop its execution.
    		
    	For RHEL4:
    		DO NOTHING.
    
    	[1].  $(ARCH) means architecture, which is i386 or x86_64.
    	[2]. ??? is options to make choose, default, smp and bigmem, depend on your booting image.
    	 
4.) Check /lib/modules/$(UTS_RELEASE)/build directy was linked properly to /usr/src/linux. 
     UTS_RELEASE is the current version of your booting image. You can get it by issuing Linux command :
    	 #uname -r

5.) Goto directory where the PROMISE driver source was located.

5.) Issue Linux command to make FastTrak driver: ftsata2.o
	#make clean
    	#make or #make all

6.) Load PROMISE driver
	# modprobe -a sd_mod
	# insmod ftsata2.ko or # insmod ftsata2.o
	
7.) You can copy this module to /lib/modules/$(UTS_VERSION)/kernel/drivers/scsi/ for automatic load when boot system.
    
Note:
	1. Promise partial source can be adapted on kernel 2.4 & 2.6. 
	2. Different OS may has different kernel source location, please  do some modifications of above steps to fit their requirements.

Ich habe den Kernel von http://www.kernel.org geholt, gcc und die benötigten libraries installiert. Die Anleitung habe ich bis zum 3. Schritt vollkommen verstanden und auch ausgeführt. Bei Punkt 3 muss man unter SuSE einiges machen und ich weiss nicht, was da gemacht wird und auch nicht ob und wie das unter Debian gemacht werden muss. Kann mir das jemand erklären? Ich wäre sehr froh, wenn ich den Raidkontroller endlich in den Betrieb nehmen könnte.

Greez Chip

[gms]

kommt mir zwar reichlich sinnlos vor, was da bei Punkt 3 für SuSE empfohlen wird, aber das gleiche kannst du auch unter Debian machen
Ich würde an deiner Stelle den 2.6.18er Kernel nehmen:

Punkt 1-2 geht dann so:

Code: Alles auswählen

apt-get install linux-source-2.6.18
cd /usr/src
tar -xjvf linux-source-2.6.18.tar.bz2
rm linux
ln -s /usr/src/linux-source-2.6.18 /usr/src/linux

Die Gründe warum du den 2.6.18er Kernel nehmen solltest:
a) du brauchst nicht auch noch zusätzlich einen eigenen Kernel zu bauen
b) die Kernel Sourcen sind ( vorallem was SATA/PATA anbelangt ) großen Veränderungen unterworfen, nachdem dieses Readme die Erstellung unter Kernel 2.6.7 beschreibt, befürchte ich faßt, daß sich dieser Treiber ohne weitere Eingriffe nicht einmal unter 2.6.18 erstellen läßt. Wenn sich der Treiber anstandslos unter 2.6.21 bauen läßt, wäre ich gänzlich überrascht.

Gruß
gms

[Chip@Debian]

Hallo

Ich habe den 2.6.18-4 Kernel von http://www.kernel.org genommen, da ich diesen Kernel auch "installiert" habe. Was wird den genau bei Punkt 3 gemacht und wieso braucht man das unter Red Hat nicht zu machen? Du meinst also, ich kann unter Debian den Punkt 3 genauso durchführen, wie es für SuSE beschrieben ist?

Danke für die Antwort und Gruss

Chip

[gms]

Was wird den genau bei Punkt 3 gemacht und wieso braucht man das unter Red Hat nicht zu machen?

Ich fange lieber erst bei Red Hat an. Dort sind die Kernelsourcen ( in /usr/src/kernel/2.6... ) schon mit der korrekten ".config" eingerichtet. Daher mit der gleichen ".config" mit der auch der installierte Kernel erstellt wurde

Das gleiche könnte man sicherlich auch unter SuSE erreichen, indem man die config mit der der Kernel gebaut wurde ( wenn ich mich recht entsinne, liegt der bei SuSE im /proc Verzeichnis, ist aber schon lange her, daß ich ein SuSE verwendet habe ), in das Kernelsource-Verzeichnis als ".config" kopiert und dann ein "make oldconfig" aufruft.
Aus welchem Grund auch immer, wird der SuSE Kernel jedoch mit eine Default-Config konfiguriert, ich halte das jedenfalls für einen groben Pfusch, oder zumindest für einen "dirty hack".
Sehe gerade, daß es bei den Debian- und Vanilla-Sourcen unter "arch/$(ARCH)/" kein "defconfig.???" gibt, sondern nur ein "defconfig".
Daher habe ich jetzt doch noch einen Änderungsvorschlag:
statt

Code: Alles auswählen

cp arch/$(ARCH)/defconfig.??? .config

kopiere die config mit der du den Kernel erstellt hast, wenn du diesen nach Debianart gebaut hast, also

Code: Alles auswählen

cp /boot/config-`uname -r` .config

wünsche viel Erfolg
gms

[Chip@Debian]

Hallo

Ich glaube,du hast mich falsch verstanden. Ich habe keinen Kernel gemacht. Ich habe einfach den 2.6.18.4-Kernel genommen, weil mein System diesen Kernel hat und diesen habe ich nicht selber kompiliert. Kann dennoch nach der Art, wie du sie beschrieben hast die .config ändern?

Gruss Chip

[gms]

jetzt verstehe ich, du hast den Debiankernel 2.6.18-4-k7 und hast dir aber die Sourcen für den 2.6.18.4 von kernel.org geholt. Dazu ist eigentlich zu sagen, daß das nicht die gleichen Sourcen sind, mit denen dein Debiankernel gebaut wurde. Korrekterweise solltest du eigentlich folgendes machen:

Code: Alles auswählen

apt-get install linux-source-2.6.18 
cd /usr/src 
rm -rf linux-source-2.6.18
tar -xjvf linux-source-2.6.18.tar.bz2 
rm linux 
ln -s /usr/src/linux-source-2.6.18 /usr/src/linux
cd /usr/src/linux/
cp /boot/config-2.6.18-4-k7 .config
make oldconfig

und nachdem es schon im Readme gewünscht wird, lassen wir nachher für kurze Zeit auch noch ein "make" laufen.

[Chip@Debian]

Hallo

Nachdem ich make oldconfig ausgeführt habe, muss ich dann noch make, danach make menuconfig und zum Schluss nochmals make ausführen? Es heisst man müsse nach ca. 5 s stoppen, wie ist das gemeint? Was muss ich bei Punkt 4 genau machen? Ich habe make clean im Treiberverzeichnis ausgeführt und es kamen Meldungen, das /lib/modules/2.6.18-4-k7/bould// .config konte nicht gefunden werden. Ich denke, das liegt bei Punkt 4.

Gruss Chip

[gms]

Nachdem ich make oldconfig ausgeführt habe, muss ich dann noch make, danach make menuconfig und zum Schluss nochmals make ausführen?

aus der Sicht der Kernelsourcen macht "make oldconfig" und "make menuconfig" das Gleiche. Beide erstellen eine aktuelle ".config" im Souceverzeichnis, es wird nur ein anderes Userinterface verwendet.

Es heisst man müsse nach ca. 5 s stoppen, wie ist das gemeint?

mit Strg-C kannst du einen (Fordergrund) Prozeß stoppen

Was muss ich bei Punkt 4 genau machen?

die ersten beiden Kommandos dürfen einen Fehler liefern, die letzten beiden Kommandos sollten fehlerfrei durchgehen:

Code: Alles auswählen

rm /usr/src/linux
rm /lib/modules/`uname -r`/build
ln -s /usr/src/linux-source-2.6.18 /usr/src/linux
ln -s /usr/src/linux /lib/modules/`uname -r`/build

Ich habe make clean im Treiberverzeichnis ausgeführt und es kamen Meldungen, das /lib/modules/2.6.18-4-k7/bould// .config konte nicht gefunden werden. Ich denke, das liegt bei Punkt 4.
[/code]
ja

Gruß
gms

[Chip@Debian]

Hallo

Ich bin schon ein bischen weitergekommen. Wenn ich nun im Treiberverzeichnis make ausführe, dann kommen diese Meldungen:

Code: Alles auswählen

Server:/daten/tx4310_partial# make
/bin/sh: line 0: [: -lt: unary operator expected
kernel version:
make  CFLAG="-O2 -DASIC_OEM -DOCTOPUSII -O2 -fomit-frame-pointer -D_LINUXDRIVER                                                                              -D__KERNEL__ -DMODULE -D__linux__ -Wall -Wstrict-prototypes -fno-strict-aliasing                                                                              -fno-common -Wno-unused -pipe -DASIC_OEM -D_X8632B -D_32BPLATFORM -I/lib/module                                                                             s/2.6.18-4-k7/build/include -I/lib/modules/2.6.18-4-k7/build/include/scsi -I/lib                                                                             /modules/2.6.18-4-k7/build/drivers/scsi -D__SMP__ -march=i386 -mpreferred-stack-                                                                             boundary=4  " -C linux
make[1]: Entering directory `/daten/tx4310_partial/linux'
gcc  -O2 -DASIC_OEM -DOCTOPUSII -O2 -fomit-frame-pointer -D_LINUXDRIVER -D__KERN                                                                             EL__ -DMODULE -D__linux__ -Wall -Wstrict-prototypes -fno-strict-aliasing -fno-co                                                                             mmon -Wno-unused -pipe -DASIC_OEM -D_X8632B -D_32BPLATFORM -I/lib/modules/2.6.18                                                                             -4-k7/build/include -I/lib/modules/2.6.18-4-k7/build/include/scsi -I/lib/modules                                                                             /2.6.18-4-k7/build/drivers/scsi -D__SMP__ -march=i386 -mpreferred-stack-boundary                                                                             =4   -I. -I../include -c osd_main.c
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/thread_info.h:1                                                                             6,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/thread_info.h                                                                             :21,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/preempt.h:9,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/spinlock.h:49                                                                             ,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/vmalloc.h:4,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/io.h:49,
                 from osd_inc.h:8,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/processor.h:80: error: âCONFIG_X86_L1                                                                             _CACHE_SHIFTâ undeclared here (not in a function)
/lib/modules/2.6.18-4-k7/build/include/asm/processor.h:80: error: requested alig                                                                             nment is not a constant
In file included from osd_inc.h:8,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/io.h: In function âvirt_to_physâ:
/lib/modules/2.6.18-4-k7/build/include/asm/io.h:77: error: âCONFIG_PAGE_OFFSETâ                                                                              undeclared (first use in this function)
/lib/modules/2.6.18-4-k7/build/include/asm/io.h:77: error: (Each undeclared iden                                                                             tifier is reported only once
/lib/modules/2.6.18-4-k7/build/include/asm/io.h:77: error: for each function it                                                                              appears in.)
/lib/modules/2.6.18-4-k7/build/include/asm/io.h: In function âphys_to_virtâ:
/lib/modules/2.6.18-4-k7/build/include/asm/io.h:95: error: âCONFIG_PAGE_OFFSETâ                                                                              undeclared (first use in this function)
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/rwsem.h:24,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h:42,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:57,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h: In function â__down_readâ:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h:104: error: expected â:â or â                                                                             )â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h: In function â__down_write_ne                                                                             stedâ:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h:156: error: expected â:â or â                                                                             )â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h: In function â__up_readâ:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h:198: error: expected â:â or â                                                                             )â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h: In function â__up_writeâ:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h:224: error: expected â:â or â                                                                             )â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h: In function â__downgrade_wri                                                                             teâ:
/lib/modules/2.6.18-4-k7/build/include/asm/rwsem.h:249: error: expected â:â or â                                                                             )â before âKBUILD_BASENAMEâ
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:57,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h: In function âdownâ:
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h:105: error: expected â:â                                                                              or â)â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h: In function âdown_interr                                                                             uptibleâ:
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h:130: error: expected â:â                                                                              or â)â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h: In function âdown_tryloc                                                                             kâ:
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h:155: error: expected â:â                                                                              or â)â before âKBUILD_BASENAMEâ
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h: In function âupâ:
/lib/modules/2.6.18-4-k7/build/include/asm/semaphore.h:179: error: expected â:â                                                                              or â)â before âKBUILD_BASENAMEâ
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/smp.h:17,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/smp.h:18,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:63,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/mpspec.h:6:25: error: mach_mpspec.h:                                                                              Datei oder Verzeichnis nicht gefunden
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/smp.h:17,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/smp.h:18,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:63,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/mpspec.h: At top level:
/lib/modules/2.6.18-4-k7/build/include/asm/mpspec.h:8: error: âMAX_MP_BUSSESâ un                                                                             declared here (not in a function)
/lib/modules/2.6.18-4-k7/build/include/asm/mpspec.h:22: error: âMAX_IRQ_SOURCESâ                                                                              undeclared here (not in a function)
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/smp.h:18,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:63,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/smp.h:76:26: error: mach_apicdef.h: D                                                                             atei oder Verzeichnis nicht gefunden
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/smp.h:18,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/sched.h:63,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/smp.h: In function âhard_smp_processo                                                                             r_idâ:
/lib/modules/2.6.18-4-k7/build/include/asm/smp.h:80: warning: implicit declarati                                                                             on of function âGET_APIC_IDâ
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/irq.h:13,
                 from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/linux/sched.h: In function âdequeue_signa                                                                             l_lockâ:
/lib/modules/2.6.18-4-k7/build/include/linux/sched.h:1209: warning: implicit dec                                                                             laration of function âlocal_irq_saveâ
/lib/modules/2.6.18-4-k7/build/include/linux/sched.h:1211: warning: implicit dec                                                                             laration of function âlocal_irq_restoreâ
In file included from osd_inc.h:10,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/irq.h:15:25: error: irq_vectors.h: Da                                                                             tei oder Verzeichnis nicht gefunden
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/hardirq.h:5,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/hardirq.h:7,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/interrupt.h:1                                                                             1,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/highmem.h:23,
                 from osd_inc.h:28,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/linux/irq.h: At top level:
/lib/modules/2.6.18-4-k7/build/include/linux/irq.h:169: error: âNR_IRQSâ undecla                                                                             red here (not in a function)
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/irq.h:182,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/hardirq.h:5,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/hardirq.h:7,
                 from /lib/modules/2.6.18-4-k7/build/include/linux/interrupt.h:1                                                                             1,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/highmem.h:23,
                 from osd_inc.h:28,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/hw_irq.h:31: error: âNR_IRQ_VECTORSâ                                                                              undeclared here (not in a function)
In file included from /lib/modules/2.6.18-4-k7/build/include/asm/tlbflush.h:4,
                 from /lib/modules/2.6.18-4-k7/build/include/asm/highmem.h:26,
                 from osd_inc.h:28,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/linux/mm.h: In function âlowmem_page_addr                                                                             essâ:
/lib/modules/2.6.18-4-k7/build/include/linux/mm.h:531: warning: implicit declara                                                                             tion of function â__page_to_pfnâ
In file included from /lib/modules/2.6.18-4-k7/build/include/linux/pci.h:691,
                 from osd_inc.h:34,
                 from osd_main.c:333:
/lib/modules/2.6.18-4-k7/build/include/asm/pci.h: In function âpci_dac_dma_to_pa                                                                             geâ:
/lib/modules/2.6.18-4-k7/build/include/asm/pci.h:72: warning: implicit declarati                                                                             on of function â__pfn_to_pageâ
/lib/modules/2.6.18-4-k7/build/include/asm/pci.h:72: warning: return makes point                                                                             er from integer without a cast
In file included from osd_inc.h:94,
                 from osd_main.c:333:
osd_timer.h: At top level:
osd_timer.h:21: warning: type qualifiers ignored on function return type
osd_timer.h:37: warning: type qualifiers ignored on function return type
osd_main.c: In function âwrap_P2Vâ:
osd_main.c:391: warning: passing argument 1 of âphys_to_virtâ makes integer from                                                                              pointer without a cast
osd_main.c: In function âprepare_sg_tableâ:
osd_main.c:868: warning: passing argument 2 of âpci_map_pageâ makes pointer from                                                                              integer without a cast
osd_main.c: In function âfasttrak_queueâ:
osd_main.c:1005: error: âScsi_Cmndâ has no member named âbufferâ
make[1]: *** [osd_main.o] Fehler 1
make[1]: Leaving directory `/daten/tx4310_partial/linux'
make: *** [linux/ft.o] Fehler 2

Wie kann ich den Treiber nun noch ganz ohne Fehler kompilieren?

Gruss Chip

[Chip@Debian]

Hallo

Kann mir bei meinen 2 Problemen niemand mehr helfen? Jetzt, wo ich doch schon um einiges weiter bin wäre es schade, wenn ich nicht mehr weiterkommen würde.

Greez Chip

[gms]

Hallo,
danke für die PN Ich hatte in den letzten Wochen wenig Zeit und hätte sonst wahrscheinlich deine Antwort übersehen.
Wie ich oben schon vermutet habe, läßt sich der Treiber mit aktuellen 2.6er Kernels nicht erstellen. Dazu wurde er zulange schon nicht mehr an den aktuellen Kerneltree angepaßt.
Jetzt müßte man sich die Fehlermeldungen im Detail anschauen und könnte dann den Treiber entsprechend anpassen.
Vorher würde ich jedoch gerne wissen, warum du nicht den "sata_promise" Treiber aus dem Standardkernel nehmen kannst/willst.

Gruß
gms

[Chip@Debian]

Hallo

Ich habe mit modconf gesehen, dass das modul sata_promise bei mir schon "aktiviert" ist. Wahrscheindlich unterstützt die Version des modules, die ich habe mein controller nicht. Ich habe im Web gesehen, dass es mit einem Patch funktioniert. Kann ich und wenn wie das Modul sata_promise updaten oder patchen? Ich habe noch etwas anderes im WWW gefunden: http://forums.debian.net/viewtopic.php?t=8076 ich weiss aber nicht, wie ich ein Debian-Kernel kompilieren muss, deshalb werde ich bei dieser Lösung auch nicht weiter kommen.

Gruss Chip

[gms]

Ich habe im Web gesehen, dass es mit einem Patch funktioniert.

poste doch den Link

Kann ich und wenn wie das Modul sata_promise updaten oder patchen?

wenn du das Modul patchen möchtest, solltest du den Kernel eigentlich vollständig neu bauen, ist wahrscheinlich dann auch einfacher, als nur das Modul upzudaten.

Ich habe noch etwas anderes im WWW gefunden: http://forums.debian.net/viewtopic.php?t=8076 ich weiss aber nicht, wie ich ein Debian-Kernel kompilieren muss, deshalb werde ich bei dieser Lösung auch nicht weiter kommen.

Diesen Lösungsansatz kannst du vergessen, eine entsprechende Zeile ist in den Debian Sourcen des 2.6.18er Kernels schon vorhanden:

Code: Alles auswählen

        { PCI_VENDOR_ID_PROMISE, 0x3515, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
          board_20319 },

es gibt auch eine Möglichkeit das "gegenzuchecken", wenn du "pcimodules" aus dem Paket "pciutils" aufrufst, sollte dir "sata_promise" angezeigt werden. Dieses Tool verwendet die Informationen aus /lib/modules/`uname -r`/modules.pcimap. In dieser Datei sind alle Karten aufgelistet, die von deinem aktuellen Kernel ( bezüglich pci ) unterstützt.

Gruß
gms

[Chip@Debian]

Also einige Links in denen von diesem "patchen" gesprochen wird:

http://www.hostelsweb.com/hostelsweb.co ... Number=427
http://gateway.total-knowledge.com/cgi- ... 39fa6b9d70

Wenn es sonst noch eine Möglichket gibt den Kontrollern irgendwie zum Funktionieren zu bringen, dann lass es mich doch wissen.

Gruss Chip

[gms]

der obige Link führt wahrscheinlich an ein Urlaubsziel von dir
der Patch im zweiten Link macht genau das gleiche:

Code: Alles auswählen

--- drivers/scsi/sata_promise.c
+++ drivers/scsi/sata_promise.c
@@ -227,6 +227,8 @@ static const struct pci_device_id pdc_at
           board_20319 },
         { PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
           board_20319 },
+        { PCI_VENDOR_ID_PROMISE, 0x3515, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+          board_20319 },
         { PCI_VENDOR_ID_PROMISE, 0x3519, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
           board_20319 },
         { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0

Dieser Patch dürfte beim 2.6.17er Kernel noch benötigt worden sein, beim 2.6.18er Kernel ist er nicht mehr nötig.

Läßt sich das Modul laden ? Was steht anschließend in den Logdateien ?

[Chip@Debian]

Hallo

Wenn ich pcimodules aufrufe, dann kommt eine Liste und sata_promise ist auch dabei. In welcher Log-Datei soll ich nach Einträgen suchen?

Gruss Chip

[gms]

Mit "modprobe sata_promise" kannst du das Modul laden, mit "rmmod sata_promise" entladen und mit "lsmod | grep sata_promise" überprüfen ob ds Modul geladen ist. Wenn du das Modul geladen hast, kannst du mit "dmesg" überprüfen, ob dabei Fehler ausgegeben wurden. Mit "dmesg -c >/dev/null" kannst vorher alle Meldungen aus dem Ring Buffer entleeren, damit die Ausgabe übersichtlicher wird.
"Historische" Meldungen kannst du dir in /var/log/messages bzw /var/log/kern.log anschauen. Wenn du das Bootlogging in /etc/default/bootlogd aktivierst, erhältst du auch noch ein /var/log/boot mit den Medlungen, die während des Bootvorgangs ausgegeben wurden.

[Niko_K]

Hallo!

Ich habe auch dieses Problem mit dem TX4310.
Chip@Debian: Gehe ich richtig in der Annahme, dass du auch die HDDs seperat siehts, obwohl du eigentlich ein RAID device erwarten würdest? Bei mir ist das nämlich so...

Eigentlich sollte der Promise Controller seit 2.6.17 funktionieren (laut Kernel Changelog...)! Muss man da wirklich noch den Treiber kompilieren??

Niko

[gms]

Chip@Debian: Gehe ich richtig in der Annahme, dass du auch die HDDs seperat siehts, obwohl du eigentlich ein RAID device erwarten würdest? Bei mir ist das nämlich so...

ist ja auch ein Software-Raid (Fake-Raid) Controller, bei Promise sind die SuperTrak Controller für die Hardware Raids

Eigentlich sollte der Promise Controller seit 2.6.17 funktionieren (laut Kernel Changelog...)! Muss man da wirklich noch den Treiber kompilieren??

der alte Treiber läßt sich für die neuen Kernels nicht kompilieren, der müßte zuerst adaptiert werden. Danach hättest du aber noch immer kein Hardware Raid

Hier habe ich eine Anleitung zu mdadm gefunden, bei der sogar der gleiche Controller verwendet wird:
http://de.gentoo-wiki.com/Raid_5_Verbun ... _erstellen

Du mußt eigentlich nur das Paket mdadm installieren und dann das Raid wie in diesem Link beschrieben einrichten. Kernel oder Treiber müßt ihr keinen bauen

Gruß
gms

[Niko_K]

Hallo,

das wusste ich nicht! Danke für die Erklärung...
...jetzt muss ich mir nur noch überlegen, ob ich mir einen echten Hardware-Raid5 (dann könnte ich ja auch schon auf Raid6 umsteigen) zulege oder das mit Fakeraid einrichte.

Was mich dabei besonders interessieren würde...
...wie sieht es denn mit Festplatten Spindowns bei Raid aus???

Im Moment kann ich die Platten am Kontroller mit hdparm ausschalten... geht das bei einem fakeraid auch? Wie sieht es da bei echtem Hardware-Raid aus??

Kennt sich damit jemand aus?

LG,
Niko

[Chip@Debian]

Hallo

Verstehe ich das richtig, dass mein Controller richtig läuft, wenn ich meine 4 Platten einzeln sehen kann obwohl ich ein Raid 5 erstellt habe? Wieso kann man dann im "Bios" des Kontrollers ein Raid 5 erstellen, wenn es nur ein Software Raind ist? Werden diese Informationen vom "Kontrollerbisos" dem Software-Raid übergeben?Dann werde ich wohl auf einen richtigen Hardware-Raidcontroller umsteigen. Kann mir da jemand eien Kontroller empfehlen, der mit Debian gut funktionert?

Gruss Chip

[gms]

Werden diese Informationen vom "Kontrollerbisos" dem Software-Raid übergeben?

vermutlich werden diese Einstellungen vom Windows Treiber ausgelesen, der dann ein Software-Raid draus bastelt, unter Linux kannst du das Raid mit mdadm konfigurieren

Dann werde ich wohl auf einen richtigen Hardware-Raidcontroller umsteigen.

Hast du spezielle Anforderungen, sodaß du mit einem Software-Raid nicht glücklich wirst ?

Kann mir da jemand eien Kontroller empfehlen, der mit Debian gut funktionert?

Die Frage etwas umformuliert: "Mit welchem Treiber für ein Hardware-Raid sind die wenigsten Probleme zu erwarten?"
Sicher mit den Treibern, die schon im Standardkernel inkludiert sind und von den Kernelentwicklern gewartet werden. Hier gibt es nach meinen Informationen nur die 3ware Kontroller:

Linux kernels 2.6.14 and newer include a driver for the 3ware 7000/8000/9500S/9550SX/9550SXU/9590SE series controllers.

Ich habe immer wieder vernommen, daß diese Controller sehr gut ( auch unter Linux ) funktionieren, hatte aber bis jetzt noch kein Hardware Raid im Einsatz

Gruß
gms