Beiträge von Arnulf zu Linden


    einen Dualcore Pentium mit einem der beiden OS zu bespielen

    Windows 7:
    Der "Dualcore Pentium" dürfte schon EM64T drin haben, womit die Frage nach 32-Bit oder 64-Bit aufkommt. Wenn nur 2 GiB oder 3 GiB RAM drin stecken, spricht vieles für 32-Bit. Wenn 6 GiB oder 8 GiB RAM drin stecken, ist 64-Bit die bessere Wahl.

    cheese kann das auch nicht richtig. Da muss man angeben, wie viele Bilder gemacht werden sollen und in welchen Zeitintervallen. Außerdem finde ich keine Möglichkeit, den Speicherort anzugeben. Das ist so nicht brauchbar. Das Programm soll so lange in Intervallen Bilder speichern, bis der Benutzer das wieder beendet. Außerdem läuft cheese nicht stabil oder da fehlt immer noch was.

    camstream kann (oder besser: konnte) alles, was gebraucht wird. Dieses Programm hat aber ein anderes Problem:

    Zitat

    News

    2006-12-28:


    Auf Slackware 10.2 Kernel 2.6.18 lief das wie gewünscht, aber schon auf Slackware 13.0 Kernel 2.6.31.5 bekam ich das nicht mehr in Gang. Da dürfte die Chance auf Slackware64 14.2 Kernel 4.10.8 gegen Null tendieren. :(

    Mal eben camstream-snapshot-091020.tar.gz runtergeladen, entpackt und ./configure laufen lassen:

    Code
    […]
    checking location of Qt header files... 
    checking location of Qt library... 
    No Qt library/headers found! Either specify the correct path with --with-qt
    or install the development package. Try 'apt-get install libqt3-mt-dev' on
    Ubuntu, for example. Also make sure the multi-threaded, shared library
    is installed.


    camstream braucht alten qt-3-Knust, nicht das installierte qt-4.8.7.

    Gesucht wird ein Programm (OSS) mit grafischer Benutzeroberfläche, das in regelmäßigen Zeitintervallen (1 Bild/Sekunde … 1 Bild/Stunde) Bilder von einer Webcam speichert. Kamerka, xvcam und webcamoid können das nicht. cheese kann das laut Beschreibung, aber da hängt das ganze GNOME-Geraffel mit dran, was für den Einsatz unter KDE 4 deutlich suboptimal ist, zumal GNOME aus der Slackware schon vor Ewigkeiten raus geflogen ist. Eingesetzt werden soll es auf älterer x86_64-Hardware (Dunstkreis: ≥ AMD Athlon64 X2 bzw. Intel Core2 Duo; ≥ 8 GiB RAM) unter Slackware64 14.2 Kernel 4.10.8, und die ldd-Party bei der Installation sollte sich in Grenzen halten.

    Heute kaum vorstellbar, dass man mit so etwas mal produktiv gearbeitet hat (Gerät wurde gebraucht von Privat gekauft):

    Toshiba Satellite™ T2130CT

    • Prozessor: Intel i486DX4-75
    • Arbeitsspeicher: 32 MiB (8 MiB onboard + 24 MiB proprietäres Modul)
    • Grafik: Chips & Technologies F65545 (1 MiB onboard VLB)
    • Bildschirm: Color TFT Active Matrix SVGA 10,4″ 640×480
    • Festplatte: aktuell Toshiba MK2103MAV (2,1 GB IDE mdma2); zeitweise Fujitsu MHN2200AT (20 GB IDE udma5) mit Ontrack DDO; damals Toshiba MK1403MAV (1,4 GB IDE mdma2), Ersatz wegen Ablebens; werksseitig (soweit nachvollziehbar) Toshiba MK1924FCV (520 MB IDE)
    • Diskettenlaufwerk: 3½“ 1,44 MB
    • Netzwerk: PCMCIA card NE2000 compatible 10Base-2/T (nachgerüstet)
    • kein optisches Laufwerk, kein Soundchip
    • Betriebssystem: aktuell Slackware 9.1 Kernel 2.4.33.3; damals Bremse 95c; werksseitig (soweit nachvollziehbar) MS-DOS 6.22 & Windows 3.11 & Treiber für Grafik, PCMCIA und Pümpel


    Immerhin hat das Teil noch keine "Laptop-Krankheiten" wie Flexing oder angebrochene Scharniere.

    Hatte keine Lust im BIOS die Bildschirmhelligkeit runter zu drehen. Daher sind die beiden unteren Bilder etwas düster.

    … und wieder sind zwei Festplatten über'n Deister gegangen. :(

    Western Digital Caviar WD0307AA-00BAA0 (3,5" 30,7 GB IDE udma4): Nach knapp einjähriger Nichtnutzung war der Start der Museumskiste für diese Festplatte der "switch to death". Auch am Testsystem wird sie nicht mal mehr vom BIOS erkannt.

    Maxtor 4D040H2 (3,5" 40 GB IDE udma5): Nach knapp einjähriger Nichtnutzung blieb der Linux-Kernel mit IDE-Fehlern hängen. Am Testsystem zeigte smart "Reallocated sector count 92" und "Current pending sectors 1". badblocks -wsv führte zu nicht enden wollenden Fehlermeldungen (nachfolgend Beispiel):

    Code
    end_request: I/O error, dev hda, sector 50542488
    hda: dma_intr: status=0x51 {DriveReady SeekComplete Error }
    hda: dma_intr: status=0x40 { UncorrectableError }, LBAsect=50542488, sector=50542488
    ide: failed opcode was: unknown


    ⇒ Abbruch, Festplatte ist tot


    Beide sind 1920x1080@60

    In Summe 3840×1080 sollte eine Grafikkarte aus dieser Zeit stemmen können. Genaueres verrät Dir nur das Datenblatt zu der HD4670.


    Ist ein MINT OK zum testen?

    Dafür geht jedes halbwegs aktuelle Live-Linux (mit Kernel 4.x ), das in eine GUI startet. Knoppix und grml sind die üblichen Verdächtigen, aber wenn Mint als Livesystem in eine GUI startet, sollte das auch gehen.

    Welche nativen Auflösungen haben die beiden Monitore? Vielleicht ist das in Summe für die Ati Radeon HD4670 zu viel.

    Was passiert, wenn Du nur jeweils einen Monitor anschließt?

    Was passiert, wenn Du die beiden Monitore "tauscht", also an den jeweils anderen Anschluss anschließt? (passende Kabel/Adapter notwendig)

    Starte mal ein Live-Linux in die GUI um zu sehen, ob dabei das gleiche Problem auftritt.

    Das Festplattensterben geht weiter. :(

    Seagate ST38421A (3,5" 8,4 GB IDE udma4): Nach knapp einjähriger Nichtnutzung war der Start der Museumskiste für diese Festplatte der "switch to death". Auch am Testsystem wird sie nicht mal mehr vom BIOS erkannt.

    Samsung SV0844A (3,5" 8,4 GB IDE udma2): Die hatte wohl schon länger einen weg, denn in meiner Hardware-Tabelle stand dahinter schon ein Fragezeichen. In der Museumskiste wurde sie komplett ignoriert, also nicht erkannt, löste aber auch keine Störungen aus. Am Testsystem wurde sie erkannt, aber POST meldete "SMART is BAD". badblocks -wsv schmiss zahlreiche Fehler und wurde daher abgebrochen.

    Code
    modprobe snd-mpu401 port=0x300 irq=-1 pnp=no


    für Nicht-PnP auf Port 0x300 und ohne IRQ, oder

    Code
    modprobe snd-mpu401 port=0x300 pnp=yes


    für PnP.

    Das untere lädt das Modul nicht, das obere lädt es. Dass man dem Modul für "no IRQ" ein "IRQ=-1" mitgeben muss, war mir gerade nicht gegenwärtig. cat /proc/ioports zeigt 0300-0301 : MPU401 UART an. Das ist merkwürdig, da der im BIOS eingestellte Adressbereich 0x300-0x303 dafür ist – ist übrigens die Standardeinstellung nach einem CMOS-Reset.


    Wenn du noch einen analogen Joystick für den Gameport hast, kannst du ansonsten die Funktionalität mit den Modulen joydev, gameport und analog testen.

    So'n Teil brauche ich mal – nicht zum Daddeln, sondern als alternatives Eingabegerät zur Maus an den alten Kisten. Das soll ja funktionieren.

    Da mpu401 mit der Option pnp=no lädt, kommt mir hinsichtlich ns558, für das modinfo genau keine Optionen ausspuckt, ein Verdacht. ns558 lässt sich für non-PnP-Gameports (ISA, XT) nur laden, wenn daran ein Joystick angeschlossen ist. Aber um herauszufinden, ob hier ähnliches vorliegt, brauche ich einen analogen Joystick …