9. FAQ

9.1 The Shell utilities return a bunch of stars (*) when I access a board I know is there. What gives?

Check to be sure the /dev/vme... files have their permissions set to 666. If not, the shell utilities will return a * in place of data to indicate an error condition similar to a VME bus error.

9.2 The Shell utilities still return a bunch of stars (*) when I access a board I know is there. Now what?

It is possible the ca91c042 Linux kernel module has been compromised. Get root access and type "lsmod" to review the loaded modules. Do you see the ca91c042? If yes, try removing it and reinstalling it with "rmmod ca91c042" and then "insmod /path/to/the/ca91c042.o" to get things up again. If it is not there check to see if you are loading the module when you boot the machine, etc.

9.3 The Shell utilities still return a bunch of stars (*) when I access a board I know is there. HELP?

Time to get a VMetro board into the VME cage and see if any accesses are occurring. Also look at the /proc/ca91c042 file to see if the read and write counters are incrementing.

9.4 How does VMELinux handle interrupts?

The driver does handle interrupts, but if you compile your interrupt handler program as a Linux loadable module, that program can handle the interrupts directly. Examples of this will be available soon. It is important to note that user level program can be made to handle interrupts, but it is a much better idea to have your interrupt handlers as part of the Linux kernel via loadable modules. Yes, you can totally hose the kernel if you do something wrong, but that is the trade off between safety and performance.

9.5 I have RedHat 5.1 and can't get VMELinux programs to compile.

RedHat 5.1 includes a new compiler. If you manually edit the Makefile in each directory to call up the new egcs compiler, things should compile. We fully intend to support RedHat 5.1 installations, but for now I suggest using 5.0 or Slackware.

9.6 I have RedHat 6.x so I assume the above issue is fixed. Right?

Maybe. RedHat threw us, and many other kernel module driver writers, a curve ball with the move to the egcs compiler. Thankfully, the two compiler camps, GCC and egcs, have united their efforts. All this incompatibility should just go away. For the moment, however, VMELinux will only be tested with GCC 2.95.x so that is what we suggest you use for a compiler. If you type "gcc --version" at your prompt and get an "egcs..." back then we cannot say it will work for you.

9.7 When will your ca91c042 Tundra Universe driver support the 2.4 kernels?

Now. Download the latest tar ball from the download directory at the main site. 2.4 support was added in version vmelinux-1.2.0.

9.8 Hey! The Universe II has eight master and eight slave images. You support four each. Why?

We have been at this a long time and initially created these tools for the original Universe I which according to the documentation has four images each. When boards arrived with the Universe II, we searched the Tundra web site in vain for new documentation. We were told by the board manufacturers the II works just like the original; Thus, we only worried about the original four images. Just recently some good folks pointed out our omission. We finally found the correct documentation on the web site and support the extra images as of the 1.3.0 development release.

More news! The latest CVS snapshots of the ca91c042.c and ca91c042.h files will notice which Universe version is in your system and act accordingly.

Please note, we have not yet found any good reason to spend time developing support for the eight (or four) slave images. The current tools only support the master images and this has proven adequate for every need we have come across. If you think slave support is a good thing, let us know.

The folks at VMIC have a kernel driver they say does support the slave images and is available under a BSD style license. The announcment may be found in our mail list archive mail list archive and the correct link to there web site is here.

9.9 How can we contribute to your VME-LINUX working group?

All programming efforts thus far have been accomplished by Michael Wyrick. My role has been to coordinate the VMELinux Project and help define and test the resulting programs.

We have successfully placed the working code into a CVS system and are using it to track code changes. Right now only Mike and myself have write access to this. If you are seriously interested in VMELinux development and you know your way around Linux kernel programming, please join us by joining the developers mailing list and creating an account on our bug tracking system located here.

If you cannot develop code, please consider keeping us informed about any bugs you see or features we should add. You can send mail to the user or developer mail lists, but contributing your comments to the bug tracking system is much more useful. Just visit VMELinux Project Bug Tracking System, create an account, submit your report and we will address it as soon as we can.

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:37