PCI-4472 not functioning with DAQmx Linux 8.0

[PeterLisherness]

We have multiple systems with PCI-4472 cards in them running SUSE Linux, and all but one of them function properly.  On the particular system in question (which has identical hardware and software to the functioning systems), nilsdev lists no devices.  Further investigation revealed the following excerpt from dmesg:

allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
Unable to handle kernel NULL pointer dereference at virtual address 000002fc
 printing eip:
f9ede608
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: nidsark nistcrk nicdrk nistc2k nimru2k nimxpk ipt_pkttype ipt_LOG ipt_limit nipxirmk nidimk nimsdrk nidmxfk nimxdfk nimstsk nimdbgk niorbk speedstep_lib freq_table nipalk nikal snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device button battery ac af_packet video1394 raw1394 edd ide_cd cdrom sk98lin ohci1394 ieee1394 snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core hw_random generic ehci_hcd intel_agp agpgart uhci_hcd usbcore shpchp pci_hotplug ip6t_REJECT ipt_REJECT ipt_state iptable_mangle iptable_nat iptable_filter ip6table_mangle ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 parport_pc lp parport nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_mod ext3 jbd sg fan thermal processor ata_piix libata piix sd_mod scsi_mod ide_disk ide_core
CPU:    1
EIP:    0060:[<f9ede608>]    Tainted: PF    U VLI
EFLAGS: 00010246   (2.6.13-15-smp)
EIP is at nidsark-unversioned0004550+0x70/0x11e4 [nidsark]
eax: 00000000   ebx: f6be1d68   ecx: 00000000   edx: 00000000
esi: f6514770   edi: f6514760   ebp: f6be1964   esp: f6be1958
ds: 007b   es: 007b   ss: 0068
Process nipalsm (pid: 6952, threadinfo=f6be0000 task=c2344540)
Stack: f6be1d68 f6514b68 f6be1d68 f6be197c f9efb4d0 f6514760 f6be1d68 f6514b68
       f6b82690 f6be1a1c f9e93409 f6514b68 f6be1d68 f6514760 f6be1d68 00000004
       f6be1d6c 00000100 f6be19b8 f95bbf19 f6be1bd0 f6be1d6c f6be1d6c f6be1b98

Assuming that the NULL pointer deference was caused by the preceding failed vmalloc, I attempted to increase the vmalloc size to 512MB (which is certainly overkill).  This did nothing to clear the error.  One final detail is that this computer dual boots Windows, while the others have only ever run Linux.  It shouldn't matter, but I feel it is worth mentioning in the event that DAQmx for Windows somehow mangles the configuration of the card to a point where it no longer functions with DAQmx for Linux.  It should be noted that the card works just fine under Windows.

I have the output from niSystemReport available in the event that it will help in diagnosing the problem, but am unable to attach it due to the size restriction of this forum.  The call trace from dmesg is in the attached file.  Any help would be greatly appreciated.

-Peter Lisherness

Message Edited by PeterLisherness on 07-10-2006 12:36 PM

[lrallen]

Peter,

Please post the niSystemReport for the machine having the problems as well as one for one of the good machines to out ftp server (ftp.ni.com/incoming).  Name them PeterniSystemReportGood and PeterniSystemReportBad.  Thanks and have a great day!

Regards,

lrallen

[PeterLisherness]

Irallen,

    Thanks for responding.  I uploaded the system report for the non-working system, but am unable to post one for a working system right now since they are not under my control.  If the system report from a functioning system is absolutely essential I can try to get it, but it could take a while.

-Peter Lisherness

[lrallen]

Peter,

Thanks!  When you get a chance, could you also post the report for the working system.  This will help us compare the nonworking system to it.  In the mean time, we will continue to investigate.

Regards,

L. Allen

[Shawn B.]

Peter,

I have a couple of other questions which might help us narrow this down.

1.  You said both the working and non working machines have identical hardware and software.  I'm assuming this means both machines are Pentium 4 3.2 GHz SMP machines 2 GB of RAM, have the same motherboards etc.  I also assume that this means that they also are both running SUSE 10.0 and have the same updates, and kernel versions.  Is this correct?  A system report from the working machine could also help us confirm this.

2.  Can you easily reproduce the Oops?  When does it occur?  Does it happen when the machine first boots up, or do you have to run nilsdev first?

Thanks,
Shawn B.