mein Pentium Pro-System (und seine Problemchen)

Steffchen

Enthusiast
Thread Starter
Mitglied seit
26.08.2007
Beiträge
212
Ort
Winsen (Luhe)
Moin Leute,

zunächst möchte ich etwas über die Geschichte meines Pentium Pro-Systems erzählen. Vor langen, langen Jahren habe ich in einem Anflug von Wahnsinn zwei Dual Pentium Pro ATX-Mainboards bei eBay geschossen. Beide vom selben Hersteller, Micronics. Dieser wurde jedoch irgendwann von Diamond aufgekauft. Was ich damals jedoch im Eifer des Gefechts vergessen hatte, war nach Unterlagen zu diesem Board zu suchen. Jedes dieser beiden Boards war mit je einem Pentium Pro 200 mit 256kb Cache bestückt. Wie es der Zufall wollte, hatten sie sogar das gleiche Stepping, sodass ich sie zusammen auf einem Board betreiben konnte. Ein passendes VRM Modul konnte ich irgendwo im Keller noch finden.

Es stellte sich jedoch die Frage, welches der beiden Boards ich verwenden sollte. Das eine war mit zwei USB-Ports ausgestattet, hatte dafür keinen Sound onboard, sowie das andere. Ich entschied mich für dasjenige mit USB. Zu meiner großen Enttäuschung unterstützte das installierte BIOS aber lediglich 8GB große Festplatten, was mir nicht so recht gefiel. Vom Platz her wäre das für ein Windows NT4 oder sogar ein Windows 2000 auf jeden Fall durchaus ausreichend gewesen, jedoch haben die kleinen, und damit alten, Festplatten immer ein sehr unangenehmes Laufgeräusch. Also machte ich mich ans Werk und suchte eine neuere BIOS-Version, welche ich dann nach endlosem googlen auch fand. Diese in das Board geflashed brachte aber keinen Vorteil. Im Gegenteil, der Bootvorgang dauerte nun endlos. Die 256MB RAM, welche ich zu der Zeit verbaut hatte, brauchten ca. 15 Minuten zum durchlaufen. Aber noch viel schlimmer war: Die USB-Ports funktionierten nicht mehr! Das neue BIOS unterstützt diese nicht! Leider hatte ich dummer Weise vergessen ein Backup des alten BIOSes zu machen. Zu allem Überfluss ist die Belegung der FAN-Header auch noch anders als gewöhnlich, worauf ein Lüfter mit Rauchzeichen seinen Dienst quittierte. Dann verließ mich die Lust und ich ließ die beiden Boards samt CPUs im Keller in irgend einem Karton verschwinden.

Wie es der Zufall wollte, stolperte ich jedoch im Sommer dieses Jahres über den doch schon recht angestaubten Karton und dachte mir: „Vielleicht kann man dieses Ding ja doch noch einmal zum Leben erwecken.“ Zunächst setzte ich mich wieder an Google. Auch, wenn mittlerweile Diamond von ATI aufgekauft wurde, war ich dieses mal schon deutlich erfolgreicher. So konnte ich zwei verschieden BIOS-Versionen finden und auch das Handbuch zu den Mainboards (es sind Micronics WL6i, was jedoch nirgendwo auf dem Board steht...) finden. Das neuere dieser beiden BIOSe habe ich dann einspielen können, und siehe da, der Bootvorgang geht immerhin wieder schneller. Aber USB: Fehlanzeige. Macht nichts, dachte ich, und baute ein schickes System drumherum. Eine größere Festplatte kann man ja auch über einen extra Controller anschließen. Ich habe sogar noch 2x 256MB buffered EDO bei eBay gefunden, sodass ich jetzt stolze 768MB verbaut habe. Ein Slot ist nun noch frei, sodass ich bei Gelegenheit irgendwann nochmal auf 1GB aufrüsten kann.

Das jetzige System setzt sich damit wie folgt zusammen:

