1394-based DC Control Library ()

Samuel Audet | 7 Aug 2009 12:44

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> Samuel Audet wrote:
>> The strange thing is, everything works just great under Windows XP (32 
>> bit mind you, so < 4 gig of RAM there) with PGR FlyCapture... ?
> 
> On the very same PC?

Yes, dual boot

> You could boot Linux with mem=2G added to the kernel command line (added 
> to the bootloader config, or entered at the boot prompt) and see what 
> happens.

Didn't change anything, didn't fix it

> Besides that, if you know how to compile kernels, you could edit 
> drivers/firewire/fw-ohci.c in function pci_probe:  Replace
> 	ohci->use_dualbuffer = version >= OHCI_VERSION_1_1;
> by
> 	ohci->use_dualbuffer = false;
> rebuild, install, and test.
> http://fedoraproject.org/wiki/Building_a_custom_kernel

(Aaarg, it's such a pain to recompile the kernel just for one module.. 
there should be an easier way to compile _one_ tiny little module)

But I managed it, finally :) And that _does_ fix the problem :) thanks!

What's that dualbuffer all about anyway? It's only used and useful in 
64-bit mode I guess?

(Continue reading)

Stefan Richter | 7 Aug 2009 14:17

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Stefan Richter wrote:
>> Samuel Audet wrote:
>>> The strange thing is, everything works just great under Windows XP (32 
>>> bit mind you, so < 4 gig of RAM there) with PGR FlyCapture... ?
>> On the very same PC?
> 
> Yes, dual boot
> 
>> You could boot Linux with mem=2G added to the kernel command line (added 
>> to the bootloader config, or entered at the boot prompt) and see what 
>> happens.
> 
> Didn't change anything, didn't fix it
> 
>> Besides that, if you know how to compile kernels, you could edit 
>> drivers/firewire/fw-ohci.c in function pci_probe:  Replace
>> 	ohci->use_dualbuffer = version >= OHCI_VERSION_1_1;
>> by
>> 	ohci->use_dualbuffer = false;
>> rebuild, install, and test.
>> http://fedoraproject.org/wiki/Building_a_custom_kernel
> 
> (Aaarg, it's such a pain to recompile the kernel just for one module.. 
> there should be an easier way to compile _one_ tiny little module)
> 
> But I managed it, finally :) And that _does_ fix the problem :) thanks!

Then we apparently need to add a quirk fix for this controller.

(Continue reading)

Samuel Audet | 7 Aug 2009 14:31

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> Then we apparently need to add a quirk fix for this controller.
> 
> Let's recapitulate:
>    - You don't need a modification in the driver source for FW323.
>    - You do need to force ohci->use_dualbuffer = false for FW643.
> Correct?

Correct

