linux1394-user Mailing List for IEEE 1394 for Linux (Page 17)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Clemens L. <cl...@la...> - 2011-07-29 14:52:01
|
Stefan Richter wrote: > On Jul 29 Clemens Ladisch wrote: > > Stefan, might it be a good idea to allow all old IRMs that look like > > such a camera, i.e., if they are a S100 device? > > Good idea.¹ But then we need to address the bug with Sony's bogus IRM in > a different way. > http://git.kernel.org/linus/10389536742cefbedecb67a5b2906f155cf3a1c3 > E.g. do not act as BM if we are not IRM too. I think I have seen another > OS doing exactly this. There are IRM-capable S400 devices that are not BM capable, so I think a S100 check would be appropriate here, too. In other words, (only) if the IRM is S100, leave it completely alone. (I guess there might be some cameras with working firmware, but are there any other S100-only A/V devices?) Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-07-29 13:17:12
|
On Jul 29 Clemens Ladisch wrote: > In theory, both should work with > a camera like yours, but it's possible that your VT6308 has smaller > tolerances, that the signal is degraded because of long lines on the > motherboard, or that it's just plain broken. On PC mainboards, the lines between the PHY and the ports may be very long, may contain many turns, may go through vias --- all pitfalls which are to be avoided in 1394 device board layouts. And if there is a breakout cable to a front panel (one without an own dedicated phy), that makes it only worse. > Stefan, might it be a good idea to allow all old IRMs that look like > such a camera, i.e., if they are a S100 device? Good idea.¹ But then we need to address the bug with Sony's bogus IRM in a different way. http://git.kernel.org/linus/10389536742cefbedecb67a5b2906f155cf3a1c3 E.g. do not act as BM if we are not IRM too. I think I have seen another OS doing exactly this. Carl, it would be very useful to know what happens after the modification of CANON_OUI in drivers/firewire/core-card.c as Clemens suggested. ¹) Not trying to become IRM when a 1394-1995-only IRM is detected goes squarely against 1394a-2000 of course. But there is little choice. -- Stefan Richter -=====-==-== -=== ===-= http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-07-29 08:00:25
|
Carl Karsten wrote: > ASUS motherboard, one on board firewire, one pci card. PCI or PCI Express? > plug camera into card, all works fine. plug into on board and things fail Which points to a hardware error. > (veyepar)juser@cnt2:~$ lspci |grep 13 > 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) > 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) The VT6315 is a rather new PCIe chip; the VT6308 is a rather old PCI chip that is known to have problems. In theory, both should work with a camera like yours, but it's possible that your VT6308 has smaller tolerances, that the signal is degraded because of long lines on the motherboard, or that it's just plain broken. Does it work when you connect the VT6315 directly to the VT6308 (i.e., do you get four devices fw0..fw3)? > (veyepar)juser@cnt2:~$ dvgrab > Error: no camera exists > > ... > [ 1572.087990] firewire_ohci: isochronous cycle inconsistent > [ 1572.798527] firewire_core: created device fw2: GUID 008045821097902b, S100 Here, after many bus resets, a device from Matsushita is found. > [ 1572.798534] firewire_core: phy config: card 1, new root=ffc1, gap_count=5 > [ 1572.799208] firewire_core: IRM is not 1394a compliant, making local node (ffc0) root. But it complies only with the oldest 1394 standard, so it is not allowed to be root (the root node does some bus management functions; if an old node is root, some new 1394a features would not be available). Switching the root node should, in theory, not be a problem, however ... > [ 1572.799211] firewire_core: phy config: card 1, new root=ffc0, gap_count=5 ... after the bus reset that made the switch, the camera has vanished again. This looks very much like this bug <https://bugzilla.redhat.com/show_bug.cgi?id=633260> that was worked around with commit 6044565af458 (fix unstable I/O with Canon camcorder). It's possible that these Canon and Matsushita cameras use the same PHY chip, or the same FireWire interface firmware. Carl, to find out which PHY chip the camera uses, please try to run the lsfirewirephy tool from the jujuutils package (<http://code.google.com/p/jujuutils/>) with the camera connected to the working controller. To check if the Canon workaround works with your camera, recompile firewire-core after changing the value of CANON_OUI in drivers/firewire/core-card.c from 0x000085 to 0x008045. Stefan, might it be a good idea to allow all old IRMs that look like such a camera, i.e., if they are a S100 device? Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-07-29 06:29:47
|
On Jul 28 Walt Frazer wrote: > I have a dell E520 on which I run Ubuntu 11.4. I also have a Sony > Handycam DCR H30, and wanted to do some editing of videotapes. The E520 > doesn't have firewire, so I got a PCI Card I thought was > linux-compatible. I then downloaded kino, but it gives me the "warning, > raw 1394 module not loaded" mesg, Kino is no longer actively updated. Therefore it warns about raw1394 not being there, which is normal in current Linux distributions. Kino only needs 1. the firewire-core and firewire-ohci kernel modules being loaded into the kernel, 2. firewire-ohci being successfully bound to a controller, 3. firewire-core successfully talking to attached FireWire devices, 4. udev configuring proper access permisions or ownership of /dev/fw* character device files. I suspect the third point goes wrong on your system. > but WILL open up when I go through sudo kino. . . Don't run application programs with sudo. This is dangerous and may malfunction. > but then it says "no avc compliant cam connected or not > switched on", and it doesn't know when I do switch it on. > > lspci: 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 > [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) OK; this is a VIA VT6307 which many people use successfully under Linux. I had one myself for a while on a mainboard. > grep 1394 /var/log/kern.log > Jul 25 17:41:49 walt-Dell-DM061 kernel: [ 1.913943] pnp 00:06: [mem 0x01000000-0x1f651bff] > Jul 25 17:41:49 walt-Dell-DM061 kernel: [ 1.913947] pnp 00:06: [mem 0x000f0000-0x000fffff] > Jul 26 21:01:59 walt-Dell-DM061 kernel: [ 9.139447] usbcore: registered new interface driver usblp > Jul 27 10:25:08 walt-Dell-DM061 kernel: [ 1.851394] PCI: Using ACPI for IRQ routing Yeah, just don't filter through grep then. :-) > Which seems to show it isn't initialized. I downloaded and installed > everything I could find in synaptic that had anything to do with 1394. > > Can you tell me what I'm missing? > > Thanx for your help. As root user, run "echo 7 > /sys/module/firewire_ohci/parameters/debug", then connect the camcorder, then watch what is being added to the kernel log and post the result here. -- Stefan Richter -=====-==-== -=== ===-= http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-07-29 03:40:08
|
ASUS motherboard, one on board firewire, one pci card. plug camera into card, all works fine. plug into on board and things fail (veyepar)juser@cnt2:~$ lspci |grep 13 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) (veyepar)juser@cnt2:~$ dvgrab Error: no camera exists [ 1106.523403] firewire_core: skipped bus generations, destroying all nodes [ 1107.020284] firewire_core: rediscovered device fw0 [ 1561.141043] firewire_core: skipped bus generations, destroying all nodes [ 1561.638991] firewire_core: rediscovered device fw0 [ 1561.638999] firewire_core: giving up on config rom for node id ffc0 [ 1572.087990] firewire_ohci: isochronous cycle inconsistent [ 1572.798527] firewire_core: created device fw2: GUID 008045821097902b, S100 [ 1572.798534] firewire_core: phy config: card 1, new root=ffc1, gap_count=5 [ 1572.799208] firewire_core: IRM is not 1394a compliant, making local node (ffc0) root. [ 1572.799211] firewire_core: phy config: card 1, new root=ffc0, gap_count=5 [ 1669.889695] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 -- Carl K |
From: Walt F. <qua...@gm...> - 2011-07-29 01:35:49
|
Hello all: I have a dell E520 on which I run Ubuntu 11.4. I also have a Sony Handycam DCR H30, and wanted to do some editing of videotapes. The E520 doesn't have firewire, so I got a PCI Card I thought was linux-compatible. I then downloaded kino, but it gives me the "warning, raw 1394 module not loaded" mesg, but WILL open up when I go through sudo kino. . .but then it says "no avc compliant cam connected or not switched on", and it doesn't know when I do switch it on. lspci: 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 80) grep 1394 /var/log/kern.log Jul 25 17:41:49 walt-Dell-DM061 kernel: [ 1.913943] pnp 00:06: [mem 0x01000000-0x1f651bff] Jul 25 17:41:49 walt-Dell-DM061 kernel: [ 1.913947] pnp 00:06: [mem 0x000f0000-0x000fffff] Jul 26 21:01:59 walt-Dell-DM061 kernel: [ 9.139447] usbcore: registered new interface driver usblp Jul 27 10:25:08 walt-Dell-DM061 kernel: [ 1.851394] PCI: Using ACPI for IRQ routing Which seems to show it isn't initialized. I downloaded and installed everything I could find in synaptic that had anything to do with 1394. Can you tell me what I'm missing? Thanx for your help. |
From: tps <tp...@ne...> - 2011-07-28 18:14:35
|
Carl Karsten writes: > On Thu, Jul 28, 2011 at 2:40 AM, Thomas Seilund <tp...@ne...> wrote: >> On 28-07-2011 08:41, Stefan Richter wrote: >>> >>> On Jul 27 Carl Karsten wrote: >>>> >>>> On Wed, Jul 27, 2011 at 12:30 PM, Stefan Richter >>>> <st...@s5...> wrote: >>>>> >>>>> On Jul 27 tps wrote: >>>>>> >>>>>> lspci on MacBook Pro: (note no reference to firewire!!!. ) >>>>> >>>>> [...] >>>>> >>>>> This s a pity. I would have liked to know whether OS X has a trick up >>>>> its >>>>> sleeve which Linux doesn't; hence the need to run either OS on the very >>>>> same hardware. >>>>> >>>>>> I reboot the MacBook Pro into native OS and I plug in the Panasonic >>>>>> camera >>>>>> and still there is no activity in the log. After capturing video from >>>>>> the >>>>>> Panasonic camera with iMovie I note that dmesg shows: >>>>>> FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 >>>>>> minutes. >>>>> >>>>> Which means that it doesn't actually work right. There should be no bus >>>>> reset at all beginning a few seconds after the camcorder was connected. >>>>> These bus resets during capture means that the bus is in fact unstable >>>>> on >>>>> the physical layer level. It is likely the DV that you captured misses >>>>> frames around each of these bus resets. >>>>> >>>>> Sounds all like the FireWire port of this old camcorder is going bad. >>>> >>>> about 3 years ago when I first started paying attention to what was >>>> going on, a friend and I drank beer and concluded that other OS's must >>>> be more tolerant of problems. >>> >>> In this case, the jury is still out. This is a comparison between >>> - wacky camcorder + an excellent Agere controller + OS X (recognizes the >>> camcorder and is able to fetch DV, though possibly not 100% free of >>> framedrops due to bus resets), and >>> - wacky camcorder + a mediocre NEC controller + Linux (does not even >>> get to the second quadlet of the Configuration ROM, but not because >>> of bus resets but because of ack-busy that don't make sense). >>> We just don't know yet how much of a role the controller plays in this >>> issue, or whether the different behavior is due to the OS X driver doing >>> things differently --- coincidentally or by design. >>> >>>> Given the camera is digitising analogue data (light reflecting off >>>> subjects) its easy to cover up problems that would be otherwise >>>> obvious on something like a hard drive. if every few minutes you >>>> loose a few frames, even a second or 2 over a 10 minute period, many >>>> people won't notice, and those that do are likely to just dismiss it >>>> as editing, encoding or player hiccups. >>> >>> Right; video dropouts may go unnoticed or be dismissed. Audible dropouts >>> are more likely to be noticed than mere visible dropouts. >>> >>> AFAIU kino or dvgrab do deal with missing frames. I am not experienced >>> though WRT their operation in face of bus resets. >>> >>> But my opinion is: There is no use to attempt to make the system software >>> and application software deal well with _defective hardware_. With some >>> luck, you can optimize it on one particular specimen of broken, >>> semi-randomly behaving hardware but it will still fail on the next >>> specimen. And it introduces costs of development or/and of operation on >>> proper hardware. >>> >>> In contrast, if there are hardware bugs or firmware bugs that result in >>> wrong but _predictable_ behavior, we try to work around them in software. >>> It is furthermore a different matter if hardware performs self-checks and >>> reports errors to software, e.g. like with ECC RAM. >>> >>> Anyway, back to the ack-busy issue. Thomas, right now I can think of >>> three >>> things that could be attempted next --- as mere shots in the dark though: >>> - Change firewire-ohci's maxATReqRetries setting from the current >>> maximum possible value to something less. >>> - Disable firewire-core's bus management. >>> - 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. >>> These require recompilation of the kernel from source. >>> >>> Or/ and try a different distribution's boot medium on the Mac to see >>> whether that recognizes the PCI FireWire controller. >>> >>> Or if your Linux box has got a spare PCI/ PCIe/ CardBus/ ExpressCard slot >>> and you know a dealer with a proper return policy, try a different >>> FireWire controller. >> >> Hi, your help is very much appreciated. I will prefer buy new hardware as >> opposed to use to much time making 'mediocre' and / or defective hardware >> work. As I read your post you seem to suggest the same. >> >> The thing is I have got a set up that I have used for a few years where I >> capture basketball games in real time and stream live. It works fine with my >> low budget JVC GR-D720E camera, IBM T60 with NEC PCMCIA Firewire card and >> Ubuntu 11.04 (dvgrab and ffmpeg). >> >> Still, I am not satisfied with the video quality so I bought a second hand >> Panasonic AG-EZ30 3CCD camera as I read that 3CCD is essential for recording >> sports. >> >> I know I can do a lot with ffmpeg parameters to influence video quality but >> my idea was that if I can improve the quality from the source, ie. from the >> camera, I would be better off. I have no intention of going from SD to HD - >> for what I do I don't think it is worth the effort. >> >> For now I will live with the JVC GR-D720E camera and then go look for 1. New >> and better PCMCIA Firewire card. 2. Another SD 3CCD camera. 3. Another >> computer with build in firewire port. > > Are you using tapes? > > If so, keep in mind that the tape data is digital, so you can use a > low quality camera to play it when transferring over firewire using > dvgrab/kino/kdenlive... > > > -- > Carl K Thanks. I am not using tape. I am capturing live via firewire. Or rather trying to !! Thomas S Venlig hilsen Thomas Seilund Løkketoften 46 2625 Vallensbæk |
From: Carl K. <ca...@pe...> - 2011-07-28 13:39:44
|
On Thu, Jul 28, 2011 at 2:40 AM, Thomas Seilund <tp...@ne...> wrote: > On 28-07-2011 08:41, Stefan Richter wrote: >> >> On Jul 27 Carl Karsten wrote: >>> >>> On Wed, Jul 27, 2011 at 12:30 PM, Stefan Richter >>> <st...@s5...> wrote: >>>> >>>> On Jul 27 tps wrote: >>>>> >>>>> lspci on MacBook Pro: (note no reference to firewire!!!. ) >>>> >>>> [...] >>>> >>>> This s a pity. I would have liked to know whether OS X has a trick up >>>> its >>>> sleeve which Linux doesn't; hence the need to run either OS on the very >>>> same hardware. >>>> >>>>> I reboot the MacBook Pro into native OS and I plug in the Panasonic >>>>> camera >>>>> and still there is no activity in the log. After capturing video from >>>>> the >>>>> Panasonic camera with iMovie I note that dmesg shows: >>>>> FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 >>>>> minutes. >>>> >>>> Which means that it doesn't actually work right. There should be no bus >>>> reset at all beginning a few seconds after the camcorder was connected. >>>> These bus resets during capture means that the bus is in fact unstable >>>> on >>>> the physical layer level. It is likely the DV that you captured misses >>>> frames around each of these bus resets. >>>> >>>> Sounds all like the FireWire port of this old camcorder is going bad. >>> >>> about 3 years ago when I first started paying attention to what was >>> going on, a friend and I drank beer and concluded that other OS's must >>> be more tolerant of problems. >> >> In this case, the jury is still out. This is a comparison between >> - wacky camcorder + an excellent Agere controller + OS X (recognizes the >> camcorder and is able to fetch DV, though possibly not 100% free of >> framedrops due to bus resets), and >> - wacky camcorder + a mediocre NEC controller + Linux (does not even >> get to the second quadlet of the Configuration ROM, but not because >> of bus resets but because of ack-busy that don't make sense). >> We just don't know yet how much of a role the controller plays in this >> issue, or whether the different behavior is due to the OS X driver doing >> things differently --- coincidentally or by design. >> >>> Given the camera is digitising analogue data (light reflecting off >>> subjects) its easy to cover up problems that would be otherwise >>> obvious on something like a hard drive. if every few minutes you >>> loose a few frames, even a second or 2 over a 10 minute period, many >>> people won't notice, and those that do are likely to just dismiss it >>> as editing, encoding or player hiccups. >> >> Right; video dropouts may go unnoticed or be dismissed. Audible dropouts >> are more likely to be noticed than mere visible dropouts. >> >> AFAIU kino or dvgrab do deal with missing frames. I am not experienced >> though WRT their operation in face of bus resets. >> >> But my opinion is: There is no use to attempt to make the system software >> and application software deal well with _defective hardware_. With some >> luck, you can optimize it on one particular specimen of broken, >> semi-randomly behaving hardware but it will still fail on the next >> specimen. And it introduces costs of development or/and of operation on >> proper hardware. >> >> In contrast, if there are hardware bugs or firmware bugs that result in >> wrong but _predictable_ behavior, we try to work around them in software. >> It is furthermore a different matter if hardware performs self-checks and >> reports errors to software, e.g. like with ECC RAM. >> >> Anyway, back to the ack-busy issue. Thomas, right now I can think of >> three >> things that could be attempted next --- as mere shots in the dark though: >> - Change firewire-ohci's maxATReqRetries setting from the current >> maximum possible value to something less. >> - Disable firewire-core's bus management. >> - 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. >> These require recompilation of the kernel from source. >> >> Or/ and try a different distribution's boot medium on the Mac to see >> whether that recognizes the PCI FireWire controller. >> >> Or if your Linux box has got a spare PCI/ PCIe/ CardBus/ ExpressCard slot >> and you know a dealer with a proper return policy, try a different >> FireWire controller. > > Hi, your help is very much appreciated. I will prefer buy new hardware as > opposed to use to much time making 'mediocre' and / or defective hardware > work. As I read your post you seem to suggest the same. > > The thing is I have got a set up that I have used for a few years where I > capture basketball games in real time and stream live. It works fine with my > low budget JVC GR-D720E camera, IBM T60 with NEC PCMCIA Firewire card and > Ubuntu 11.04 (dvgrab and ffmpeg). > > Still, I am not satisfied with the video quality so I bought a second hand > Panasonic AG-EZ30 3CCD camera as I read that 3CCD is essential for recording > sports. > > I know I can do a lot with ffmpeg parameters to influence video quality but > my idea was that if I can improve the quality from the source, ie. from the > camera, I would be better off. I have no intention of going from SD to HD - > for what I do I don't think it is worth the effort. > > For now I will live with the JVC GR-D720E camera and then go look for 1. New > and better PCMCIA Firewire card. 2. Another SD 3CCD camera. 3. Another > computer with build in firewire port. Are you using tapes? If so, keep in mind that the tape data is digital, so you can use a low quality camera to play it when transferring over firewire using dvgrab/kino/kdenlive... -- Carl K |
From: Stefan R. <st...@s5...> - 2011-07-28 12:32:45
|
On Jul 28 Thomas Seilund wrote: > On 28-07-2011 08:41, Stefan Richter wrote: > > In this case, the jury is still out. This is a comparison between > > - wacky camcorder + an excellent Agere controller + OS X (recognizes the > > camcorder and is able to fetch DV, though possibly not 100% free of > > framedrops due to bus resets), and > > - wacky camcorder + a mediocre NEC controller + Linux (does not even > > get to the second quadlet of the Configuration ROM, but not because > > of bus resets but because of ack-busy that don't make sense). > > We just don't know yet how much of a role the controller plays in this > > issue, or whether the different behavior is due to the OS X driver doing > > things differently [...] > Hi, your help is very much appreciated. I will prefer buy new hardware > as opposed to use to much time making 'mediocre' and / or defective > hardware work. As I read your post you seem to suggest the same. Well, as mentioned, there are some modifications of the driver source code that could be experimented with, but (a) chances aren't high that these are going to do any good, (b) going from a distributor kernel to a self-compiled kernel is not quite easy if never done before. [...] > For now I will live with the JVC GR-D720E camera and then go look for 1. > New and better PCMCIA Firewire card. 2. Another SD 3CCD camera. 3. > Another computer with build in firewire port. To put my 'mediocre NEC controller' sentence into perspective: The very first FireWire controller that I got myself about ten years ago is a NEC based CardBus card, and it always served me very well and still does. It only has some shortcomings at the link layer that make it unsuitable for one very demanding purpose in the FireWire audio domain (using more than one audio device on it simultaneously and synchronized --- this is a border use case that only succeeds with Texas Instruments and Agere based cards). But so far I never observed issues at the physical level with this NEC card here. Still, if you can try a different controller, do so. -- Stefan Richter -=====-==-== -=== ===-- http://arcgraph.de/sr/ |
From: Thomas S. <tp...@ne...> - 2011-07-28 08:21:44
|
On 28-07-2011 08:41, Stefan Richter wrote: > On Jul 27 Carl Karsten wrote: >> On Wed, Jul 27, 2011 at 12:30 PM, Stefan Richter >> <st...@s5...> wrote: >>> On Jul 27 tps wrote: >>>> lspci on MacBook Pro: (note no reference to firewire!!!. ) >>> [...] >>> >>> This s a pity. I would have liked to know whether OS X has a trick up its >>> sleeve which Linux doesn't; hence the need to run either OS on the very >>> same hardware. >>> >>>> I reboot the MacBook Pro into native OS and I plug in the Panasonic camera >>>> and still there is no activity in the log. After capturing video from the >>>> Panasonic camera with iMovie I note that dmesg shows: >>>> FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 minutes. >>> Which means that it doesn't actually work right. There should be no bus >>> reset at all beginning a few seconds after the camcorder was connected. >>> These bus resets during capture means that the bus is in fact unstable on >>> the physical layer level. It is likely the DV that you captured misses >>> frames around each of these bus resets. >>> >>> Sounds all like the FireWire port of this old camcorder is going bad. >> about 3 years ago when I first started paying attention to what was >> going on, a friend and I drank beer and concluded that other OS's must >> be more tolerant of problems. > In this case, the jury is still out. This is a comparison between > - wacky camcorder + an excellent Agere controller + OS X (recognizes the > camcorder and is able to fetch DV, though possibly not 100% free of > framedrops due to bus resets), and > - wacky camcorder + a mediocre NEC controller + Linux (does not even > get to the second quadlet of the Configuration ROM, but not because > of bus resets but because of ack-busy that don't make sense). > We just don't know yet how much of a role the controller plays in this > issue, or whether the different behavior is due to the OS X driver doing > things differently --- coincidentally or by design. > >> Given the camera is digitising analogue data (light reflecting off >> subjects) its easy to cover up problems that would be otherwise >> obvious on something like a hard drive. if every few minutes you >> loose a few frames, even a second or 2 over a 10 minute period, many >> people won't notice, and those that do are likely to just dismiss it >> as editing, encoding or player hiccups. > Right; video dropouts may go unnoticed or be dismissed. Audible dropouts > are more likely to be noticed than mere visible dropouts. > > AFAIU kino or dvgrab do deal with missing frames. I am not experienced > though WRT their operation in face of bus resets. > > But my opinion is: There is no use to attempt to make the system software > and application software deal well with _defective hardware_. With some > luck, you can optimize it on one particular specimen of broken, > semi-randomly behaving hardware but it will still fail on the next > specimen. And it introduces costs of development or/and of operation on > proper hardware. > > In contrast, if there are hardware bugs or firmware bugs that result in > wrong but _predictable_ behavior, we try to work around them in software. > It is furthermore a different matter if hardware performs self-checks and > reports errors to software, e.g. like with ECC RAM. > > Anyway, back to the ack-busy issue. Thomas, right now I can think of three > things that could be attempted next --- as mere shots in the dark though: > - Change firewire-ohci's maxATReqRetries setting from the current > maximum possible value to something less. > - Disable firewire-core's bus management. > - 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. > These require recompilation of the kernel from source. > > Or/ and try a different distribution's boot medium on the Mac to see > whether that recognizes the PCI FireWire controller. > > Or if your Linux box has got a spare PCI/ PCIe/ CardBus/ ExpressCard slot > and you know a dealer with a proper return policy, try a different > FireWire controller. Hi, your help is very much appreciated. I will prefer buy new hardware as opposed to use to much time making 'mediocre' and / or defective hardware work. As I read your post you seem to suggest the same. The thing is I have got a set up that I have used for a few years where I capture basketball games in real time and stream live. It works fine with my low budget JVC GR-D720E camera, IBM T60 with NEC PCMCIA Firewire card and Ubuntu 11.04 (dvgrab and ffmpeg). Still, I am not satisfied with the video quality so I bought a second hand Panasonic AG-EZ30 3CCD camera as I read that 3CCD is essential for recording sports. I know I can do a lot with ffmpeg parameters to influence video quality but my idea was that if I can improve the quality from the source, ie. from the camera, I would be better off. I have no intention of going from SD to HD - for what I do I don't think it is worth the effort. For now I will live with the JVC GR-D720E camera and then go look for 1. New and better PCMCIA Firewire card. 2. Another SD 3CCD camera. 3. Another computer with build in firewire port. Again thanks a lot for all the help. |
From: Stefan R. <st...@s5...> - 2011-07-28 06:41:37
|
On Jul 27 Carl Karsten wrote: > On Wed, Jul 27, 2011 at 12:30 PM, Stefan Richter > <st...@s5...> wrote: > > On Jul 27 tps wrote: > >> lspci on MacBook Pro: (note no reference to firewire!!!. ) > > [...] > > > > This s a pity. I would have liked to know whether OS X has a trick up its > > sleeve which Linux doesn't; hence the need to run either OS on the very > > same hardware. > > > >> I reboot the MacBook Pro into native OS and I plug in the Panasonic camera > >> and still there is no activity in the log. After capturing video from the > >> Panasonic camera with iMovie I note that dmesg shows: > >> FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 minutes. > > > > Which means that it doesn't actually work right. There should be no bus > > reset at all beginning a few seconds after the camcorder was connected. > > These bus resets during capture means that the bus is in fact unstable on > > the physical layer level. It is likely the DV that you captured misses > > frames around each of these bus resets. > > > > Sounds all like the FireWire port of this old camcorder is going bad. > > about 3 years ago when I first started paying attention to what was > going on, a friend and I drank beer and concluded that other OS's must > be more tolerant of problems. In this case, the jury is still out. This is a comparison between - wacky camcorder + an excellent Agere controller + OS X (recognizes the camcorder and is able to fetch DV, though possibly not 100% free of framedrops due to bus resets), and - wacky camcorder + a mediocre NEC controller + Linux (does not even get to the second quadlet of the Configuration ROM, but not because of bus resets but because of ack-busy that don't make sense). We just don't know yet how much of a role the controller plays in this issue, or whether the different behavior is due to the OS X driver doing things differently --- coincidentally or by design. > Given the camera is digitising analogue data (light reflecting off > subjects) its easy to cover up problems that would be otherwise > obvious on something like a hard drive. if every few minutes you > loose a few frames, even a second or 2 over a 10 minute period, many > people won't notice, and those that do are likely to just dismiss it > as editing, encoding or player hiccups. Right; video dropouts may go unnoticed or be dismissed. Audible dropouts are more likely to be noticed than mere visible dropouts. AFAIU kino or dvgrab do deal with missing frames. I am not experienced though WRT their operation in face of bus resets. But my opinion is: There is no use to attempt to make the system software and application software deal well with _defective hardware_. With some luck, you can optimize it on one particular specimen of broken, semi-randomly behaving hardware but it will still fail on the next specimen. And it introduces costs of development or/and of operation on proper hardware. In contrast, if there are hardware bugs or firmware bugs that result in wrong but _predictable_ behavior, we try to work around them in software. It is furthermore a different matter if hardware performs self-checks and reports errors to software, e.g. like with ECC RAM. Anyway, back to the ack-busy issue. Thomas, right now I can think of three things that could be attempted next --- as mere shots in the dark though: - Change firewire-ohci's maxATReqRetries setting from the current maximum possible value to something less. - Disable firewire-core's bus management. - 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. These require recompilation of the kernel from source. Or/ and try a different distribution's boot medium on the Mac to see whether that recognizes the PCI FireWire controller. Or if your Linux box has got a spare PCI/ PCIe/ CardBus/ ExpressCard slot and you know a dealer with a proper return policy, try a different FireWire controller. -- Stefan Richter -=====-==-== -=== ===-- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-07-27 23:28:41
|
On Wed, Jul 27, 2011 at 12:30 PM, Stefan Richter <st...@s5...> wrote: > On Jul 27 tps wrote: >> On my MacBook Pro: >> - hold down c >> - power on >> - insert Ubuntu 11.04 CD >> - select "Try Ubuntu" >> >> When I connect Panasonic camera and turn it on then there is no activity in >> the kernel log. > > ...because the PCI subsystem is unaware of the FireWire controller. Why > that is I don't know. There may be something in "dmesg" early during > boot. But it is not a FireWire problem. > >> When connecting the camera I use a 4 pin / 9 pin cable as I >> believe the MacBook Pro has firewire 800 input. > > OK. FWIW, my somewhat recent JVC camcorder and my older Canon camcorder > both work fine with a 4-pin to 9-pin cable on an Agere FW643e card and a > Texas Instruments TSB82AA2 + TSB81BA3 card. > >> lspci on MacBook Pro: (note no reference to firewire!!!. ) > [...] > > This s a pity. I would have liked to know whether OS X has a trick up its > sleeve which Linux doesn't; hence the need to run either OS on the very > same hardware. > >> I reboot the MacBook Pro into native OS and I plug in the Panasonic camera >> and still there is no activity in the log. After capturing video from the >> Panasonic camera with iMovie I note that dmesg shows: >> FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 minutes. > > Which means that it doesn't actually work right. There should be no bus > reset at all beginning a few seconds after the camcorder was connected. > These bus resets during capture means that the bus is in fact unstable on > the physical layer level. It is likely the DV that you captured misses > frames around each of these bus resets. > > Sounds all like the FireWire port of this old camcorder is going bad. about 3 years ago when I first started paying attention to what was going on, a friend and I drank beer and concluded that other OS's must be more tolerant of problems. Given the camera is digitising analogue data (light reflecting off subjects) its easy to cover up problems that would be otherwise obvious on something like a hard drive. if every few minutes you loose a few frames, even a second or 2 over a 10 minute period, many people won't notice, and those that do are likely to just dismiss it as editing, encoding or player hiccups. The win users are conditioned to either tolerate nonsense or reboot, defrag and wait for another Tuesday update. -- Carl K |
From: Stefan R. <st...@s5...> - 2011-07-27 17:30:42
|
On Jul 27 tps wrote: > On my MacBook Pro: > - hold down c > - power on > - insert Ubuntu 11.04 CD > - select "Try Ubuntu" > > When I connect Panasonic camera and turn it on then there is no activity in > the kernel log. ...because the PCI subsystem is unaware of the FireWire controller. Why that is I don't know. There may be something in "dmesg" early during boot. But it is not a FireWire problem. > When connecting the camera I use a 4 pin / 9 pin cable as I > believe the MacBook Pro has firewire 800 input. OK. FWIW, my somewhat recent JVC camcorder and my older Canon camcorder both work fine with a 4-pin to 9-pin cable on an Agere FW643e card and a Texas Instruments TSB82AA2 + TSB81BA3 card. > lspci on MacBook Pro: (note no reference to firewire!!!. ) [...] This s a pity. I would have liked to know whether OS X has a trick up its sleeve which Linux doesn't; hence the need to run either OS on the very same hardware. > I reboot the MacBook Pro into native OS and I plug in the Panasonic camera > and still there is no activity in the log. After capturing video from the > Panasonic camera with iMovie I note that dmesg shows: > FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 minutes. Which means that it doesn't actually work right. There should be no bus reset at all beginning a few seconds after the camcorder was connected. These bus resets during capture means that the bus is in fact unstable on the physical layer level. It is likely the DV that you captured misses frames around each of these bus resets. Sounds all like the FireWire port of this old camcorder is going bad. -- Stefan Richter -=====-==-== -=== ==-== http://arcgraph.de/sr/ |
From: tps <tp...@ne...> - 2011-07-27 16:12:20
|
Stefan Richter writes: > On Jul 26 tps wrote: >> I can't make my Panasonic AG-EZ30 camera work on my IBM Labtop T60 with >> Ubuntu 11.04. Below you see the details. The camera is connected through a >> PCMCIA Firewire card. If I plug in another camera, ie. JVC GR-D720E >> everything is file. The Panasonic camera works fine on a Mac. > [...] >> Jul 26 16:52:42 t60 kernel: [ 933.272225] firewire_ohci: AT spd 0 tl 08, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 >> Jul 26 16:52:42 t60 kernel: [ 933.280913] firewire_ohci: AR spd 0 tl 08, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 > > Here, firewire-core starts to read the Configuration ROM register of the > remote node in order to find out what kind of device it is. The > camcorder's response means: > - The firmware has readied the Configuration ROM, > - the first section of it (the so-called bus information block) is 4 > quadlets long (as required by the standard), > - the first CRC was computed for the next 15 quadlets, > - that CRC is 0xb170. > > That's all nice and well and firewire-core attempts to fetch the next > quadlet: > >> Jul 26 16:52:42 t60 kernel: [ 933.281421] firewire_ohci: AT spd 0 tl 09, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 > > But the camcorder now responds with "I'm busy, try again later". > > firewire-core makes a short pause, then starts again at the beginning of > the Configuration ROM, gets the very same header quadlet, proceeds o the > next quadlet, gets again ack-busy. > > In total, firewire-core tries this 10 times with plenty of pauses. Yet > the camcorder's firmware never shows the next quadlet or more --- even > though it allegedly has the entire Configuration ROM ready to be read, and > even though there is no third node on the bus trying to get to the > Configuration ROM. > >> Jul 26 16:52:42 t60 kernel: [ 933.281447] firewire_core: giving up on config rom for node id ffc0 > > So, at some point firewire-core decides that enough is enough. > > I have no idea why the camcorder refuses to work while it does work on the > Mac. Maybe you are using different cables. On the other hand, cable > problems typically look at lot different from what you reported. > > Or maybe the camcorder's physical interface chip is junk and does not > interoperate with the uPD72874's phy. > > Could you try a Linux live CD or Live USB stick on the Mac and see whether > it recognizes the camcorder when running on that other hardware? On my MacBook Pro: - hold down c - power on - insert Ubuntu 11.04 CD - select "Try Ubuntu" When I connect Panasonic camera and turn it on then there is no activity in the kernel log. When connecting the camera I use a 4 pin / 9 pin cable as I believe the MacBook Pro has firewire 800 input. lspci on MacBook Pro: (note no reference to firewire!!!. ) 00:00.0 Host bridge: nVidia Corporation MCP89 HOST Bridge (rev a1) 00:00.1 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:01.0 RAM memory: nVidia Corporation Device 0d6d (rev a1) 00:01.1 RAM memory: nVidia Corporation Device 0d6e (rev a1) 00:01.2 RAM memory: nVidia Corporation Device 0d6f (rev a1) 00:01.3 RAM memory: nVidia Corporation Device 0d70 (rev a1) 00:02.0 RAM memory: nVidia Corporation Device 0d71 (rev a1) 00:02.1 RAM memory: nVidia Corporation Device 0d72 (rev a1) 00:03.0 ISA bridge: nVidia Corporation MCP89 LPC Bridge (rev a2) 00:03.1 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:03.2 SMBus: nVidia Corporation MCP89 SMBus (rev a1) 00:03.3 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:03.4 Co-processor: nVidia Corporation MCP89 Co-Processor (rev a1) 00:04.0 USB Controller: nVidia Corporation MCP89 OHCI USB 1.1 Controller (rev a1) 00:04.1 USB Controller: nVidia Corporation MCP89 EHCI USB 2.0 Controller (rev a2) 00:06.0 USB Controller: nVidia Corporation MCP89 OHCI USB 1.1 Controller (rev a1) 00:06.1 USB Controller: nVidia Corporation MCP89 EHCI USB 2.0 Controller (rev a2) 00:08.0 Audio device: nVidia Corporation MCP89 High Definition Audio (rev a2) 00:0a.0 IDE interface: nVidia Corporation MCP89 SATA Controller (rev a2) 00:0b.0 RAM memory: nVidia Corporation Device 0d75 (rev a1) 00:0e.0 PCI bridge: nVidia Corporation Device 0d9a (rev a1) 00:15.0 PCI bridge: nVidia Corporation Device 0d9b (rev a1) 00:16.0 PCI bridge: nVidia Corporation Device 0d9b (rev a1) 00:17.0 PCI bridge: nVidia Corporation MCP89 PCI Express Bridge (rev a1) 02:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10) 04:00.0 VGA compatible controller: nVidia Corporation Device 08a0 (rev a2) I reboot the MacBook Pro into native OS and I plug in the Panasonic camera and still there is no activity in the log. After capturing video from the Panasonic camera with iMovie I note that dmesg shows: FireWire (OHCI) Lucent ID 5901 built-in: 328 bus resets in last 3 minutes. > -- > Stefan Richter > -=====-==-== -=== ==-=- > http://arcgraph.de/sr/ Venlig hilsen Thomas Seilund Løkketoften 46 2625 Vallensbæk |
From: tps <tp...@ne...> - 2011-07-27 06:11:57
|
Stefan Richter writes: > On Jul 26 Stefan Richter wrote: >> Or maybe the camcorder's physical interface chip is junk and does not >> interoperate with the uPD72874's phy. > > Maybe the following does something, or maybe not: > > Disconnect camcorder. > > # modprobe -r firewire-ohci > # modprobe firewire-ohci quirks=9 debug=3 > > Check that the new quirks parameter is active now: > # dmesg | grep quirks Here is dmesg after I reinsert module firewire-ohci: tps@t60:~$ sudo modprobe firewire-ohci quirks=9 debug=3 tps@t60:~$ dmesg | grep quirks [ 2014.480195] firewire_ohci: Added fw-ohci device 0000:16:00.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 [ 2608.448234] firewire_ohci: Added fw-ohci device 0000:16:00.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 [ 8822.400218] firewire_ohci: Added fw-ohci device 0000:16:00.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 [ 8922.200234] firewire_ohci: Added fw-ohci device 0000:16:00.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x9 tps@t60:~$ > > Connect the camcorder and watch the kernel log again. > -- /var/log/kern.log after I turn on Panasonic camcorder: Jul 27 07:58:41 t60 kernel: [ 8995.136130] firewire_core: rediscovered device fw0 Jul 27 07:58:41 t60 kernel: [ 8995.136177] firewire_ohci: AT spd 0 tl 0a, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:41 t60 kernel: [ 8995.151698] firewire_ohci: AR spd 0 tl 0a, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:41 t60 kernel: [ 8995.151847] firewire_ohci: AT spd 0 tl 0d, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:44 t60 kernel: [ 8998.152149] firewire_ohci: AT spd 0 tl 0e, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:44 t60 kernel: [ 8998.164990] firewire_ohci: AR spd 0 tl 0e, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:44 t60 kernel: [ 8998.165225] firewire_ohci: AT spd 0 tl 0f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:47 t60 kernel: [ 9001.168151] firewire_ohci: AT spd 0 tl 10, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:47 t60 kernel: [ 9001.185149] firewire_ohci: AR spd 0 tl 10, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:47 t60 kernel: [ 9001.185425] firewire_ohci: AT spd 0 tl 11, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:50 t60 kernel: [ 9004.192315] firewire_ohci: AT spd 0 tl 12, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:50 t60 kernel: [ 9004.211780] firewire_ohci: AR spd 0 tl 12, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:50 t60 kernel: [ 9004.211987] firewire_ohci: AT spd 0 tl 13, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:53 t60 kernel: [ 9007.216120] firewire_ohci: AT spd 0 tl 14, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:53 t60 kernel: [ 9007.225205] firewire_ohci: AR spd 0 tl 14, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:53 t60 kernel: [ 9007.225466] firewire_ohci: AT spd 0 tl 15, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:56 t60 kernel: [ 9010.234925] firewire_ohci: AT spd 0 tl 16, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:56 t60 kernel: [ 9010.251712] firewire_ohci: AR spd 0 tl 16, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:56 t60 kernel: [ 9010.251962] firewire_ohci: AT spd 0 tl 17, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:58:59 t60 kernel: [ 9013.256124] firewire_ohci: AT spd 0 tl 18, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:58:59 t60 kernel: [ 9013.271947] firewire_ohci: AR spd 0 tl 18, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:58:59 t60 kernel: [ 9013.272148] firewire_ohci: AT spd 0 tl 19, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:59:02 t60 kernel: [ 9016.280153] firewire_ohci: AT spd 0 tl 1a, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:59:02 t60 kernel: [ 9016.298665] firewire_ohci: AR spd 0 tl 1a, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:59:02 t60 kernel: [ 9016.298833] firewire_ohci: AT spd 0 tl 1b, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:59:05 t60 kernel: [ 9019.304203] firewire_ohci: AT spd 0 tl 1c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:59:05 t60 kernel: [ 9019.312196] firewire_ohci: AR spd 0 tl 1c, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:59:05 t60 kernel: [ 9019.312460] firewire_ohci: AT spd 0 tl 1d, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:59:08 t60 kernel: [ 9022.320148] firewire_ohci: AT spd 0 tl 1e, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:59:08 t60 kernel: [ 9022.338926] firewire_ohci: AR spd 0 tl 1e, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:59:08 t60 kernel: [ 9022.339157] firewire_ohci: AT spd 0 tl 1f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:59:11 t60 kernel: [ 9025.344126] firewire_ohci: AT spd 0 tl 20, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 27 07:59:11 t60 kernel: [ 9025.359064] firewire_ohci: AR spd 0 tl 20, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 27 07:59:11 t60 kernel: [ 9025.359293] firewire_ohci: AT spd 0 tl 21, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 27 07:59:11 t60 kernel: [ 9025.359307] firewire_core: giving up on config rom for node id ffc0 > Stefan Richter > -=====-==-== -=== ==-=- > http://arcgraph.de/sr/ Venlig hilsen Thomas Seilund Løkketoften 46 2625 Vallensbæk |
From: Stefan R. <st...@s5...> - 2011-07-26 21:57:23
|
On Jul 26 Stefan Richter wrote: > Or maybe the camcorder's physical interface chip is junk and does not > interoperate with the uPD72874's phy. Maybe the following does something, or maybe not: Disconnect camcorder. # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=9 debug=3 Check that the new quirks parameter is active now: # dmesg | grep quirks Connect the camcorder and watch the kernel log again. -- Stefan Richter -=====-==-== -=== ==-=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-07-26 21:45:11
|
On Jul 26 tps wrote: > I can't make my Panasonic AG-EZ30 camera work on my IBM Labtop T60 with > Ubuntu 11.04. Below you see the details. The camera is connected through a > PCMCIA Firewire card. If I plug in another camera, ie. JVC GR-D720E > everything is file. The Panasonic camera works fine on a Mac. [...] > Jul 26 16:52:42 t60 kernel: [ 933.272225] firewire_ohci: AT spd 0 tl 08, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > Jul 26 16:52:42 t60 kernel: [ 933.280913] firewire_ohci: AR spd 0 tl 08, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Here, firewire-core starts to read the Configuration ROM register of the remote node in order to find out what kind of device it is. The camcorder's response means: - The firmware has readied the Configuration ROM, - the first section of it (the so-called bus information block) is 4 quadlets long (as required by the standard), - the first CRC was computed for the next 15 quadlets, - that CRC is 0xb170. That's all nice and well and firewire-core attempts to fetch the next quadlet: > Jul 26 16:52:42 t60 kernel: [ 933.281421] firewire_ohci: AT spd 0 tl 09, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 But the camcorder now responds with "I'm busy, try again later". firewire-core makes a short pause, then starts again at the beginning of the Configuration ROM, gets the very same header quadlet, proceeds o the next quadlet, gets again ack-busy. In total, firewire-core tries this 10 times with plenty of pauses. Yet the camcorder's firmware never shows the next quadlet or more --- even though it allegedly has the entire Configuration ROM ready to be read, and even though there is no third node on the bus trying to get to the Configuration ROM. > Jul 26 16:52:42 t60 kernel: [ 933.281447] firewire_core: giving up on config rom for node id ffc0 So, at some point firewire-core decides that enough is enough. I have no idea why the camcorder refuses to work while it does work on the Mac. Maybe you are using different cables. On the other hand, cable problems typically look at lot different from what you reported. Or maybe the camcorder's physical interface chip is junk and does not interoperate with the uPD72874's phy. Could you try a Linux live CD or Live USB stick on the Mac and see whether it recognizes the camcorder when running on that other hardware? -- Stefan Richter -=====-==-== -=== ==-=- http://arcgraph.de/sr/ |
From: tps <tp...@ne...> - 2011-07-26 15:51:33
|
Dear All, I can't make my Panasonic AG-EZ30 camera work on my IBM Labtop T60 with Ubuntu 11.04. Below you see the details. The camera is connected through a PCMCIA Firewire card. If I plug in another camera, ie. JVC GR-D720E everything is file. The Panasonic camera works fine on a Mac. Any help would be appreciated. Kernel Linux t60 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux Modules tps@t60:~$ lsmod | grep -e 1394 tps@t60:~$ lsmod | grep -e firewire firewire_ohci 31504 0 firewire_core 56138 1 firewire_ohci crc_itu_t 12627 1 firewire_core tps@t60:~$ lspci tps@t60:~$ lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01) 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller 16:00.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01) tps@t60:~$ FireWire peripheral Panasonic AG-EZ30 kern.log Jul 26 16:52:11 t60 kernel: [ 902.071867] firewire_ohci: IRQ 00020010 AR_req busReset Jul 26 16:52:11 t60 kernel: [ 902.071890] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.071898] firewire_ohci: AR evt_bus_reset, generation 9 Jul 26 16:52:11 t60 kernel: [ 902.071912] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.071919] firewire_ohci: AR evt_bus_reset, generation 10 Jul 26 16:52:11 t60 kernel: [ 902.071934] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.071960] firewire_ohci: IRQ 00030000 selfID busReset Jul 26 16:52:11 t60 kernel: [ 902.071980] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.072006] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.072045] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.072053] firewire_ohci: 2 selfIDs, generation 10, local node ID ffc1 Jul 26 16:52:11 t60 kernel: [ 902.072070] firewire_ohci: selfID 0: 807f0882, phy 0 [p..] S100 gc=63 +0W Lci Jul 26 16:52:11 t60 kernel: [ 902.072077] firewire_ohci: selfID 0: 817f8c74, phy 1 [-c-] S400 gc=63 -3W Lc Jul 26 16:52:11 t60 kernel: [ 902.072083] firewire_core: skipped bus generations, destroying all nodes Jul 26 16:52:11 t60 kernel: [ 902.572220] firewire_core: rediscovered device fw0 Jul 26 16:52:11 t60 kernel: [ 902.572265] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:11 t60 kernel: [ 902.572279] firewire_ohci: AT spd 0 tl 1a, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:11 t60 kernel: [ 902.572288] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Jul 26 16:52:11 t60 kernel: [ 902.572318] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:11 t60 kernel: [ 902.572326] firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff Jul 26 16:52:11 t60 kernel: [ 902.572355] firewire_ohci: IRQ 00020010 AR_req busReset Jul 26 16:52:11 t60 kernel: [ 902.572363] firewire_ohci: AR evt_bus_reset, generation 11 Jul 26 16:52:11 t60 kernel: [ 902.572378] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572385] firewire_ohci: AR evt_bus_reset, generation 12 Jul 26 16:52:11 t60 kernel: [ 902.572400] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572421] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572444] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572497] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572521] firewire_ohci: IRQ 00030000 selfID busReset Jul 26 16:52:11 t60 kernel: [ 902.572541] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572567] firewire_ohci: IRQ 00020000 busReset Jul 26 16:52:11 t60 kernel: [ 902.572575] firewire_ohci: 2 selfIDs, generation 12, local node ID ffc1 Jul 26 16:52:11 t60 kernel: [ 902.572592] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc Jul 26 16:52:11 t60 kernel: [ 902.572599] firewire_ohci: selfID 0: 81458c76, phy 1 [-c-] S400 gc=5 -3W Lci Jul 26 16:52:11 t60 kernel: [ 902.572604] firewire_core: skipped bus generations, destroying all nodes Jul 26 16:52:12 t60 kernel: [ 902.672138] firewire_core: giving up on config rom for node id ffc0 Jul 26 16:52:12 t60 kernel: [ 903.072244] firewire_core: rediscovered device fw0 Jul 26 16:52:12 t60 kernel: [ 903.072289] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:12 t60 kernel: [ 903.072302] firewire_ohci: AT spd 0 tl 32, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:12 t60 kernel: [ 903.087289] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:12 t60 kernel: [ 903.087306] firewire_ohci: AR spd 0 tl 32, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:12 t60 kernel: [ 903.087512] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:12 t60 kernel: [ 903.087527] firewire_ohci: AT spd 0 tl 35, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:15 t60 kernel: [ 906.088271] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:15 t60 kernel: [ 906.088288] firewire_ohci: AT spd 0 tl 36, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:15 t60 kernel: [ 906.100273] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:15 t60 kernel: [ 906.100289] firewire_ohci: AR spd 0 tl 36, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:15 t60 kernel: [ 906.100659] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:15 t60 kernel: [ 906.100674] firewire_ohci: AT spd 0 tl 37, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:18 t60 kernel: [ 909.104200] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:18 t60 kernel: [ 909.104216] firewire_ohci: AT spd 0 tl 38, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:18 t60 kernel: [ 909.120533] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:18 t60 kernel: [ 909.120549] firewire_ohci: AR spd 0 tl 38, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:18 t60 kernel: [ 909.120890] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:18 t60 kernel: [ 909.120905] firewire_ohci: AT spd 0 tl 39, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:21 t60 kernel: [ 912.128200] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:21 t60 kernel: [ 912.128216] firewire_ohci: AT spd 0 tl 3a, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:21 t60 kernel: [ 912.147088] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:21 t60 kernel: [ 912.147105] firewire_ohci: AR spd 0 tl 3a, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:21 t60 kernel: [ 912.147335] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:21 t60 kernel: [ 912.147346] firewire_ohci: AT spd 0 tl 3b, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:24 t60 kernel: [ 915.152216] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:24 t60 kernel: [ 915.152232] firewire_ohci: AT spd 0 tl 3c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:24 t60 kernel: [ 915.160481] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:24 t60 kernel: [ 915.160498] firewire_ohci: AR spd 0 tl 3c, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:24 t60 kernel: [ 915.160810] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:24 t60 kernel: [ 915.160821] firewire_ohci: AT spd 0 tl 3d, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:27 t60 kernel: [ 918.168208] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:27 t60 kernel: [ 918.168224] firewire_ohci: AT spd 0 tl 3e, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:27 t60 kernel: [ 918.187368] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:27 t60 kernel: [ 918.187385] firewire_ohci: AR spd 0 tl 3e, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:27 t60 kernel: [ 918.187732] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:27 t60 kernel: [ 918.187747] firewire_ohci: AT spd 0 tl 3f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:30 t60 kernel: [ 921.192216] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:30 t60 kernel: [ 921.192231] firewire_ohci: AT spd 0 tl 00, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:30 t60 kernel: [ 921.207432] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:30 t60 kernel: [ 921.207449] firewire_ohci: AR spd 0 tl 00, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:30 t60 kernel: [ 921.207773] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:30 t60 kernel: [ 921.207788] firewire_ohci: AT spd 0 tl 01, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:33 t60 kernel: [ 924.208223] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:33 t60 kernel: [ 924.208239] firewire_ohci: AT spd 0 tl 02, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:33 t60 kernel: [ 924.220797] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:33 t60 kernel: [ 924.220814] firewire_ohci: AR spd 0 tl 02, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:33 t60 kernel: [ 924.221059] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:33 t60 kernel: [ 924.221074] firewire_ohci: AT spd 0 tl 03, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:36 t60 kernel: [ 927.224253] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:36 t60 kernel: [ 927.224269] firewire_ohci: AT spd 0 tl 04, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:36 t60 kernel: [ 927.240876] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:36 t60 kernel: [ 927.240893] firewire_ohci: AR spd 0 tl 04, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:36 t60 kernel: [ 927.241216] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:36 t60 kernel: [ 927.241232] firewire_ohci: AT spd 0 tl 05, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:39 t60 kernel: [ 930.248194] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:39 t60 kernel: [ 930.248210] firewire_ohci: AT spd 0 tl 06, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:39 t60 kernel: [ 930.267623] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:39 t60 kernel: [ 930.267639] firewire_ohci: AR spd 0 tl 06, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:39 t60 kernel: [ 930.267932] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:39 t60 kernel: [ 930.267947] firewire_ohci: AT spd 0 tl 07, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:42 t60 kernel: [ 933.272209] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:42 t60 kernel: [ 933.272225] firewire_ohci: AT spd 0 tl 08, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jul 26 16:52:42 t60 kernel: [ 933.280896] firewire_ohci: IRQ 00000020 AR_resp Jul 26 16:52:42 t60 kernel: [ 933.280913] firewire_ohci: AR spd 0 tl 08, ffc0 -> ffc1, ack_complete, QR resp = 040fb170 Jul 26 16:52:42 t60 kernel: [ 933.281405] firewire_ohci: IRQ 00000001 AT_req Jul 26 16:52:42 t60 kernel: [ 933.281421] firewire_ohci: AT spd 0 tl 09, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Jul 26 16:52:42 t60 kernel: [ 933.281447] firewire_core: giving up on config rom for node id ffc0 Jul 26 16:52:48 t60 kernel: [ 938.607680] firewire_ohci: IRQ 00200000 cycle64Seconds Thanks Thomas S |
From: Carl K. <ca...@pe...> - 2011-07-20 19:52:43
|
On Wed, Jul 20, 2011 at 2:41 PM, Stefan Richter <st...@s5...> wrote: > On Jul 20 Carl Karsten wrote: >> found it: dvconnect captures raw DV streams from or sends raw DV >> streams to the Linux IEEE 1394 video1394 device. ... channel to send >> / receive on (range: 0 - 63, default = 63). >> >> But: >> >> sudo dvconnect -s -d /dev/fw1 dvgrab-008.dv >> VIDEO1394_TALK_CHANNEL: Invalid argument >> >> sudo dvconnect -s -d /dev/fw0 dvgrab-008.dv >> VIDEO1394_TALK_CHANNEL: Invalid argument > > The video1394 kernel driver has been removed in Linux 2.6.37. > firewire-core's ioctl ABI differs from video1394's. > > Unless you find a DV sender that is solely libraw1394 (plus perhaps > libiec61883) based, you either need to dig out an old kernel, or > forward-port video1394 to your current kernel, or write a > <linux/firewire-cdev.h> based DV sender... Figured as much, thanks for confirming. Not worth putting much effort into, and need it to be used in production in 2 days. I didn't even like how things were going when it seemed like there might be a usable chain. -- Carl K |
From: Stefan R. <st...@s5...> - 2011-07-20 19:41:17
|
On Jul 20 Carl Karsten wrote: > found it: dvconnect captures raw DV streams from or sends raw DV > streams to the Linux IEEE 1394 video1394 device. ... channel to send > / receive on (range: 0 - 63, default = 63). > > But: > > sudo dvconnect -s -d /dev/fw1 dvgrab-008.dv > VIDEO1394_TALK_CHANNEL: Invalid argument > > sudo dvconnect -s -d /dev/fw0 dvgrab-008.dv > VIDEO1394_TALK_CHANNEL: Invalid argument The video1394 kernel driver has been removed in Linux 2.6.37. firewire-core's ioctl ABI differs from video1394's. Unless you find a DV sender that is solely libraw1394 (plus perhaps libiec61883) based, you either need to dig out an old kernel, or forward-port video1394 to your current kernel, or write a <linux/firewire-cdev.h> based DV sender... -- Stefan Richter -=====-==-== -=== =-=-- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-07-20 17:13:17
|
found it: dvconnect captures raw DV streams from or sends raw DV streams to the Linux IEEE 1394 video1394 device. ... channel to send / receive on (range: 0 - 63, default = 63). But: sudo dvconnect -s -d /dev/fw1 dvgrab-008.dv VIDEO1394_TALK_CHANNEL: Invalid argument sudo dvconnect -s -d /dev/fw0 dvgrab-008.dv VIDEO1394_TALK_CHANNEL: Invalid argument On Wed, Jul 20, 2011 at 8:26 AM, Carl Karsten <ca...@pe...> wrote: > I need to send dv from linux to a windows app that expects to see a DV > cam hooked up to its firewire port. > So I am hoping I can make my linux firewire look like a DV cam. > > I thought dvgrab would do this, but now I don't see such in the man page. > > -- > Carl K > -- Carl K |
From: Carl K. <ca...@pe...> - 2011-07-20 13:26:51
|
I need to send dv from linux to a windows app that expects to see a DV cam hooked up to its firewire port. So I am hoping I can make my linux firewire look like a DV cam. I thought dvgrab would do this, but now I don't see such in the man page. -- Carl K |
From: Alan E. <ala...@gm...> - 2011-07-19 17:43:15
|
Final update. I opened a ticket with Hauppauge via email and was told that others have reported problems with the PVR-500 and Sandy Bridge based systems. Its an older card so I am not going to pursue this. I'll probably just upgrade to a dual tuner ATSC/QAM card. Thanks lists for the pointers. -Alan On Tue, Jul 19, 2011 at 12:39 AM, Bjorn Helgaas <bhe...@go...> wrote: > On Mon, Jul 18, 2011 at 9:52 PM, Alan Evans <ala...@gm...> wrote: >> Ok. I've found the culprit but don't understand why. >> >> Working on the theory that the problem was A. virtualization >> technology, B. the 1394 controller or C. my Hauppauge PVR-500 card I >> disabled or removed each one at a time. >> >> After removing the PVR-500 card the firewire controller shows up as one device. >> >> I took lspci -vvv and dmesg output from each of the four scenarios: >> >> 1. Virtualization enabled, PVR card installed and 1394 controller enabled >> 2. Virtualization DISABLED, PVR card installed and 1394 controller enabled >> 3. Virtualization enabled, PVR card installed and 1394 controller DISABLED >> 4. Virtualization enabled, PVR card REMOVED and 1394 controller enabled >> >> Nothing changed until I removed the PVR card. The output of all four >> are quite lengthy. Can I add attachments on this list? > > You could open a bug report at http://bugzilla.kernel.org, attach the > logs there, and reply to this email thread with a pointer to the bug > report. > > Bjorn > |
From: Bjorn H. <bhe...@go...> - 2011-07-19 04:39:37
|
On Mon, Jul 18, 2011 at 9:52 PM, Alan Evans <ala...@gm...> wrote: > Ok. I've found the culprit but don't understand why. > > Working on the theory that the problem was A. virtualization > technology, B. the 1394 controller or C. my Hauppauge PVR-500 card I > disabled or removed each one at a time. > > After removing the PVR-500 card the firewire controller shows up as one device. > > I took lspci -vvv and dmesg output from each of the four scenarios: > > 1. Virtualization enabled, PVR card installed and 1394 controller enabled > 2. Virtualization DISABLED, PVR card installed and 1394 controller enabled > 3. Virtualization enabled, PVR card installed and 1394 controller DISABLED > 4. Virtualization enabled, PVR card REMOVED and 1394 controller enabled > > Nothing changed until I removed the PVR card. The output of all four > are quite lengthy. Can I add attachments on this list? You could open a bug report at http://bugzilla.kernel.org, attach the logs there, and reply to this email thread with a pointer to the bug report. Bjorn |
From: Alan E. <ala...@gm...> - 2011-07-19 03:52:14
|
Ok. I've found the culprit but don't understand why. Working on the theory that the problem was A. virtualization technology, B. the 1394 controller or C. my Hauppauge PVR-500 card I disabled or removed each one at a time. After removing the PVR-500 card the firewire controller shows up as one device. I took lspci -vvv and dmesg output from each of the four scenarios: 1. Virtualization enabled, PVR card installed and 1394 controller enabled 2. Virtualization DISABLED, PVR card installed and 1394 controller enabled 3. Virtualization enabled, PVR card installed and 1394 controller DISABLED 4. Virtualization enabled, PVR card REMOVED and 1394 controller enabled Nothing changed until I removed the PVR card. The output of all four are quite lengthy. Can I add attachments on this list? -Alan On Mon, Jul 18, 2011 at 3:14 AM, Stefan Richter <st...@s5...> wrote: > On Jul 18 Alan Evans wrote to linux1394-user: >> I have never paid much attention to firewire support but now I am >> building a media player and plan to scrape video via firewire so I >> have to pay attention! >> >> Anyway, my motherboard has 2 onboard firewire ports (one on ATX rear >> panel and 1 header which is unconnected) but lspci shows the device 33 >> times! What gives? > > lspci should show only one VT6307 device. The two physical ports are both > attached to a single link layer controller device i.e. FireWire-to-PCI > bridge device. > > I have never heard of such a problem before. It is not a FireWire problem > but a PCI problem. Hence I Cc'd linux-pci. > > VT6307 is a PCI device and is surely located behind a PCIe-to-PCI bridge. > Perhaps that bridge doesn't work right. > > Alan, could you please reply-to-all with the output of "dmesg" attached, > beginning at the boot of the system? > > Maybe a BIOS update can fix it? > >> Secondly I am seeing a bunch of "Failed to reset ohci card" messages >> that coincide with the extra devices. >> >> ...snip... >> [ 37.619910] firewire_ohci 0000:04:12.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 >> [ 38.618540] firewire_ohci: Failed to reset ohci card. >> [ 38.618607] firewire_ohci 0000:04:12.0: PCI INT A disabled >> [ 38.618615] firewire_ohci: probe of 0000:04:12.0 failed with error -16 >> ...snip... > > Well, if the kernel driver core binds firewire-ohci to devices that don't > actually exist, there are bound to be initialization failures. > >> lspci >> ...snip... >> 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> ...omitted for brevity... >> 04:1e.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> 04:1f.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) >> ...snip... >> >> Any thoughts? >> >> Regards, >> -Alan > > I suppose the one VT6307 at bus 03 is for real, and the 32 ones on bus 04 > are ghosts. > -- > Stefan Richter > -=====-==-== -=== =--=- > http://arcgraph.de/sr/ > |