Mainboard: Micronics WL6i
CPU: 2x Pentium Pro 200 mit 256kb Cache und VRM-Modul von Compaq
Grafikkarte: ATI 3D Rage Pro PCI
IDE-Controller: Dawicontrol DC-100 RAID
Festplatte: Maxtor 40GB 5400rpm
Soundkarte: Sondblaster Live! value
Netzwerkkarte: 3com EtherLink III
Betriebssystem: Windows 2000

Da ich aber schon gerne die USB-Ports nutzen möchte, bin ich immer noch auf der Suche nach dem passenden BIOS. Eventuell kann mir ja hier jemand helfen? Besitzt irgend jemand auch noch eines dieser Boards und kann mir eventuell eine Kopie des BIOSes ziehen? Ich habe sie seit meinem Kauf nicht wieder bei eBay gefunden. Oder hat jemand noch irgend eine andere Idee, wie man die USB-Ports zum Laufen bekommt?

Im Anhang befinden sich noch einige Bilder des Systems, sowie dem nicht verbauten Board mit Sound.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich würd jetz einfach mal Ganz doof sagen, Pack dir ne USB 2.0 Karte rein :lol:

Hast du es denn mal mit dem adneren Bios versucht ob da die Ports wieder gehen oder ob sie weiterhin tot sind ? wäre mal nen Versuch wert ;)

Gruß Intel Freak

EDIT: Schicker Chiefteck Tower :P
 
Zuletzt bearbeitet:
@Intel Freak,
wlkikiv ;)

Zum Thema,
falls du die Ports echt brauchst versuch "einfach" das alte BIOS wieder aufzutreiben, alternativ halt eine USB Karte, einen Slot hast du ja noch frei... Ist aber natürlich ärgerlich.

MfG,
chrissi
 
falls du die Ports echt brauchst versuch "einfach" das alte BIOS wieder aufzutreiben, alternativ halt eine USB Karte, einen Slot hast du ja noch frei... Ist aber natürlich ärgerlich.

Genau das versuche ich ja, das alte BIOS aufzutreiben. Jedoch kann ich es im Internet nicht mehr finden, daher ist meine letzte Hoffnung, dass jemand hier im Forum auch so ein Board hat und eventuell auchnoch eine passende BIOS-Version eingespielt hat. (Oder google besser bedienen kann, als ich ;))

Würde ich wirklich USB dringend brauchen, könnte ich natürlich eine USB-Karte einbauen. Aber bei dem System geht es nicht um den praktischen Nutzen, sondern nur im Spass an der Sache. Und da ist ein nicht funktionierender USB-Port doch ein Ärgernis. ;)

In dem freien PCI-Slot war übrigends bis vor kurzem noch eine 100Mbit Gammelnetzwerkkarte mit Realtek-Chip. Eventuell werd ich da noch eine Token Ring-Karte 'rein bauen, kommt drauf an, ob ich noch eine ISA-Karte finde oder nicht.
 
kennen nicht
siet aber so aus als wenns ein intel layout wär, nur mit anderem namen dann halt
 
siet aber so aus als wenns ein intel layout wär, nur mit anderem namen dann halt

Danke für den Tipp, ich habe mich mal schlau gemacht, was Intel so produziert hat. Leider hab ich kein ähnliches Layout gefunden. Von Intel habe ich sogar nur ein ATX Dual-Board gefunden (das PR440FX).

Eine Liste von Intel Board habe ich hier gefunden, eine weitere Liste mit sehr vielen anderen Pentium Pro Boards hier.
 
naja n versuch war es wert
die intel boards von damals sehen dem aber ähnlich

die bauart vom bios chip
oben die ecke
die Einteilung in Planquadrate wie bei Landkarten
 
ACHTUNG: Der folgende Post enthält für die meisten Leute eher langweiliges Softwaregebastel, weiterlesen auf eigene Verantwortung.

All die vergangenen Jahre ist mir das hier beschriebene System nicht aus dem Kopf gegangen. Immer mal wieder habe ich versucht ein passendes BIOS zu finden. Bis jetzt ist es mir nicht gelungen... aber:

Warum muss es unbedingt das BIOS sein, dass mir den USB-Controller im Chipsatz aktiviert? Geht das nicht auch später?

