Beiträge von Arnulf zu Linden

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?

Zitat von Sje

Die Geforce 7800GS ist in der Sockel A Kiste ziemlich unterfordert, mein 3200+ (2,2 Ghz, FSB 400) kann mit Asus A7V600-X und Radeon 9800 XL 128 MB locker das selbe leisten.

Sie ist nicht der Flaschenhals im System.
Die anderen beiden Geforce 7800GS stecken in einem Sockel-478-System (Intel Pentium 4 550 (3,4 GHz HT) auf AsRock P4V88 mit 3 GiB DDR-RAM) und einem Sockel-775-System (Intel Pentium D 820 (2,8 GHz ×2) auf MSI PM8PM-L mit 2 GiB DDR2-RAM). Danach kam doch kaum noch was mit AGP-Steckplatz. Alles, was hier an neueren Kisten steht, hat schon PCIe x16-Steckplätze.
Auch in dem erwähnten Uralt-Sackel-A-System dürfte die Geforce FX5200 nicht den Flaschenhals bilden, aber sie hat anders als diverse "zeitgemäße" Grafikkarten wenigstens DVI, was mit bei solchen Kisten wichtig ist.

Zitat von Dirk

Quatsch vor allem, weil ich nen Athlon 1400 und ne Geforce 3 wiedererwecke wollte, obwohl ich nen Ahtlon 2600+ mit Geforce 6 System danneben stehen habe, dass wirklich gut läuft.

Da können Welten zwischen liegen, da der Sockel-A sehr langlebig war. Insofern muss das kein Quatsch sein. Die Sockel-A-Bretter der ersten Generation können max. FSB200 (≙ 100 MHz) und wollen vom Athlon XP nix wissen. Da ist beim Athlon 1400B Schluss. Bei eingen dieser Bretter geht der Athlon XP zwar mit 'nem modded BIOS, aber es bleibt bei FSB200. Mit dem Athlon XP 2600 (AXDA2600DKV3C, also mit FSB266) kommt man dann auf 1,6 GHz bei FSB200.

Hier stehen mehrere Sockel-A-Kisten. Am unteren Ende ist es ein Athlon XP 2600 (AXDA2600DKV3C) @ 1,6 GHz; FSB200 auf einem Gigabyte GA-7IXE4 (mit ISA-Steckplätzen & modded BIOS für den Athlon XP), mageren 768 MiB SDRAM (≙ Maximalbestückung) und nvidia GeForce FX5200. Am oberen Ende ist es ein Athlon XP 3200+ (2,2 GHz; FSB400) auf einem Asus A7N8X-E Deluxe (mit SATA-Controller onboard), 3 GiB DDR-RAM und nvidia GeForce 7800GS. Die Unterschiede zwischen diesen beiden Sockel-A-Systemen dürften recht deutlich sein.

Zitat von Dirk

Der ist hinne. Habe das Netzteil getauscht, Strom gegeben und es hat Peng gemacht.

Klassischer "switch to death".

Zitat von Dirk

Wenn ich den Quatsch weitermachen will, brauch ich wohl nen ATX Gehäuse,

Wieso "Quatsch"?
Sockel-A finde ich im ATX-Gehäuse eh charmanter, weil man da besser die warme Luft raus bekommt.

Scrippler müsste noch ein ATX-Gehäuse übrig haben. Das Gehäuse im Bild ganz unten müsste noch da sein, die anderen beiden sind schon weg.

Zitat von Coburg-M

Aber mal ohne Guano: Ist Bremsenreiniger ned etwas zu aggresiv zu Elektroniksachen? Ich würd wohldosierte Druckluft und Isopropanol bevorzugen.

Mit der oben erwähnten Mischung habe ich noch keine negativen Erfahrungen bei der Elektronikreinigung gemacht. Gegenüber Fetten, Ölen und Wärmeleitpasten ist Bremsenreiniger nach meiner Erfahrung effektiver als Isopropanol. Das Zeug bleibt ja auch nicht lange auf den Bauteilen, da es rasch verdunstet.

Druckluft ist so eine Sache. Der Kompressor macht Krach. Außerdem ist Druckluft häufig mit Öl kontaminiert. Druckluft in Dosen scheint es leider nur als inakzeptable Einweggebinde zu geben. Oder gibt es auch widerbefüllbare Dosen, also solche, die man etwa mittels Luftpumpe über ein Autoventil aufpumpen kann?