ni488225L - support SMP kernels, install prefix changeable

[Axel Wachtler]

Hallo,

I recently try to install the package ni488225L on a Red Hat Enterprise Linux AS release 4 (Centos 4.6) with
2.6.9-67.ELsmp kernel.

The background for this question is, that an automatic kickstart installation shall be used. Kickstart runs
a non-smp kernel during the install process but installs a smp kernel, so the INSTALL script runs with
a non-smp kernel and therefore the execution of gpibtsw & Co fails in the running system.

The following questions arise:

a)  Does ni488225L support smp kernels at all or do I have to go with a non-smp kernel
     (similiar to use non-x86_64 kernels on a 64bit PC)?

b) Is there a way to handover the directory of the kernel sources/headers while executing INSTALL.
     (maybe it is  possible to guide INSTALL to the right location of this files).

c) Can the location of /usr/local/natinst be changed within an automatic run of
    "INSTALL --no-prompt --accept-license" ?

Regards, Axel

[Shawn B.]

---

@Axel Wachtler wrote:

a)  Does ni488225L support smp kernels at all or do I have to go with a non-smp kernel
     (similiar to use non-x86_64 kernels on a 64bit PC)?

---

Yes SMP kernels are supported.  If you need 64-bit (x86_64) kernel support, the current released version will not work.  However, we hope to make a Beta version that supports 64-bit kernels available in the near future.

One solution to your problem is to use the "updateNIDrivers" command once you have rebooted into the kernel your plan to run.  updateNIDrivers can also take a kernelVersion if you are not running the kernel you intend to use try "updateNIDrivers --help" for more information.

---

b) Is there a way to handover the directory of the kernel sources/headers while executing INSTALL.
     (maybe it is  possible to guide INSTALL to the right location of this files).

---

Yes.  Try:

KERNELTARGET= <kernelVersion> ./INSTALL

where kernelVersion is what "uname -r" would return from the kernel you which to install the drivers to.

---

c) Can the location of /usr/local/natinst be changed within an automatic run of
    "INSTALL --no-prompt --accept-license" ?

---

I believe the answer is no, since we generally don't allow the changing the location of /usr/local/natinst.  Were you able to change the location of /usr/local/natinst without the "--no-prompt --accept-license" options?

Shawn Bohrer
National Instruments

[Axel Wachtler]

> KERNELTARGET= <kernelVersion> ./INSTALL
Ok, thank you, I'll go to try this.


> I believe the answer is no, since we generally don't allow the changing the location of /usr/local/natinst.  Were you able to change the location of /usr/local/natinst without the
> "--no-prompt  --accept-license" options?

No, you are right, I was not able 🙂 So /usr/local/natinst is in general ok, the only reason I want to have it on a network drive is,
that I build a software that links against libgpibapi.so/ni488.h and therefore it should be on a central place. My solution could be
that I make a non-runable package of the libs and put them in the desired place.

Axel Wachtler

[Axel Wachtler]

The installation with "env KERNELTARGET=<kernelVersion> ./INSTALL" works in KickStart.

Thanks Shawn!!

Here are just some comments about the further testing:
 During operation I encountered trouble with the GPIB USB-HS adapter, which consumes
 400mA, my PC seems to provide only 500mA at all plugs. The result was that gpibtsw run
 fails sporadically in test 3, (behaviour was not predictable, either after reboot, replug in different
 sequences). I moved over to the PCI board, which resolved that problem. In
 the 2nd trial, I'll go to use a PCI USB card in the PC (this is currently in progress).
 In general it would be nice to have a USB-HS device with a extra 5V supply, so that it can
 act "self powered" instead of  "bus powered", because the number of USB enabled equipment
 increases from day to day.