Mit dieser Idee habe ich das System wieder ausgegraben und mich an die Arbeit gemacht. Die passenden Register in der Southbridge (82371SB oder besser bekannt als PIIX3) sind dank super Dokumentation von Intel schnell gefunden. Zugriff auf diese Register hat man über den PCI configuration space. Und tatsächlich, der USB-Controller ist nach dem Booten deaktiviert.

Die lässt sich aber ganz leicht über einen Befehl ändern:

# setpci -v -d8086:7000 6a.W=0x00d0

Wenn ich nun den PCI-Bus erneut prüfen lasse, dann wird der USB-Controller erkannt (YAY!):

# echo 1 > /sys/bus/pci/rescan

Leider ist der USB-Controller beim PIIX3 fest an den PCI-Interrupt INT D gekoppelt. Und das BIOS stellt für diesen Interrupt keine Routing-Informationen im MP Spec Table zur Verfügung. Dies äußert sich dann mit einem Initialisierungsfehler:


Sep 2 23:54:04 localhost kernel: pci 0000:00:07.2: [8086:7020] type 00 class 0x0c0300
Sep 2 23:54:04 localhost kernel: pci 0000:00:07.2: reg 0x20: [io 0x0000-0x001f]
Sep 2 23:54:04 localhost kernel: pci 0000:00:07.2: BAR 4: assigned [io 0x1000-0x101f]
Sep 2 23:54:04 localhost kernel: pci 0000:00:07.2: enabling device (0000 -> 0001)
Sep 2 23:54:04 localhost kernel: pci 0000:00:07.2: can't find IRQ for PCI INT D; probably buggy MP table
Sep 2 23:54:04 localhost kernel: uhci_hcd: USB Universal Host Controller Interface driver
Sep 2 23:54:04 localhost kernel: uhci_hcd 0000:00:07.2: can't find IRQ for PCI INT D; probably buggy MP table
Sep 2 23:54:04 localhost kernel: uhci_hcd 0000:00:07.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:07.2 setup!
Sep 2 23:54:04 localhost kernel: uhci_hcd 0000:00:07.2: init 0000:00:07.2 fail, -19


Lange habe ich geschaut, ob man diesen MP Spec Table irgendwie modifizieren kann... aber ohne das eigentlich BIOS zu verändern ist dies nicht so einfach möglich. Ich habe also mich durch die Linux-Quellen gewühlt und beim Auslesen der Tabelle aus dem BIOS einen Eintrag hinzugeschummelt, der den INT D auf INT 19 routet. Damit schaut es dann viel besser aus:


Sep 13 09:09:06 localhost kernel: pci 0000:00:07.2: [8086:7020] type 00 class 0x0c0300
Sep 13 09:09:06 localhost kernel: pci 0000:00:07.2: reg 0x20: [io 0x0000-0x001f]
Sep 13 09:09:06 localhost kernel: pci 0000:00:07.2: BAR 4: assigned [io 0x1000-0x101f]
Sep 13 09:09:06 localhost kernel: pci 0000:00:07.2: enabling device (0000 -> 0001)
Sep 13 09:09:06 localhost kernel: pci 0000:00:07.2: PCI->APIC IRQ transform: INT D -> IRQ 19
Sep 13 09:09:06 localhost kernel: uhci_hcd: USB Universal Host Controller Interface driver
Sep 13 09:09:06 localhost kernel: uhci_hcd 0000:00:07.2: PCI->APIC IRQ transform: INT D -> IRQ 19
Sep 13 09:09:06 localhost kernel: uhci_hcd 0000:00:07.2: UHCI Host Controller
Sep 13 09:09:06 localhost kernel: uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
Sep 13 09:09:06 localhost kernel: uhci_hcd 0000:00:07.2: irq 19, io base 0x00001000
Sep 13 09:09:06 localhost kernel: hub 1-0:1.0: USB hub found
Sep 13 09:09:06 localhost kernel: hub 1-0:1.0: 2 ports detected


