Re: about using NI-1014 with VME/Linux

[Eric Norum <norume@aps.anl.gov>]

On Dec 22, 2005, at 7:39 PM, Jun-ichi Odagiri wrote:

Dear Eric;

I'd like to thank you for your reply.

I think I should have explained why I'm trying to do the work.

Using NI-1014 in itself is not the purpose of the work.

What I'd like to do is to confirm that a library developed by Dr. Kim Kukhee

to support VME-bus access works well for J-PARC control.

The reason I chose NI-1014 is, as far as I know, its driver is the most

complicated one, since the board uses interrupts and DMA.

If I can make it work with the library, I thought I could say,

"OK, I may be able to support any kind of boards with the library."

That's the goal of the work.

Yes, that would be a good learning experience, but I should mention that the NI-1014 driver distributed with the ASYN package does not use DMA.  Marty and I had a long look at the hardware description and found so many race conditions that we felt it better to use interrupt-driven I/O.    In fact we've just been informed that we may need to add some more busy-loops to get the hardware to work with fast PowerPC VME processor cards.

The library works on top of a kernel level driver supplied by the

manufacture of the VMIVME-series CPU, and maps the VME address space into

the address space of a user process.

The library offers functions something like "sysBusToLocalAddr",

"intConnect", ... to be called by normal user process.

I'm thinking of running the NI1014 driver in user space by using the

library.

(I never want to work in the Linux kernel space. I know how hard it is.)

Having told you the background, I'd like to ask you the following questions

again.

How is the driver of NI1014 supposed to be used in user mode on Linux?

Is it supposed to work with some specific library in EPICS Base?

How the driver was tested when it was developed?

What was the platform for the development?

The NI-1014 driver was not written with Linux in mind and certainly not Linux in user-mode.  Marty Kraimer and Ron Sluiter have done extensive tests of the driver on vxWorks and I have some some very quick tests on RTEMS.  It was Ron's testing that recently revealed the problems with fast processors.

I thank you a lot for this support.

We are using this support for several different applications here at KEK.

It's working just fine for us. 

My colleague and I recently found that if the firewall was enabled on Linux

(Scientific Linux), invocation to the Linux RPC-library (clnt_call) gets the

IOC process a core dump, for that matter.

Do you have a stack trace you can send to show where the problem is occurring?

-- 

Eric Norum <norume@aps.anl.gov>

Advanced Photon Source                     

Argonne National Laboratory

(630) 252-4793