Re: receiving an evt_timeout error code with Ricoh R5C832 PCIe controller
Brought to you by:
aeb,
bencollins
From: Jarvis S. <sch...@gm...> - 2012-08-06 16:15:56
|
Just FYI, I gave the Phantom Omni forum a quick overview of the discussion that we have been having, and I just received a response. Here is a quote from one of their support team members: > Most of the firewire cards have some firmware logic in them to arbitrate the 1394 isochronous mode. The omni also operates in the isochronous mode. > If the firmware in the 1394 chip has some problem, then you are going to see it in someway of the other. Because, the isochronous mode is > completely initiated and managed by the 1394 controller. He then provided a link to some recommended cards that seem to work. I just ordered the cheapest recommended one, and I will report back with the results and the card info. On Thu, Aug 2, 2012 at 8:49 PM, Jarvis Schultz <sch...@gm...> wrote: > > On Thu, Aug 2, 2012 at 5:12 PM, Stefan Richter > <st...@s5...> wrote: > > > > On Aug 02 Jarvis Schultz wrote: > > > On Thu, Aug 2, 2012 at 1:54 AM, Stefan Richter > > > <st...@s5...> > > > wrote: > > > > Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does > > > > "grep firewire /proc/interrupts" show? > > > > > > > Here is the output of that: > > > 19: 3043 0 0 0 0 0 > > > 0 21 IO-APIC-fasteoi firewire_ohci > > > > I.e. your kernel has got the "don't use MSI on Ricoh OHCI-1394" flag > > already in its built in table. > > > > [...] > > > > Vice versa, if the quirk is built in, it can be switched off > > > > by a different value to the module parameter: > > [...] > > > I tried both of these "quirk" levels, and there is no change to the > > > behavior. > > > > Interesting; this means we could narrow the built-in quirk down to the > > chip version which was originally reported as broken with MSI, and let > > chip versions like yours use MSI again. But this doesn't help you one > > bit, alas. > > > > [...] > > > >> System Details: > > > >> Kernel version - 3.2.0-27 > > [...] > > > grep command: > > > # CONFIG_PREEMPT_RCU is not set > > > CONFIG_PREEMPT_NOTIFIERS=y > > > # CONFIG_PREEMPT_NONE is not set > > > CONFIG_PREEMPT_VOLUNTARY=y > > > # CONFIG_PREEMPT is not set > > > > Have a look whether your distribution also offers a kernel package which > > is called "lowlatency" or "desktop" or something along these lines --- and > > in effect has got CONFIG_PREEMPT=y and "# CONFIG_PREEMPT_VOLUNTARY is not > > set". The CONFIG_PREEMPT option is found under "Processor type and > > features -> Preemption Model -> Preemptible Kernel (Low-Latency Desktop)" > > in the kernel configuration menu when kernel sources are configured as > > preparation of a kernel build from source. > > > > CONFIG_PREEMPT means that kernel threads are put to sleep by the CPU > > scheduler when it used up its time slice and another process is waiting to > > get CPU time, very much the same way as the CPU scheduler treats userspace > > processes when they used up their time slice. > > > > I am suggesting to try such a kernel because there is a slight chance that > > reduced scheduling latency helps the Phantom Omni drivers to queue > > FireWire packets more steadily, which in turn might reduce the likelihood > > that Ricoh controller stops its DMA unrecoverably. > > > I just ran installed the most up-to-date lowlatency kernel that Ubuntu > 12.04 has which was built around 3.2.0-23. To address the next > comment, I booted into a console-only-mode, and made sure the fglrx > drivers weren't loaded. I saw the same behavior as before. Also, I > tried both kernels with the open source radeon drivers in a full > desktop session, and repeatedly received the same errors. > > > I attached my /proc/interrupts file as interrupts_log.txt > > > > Looks inconspicuous to me. Just one thing: Have you tried the mainline > > "radeon" driver instead of the closed source fglrx driver already? 3rd > > party kernel drivers tend to be latency sources due to lack of independent > > review and tie-in into mainline development. > > > > [...] > > > > Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > > > > > > > Here it is: > > > 09:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 > > > Controller [1180:e832] (rev 01) > > > > Thanks for this. Same PCI ID as in the report which led to kernel commit > > 320cfa6ce0b3, but rev 01 instead of rev 00. > > > > > >> 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 drivers are userspace drivers, and they are distributed as just a > > > sequence of shared libraries. The old drivers that they released > > > depended > > > on the raw1394 kernel module. These new "pre-beta JUJU" drivers do not. > > > I > > > originally tried to get this working with their old drivers, and > > > followed > > > the instructions at this site: > > > https://wiki.sofa-framework.org/tdev/wiki/HowTo/SensableWithoutRaw1394 > > > to > > > create a "dummy" kernel module. > > > > Argh. :-) Nitpick: "ln /dev/null /dev/raw1394" probably would have worked > > just as well as "ln /dev/fw0 /dev/raw1394". /dev/fw* does not support > > any of the ioctl/write/read operations that are valid on /dev/raw1394. > > Anyway, the former necessity of this dummy module and dummy file is a fine > > showcase of the joys and wonders of non-free software. > > > > > I am not positive I was getting the same > > > error messages, but I was getting the same "freezing" behavior. > > > > > > > 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. > > > > > > > I am a little confused by their terminology. Their binaries are > > > absolutely > > > linked to libraw1394 libraries. I believe they are using the term JUJU > > > because they no longer use the kernel module raw1394. > > > > They never directly used the kernel module, they used libraw1394. > > (Which is good because the developers of raw1394 intended the raw1394 > > kernel interface to be private to the raw1394<-->libraw1394 pair. This > > in turn facilitated the transition to the binary incompatible > > <linux/firewire-cdev.h> kernel interface provided by firewire-core > > while retaining compatibility with libraw1394 based application > > software. libraw1394 v2 transparently uses raw1394's or firewire-core's > > mutually incompatible interfaces depending on what libraw1394 detects to > > be > > available at runtime.) > > > > So this "JUJU" designation either refers to the accomplishment of removing > > that silly check for presence of raw1394, or it means that they added a > > new > > <linux/firewire-cdev.h> backend but are still keeping a libraw1394 based > > backend as an alternative or for parts of their functionality. > > > > Or it means that they noticed that libraw1394 does not behave 100% the > > same when running on top of firewire-core versus raw1394, and added some > > workarounds in their own code (instead of submitting fixes to upstream > > libraw1394 or kernel, or at least reporting such issues). > > > > I guess one could find out more about it by running it all in a debugger > > or by inserting some simple debug logging into libraw1394. But I don't > > think at this point that it would get us nearer to a fix for the Ricoh > > problem (or what I believe to be a Ricoh problem). > > > > > Not really sure if > > > this is correct. I just downloaded and compiled libraw1394 2.1.0, and > > > made > > > sure that the drivers were finding the new versions that I installed > > > (using > > > ldd and ldconfig). I still get the same error message. > > > > OK. Either the libraw1394 2.0.7 change which I alluded to simply does not > > have a positive effect here ---- which is not surprising since that change > > was implemented to address a different problem than yours ---, or the > > drivers bypass libraw1394 when running on top of firewire-core, or both. > > > > > > 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. > > > > > > You are absolutely correct. I have to provide them with my device > > > serial > > > number, just to access the driver download, and even then, I only get > > > binaries and libraries, not source code. I guess it's not quite > > > "OpenHaptics"... > > > > Well, at least they do provide something for Linux users among their > > customers, although in a not particularly pragmatic form. > That is absolutely right, the Linux support is definitely appreciated! > > As a final update, I just did some testing with our lab's server > machine. The machine has the same version for the kernel, the > drivers, the shared libraries the drivers depend on, and the > application I have been using to test (i.e. quite similar software > builds). The firewire controller on that machine is > > 06:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A > IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023] > > Every test application that sensable/ OpenHaptics provides worked > without any errors. > > > -- > > Stefan Richter > > -=====-===-- =--- ---== > > http://arcgraph.de/sr/ |