I just got off the phone with a long conference call with two Mercury support engineers. Short answer is I am in the same boat I was in before. Long answer is that many things were tried, and they all boiled down to nothing but locking up my machine. We have found that in a surprising turn of events this sequence causes bad things too:
(On a freshly rebooted system, and ./vxi is a simple program I wrote that uses LPeek to get the translation windows, opens A16 space and looks for LAs and configuration registers to decode -- source code attached, but your web page thinks it's binary!).
[mpercy@msted mpercy]$ cd ~/work/scires/msted/engines/
[mpercy@msted engines]$ configmc -cf test.cfg init
[mpercy@msted engines]$ cd /usr/local/nivxi/sys/
[mpercy@msted sys]$ sudo ./load_vxi
Password:
Warning: The module you have loaded (vxi) does not seem to have a
GPL license. Please send any kernel problem reports to the
author of this module, or duplicate them from a boot without
ever loading this module before reporting them to the community.
[mpercy@msted sys]$ cd ~
[mpercy@msted mpercy]$ ./vxi
VXI_Window::VXI_Window ():108
VXI_Window::VXI_Window ():117
WBSR4 = 0xe900008f WPR4 = 0x00000000
For window 4
WSIZE [WBSR 4:0] = 0x0000000f (65536 65536)
CPU address decode [WBSR 31:8] = 0xe9000000
VXI address decode [WPR 31:8] = 0x00000000
-- LA 0 present.
0000 bff6 [Device Class: Message Based Address Space: A16 Only Vendor ID: ff6]
0002 fec [Required Memory A16 Model Code fec]
0004 600c [A24/A32 Active 0 MODID* 1 DD13-4 2000 READY 1 PASSED 1 DD1-0 0]
0006 0 [Offset 0]
-- LA 1 present.
0000 4ff6 [Device Class: Extended Address Space: A16/A24 Vendor ID: ff6]
0002 90ea [Required Memory 16384 Model Code ea]
0004 fbbc [A24/A32 Active 1 MODID* 1 DD13-4 3bb0 READY 1 PASSED 1 DD1-0 0]
0006 8000 [Offset 80000000]
[mpercy@msted mpercy]$ ./vxi
VXI_Window::VXI_Window ():108
VXI_Window::VXI_Window ():117
WBSR4 = 0xffffffff WPR4 = 0xffffffff
For window 4
WSIZE [WBSR 4:0] = 0x0000001f (1 0)
CPU address decode [WBSR 31:8] = 0x00000000
VXI address decode [WPR 31:8] = 0x00000000
Bus error
[mpercy@msted mpercy]$ lspci -v
[snipped some things]
02:04.0 PCI bridge: Mercury Computer Systems Raceway Bridge (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, slow devsel, latency 132
[virtual] Memory at f8000000 (32-bit, prefetchable) [size=64M]
Memory at ea000000 (32-bit, non-prefetchable) [size=16M]
Bus: primary=fd, secondary=fe, subordinate=fe, sec-latency=0
Memory behind bridge: ea000000-eaffffff
Prefetchable memory behind bridge: f8000000-fbffffff
Expansion ROM at
[disabled] [size=256K]
Capabilities:
[snipped some things]
02:07.0 Bridge: National Instruments: Unknown device a001 (rev 01)
Flags: medium devsel, IRQ 10
[virtual] Memory at e9010000 (32-bit, non-prefetchable) [disabled] [size=32K]
[virtual] Memory at e9000000 (32-bit, non-prefetchable) [disabled] [size=64K]
Expansion ROM at [disabled] [size=2K]
The crictical point here is that the code ran once fine, but a second time kills the system (well, if I ever want VXI access again). I note that lspci tells me that the PCI-MXI-2 card memory is disabled now! I can run my vxi program multiple times without problem if I have never done configmc. If I load the vxi driver first, then run configmc, my vxi program will not work even once.
Does the NIVXI driver module make any assumptions about state of PCI bus configuration that might be invalidated by Mercury's drivers? Does my code (source attached) violate any PCI-MXI-2 interface requirements? Why might my program work fine for many runs, but never more than once if Mercury configuration is run? Are there any debugging flags I could put on the driver?
Since this is obviously and interaction issue, everyone will want to blame everyone else. Meanwhile, I'm stuck. So if there's any insight into what the NIVXI driver is doing and/or assumptions it might make, I can relay them to Mercury to see if they are violating anything.