Welcome, Guest! Log In | Create Account

SourceForge.net > Projects > 1394-based DC Control Library > Mail > Archive

Donate

1394-based DC Control Library

Email Archive: libdc1394-devel (read-only)

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-07 10:44

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?

Samuel

Thread View

Thread	Author	Date
[libdc] multiple cameras and juju	Samuel Audet <samuel.audet@gm...>

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-24 13:56

Hi again,

Update: I tried something a bit different. Instead of using
DC1394_CAPTURE_POLICY_WAIT I tried to use DC1394_CAPTURE_POLICY_POLL
with a select() on the file descriptor just before... What happens then
is that select() continuously returns 1 (i.e.: no timeout), while
dc1394_capture_dequeue() continuously returns a NULL pointer for the
image... ???

Everything works fine with only one camera, but with two cameras on the
bus, it starts doing weird things.. Oh, and everything works fine with
PGR FlyCapture under Windows, so it's not a hardware problem.. thanks
for any advice, I will continue to investigate

Samuel

Samuel Audet wrote:
> 1. init the cameras as appropriate.. either of them have no problems
> running on their own
> 2. call dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT,
> raw_image) on both cameras on the same thread, one after the other
>
> This works for a couple of frames, but then dc1394_capture_dequeue()
> never returns...
>
> I noticed that if I insert a sleep() of 100 ms between the calls to
> dc1394_capture_dequeue(), then it appears to work OK, but the frame rate
> is tty bad obviously. Instead, if I simply yield() my timeslice on
> the thread, then it works for a few more frames than without, but
> eventually dc1394_capture_dequeue() never returns.

Re: [libdc] multiple cameras and juju

From: David Moore <dcm@MI...> - 2009-07-24 14:35

Hi Samuel,

My first suggestion would be to run your code with the environment
variable DC1394_DEBUG set to 1. This will produce some additional
debugging output that might be useful.

Secondly, it would be nice to rule-out thread-safety as a potential
issue. Could you transfer some of your code to a single-threaded
program and see if you can get it to work (two-camera) in that state?

Thanks,
David

On Fri, 2009-07-24 at 21:37 +0900, Samuel Audet wrote:
> Hello,
>
> I am having problems using more than one camera with juju... I am
> running libdc1394 2.1.2 on Fedora 10 and installed Linux 2.6.30 today
> just to make sure that did not fix the problem, and it has not. What I
> do is basically:
>
> 1. init the cameras as appropriate.. either of them have no problems
> running on their own
> 2. call dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT,
> raw_image) on both cameras on the same thread, one after the other
>
> This works for a couple of frames, but then dc1394_capture_dequeue()
> never returns...
>
> I noticed that if I insert a sleep() of 100 ms between the calls to
> dc1394_capture_dequeue(), then it appears to work OK, but the frame rate
> is tty bad obviously. Instead, if I simply yield() my timeslice on
> the thread, then it works for a few more frames than without, but
> eventually dc1394_capture_dequeue() never returns.
>
> Anyone knows what might explain this behavior? I do not remember having
> this problem a few years ago on the old firewire stack... Thank you for
> any input
>
> Samuel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mailing list for libdc1394-devel
> libdc1394-devel@lists.sourceforge.net /> > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: [libdc] multiple cameras and juju

From: David Moore <dcm@MI...> - 2009-07-24 14:38

On Fri, 2009-07-24 at 22:55 +0900, Samuel Audet wrote:
> Hi again,
>
> Update: I tried something a bit different. Instead of using
> DC1394_CAPTURE_POLICY_WAIT I tried to use DC1394_CAPTURE_POLICY_POLL
> with a select() on the file descriptor just before... What happens then
> is that select() continuously returns 1 (i.e.: no timeout), while
> dc1394_capture_dequeue() continuously returns a NULL pointer for the
> image... ???
>

I would suggest a slight modification to this test:

