Thread: Error: no camera exists
Brought to you by:
aeb,
bencollins
From: David <da...@ke...> - 2015-10-12 04:42:24
|
There are lots of posts on the net that look like my problem below, but no solutions that I have been able to find. Is DV capture over firewire unavailable now? Any help would be greatly appreciated. Ubuntu 12.04 david@david:~$ uname -a Linux david 3.2.0-91-generic #129-Ubuntu SMP Wed Sep 9 10:56:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Canon XHA1 camcorder When I plug in the firewire, the camera's screen reports: "HDV/DV IN" david@david:~$ lspci | grep -i firewire 08:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) david@david:~$ lsmod | grep -e 1394 -e firewire firewire_ohci 41000 0 firewire_core 63600 1 firewire_ohci crc_itu_t 12707 1 firewire_core david@david:~$ ls -l /dev/raw1394 /dev/fw0 crw-rw-rw- 1 root video 251, 0 Oct 11 15:54 /dev/fw0 lrwxrwxrwx 1 root root 8 Oct 11 16:59 /dev/raw1394 -> /dev/fw0 david@david:~$ sudo dvgrab -i Error: no camera exists david@david:~$ dvgrab -v dvgrab 3.5 I created the link for /dev/raw1394 because of this page: https://help.ubuntu.com/community/FireWire/DigitalVideo I also did this (and then rebooted): https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" SUBSYSTEM=="firewire", GROUP="video" david@david:~$ dmesg -T | grep firewire [Sun Oct 11 15:53:52 2015] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [Sun Oct 11 15:53:52 2015] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 [Sun Oct 11 15:53:52 2015] firewire_core: created device fw0: GUID 00cc13240000241d, S400 [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0xf (was 0x4020100, writing 0x4020105) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x5 (was 0x0, writing 0xfb8f8000) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xfb8ff000) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x3 (was 0x0, writing 0x2010) [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006) [Sun Oct 11 20:29:47 2015] firewire_core: skipped bus generations, destroying all nodes [Sun Oct 11 20:29:47 2015] firewire_core: rediscovered device fw0 -- David McQuire 0418 310312 |
From: Stefan R. <st...@s5...> - 2015-10-12 06:36:06
|
On Oct 12 David wrote: > There are lots of posts on the net that look like my problem below, but > no solutions that I have been able to find. Is DV capture over firewire > unavailable now? DV works just fine. > Any help would be greatly appreciated. > > Ubuntu 12.04 > david@david:~$ uname -a > Linux david 3.2.0-91-generic #129-Ubuntu SMP Wed Sep 9 10:56:06 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux This kernel should be OK. > Canon XHA1 camcorder A HDV (MPEG-2) camcorder; AFAIU capture from this is supported by dvgrab. > When I plug in the firewire, the camera's screen reports: > "HDV/DV IN" > > david@david:~$ lspci | grep -i firewire > 08:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 > IEEE-1394a-2000 Controller (PHY/Link) This controller type is well supported. Please post the entire output of "lspci -nn" though, so that we see all other PCI(e) devices too and their numeric IDs. > david@david:~$ lsmod | grep -e 1394 -e firewire > firewire_ohci 41000 0 > firewire_core 63600 1 firewire_ohci > crc_itu_t 12707 1 firewire_core OK. > david@david:~$ ls -l /dev/raw1394 /dev/fw0 > crw-rw-rw- 1 root video 251, 0 Oct 11 15:54 /dev/fw0 > lrwxrwxrwx 1 root root 8 Oct 11 16:59 /dev/raw1394 -> /dev/fw0 This symlink is total nonsense. The /dev/raw1394 ABI is entirely different from the /dev/fw* ABI. Since after kernel 2.6.36, a file with the name /dev/raw1394 will simply do nothing. However, what's missing here is a second /dev/fw* file. There is one such file created on-the-fly for each present FireWire node, including each so-called local node = link layer controller. So, normally you would get crw------- 1 root root 250, 0 * /dev/fw0 for the controller after boot, and crw-rw---- 1 root video 250, 1 * /dev/fw1 for the camcorder as soon as it is plugged in/ switched on. Missing /dev/fw1 (or a higher number on systems with more than two FireWire nodes, e.g. with multiple FireWire controllers) means that the kernel did not discover any other FireWire node. > david@david:~$ sudo dvgrab -i > Error: no camera exists This is a consequence of the camera node not being detected. > david@david:~$ dvgrab -v > dvgrab 3.5 OK > I created the link for /dev/raw1394 because of this page: > https://help.ubuntu.com/community/FireWire/DigitalVideo Which is wrong. It does nothing, neither good nor harm. > I also did this (and then rebooted): > https://kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture > > > david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules > KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" > SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" > SUBSYSTEM=="firewire", GROUP="video" This is unnecessary; stock udev already contains proper rules for almost all FireWire applications, including (H)DV capture. > david@david:~$ dmesg -T | grep firewire > [Sun Oct 11 15:53:52 2015] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > [Sun Oct 11 15:53:52 2015] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > [Sun Oct 11 15:53:52 2015] firewire_core: created device fw0: GUID 00cc13240000241d, S400 OK. > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0xf (was 0x4020100, writing 0x4020105) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x5 (was 0x0, writing 0xfb8f8000) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xfb8ff000) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x3 (was 0x0, writing 0x2010) > [Sun Oct 11 20:29:47 2015] firewire_ohci 0000:08:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006) > [Sun Oct 11 20:29:47 2015] firewire_core: skipped bus generations, destroying all nodes > [Sun Oct 11 20:29:47 2015] firewire_core: rediscovered device fw0 Not sure what that means. Maybe this is from a power management suspend--resume cycle. Messages about an fw1 are notably absent. What do you get in the kernel log if you run sudo modprobe -r firewire-ohci sleep 1 sudo modprobe firewire-ohci debug=2 while the camcorder is plugged in and switched on? And after this, what do you get if you leave firewire-ohci this way and unplug and replug the camcorder? (Please carefully note which kernel messages follow from what action.) -- Stefan Richter -=====-===== =-=- -==-- http://arcgraph.de/sr/ |
From: David <da...@ke...> - 2015-10-12 12:26:54
|
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DMI [8086:d131] (rev 11) 00:03.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express Root Port 1 [8086:d138] (rev 11) 00:05.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express Root Port 3 [8086:d13a] (rev 11) 00:08.0 System peripheral [0880]: Intel Corporation Core Processor System Management Registers [8086:d155] (rev 11) 00:08.1 System peripheral [0880]: Intel Corporation Core Processor Semaphore and Scratchpad Registers [8086:d156] (rev 11) 00:08.2 System peripheral [0880]: Intel Corporation Core Processor System Control and Status Registers [8086:d157] (rev 11) 00:08.3 System peripheral [0880]: Intel Corporation Core Processor Miscellaneous Registers [8086:d158] (rev 11) 00:10.0 System peripheral [0880]: Intel Corporation Core Processor QPI Link [8086:d150] (rev 11) 00:10.1 System peripheral [0880]: Intel Corporation Core Processor QPI Routing and Protocol Registers [8086:d151] (rev 11) 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3b] (rev 05) 00:1a.1 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3e] (rev 05) 00:1a.2 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b3f] (rev 05) 00:1a.7 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05) 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05) 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 05) 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05) 00:1c.2 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 [8086:3b46] (rev 05) 00:1c.3 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 [8086:3b48] (rev 05) 00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 7 [8086:3b4e] (rev 05) 00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b36] (rev 05) 00:1d.1 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b37] (rev 05) 00:1d.2 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b38] (rev 05) 00:1d.3 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller [8086:3b39] (rev 05) 00:1d.7 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 05) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) 00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface Controller [8086:3b02] (rev 05) 00:1f.2 IDE interface [0101]: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller [8086:3b20] (rev 05) 00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 05) 00:1f.5 IDE interface [0101]: Intel Corporation 5 Series/3400 Series Chipset 2 port SATA IDE Controller [8086:3b26] (rev 05) 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 GT] [10de:0402] (rev a1) 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) 05:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) 06:00.0 IDE interface [0101]: Marvell Technology Group Ltd. Device [1b4b:91a3] (rev 11) 07:00.0 SATA controller [0106]: JMicron Technology Corp. JMB363 SATA/IDE Controller [197b:2363] (rev 03) 07:00.1 IDE interface [0101]: JMicron Technology Corp. JMB363 SATA/IDE Controller [197b:2363] (rev 03) 08:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] 08:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] 3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers [8086:2c51] (rev 04) 3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2c81] (rev 04) 3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2c90] (rev 04) 3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 [8086:2c91] (rev 04) 3f:03.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller [8086:2c98] (rev 04) 3f:03.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder [8086:2c99] (rev 04) 3f:03.4 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Test Registers [8086:2c9c] (rev 04) 3f:04.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers [8086:2ca0] (rev 04) 3f:04.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers [8086:2ca1] (rev 04) 3f:04.2 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers [8086:2ca2] (rev 04) 3f:04.3 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers [8086:2ca3] (rev 04) 3f:05.0 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers [8086:2ca8] (rev 04) 3f:05.1 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers [8086:2ca9] (rev 04) 3f:05.2 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers [8086:2caa] (rev 04) 3f:05.3 Host bridge [0600]: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers [8086:2cab] (rev 04) |
From: Stefan R. <st...@s5...> - 2015-10-19 07:01:35
|
On Oct 12 David wrote: > On 12/10/15 17:35, Stefan Richter wrote: > > What do you get in the kernel log if you run > > sudo modprobe -r firewire-ohci > > sleep 1 > > sudo modprobe firewire-ohci debug=2 > > while the camcorder is plugged in and switched on? > > > > And after this, what do you get if you leave firewire-ohci this way and > > unplug and replug the camcorder? > > > > (Please carefully note which kernel messages follow from what action.) > plugging and unplugging the device resulted in nothing in the log :( > > The camcorder is definitely getting a signal of some sort because it > displays "HDV/DV IN" on it's screen. This stays on during reboot, so I > guess it's just some power thing. > > The camera is definitely working OK because (I hate to say it) it > connects to an Apple OK > > david@david:/var/log$ tail -f -n0 kern.log > Oct 12 23:02:48 david kernel: [ 675.823166] firewire_ohci 0000:08:06.0: PCI INT A disabled > Oct 12 23:02:48 david kernel: [ 675.823171] firewire_ohci: Removed fw-ohci device. > Oct 12 23:02:48 david kernel: [ 675.830928] firewire_ohci 0000:08:01.0: PCI INT A disabled > Oct 12 23:02:48 david kernel: [ 675.830933] firewire_ohci: Removed fw-ohci device. This is from "modprobe -r", and it shows shutdown messages from two OHCI link layer controllers. As you mentioned in today's post, you actually have two controllers. > Oct 12 23:03:03 david kernel: [ 690.683053] firewire_ohci 0000:08:01.0: Refused to change power state, currently in D3 > Oct 12 23:03:03 david kernel: [ 690.683067] firewire_ohci 0000:08:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > Oct 12 23:03:03 david kernel: [ 690.683126] firewire_ohci: Failed to reset ohci card. > Oct 12 23:03:03 david kernel: [ 690.683144] firewire_ohci 0000:08:01.0: PCI INT A disabled > Oct 12 23:03:03 david kernel: [ 690.683153] firewire_ohci: probe of 0000:08:01.0 failed with error -16 One of the last steps to initialize the first controller failed. It is not clear why that happened. > Oct 12 23:03:03 david kernel: [ 690.683171] firewire_ohci 0000:08:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > Oct 12 23:03:03 david kernel: [ 690.738942] firewire_ohci: Added fw-ohci device 0000:08:06.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > Oct 12 23:03:03 david kernel: [ 690.739165] firewire_ohci: 1 selfIDs, generation 1, local node ID ffc0 > Oct 12 23:03:03 david kernel: [ 690.739172] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci > Oct 12 23:03:04 david kernel: [ 691.238374] firewire_core: created device fw0: GUID 00cc13240000241d, S400 The second controller is initialized seemingly fine. From your lspci listing: > 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) This bridge implements a PCI bus, on which the following devices are located (if I read the listing correctly): > 08:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] > 08:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] The device 08:01.0 is notably absent from the lspci listing. Maybe the contact is loose, as Carl suggested among else. I also note that the "dmesg -T | grep firewire" results which you posted in your initial message were all from device 08:06.0, and none were from 08:01.0. -- Stefan Richter -=====-===== =-=- =--== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2015-10-12 14:10:08
|
On Oct 12 David wrote: > On 12/10/15 17:35, Stefan Richter wrote: > > On Oct 12 David wrote: > >> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules > >> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" > >> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" > >> SUBSYSTEM=="firewire", GROUP="video" > > This is unnecessary; stock udev already contains proper rules for almost > > all FireWire applications, including (H)DV capture. > > I removed this file. Should there be a rule for firewire in /etc/udev? > david@david:/etc/udev$ grep -ri firewire . > david@david:/etc/udev$ <nothing> $ grep -r firewire /lib/udev/ should turn up a few hits. I am following up on the rest later. -- Stefan Richter -=====-===== =-=- -==-- http://arcgraph.de/sr/ |
From: David <da...@ke...> - 2015-10-19 00:14:38
|
Hi I've discovered the problem. The motherboard has an on-board firewire of which I was unaware. If I plug into the motherboard everything works as advertised. It seems that the PCI board is being ignored. Since I only have one firewire device I'm not sure what would happen if I plug a second device into the card. Would it get recognised? I can't find any way to turn off the on-board firewire to try this. Meantime, thanks for your encouragement and help. On 13/10/15 01:09, Stefan Richter wrote: > On Oct 12 David wrote: >> On 12/10/15 17:35, Stefan Richter wrote: >>> On Oct 12 David wrote: >>>> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules >>>> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" >>>> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" >>>> SUBSYSTEM=="firewire", GROUP="video" >>> This is unnecessary; stock udev already contains proper rules for almost >>> all FireWire applications, including (H)DV capture. >> I removed this file. Should there be a rule for firewire in /etc/udev? >> david@david:/etc/udev$ grep -ri firewire . >> david@david:/etc/udev$ <nothing> > $ grep -r firewire /lib/udev/ > should turn up a few hits. > > I am following up on the rest later. -- David McQuire 0418 310312 |
From: Carl K. <ca...@pe...> - 2015-10-19 04:28:12
|
On Sun, Oct 18, 2015 at 7:14 PM, David <da...@ke...> wrote: > Hi > > I've discovered the problem. The motherboard has an on-board firewire of > which I was unaware. If I plug into the motherboard everything works as > advertised. It seems that the PCI board is being ignored. Since I only > have one firewire device I'm not sure what would happen if I plug a > second device into the card. Would it get recognised? If I understand your question, No. it sounds like a faulty card, or it isn't seated, or something of bad hardware. pull it out, run lspci >lspci.1.txt add it back, lspci >lspci.2.txt diff lspci.1.txtlspci.2.txt If you don't see a new entry... um... you don't have a card ;) if you do see a 2nd firewire card, you should see /dev/fw0 /dev/fw1 and when you plug in your dv camera to either card: /dev/fw2 > > I can't find any way to turn off the on-board firewire to try this. > > Meantime, thanks for your encouragement and help. > > On 13/10/15 01:09, Stefan Richter wrote: >> On Oct 12 David wrote: >>> On 12/10/15 17:35, Stefan Richter wrote: >>>> On Oct 12 David wrote: >>>>> david@david:~$ cat /etc/udev/rules.d/z95_firewire.rules >>>>> KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video" >>>>> SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video" >>>>> SUBSYSTEM=="firewire", GROUP="video" >>>> This is unnecessary; stock udev already contains proper rules for almost >>>> all FireWire applications, including (H)DV capture. >>> I removed this file. Should there be a rule for firewire in /etc/udev? >>> david@david:/etc/udev$ grep -ri firewire . >>> david@david:/etc/udev$ <nothing> >> $ grep -r firewire /lib/udev/ >> should turn up a few hits. >> >> I am following up on the rest later. > > -- > David McQuire > 0418 310312 > > > ------------------------------------------------------------------------------ > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user -- Carl K |
From: Stefan R. <st...@s5...> - 2015-10-19 06:41:23
|
On Oct 18 Carl Karsten wrote: > On Sun, Oct 18, 2015 at 7:14 PM, David <da...@ke...> wrote: > > Hi > > > > I've discovered the problem. The motherboard has an on-board firewire of > > which I was unaware. If I plug into the motherboard everything works as > > advertised. It seems that the PCI board is being ignored. Since I only > > have one firewire device I'm not sure what would happen if I plug a > > second device into the card. Would it get recognised? > > If I understand your question, No. > > it sounds like a faulty card, or it isn't seated, or something of bad hardware. Or a bad PCIe-to-PCI bridge. Though the bad controller card and the good onboard controller apparently sit both behind the same bridge, which would be 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5) according to the posting on October 12, so the bridge works at least for the onboard controller. > pull it out, run lspci >lspci.1.txt > add it back, lspci >lspci.2.txt > > diff lspci.1.txt lspci.2.txt > > If you don't see a new entry... um... you don't have a card ;) > > if you do see a 2nd firewire card, you should see > /dev/fw0 > /dev/fw1 > > and when you plug in your dv camera to either card: > /dev/fw2 > > > > > > I can't find any way to turn off the on-board firewire to try this. You don't need to turn off one FireWire controller in order to use another. Arbitrary many cards in the same system are supported. -- Stefan Richter -=====-===== =-=- =--== http://arcgraph.de/sr/ |