#94 gpib_config is silently failing on kernel 7.0.0.22

[David Gravereaux]

gpib_config is silently failing to configure my NI PCI-GPIB cards. All behavior ends with ECIC. Please help me debug this. User-space bits installed with 'apt gpib-user-tools libgpib-bin libgpib-dev libgpib0'. kernel parts installed through dkms.

$ dkms status
linux-gpib/4.3.7, 7.0.0-22-generic, x86_64: installed (Original modules exist)

Please help me debug this

[David Gravereaux]

gpib.conf

[David Gravereaux]

/etc/udev/rules.d/

[David Gravereaux]

Everything is ECIC

davygrvy@workbench:~$ ibterm -m 0 -d 25
Attempting to open /dev/gpib0
pad = 25, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000
ibterm>ID?
ibterm error: Unable to write to device at pad 25

• ECIC 1: Board not controller in charge
  ibterm>

[DaveP]

gpib_config is not failing per se.
The status from the nec7210 compatible registers on the tnt4882 chip is not reporting the controller in charge status.

[David Gravereaux]

Could this be a change in kernel 7.0.0.22 some how? I booted the kernel with 'pci=routeirq' in the commandline as I was searching for a possible irq issue, but no change

[David Gravereaux]

I don't know if this means anything, but I changed the board_type in gpib.conf to "ni_pci_accel" as an experiment and my mouse disappeared after gpib_config. It shares the same IRQ.

cat /proc/interrupts |grep gpib
20: 0 0 0 0 843 0 IO-APIC 20-fasteoi ohci_hcd:usb5, ni-pci-gpib

[DaveP]

the ni_pci_accel board type is in every way identical to ni_pci
The mouse disappearing is linked to something else: IRQ 20 is being shared with usb

[David Gravereaux]

Problem solved. It was a bad cable or a bad piece of a test gear at the end of the chain. Please mark this closed/solved