Re: capture of camera often fails to work

[Stefan R. <st...@s5...>]

On Aug 28 Dirk Langner wrote:
> A friend of mine tries to attach his (Sony) camera to a NEC uPD72874 firewire 
> card. Sometimes the captures works, most of the time the control of camera and 
> firewire interface for whatever reason fails to work correctly.

Is this a DV/HDV camcorder or an IIDC/DCAM industrial camera?
Which application is your friend using for control and capture?

> dmesg throughs out the messages:
> [  424.051551] firewire_ohci: isochronous cycle inconsistent

If this happens only at the moment when the camera is plugged in or
switched on, then this is normal.  The kernel simply always logs this,
regardless whether a bus topology change happened or not and regardless
whether isochronous DMAs are active or not.  I guess we should suppress
the message at least if isochronous DMA is off.

> [  480.812183]  [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core]
> [  480.812210]  [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core]
> 
> Has anybody seen error messages like that and know what this might cause? How 
> to get around this problem?

These two lines are unexpected.  Please post all dmesg lines around these
two, not only the lines which contain something about firewire.  If you
are only in the slightest doubt what could be related and what's not,
simply post everything from dmesg.  (Try to keep the message size below 50
kByte, otherwise the message will make a detour through the moderation
queue.)

> Thanks, 
> 	Dirk
> 
> 
> 
> Kernel 3.0.0, Linux Mint 12

Should be OK.

> libraw1394 2.0.7

This too.  By the way, libraw1394 2.0.7 does not use ioctl_get_speed.

>  ~ $ lspci | grep FireWire
> 04:06.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-ort PHY-Link Ctrlr (rev 01)

Should work, from what I know.  I have a NEC controller too, but a
different model.

>  ~ $ lsmod | grep fire
> firewire_ohci 40722 0
> firewire_core 63626 1 firewire_ohci
> crc_itu_t 12707 1 firewire_core
> 
>  ~ $ ls -l /dev/fw*
> crw-------  1 root root  251, 0 2012-08-04 15:22 /dev/fw0
> crw-rw----+ 1 root video 251, 1 2012-08-04 15:24 /dev/fw1

OK.

>  ~ $ dmesg | grep firewire
> [    2.028465] firewire_ohci 0000:04:06.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
> [    2.084103] firewire_ohci: Added fw-ohci device 0000:04:06.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1
> [    2.584242] firewire_core: created device fw0: GUID 00004c010000404f, S400
> [   95.874456] firewire_core: skipped bus generations, destroying all nodes
> [   96.372150] firewire_core: rediscovered device fw0
> [   96.481178] firewire_core: created device fw1: GUID 08004601012fa403, S100
> [   96.481187] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
> [   96.481427] firewire_core: skipped bus generations, destroying all nodes
> [   96.980085] firewire_core: rediscovered device fw0
> [   97.088906] firewire_core: rediscovered device fw1
> [   97.097512] firewire_ohci: isochronous cycle inconsistent

Looks normal.  The "destroying all nodes" may sound scary or at least
weird, but the procedure which prints this is actually pretty
straightforward and common.  Therefore this message is no longer printed by
most recent kernels (3.4 and later).

> [  360.812159]  [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core]
> [  360.812190]  [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core]
[...]

As noted, these messages are unusual, but we need more context to learn
what this is about.
-- 
Stefan Richter
-=====-===-- =--- ===--
http://arcgraph.de/sr/