Re: receiving an evt_timeout error code with Ricoh R5C832 PCIe controller
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-08-02 06:54:29
|
On Jul 31 Jarvis Schultz wrote: > I'm trying to use the Phantom Omni haptic device, and the apps keep > freezing. The driver developers insist that the drivers work stably on all > of the linux distros that they have tested them on. Phantom Omni's developers possibly don't have a Ricoh PCIe controller, or do they? > Yet, both firewire > computers I have are producing the exact same results. I noticed that in > the change log for kernel version 3.3 there was mention of some bug fixes > for the Ricoh PCIe 1394 controllers. I'm wondering if it is possible that > I am experiencing some of these downstream fixed bugs? The Ricoh PCIe controller related change in kernel 3.3 simply consists of using classic interrupts instead of MSI (http://en.wikipedia.org/wiki/Message_Signaled_Interrupts). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=320cfa6ce0b3dc794fedfa4bae54c0f65077234d This change was also put into kernel 3.2.6, released on 13 February 2012. http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=c1a1e15fd6fe7ed496d115ac9b87649e4d827d65 Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does "grep firewire /proc/interrupts" show? The "disable MSI" quirk can also be switched on by means of a module parameter to firewire-ohci if you have a kernel without the built-in quirk table entry. As root user: # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=17 Vice versa, if the quirk is built in, it can be switched off by a different value to the module parameter: # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=1 (A note for other readers and for the mailinglist archive: This module parameter is not a stable API and does some fairly low-level changes. For this and other reasons this module parameter is not normally meant to be used by end users, and particularly not meant for permanent use.) > Occasionally when connecting the device I get a message that says > > firewire_ohci: isochronous cycle inconsistent This is quite common when the bus topology changes. I wonder if we should normally suppress this message. If the drivers are not yet active at the very moment when you connect the device, you can disregard this message. Or are they? > Every application that I run works for a few seconds, and then just > freezes. The message printed in dmesg every time an app freezes is > > firewire_ohci: DMA context IT0 has stopped, error code: evt_timeout This indicates that drivers use isochronous transmission DMA (among else), i.e. a stream of packets from the PC to the device at a steady rate of 8000 packets per second. This is probably the carrier for the force feedback functionality. The message is logged when an interrupt signaled to the CPU that one or more DMA stopped due to an unrecoverable error. If they do, then the drivers are quite likely to be affected by controller hardware bugs to a similar extent as the FFADO audio drivers. http://subversion.ffado.org/wiki/HostControllers gives you an expression how many controller types are actually very unreliable as soon as I/O gets a little bit different from the usual SBP-2 storage or DV capture applications. > System Details: > Kernel version - 3.2.0-27 What do you get from "grep PREEMPT /boot/config-$(uname -r)" and from "cat /proc/interrupts"? > Kernel drivers, adapter, card and OHCI chipset - > 09:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 01) (prog-if 10 [OHCI]) > Kernel driver in use: firewire_ohci > Kernel modules: firewire-ohci Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > > libraw1394 version - 2.0.5 Are the Phantom Omni drivers kernel drivers or userspace drivers? If the latter, are they using libraw1394? You could for example check with "ldd /path/to/the/driver/binary.xy" which lists all libraries to which 'binary.xy' is dynamically linked to. Libraries which are statically linked into a binary ( = incorporated into the binary) won't show up this way though. The term "JUJU" implies that the drivers are not using libraw1394. But if they do, you should try to update to libraw1394 2.0.7 or later because it has got changes which affect isochronous streaming. Current and stable is 2.1.0. Of course an update of the system-wide installed libraw1394 would only have effect if the Phantom Omni drivers are dynamically linked to it. http://www.sensable.com/support-download-pdd.htm looks like the Phantom Omni drivers are not free, not open source, and not even made available to anybody but customers of theirs. In which case it would be hard to find out what kinds of I/O these drivers need and which userspace/ kernelspace code paths they go through, obviously. -- Stefan Richter -=====-===-- =--- ---=- http://arcgraph.de/sr/ |