Der Controller wird also nun erkannt. Der Test mit einer USB-Tastatur ergibt dann auch, dass wirklich alles funktioniert:


Sep 13 09:18:42 localhost kernel: usb 1-2: new low-speed USB device number 2 using uhci_hcd
Sep 13 09:18:42 localhost kernel: input: HID 046a:0001 as /devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0/0003:046A:0001.0001/input/input3
Sep 13 09:18:42 localhost kernel: hid-generic 0003:046A:0001.0001: input: USB HID v1.00 Keyboard [HID 046a:0001] on usb-0000:00:07.2-2/input0
Sep 13 09:18:42 localhost kernel: usbcore: registered new interface driver usbhid
Sep 13 09:18:42 localhost kernel: usbhid: USB HID core driver


Nun habe ich es also nach fast 6 Jahren doch noch geschafft mein Pentium Pro System vollständig in Betrieb zu nehmen. Als Betriebssystem musste ich mich zwar dafür von Windows 2000 verabschieden; Windows 2000 ist aber sicherlich auch nie das wirklich richtige OS für dieses System gewesen. Laufen tut dort nun ein Gentoo Linux drauf, selbstverständlich vom System selbst compiliert.

Fehlen tun mir nun noch zwei Pentium Pros in der Black Edition - also mit 1MB L2 Cache. Hat hier zufällig jemand welche im Regal, die er mir zur Verfügung stellen kann?

Viele Grüße,
Steff
 
Cooles Teil und Respekt vor der Arbeit mit dem USB aktivieren. Aber Mensch, da gehört doch ne SCSI Platte rein! Der hat doch sogar nen Controller mit 68Pin onboard, da sparste sogar noch eine PCI Karte.
 
Genau, ne SCSI HDD würd dem Mopped nochmal Flügel verleihen 8)
Wenn du ne relativ aktuelle erwischst, wirds auch nicht zuuu laut, nur die Zugriffe hört man deutlich :d
Aber netter Hobel und echt viel Arbeit, die du dir da gemacht hast :)
 
Nun denn, so soll es sein.

Ich habe nach längerem Wühlen in meinem Stapel alter Platten noch zwei Schmuckstücke von 1998 gefunden: zwei IBM DCAS 34330, 4GByte, SCSI-3 68pol. (Ultra Wide SCSI 40MB/sec). Ich habe sie damals in meinem aller ersten selbst gekauften Rechner, einem Pentium II mit 300 MHz, bekommen. Ich hatte keine Ahnung und wollte das schnellste und beste System haben, was zu dem Zeitpunkt gerade noch erschwinglich war. Insgesamt hat der Rechner um die 3000DM gekostet.

Nach richtigem Jumpern, also ID0 für die Bootplatte (Dateisystem /), ID1 für die zweite Platte (Dateisystem /usr), ID4 für das CDROM-Laufwerk, Terminierung einmal am CD-Laufwerk, einmal an der unteren Platte, werden beide Platten sauber vom BIOS des Onboard Adapter-Controllers erkannt. An die charakteristische Säuselei der IBM Platten wird sich hier der eine oder andere Nostalgiker sicher gerne zurückerinnern.

Anhang anzeigen 295050 Anhang anzeigen 295051

Mit ein paar Tricks kann man auch ein laufendes Linux-System kopieren. Gesagt getan... nun befindet sich das Gentoo aufgeteilt auf den beiden SCSI-Platten.

Interessiert hat mich aber natürlich auch, wie sich die betagten SCSI Platten gegen die nicht unbedingt viel weniger betagte IDE Platte von Maxtor (Baujahr 2001) schlagen. Das Ergebnis ist leider etwas ernüchternd, die IDE-Platte ist einfach 3x so schnell:

# hdparm -t /dev/sda && hdparm -t /dev/sdb
/dev/sda:
Timing buffered disk reads: 24 MB in 3.08 seconds = 7.79 MB/sec
/dev/sdb:
Timing buffered disk reads: 74 MB in 3.06 seconds = 24.15 MB/sec

