Beiträge von Arnulf zu Linden

Zitat von Xaar

Ja und? Diese Boards sind für solche Prozessoren vorgesehen, auch wenn sie bei deren Release noch nicht erhältlich waren. Und wenn sie nicht dafür gedacht sind - weils bspw. keinen BIOS-Support dafür gibt - dann gehen die CPUs auch nicht.

Hmm …
Der K6 233 (Model 6) wurde mit Vcore = 3,2 V & Vio = 3,3 V für den Sockel-7 "split voltage" gebaut. Dass der auch auf dem "einfachen" Sockel-7 mit Vcore = Vio = 3,3 V funktioniert, dürfte eher Zufall sein. Sonst hätte AMD den wohl gleich mit Vcore = Vio gebaut.
Der Celeron 533 (Mendocino) ist für den Sockel-370 bestimmt. Da scheint es sehr unwahrscheinlich, dass die Konstrukteure der ersten Slot-1-Hauptplatinen schon an einen Celeron (Mendocino) auf Slotket dachten.

Das mit dem BIOS-Support ist auch so eine Sache. Das kann, muss aber nicht bedeuten, dass das System dann nicht startet. Ein Sockel-7-System mit einem K6 233 (Model 6) startete damit und lief auch stabil, allerdings zeigte das BIOS einigemaßen sinnfrei einen "i486DX/2 66 MHz" an. Das "Intel 440LX" startet mit dem Celeron 533 (Mendocino) und läfut damit auch stabil, zeigt aber einen "Celeron 550 MHz" an. Und dann gibt es auch Fälle, in denen solche Aufrüstaktionen zwar nicht mit dem aktuellen BIOS vom Hersteller der Hauptplatine funktionieren, aber mit einem modded BIOS.

Zitat von s4ndwichMakeR

Uhh, ich habe zwar vor Jahren beide Laufwerkstypen erfolgreich via Slackware bedient, aber ich kann mich nicht erinnern, ob ich denn je gemountet habe. Meistens brauchte ich nur die Low-Level-Geschichten.

Kannst du denn überhaupt was auslesen à la xxd /dev/fd[i]n[/i] | less?
Wie steht’s eigentlich mit mount -t msdos?

xxd /dev/fd[i]n[/i] | less

Liefert eine sinnvolle Ausgabe.

mount -t msdos

Funktioniert nur auf der Console, wenn kein X läuft und auch vorher nicht gelaufen ist, also das System direkt in die Console gestartet worden ist, mount -t vfat dito. Auf dem x86_64-System kann dann mit der Diskette auf der Console gearbeitet werden.

Beim Versuch, eine Datei auf die Diskette zu kopieren, verabschiedet sich das ia32-System mit einer kernel panic.

Unter Slackware-13.0 bzw. Slackware64-13.0 funktionieren Disketten klaglos auch unter X. Das legt den Verdacht nahe, dass entweder im Kernel 3.17.4 der Wurm drin steckt oder bei X irgend etwas gefummelt wurde.

Zitat von DosAmp

vfat-Kernelmodul ist auch geladen bzw. in den Kernel kompiliert?

vfat ist im Kernel drin, da für Linux & Windows eine FAT32-Festplattenpartition als gemeinsame Datenhalde dient.

Zitat von Xaar

Mir gehts ja eher darum, dass es Leute gibt, die Meinen "das geht alles noch mit einem Amiga 1200!eins!1!elf!" - und dabei sich auf ihren aufgerüsteten Amiga 1200 mit 68060 und PowerPC-CPU beziehen und eben nicht auf einen originalen - "echten" Amiga 1200 (also den mit dem billigen 68EC020). Und das ist eigentlich das, was ich nicht verstehe. Klar, ein Teil der alten Infrastruktur wird zwar mitbenutzt - aber letztlich ist das Herz doch ein anderes.

Grundsätzlich nachvollziehbar, aber wo ist die Grenze?

Beispiele:

• Sockel-7-System (ohne "split voltage" oder "Super"): Da geht nominell max. ein Pentium-S 200. Mit aktiver Zusatzkühlung für die Spannungsregler geht aber oft auch ein AMD K6 233 (Model 6).
• Slot-1-System mit nur 66 MHz FSB: Da geht nominell max. ein Pentium II 333. Mit Slotket (ohne Zusatzspannungsregler) geht oft aber auch ein Celeron 533 (Mendocino).

Das nachfolgende Problem scheint unabhängig von der Hardware zu sein, da es auf zwei unterschiedlichen Computern auftritt. Am x86_64-System hängt ein 3½"-Diskettenlaufwerk (BIOS drive A: ), installiert ist Slackware64-14.1 mit Kernel 3.17.4. Am ia-32-System hängen zwei Diskettenlaufwerke (3½" = BIOS drive A:; 5¼" = BIOS drive B: ), installiert ist Slackware-14.1 mit Kernel 3.17.4.

