Thread: HV30 and grabbing in 3.16.0-31
Brought to you by:
aeb,
bencollins
From: Elias A. <eli...@ik...> - 2015-03-02 09:15:26
|
Hi, I am trying to get dvgrab to work in Ubuntu 14.10 running kernel 3.16.0-31. The distro has the "new" FW stack and I have done the tricks described here: https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture I have tested two PCIMCIA adapters: 16:00.0 FireWire (IEEE 1394):16:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) and 16:00.0 FireWire (IEEE 1394): NEC Corporation uPD72874 [Firewarden] IEEE1394a OHCI 1.1 Link/3-port PHY Controller (rev 01) When I plug in the VIA card, syslog says: Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744121] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744155] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744202] pci 0000:16:00.0: reg 0x14: [mem 0x82100090-0x8210009f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744234] pci 0000:16:00.0: reg 0x1c: [mem 0x00000010-0x0000001f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744513] pci 0000:16:00.0: BAR 1: assigned [mem 0x84000000-0x8400000f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744527] pci 0000:16:00.0: BAR 1: error updating (0x84000000 != 0x3100010) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744537] pci 0000:16:00.0: BAR 3: assigned [mem 0x84000010-0x8400001f] Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744550] pci 0000:16:00.0: BAR 3: error updating (0x84000010 != 0x000010) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744570] pci 0000:16:00.0: cache line size of 64 is not supported Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744675] firewire_ohci 0000:16:00.0: enabling device (0000 -> 0002) Mar 2 10:48:28 nakka-ThinkPad-T60 kernel: [ 926.744811] firewire_ohci 0000:16:00.0: invalid MMIO resource The last row looks like it is a no go so let's try the NEC one. Syslog: Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.548123] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554732] pci 0000:16:00.0: [1033:00f2] type 00 class 0x0c0010 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554775] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x00000fff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554799] pci 0000:16:00.0: reg 0x14: [mem 0x00000000-0x000000ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554818] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554936] pci 0000:16:00.0: supports D1 D2 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.554942] pci 0000:16:00.0: PME# supported from D0 D1 D2 D3hot Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556428] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x84000fff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556445] pci 0000:16:00.0: BAR 1: assigned [mem 0x84001000-0x840010ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556459] pci 0000:16:00.0: BAR 2: assigned [mem 0x84001100-0x840011ff] Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.556598] firewire_ohci 0000:16:00.0: enabling device (0000 -> 0002) Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1400.612169] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 6, 4 IR + 4 IT contexts, quirks 0x1 Mar 2 10:56:22 nakka-ThinkPad-T60 kernel: [ 1401.112354] firewire_core 0000:16:00.0: created device fw0: GUID 0000000000000000, S400 So far so good. Now let's plug in Canon HV30 and switch it on. dvgrab -i Error: no camera exists Let's try Ubuntu studio control to enable raw 1394 access. Still no camera. Eject & replug the PCMCIA card - oops... no changes shown in syslog anymore.... What should I try next? |
From: Elias A. <eli...@ik...> - 2015-03-02 10:29:24
|
After booting the machine with the PCMCIA card installed, removed it, plugged it in again: Syslog: Mar 2 12:14:19 nakka-ThinkPad-T60 kernel: [ 322.780636] firewire_ohci 0000:16:00.0: removed fw-ohci device Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952178] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952218] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952258] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x000007ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952278] pci 0000:16:00.0: reg 0x14: [io 0x0000-0x007f] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952297] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952415] pci 0000:16:00.0: supports D2 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952422] pci 0000:16:00.0: PME# supported from D2 D3hot D3cold Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952660] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x840007ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952675] pci 0000:16:00.0: BAR 2: assigned [mem 0x84000800-0x840008ff] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952689] pci 0000:16:00.0: BAR 1: assigned [io 0xa000-0xa07f] Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952829] firewire_ohci 0000:16:00.0: enabling device (0080 -> 0083) Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.016152] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 4, 4 IR + 8 IT contexts, quirks 0x41 Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.516427] firewire_core 0000:16:00.0: created device fw0: GUID 00111666123403bc, S400 Then I plugged in the camera cable and switched camera on: Mar 2 12:14:46 nakka-ThinkPad-T60 kernel: [ 349.240209] firewire_core 0000:16:00.0: rediscovered device fw0 Mar 2 12:14:47 nakka-ThinkPad-T60 kernel: [ 350.556151] firewire_core 0000:16:00.0: rediscovered device fw0 Mar 2 12:14:48 nakka-ThinkPad-T60 kernel: [ 351.864169] firewire_core 0000:16:00.0: rediscovered device fw0 This last line keeps getting repeated once in a second, endlessly. Any thoughts? |
From: Stefan R. <st...@s5...> - 2015-03-02 20:25:23
|
On Mar 02 Elias Aarnio wrote: > After booting the machine with the PCMCIA card installed, removed it, > plugged it in again: > > Syslog: > > Mar 2 12:14:19 nakka-ThinkPad-T60 kernel: [ 322.780636] firewire_ohci 0000:16:00.0: removed fw-ohci device > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952178] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952218] pci 0000:16:00.0: [1106:3044] type 00 class 0x0c0010 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952258] pci 0000:16:00.0: reg 0x10: [mem 0x00000000-0x000007ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952278] pci 0000:16:00.0: reg 0x14: [io 0x0000-0x007f] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952297] pci 0000:16:00.0: reg 0x18: [mem 0x00000000-0x000000ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952415] pci 0000:16:00.0: supports D2 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952422] pci 0000:16:00.0: PME# supported from D2 D3hot D3cold > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952660] pci 0000:16:00.0: BAR 0: assigned [mem 0x84000000-0x840007ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952675] pci 0000:16:00.0: BAR 2: assigned [mem 0x84000800-0x840008ff] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952689] pci 0000:16:00.0: BAR 1: assigned [io 0xa000-0xa07f] > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 325.952829] firewire_ohci 0000:16:00.0: enabling device (0080 -> 0083) > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.016152] firewire_ohci 0000:16:00.0: added OHCI v1.10 device as card 4, 4 IR + 8 IT contexts, quirks 0x41 > Mar 2 12:14:23 nakka-ThinkPad-T60 kernel: [ 326.516427] firewire_core 0000:16:00.0: created device fw0: GUID 00111666123403bc, S400 This appears to be the VT6306 card. (I have a VT6306 based CardBus Card too but it is configured to OHCI 1.0 mode by the card manufacturer. However OHCI 1.1 versus 1.0 is not of importance to the matter at hand.) > Then I plugged in the camera cable and switched camera on: > > Mar 2 12:14:46 nakka-ThinkPad-T60 kernel: [ 349.240209] firewire_core 0000:16:00.0: rediscovered device fw0 > Mar 2 12:14:47 nakka-ThinkPad-T60 kernel: [ 350.556151] firewire_core 0000:16:00.0: rediscovered device fw0 > Mar 2 12:14:48 nakka-ThinkPad-T60 kernel: [ 351.864169] firewire_core 0000:16:00.0: rediscovered device fw0 > > This last line keeps getting repeated once in a second, endlessly. > > Any thoughts? Normally, when a device is plugged in/ switched on, there are two or three bus resets or so and then the bus becomes operational, firewire-core queries the node for its type, and then higher-level software can take over. You however get a never ending series of bus resets. These could be caused by a hardware defect --- e.g. burnt out port or loose port at the camcorder; worn out plug at the cable or broken wire or bad shielding of the cable; worn out or desoldered port at the card; etc.. Or it could be firmware fighting against core driver: firewire-core assumes certain bus management duties, and these involve software-initiated bus resets. We had cases in the past where device firmware undid the bus configurations that firewire-core attempted to establish, and device and firewire-core repeatedly reset the bus. In order to learn more whether it could be a firmware <-> driver issue, please attempt again with some event logging switched on in firewire-ohci: When firewire-ohci is already loaded, but before the camcorder is plugged in/ switched on, issue the following command: sudo dd of=/sys/module/firewire_ohci/parameters/debug <<< 3 The plug in/ switch on the camcorder (shouldn't matter whether you first plug it in and then switch it on, or the other way around; but you can of course try both sequences), watch what is being logged in the kernel log, and post the log here. You can tell firewire-ohci to stop the debug logging any time by the same command as above but with 0 as parameter. -- Stefan Richter -=====-===== --== ---=- http://arcgraph.de/sr/ |
From: Elias A. <eli...@ik...> - 2015-04-09 15:58:05
|
Hello, 02.03.2015, 22:25, Stefan Richter kirjoitti: > You however get a never ending series of bus resets. These could be > caused by a hardware defect --- e.g. burnt out port or loose port at the > camcorder; worn out plug at the cable or broken wire or bad shielding of > the cable; worn out or desoldered port at the card; etc.. This was the reason. The cable was damaged so that in some positions it stopped working. Thank you really much for your help! -- Elias Aarnio |
From: Stefan R. <st...@s5...> - 2015-04-09 18:45:00
|
On Apr 09 Elias Aarnio wrote: > 02.03.2015, 22:25, Stefan Richter kirjoitti: > > You however get a never ending series of bus resets. These could be > > caused by a hardware defect --- e.g. burnt out port or loose port at the > > camcorder; worn out plug at the cable or broken wire or bad shielding of > > the cable; worn out or desoldered port at the card; etc.. > > This was the reason. The cable was damaged so that in some positions it > stopped working. For this reason I like the following cables with mere 3 mm outer diameter, hence less weight and stiffness pulling on the plug: http://www.partsdata.co.uk/firewire-cables-ieee-1394-accessories/firewire-400-cables-adapters/firewire-cable-46-white-flexible/ (This vendor is based in Germany. Shipping costs to Scandinavia seem to be quite high if all you need is just one cable.) Sony, who originally came up with the 4-pin plug, used to make cables which were almost as thin but even more flexible. Maybe you can find a used Sony cable for cheap. About half a year ago I got 4 mm thin and still quite flexible cables via this page: http://www.amazon.de/gp/product/B00L8ZRQ0S But one can never be sure what cable material one gets when buying noname. The cables which I received from there have a different mold of the plug casings than the cable on the amazon photo. -- Stefan Richter -=====-===== -=-- -=--= http://arcgraph.de/sr/ |
From: Ларионов Д. <lar...@ya...> - 2015-04-09 19:35:45
|
Hello Stefan. You seem to know a lot about IEEE1394 hardware, not only software. Could you please tell me whether it is possible to burn a FireWire device by not connecting its housing to the host's? I have a ScanControl surface analyzer from MicroEpsilon. It is essentially a DCAM camera with IEEE1394 interface. I soldered my own cable, because I needed a special one (not fracturing at extremely low temperatures etc.) Since the scanner has a separate power port, I soldered only 4 wires (TPA+, TPB+, TPA-, TPB-). I also connected the connector ground to the cable shield at only one end of the wire. I asked the manufacturer employee and he said that's ok. The scanner worked fine for a while, but then it just suddenly broke. I sent it back to the manufacturer and they sent me these photos: https://yadi.sk/d/nlIi62iXf9dEE and recommended to buy their own cable. I did that, and it seems that the only difference between my cable and theirs (besides the absence of power wires) was that the shield was connected to the connectors at both ends. Did you have similar cases in your experience? Thanks in advance. -- Даниил Ларионов 09.04.2015, 21:45, "Stefan Richter" <st...@s5...>: > On Apr 09 Elias Aarnio wrote: >> 02.03.2015, 22:25, Stefan Richter kirjoitti: >>> You however get a never ending series of bus resets. These could be >>> caused by a hardware defect --- e.g. burnt out port or loose port at the >>> camcorder; worn out plug at the cable or broken wire or bad shielding of >>> the cable; worn out or desoldered port at the card; etc.. >> This was the reason. The cable was damaged so that in some positions it >> stopped working. > > For this reason I like the following cables with mere 3 mm outer diameter, > hence less weight and stiffness pulling on the plug: > http://www.partsdata.co.uk/firewire-cables-ieee-1394-accessories/firewire-400-cables-adapters/firewire-cable-46-white-flexible/ > (This vendor is based in Germany. Shipping costs to Scandinavia seem to be > quite high if all you need is just one cable.) > > Sony, who originally came up with the 4-pin plug, used to make cables > which were almost as thin but even more flexible. Maybe you can find a > used Sony cable for cheap. > > About half a year ago I got 4 mm thin and still quite flexible cables via > this page: http://www.amazon.de/gp/product/B00L8ZRQ0S > But one can never be sure what cable material one gets when buying noname. > The cables which I received from there have a different mold of the plug > casings than the cable on the amazon photo. > -- > Stefan Richter > -=====-===== -=-- -=--= > http://arcgraph.de/sr/ > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |
From: Allan D. <al...@fa...> - 2015-04-10 05:24:33
|
On 10/04/15 05:35, Ларионов Даниил wrote: > Hello Stefan. > > You seem to know a lot about IEEE1394 hardware, not only software. Could you please tell me whether it is possible to burn a FireWire device by not connecting its housing to the host's? > I have a ScanControl surface analyzer from MicroEpsilon. It is essentially a DCAM camera with IEEE1394 interface. > I soldered my own cable, because I needed a special one (not fracturing at extremely low temperatures etc.) Since the scanner has a separate power port, I soldered only 4 wires (TPA+, TPB+, TPA-, TPB-). > I also connected the connector ground to the cable shield at only one end of the wire. I asked the manufacturer employee and he said that's ok. > The scanner worked fine for a while, but then it just suddenly broke. I sent it back to the manufacturer and they sent me these photos: > > https://yadi.sk/d/nlIi62iXf9dEE > > and recommended to buy their own cable. I did that, and it seems that the only difference between my cable and theirs (besides the absence of power wires) was that the shield was connected to the connectors at both ends. > Did you have similar cases in your experience? > Thanks in advance. > Contrary to the advice you got, the earth/shield coonection to both ends is critically important - without it the device at each end can float to large relative voltages, well beyond the Common Mode voltage range of the input electronics. You are lucky it only killed the analyzer. If both devices have explicit, and common, ground connections then only one end need be shielded, and not having either end connected may also work fine. Most plug-pack power sources have floating outputs. |