zur Abwechselung mal wieder was Schlichtes (KDE 3.5.10 auf Slackware64-13.0, Kernel 2.6.39.4):
Mit KDE4 stehe ich noch etwas auf Kriegsfuß, werde aber wohl (unter anderem) wegen musescore, das Qt4 (ältere Versionen) oder Qt5.1 (aktuelle Version) braucht, nicht drumrum kommen, weshalb der KDE4 momentan nur auf meinem x86_64-Ausprobier-PC läuft.
Nein, 720K 5,25" habe ich nicht im Bios. Finde ich auch komisch. Sagt diese Größenangabe was aus?
720K 5,25" ist eine 2S4D-Diskette.
Damit wird der für Windows verfügbare Ram auf 512MB eingeschränkt bzw. der restliche Ram bleibt komplett unbenutzt.
Jetzt möchte ich aber den überschüssigen Ram mittels Ramdisk nutzen. Für die Auslagerungsdatei etc.
Vielleicht ist die Gavotte RAM-Disk dafür geeignet. Das Programm eignet sich nicht nur, um RAM oberhalb der 4GiB-Grenze unter Win 32-Bit nutzbar zu machen, es kann auch RAM-Disks innerhalb der 4GiB-Grenze erstellen. Ich habe es allerdings nur unter WinXP 32-Bit genutzt.
Selbst ein Altes K6/2 oder K6/3 System kann mit entsprechend schneller HDD 52x brennen.
Ich hab testweise mal einen DVD-Brenner in meinem K6/3 400 gesteckt und CD's lassen sich problemlos mit 48x Brennen, 52x ist nur 600 KB/s schneller und würde auf meinem K6/3 auch noch klappen.
Läuft der DVD-Brenner am Onboard-IDE-Controller mit udma2 oder nur mit mdma2?
Hab sogar noch ein S478 P4.. im "Stylischen" Gehäuse, könnte da sogar richtig Dampf reinsetzen (hab noch nen 2,6GHz..)
Soll der auch weg? Daran hätte ich ggf. Interesse. Was steckt da alles drin?
Du kannst ja versuchen mit dem 52x Brenner zu brennen,
Nee, der war nur zum Testen, ob es evtl. am 16x/12x/40x-Brenner lag. Das Ding ist mit dem Einbau des Yamaha CRW8824E nun auch durch, der PC steht wieder im Stapel zusammen mit den anderen alten Kisten. Der 52x/32x/52x-Brenner wird dann mal in ein System kommen, das damit bei voller Geschwindigkeit brennen kann.
Ähm wegen den 768MB Ram und selbstverständlich:
Mit einer K6-2 CPU wird sich die Cacheable Area eines P5-A/B weniger darüber freuen.
Die cacheable RAM area interessiert das doch gar nicht, die liegt einfach bei 128 MiB. Na und? Linux belegt das RAM von unten nach oben, also werkeln Kernel usw. innerhalb der cacheable RAM area. Und uncached system RAM ist immer noch viel schneller als swap. Bei Win9x mag das mit der cacheable RAM area noch eine Überlegung wert sein, aber WinXP mit nur 128 MiB RAM will man wohl eher nicht erleben. WinXP läuft ohnehin erst mit einem K6-III oder K6-2+ und 768 MiB RAM erträglich (ausprobiert mit K6-2 500 vs. K6-III 400 bei 768 MiB RAM).
Das war aber alles früher, denn aktuell werkelt ein K6-2+ in dem System, und mit dem liegt die cacheable RAM area bei 4 GiB.
Das udma-Problem liegt im Kerneltreiber begraben. In linux-2.6.31.5/drivers/ide/alim15x3.c findet sich dazu:
/**
* ali_udma_filter - compute UDMA mask
* @drive: IDE device
*
* Return available UDMA modes.
*
* The actual rules for the ALi are:
* No UDMA on revisions <= 0x20
* Disk only for revisions < 0xC2
* Not WDC drives on M1543C-E (?)
*/Einen Grund für diese udma-Restriktionen konnte ich aber nicht im kernel-source-tree oder im Internet finden.
lspci -v ergibt für das Asus P5A-B: ALi Corporation M5229 IDE (rev c1)
Das ist genau eine Revision zu niedrig.
Also wurde ein quick & dirty-patch angewendet: An den entsprechenden Stellen in alim15x3.c wurde 0xC2 durch 0xC0 ersetzt und dann ein neuer Kernel damit kompiliert. Dieser Kernel erkennt beide Laufwerke mit udma2. Von /dev/hdd (DVD-ROM) lässt sich lesen, aber nicht von /dev/hdc (CD-Brenner). Auch ein Tausch des 16x/12x/40x-Brenners gegen einen 52x/32x/52x-Brenner brachte keine Änderung. Das führte zum Test folgender Konfiguration:
/dev/hda Festplatte udma4 @ udma2
/dev/hdb DVD-ROM udma2 @ udma2
/dev/hdc Festplatte udma5 @ udma2
/dev/hdd CD-Brenner udma2 @ udma2
Bie dieser Konfiguration kann von beiden optischen Laufwerken gelesen werden, aber der CD-Brenner lässt sich partout nicht zum Brennen überreden. Der 52x/32x/52x-Brenner wurde hier nicht mehr versucht, da der eh zu schnell für das System sein dürfte.
Schluss, Ende, Aus - geht nicht!
Der unpatched-Kernel wurde wieder aktiviert und der 16x/12x/40x-Brenner durch einen alten 8x/8x/24x-Brenner ersetzt, der nur max. mdma2 unterstützt. Nun laufen die beiden optischen Laufwerke wieder nur mit mdma2, dafür funktioniert aber auch das Brennen. Für die zusätzliche Festplatte wäre in dem Mini-AT-Tower auch kein Platz gewesen und mit mdma2 laufen die beiden optischen Laufwerke wieder am sekundären IDE-Controller, bremsen also die Festplatte am primären IDE-Controller nicht aus.
Somit haben der 8x/8x/24x-Brenner und die Hauptplatine nach Jahren der Trennung wieder zueinander gefunden, denn der Yamaha CRW8824E lief schon damals an genau diesem Asus P5A-B, als das System (damals K6-2 500; 256 MiB RAM, später 512 MiB RAM; dazu 'ne lahme nvidia Vanta 16 MiB AGP 2×; aber schon zwei "große" udma5-Festplatten an einem PDC20267; OS: SuSE Linux 6.2, später 7.1 / Win98SE) noch unter'm Schreibtisch seine tägliche Arbeit verrichtete. Mit dem Yamaha CRW8824E hat das System sogar wieder einen Sinn, denn dieser Brenner liest Audio- und Daten-CDs aus, an denen sich zumindest damals die meisten anderen Laufwerke die Zähne ausgebissen haben. Der las sogar mal eine gepresste CD aus, bei der das Loch nicht genau in der Mitte war, und die damals in keinem anderen Laufwerk bei mir und beim Besitzer der CD ausgelesen werden konnte. Nach über einer Stunde bei Höllenlärm aus dem Brenner war tatsächlich ein vollständiges iso-Image dieser CD auf der Festplatte gelandet.
"Früher, als noch alle Prozessoren in den Sockel-7 passten, war alles besser." 
D [14/Nov/2013:19:24:21 +0100] [Job 8] Failed to get profile filename!
D [14/Nov/2013:19:24:21 +0100] [Job 8] no profiles specified in PPD
Kaputte oder inhaltsleere PPD?
Das zeug ist reserviert... schau mal genauer
Ich bring es nicht übers Herz den Kram wegzuschmeißen... also bitte, adoptiert ein bisschen Hardware
Das klang irgendwie nach "Ich werd' das Zeug einfach nicht los - vor längerer Zeit reserviert hin oder her."
Wenn's weg ist, ist's halt weg. Wenn die Reservierer es nicht mehr haben wollen oder nicht aus dem Quark kommen und Du entsorgen musst, würde ich es nehmen.
Die 8600gt geb ich nicht nur für Versand ab !_!
Dann viel Spaß bei ebay damit. Die hätte ich nur vor der Tonne retten wollen.
merkwürdig... Habe selber noch zwei ASUS P5A - Platinen im Einsatz, solche Probleme sind mir allerdings nie vorgekommen. Wobei ich allerdings sagen muß, ich hatte nie ein Linux auf diesen Rechnern am Rennen..
Jedenfalls meldet mir Dr.Hardware v. 2.xx unter Win98 brav den UDMA/33 Modus und keinen PIO4
Dann muss ich mal in den SRC vom Kerneltreiber schauen, ob da etwas Verdächtiges drin steht. Das BIOS meldet ja auch udma2, obwohl das genau gar nix heißen muss.
Ähm: mdma2 != PIO4
PIO4 wäre echt schlimm. mdma2 ist halt DMA mit etwa halber Geschwindigkeit von udma2.
Nebenbei.. die letzte Bios Version hast du wohl drauf, oder? (1011beta?) ...
Ja, auf dem Biostar entsprechend.
Aah... nochwas, welcher Revisionen sind denne in deinem Besitz?
Asus P5A-B & Biostar M5ALA: Ali Aladdin V Rev. E
Asus P5A: Ali Aladdin V Rev. G
Daher werkeln auf dem Asus P5A-B ein K6-2+ 550 @ 600 MHz und auf dem Biostar M5ALA ein K6-III 450, auf dem P5A aber nur ein K6-2 550 wegen der Rev. G. Selbstverständlich sind alle drei Systeme mit je 768 MiB SD-RAM PC-133 bestückt.
Ich bring es nicht übers Herz den Kram wegzuschmeißen... also bitte, adoptiert ein bisschen Hardware
Bevor es in der Tonne landet, würde ich Folgendes gegen Porto & Verpackung nehmen:
Folgendes tritt bei drei Hauptplatinen (Asus P5-A, Asus P5A-B, Biostar M5ALA) mit dem "Ali Aladdin V"-Chipsatz und unterschiedlichen Linux-2.6-Kerneln (auf Festplatte: Slackware 13.0 mit Kernel 2.6.31.5, oder im CD-Brenner: Knoppix 5.01) auf:
Werden an einen der beiden oder beide IDE-Controller eine oder mehrere Festplatten, die mindestens udma2 beherrschen, angeschlossen, so laufen diese erwartungsgemäß mit udma2.
Werden an einen der beiden oder beide IDE-Controller eine oder mehrere "optische Laufwerke" (CD-ROM, CD-RW, DVD-ROM), die udma2 beherrschen, angeschlossen, so laufen diese nur mit mdma2.
Zumindest melden dmesg und hdparm dies.
DOS hwinfo bringt auch keine Klärung, da es alle möglichen Transfermodi der Laufwerke anzeigt, auch wenn der IDE-Controller gar nicht alle unterstützt.
Liegt das am Kerneltreiber oder ist das Problem in der Hardware eingebaut?
und wie geht das damit ? hab echt nur einen da da is wichtiges druf alle anderen ausgeliehen, cd methode wär mir lieber
Erst mal muss z.B. mit Hilfe des Handbuchs zur Hauptplatine geklärt werden, ob diese überhaupt ein BIOS-Update von einem "USB mass storage device", also z.B. einem USB-Stick, unterstützt.
Das BIOS Image (eine Datei, Dateigröße ist ein Vielfaches von 2; nicht das iso-Image für CD oder Diskette!) wird auf einen USB-Stick kopiert, der mit vfat (FAT16 oder FAT32) formatiert ist. Weitere Dateien und Verzeichnisse auf diesem USB-Stick stören nicht, er sollte nur nicht komplett voll sein, damit noch Platz für das Backup des alten BIOS vorhanden ist.
Der USB-Stick wird an den PC gesteckt, auf dem das BIOS-Update ausgeführt werden soll.
Im BIOS dieses PC werden "USB legacy support" und "USB disk support" (o.ä., z.B. "USB mass storage device supprt") aktiviert.
Dann wird die BIOS-Update-Prozedur gestartet.
es läuft auch nicht jedes Linux drauf. Aktuelle Distributionen bekommen Probleme, weil der CPU ein Befehlssatz fehlt 'cmov'.
Das Fehlen von cmov lässt sich meist mit dem Kompilieren eines zum Prozessor passenden Kernels lösen. Problematisch wird es, wenn die Distri keinen Installationskernel für ältere Prozessoren ohne cmov mehr enthält oder die enthaltene Software für Intels 6. Prozessorgeneration (ab Pentium II/Celeron) bzw. AMDs 7. Prozessorgeneration (ab Athlon/Duron) kompliliert ist.
Eine Knoppix 7 startet meines Wissens nicht auf Prozessoren ohne cmov, Knoppix 5 geht.
Jetzt mein Problem: Egal was für ein System ich nehme der Bootvorgang bleibt jedes mal stehen (freeze) oder es kommt irgend ein fehler mit dem Kernel und danach auch "freeze"An was könnte das liegen? Ev Ram defekt ?
Welche "kernel errors" kommen den?
Sofern ich mich erinnern kann, läuft mein internes IDE-Zip-100-Laufwerk am Scenic (Intel i815E + ICH) unter Windows Me auch nur im PIO-Modus – das DMA-Häkchen im Geräte-Manager hatte sich nach einem Neustart zurückgesetzt.
Es scheint wirklich ein DMA-Problem zu sein, denn am AsRock K7Upgrade-600 hat der Kernel-Bootparameter "ide_core.nodma=1.0" das Problem ebenfalls gelöst. Das zip-Laufwerk darf weiterhin mit "hdparm -c1u1" bestiefelt werden.
Also bei mir läuft sogar ein internes SCSI Zip 100 ohne Probleme unter Scientific Linux 6
Da war es, das entscheidende Wort: SCSI
Das zip100 läuft jetzt am K7S5A, allerdings nur im Pio-Mode 3 
Dem Kernel ein "ide_core.nodma=1.0" zu verabreichen, reichte aus. Bei den Sockel-Super-7-Systemen war so etwas nicht nötig, aber ich weiß jetzt nicht mehr, ob das Ding daran nicht auch ohne DMA lief. Die Hauptplatinen konnten auch nur max. udma2 und auch das funktionierte mitunter nicht mit Laufwerken für Wechseldatenträger (z.B: Asus P5A-B mit DVD-ROM udma2 an IDE-Controller udma2: Transfermode max. mdma2 einstellbar).
Wie ist es gejumpert, und liegt noch was anderes auf dem kanal?
Master, wird ja auch korrekt als /dev/hdc erkannt. Es hat den secondary IDE für sich allein.
Hatte auch schon in solchen Kisten auch Atapis am laufen. aber mit windows.
Kann es evtl. sein, dass Windows die Dinger im Pio-Mode laufen lässt? Linux nimmt standardmäßig DMA. Das werde ich nachher mal gewaltsam für secondary IDE abwürgen.
Hab ein zip in meinem i5 und das tut 1a...also liegts an der linuxgrütze
Proprietären Müll aus Redmont/USA wird es auf den erwähnten Systemen nicht geben!
Alle Versuche, ein internes zip-Laufwerk an einem Sockel-A-System stabil in Gang zu kriegen, sind bisher gescheitert
Hardware:
Software (auf beiden Systemen):
Gestest wurden alle Kombinationen mit einem zip-Laufwerk am Onboard-IDE-Controller als Secondary Master, also /dev/hdc.
Bei allen Kombinationen passiert Folgendes:
Nach dem Systemstart funktioniert mit dem ersten eingesteckten zip-Medium genau einmal mount, rw-Zugriff auf das Medium und umount. Wird dann ein weiteres oder das selbe zip-Medium nochmal eingsteckt, friert die Console nach dem mount-Befehl ein. Auf das Medium kann nicht zugegriffen werden. Auf den anderen Consolen kann weiter gearbeitet werden, ein shutdown lässt sich auslösen. Allerdings fährt das System nicht komplett herunter, sondern friert kurz vor dem Ende ein (K7S5A) oder hängt in einer Endlosschleife (K7Upgrade-600). Die letzten Meldungen vor dem Einfrieren des K7S5A:
/dev/root umounted
Remounting root filesystem read-only.
/dev/hde3 on / type ext3 (ro)
Shutdown: hdcBeim K7Upgrade-600 kommt zum Ende eine kryptische ACPI-Fehlermeldung, danach "hdc: lost interrupt" mit irgendwelche IDE-reset-Versuchen im Wechsel als Endlosschleife.
Dann hilft nur noch der Ausschalter.
Im Internet findet sich der Hinweis, das zip-Laufwerk im BIOS zu deaktivieren. Allerdings ändert das genau gar nichts, da der Linux-Kernel nach dem Start das BIOS für die Laufwerksverwaltung nicht mehr benutzt. Gibt es für das Problem eine Lösung am Sockel-A-System oder bleibt nur der Einbau der zip-Laufwerke in wesentlich ältere Kisten? Wie alt? Sockel-Super-7 geht, Sockel-370?
Dazu auch etwas Kleinkram (RAM, Lüfter, Kühler, Netzwerkkarten, Prozessoren..)
Was ist das für "Kleinkram" und wurde der funktionsfähig oder als Schrott ausgebaut?
An "funktionsfähig ausgebaut" wäre ich gegen Versandkostenerstattung ggf. an RAM, Prozessoren und Netzwerkkarten interessiert.
