Beiträge von Arnulf zu Linden

    Ein Pentium-S 200 (200 MHz @ 66 MHz FSB) läuft auf einer Hauptplatine MSI MS-5117A mit 64 MiB RAM (optional 96 MiB RAM). Das Ding lief einige Jahre als fli4l-router, stand dann einige Jahre in der Ecke rum und sollte nun mit Windows 95c (optional 98SE) und Slackware-9.1 (optional 10.2) einer anderen Nutzung (Messwerte über RS232 einsammeln, zeitunkritisch) zugeführt werden. Beim Einschalten fiel dann auf, dass die auf der Hauptplatine verbauten 256 KiB L2-Cache (pipeline burst SRAM) im BIOS-Statusfenster nicht angezeigt werden. cachechk erkennt ebenfalls keinen L2-Cache.

    Ist nun der L2-Cache hinüber oder kann es auch "nur" das (gesockelte) Tag-RAM dahin gerafft haben?

    Lässt sich die Hauptplatine ganz ohne L2-Cache noch sinnvoll (s.o.) einsetzen oder wird das so unerträglich lahm, dass die besser gleich in den Elektroschrott wandert?

    Jetzt wird es skurril.
    Das MSI PM8PM-L läuft stabil mit einem Intel Pentium D 820 SL8CP (Smithfield; 2,8 GHz ×2; TDP 95W). Damit scheitert der stabile Betrieb des Pentium D 950 nicht an seiner TDP von 95W und auch nicht an der Tatsache, dass der ein "Zweikernprozessor" (genau genommen zwei Einkernprozessoren in einem Gehäuse) ist. Vcore ist auch nicht das Problem.

    Anscheinend mag die Hauptplatine einfach den Pentium D 9xy (Presler) nicht. Wenn MSI allerdings nur mal schnell den Pentium D 960 drauf gesteckt hat und dann gesehen hat, dass das BIOS den korrekt erkennt, dann sind alle Pentium D 9xy mit max. 95W TDP mal eben auf der "CPU compatibility list" gelandet.

    Somit bleibt der Pentium D 950 bis auf Weiteres heimatlos.
    Mit dem Pentium D 820 (Hauptplatine unterstützt Pentium D mit max. 95 W TDP, daher kein Pentium D 830 oder 840) auf dem MSI PM8PM-L mit 2 GiB RAM (mehr geht leider nicht) dürfte ein System bestehen, dass seine maximale Ausbaustufe erreicht hat. Nur 2 GiB RAM wird für Linux x86_64 natürlich recht eng.


    Unterstützt das Medion Bios die CPU?

    Keine Ahnung, habe ich nicht ausprobiert.


    Nach einem fehlerfreien Druchlauf memtest86+ wurde erst mal das besch☠☠☠ene Medion-BIOS durch das aktuelle MSI-BIOS ersetzt.

    ;)


    Es kann auch sein das msi die boards für Medion ultraknapp kalkuliert hat, und die spannungsversorgung schlicht nicht ausreichend ist. Oem boards sind häufig mal heikel. Hab nen Fujitsu oem bei eBay Händler gekauft, wo es auch nur hieß c2d bis 65 watt Leistung. Drüber würden auf dem Papier her laufen, aber halt nicht stabil 20 Cent am board gespart, und schnell einige Rendite mitgenommen.

    Die Hauptplatine enthält keinen sichtbaren Hinweis auf Medion oder generell OEM. Nach dem Ersatz des Medion-BIOS durch das MSI-BIOS ist auch beim Startvorgang nichts mehr von Medion oder OEM zu erkennen. Das heißt natürlich nicht, dass da nicht doch irgendwo gespart wurde und dadurch ein Prozessor mit 84 W TDP stabil läuft, aber einer mit 95 W TDP nicht mehr. Das Fiese ist hier ja, dass der instabile Betrieb erst in Verbindung mit einem Betriebssystem auftritt. Das BIOS hat kein Problem mit dem Prozessor und selbst memtest86+ läuft ja fehlerfrei. Letzteres lässt den Schluss zu, dass die Instabilität erst auftritt, wenn beide Kerne des Prozessors belastet werden. Letztlich bleibt natürlich auch die Möglichkeit, das die Angaben von MSI zu den kompatiblen Prozessoren schlicht falsch sind.


    Abit AW8D kann keine C2D
    Und nicht grad ein Billigboard damals gewesen..

    Und auch heute nicht günstig zu bekommen.

    Fast hätte der heimatlos gewordene Intel Pentium D 950 SL9K8 (Presler; 3,4 GHz ×2) ein neues Zuhause gefunden, aber eben nur fast.
    Im Zuge einer PC-Aufrüstung fielen mir folgende funktionsfähige Komponenten in die Hände, ein Intel Pentium 4 620 SL8AB (Prescott 2M; 2,8 GHz HT) auf einem MSI PM8PM-L mit 2 GiB DDR2-RAM PC-800 (Vollbestückung) und eine nvidia GeForce 6200 (256 MiB RAM; AGP 8×). Nach einem fehlerfreien Druchlauf memtest86+ wurde erst mal das besch☠☠☠ene Medion-BIOS durch das aktuelle MSI-BIOS ersetzt. Nach diversen erfolgreich verlaufenen Tests (memtest86+, Kernel kompilieren unter Linux, glxgears auf KDE4) und einer Internetrecherche wurde dann der Pentium D 950 eingebaut. Laut MSI kann die Hauptplatine mit dem Prozessor umgehen. Der Prozessor wird vom BIOS korrekt erkannt. memtest86+ läuft fehlerfrei durch. Wenn aber ein Linux (mehrere getestet, alle laufen stabil, wenn der Pentium 4 620 auf dem PM8PM-L werkelt) ins Spiel kommt, wird es seltsam. Der Kernel startet normal. Danach kann aber nahezu jeder beliebige Befehl auf der Konsole oder unter X, sofern dies überhaupt startet, das System mit einer "Kernel panic" ins Nirvanan schießen. In einem Fall wurde gleich ohne Vorwarnung ein reboot ausgelöst.

    Was ist da los?

    Da nur Hardware eingesetzt wurde, die bekanntermaßen funktioniert, scheidet ein Hardwarefehler aus.

    Nach der Liste sind die meisten Grafikkarten schon in den passenden Systemen gelandet. Lediglich die "nvidia GeForce FX5200GT 256 MiB AGP 8×" wird etwas "nach unten" wandern.


    wobei es da wohl auf den Unterschied DX8 vs. DX9 ankommt.

    Seit wann läuft DirectX unter Linux?


    Für die nvidia-Grafikkarten wird z.Z. der proprietäre nvidia-Treiber genutzt, für die ATI-Grafikkarten der xorg-Treiber + Kernel-DRI-Modul. Letzteres geht nicht mit der Radeon HD, weshalb die erst nach einem Update auf Slackware64-14.0 (oder höher) und einen halbwegs aktuellen Kernel 3.x zum Einsatz kommen kann.

    Die nachfolgend aufgelisteten Grafikkarten möchte ich den verschiedenen verfügbaren Systemen so zuordnen, dass die leistungsstärkste Grafikkarte in das leistungsstärkste System kommt usw..

    AGP (ia32-Systeme, Linux 32-Bit, Kernel 2.6.x):

    • nvidia GeForce 6800 256 MiB AGP 8×
    • nvidia GeForce 6600GT 128 MiB AGP 8×
    • nvidia GeForce 6200A 256 MiB AGP 8×
    • nvidia GeForce FX5700LE 128 MiB AGP 8×
    • nvidia GeForce FX5200GT 256 MiB AGP 8×
    • nvidia GeForce FX5200 128 MiB AGP 8×
    • nvidia GeForce4 Ti4400 128 MiB AGP 4×
    • ATI Radeon 9600XT 256 MiB AGP 8×
    • ATI Radeon 9550 256 MiB AGP 8×
    • ATI Radeon 9000 mit TV-Tuner 64 MiB AGP 4×


    Die meisten in Frage kommenden Systeme bieten einen AGP 8× oder AGP 4× Steckplatz. Die Grafikkarten funktionieren in AGP 8× und AGP 4× Steckplätzen, die FX5200 und die Radeon 9000 auch in AGP 2× Steckplätzen.

    PCIe (x86_64-Systeme, Linux 64-Bit, Kernel 2.6.x):

    • nvidia GeForce GT220 1 GiB PCIe x16
    • nvidia GeForce 9400GT 1 GiB PCIe x16
    • nvidia GeForce 8500GT 512 MiB PCIe x16
    • ATI Radeon HD6570 2 GiB PCIe x16 (z.Z. noch nicht im Einsatz, sinnvoll nur mit Kernel 3.x und KMS)


    Wie wichtig ist eigentlich die Speichergröße (hier AGP ab 128 MiB, bis auf die eine mit nur 64 MiB; PCIe ab 512 MiB)?

    Für die nvidia-Grafikkarten wird z.Z. der proprietäre nvidia-Treiber genutzt, für die ATI-Grafikkarten der xorg-Treiber + Kernel-DRI-Modul. Letzteres geht nicht mit der Radeon HD, weshalb die erst nach einem Update auf Slackware64-14.0 (oder höher) und einen halbwegs aktuellen Kernel 3.x zum Einsatz kommen kann.

    Wie müssen also nach Leistung der Grafikkarten die obigen Listen umsortiert werden?


    Ich habe schon einige vServer administriert und habe selbst Ubuntu/Fedora fast über ein Jahr lang auf meinem System für den Produktiveinsatz konfiguriert und benutzt.
    BTW: Ich bin gewillt, mich durch Dokumentationen zu hangeln und MAL was zu frickeln

    Unter diesen Voraussetzungen, die du vielleicht zwecks Vermeidung von Missverständnissen in deinem Startbeitrag hättest erwähnen sollen, wäre auch die Slackware bzw. Slackware64 etwas für dich. Slackware ist z.Z. die älteste aktive Distri, und im Gegensatz zu den bunte-Bilder-Distris wie etwa Ubuntu oder SuSE finde ich die sehr übersichtlich. Installiert wird komplett im Textmodus. Die Konfiguration erfolgt über Textdateien (Ausnahme: GUI mit den jeweiligen Bordmitteln). Erst wenn das System "steht" (Kernel passend zur Hardware kompiliert - auf Standardhardware meist kein "Muss", Netzwerk eingerichtet, usw.) werden X und die GUI konfiguriert. GNOME muss man allerdings zu Fuß nachschieben, aber da gibt es u.U. "inoffizielle" Slackware-Pakete.
    Anm.: Warum GNOME aus der Slackware rausgeflogen ist, kann ich, obwohl ich es nicht nutze, nicht nachvollziehen.


    Wollte hier eh platt machen.
    Ich will als Distro Antergos nehmen und mal GNOME3 richtig testen. Gute Idee, oder nicht? Was soll ich beachten?
    Würde dann auch gleich mal vim etc. ausprobieren.

    Die Auswahl der Distro hängt von mehreren Faktoren ab:

    • persönliche Vorliebe
    • vorhandene Linux-Erfahrung
    • Einsatzzweck
    • Hardware, auf die installiert werden soll
    • Ist aktuelle Software wichtig?
    • nur OSS gewünscht oder auch proprietäre Software erlaubt


    Wenn die Festplatte genug Platz bietet, würde ich nicht "entweder oder", sondern "sowohl als auch" durch eine entsprechende Partitionierung ermöglichen, z.B. so für ein Linux und ein WinNT-Derivat:

    /dev/sda1 7 HPFS/NTFS (Windows Programmpartition)
    /dev/sda2 83 Linux (ext3 bei Kernel 2.6 oder ext4 bei Kernel 3.x, Linux /boot)
    /dev/sda3 83 Linux (ext3 bei Kernel 2.6 oder ext4 bei Kernel 3.x, Linux /)
    /dev/sda4 f W95 Ext'd (LBA) (erweiterte Partition)
    /dev/sda5 c W95 FAT32 (LBA) (gemeinsame Datenpartition für Linux & Windows)
    /dev/sda6 7 HPFS/NTFS (Windows Auslagerungspartition)
    /dev/sda7 82 Linux swap (Linux Auslagerungspartition)

    Diese Partitionierung ist natürlich nur eine Möglichkeit, funktioniert aber auch mit älteren Linux- & Windows-Versionen. Mit aktueller Software gibt es mehr Möglichkeiten.

    vim ist -äh- seeeehr speziell. ;)

    Ausgangssituation: Sockel-7-AT-Hauptplatine bestückt mit Pentium-S 200 und 128 MiB RAM; cacheable RAM area = 64 MiB, nicht erweiterbar

    Auf der Kiste soll ein Win9x, zur Auswahl stehen Win95c oder Win98SE, installiert werden. Eine Abrüstung auf 64 MiB RAM kommt nicht in Frage, da auf der Kiste auch noch ein Linux installiert ist, das mit nur 64 MiB RAM keinen Spaß macht.

    Bei Linux gibt es zwei Möglichkeiten, mit obiger Kiste umzugehen. Entweder man lässt es einfach laufen und baut darauf, dass der Linux-Kernel das RAM von unten nach oben füllt, also die wirklich wichtigen Sachen alle im cached RAM laufen. Oder man kompiliert einen entsprechenden Kernel, dem man dann per Bootparameter "mem=64M slram=ramswap,64M,+64M" mittteilen kann, dass er nur die ersten 64 MiB RAM als Arbeitsspeicher nutzen soll und im Rest, dem uncached RAM, eine RAM-Disk anlegen soll.

    Gibt es eine ähnliche Möglichkeit (nur cached RAM als Arbeitsspeicher, Rest als RAM-Disk) für Win9x?


    Grafikkarte ist eine Cirrus Logic im ISA Steckplatz, da ich keine VLB Grafikkarte habe. CPU ist ein 486 SX 25.

    Handelt es sich bei Grafikkarte, Prozessor und RAM um funktionsfähige Teile? Wurden diese auf einem anderen System getestet?

    Einen getesteten i486DX-33 und evtl. auch getestete PS/2-FPM-Module mit 4 MiB Kapazität und Organisation ×36 kann ich dir anbieten, wenn es nicht extrem eilig ist.


    Mit einem FPM Modul geht es nicht, mit 2 FPM Modulen oder 4 SIMM Modulen geht es auch nicht :(
    Gerade habe ich mal einen Biospiepser angeschlossen, der Piept 1x lange. Da es ein Award Bios ist müsste das ein Speicherproblem sein. Aber es funktioniert ja mit keinem der Speicher? seltsam.

    Laut TH99 nimmt die Hauptplatine nur SIMM, das ×9 organisiert und PS/2 FPM, dass ×36 organisiert ist. Derartige Module haben i.d.R. 9 Chips pro Seite. Wenn nur 8 Chips pro Seite drauf sind, sind die ×8 (SIMM) oder ×32 (PS/2 FPM) organisiert. Bei Modulen mit weniger als 8 Chips pro Seite ist die Organisation u.U. nicht so einfach feststellbar. Außerdem mögen einige Hauptplatinen solche Module nicht. Die Hauptplatine verträgt lt. TH99 auch nur "single sided" organisierte PS/2-FPM-Module mit den Kapazitäten 1 MiB, 4 MiB und16 MiB pro Modul.

    Wurden zum Test bekanntermaßen funktionierende Speichermodule verwendet?


    Tja, ich habe vor einiger Zeit das im Titel genannte VLB Board bekommen, soweit sieht es ordentlich aus, aber es Funktioniert nicht so, wie es soll. Nach dem einschalten kommt kein Bild und die CPU wird nach einigen Sekunden recht warm und heizt sich dabei recht schnell auf. Schneller als bei dem 486er ISA Board, was ich auch noch habe.

    Grafikkarte ist eine Cirrus Logic im ISA Steckplatz, da ich keine VLB Grafikkarte habe. CPU ist ein 486 SX 25.

    Liegt das das kein Bild kommt nur daran, das eine ISA Grafikkarte statt einer VLB Grafikkarte drinnen ist, hat das Mainboard einen Schaden oder gibt es irgendein anderes Problem?

    An der ISA-Grafikkarte darf das nicht liegen! Sind alle Steckbrücken richtig gesetzt? Wie ist die Bestückung mit RAM? Und auf TH99 ist auf der Hauptplatine ein Dallas-Uhrenmodul abgebildet. Wenn in dem Ding die CMOS-Stütze tot ist, kann das zu den beschriebenen Symptomen führen. Leider klappt es nämlich nicht immer, dass das BIOS dann trotzdem startet und einfach "CMOS battery low" meldet. CMOS-Reset schon versucht? Bei so alter Hardware kann ein Schaden natürlich auch nicht ausgeschlossen werden.


    naja was will man da raus finden, jumper hats keine, den stärksten 386er wo gibt verbaut, Baujahr *92 oder später. bios hat sicher ne 504mb grenze für hdds.
    Maximum ram wird entweder 8x4mb (32) sein

    Die Hauptplatine läuft mit folgenden Komponenten:

    • Koprozessor IIT 4C87-40
    • RAM: 32 MiB = 8× 4 MiB SIMM 70 ns
    • Grafik: Trident TVGA8900B (1 MiB)
    • Ethernet: 3Com 3C509B
    • Sound: Creative Labs Vibra16C
    • 3× RS232
    • 2× Parallelport
    • 2× ISA-IDE-Controller
    • Diskettenlaufwerk: 3½“ 1,44 MB
    • Festplatten: IBM DCAA-34330 (4,3 GB IDE) + Seagate ST32122A (2,1 GB IDE)
    • CD-ROM-Laufwerk: IDE

    Natürlich hat das BIOS die 1024-Zylinder-Grenze (504 MB-Grenze), was die Slackware 9.0 aber nur dahingehend interessiert, dass /boot mit dem Kernel darin komplett innerhalb der 1024-Zylinder-Grenze liegen muss. Da soll noch FreeDOS drauf, und dann könnte ein DDO Thema werden, um eine gemeinsam nutzbare FAT-Partition anzulegen. Für FreeDOS + Programme würden 504 MB ja reichen.


    so blödsinn wie 14MB wie bei meinem 286/386 combi board

    Beim 286er ist ohne Trickserei bei 16 MiB RAM Schluss, wobei von den 16 MiB noch 384 KiB (Adressbereich von 640 KiB bis 1024 KiB) ausgeblendet werden. Weiterhin gehen einige Adressbereiche für die Geräteadressen verloren und bei Bestückung mit 16 MiB RAM greift auch ein "memory remapping"¹ nicht mehr.
    Wenn wirklich nur mit 14 MiB bestückt werden darf, wäre das schon seltsam, ginge aber bei acht Steckplätzen, da die SIMMs für 286er nur pärchenweise gesteckt werden müssen.

    ¹So eine Option bietet das BIOS der Hauptplatine TOPCAT286, die Überraschung war damals groß, denn eigentlich denkt man bei "memory remapping" an Systeme mit 4+ GiB RAM.

    OT:


    hab in nen 486er
    da der aber kein cache hat, reißt es den rechner auch nicht raus. kack compaq, so nen cachemodul werde ich wohl nie bekommen.

    Wie soll dieses Cache-Modul denn aussehen? Es sind sicher nicht die üblichen COAST-Module, denn die gibt es immer wieder mal in der Bucht. Ich habe da mal 'ne Tüte mit 10 Stück geschossen. 9 Stück sind die normalen COAST-Module, aber das 10. Cache-Modul kann ich keinem System zuordnen. Es hat 128 KiB 24 ns Cache-RAM drauf, dürfte also für etwas Älteres als ein Sockel-7-System sein, und sieht auf den ersten Blick wie ein PS/2-RAM-Modul aus, ist aber länger und würde daher nicht in einen PS/2-Speichersteckplatz passen (Foto zusammen mit 'nem PS/2-RAM-Modul zum Vergleich bei Bedarf). Dieses Modul kann ich als "ungetestet, Funktion unbekannt" abgeben.