On Tue, 2005-04-19 at 17:06 -0700, Carlos Y. Villalpando wrote:
> Hey all,
> I'm trying to chase down a problem with 1394 capture using libdc, and
> have run out of ideas. So I'm trolling for suggestions.
> It is a custom hardware embedded system using Xilinx's VirtexIIPro,
> which will explain why we're using an old version of libdc and Linux.
> The system is a VirtexIIPro, with on-board PCI/ethernet/DDR/serial/CF
> using Xilinx's opb_pci_ref core based on the ML300 reference design.
> We're using Linux kernel 2.4.22, libraw1394 0.9.0, and libdc1394 0.9.1
> and 0.9.3. We can't swtich to Linux 2.6 yet since MontaVista is
> supplying the Linux device drivers for Xilinx, and they're still at
> 2.4.x. There is a TI 4322 family OHCI 1394 chip hanging off the PCI
> bus, and we've even run experiments with a Synergy 1394 PMC card
> connected to the on-board PCI bus using PMC with the same results.
> The same results will happen to both our custom board, and the Xilinx
> ML300 evaluation board.
Have you tried the latest 2.4.30? I don't know how well the 2.4 branch
is maintained but there must have been improvements since 2.4.22...
> The symptoms are:
> Linux boots, sees the 1394 chip (or both, if the Synergy board is
> connected) and configures it.
> The ohci1394 and ieee1394 modules see the chip(s) and the devices
> appear in /dev (using devfs at the moment).
> lspci lists the devices correctly.
> /proc/bus/ieee1394/devices lists the host, and the 1394 cameras on
> the bus (Pt Grey Dragonflys at the moment. Hi PtGrey!)
Hi Don! ;-)
> Using a custom program based on the example included in libdc, but
> modified to capture stereo images using dma_multi_capture(), I can
> see the cameras, query them, set them up, set up the dma capture, and
> start isochronous transmission. This is all verified using a 1394
> bus analyzer.
> Capture will happen fine from anywhere from 20 seconds to 20 minutes,
> and then hang. Hanging will occur with the program waiting on a
> VIDEO1394_LISTEN_WAIT_BUFFER ioctl to return. I can control-C out of
> the program, and re-start it with the same behavior. The hanging
> seems to be triggered on a race condition. If I increase the
> frequency in which I call dma_multi_capture() the quicker it will
If it works for some time and then hang I would suspect a kernel
problem, not something related to libdc. The only thing I can imagine
with libdc would be that your image buffer gets full at some point and
then something goes wrong. Very unlikely though...
> On infrequent, but not insignificant, occasion, the hang will occur on
> the dma_setup_capture() call. If I control-C out of that, the entire
> OS will hang.
> I'm hoping it's the last two items that will jog someone's memory. I'm
> also working on converting to the full EDK PCI, but having Linux
> problems at the moment.
I remember that a serious issue was corrected around 2.4.23. If possible
upgrade to 2.4.30 and hope it will work. If not, upgrade your kernel
version step by step (2.4.23, 2.4.24,...) to see if something works. I
know this can be time consuming but I'm not a kernel hacker so I don't
have many ideas here...
Alternatively, you can check linux1394.org and get the a recent SVN
snapshot for your kernel (be sure to get the 2.4 branch, of course).
That will avoid lengthy compilations but you could run into compilation
> I'm not ruling out anything, but I've also speed up the PCI clock,
> slowed it down, changed its phase internal vs external, etc. Same
> results. I don't expect this list to answer hardware problems, I'm
> asking elsewhere for that.
> Any clues? I'm chasing two paths, 1) something's up with the Linux
> kernel/libdc, which is for this list, and 2) Something's up with
> OPB_PCI_REF, which is for my other source.
I'm not aware of any problem in libdc that would trigger this hang. To
me it's rather a kernel problem.
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, Nara Institute of Science and Technology