Re: fw1 not created for dv-camera

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Jul 30 René Fritz wrote:
> Hi
> 
> My mini-dv camcorder is not detected.
> 
> The same hardware once worked, I guess with ohci1394 but I can't say 
> definitely. I have a firewire scanner which works fine, but the camcorder not.
> 
> I already searched the web for a solution but couldn't find one. At least none 
> that helped me.
> 
> As I understand the problem is that the device /dev/fw1 will no be created due 
> to some problems I don't understand :-)
> 
> Any help is much appreciated
> René
> 
> 
> 
> Here are the facts:
> 
> kubuntu 11.04 natty
> kernel 2.6.38-11 and I tried 3.0.0 too
> 
> camcoder Grundig Scenos (old one but works fine for me :-)
> 
> 
> # lspci | grep 1394
> 03:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 
> Controller (PHY/Link)
> 
> (onboard controller)
> 
> 
> # lsmod | grep firewire
> firewire_sbp2          23099  0 
> firewire_ohci          40832  0 
> firewire_core          64614  2 firewire_sbp2,firewire_ohci
> crc_itu_t              12707  1 firewire_core
> 
> 
> # ls /dev/fw*
> /dev/fw0
> 
> 
> # dmesg (with debug=7)
> [12018.315369] firewire_ohci: IRQ 00000010 AR_req
> [12018.315387] firewire_ohci: AR evt_bus_reset, generation 20
> [12018.315535] firewire_ohci: IRQ 00010000 selfID
> [12018.315558] firewire_ohci: 2 selfIDs, generation 20, local node ID ffc1
> [12018.315566] firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc
> [12018.315574] firewire_ohci: selfID 0: 817f8cd6, phy 1 [c--] S400 gc=63 -3W Lci
> [12018.315636] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
> [12018.315660] firewire_ohci: IRQ 00000001 AT_req
> [12018.315669] firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff
> [12018.315694] firewire_ohci: IRQ 00000010 AR_req
> [12018.315700] firewire_ohci: AR evt_bus_reset, generation 21
> [12018.315705] firewire_ohci: AR evt_bus_reset, generation 21
> [12018.315867] firewire_ohci: IRQ 00010000 selfID
> [12018.315886] firewire_ohci: 2 selfIDs, generation 22, local node ID ffc1
> [12018.315892] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc
> [12018.315899] firewire_ohci: selfID 0: 81458cd6, phy 1 [c--] S400 gc=5 -3W Lci
> [12018.315904] firewire_core: skipped bus generations, destroying all nodes
> [12018.810031] firewire_core: giving up on config rom for node id ffc0
> [12018.810060] firewire_core: rediscovered device fw0
> [12018.810081] firewire_ohci: IRQ 00000001 AT_req
> [12018.810088] firewire_ohci: AT spd 0 tl 3c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400
> [12018.814386] firewire_ohci: IRQ 00000020 AR_resp
> [12018.814392] firewire_ohci: AR spd 0 tl 3c, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df
> [12018.814506] firewire_ohci: IRQ 00000001 AT_req
> [12018.814511] firewire_ohci: AT spd 0 tl 3f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404
> [12021.820107] firewire_ohci: IRQ 00000001 AT_req
> [12021.820125] firewire_ohci: AT spd 0 tl 00, ffc1 -> ffc0, ack_pending , QR req, fffff0000400
> [12021.823489] firewire_ohci: IRQ 00000020 AR_resp
> [12021.823503] firewire_ohci: AR spd 0 tl 00, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df
> [12021.823637] firewire_ohci: IRQ 00000001 AT_req
> [12021.823646] firewire_ohci: AT spd 0 tl 01, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404
> [12024.830097] firewire_ohci: IRQ 00000001 AT_req
> [12024.830116] firewire_ohci: AT spd 0 tl 02, ffc1 -> ffc0, ack_pending , QR req, fffff0000400
> 
> and so on

This is almost exactly the same behavior that Thomas (Cc'd) reported in
"Panasonic AG-EZ30 - camera can't connect".
http://thread.gmane.org/gmane.linux.kernel.firewire.user/4306

Differences between these two reports, besides Panasonic vs. Grundig (they
may use the same interface hardware internally) is that Thomas has a NEC
controller vs. your Texas Instruments controller, and that Thomas'
camcorder is known to work on a Mac while yours worked a time ago with an
older Linux distribution.

The two reports taken together indicate that aged hardware is not the
problem here, or at least not the primary problem.  Rather we are
apparently facing a device hardware/firmware quirk here with which our
current drivers deal worse than other OSs or even our older drivers.

René and Thomas, please test the following:
  - Unload the OHCI-1394 driver:
    modprobe -r firewire-ohci; lsmod | grep fire
  - Plug in and switch on the camcorder.
  - Reload the driver:
    modprobe firewire-ohci debug=7

Then post the output of dmesg or contents of /var/log/kern.log starting
from the point where you unloaded the driver.

Please try the above with the camcorder in recorder mode and also in
player mode.

Also, would you be willing to take the time to compile a
modified kernel?  In
http://thread.gmane.org/gmane.linux.kernel.firewire.user/4306/focus=4313
I suggested:

  - Change firewire-ohci's maxATReqRetries setting from the current
    maximum possible value to something less.

This is unlikely to help.  firewire-ohci currently uses the same
parameters there as ohci1394 has been using for years.

  - Disable firewire-core's bus management.

This could have an effect.  The ieee1394 driver had different bus
management with fewer features than firewire-core, notably no gap count
optimization.

  - Insert a small pause between reception of quadlet response and
    transmission of the next quadlet request in firewire-core's reading of
    the Configuraton ROM.

Might not help; ieee1394 also used to send those quadlet requests as soon
as it could.

The following steps are involved:
  - Get the kernel sources, either from a source package of your
    distribution or from kernel.org.
  - Copy the configuration of the current kernel into the base directory
    of the kernel sources.  The existing configuration file is typically
    named /boot/config-2.6.38* or similar.  It needs to be copied to
    e.g. "/usr/src/linux-2.6.38/.config" or wherever the linux sources
    were unpacked.
  - Optionally, run the kernel configurator in order to disable all
    drivers that you are sure that you don't need.
    cd /usr/src/linux-2.6.38     # or wherever
    make xconfig                 # or make menuconfig
  - Build the kernel and kernel modules:
    nice make -j4
    The number after j should be the same as the number of CPU cores, or
    one or two more, in order to utilize your CPU resources fully.  This
    is because the first time that you compile the kernel is going to take
    very long.  The "nice" in front of make lets you continue to use the
    PC while it compiles without much impact on interactive usage.
  - Build the initrd.  For this step, please look for documentation that
    is specific to your distribution.  I have not used distributor kernels
    for many years myself, and always configured my kernels such that they
    can boot without an initrd.
  - Install kernel, modules, and initrd.  Configure the boot manager such
    that it offers a menu at boot that lets you choose between your own
    kernel and the existing distributor kernel.  Again, look for
    distribution specific documentation on this step.
  - Reboot into the new, self built kernel.

After that, you can modify firewire driver sources according to directions
that I would give you, or apply patches that I would send you.  After such
a modification, you can rebuild and install the firewire modules in less
than a minute (the rest of the kernel won't be rebuilt), unload the
unmodified modules and load the modified modules.
-- 
Stefan Richter
-=====-==-== -=== =====
http://arcgraph.de/sr/