linux1394-user Mailing List for IEEE 1394 for Linux (Page 10)
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: Lluís B. i R. <vi...@vi...> - 2012-05-08 16:31:51
|
On Tue, May 08, 2012 at 06:28:50PM +0200, Lluís Batlle i Rossell wrote: > On Tue, May 08, 2012 at 05:30:34PM +0200, Clemens Ladisch wrote: > > Lluís Batlle i Rossell wrote: > > > SysRq : Show Blocked State > > > task PC stack pid father > > > cc1394 D ffffffff81407520 0 5918 5880 0x00000005 > > > Call Trace: > > > [<ffffffff813c8baf>] schedule+0x3f/0x60 > > > [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] > > (BTW: what is the output of lsfirewirephy?) > > I notice that, let's say, my /usr/include/linux is from 2.6.35, and I've all > built with those headers. Is the public API of the kernel changed at 3.3.x, for > firewire? Should I rebuild all the libdc/libraw code with newer headers? > > Or simply getting the newer firewire-cdev header files would be enough, building > jujuutils with them? > > I'll try this later. Hm this was fast. I have the jujutils built: # lsfirewirephy timeout timeout Does this mean much? Regards, Lluís. |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 16:29:00
|
On Tue, May 08, 2012 at 05:30:34PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > SysRq : Show Blocked State > > task PC stack pid father > > cc1394 D ffffffff81407520 0 5918 5880 0x00000005 > > Call Trace: > > [<ffffffff813c8baf>] schedule+0x3f/0x60 > > [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] > (BTW: what is the output of lsfirewirephy?) I notice that, let's say, my /usr/include/linux is from 2.6.35, and I've all built with those headers. Is the public API of the kernel changed at 3.3.x, for firewire? Should I rebuild all the libdc/libraw code with newer headers? Or simply getting the newer firewire-cdev header files would be enough, building jujuutils with them? I'll try this later. Regards, Lluís. |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 15:34:55
|
On Tue, May 08, 2012 at 05:30:34PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > Please check whether a bus reset helps: download and install the jujuutils > package from <http://code.google.com/p/jujuutils/>, and run: > firewire-request /dev/fw1 reset It does not help... Nothing changes, neither to fw1 or fw0. > (BTW: what is the output of lsfirewirephy?) I only have 'lsfirewire': # lsfirewire -v device fw0: vendor ID: 0xd00d1e model ID: 0x000001 vendor: Linux Firewire model: Juju guid: 0x001e8c0001c08664 device fw1: vendor ID: 0x000a47 guid: 0x000a47010f0a468c units: 0x00a02d:0x000102 unit fw1.0: specifier ID: 0x00a02d version: 0x000102 |
From: Clemens L. <cl...@la...> - 2012-05-08 15:26:41
|
Lluís Batlle i Rossell wrote: > SysRq : Show Blocked State > task PC stack pid father > cc1394 D ffffffff81407520 0 5918 5880 0x00000005 > Call Trace: > [<ffffffff813c8baf>] schedule+0x3f/0x60 > [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] Some command to the device did not get a response; the kernel is still waiting for one. In theory, there should be a two-second timeout; I don't know why is doesn't trigger. Please check whether a bus reset helps: download and install the jujuutils package from <http://code.google.com/p/jujuutils/>, and run: firewire-request /dev/fw1 reset (BTW: what is the output of lsfirewirephy?) Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 15:11:24
|
On Tue, May 08, 2012 at 04:27:20PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > On Tue, May 08, 2012 at 02:00:15PM +0200, Clemens Ladisch wrote: > >> Lluís Batlle i Rossell wrote: > >>> here we have two computers, both with VT6315, running all x86_64, one is an > >>> intel i7 and the other an amd Phenom II. > >>> > >>> The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. > >>> The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. > >>> Then the process hangs too. Killing the process leaves it <defunct> (unrelated > >>> to the parent accepting it or not). > >> > >> Apparently, the driver is waiting for the hardware to do something. > >> > >> When this happens, are there any messages in the system log (see the output of > >> dmesg)? > > > > Nothing there. I only get some lines if I disconnect the camera, but the process > > remains <defunct>. > The FireWire stack was completely rewritten. Check that your libraw1394 package > is recent enough (current is 2.0.8, but 2.0.6 or newer should work). In any > case, this library could not cause the kernel to lock up. I'm using libraw1394 2.0.7. I can try 2.0.8. I will later. The program just blocked (in 3.3.4), and I attach strace: read(13, I look at the fd 13 in /proc: 13 -> /dev/fw1 I use kill. SIGINT causes the read() call to restart: read(13, 0x7fff19de7760, 40) = ? ERESTARTSYS (To be restarted) --- {si_signo=SIGINT, si_code=SI_KERNEL, si_value={int=1174533440, ptr=0x7fbf4601f540}} (Interrupt) --- rt_sigaction(SIGINT, {0x7fe92d954390, [INT], SA_RESTORER|SA_RESTART, 0x7fe92b4e8b10}, {0x7fe92d954390, [INT], SA_RESTORER|SA_RESTART, 0x7fe92b4e8b10}, 8) = 0 rt_sigreturn(0) = 0 read(13, If now with strace attached I use kill -9, strace does not notice that. Ctrl-C to the strace, hangs: read(13, ^C <unfinished ...> cat /proc/5918/status: Name: cc1394 State: D (disk sleep) .... If I hadn't had strace attached, the process would appear defunct - as I tried other times. Unplugging the fw camera does not show any message in dmesg. Now issuing the sysreq w shows one task: [17613.274738] SysRq : Show Blocked State [17613.274749] task PC stack pid father [17613.274790] cc1394 D ffffffff81407520 0 5918 5880 0x00000005 [17613.274801] ffff880032101b68 0000000000000046 ffff880032101b08 ffff880000000000 [17613.274810] ffff8801285ea940 ffff880032101fd8 ffff880032101fd8 ffff880032101fd8 [17613.274819] ffff880129ace040 ffff8801285ea940 ffff880032101b78 ffff8800364a2c00 [17613.274828] Call Trace: [17613.274843] [<ffffffff813c8baf>] schedule+0x3f/0x60 [17613.274882] [<ffffffffa0106fcd>] fw_device_op_release+0x18d/0x250 [firewire_core] [17613.274894] [<ffffffff8106b7c0>] ? add_wait_queue+0x60/0x60 [17613.274904] [<ffffffff8114c6ba>] fput+0xea/0x220 [17613.274912] [<ffffffff81149466>] filp_close+0x66/0x90 [17613.274921] [<ffffffff8104cc88>] put_files_struct+0x88/0xf0 [17613.274930] [<ffffffff8104cd9a>] exit_files+0x4a/0x60 [17613.274938] [<ffffffff8104d277>] do_exit+0x197/0x870 [17613.274946] [<ffffffff8104dcb4>] do_group_exit+0x44/0xa0 [17613.274955] [<ffffffff8105d7c5>] get_signal_to_deliver+0x215/0x5e0 [17613.274964] [<ffffffff810131b5>] do_signal+0x65/0x710 [17613.274972] [<ffffffff8104dfbb>] ? sys_wait4+0xab/0xf0 [17613.274979] [<ffffffff8106b7c0>] ? add_wait_queue+0x60/0x60 [17613.274987] [<ffffffff810138e5>] do_notify_resume+0x65/0x80 [17613.274996] [<ffffffff813ca7a2>] int_signal+0x12/0x17 Does it tell enough to you? Any other test? Regards, Lluís. |
From: Clemens L. <cl...@la...> - 2012-05-08 14:23:27
|
Lluís Batlle i Rossell wrote: > On Tue, May 08, 2012 at 02:00:15PM +0200, Clemens Ladisch wrote: >> Lluís Batlle i Rossell wrote: >>> here we have two computers, both with VT6315, running all x86_64, one is an >>> intel i7 and the other an amd Phenom II. >>> >>> The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. >>> The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. >>> Then the process hangs too. Killing the process leaves it <defunct> (unrelated >>> to the parent accepting it or not). >> >> Apparently, the driver is waiting for the hardware to do something. >> >> When this happens, are there any messages in the system log (see the output of >> dmesg)? > > Nothing there. I only get some lines if I disconnect the camera, but the process > remains <defunct>. Try executing (as root) echo w > /proc/sysrq-trigger when this happens; this should output a list of blocked tasks to the system log. > Another thing I could not find anywhere is that in the 2.6.35 computer, I get > /dev/raw1394 and /dev/video1394-0. In the 3.3.x computer, I don't get any such > device node, and I don't have any modules named raw1394 or video1394. The FireWire stack was completely rewritten. Check that your libraw1394 package is recent enough (current is 2.0.8, but 2.0.6 or newer should work). In any case, this library could not cause the kernel to lock up. Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 13:42:11
|
On Tue, May 08, 2012 at 02:00:15PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > here we have two computers, both with VT6315, running all x86_64, one is an > > intel i7 and the other an amd Phenom II. > > > > The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. > > The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. > > Then the process hangs too. Killing the process leaves it <defunct> (unrelated > > to the parent accepting it or not). > > Apparently, the driver is waiting for the hardware to do something. > > When this happens, are there any messages in the system log (see the output of > dmesg)? Another thing I could not find anywhere is that in the 2.6.35 computer, I get /dev/raw1394 and /dev/video1394-0. In the 3.3.x computer, I don't get any such device node, and I don't have any modules named raw1394 or video1394. Did those device nodes disappeared in recent kernels? Regards, Lluís. |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 13:21:13
|
On Tue, May 08, 2012 at 02:00:15PM +0200, Clemens Ladisch wrote: > Lluís Batlle i Rossell wrote: > > here we have two computers, both with VT6315, running all x86_64, one is an > > intel i7 and the other an amd Phenom II. > > > > The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. > > The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. > > Then the process hangs too. Killing the process leaves it <defunct> (unrelated > > to the parent accepting it or not). > > Apparently, the driver is waiting for the hardware to do something. > > When this happens, are there any messages in the system log (see the output of > dmesg)? Nothing there. I only get some lines if I disconnect the camera, but the process remains <defunct>. I'll try to switch kernels some time soon. |
From: Clemens L. <cl...@la...> - 2012-05-08 11:56:27
|
Lluís Batlle i Rossell wrote: > here we have two computers, both with VT6315, running all x86_64, one is an > intel i7 and the other an amd Phenom II. > > The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. > The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. > Then the process hangs too. Killing the process leaves it <defunct> (unrelated > to the parent accepting it or not). Apparently, the driver is waiting for the hardware to do something. When this happens, are there any messages in the system log (see the output of dmesg)? Regards, Clemens |
From: Lluís B. i R. <vi...@vi...> - 2012-05-08 11:17:37
|
Hello, here we have two computers, both with VT6315, running all x86_64, one is an intel i7 and the other an amd Phenom II. The I7 runs 2.6.35 and dc1394 cameras work perfectly in it. The Phenom II runs 3.3.4 and dc1394 cameras work for a short seconds, and hang. Then the process hangs too. Killing the process leaves it <defunct> (unrelated to the parent accepting it or not). Using the same userland software in both computers. I can't test 3.3.4 on the I7 easily, but I imagine something could have got broken for the VT6315 since 2.6.35. Can anyone confirm that VT6315 works in 3.3.x kernels? Regards, Lluís. |
From: Stefan R. <st...@s5...> - 2012-05-02 21:02:23
|
Hi all, today, editing functionality of the wikis at kernel.org has been restored. I will slowly update the ieee1394.wiki with current release notes, to-do items etc. but everyone else is of course welcome to do so as well. -- Stefan Richter -=====-===-- -=-= ---=- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2012-04-25 14:15:17
|
On Wed, Apr 25, 2012 at 7:59 AM, Stefan Richter <st...@s5...> wrote: > Wouldn't the two DV devices be able to work simultaneously on the same > bus? You would of course have to configure them to transmit on separate > channels. Haven't tried that myself yet with my three DV specimen > (consumer grade camcorders), and don't know what the chances are to get > this working with random devices. > Someone I trust, likely Dan Dennedy, said "it could work, but in practice it doesn't." I think the problem is the device (camera) doesn't have the inelegance to negotiate using a different port. I also hear someone has been successful using dvgrab by specifying the device guid, but I never got any details on what device or card. I have tried it in the past, the results were confusing. I quickly decided it wasn't worth messing with. I'll be happy to setup a box with a few cards and devices plugged in if someone wants to feed me some tests. Or send me a public key and I'll give you root. -- Carl K |
From: Stefan R. <st...@s5...> - 2012-04-25 13:00:05
|
On Apr 25 Clemens Ladisch wrote: > Carl Karsten wrote: > > I need to buy 20 or so PCIe firewire 400 cards. (10 machines, 2 cards > > each, or 1 card with 2 bus/chips - I need to plug in 2 dv video > > devices) Wouldn't the two DV devices be able to work simultaneously on the same bus? You would of course have to configure them to transmit on separate channels. Haven't tried that myself yet with my three DV specimen (consumer grade camcorders), and don't know what the chances are to get this working with random devices. AFAIU, bus bandwidth is enough for two S100 DV streams. Perhaps three if you cheat and cut into the 1/5 of total bandwidth which are reserved for asynchronous transfers. > http://subversion.ffado.org/wiki/HostControllers#Recommendations > (Those are chips, not cards.) > > As far as I know, only IOI and Unibrain make dual-controller cards. Point Grey offer a dual S800 card too. > The only S400 cards with multiple controllers, the FWX3-PCIE1XE120/-3, > have three chips and are not widely available, so two cards might be > cheaper overall. There are also PCIe cards with 2x TSB43AB22A available, made by IOI. And indeed, two 1x cards are cheaper in retail than one 2x card. > Avoid cards with a PCI controller behind a PCIe/PCI bridge (cards with > two visible chips). This also applies to the TI XIO2200A, which has > a built-in PCIe/PCI bridge which is so slow and buggy that TI has > discontinued this chip. Those were very commonly used on 1394A PCIe cards though, and apparently still are. I have one XIO2200A based card which seemed to work OK overall when I tried it briefly. I didn't stress it much though, and now the slot is occupied by a different card. -- Stefan Richter -=====-===-- -=-- ==--= http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-04-25 08:14:26
|
Carl Karsten wrote: > I need to buy 20 or so PCIe firewire 400 cards. (10 machines, 2 cards > each, or 1 card with 2 bus/chips - I need to plug in 2 dv video > devices) http://subversion.ffado.org/wiki/HostControllers#Recommendations (Those are chips, not cards.) As far as I know, only IOI and Unibrain make dual-controller cards. The only S400 cards with multiple controllers, the FWX3-PCIE1XE120/-3, have three chips and are not widely available, so two cards might be cheaper overall. > Has anyone shopped around recently? Yes, in Germany. :) Which retailers would you consider? > Are there any I should avoid? The most problematic controllers aren't typically used on extension cards. Avoid cards with a PCI controller behind a PCIe/PCI bridge (cards with two visible chips). This also applies to the TI XIO2200A, which has a built-in PCIe/PCI bridge which is so slow and buggy that TI has discontinued this chip. Regards, Clemens |
From: Carl K. <ca...@pe...> - 2012-04-24 19:51:19
|
I need to buy 20 or so PCIe firewire 400 cards. (10 machines, 2 cards each, or 1 card with 2 bus/chips - I need to plug in 2 dv video devices) Has anyone shopped around recently? Are there any I should avoid? -- Carl K |
From: Stefan R. <st...@s5...> - 2012-04-11 12:02:35
|
> On Wednesday 22 February 2012 19:11:36 Stefan Richter wrote: > > On Feb 22 Peter Christy wrote: > > > Can I leave it to you good folks to pursue? I'm quite happy to try > > > out potential fixes to see if they work. > > > > Sure, I will come up with something when time permits and keep you > > Cc'ed in case that tests with your disk are required or if upstream > > people ask for more information or a different approach. Sorry that I haven't followed up upon this yet, will do so at some point... -- Stefan Richter -=====-===-- -=-- -=-== http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-04-06 21:30:19
|
Chris Wj wrote: > I'm looking to be notified of data on 2 separate channels using 2 file > descriptors and read their data separately. I'd like to have one event > loop that reads both descriptors but I have had trouble with select(). > It looked like select() would only detect data on the first ISO > channel's file descriptor. But events are actually available on the second one? This sounds like a bug somewhere. Could you show the code? > Can I set the second file descriptor options to non-blocking Yes. This might be a good idea in any case so that in case of a logic error, you can detect this immediately when you get -EAGAIN instead of having the select call hang. > is there a better way to poll the two descriptors? poll(), but it won't behave differently. Regards, Clemens |
From: Chris Wj <chr...@gm...> - 2012-04-06 20:15:21
|
Hi all. I am currently having a problem with multiple file descriptors and ISO receive contexts. I'm looking to be notified of data on 2 separate channels using 2 file descriptors and read their data separately. I'd like to have one event loop that reads both descriptors but I have had trouble with select(). It looked like select() would only detect data on the first ISO channel's file descriptor. I could use the notification on the first to read from both but I don't like the possibility that my second read could block. Is this normal operation? Can I set the second file descriptor options to non-blocking or is there a better way to poll the two descriptors? Also, we got our hands on PointGrey Firewire cards so we don't have the problems you mentioned concerning the TI chips. -Chris |
From: Clemens L. <cl...@la...> - 2012-03-31 13:00:27
|
Stefan Richter wrote: > From what I have heard, TSB82AA2 is useless for high-bandwidth video. ISO receive FIFO size (if the datasheets can be trusted): TSB82AA: 2 KB FW643E: 8 KB However, the controller begins writing the data to memory as soon as the first byte has been recveived; this is not a limit on the packet size but just a means to handle delays on the PCI and memory buses. > Hence be prepared to have to look for an Agere FW643E(2) based card. It would also be possible to use multiple controllers, so that each channel's packets can occpuy an entire FIFO. (There are adapters with two or three controller chips on one card.) However, it's likely that one good controller is enough for you. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2012-03-31 12:42:52
|
Stefan Richter wrote: > On Mar 30 Clemens Ladisch wrote: >> Chris Wj wrote: >>> Do you have any pointers to some example code that I can study? >> >> Attached. > > That was quick. Yeah, I quickly jumped into my time machine to write a test program months ago. ;-) > Furthermore, besides the inline documentation in > include/linux/firewire-cdev.h, there is a brief overview in > Documentation/ABI/stable/firewire-cdev. And you're one of the first people to use that documentation without knowing the source code by heart, so if anything is unclear, feel free to vent^Wprovide constructive criticism here. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2012-03-31 11:37:03
|
On Mar 30 Chris Wj wrote: > On Thu, Mar 29, 2012 at 7:50 PM, Stefan Richter > <st...@s5...>wrote: > > This should indeed work. IIRC there are libdc1394 users who do actually > > capture video streams with packets larger than 4 kiB. > > > > So our software supports that, but be warned that Texas Instruments > > controllers will not work for you. They have a too small isochronous > > reception FIFO and will inevitably give you corruption due to dropped (or > > maybe incomplete?) packets. > > > Oh man... I just went back and checked and my host controller has the Texas > Instruments TSB82AA2 chip! It is the Data Optic 1394b PCI Express > Controller. Do you foresee me having to get a new controller? How big of an > issue do you think this will be for me? From what I have heard, TSB82AA2 is useless for high-bandwidth video. Of course, isochronous transmissions are about guaranteed data rate and limited latency but without delivery guarantee in the first place (in contrast to asynchronous transactions with guaranteed delivery but no bandwidth guarantee and (almost) unlimited latency). Though video folks appreciate it if delivery failures occur rarely or not at all. But with TSB82AA2, large 1394b isochronous packets reportedly result in corruptions of practically every video frame, IIRC. Extrapolating from those reports to the application that you described, I suspect that you would get corruptions to an intolerable extent too. Hence be prepared to have to look for an Agere FW643E(2) based card. IOI, Point Grey Research, Unibrain and maybe others offer such cards. -- Stefan Richter -=====-===-- --== ===== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-03-31 11:16:06
|
On Mar 30 Clemens Ladisch wrote: > Chris Wj wrote: > > Do you have any pointers to some example code that I can study? > > Attached. That was quick. --- Chris, currently I am aware of the following five /dev/fw* ABI users: libraw1394 https://git.kernel.org/?p=libs/ieee1394/libraw1394.git libdc1394 http://libdc1394.git.sourceforge.net/git/gitweb-index.cgi jujuutils https://code.google.com/p/jujuutils/source/browse/ fwhack http://people.redhat.com/fenlason/fwhack.tar.gz some small tests https://user.in-berlin.de/~s5r6/linux1394/utils/ Furthermore, besides the inline documentation in include/linux/firewire-cdev.h, there is a brief overview in Documentation/ABI/stable/firewire-cdev. https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/ABI/stable/firewire-cdev -- Stefan Richter -=====-===-- --== ===== http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2012-03-30 19:41:21
|
Chris Wj wrote: > Do you have any pointers to some example code that I can study? Attached. Regards, Clemens |
From: Chris Wj <chr...@gm...> - 2012-03-30 18:10:35
|
On Thu, Mar 29, 2012 at 7:50 PM, Stefan Richter <st...@s5...>wrote: > On Mar 29 Chris Wj wrote: > > With the new firewire-core (Juju) modules, I am no longer limited by the > > system's pagesize, correct? I am expecting S800 8K packets and the page > > size of the x86_64 system is set to 4K. > > This should indeed work. IIRC there are libdc1394 users who do actually > capture video streams with packets larger than 4 kiB. > > So our software supports that, but be warned that Texas Instruments > controllers will not work for you. They have a too small isochronous > reception FIFO and will inevitably give you corruption due to dropped (or > maybe incomplete?) packets. > > Oh man... I just went back and checked and my host controller has the Texas Instruments TSB82AA2 chip! It is the Data Optic 1394b PCI Express Controller. Do you foresee me having to get a new controller? How big of an issue do you think this will be for me? > You are going to need Agere FW643E or FW643E2 controllers for this; they > have suitably large FIFOs. > |
From: Clemens L. <cl...@la...> - 2012-03-30 17:52:47
|
Chris Wj wrote: > On Fri, Mar 30, 2012 at 3:09 AM, Clemens Ladisch <cl...@la... <mailto:cl...@la...>> wrote: > Well, there is the slight problem that the Juju IR buffer-fill code has > the same problem that the old AR code had, i.e., if a packet has been > split over three or more descriptors, the controller is not required to > update the middle descriptor(s), so the descriptor parsing loop just > stops. This might be easier to trigger because applications can submit > buffers smaller than a page. > > Is this problem applicable only to multi-channel receive mode? Yes, normal reception with one channel per context works fine. Regards, Clemens |