(11.11.2013 03:43)Aqua schrieb: Ä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:
Code:
/**
* 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."