Call select() on _both_ camera's file descriptors simultaneously (they
will each have a different fd). Then, only call
dc1394_capture_dequeue() for a camera when that fd returns a readable
from select. Ultimately, this should be a superior method than just
alternating calls to dc1394_capture_dequeue.

-David

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-25 14:26

David Moore wrote:
> Hi Samuel,
>
> My first suggestion would be to run your code with the environment
> variable DC1394_DEBUG set to 1. This will produce some additional
> debugging output that might be useful.
>
> Secondly, it would be nice to rule-out thread-safety as a potential
> issue. Could you transfer some of your code to a single-threaded
> program and see if you can get it to work (two-camera) in that state?

Thanks! I will be trying those next week..

> Call select() on _both_ camera's file descriptors simultaneously (they
> will each have a different fd). Then, only call
> dc1394_capture_dequeue() for a camera when that fd returns a readable
> from select. Ultimately, this should be a superior method than just
> alternating calls to dc1394_capture_dequeue.

That brings back memories on debates over which "threading" model was
best :) With the future going towards multi-core processors, I guess we
can settle on kernel threads winning the argument. But synchronization
remains an issue, right.. something to think about..

> There's not an easy way to add this support because the kernel is doing
> all the queuing behind the scenes, but I'll think about it -- it might
> be possible.

And the kernel offers no way to peek at the queue?

I have no experience with juju, but quickly looking at the code, it
seems to work entirely with file descriptors.. ? I guess we could call
poll() or select() a second time after grabbing a frame to find if we
have at least _one_ frame behind. That's probably what most people are
looking after..

> On the other hand, now that timestamps are added, you can easily
> estimate frames_behind in userspace by subtracting the timestamp from a
> call to gettimeofday and then dividing by the expected time between
> frames.

That's an idea, thanks. If need be, I will do some testing to see how
much time difference I should expect for a fresh frame..

Samuel

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-27 09:02

David Moore wrote:
> Hi Samuel,
>
> My first suggestion would be to run your code with the environment
> variable DC1394_DEBUG set to 1. This will produce some additional
> debugging output that might be useful.

Ok, here is what I get just before and after it fails with two cameras:

libdc1394 debug: Juju: got iso event, cycle 0xae31, header_len 3840
libdc1394 debug: Juju: frame latency 406236 us
libdc1394 debug: Juju: got iso event, cycle 0xb25c, header_len 3840
libdc1394 debug: Juju: frame latency 273288 us
libdc1394 debug: Juju: got iso event, cycle 0xb686, header_len 3840
libdc1394 debug: Juju: frame latency 140695 us
libdc1394 debug: Juju: got iso event, cycle 0xae51, header_len 3840
libdc1394 debug: Juju: frame latency 404370 us
libdc1394 debug: Juju: got iso event, cycle 0xb27b, header_len 3840
libdc1394 debug: Juju: frame latency 271448 us
libdc1394 debug: Juju: got iso event, cycle 0xb6a6, header_len 3840
libdc1394 debug: Juju: frame latency 138725 us
libdc1394 debug: juju: Response error, rcode 0x11
libdc1394 error: Generic failure: in dc1394_video_set_transmission
(control.c, line 953): Could not stop ISO transmission
libdc1394 debug: juju: Response error, rcode 0x11
libdc1394 error: Generic failure: in dc1394_video_set_transmission
(control.c, line 953): Could not stop ISO transmission

I use poll() and my application does not stuck, but after this happens,
the firewire_ohci and firewire_core are fried. I have to reload them.
And I get a bunch of these in dmesg after my application exits:

firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)
firewire_ohci: context_stop: still active (0x48000671)

This happens even in a single threaded application.. as long as there is
a long enough wait between the dequeue()s and the enqueue()s, like a
sleep(1). Any opinions? (I have Core 2 Quad here.. might be a kernel
problem, but it's kind of weird that nothing bad happens with only one
camera.)

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-07-27 13:05

Samuel Audet wrote:
> And I get a bunch of these in dmesg after my application exits:
>
> firewire_ohci: context_stop: still active (0x48000671)