"mount -t vfat /dev/fd0 /mnt/floppy-a" läuft ins Leere, "mount -t vfat /dev/fd1/mnt/floppy-b" beim ia32-System entsprechend. Der Befehl wird scheinbar ausgeführt, aber auf die einliegende Diskette ist kein Zugriff möglich. /etc/mtab zeigt auch kein mounted /dev/fd0 bzw. mounted /dev/fd1 an. Im syslog finden sich gar keine Meldungen zu dem ausgeführten mount-Befehl. Auf der Console ausgeführt gibt es ebenfalls keine Meldungen. /dev/fd0, /dev/fd1, /mnt/floppy-a und /mnt/floppy-b existieren.

/etc/fstab
/dev/fd0 /mnt/floppy-a vfat noauto,user,exec,umask=000
/dev/fd1 /mnt/floppy-b vfat noauto,user,exec,umask=000 # ia32-System

fdformat und mformat funktionieren.
Disketten und Laufwerke sind in Ordnung. Unter Slackware64-13.0 & Windows 7 pro SP1 64-Bit (x86_64-System) bzw. Slackware-13.0 & Windows XP pro SP3 (ia32-System) funktioniert alles fehlerfrei.

Woran klemmt das?

Zitat von Mr. Vain

Ich kann im DSM 5.2 auch noch "Standard UNIX Berechtigungen" aktivieren. So wie ich das verstanden habe, hebelt das dann den ACL Mechanismus aus, oder wie?

Es hört sich zumindest danach an. Probier es aus! In einem privaten LAN braucht man meist keine ACL.

Zitat von Blue

(außer an meinen x230 mit dem i7-vpro aufkleber, weil direkter schwanzvergleich junge)

Der Kenner genießt und schweigt.

Zitat von Spit

hab auch aufkleber aufm laptop

beklebe sogar meinen bauhelm.

Hmm, auf Helme mit Kunststoffaußenschale (Bauhelm, Motorradhelm, Fahrradhelm, …) soll man nix drauf kleben, weil ungeeingete Kleber durch chemische Reaktionen die Schutzfunktion der Außenschale reduzieren können.

Ein P4-System (Pentium 4 550 (3,4 GHz HT) auf AsRock P4V88; 3 GiB DDR-RAM PC-400; nvidia GeForce 7900GS (AGP 8×, 512 MiB RAM)) hat ein Software-Update erfahren von Slackware 13.0 Kernel 2.6.31.5 auf Slackware 14.1 Kernel 3.17.4, wobei die alte Software komplett entfernt wurde und die Festplatte neu partitioniert wurde. Dabei wurde an Stelle des proprietären nvidia-Treibers der nouveau-Treiber installiert. Zum schnellen Testen der Grafikleistung wurde glxgears in einem Terminalfenster gestartet, nachdem dort zuvor "export vblank_mode=0" eingegeben wurde. Seltsamerweise zeigt glxgears unabhängig von der Größe des Fensters mit den sich drehenden Zahnrädern immer gleiche Werte an. Das habe ich bisher noch nie gesehen, auch nicht auf Kisten mit Slackware64-14.1 Kernel 3.17.4 und nouveau-Treiber, wobei in diesen Kisten allerdings PCIe x16-Grafikkarten stecken.

P4-System:
Mittelwert aus angezeigten Werten
300×300 Standardfenster ≈ 247 fps
1280×1024 abzgl. Fensterrahmen ≈ 247 fps

Der Wert selbst wäre für das "Vollbild", also 1280×1024 abzgl. Fensterrahmen wohl in Ordnung. Für das kleine Fenster, das nach dem Start von glxgears aufgeht, wäre das aber etwas mager.

