#28 NI-4882 GPIB
The tnt4882 module crashes when it is loaded. It is missing a lot of symbols that seem to be referenced in the nec7210.
I ran dmesg and have the following output.
tnt4882: Unknown symbol readw_wrapper
tnt4882: Unknown symbol nec7210_locking_iomem_read_byte
tnt4882: Unknown symbol nec7210_primary_address
tnt4882: Unknown symbol nec7210_request_system_control
tnt4882: Unknown symbol nec7210_board_reset
tnt4882: Unknown symbol gpib_register_driver
tnt4882: Unknown symbol nec7210_write
tnt4882: Unknown symbol nec7210_disable_eos
tnt4882: Unknown symbol nec7210_secondary_address
tnt4882: Unknown symbol nec7210_take_control
tnt4882: Unknown symbol nec7210_interrupt
tnt4882: Unknown symbol nec7210_board_online
tnt4882: Unknown symbol nec7210_read_data_in
tnt4882: Unknown symbol nec7210_locking_ioport_read_byte
tnt4882: Unknown symbol nec7210_go_to_standby
tnt4882: Unknown symbol nec7210_interface_clear
tnt4882: Unknown symbol nec7210_parallel_poll
tnt4882: Unknown symbol outb_wrapper
tnt4882: Unknown symbol push_gpib_event
tnt4882: Unknown symbol nec7210_parallel_poll_configure
tnt4882: Unknown symbol outw_wrapper
tnt4882: Unknown symbol nec7210_return_to_local
tnt4882: Unknown symbol gpib_unregister_driver
tnt4882: Unknown symbol readb_wrapper
tnt4882: Unknown symbol nec7210_update_status
tnt4882: Unknown symbol nec7210_enable_eos
tnt4882: Unknown symbol nec7210_serial_poll_status
tnt4882: Unknown symbol nec7210_set_handshake_mode
tnt4882: Unknown symbol nec7210_set_reg_bits
tnt4882: Unknown symbol nec7210_remote_enable
tnt4882: Unknown symbol nec7210_command
tnt4882: Unknown symbol nec7210_serial_poll_response
tnt4882: Unknown symbol writeb_wrapper
I have a similar problem. I compiled it for Debian stretch as described in the INSTALL document (btw, the document is out of date, there is no EXTRAVERSION in the Makefile, it auto-detects the kernel version) and tried to load the module. It detects my device, but I get these message when re-booting my system:
ct 4 07:40:13 xps8900 kernel: [ 1240.525625] agilent_82350b: Unknown symbol tms9914_line_status (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.525690] agilent_82350b: Unknown symbol tms9914_iomem_write_byte (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.525754] agilent_82350b: Unknown symbol tms9914_return_to_local (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.525814] agilent_82350b: Unknown symbol tms9914_interrupt_have_status (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.525885] agilent_82350b: Unknown symbol tms9914_set_holdoff_mode (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.525948] agilent_82350b: Unknown symbol tms9914_go_to_standby (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.526022] agilent_82350b: Unknown symbol tms9914_interface_clear (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.526102] agilent_82350b: Unknown symbol gpib_register_driver (err 0)
Oct 4 07:40:13 xps8900 kernel: [ 1240.526170] agilent_82350b: Unknown symbol tms9914_command (err 0)
and lots more of these. lsusb shows this:
Bus 001 Device 002: ID 0957:0518 Agilent Technologies, Inc. 82357B GPIB Interface
I tested it once some time ago on a Raspberry Pi and it worked on this system. Now I wanted to install it on my desktop.
Why was this bug report status changed to "invalid"?
It looks like you hand installed the agilent_82350b module (which is not
the driver for your 82357 btw) rather than doing "make install". The linux
kernel definitely does still have an EXTRAVERSION variable in its Makefile.
On Fri, Oct 4, 2019, 01:46 Frank Buss frankbuss@users.sourceforge.net
wrote:
Related
Bugs:
#28You are right, I thought the EXTRAVERSION was in the gpib Makefile.
This is what I did, after installing the kernel headers on my Debian system:
1. download of the latest released version in the files section, linux-gpib-4.3.0.tar.gz and unpacked it
2. unpacked the contained file linux-gpib-kernel-4.3.0.tar.gz
3. executed "make" (no errors)
4. executed "make install" as root (no errors)
5. rebooted
And then I can see the message I posted above in the kernel.log file. How can I fix it?
As root, what is the output from doing the following?
/sbin/depmod -a
uname -r
On Fri, Oct 4, 2019 at 12:07 PM Frank Buss
frankbuss@users.sourceforge.net wrote:
"/sbin/depmod -a" runs a few seconds, then I'm back at the prompt, no output.
"uname -r" shows this:
4.9.0-9-amd64
Ok, it should be fine then. Try "modprobe agilent_82357a" or reboot.
On Fri, Oct 4, 2019 at 12:30 PM Frank Buss
frankbuss@users.sourceforge.net wrote:
--
Frank
Related
Bugs:
#28Thanks, works now.
For the record, if someone else has problems, these were the steps after the device driver itself was loaded:
The firmware had to be loaded with fxload, twice, and it changes the USB number after a reload. The device path was not available on my system, but it worked with this line (1st call was 010, then 011) :
fxload -t fx2 -D /dev/bus/usb/001/011 -I measat_releaseX1.8.hex
and then calling gpib_conf, after editing the gpib.conf file, which has this content for my adapter:
interface {
minor = 0 / board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. /
board_type = "agilent_82357a" / type of interface board being used /
name = "agilent_82357b"
master = yes /interface board is system controller/
pad = 0 / primary address of interface /
sad = 0 / secondary address of interface /
timeout = T3s / timeout for commands /
eos = 0xa / EOS Byte, 0xa is newline and 0xd is carriage return /
set-reos = yes / Terminate read if EOS /
set-bin = yes / Compare EOS 8-bit /
set-xeos = no / Assert EOI whenever EOS byte is sent /
set-eot = yes / Assert EOI with last byte on writes /
}
Now my Python script is working again. Only for Python 2, but this is ok. Looks like this:
https://github.com/FrankBuss/RPi_LogNut/blob/master/pub/python/Fluke-8842A.py
It is not exactly user friendly to get it working :-)