On Mon, May 27, 2013 at 7:54 AM, Michael Haberler <[email protected]>wrote:
> > > - the branch you compiled, and the configure options > 25may pull from v2.5_branch - the operating system version and source > Kernel: vmlinuz-2.6.38.8-120804.a-multitouch-rtai this is 2.6.38.8 with multitouch and rtai (3.9magma from august '12) applied. OS: Debian 'jessie' amd64 - the invocation line of the hostmot2 driver > loadrt hm2_pci config="firmware=hm2/5i23/SVST8_4.BIT" > > so far I do not even know this is a kernel or userland build; > /var/log/messages hints at userland but I cannot tell > > since RTAPI messages go some very different flows depending on branch and > build options, all guesses are off > > I am rather confident that is is a simple non-blocking buffering problem from 'rtapi_print_msg'. I note that the behavior of this call has changed in 'rtos-integration-preview3', with the output messages going to hal's tty rather than the system message logging facility. I have, within the last 2 hours configured and compiled 'rtos-integration-preview3' against '3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.41-2+deb7u2 x86_64', which is the vanilla -rt kernel from 'jessie'. In this instance the pin enumeration is correct. please state a git commit (SHA) of the Xenomai branch you pulled. > Unfortunately, I threw that pull and its parent directory away. > My suggestion is to report to the Xenomai list as the code comes from the > Xenomai project; the builtin SMI support is rather new and it is quite > likely some chipset variation isnt supported. > > I should probably do that. The error is not in the chipset detection, but rather in the kernel commandline parsing. I gather that the current Xenomai code does not do chipset detection at all, but rather relies upon the user to pass correct configuration parameters to the kernel. I couldn't get that to work. > > there's nothing anybody could say with confidence before we know the basic > facts. > Well, your preview3 stuff against a vanilla jessie kernel enumerates hostmot2 pins correctly on hal's tty rather than /var/log/messages. v2.5_branch against vmlinuz-2.6.38.8-120804.a-multitouch-rtai writes 'rtapi_print_msg' to /var/log/messages, incorrectly. vmlinuz-2.6.38.8-120804.a-multitouch-rtai has less that 5us latency. 3.2.0-4-rt-amd64 has ~50us latency. This is better than Xenomai for me. Further with respect to 3.2.0-4-rt-amd64 latency. There are latency spikes on invocation, but once it 'warms up' the latency goes down to about ~25us. Is this consistent with what others have observed? Finally, is 64bit getting good test coverage? I note that vast majority of users are on 32bits. I will most likely proceed with v2.5_branch against vmlinuz-2.6.38.8-120804.a-multitouch-rtai. I would like to try to fix (read: understand) its issue with 'rtapi_print_msg'. > thanks, > > - Michael > > Thankyou jCandlish ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