Zur Erklärung: /dev/sda ist eine der SCSI-Platten, /dev/sdb ist die IDE Platte

Von Flügeln kann man also sicherlich nicht sprechen. Im Datenblatt der Platte sind jedoch auch 8.1MB/sec als Obergrenze angegeben. Da kommt mein System doch erstaunlich dich heran. Der Aufwand hat sich also sicherlich gelohnt. Weitere Vorschläge sind willkommen, ich werde schauen, was ich mit meinem Sammelsurium anfangen kann.

Viele Grüße,
Steff
 
Finde ich toll das du dem alten Schätzchen wieder leben eingehaucht hast :)
 
Großen Respekt für deinen Umbau im Linux-Kern. Kannst du vielleicht die Kernelversion nennen, in der du das implementiert hast und wie du das Routing des Interrupts geändert hast? Wäre daran sehr interessiert.

Viele Grüße
 
Um ganz genau zu sein: Ich habe die Version 3.14.16-gentoo verwendet. Diese Version unterscheidet sich von der Vanilla-Version durch ein paar Gentoo-spezifische Patches. Das ist aber in diesem Zusammenhang hier nicht relevant.

Dies ist der Hack (als etwas anderes darf man es nicht bezeichnen), den ich durchgeführt habe, damit der PCI INT D auf Interrupt 19 geroutet wird:
Code:
--- mpparse.c_vanilla   2014-09-24 10:52:24.000000000 +0200
+++ /usr/src/linux/arch/x86/kernel/mpparse.c    2014-09-07 22:58:33.000000000 +0200
@@ -258,6 +258,20 @@
                x86_init.mpparse.mpc_record(1);
        }

+       {
+               struct mpc_intsrc mpt = {
+                       .type = MP_INTSRC,
+                       .irqtype = mp_INT,
+                       .irqflag = MP_IRQDIR_LOW | (3 << 2),    /* pol | trigger */
+                       .srcbus = 0,
+                       .srcbusirq = 3 | (7 << 2),              /* INT D, Device 07 */
+                       .dstapic = 2,
+                       .dstirq = 19,
+               };
+
+               mp_save_irq(&mpt);
+       }
+
        if (!num_processors)
                printk(KERN_ERR "MPTABLE: no processors registered!\n");
        return num_processors;

Das lässt sich beim aktuellen stabilen Kernel (3.16.3) immer noch genau so lösen. An dem Parsen der MP-Tabelle wird sich vermutlich auch nicht mehr wirklich viel tun.

Zur Erklärung:
In der modifizierten Funktion smp_read_mpc( .. ) wird die MP-Tabelle nach Einträgen für Interrupts durchsucht. Wird ein passender Eintrag gefunden, so wird mit der Funktion mp_save_irq( .. ) dies registriert.
Ich habe nun durch den manuellen Aufruf der eben genannten Funktion selbst noch einen Eintrag hinzugefügt. Der funktioniert natürlich nur, weil auf dem Board der INT D vom 82371SB mit dem INT A vom ersten PCI-Slot verbunden ist, in dem ich die Soundkarte stecken habe. Der USB-Teil des 82371SB teilt sich also eine Interrupt-Leitung mit der Soundkarte. Das BIOS konfiguriert nun den APIC so, dass dieser Interrupt auf INT 19 landet und teilt dieses im MP-Table auch so mit.

Falls Du eine bessere Idee hast, so lass es mich wissen. Die Variante dort oben ist als 'proof of concept' ganz gut geeignet, mehr aber nicht. Auch weitere Fragen beantworte ich natürlich gerne. ;)

Viele Grüße,
Steff
 
Die Idee finde ich richtig gut: Der Nachteil ist nur, wenn ich deine Erklärungen richtig verstanden habe, dass du da wirklich ein statisches Routing des INT D auf den INT 19 umleitest. Praktischer wäre es doch dann eigentlich dieses Routing anhand von Product ID oder Vendor ID vorzunehmen. Besser wahrscheinlich noch durch durch die Geräteklasse, weil das Verfahren dann noch generischer bleibt.