Auf meinem Arbeitsrechner (ist 'ne andere Liga, aber es geht auch nicht um die absoluten Werte, sondern um das Verhalten von glxgears) sieht das so aus:
Mittelwert aus angezeigten Werten
300×300 Standardfenster ≈ 6325 fps
1920×1200 abzgl. Fensterrahmen ≈ 180 fps

Ein ähnliches Verhalten kenne bisher von allen anderen Systemen, nur das oben erwähnte P4-System macht das nicht. Woran kann das liegen?

Zitat von Xaar

Es gab doch (wimre auch von ASRock?) mal 'n Board, bei dem man den CPU-Sockel tauschen konnte. Sprich, der saß auf 'ner Separaten Karte, so dass man von 'nem Sockel 754 zum 939 oder so wechseln konnte. Weiß leider nimmer genau, welche Sockel damit gingen - kann auch sein, dass das 462 und 478 waren...

Hat jemand so ein Teil schonmal in der freien Wildbahn angetroffen?

Ja, hier läuft ein AsRock K7Upgrade-600, dass vor dem E-Schrott gerettet wurde. Das Upgrade-Kit war nicht vorhanden, weshalb da nur ein AMD Sempron 3300+ drauf werkelt.

Zitat von Michael_

Zitat von freaked

richte gerade meinen c64 neu ein

Als ich das sah, musste ich unweigerlich an meine letzte fdisk-Aktion unter Linux vor ein paar Tagen denken (siehe auch Anm. unten).

Die Ähnlichkeiten sind frappierend. Sogar die Komandokürzel sind soweit nachvollziehbar die selben:

• m = help
• t = toggle partition Id
• w = write partition table to disk

Anm.: Im Bild ist nur eine "Simulation" zu sehen, wie es z.B. für WinXP & Linux auf einer HDD in einer ia32-Kiste aussehen könnte. "w" wurde nicht ausgeführt. "Real" mache ich so etwas auf der Console, nicht unter X.

Igitt! Es schneit, und das auf gerade mal 60 m ü.NHN.

www = widerlich weißer Winter

Zitat von Xaar

Es ist halt nicht jeder Linux-Nutzer drauf erpicht, sich seinen eigenen Kernel zu stricken.

Das mag ja sein. Wie lautet Deine Lösung, die Radeon 9000 vernünftig unter dem installierten Linux in Gang zu kriegen?

Zitat von Sje

Im Kernel scheint kein Treiber für ne Radeon 9000 zu sein und ich hab auch keine Ahnung wo ich für so einen uralten Grafikchip ein Linuxtreiber herzaubern soll, vom Kernel backen fang gar nicht erst an.

Neues Linux auf alter oder schlapper Hardware und dann keinen zur Hardware passenden Kernel backen wollen …
Das ist keine so gute Idee.

Welcher Kernel läuft denn?
Gemeint ist dieser Kernel-Treiber:

Kurzfassung:

in /usr/src/linux/.config setzen:

CONFIG_AGP=y # not required for PCI or PCIe graphics cards
CONFIG_DRM_RADEON=y

Langfassung:

cd /usr/src/linux && make menuconfig

Device Drivers -->
Graphics support -->
<*> /dev/agpgart (AGP Support) ---- # not required for PCI or PCIe graphics cards
Direct Rendering Manager --->
<*> ATI Radeon

Zitat von Sje

wobei Lubuntu leider keinen Grafiktreiber für ne Radeon 9000, deswegen lassen sich Videos nicht brauchbar abspielen.

Die Radeon 9000 sollte sich doch mit dem Kernel-Treiber bestiefeln lassen. Wenn der im Distro-Kernel nicht drin ist, musst Du halt einen eigenen Kernel backen, was bei schwacher Hardware m.E. immer sinnvoll ist.

Zitat von Xaar

Was für ein Treiberproblem denn? Sowohl mit dem Stock-Treiber von Windows XP SP3 als auch mit dem Catalyst 6.2 von ATi ist das so.

Der Gedanke ist, es noch mal mit einem anderen Betriebssystem zu probieren, bevor so etwas in die Tonne wandert. Soweit möglich teste ich solche Kandidaten auch noch mal auf anderer Hardware, um die Möglichkeit einer Inkompatibilität zu reduzieren. Wegschmeißen kann man das Teil dann immer noch, wenn es wirklich hinüber ist.

Zitat von Xaar

Ick gloob, die ATi Radeon SDR 32 MB ist defekt. Läuft zwar, aber GPU-Z und auch das ATi Control Center meinen, die Karte hätte nur 16 MB Speicher

Treiber-Problem? Was sagt denn Xorg (z.B. von 'ner Knoppix) dazu?

Zitat von Playitlouder

Musst halt Slackware compilen, das läuft da sicher drauf.

Nö, einfach 'ne Minimalinstallation machen und dann nach Bedarf Pakete nachschieben oder ZipSlack nehmen.

Zitat von Sje

Alternativ könntest du auch ne Radeon 8500 "Uralt-Sockel-A-System" in Betracht ziehen die gab es schon mit DVI und ne GeforceFX 5200 sieht gegen ne Radeon 8500 kein Land.

Hier liegen genug AGP-Grafikkarten mit DVI rum, Neuanschaffungen stehen daher nicht an.

Zitat von Sje

Was die Geforce 7800GS in deinme 3200+ angeht hast du mich falsch verstanden, die 7800GS ist kein Flaschenhals in einem Sockel A System, eher im Gegenteil.
Ein Athlon XP 3200+ bremst ne Geforce 7800GS gewaltig aus, das weiß ich aus Erfahrung.

war gesetzt. Das habe ich schon verstanden. Welcher Prozessor bremst eine Geforce 7800GS nicht aus?