Manchmal ist die Linux-Welt nicht so heile, wie man gern sehen will. Die rosa Brille bekam heute einen kleinen Kratzer. AV-Bearbeitung unter Linux ist ansich kein Problem, aber den Schlammassel von einer DV-Cam in den Rechenknecht zu bekommen ist ’ne Kür.

Die Krux ist hier Firewire. Ich wollte von einer Sony DCR-HC42E mit Kino meinen aufgezeichneten Kram importieren. Kino meinte erst das raw-device wäre nicht geladen: stimmt! Also modprobe raw1394. Das Device in Kino war jetzt aber immer noch leer. Werfen wir einen Blick ins syslog, was denn beim Anstecken der Cam passiert:

Sesta:/# tail -f /var/log/syslog
May 11 20:45:17 Sesta kernel: ohci1394: fw-host0: Error in reception of SelfID packets [0x00020014/0x00012067] (count: 0)
May 11 20:45:17 Sesta kernel: ohci1394: fw-host0: SelfID received outside of bus reset sequence
May 11 20:45:17 Sesta kernel: ohci1394: fw-host0: Error in reception of SelfID packets [0x00040014/0x00012067] (count: 1)
May 11 20:45:17 Sesta kernel: ohci1394: fw-host0: SelfID received outside of bus reset sequence
May 11 20:45:17 Sesta kernel: ieee1394: impossible ack_complete from node 65535 (tcode 4)
May 11 20:45:17 Sesta kernel: ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
[...]
May 11 20:45:18 Sesta kernel: ohci1394: fw-host0: Error in reception of SelfID packets [0x000e0014/0x00012067] (count: 6)
May 11 20:45:18 Sesta kernel: ohci1394: fw-host0: SelfID received outside of bus reset sequence
May 11 20:45:18 Sesta kernel: ieee1394: impossible ack_complete from node 65535 (tcode 4)
May 11 20:45:18 Sesta kernel: ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
May 11 20:45:18 Sesta kernel: ieee1394: Stopping reset loop for IRM sanity
May 11 20:45:18 Sesta kernel: ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0011d800011ef88d]

Aha, ist was kaputt. Einiges rumgegoogle brachte Tips zu billigen und defekten Kabeln usw. Aber dieser Beitrag in den Ubuntuforen half wirklich weiter. Schickt man seinen Rechner in den suspend (2disk oder 2ram) semmelt der Firewire-Stack beim nächsten Aufwachen ab. Beheben kann man das ganz einfach: man entlädt alle Firewire-Module des Kernels und lädt sie erneut.
modprobe -r dv1394
modprobe -r eth1394
modprobe -r ohci1394
modprobe -r raw1394
modprobe -r ieee1394
modprobe eee1394
modprobe ohci1394
modprobe raw1394
Dieser Tip sollte allen bis zum Kernel 2.6.21 weiterhelfen. Auf meinem AMD64 mit Debian stable und 2.6.18er-Kernel brennt jetzt der Draht.

Ab Kernel 2.6.22 wurde der alte Firewire-Stack abgeschaltet, da man ein Sicherheitsproblem entdeckt hatte. Die meisten Distributoren entschieden sich so, auch Debian, man nahm stattdessen einen neuimplementierten Stack mit diversen Problemen und geändertem Interface rein. Mühsam ernährt sich das Eichhörnchen und mühsamer sieht die Sache im Bereich Userland aus: Kino 1.2.0 verwendet den neuen Firewire-Stack noch nicht und sucht immer noch das alte raw-device, das es nicht mehr gibt. Eine Lösung dafür hab ich nicht, jedenfalls bleibt auf meinem Notebook mit Debian unstable und kernel 2.6.24 der Draht vorerst kalt. (swg)