Was mich interessiert ist, wie hast du die Sachen identifiziert: Ich kenne mich zwar im Bereich Scheduler, Filesystem und Treiber recht gut aus, aber diese Stelle konnte ich bei aller Liebe nicht identifizieren. Wie bist du da vorgegangen?
 
Die Idee finde ich richtig gut: Der Nachteil ist nur, wenn ich deine Erklärungen richtig verstanden habe, dass du da wirklich ein statisches Routing des INT D auf den INT 19 umleitest. Praktischer wäre es doch dann eigentlich dieses Routing anhand von Product ID oder Vendor ID vorzunehmen. Besser wahrscheinlich noch durch durch die Geräteklasse, weil das Verfahren dann noch generischer bleibt.
Schön wäre das... aber es ist nun mal eine Eigenschaft des Boards, wie die Interrupts (in Hardware) geroutet sind. Daher wäre es auch Aufgabe des BIOS dies richtig einzustellen. Auf einem anderen Board kann es ganz anders aussehen, selbst wenn der gleiche Chipsatz verbaut ist.

Das Vorgehen war eigentlich recht straight forward. Mit der Fehlermeldung, es könne kein IRQ gefunden werden weil vermutlich ein 'buggy MP table' vorliegt, war es relativ simpel die Stelle zu finden. Ich bin einfach von der Fehlermeldung ausgegangen und habe von da aus geschaut, wie sie entsteht und was ich tun kann, um das Problem zu lösen. Es hat sich heraus gestellt, dass beim Initialisieren des PCI-Devices der zugehörige Interrupt in genau jener Tabelle nachgeschlagen wird, in die ich dann den Eintrag hinzugemogelt habe. Den richtigen Interrupt (INT D) liefert das PCI Device selbst, der lässt sich im Configuration Space auslesen.
 
Also Stacktracing im Kernel :p

Coole Lösung, ich wünsche mir auch endlich mal wieder ein echtes interessantes Kernel-Problem. Gerade in Kombination mit so einen Retro-System erscheint mir das eine wirklich lohnende Aufgabe. Danke für die Ausführungen, habe es verstanden.
 
Zuletzt bearbeitet:
Nunja, die DCAS sind natürlich steinzeitlich (ich hab auch noch 2Stck. mit 50Pol Anschluss aus der Serie :) ), davon darf man keine großen Sprünge erwarten. Zudem - die sind 3 Jahre älter als die IDE HDD, das waren damals WELTEN ;) Selbst mit dem Nachfolger (?) DDRS kann man nicht viel reißen. Die DNES Serie kommt da schon etwas näher dran.
Aber beflügeln würd den natürlich ne neuere HDD. Das ist ja das schöne an SCSI - man kann problemlos größere HDDs anschließen, die erheblich neuer und schneller sind. Um alte Chipsätze muss man sich da wenig Gedanken machen :d
Aber so ist natürlich kultiger - gerade wenn man zu den HDDs noch einen Bezug hat. Meine beiden DCAS stecken in meiner DOS Kiste :)

Nun denn, so soll es sein.

Ich habe nach längerem Wühlen in meinem Stapel alter Platten noch zwei Schmuckstücke von 1998 gefunden: zwei IBM DCAS 34330, 4GByte, SCSI-3 68pol. (Ultra Wide SCSI 40MB/sec). Ich habe sie damals in meinem aller ersten selbst gekauften Rechner, einem Pentium II mit 300 MHz, bekommen. Ich hatte keine Ahnung und wollte das schnellste und beste System haben, was zu dem Zeitpunkt gerade noch erschwinglich war. Insgesamt hat der Rechner um die 3000DM gekostet.

Nach richtigem Jumpern, also ID0 für die Bootplatte (Dateisystem /), ID1 für die zweite Platte (Dateisystem /usr), ID4 für das CDROM-Laufwerk, Terminierung einmal am CD-Laufwerk, einmal an der unteren Platte, werden beide Platten sauber vom BIOS des Onboard Adapter-Controllers erkannt. An die charakteristische Säuselei der IBM Platten wird sich hier der eine oder andere Nostalgiker sicher gerne zurückerinnern.

