Hallo Gemeinde, ich weis nicht ob ich hier richtig bin, aber ich hatte so viel Nerven an einem Problem verloren, dass ich andere davor bewahren möchte. Die Essenz aus meinen Erfahrungen sollte irgendwie in die Weiterentwicklung einfließen und wenn nur mit Warnhinweisen. Leider weiß ich nicht recht, wie ich das anstellen soll, daher mein Posting hier.
Da nicht nur Debian betroffen ist, wäre es toll, wenn jemand das an die Kernelentwicklung weitergeben könnte. Für Rückfragen, stehe ich gerne zur Verfügung. Gruß Frank Hier mein Problem gemailt an den Support von ICP (Auszug) darunter die Antwort von ICP): ---------------------------------------------------------------------------------------------------------- Hallo ICP Support Ich selbst habe ein System mit einem GDT-7118RN SCSI RAID Controller auf einem Asus K8V Deluxe mit AMD64 CPU & 1GB RAM. Die Probleme habe ich in verschiedenen Crosstests auch mit einem GDT-8124RZ, einem anderen Mainboard Gigabyte GA6-BA PIII, alternativen HDDs und ROMs verifiziert. Der GDT-8124RZ schein hierbei noch empfindlicher zu sein, als alte GDT-7118RN. Etwas unempfindlicher sind augenscheinlich die 32Bit Linux Versionen. Konfiguration: 2 x IBM IC35L073UWDY10-0 HDD an Kanal A als RAID 1 Verbund 1 x Pioneer DVD-305 & Teac CD-W512SB an Kanal B Getestete Software: - Debian Sarge 3.1 AMD64 & i386 - Ubuntu 5.10 Badgy Breezer AMD64 & i386 - SuSE Linux 10.0 x86_64 & i386 - Fedora Core 4 x86_64 - Knoppix Linux Live CD 4.0.2 (Vanilla Kernel i386 optimiert) - SuSE Linux 9.0 x86_64 Der Rechner friert ein, teilw. je nach Kombination gibt es Fehlermeldungen wie: - Kernel Panic: PCI-DMA: high Address but no IOMMU - Pid:198,comm: scsi_eh_0 Not tainted 2.6.11-11-amd64-generic - Console Shuts up - Interrupt handler - not syncing usw. Der Effekt ist immer der gleiche und tritt teilweise direkt beim Laden der gdth.o Modules auf (Fedore Core 4 x64_86) oder erst im Laufe der Installation (SuSE 10.0 i386) i.d.R. dann, wenn auf das optische SCSI Gerät zugegriffen wird). Debian hat zusatzlich dass Problem, dass es zwar von den Medien bootet (per Controller Bios) aber dann nicht auf das Installationsmediom im SCSI DVD-ROM zugreifen kann. In langwierigen Tests habe ich herausgefunden, woran es liegt. Sobald ein optisches SCSI Laufwerk mit am GDT-Controller angeschlossen ist, wird das System instabil. Egal an welchem Kanal, teilweise reicht ein "mount /cdrom" und der Rechner hängt sich auf. In Verbindung mit einem IDE/PATA DVD-ROM und nur Festplatten am GDT-Controller, läuft alles wunderbar, egal an welchem Kanal die Platten hängen. Anfangs dachte ich, dass nur der nicht mehr supportete GDT-7118RN in Verbindung mit einem neueren Linux Kernel das Problem ist, siehe http://www.icp-vortex.com/german/support/faq/linux_d.htm#oldhw Allerdings haben die Tests mit dem GDT-8124RZ U320 Controller gezeigt, dass wohl generell optische Laufwerke ein Problem sind (Bandlaufwerke habe ich nicht testen können). Das ist sehr schlecht, wenn reine SCSI Lösungen gewünscht sind. Ein einfacher SCSI-Controller (z.B. Adaptec AHA-2940U) als alternative Anschlußmöglichkeit für die optischen SCSI Geräte scheidet auch aus. Oft kann man im Rechner BIOS nur einen der beiden SCSI Controller (das erste PCI Device) in die Bootfolge einbinden. D.H. ich kann entweder vom AHA-2940U DVD-ROM booten oder vom GDT-Hostdrive nicht aber beides in einer Bootreihenfolge. Wenn ein Umstellen im Bios ausreichen würde, könnte man damit leben, aber man muß die Karten umstecken. Außerdem geht duch den zusätzlichen SCSI Controller ein wertfoller PCI Slot verloren (schließlich nimmt man ja extra einen GDT Mehrkanal Controller). Als kleine Anmerkung sei noch erwähnt, dass lediglich folgende Kombinationen auf dem AMD64 liefen: - Eine alte SuSE 9.0 x86_64 mit Kernel 2.4.21-226 spätere Security Updates ab -238 liefen auch nicht mehr - Die Knoppix Live CD, welche einen nur für 386er optimierten (SMP) Kernel 2.6.12 verwendet. Also, scheint dieses Problem irgendwann im Kernel (gdth.o) aufgetaucht zu sein und nur bei Pentium oder höher optimierten Kerneln Abstürze zu verursachen. Da ich Ihnen hier detailierte Infos zu einem ernsten Problem gebe, wäre ein Feedback sehr nett und ggf. eine Lösung sehr schön. -------------------------------------------------------------------------------------------------------------------------------------- Antwort von ICP: -------------------------------------------------------------------------------------------------------------------------------------- Sehr geehrter Herr xxx, zuerst einmal vielen Dank für die ausführliche Problembeschreibung. Mit einem Feedback können wir Ihnen tatsächlich dienen - mit einer Lösung die Ihrem Ziel nahekommt jedoch leider nicht. Die Aussage seitens ICP zum Betrieb asynchroner Geräte an ICP RAID Controllern ist und war, dass dies zwar technisch möglich ist und die RAID Controller eine allgemeine Schnittstelle zu ASPI bieten, die Unterstützung jeglicher Geräte jedoch nicht validiert wird und daher leider keine unbeschränkte Funktionsgewähr besteht. Dies gilt für Firmware und Treiber gleichermaßen. Im Zweifel oder bei Problemen empfehlen wir für den Betrieb dieser Geräte den Einsatz eines SCSI Adapters, wobei dies in Ihrem Fall nur bedingt eine Lösung darstellen würde. Bezüglich der Bootreihenfolge könnte man eventuell den BIOS Support des ICP Controllers temporär deaktivieren und so verhindern, dass von dessen Host Drive gebootet wird. Sofern wir Ihnen trotzdem bei möglichen Fragen zur Konfiguration der ICP RAID Controller behilflich sein können, stehen wir Ihnen gerne auch telefonisch unter 07132 9620900 zur Verfügung. Mit freundlichem Gruss / with kind regards Thomas Holm Technical Services RAID Products ICP vortex Computersysteme GmbH Konrad-Zuse-Str. 9 D-74172 Neckarsulm, Germany Phone: +49-7132-9620-900 Fax: +49-7132-9620-400 Email: [EMAIL PROTECTED] url: www.icp-vortex.com
