Re: capture of camera often fails to work
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-08-28 14:19:46
|
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/ |