Anhang anzeigen 295050 Anhang anzeigen 295051

Mit ein paar Tricks kann man auch ein laufendes Linux-System kopieren. Gesagt getan... nun befindet sich das Gentoo aufgeteilt auf den beiden SCSI-Platten.

Interessiert hat mich aber natürlich auch, wie sich die betagten SCSI Platten gegen die nicht unbedingt viel weniger betagte IDE Platte von Maxtor (Baujahr 2001) schlagen. Das Ergebnis ist leider etwas ernüchternd, die IDE-Platte ist einfach 3x so schnell:

# hdparm -t /dev/sda && hdparm -t /dev/sdb
/dev/sda:
Timing buffered disk reads: 24 MB in 3.08 seconds = 7.79 MB/sec
/dev/sdb:
Timing buffered disk reads: 74 MB in 3.06 seconds = 24.15 MB/sec

Zur Erklärung: /dev/sda ist eine der SCSI-Platten, /dev/sdb ist die IDE Platte

Von Flügeln kann man also sicherlich nicht sprechen. Im Datenblatt der Platte sind jedoch auch 8.1MB/sec als Obergrenze angegeben. Da kommt mein System doch erstaunlich dich heran. Der Aufwand hat sich also sicherlich gelohnt. Weitere Vorschläge sind willkommen, ich werde schauen, was ich mit meinem Sammelsurium anfangen kann.

Viele Grüße,
Steff
 
Falls Steffchen Interesse an einer U-320 300GB 15krpm Platte haben sollte - mit SCA Anschluss (habe leider keine passenden Adapter dazu, da ich die auf einer Backplane verwendet habe) - würde ich dem System gerne eine gegen den günstigst-möglichen Versand geschenkt spendieren. :) Ich habe einen Adapter, der macht aber nur 80er Sync, durch den Narrow-SCSI Anschluss.
 
Falls Steffchen Interesse an einer U-320 300GB 15krpm Platte haben sollte - mit SCA Anschluss (habe leider keine passenden Adapter dazu, da ich die auf einer Backplane verwendet habe) - würde ich dem System gerne eine gegen den günstigst-möglichen Versand geschenkt spendieren. :) Ich habe einen Adapter, der macht aber nur 80er Sync, durch den Narrow-SCSI Anschluss.

Die Idee ist total gut. Ich habe sogar selbst noch ein paar SCA-Platten als Zubehör zu meiner HPUX-Maschine (Quatum 9,1GB). Leider fehlt mir auch sinnvolle Möglichkeit die Platten anzuschließen. Hübsch wäre eine SCA Backplane, wie sie früher in kleineren Servern zu finden war, z.B. eine DE300i-RSWC160/B. Wenn du mir die genannte Platte zur Verfügung stellst, dann ist eine Anschaffung der Backplane sicher auch drin. Oder hat jemand etwas passendes im Keller rumliegen? ;)

Weiß einer, ob so eine moderne Platte an dem uralt SCSI-Controller überhaupt erkannt wird? Der kann zwar immerhin SCSI-3, aber das ist weit weg von Ultra-320. Ist das Protokoll soweit abwärtskompatibel?
 
Eine SCA Backplane hätte ich da. Leider keine von StoreCase, wie du suchst. Da habe ich nur einen D100i, aber die gebe ich leider nicht her. :) Vielleicht komme ich noch an eine, aber das kann ich nicht mit Sicherheit sagen. Ich könnte mein Angebot von meiner Resterampe erweitern:
SCSI Controller U-320 von LSI (PCBX520-A2) + U-320 3-Port Backplane (macht mit 3 Platten im RAID 0 auch wirklich 320MByte/s :p) aus FSC Server. Dazu ein Kabel für U320. -> Die Backplane terminiert selbstständig.

