On Sunday 17 May 2009 04:17:17 am Stefan Richter wrote:
> Carl Karsten wrote:
> > On Sat, May 16, 2009 at 7:03 PM, Woojin Lee <wlee@...> wrote:
> >> when I connected two PCs together
> >> with the same cable, this is what I got on both PCs.
> >> /sys/bus/ieee1394/devices/fw-host0/node_count:2
> >> /sys/bus/ieee1394/devices/fw-host0/nodes_active:2
> >> /sys/bus/ieee1394/devices/fw-host0/selfid_count:2
> >> which I presume means success. So, am I safe to assume the cards and
> >> the cable are good then? It's hard to believe that both DV camcoders
> >> are damaged though... They both are relative new. Is there anything
> >> else that could be the issue? I'll see if I can find another DV camera.
> > I had some problems too. No clue if it was the same problem, or
> > exactly what my problem was. but I remember thinking " It's hard to
> > believe that both DV camcoders" till someone pointed out there are
> > probably some common chipsets / implementations. I also concluded
> > that 99% of the people coming across the problem were able to roll
> > with it, like the driver/app was able to just drop some frames and
> > continue.
> > my only point is "yes, it could be both DV camcoders are damaged." but
> > it isn't a very strong case.
> OTOH it could still be an issue between our kernel drivers and the PC's
> controller chips. Is it the Texas Instruments PCI4451 in both PCs?
No. The Dell Inspiron 8100 laptop has built-in firewire w/ Texas Instruments
PCI4451 whereas the other two PCI firewire cards have VIA chipset. (two
different brand but seems to have same chipset.) Here's lspci output of the
computer that has one of the pci card.
00:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394
OHCI Link Layer Controller (rev 46) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at cfffc000 (32-bit, non-prefetchable) [size=2K]
Region 1: I/O ports at d000 [size=128]
Capabilities:  Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ohci1394
Kernel modules: ohci1394
> Texas Instruments controllers like the TSB43ABxx family and TSB82AA2
> work very well under Linux. These are all OHCI 1.1 implementations
> though, while PCI4451 is shown in your logs as an OHCI 1.0 part. Maybe
> they used the older TSB12LV26 design there. By far fewer people have
> these compared to the aforementioned TI controller series, hence there
> might be issues between our drivers and these chips which we weren't
> aware of yet.
Both the Dell laptop and the pci firewire cards with VIA chipset are pretty
old (at least 4 years). Both used to work fine with older versions of linux,
running mandriva distro.
> Ah, by the way:
> >>>> ieee1394: Host added: ID:BUS[0-00:1023] GUID[434fc000248c8821]
> This GUID is not a proper one. 434fc0 is not a registered
> Organizationally Unique ID. I.e. the serial EEPROM which feeds
> initialization values to the controller has some bogus contents.
> However, the OUI of the other card, 001106, is a registered one.
> (Siemens NV, Belgium - can this be correct?)
434fc0 is the Dell laptop w/ Texas Instruments PCI4451 chipset and 001106 is
the pci card w/ VIA chipset.
> The next thing is that this could be a problem between the camcorders
> and the PHY chips --- these are interface chips which sit between the
> PCI4451 and the FireWire socket. I suspect that some or many camcorders
> send stream data right from the moment on when they are powered on, and
> that some PHY chips are disturbed by this and unable to finish the bus
> reset/ self identification phases.
> Owners of Sony camcorders sometimes seem to experience something which
> might be explainable by the latter, but other camcorder types might be
> involved too. Whether the fault lies with the camcorders or the PC's
> PHY or somewhere else is unclear. Deviation from the IEEE 1394 physical
> layer specification on one or the other or both sides seems the most
> plausible explanation to me though.
Both camcoders (Samsung and Canon) worked fine with both the Dell laptop and
the pci cards (VIA chipset) a while ago running older version of linux
Is there any possibility that as linux driver for IEEE1394 evolved, it broke
the compatibility with older chipsets that used to work?