Kernel 2.6.28 and older printed these messages whenever a context was
stopped; they are harmless --- unless you get 10 of them at once. Then
it could be that DMA buffers are going to be freed before the controller
finished writing into them.

Kernel 2.6.29 and newer do not print these noisy messages anymore, they
only log an "Error: DMA context still active"... when the driver really
wasn't able to stop the controller in time.
--
Stefan Richter
-=====-==--= -=== ==-==
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-27 13:13

Stefan Richter wrote:
> Samuel Audet wrote:
>> And I get a bunch of these in dmesg after my application exits:
>>
>> firewire_ohci: context_stop: still active (0x48000671)
>
> Kernel 2.6.28 and older printed these messages whenever a context was
> stopped; they are harmless --- unless you get 10 of them at once. Then
> it could be that DMA buffers are going to be freed before the controller
> finished writing into them.

Yes, that is what I am getting. Exactly the amount I pasted and at the
very moment the application exits. But by that time, everything has
already gone south anyway, so ... it seems like the DMA transfers stop
coming through for some reason, but only when there are more than one
camera.

> Kernel 2.6.29 and newer do not print these noisy messages anymore, they
> only log an "Error: DMA context still active"... when the driver really
> wasn't able to stop the controller in time.

Ah, I remember that was the message I got when I tried 2.6.30 (but I
have issues unrelated to firewire running it on Fedora 10, so I am not
making it my primary kernel..)

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-07-27 13:29

Samuel Audet wrote:
> Stefan Richter wrote:
>> Samuel Audet wrote:
>>> And I get a bunch of these in dmesg after my application exits:
>>>
>>> firewire_ohci: context_stop: still active (0x48000671)
>> Kernel 2.6.28 and older printed these messages whenever a context was
>> stopped; they are harmless --- unless you get 10 of them at once. Then
>> it could be that DMA buffers are going to be freed before the controller
>> finished writing into them.
>
> Yes, that is what I am getting. Exactly the amount I pasted and at the
> very moment the application exits. But by that time, everything has
> already gone south anyway, so ... it seems like the DMA transfers stop
> coming through for some reason, but only when there are more than one
> camera.

Well, then it could be that the controller is already locked up and
doesn't react on some register writes and reads anymore.

What controller do you have? (lspci)

Furthermore, do you still get isochronous IRQ events when your
application doesn't receive any frames? You can check this by switching
on IRQ logging in the kernel:

echo 4 > /sys/module/firewire_ohci/parameters/debug

This will create considerable logging load, hence it may influence your
actual results. (Somebody once reported that he could control and
receive video from a consumer camcorder with debug logging enabled but
not without.)

>> Kernel 2.6.29 and newer do not print these noisy messages anymore, they
>> only log an "Error: DMA context still active"... when the driver really
>> wasn't able to stop the controller in time.
>
> Ah, I remember that was the message I got when I tried 2.6.30 (but I
> have issues unrelated to firewire running it on Fedora 10, so I am not
> making it my primary kernel..)
>
> Samuel

Ah, OK.
--
Stefan Richter
-=====-==--= -=== ==-==
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-28 01:17

Stefan Richter wrote:
> Well, then it could be that the controller is already locked up and
> doesn't react on some register writes and reads anymore.
>
> What controller do you have? (lspci)

I have two controllers actually:
03:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Exss1394b
Controller (PHY/Link) (rev 06)
04:00.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

The first one is from PGR, and that's the problematic one. I just tested
the second one (it is a cheap IEEE-1394a PCI card from Dell), and it
seems to work just fine. I cannot reproduce the problem with that one..

> Furthermore, do you still get isochronous IRQ events when your
> application doesn't receive any frames? You can check this by switching
> on IRQ logging in the kernel:
>
> echo 4 > /sys/module/firewire_ohci/parameters/debug

Ok, I did this under 2.6.30 and I get a lot of AR_resp and AR_req when
everything is fine, and here is what I get just before and after it fails:

Jul 28 10:10:40 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000001 AT_req
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000001 AT_req
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:42 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:42 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:43 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:43 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:44 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:44 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:45 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:45 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:46 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:46 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:47 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:47 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00000080 IR
Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
Jul 28 10:11:52 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
Jul 28 10:11:52 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
Jul 28 10:12:56 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
Jul 28 10:12:56 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds

At this point I get "cycle64Seconds" and that's it.. I get no new buffer
from the cameras.

Thanks for the input!

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-07-31 12:43

Samuel Audet wrote:
> I have two controllers actually:
> 03:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Exss1394b
> Controller (PHY/Link) (rev 06)
> 04:00.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)
>
> The first one is from PGR, and that's the problematic one. I just tested
> the second one (it is a cheap IEEE-1394a PCI card from Dell), and it
> seems to work just fine. I cannot reproduce the problem with that one..

I haven't heard anything negative about FW643 so far.

[...]
> Ok, I did this under 2.6.30 and I get a lot of AR_resp and AR_req when

This is when the configuration ROM is read and when control requests are
sent to the camera.

> everything is fine, and here is what I get just before and after it fails:
>
> Jul 28 10:10:40 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000001 AT_req
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000001 AT_req
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000020 AR_resp
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:41 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:42 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:42 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:43 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:43 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:44 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:44 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:45 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:45 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:46 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:46 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:47 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:47 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
> Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00000080 IR
> Jul 28 10:10:48 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
> Jul 28 10:11:52 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
> Jul 28 10:11:52 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
> Jul 28 10:12:56 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
> Jul 28 10:12:56 nemesis kernel: firewire_ohci: IRQ 00200000 cycle64Seconds
>
> At this point I get "cycle64Seconds" and that's it.. I get no new buffer
> from the cameras.

Either the camera stopped streaming, or the controller's IR DMA engine
stopped for whatever other reason.

cycle64Seconds is an interrupt event which the controller generates
whenever its cycle counter register wraps around. (As the name says,
that's every 64 seconds.)
--
Stefan Richter
-=====-==--= -=== =====
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-07-31 13:24

Stefan Richter wrote:
>> I have two controllers actually:
>> 03:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Exss1394b
>> Controller (PHY/Link) (rev 06)
>> 04:00.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)
>>
>> The first one is from PGR, and that's the problematic one. I just tested
>> the second one (it is a cheap IEEE-1394a PCI card from Dell), and it
>> seems to work just fine. I cannot reproduce the problem with that one..
>
> I haven't heard anything negative about FW643 so far.

There's always a first :)

Anyone else? :)

>> At this point I get "cycle64Seconds" and that's it.. I get no new buffer
>> from the cameras.
>
> Either the camera stopped streaming, or the controller's IR DMA engine
> stopped for whatever other reason.
>
> cycle64Seconds is an interrupt event which the controller generates
> whenever its cycle counter register wraps around. (As the name says,
> that's every 64 seconds.)

The strange thing is, everything works just great under Windows XP (32
bit mind you, so < 4 gig of RAM there) with PGR FlyCapture... ?

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-07-31 13:58

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?

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.

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
--
Stefan Richter
-=====-==--= -=== =====
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-07 10:44

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?

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-08-07 12:19

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.

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?

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

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

It's not about 64 bit vs. 32 bit...

OHCI 1.0 (1997-10-20) compliant controllers offer two modes of
isochronous reception: Packet-per-buffer, and buffer-fill. They differ
WRT how packets are written into buffer segments.

OHCI 1.1 (2000-01-06) added a third mode: Dual-buffer. This mode uses
two reception buffers instead of one, and the controller automatically
splits each packet into two portions of configurable length; one portion
to be written into the 1st buffer, the other portion into the 2nd
buffer. Obviously, this mode is perfect for splitting packet headers
from payloads, therefore firewire-ohci uses this whenever possible.

The older ohci1394 driver only uses packet-per-buffer and buffer-fill,
and video1394 only uses buffer-fill. And I suppose the other 1394
driver stacks of popular OSs don't use dual-buffer either.

And guess what: Now that /somebody/ actually starts using this new
feature, new hardware bugs are being discovered.

This is from our current setup code of firewire-ohci:

version = reg_read(ohci, OHCI1394_Version) & 0x00ff00ff;
ohci->use_dualbuffer = version >= OHCI_VERSION_1_1;

/* x86-32 currently doesn't use highmem for dma_alloc_coherent */
#if !defined(CONFIG_X86_32)
/* dual-buffer mode is broken with descriptor addresses above 2G */
if (dev->vendor == PCI_VENDOR_ID_TI &&
dev->device == PCI_DEVICE_ID_TI_TSB43AB22)
ohci->use_dualbuffer = false;
#endif

This was added after we had a report of corrupt video data received with
a TSB43AB22 or more likely TSB43AB22A on a PC with "lots" of memory:
http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commit;h=95984f62c9b0bf6d89ef4f514b1afe73623481de
https://bugzilla.redhat.com/show_bug.cgi?id=435550
This bug took ages to debug, and this chip erratum was not viously
known even to technicians at TI, so I heard.

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
FW643 or at least your particular hardware revision of FW643.
--
Stefan Richter
-=====-==--= =--- --===
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-07 12:32

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
Exss1394b 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
> FW643 or at least your particular hardware revision of FW643.

Interesting story, thanks for the details :) Yes, mem=2G did not change
anything..

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-08-07 13:45

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
# dmesg | tail

>> How are these two controllers shown by "lspci -nn"?
>
> 03:00.0 FireWire (IEEE 1394) [0c00]: Agere Systems FW643 PCI
> Exss1394b 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!

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.

(a) If FW643 is buggy in dual buffer mode, it's not very unlikely that
the older FWxxx are buggy there too; nobody noticed it yet though
because so many FW323 are EEPROM-programmed to OHCI 1.0 mode.

(b) Now that FW643 or FWxxx have become known to be buggy in dual buffer
mode, there remains only a _single_ controller which is known to support
dual buffer correctly and is reasonably widesad: The TI TSB82AA2
1394b/S800 controller.

Well, I for one currently have controllers with the following four OHCI
1.1 controllers and can test them in a PC with 6 GB RAM:
- TI TSB82AA2 -- seems to work,
- TI TSB43AB22(A) -- the buggy one, but I haven't tested it myself in
the 6 GB machine without the quirk fix yet,
- ALi M5271 -- can't test it yet because we need to fix
http://bugzilla.kernel.org/show_bug.cgi?id=10935 first,
- JMicron JMB381 -- seems to work. (Doesn't work very stable BTW.
I have seen its DMA units occasionally getting stuck with the new
drivers and with the old drivers alike.)
--
Stefan Richter
-=====-==--= =--- --===
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-10 09:25

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
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?

> (a) If FW643 is buggy in dual buffer mode, it's not very unlikely that
> the older FWxxx are buggy there too; nobody noticed it yet though
> because so many FW323 are EEPROM-programmed to OHCI 1.0 mode.
>
> (b) Now that FW643 or FWxxx have become known to be buggy in dual buffer
> mode, there remains only a _single_ controller which is known to support
> dual buffer correctly and is reasonably widesad: The TI TSB82AA2
> 1394b/S800 controller.
>
> Well, I for one currently have controllers with the following four OHCI
> 1.1 controllers and can test them in a PC with 6 GB RAM:
> - TI TSB82AA2 -- seems to work,
> - TI TSB43AB22(A) -- the buggy one, but I haven't tested it myself in
> the 6 GB machine without the quirk fix yet,
> - ALi M5271 -- can't test it yet because we need to fix
> http://bugzilla.kernel.org/show_bug.cgi?id=10935 first,
> - JMicron JMB381 -- seems to work. (Doesn't work very stable BTW.
> I have seen its DMA units occasionally getting stuck with the new
> drivers and with the old drivers alike.)

And I can test the FW643 :)

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-08-10 18:12

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
known in advance.

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.

But support of stream formats with variably sized packets is another
matter which changes the whole picture.
--
Stefan Richter
-=====-==--= =--- -=-=-
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-11 06:13

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.
>
> But support of stream formats with variably sized packets is another
> matter which changes the whole picture.

That's why I think it should remain a module parameter somewhere.. A
device that would benefit from dual buffers could tell the user to drop
some file in /etc/modprobe.d/, try it, and delete it if it makes things
worse instead..

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-08-19 19:16

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
@@ -29,6 +29,7 @@ /> #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>
@@ -181,6 +182,7 @@ struct fw_ohci {
u32 bus_seconds;

bool use_dualbuffer;
+ bool single_dualbuffer;
bool old_uninorth;
bool bus_reset_packet_quirk;

@@ -1921,11 +1923,18 @@ static struct fw_iso_context *ohci_alloc
}

spin_lock_irqsave(&ohci->lock, flags);
+
+ if (type == FW_ISO_CONTEXT_RECEIVE &&
+ ohci->single_dualbuffer &&
+ *channels != ~0ULL)
+ callback = handle_ir_packet_per_buffer;
+
index = *channels & 1ULL << channel ? ffs(*mask) - 1 : -1;
if (index >= 0) {
*channels &= ~(1ULL << channel);
*mask &= ~(1 << index);
}
+
spin_unlock_irqrestore(&ohci->lock, flags);

if (index < 0)
@@ -1980,7 +1989,7 @@ static int ohci_start_iso(struct fw_iso_
} else {
index = ctx - ohci->ir_context_list;
control = IR_CONTEXT_ISOCH_HEADER;
- if (ohci->use_dualbuffer)
+ if (ctx->context.callback == handle_ir_dualbuffer_packet)
control |= IR_CONTEXT_DUAL_BUFFER_MODE;
match = (tags << 28) | (sync << 8) | ctx->base.channel;
if (cycle >= 0) {
@@ -2308,7 +2317,7 @@ static int ohci_queue_iso(struct fw_iso_
spin_lock_irqsave(&ctx->context.ohci->lock, flags);
if (base->type == FW_ISO_CONTEXT_TRANSMIT)
ret = ohci_queue_iso_transmit(base, packet, buffer, payload);
- else if (ctx->context.ohci->use_dualbuffer)
+ else if (ctx->context.callback == handle_ir_dualbuffer_packet)
ret = ohci_queue_iso_receive_dualbuffer(base, packet,
buffer, payload);
else
@@ -2429,6 +2438,10 @@ static int __devinit pci_probe(struct pc
#endif
ohci->bus_reset_packet_quirk = dev->vendor == PCI_VENDOR_ID_TI;

+ /* dual-buffer mode is broken if more than one context is active */
+ ohci->single_dualbuffer = dev->vendor == PCI_VENDOR_ID_ATT &&
+ dev->device == 0x5901; /* FW643 */
+
ar_context_init(&ohci->ar_request_ctx, ohci,
OHCI1394_AsReqRcvContextControlSet);

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

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-08-28 07:07

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.

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-08-28 07:31

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/

Re: [libdc] multiple cameras and juju

From: Jonathan Cameron <jic23@ca...> - 2009-09-01 11:33

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

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-09-01 11:48

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/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-09-01 13:03

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

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-09-01 15:21

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 apciated. 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
-=====-==--= =--= ----=
http://arcgraph.de/sr/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-09-02 12:32

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 apciated. 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 cise..) thanks again!

Samuel

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-09-02 14:03

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 cise..) 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/

Re: [libdc] multiple cameras and juju

From: Stefan Richter <stefanr@s5...> - 2009-09-04 08:14

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/

Re: [libdc] multiple cameras and juju

From: Samuel Audet <samuel.audet@gm...> - 2009-09-15 09:45

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?

1394-based DC Control Library

Email Archive: libdc1394-devel (read-only)

Thread View

About SourceForge

Find Software

Develop Software

Community

Help