Und die Platte ist traurigerweise nur eine 10.000rpm. :( Habe mich da irgendwie versehen. HP gelabelt MAW3300NC. Gegen Adresse sollte das zusammen in ein Paket von 2kg passen.
Viele Grüße.

Zum Protokoll: Der Vorteil an SCSI-Commands ist, dass sie universell sind (gerade der Vorteil von iSCSI). Sehe da eigentlich keine Einwände.
 

Anhänge

  • P9250100.jpg
    P9250100.jpg
    54,7 KB · Aufrufe: 79
  • P9250101.jpg
    P9250101.jpg
    77,2 KB · Aufrufe: 73
  • P9250102.jpg
    P9250102.jpg
    72,4 KB · Aufrufe: 63
... Ich könnte mein Angebot von meiner Resterampe erweitern ...

Da kann ich nicht "nein" sagen. Eine vernünftige Befestigung für die Backplane sollte ich bauen können.

Der LSI-Controller ist vermutlich hoffnungslos unterfordert. Mein System hat ja nur 32-Bit PCI bei 33 MHz, das reicht (rein theoretisch) für 133MByte/s. Praktisch bleiben davon wahrscheinlich maximal 50MByte/s übrig. Aber auf die Messungen bin ich trotzdem sehr gespannt. Auch der Unterschied von Onboard-Controller zum PCI-Controller könnte interessant sein. Die Anbindung ist ja die gleiche, kann also ein moderner Controller mehr 'raus holen?
 
Das finde ich cool, wenn jemand diese Sachen noch benutzt. Ich habe hier nur ein LTO3 als Backup. Zwar antiquarisch, aber den Bändern traue ich einfach auf die Dauer noch wirklich. :p
Hier mal einen Screenie von der Performance der einzelnen Platte an dem Controller alleine im PCI Slot (vermutlich auch Bus). Der Controller scheint sich auf dem H61 Board ein klein wenig anzustellen. Allerdings lief der in dem alten FSC Rackserver bis zuletzt sehr zuverlässig. :)

Bin sehr gespannt was der Onboard-Controller wuppen wird - und ich hoffe natürlich auf Dokumentation in Form von Bildern hier.
Viele Grüße
 

Anhänge

  • MAW3300NC_perf.jpg
    MAW3300NC_perf.jpg
    77,6 KB · Aufrufe: 80
Bin sehr gespannt was der Onboard-Controller wuppen wird - und ich hoffe natürlich auf Dokumentation in Form von Bildern hier.
Natürlich gibt es Bilder, sobald der Kram hier ist!

Womit hast du den Benchmark-Screen dort gemacht? Es sieht ein wenig wir Gnome aus.. genauer gesagt gnome-disks.

Gerne würde ich auch derart hübsche Bilder präsentieren, ich vermute aber, dass die CPU-Last durch die Grafikausgabe so hoch ist, dass die Ergebnisse nicht mehr wirklich aussagekräftig sind. Dann muss ich mich doch mit den Transfertests von hdparm zufrieden geben. Aber ich werde es auf jeden Fall probieren. Ein X läuft sowieso schon, weil ich unbedingt mal den Windows-Manager I3 für ein so altes System probieren wollte (Screen-Shots folgen!).
 
Habe den Controller gerade mal mit MegaCLI gecheckt. Das funzt alles wie es soll. Der Screenie ist auf einem G530 Celeron entstanden. HDparm bestätigt die Werte aber ebenfalls. Also das sollte dann, solange die CPU nicht in I/O-Wait läuft locker passen. Aber ein "Dual-Core" System sollte das eigentlich an I/O noch schaufeln können. Die CPU Last ist unter write auf meinem Testsystem hier bei faktisch null.

Grafik kannst du darauf fast vergessen. Ich weiß nicht ob Fluxbox einen versuch wert ist. Ich habe mal auf einem Pentium II 400 mit tinycore die Hardware inspiziert. Und das hat erstaunlich gut funktioniert. Der Controller hat sich übrigens auf IRQ 16 angemeldet. Nur schon mal so als Vorwarnung. Die GUI des Controllers funktioniert mit Maus wenn überhaupt nur via P/S2. Mit "Tabben" kommt man da aber recht gut durch. Paket ist gepackt, versuche nun die Hauspost noch abzupassen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh