[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-devel
Subject:    instability of JMicron OHCI 1394 controllers
From:       Stefan Richter <stefanr () s5r6 ! in-berlin ! de>
Date:       2010-02-21 16:45:50
Message-ID: 4B81633E.30302 () s5r6 ! in-berlin ! de
[Download RAW message or body]

On 2010-02-13, I wrote at ffado-devel:
>> 2010/1/22 Stefan Richter <stefanr@s5r6.in-berlin.de>
>>
>>> Martin Pittamitz wrote:
>>>> My firewire controller is
>>>>
>>>> 02:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host
>>>> Controller
>>> I have a motherboard with a JMicron controller.  It works quite OK for
>>> storage devices (asynchronous I/O, comparably low interrupt rate),
>>> though not as stable as most controllers.  But DV and DCAM capture (i.e.
>>> compressed and uncompressed video) do not really work:  The DMA units of
>>> the controller get stuck at a random point not long after captuer is
>>> started.  I have not tested it with FFADO yet.
>>>
>>> Perhaps there are ways to make it work for audio, but its consistent
>>> failures in video capture aren't a good sign.
> 
> I tested the JMicron controller again today.  The issue with DCAM
> capture is that video reception works, but trying to control camera
> parameters like white balance and saturation on the fly, let alone
> changing video format, is a quick way to let all isochronous and
> asynchronous DMAs of the controller die.  The only way out of this is to
> unbind and re-bind the kernel driver to the PCI device (or unload and
> re-load the driver module).
> 
> I then tested FFADO with a Terratec Phase X24 FW on this controller.
> Stereo audio streaming works similarly well as with a different
> controller (i.e. with some xruns; I only run vanilla kernels, not -rt
> patched kernels).  However, starting ffado-mixer let jackd die
> immediately.  Right at this moment, the controller is left unusable; an
> "echo -n 0000:04:00.0 >
> /sys/module/firewire_ohci/drivers/pci\:firewire_ohci/unbind" is stuck in
> D state.  I.e. I will have to reboot before I can use that controller
> for anything again.

A few days ago I coincidentally read in a German-speaking web forum from
somebody who owns the same motherboard as I do.  He reported that he
could only use a FireWire set top box at the onboard FireWire controller
if he used only 2 GB of RAM.  He did not describe in detail how it
failed with more RAM than this.  Also, this was on Windows, so maybe it
was simply a bug in the Windows drivers for this set top box.

Anyway; since I have 6 GB RAM installed, I tried the following to
workarounds today (separately):

	/* Force descriptors into lower 2 GB of physical addresses */
	pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(31));

	/* Force descriptors and buffers into lower 2 GB */
	dma_set_mask(&dev->dev, DMA_BIT_MASK(31));

However, as my quick coriander based test revealed, neither of these was
able to stabilize the JMicron controller.

What I also noticed today is that asynchronous I/O failed ( = coriander
told that it could not set a feature) apparently before isochronous I/O
( = the live video window kept showing new frames for another one or two
seconds or so before the image froze).
-- 
Stefan Richter
-=====-==-=- --=- =-=-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
[prev in list] [next in list] [prev in thread] [next in thread]