(But the FW323 has no dual buffer mode, it isn't OHCI 1.0, is that right?)

> How are these two controllers shown by "lspci -nn"?

03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems FW643 PCI 
Express1394b Controller (PHY/Link) [11c1:5901] (rev 06)
04:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems FW323 [11c1:5811] 
(rev 61)

Let me know if you need more details!

> The #if !defined(CONFIG_X86_32)... #endif is only a micro-optimization 
> for one of the platforms which is known to not use physical addresses 
> bigger than 2 GB for kernel-internal buffer allocations.  (There are 
> more of such platforms, notably PPC-32, but I didn't add those to this 
> micro-optimization because there was a vague possibility that the 
> architecture maintainers might change PPC-32 platform behavior in this 
> regard.)  Anyway, in your case it's according to your findings not tied 
> to buffers in the range of >2 GB... <= 4 GB (they can't be beyond 4 GB 
> because plain PCI uses only 32 bit addressing) but a general problem of

(Continue reading)

Stefan Richter | 7 Aug 2009 15:45

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Stefan Richter wrote:
>> Then we apparently need to add a quirk fix for this controller.
>>
>> Let's recapitulate:
>>    - You don't need a modification in the driver source for FW323.
>>    - You do need to force ohci->use_dualbuffer = false for FW643.
>> Correct?
> 
> Correct
> 
> (But the FW323 has no dual buffer mode, it isn't OHCI 1.0, is that right?)

Well, yes and no...

The FW323 v5 datasheet claims OHCI 1.1 conformance in the overview but 
its register definitions are actually plain OHCI 1.0.

The FW323 v6 product brief states that the chip can be programmed into 
OHCI 1.1 mode or OHCI 1.0 mode by means of the card's serial EEPROM.
Same says the FW643 product brief.

Many Apple computers contain FW323; Apple happens to program them into 
OHCI 1.0 mode for whatever reason.  Perhaps for no particular reason at all.

You can check it in firewire-ohci's initialization message in dmesg. If 
these messages are already out of dmesg, you can find them in 
/var/log/messages or simply by
# modprobe -r firewire-ohci
# modprobe firewire-ohci

(Continue reading)

Samuel Audet | 10 Aug 2009 11:25

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> The FW323 v5 datasheet claims OHCI 1.1 conformance in the overview but 
> its register definitions are actually plain OHCI 1.0.
> 
> The FW323 v6 product brief states that the chip can be programmed into 
> OHCI 1.1 mode or OHCI 1.0 mode by means of the card's serial EEPROM.
> Same says the FW643 product brief.
> 
> Many Apple computers contain FW323; Apple happens to program them into 
> OHCI 1.0 mode for whatever reason.  Perhaps for no particular reason at all.
> 
> You can check it in firewire-ohci's initialization message in dmesg. If 
> these messages are already out of dmesg, you can find them in 
> /var/log/messages or simply by
> # modprobe -r firewire-ohci
> # modprobe firewire-ohci
> # dmesg | tail

The FW323 is loading as OHCI 1.0..

> I'll have you try a simple patch with quirk fix later.  Or you could 
> write one if you like.  I'm not sure though whether we should disable 
> dual buffer for Agere FW643, disable dual buffer for Agere FWxxx, remove 
> dual buffer mode entirely.

Given that Apple, Microsoft, PGR.. and others ? do not even use dual 
buffer mode by default, I think Linux should follow suit, as it was the 
case with the old Firewire drivers as well IIRC.. ?

But, the driver could automatically white list known working controllers

(Continue reading)

Stefan Richter | 10 Aug 2009 20:12

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> The FW323 is loading as OHCI 1.0..

OK, therefore this one is in programmed in packet-per-buffer mode from 
the outset (which works also on FW643 with the driver forced to ignore 
OHCI 1.1 capability of FW643).

One more thing which is not fully clear to me, even after skimming back 
through the whole thread:  You only got the issue with FW643 ("issue" == 
reception stops after an arbitrary amount of data was received) if you 
receive streams from _two_ cameras --- but it does work OK if you 
receive only from a single camera, right?

And libdc1394 or your app took care that the two cameras are told to 
stream to two separate iso channel numbers, yes?

> Given that Apple, Microsoft, PGR.. and others ? do not even use dual 
> buffer mode by default, I think Linux should follow suit, as it was the 
> case with the old Firewire drivers as well IIRC.. ?
> 
> But, the driver could automatically white list known working controllers 
> like the TSB82AA2 you have, and we could provide a module parameter so 
> that users may easily enable dual buffers on load, if they feel 
> adventurous.. What do you think?

According to comments by David and Kristian in 
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13393, 
dual-buffer does not offer any advantage over packet-per-buffer 
regarding CPU usage and binary interface between kernel and userspace 
--- in case of IIDC and other stream formats whose packet sizes are

(Continue reading)

Stefan Richter | 19 Aug 2009 21:15

Picon

Re: [libdc] multiple cameras and juju

Samuel,

could you test whether the following patch works?

This approach keeps the door open to use at least one of the 8 IR DMA
contexts of FW643 in the more featureful dual-buffer mode.  If a second
(3rd, ...) stream is started, then only these subsequent streams will be
forced to packet-per-buffer mode.
---
 drivers/firewire/fw-ohci.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

Index: linux-2.6.30.5/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.30.5.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.30.5/drivers/firewire/fw-ohci.c
 <at>  <at>  -29,6 +29,7  <at>  <at> 
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/pci.h>
+#include <linux/pci_ids.h>
 #include <linux/spinlock.h>

 #include <asm/page.h>
 <at>  <at>  -181,6 +182,7  <at>  <at>  struct fw_ohci {
 	u32 bus_seconds;

 	bool use_dualbuffer;
+	bool single_dualbuffer;
 	bool old_uninorth;

(Continue reading)

Samuel Audet | 28 Aug 2009 09:07

Picon

Re: [libdc] multiple cameras and juju

Hello,

Thanks for the patch! Sorry about the delay... I had to find the courage 
and take the time to get 2.6.30 to compile on Fedora 10 :) Actually, the 
current test package for Fedora 11 builds in Fedora 10 now, ya! nice 
surprise

But no, sorry it does not work :( It works fine with one camera, but 
with two cameras, it stalls after a few frames and I get the same 
dreaded message from the kernel:
	firewire_ohci: Error: DMA context still active (0x48000671)

Samuel

Stefan Richter wrote:
> could you test whether the following patch works?
> 
> This approach keeps the door open to use at least one of the 8 IR DMA
> contexts of FW643 in the more featureful dual-buffer mode.  If a second
> (3rd, ...) stream is started, then only these subsequent streams will be
> forced to packet-per-buffer mode.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Stefan Richter | 28 Aug 2009 09:31

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Thanks for the patch! Sorry about the delay... I had to find the courage 
> and take the time to get 2.6.30 to compile on Fedora 10 :) Actually, the 
> current test package for Fedora 11 builds in Fedora 10 now, ya! nice 
> surprise

Thanks for taking the time.

> But no, sorry it does not work :( It works fine with one camera, but 
> with two cameras, it stalls after a few frames and I get the same 
> dreaded message from the kernel:
>     firewire_ohci: Error: DMA context still active (0x48000671)

So even a parallel running packet-per-buffer DMA causes a dual-buffer 
DMA context to lock up.  I'll post a patch to linux1394-devel to disable 
dual-buffer on FW643 entirely.
--

-- 
Stefan Richter
-=====-==--= =--- ===--
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Jonathan Cameron | 1 Sep 2009 13:33

Picon

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> Samuel Audet wrote:
>> Thanks for the patch! Sorry about the delay... I had to find the courage 
>> and take the time to get 2.6.30 to compile on Fedora 10 :) Actually, the 
>> current test package for Fedora 11 builds in Fedora 10 now, ya! nice 
>> surprise
> 
> Thanks for taking the time.
> 
>> But no, sorry it does not work :( It works fine with one camera, but 
>> with two cameras, it stalls after a few frames and I get the same 
>> dreaded message from the kernel:
>>     firewire_ohci: Error: DMA context still active (0x48000671)
> 
> So even a parallel running packet-per-buffer DMA causes a dual-buffer 
> DMA context to lock up.  I'll post a patch to linux1394-devel to disable 
> dual-buffer on FW643 entirely.

Just for reference, this may not effect all versions of the fw643 out there.
(lspci gives me)
03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems Device [11c1:5901] (rev 06)
(which certainly has the correct id to be a fw643)

Works fine with 2 cameras in dual buffered mode on my machine (8GB). I haven't
seen the reported behavior.   Perhaps we are dealing with different firmware
versions or some other odd quirk.

---
Jonathan Cameron

(Continue reading)

Samuel Audet | 1 Sep 2009 15:02

Picon

Re: [libdc] multiple cameras and juju

Jonathan Cameron wrote:
> Just for reference, this may not effect all versions of the fw643 out there.
> (lspci gives me)
> 03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems Device [11c1:5901] (rev 06)
> (which certainly has the correct id to be a fw643)
> 
> Works fine with 2 cameras in dual buffered mode on my machine (8GB). I haven't
> seen the reported behavior.   Perhaps we are dealing with different firmware
> versions or some other odd quirk.

Or maybe it depends on the kind of cameras... that would be a quirk.. 
would be very strange that a card sold by PGR does not work well only 
with PGR cameras, but stranger things have happened. In any case, if 
it's not disabled by default, then a module parameter would be needed.

(BTW, Stefan, I will test the patch you sent the list tomorrow just to 
make sure it works for me)

Samuel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Stefan Richter | 4 Sep 2009 10:13

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Jonathan Cameron wrote:
>> Just for reference, this may not effect all versions of the fw643 out there.
>> (lspci gives me)
>> 03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems Device [11c1:5901] (rev 06)
>> (which certainly has the correct id to be a fw643)
>>
>> Works fine with 2 cameras in dual buffered mode on my machine (8GB). I haven't
>> seen the reported behavior.   Perhaps we are dealing with different firmware
>> versions or some other odd quirk.
> 
> Or maybe it depends on the kind of cameras...

Or different video formats, notably different frame sizes, hence 
different packet sizes?  Samuel, which formats (or rather: packet sizes) 
do you know were affected?
--

-- 
Stefan Richter
-=====-==--= =--= --=--
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Samuel Audet | 15 Sep 2009 11:44

Picon

Re: [libdc] multiple cameras and juju

Hello,

Sorry about the delay. Well, I tested mostly with 
DC1394_VIDEO_MODE_640x480_MONO8 and DC1394_FRAMERATE_30... So what kind 
of packet size would that be?

I've just tested using custom packet sizes via Format 7.. With two 
cameras and packet sizes of up to 172 bytes, it seems to work fine, but 
at 176 bytes and over it freezes for sure. Small packets work, but vewy 
vewy small packets indeed..

Samuel

Stefan Richter wrote:
> Or different video formats, notably different frame sizes, hence 
> different packet sizes?  Samuel, which formats (or rather: packet sizes) 
> do you know were affected?

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf

Stefan Richter | 1 Sep 2009 17:21

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Jonathan Cameron wrote:
>> Works fine with 2 cameras in dual buffered mode on my machine (8GB). I haven't
>> seen the reported behavior.   Perhaps we are dealing with different firmware
>> versions or some other odd quirk.
> 
> Or maybe it depends on the kind of cameras... that would be a quirk..

Yes, could be.

> would be very strange that a card sold by PGR does not work well only 
> with PGR cameras, but stranger things have happened.

> In any case, if 
> it's not disabled by default, then a module parameter would be needed.

Module parameters should only be the very last resort, i.e. if a fix 
that's necessary in system A would cause a regression in system B, and 
we had no other way to fix system A.

> (BTW, Stefan, I will test the patch you sent the list tomorrow just to 
> make sure it works for me)

That would be appreciated.  Note that if you are using kernel 2.6.30 or 
2.6.29 (and this kernel doesn't contain firewire driver sources 
backported from 2.6.31), then you need to edit the filenames in the 
patch to apply to fw-ohci.c instead of ohci.c.  (Source files have been 
renamed in 2.6.31-rc1.)
--

-- 
Stefan Richter

(Continue reading)

Samuel Audet | 2 Sep 2009 14:24

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> Module parameters should only be the very last resort, i.e. if a fix 
> that's necessary in system A would cause a regression in system B, and 
> we had no other way to fix system A.

Ah, well I guess if nobody on Mac OS X and Windows is using dual buffer 
mode anyway, we're probably not missing much either..

>> (BTW, Stefan, I will test the patch you sent the list tomorrow just to 
>> make sure it works for me)
> 
> That would be appreciated.  Note that if you are using kernel 2.6.30 or 
> 2.6.29 (and this kernel doesn't contain firewire driver sources 
> backported from 2.6.31), then you need to edit the filenames in the 
> patch to apply to fw-ohci.c instead of ohci.c.  (Source files have been 
> renamed in 2.6.31-rc1.)

Just finished testing it. Works fine! (with kernel-2.6.30.5-32 from 
Fedora to be precise..) thanks again!

Samuel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Stefan Richter | 2 Sep 2009 15:49

Picon

Re: [libdc] multiple cameras and juju

Samuel Audet wrote:
> Stefan Richter wrote:
>> Module parameters should only be the very last resort, i.e. if a fix 
>> that's necessary in system A would cause a regression in system B, and 
>> we had no other way to fix system A.
> 
> Ah, well I guess if nobody on Mac OS X and Windows is using dual buffer 
> mode anyway, we're probably not missing much either..

Right, libdc1394 or any other IIDC related user of the 
<linux/firewire-cdev.h> ABI are not missing anything, feature- or 
performance-wise.  (IEC 61883 a.k.a. AV/C based stream formats and 
similar ones still worry me though.)

>>> (BTW, Stefan, I will test the patch you sent the list tomorrow just 
>>> to make sure it works for me)
[...]
> Just finished testing it. Works fine! (with kernel-2.6.30.5-32 from 
> Fedora to be precise..) thanks again!

Well, thank you for your time spent on the reports and tests.

Since the release of mainline kernel 2.6.31 is imminent, I will probably 
get the fix into the mainline after 2.6.31 + before 2.6.32-rc1 and into 
then current 2.6.3[01].? releases.  The Fedora kernel maintainers tend 
to pick such fixes up rather soon as well.
--

-- 
Stefan Richter
-=====-==--= =--= ---=-
http://arcgraph.de/sr/

(Continue reading)

Stefan Richter | 1 Sep 2009 13:48

Picon

Re: [libdc] multiple cameras and juju

Jonathan Cameron wrote:
> Just for reference, this may not effect all versions of the fw643 out there.
> (lspci gives me)
> 03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems Device [11c1:5901] (rev 06)
> (which certainly has the correct id to be a fw643)
> 
> Works fine with 2 cameras in dual buffered mode on my machine (8GB). I haven't
> seen the reported behavior.   Perhaps we are dealing with different firmware
> versions or some other odd quirk.

We could apply the workaround selectively based on dev->revision *if* 
affected and unaffected chips had different Revision ID register 
contents and we knew which revisions were affected...
--

-- 
Stefan Richter
-=====-==--= =--= ----=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Samuel Audet | 11 Aug 2009 08:12

Picon

Re: [libdc] multiple cameras and juju

Stefan Richter wrote:
> OK, therefore this one is in programmed in packet-per-buffer mode from 
> the outset (which works also on FW643 with the driver forced to ignore 
> OHCI 1.1 capability of FW643).

Seems that way..

> One more thing which is not fully clear to me, even after skimming back 
> through the whole thread:  You only got the issue with FW643 ("issue" == 
> reception stops after an arbitrary amount of data was received) if you 
> receive streams from _two_ cameras --- but it does work OK if you 
> receive only from a single camera, right?

Yes, that's right

> And libdc1394 or your app took care that the two cameras are told to 
> stream to two separate iso channel numbers, yes?

I'm running this on < 2.6.30 and I get messages like
libdc1394 warning: iso allocation not available in this kernel, using 
channel 0.
libdc1394 warning: iso allocation not available in this kernel, using 
channel 1.

So I guess so... on 2.6.30, the behavior is not different.

> So if we dealt only with those streams, we could delete the dual-buffer 
> code from the driver for sake of smaller kernel footprint and 
> maintainability, and don't worry about blacklisting or whitelisting or a 
> module parameter anymore.

(Continue reading)

Return

Return to gmane.comp.multimedia.libdc1394.devel.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane