linux-gpib-general — linux-gpib package mailing list

Re: [Linux-gpib-general] Counterfeit NI GPIB-USB-HS half-works?

[Hernán F. <hj...@hj...>]

Hi Dave
thanks. What exactly is the problem though? I've been going through the
code a bit and patched a couple of error messages, regarding these:
[    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
expected 0x2, 0xe, 0xf or 0x16
[    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
expected 0x96, 0x07 or 0x6e

I tested the following sequence with ibtest:

board mode, line status:
gpib status is:
ibsta = 0x178  < CMPL REM CIC ATN TACS >

switch to device mode, write *IDN?
fails and dmesg shows:

ni_usb_gpib: Addressing error retval 0 error code=3

go back to board mode in this situation:
gpib status is:
ibsta = 0x120  < CMPL CIC >

which i guess makes sense because Addressing error
is: NIUSB_ADDRESSING_ERROR occurs when you do a board read/write as CIC but
are not in LACS/TACS

why can't this be made to work with linux-gpib though? trying to understand
if I can patch the driver to make it work.



On Thu, Jun 12, 2025 at 9:06 AM dave penkler <dpe...@gm...> wrote:

> Hi Hernán,
> It looks like you have an unsupported clone. This line in the dmesg is
> relevant:
> [    4.830150] usb 1-1.6: config 1 interface 0 altsetting 0 endpoint 0x81
> has an invalid bInterval 0, changing to 7
> Unfortunately this board cannot be made to work with linux-gpib.
> cheers,
> -Dave
>
> On Wed, 11 Jun 2025 at 22:41, Hernán Freschi <hj...@hj...> wrote:
>
>> Hello. I installed the latest version from master (4c820721), but when
>> trying to use it, it half works, and it does a lot of other weird stuff.
>> I'm using a counterfeit GPIB-USB-HS from eBay (I assume it's counterfeit
>> because it costed $70). The device is not detected as counterfeit by NI
>> drivers on Windows, and works fine there. I can communicate with the GPIB
>> device. But not on Linux. I don't get any prompts to update its firmware
>> either.
>> This is dmesg on a fresh boot:
>>
>> $ sudo dmesg|grep gpib
>> [    4.912608] gpib_common: loading out-of-tree module taints kernel.
>> [    4.912658] gpib_common: module verification failed: signature and/or
>> required key missing - tainting kernel
>> [    4.915244] gpib_common: Linux-GPIB 4.3.7 core driver loaded
>> [    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
>> usb-0000:00:1a.0-1.6
>> [    4.937228] usbcore: registered new interface driver ni_usb_gpib
>> [    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
>> expected 0x2, 0xe, 0xf or 0x16
>> [    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
>> expected 0x96, 0x07 or 0x6e
>> [    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
>> intf 0
>> [  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
>> expected 0x2, 0xe, 0xf or 0x16
>> [  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
>> expected 0x96, 0x07 or 0x6e
>> [  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
>> intf 0
>> also:[    4.717800] usb 1-1.6: new high-speed USB device number 7 using
>> ehci-pci
>> [    4.830150] usb 1-1.6: config 1 interface 0 altsetting 0 endpoint 0x81
>> has an invalid bInterval 0, changing to 7
>> [    4.830649] usb 1-1.6: New USB device found, idVendor=3923,
>> idProduct=709b, bcdDevice= 1.01
>> [    4.830654] usb 1-1.6: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [    4.830657] usb 1-1.6: Product: GPIB-USB-HS
>> [    4.830659] usb 1-1.6: Manufacturer: National Instruments
>> [    4.830660] usb 1-1.6: SerialNumber: 019A335E
>> [    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
>> usb-0000:00:1a.0-1.6
>> [    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
>> expected 0x2, 0xe, 0xf or 0x16
>> [    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
>> expected 0x96, 0x07 or 0x6e
>> [    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
>> intf 0
>> [  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
>> expected 0x2, 0xe, 0xf or 0x16
>> [  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
>> expected 0x96, 0x07 or 0x6e
>> [  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
>> intf 0
>> Here are the issues:
>> 1) It appears my device (HP 34401A) receives the commands, but linux-gpib
>> doesn't get any acknowledgement. The device goes into remote mode if I send
>> *IDN?, but I get an error message
>>
>> : w
>> enter a string to send to your device: *RST
>> sending string: *RST
>>
>> gpib status is:
>> ibsta = 0x8000  < ERR >
>> iberr= 0
>> EDVR 0: OS error
>>
>> ibcntl = 6
>> ..: r
>> enter maximum number of bytes to read [1024]: 199
>> trying to read 199 bytes from device...
>> received string: ''
>> Number of bytes read: 0
>> gpib status is:
>> ibsta = 0xc000  < ERR TIMO >
>> iberr= 6
>> EABO 6: Operation aborted
>>
>> ibcntl = 0
>> this line appears in dmesg:[  164.340630] usb 3-1.6: ni_usb_gpib:
>> Addressing error retval 0 error code=3
>> That's as far as the first issue goes. Then:
>> 2) After some time, it stops working completely. The error message
>> changes to:gpib status is:
>> ibsta = 0x8000  < ERR >
>> iberr= 0
>> EDVR 0: OS error
>>
>> ibcntl = 14and dmesg is flooded with
>> [ 2980.442771] ni_usb_gpib: parse error: wrong start id
>> [ 2980.442775] ni_usb_gpib: parse error: wrong end id
>> [ 2980.442777] ni_usb_gpib: parse error: wrong count=0 for
>> NIUSB_REGISTER_READ_DATA_END
>> [ 2980.442779] ni_usb_gpib: unexpected data: raw_data[6]=0xff, expected 0
>> [ 2980.442781] ni_usb_gpib: unexpected data: raw_data[7]=0xff, expected 0
>> [ 2980.442784] 0c 00 68 00 00 00 ff ff                          ..h.....
>> also, something breaks completely in my computer's USB controller and a
>> reset won't fix it. When it goes into that mode, the computer even refuses
>> to boot when the USB adapter is plugged. The machine needs to be completely
>> turned off for it to work again. When it's in this state, gpib_config won't
>> work even after a reboot, and lsusb hangs if the device is plugged in.
>> Unplugging it and plugging it back in doesn't fix the issue, the computer
>> needs to be powered down.
>> Regards
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

Re: [Linux-gpib-general] Counterfeit NI GPIB-USB-HS half-works?

[dave p. <dpe...@gm...>]

Hi Hernán,
It looks like you have an unsupported clone. This line in the dmesg is
relevant:
[    4.830150] usb 1-1.6: config 1 interface 0 altsetting 0 endpoint 0x81
has an invalid bInterval 0, changing to 7
Unfortunately this board cannot be made to work with linux-gpib.
cheers,
-Dave

On Wed, 11 Jun 2025 at 22:41, Hernán Freschi <hj...@hj...> wrote:

> Hello. I installed the latest version from master (4c820721), but when
> trying to use it, it half works, and it does a lot of other weird stuff.
> I'm using a counterfeit GPIB-USB-HS from eBay (I assume it's counterfeit
> because it costed $70). The device is not detected as counterfeit by NI
> drivers on Windows, and works fine there. I can communicate with the GPIB
> device. But not on Linux. I don't get any prompts to update its firmware
> either.
> This is dmesg on a fresh boot:
>
> $ sudo dmesg|grep gpib
> [    4.912608] gpib_common: loading out-of-tree module taints kernel.
> [    4.912658] gpib_common: module verification failed: signature and/or
> required key missing - tainting kernel
> [    4.915244] gpib_common: Linux-GPIB 4.3.7 core driver loaded
> [    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
> usb-0000:00:1a.0-1.6
> [    4.937228] usbcore: registered new interface driver ni_usb_gpib
> [    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
> expected 0x2, 0xe, 0xf or 0x16
> [    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
> expected 0x96, 0x07 or 0x6e
> [    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
> intf 0
> [  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
> expected 0x2, 0xe, 0xf or 0x16
> [  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
> expected 0x96, 0x07 or 0x6e
> [  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
> intf 0
> also:[    4.717800] usb 1-1.6: new high-speed USB device number 7 using
> ehci-pci
> [    4.830150] usb 1-1.6: config 1 interface 0 altsetting 0 endpoint 0x81
> has an invalid bInterval 0, changing to 7
> [    4.830649] usb 1-1.6: New USB device found, idVendor=3923,
> idProduct=709b, bcdDevice= 1.01
> [    4.830654] usb 1-1.6: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [    4.830657] usb 1-1.6: Product: GPIB-USB-HS
> [    4.830659] usb 1-1.6: Manufacturer: National Instruments
> [    4.830660] usb 1-1.6: SerialNumber: 019A335E
> [    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
> usb-0000:00:1a.0-1.6
> [    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
> expected 0x2, 0xe, 0xf or 0x16
> [    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
> expected 0x96, 0x07 or 0x6e
> [    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
> intf 0
> [  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
> expected 0x2, 0xe, 0xf or 0x16
> [  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
> expected 0x96, 0x07 or 0x6e
> [  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
> intf 0
> Here are the issues:
> 1) It appears my device (HP 34401A) receives the commands, but linux-gpib
> doesn't get any acknowledgement. The device goes into remote mode if I send
> *IDN?, but I get an error message
>
> : w
> enter a string to send to your device: *RST
> sending string: *RST
>
> gpib status is:
> ibsta = 0x8000  < ERR >
> iberr= 0
> EDVR 0: OS error
>
> ibcntl = 6
> ..: r
> enter maximum number of bytes to read [1024]: 199
> trying to read 199 bytes from device...
> received string: ''
> Number of bytes read: 0
> gpib status is:
> ibsta = 0xc000  < ERR TIMO >
> iberr= 6
> EABO 6: Operation aborted
>
> ibcntl = 0
> this line appears in dmesg:[  164.340630] usb 3-1.6: ni_usb_gpib:
> Addressing error retval 0 error code=3
> That's as far as the first issue goes. Then:
> 2) After some time, it stops working completely. The error message changes
> to:gpib status is:
> ibsta = 0x8000  < ERR >
> iberr= 0
> EDVR 0: OS error
>
> ibcntl = 14and dmesg is flooded with
> [ 2980.442771] ni_usb_gpib: parse error: wrong start id
> [ 2980.442775] ni_usb_gpib: parse error: wrong end id
> [ 2980.442777] ni_usb_gpib: parse error: wrong count=0 for
> NIUSB_REGISTER_READ_DATA_END
> [ 2980.442779] ni_usb_gpib: unexpected data: raw_data[6]=0xff, expected 0
> [ 2980.442781] ni_usb_gpib: unexpected data: raw_data[7]=0xff, expected 0
> [ 2980.442784] 0c 00 68 00 00 00 ff ff                          ..h.....
> also, something breaks completely in my computer's USB controller and a
> reset won't fix it. When it goes into that mode, the computer even refuses
> to boot when the USB adapter is plugged. The machine needs to be completely
> turned off for it to work again. When it's in this state, gpib_config won't
> work even after a reboot, and lsusb hangs if the device is plugged in.
> Unplugging it and plugging it back in doesn't fix the issue, the computer
> needs to be powered down.
> Regards
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Counterfeit NI GPIB-USB-HS half-works?

[Hernán F. <hj...@hj...>]

Hello. I installed the latest version from master (4c820721), but when
trying to use it, it half works, and it does a lot of other weird stuff.
I'm using a counterfeit GPIB-USB-HS from eBay (I assume it's counterfeit
because it costed $70). The device is not detected as counterfeit by NI
drivers on Windows, and works fine there. I can communicate with the GPIB
device. But not on Linux. I don't get any prompts to update its firmware
either.
This is dmesg on a fresh boot:

$ sudo dmesg|grep gpib
[    4.912608] gpib_common: loading out-of-tree module taints kernel.
[    4.912658] gpib_common: module verification failed: signature and/or
required key missing - tainting kernel
[    4.915244] gpib_common: Linux-GPIB 4.3.7 core driver loaded
[    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
usb-0000:00:1a.0-1.6
[    4.937228] usbcore: registered new interface driver ni_usb_gpib
[    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
expected 0x2, 0xe, 0xf or 0x16
[    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
expected 0x96, 0x07 or 0x6e
[    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
intf 0
[  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
expected 0x2, 0xe, 0xf or 0x16
[  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
expected 0x96, 0x07 or 0x6e
[  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
intf 0
also:[    4.717800] usb 1-1.6: new high-speed USB device number 7 using
ehci-pci
[    4.830150] usb 1-1.6: config 1 interface 0 altsetting 0 endpoint 0x81
has an invalid bInterval 0, changing to 7
[    4.830649] usb 1-1.6: New USB device found, idVendor=3923,
idProduct=709b, bcdDevice= 1.01
[    4.830654] usb 1-1.6: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    4.830657] usb 1-1.6: Product: GPIB-USB-HS
[    4.830659] usb 1-1.6: Manufacturer: National Instruments
[    4.830660] usb 1-1.6: SerialNumber: 019A335E
[    4.937190] usb 1-1.6: ni_usb_gpib: probe succeeded for path:
usb-0000:00:1a.0-1.6
[    5.317767] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
expected 0x2, 0xe, 0xf or 0x16
[    5.318304] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
expected 0x96, 0x07 or 0x6e
[    5.324141] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
intf 0
[  155.040427] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[6]=0x19,
expected 0x2, 0xe, 0xf or 0x16
[  155.040443] usb 1-1.6: ni_usb_gpib: unexpected data: buffer[10]=0x59,
expected 0x96, 0x07 or 0x6e
[  155.046186] usb 1-1.6: ni_usb_gpib: bus 1 dev num 7 attached to gpib0,
intf 0
Here are the issues:
1) It appears my device (HP 34401A) receives the commands, but linux-gpib
doesn't get any acknowledgement. The device goes into remote mode if I send
*IDN?, but I get an error message

: w
enter a string to send to your device: *RST
sending string: *RST

gpib status is:
ibsta = 0x8000  < ERR >
iberr= 0
EDVR 0: OS error

ibcntl = 6
..: r
enter maximum number of bytes to read [1024]: 199
trying to read 199 bytes from device...
received string: ''
Number of bytes read: 0
gpib status is:
ibsta = 0xc000  < ERR TIMO >
iberr= 6
EABO 6: Operation aborted

ibcntl = 0
this line appears in dmesg:[  164.340630] usb 3-1.6: ni_usb_gpib:
Addressing error retval 0 error code=3
That's as far as the first issue goes. Then:
2) After some time, it stops working completely. The error message changes
to:gpib status is:
ibsta = 0x8000  < ERR >
iberr= 0
EDVR 0: OS error

ibcntl = 14and dmesg is flooded with
[ 2980.442771] ni_usb_gpib: parse error: wrong start id
[ 2980.442775] ni_usb_gpib: parse error: wrong end id
[ 2980.442777] ni_usb_gpib: parse error: wrong count=0 for
NIUSB_REGISTER_READ_DATA_END
[ 2980.442779] ni_usb_gpib: unexpected data: raw_data[6]=0xff, expected 0
[ 2980.442781] ni_usb_gpib: unexpected data: raw_data[7]=0xff, expected 0
[ 2980.442784] 0c 00 68 00 00 00 ff ff                          ..h.....
also, something breaks completely in my computer's USB controller and a
reset won't fix it. When it goes into that mode, the computer even refuses
to boot when the USB adapter is plugged. The machine needs to be completely
turned off for it to work again. When it's in this state, gpib_config won't
work even after a reboot, and lsusb hangs if the device is plugged in.
Unplugging it and plugging it back in doesn't fix the issue, the computer
needs to be powered down.
Regards

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[dave p. <dpe...@gm...>]

Hi Michael,
Are you using the same word width (32 or 64 bit) for both user space and
kernel?
cheers,
-dave

On Wed, 13 Nov 2024, 06:41 Michael Jaggers, <mgj...@gm...> wrote:

> Hey Dave,
>
> The dmesg log I sent is currently using the sourceforge user/kernel
> packages for tag v4_3_6.
> Would you like me to send you the udev script rules? I did change them a
> little bit to debug this issue, but it didn't improve things. It did prove
> that the rules are being enacted (I changed the group and saw that
> reflected in the /dev/gpib* files).
>
> Thanks,
> Michael
>
> On Mon, Nov 11, 2024 at 10:25 PM dave penkler <dpe...@gm...> wrote:
>
>> OK it is hitting EFAULT at the IBONL ioctl gpib_config. To be sure that
>> everything is compatible, you can download, build and install the standard
>> current combined  4.3.6 user and kernel packages from sourceforge
>> <https://sourceforge.net/projects/linux-gpib/files/latest/download> and
>> see if the problem persists. This package supports 6.1.xx kernels. BTW the
>> /dev/gpib* files are set up by the gpib_common module and the access
>> permissions in the  98-gpib-generic.rules udev script, so there should be
>> no problem there.
>> cheers,
>> -Dave
>>
>> On Mon, 11 Nov 2024 at 21:43, Michael Jaggers <mgj...@gm...>
>> wrote:
>>
>>> Yes, there is quite a bit in the console log. I have the debug turned on
>>> (and added some statements in myself), but this is pretty much what happens
>>> when I plug in the device:
>>> [ 9748.976545] usb 1-1.4: new high-speed USB device number 5 using
>>> xhci-hcd
>>> [ 9749.084858] usb 1-1.4: config 1 interface 0 altsetting 0 endpoint
>>> 0x81 has an invalid bInterval 0, changing to 7
>>> [ 9749.095353] usb 1-1.4: New USB device found, idVendor=3923,
>>> idProduct=709b, bcdDevice= 1.01
>>> [ 9749.103769] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [ 9749.111094] usb 1-1.4: Product: GPIB-USB-HS
>>> [ 9749.115289] usb 1-1.4: Manufacturer: National Instruments
>>> [ 9749.120690] usb 1-1.4: SerialNumber: 01D9F4A4
>>> [ 9749.210590] Linux-GPIB 4.3.6 Driver
>>> [ 9749.386255] ni_usb_gpib driver loading
>>> [ 9749.402265] ni_usb_gpib: probe succeeded for path:
>>> usb-xhci-hcd.1.auto-1.4
>>> [ 9749.414241] usbcore: registered new interface driver ni_usb_gpib
>>> [ 9749.423413] gpib: registered ni_usb_b interface
>>> [ 9749.927552] gpib debug: pid 0, gpib: opening minor 0
>>> [ 9749.935625] gpib debug: pid 0, gpib: request module returned 256
>>> [ 9749.942207] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>>> onl=0, arg=f523e908
>>> [ 9749.970918] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>>> onl=0
>>> [ 9749.978472] gpib debug: pid 0, gpib: closing minor 0
>>> [ 9808.492473] gpib debug: pid 0, gpib: opening minor 0
>>> [ 9808.500324] gpib debug: pid 0, gpib: request module returned 256
>>> [ 9808.506433] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>>> onl=0, arg=fb3f8278
>>>
>>> When I try to run "gpib_config", it only shows this line:
>>> [11325.680770] gpib debug: pid 0, gpib: opening minor 0
>>> [11325.688909] gpib debug: pid 0, gpib: request module returned 256
>>> [11325.695036] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>>> onl=0, arg=ef9596d8
>>> [11325.723526] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>>> onl=0
>>> [11325.730940] gpib debug: pid 0, gpib: closing minor 0
>>>
>>> Best Regards,
>>> Michael
>>>
>>> On Mon, Nov 11, 2024 at 1:28 PM dave penkler <dpe...@gm...> wrote:
>>>
>>>> Hi Michael,
>>>> The gpib.conf looks perfect. Somewhere during the configure we are
>>>> getting an EFAULT - Bad address. This would point to some incompatibility
>>>> between user space gpib_config and the gpib_common kernel module. Is there
>>>> anything in the console log (dmesg) ?
>>>> cheers,
>>>> -dave
>>>>
>>>>
>>>>
>>>> On Tue, 12 Nov 2024, 05:28 Michael Jaggers, <mgj...@gm...>
>>>> wrote:
>>>>
>>>>> Hey Dave,
>>>>>
>>>>> I went back and double checked on the configure argument you asked
>>>>> for, and I did provide the path to it. I also checked it by putting a
>>>>> syntax error into the gpib.conf file and that output an error and the path
>>>>> it was pointing to.
>>>>>
>>>>> Here is the conf file that I'm using:
>>>>>
>>>>> /* This section configures the configurable driver characteristics
>>>>>  * for an interface board, such as board address, and interrupt level.
>>>>>  * minor = 0 configures /dev/gpib0, minor = 1 configures /dev/gpib1,
>>>>> etc.
>>>>>  */
>>>>>
>>>>> interface {
>>>>>     minor = 0
>>>>>     board_type = "ni_usb_gpib"
>>>>>     name = "gpib0"
>>>>>     pad = 2
>>>>>     timeout = T1s
>>>>>     eos = 0x0A
>>>>>     set-reos = yes
>>>>>     set-bin = no
>>>>>     master = yes
>>>>>
>>>>> }
>>>>>
>>>>> Thanks!
>>>>> Michael
>>>>>
>>>>> On Sat, Nov 9, 2024 at 2:24 AM dave penkler <dpe...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi Michael,
>>>>>> It looks like a gpib.conf problem. Did you provide a sysconfdir
>>>>>> argument to .configure ?
>>>>>> Please send me your gpib.conf file.
>>>>>> cheers,
>>>>>> -dave
>>>>>>
>>>>>> On Sat, 9 Nov 2024, 04:38 Michael Jaggers, <mgj...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Dave,
>>>>>>>
>>>>>>> I've run the gpib_config, but no luck on that end. Here is what
>>>>>>> happens to me:
>>>>>>> 1. First, I restart the device without plugging in the gpib (drivers
>>>>>>> aren't loaded).
>>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>>> failed to open device file '/dev/gpib0'
>>>>>>> main: No such file or directory
>>>>>>>
>>>>>>> 2. Now, I plug the gpib dongle in.
>>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>>> failed to bring board offline
>>>>>>> failed to configure board
>>>>>>> main: Bad address
>>>>>>>
>>>>>>> 3. Finally, I unplug the gpib dongle.
>>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>>> failed to bring board offline
>>>>>>> failed to configure board
>>>>>>> main: Bad address
>>>>>>>
>>>>>>> To me, this looks like the dongle isn't attaching to /dev/gpib0. I
>>>>>>> know the driver recognizes the device, it correctly starts the ni_usb_gpib
>>>>>>> driver, and probes the correct location on the device tree, and the driver
>>>>>>> in the device tree points to the correct place the dongle is attached to.
>>>>>>> What's got me scratching my head is why it's not attached to gpib0 (or even
>>>>>>> how to circumvent the need to attach to gpib0).
>>>>>>>
>>>>>>> Could it be related to my udev? In the rules, in file
>>>>>>> "/etc/udev/rules.d/98-gpib-generic.rules" I added:
>>>>>>> ACTION=="add|change",
>>>>>>> DEVPATH=="/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0",
>>>>>>> ENV{GPIB_CONFIG_OPTIONS}="--minor 0"
>>>>>>>
>>>>>>> That's the path that udev recognizes. When I run udevadm monitor, I
>>>>>>> get this after plugging in the dongle:
>>>>>>> KERNEL[1122.600699] add
>>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>>> (usb)
>>>>>>> KERNEL[1122.650504] add
>>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>>> (usb)
>>>>>>> KERNEL[1122.671551] bind
>>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>>> (usb)
>>>>>>> KERNEL[1122.671684] bind
>>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>>> (usb)
>>>>>>> UDEV  [1122.676333] add
>>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>>> (usb)
>>>>>>> UDEV  [1122.769461] add
>>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>>> (usb)
>>>>>>> UDEV  [1122.772939] bind
>>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>>> (usb)
>>>>>>> UDEV  [1122.777553] bind
>>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>>> (usb)
>>>>>>>
>>>>>>> Could the version of udev be the cause?
>>>>>>> root@tester0:~/git/linux-gpib-git# udevd --version
>>>>>>> 251.8+
>>>>>>> root@tester0:~/git/linux-gpib-git# udevadm --version
>>>>>>> 251
>>>>>>>
>>>>>>> Thanks for your responses!
>>>>>>> Michael
>>>>>>>
>>>>>>> On Thu, Nov 7, 2024 at 9:04 PM dave penkler <dpe...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It looks like the board is not attached. Did you run # gpib_config
>>>>>>>> ? Normally the supplied udev scripts do this for you.
>>>>>>>> cheers,
>>>>>>>> -dave
>>>>>>>>
>>>>>>>> On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:
>>>>>>>>
>>>>>>>>> Setting up the /dev/gpib* devices is something that
>>>>>>>>> you might want to look at udev for...but as I recall
>>>>>>>>> there's some problems. That isn't necessarily in the
>>>>>>>>> linux-gpib git project, maybe in linux-gpib-packaging
>>>>>>>>> project....where the idea is to wrap the linux-gpib
>>>>>>>>> code in an rpm package (so that installation deals
>>>>>>>>> with udev scripts, protection issues, etc)
>>>>>>>>>
>>>>>>>>> On Thu, 7 Nov 2024 09:51:32 -0700
>>>>>>>>> Michael Jaggers <mgj...@gm...> wrote:
>>>>>>>>>
>>>>>>>>> > Hello,
>>>>>>>>> >
>>>>>>>>> > I'm working on installing the gpib kernel drivers to the
>>>>>>>>> Petalinux
>>>>>>>>> > platform. So far, I've managed to get the headers and get the
>>>>>>>>> gpib
>>>>>>>>> > drivers compiled + installed. The modules show up with modprobe,
>>>>>>>>> and
>>>>>>>>> > when I plug my gpib dongle in the driver loads properly and it
>>>>>>>>> seems
>>>>>>>>> > to recognize it. Below is the message I get when plugging in the
>>>>>>>>> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device
>>>>>>>>> number 11
>>>>>>>>> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
>>>>>>>>> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing
>>>>>>>>> to 7
>>>>>>>>> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
>>>>>>>>> > idProduct=709b, bcdDevice= 1.01
>>>>>>>>> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1,
>>>>>>>>> Product=2,
>>>>>>>>> > SerialNumber=3
>>>>>>>>> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
>>>>>>>>> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
>>>>>>>>> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
>>>>>>>>> >
>>>>>>>>> > Here is where the issue comes up. When ibopen goes to set things
>>>>>>>>> up
>>>>>>>>> > with the dongle, the /dev/gpib0 doesn't seem to be properly
>>>>>>>>> > configured. I get this message when I run the ibtest utility:
>>>>>>>>> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
>>>>>>>>> > [84391.696029] gpib debug: pid 0, gpib: request module returned
>>>>>>>>> 256
>>>>>>>>> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>>>> use=0,
>>>>>>>>> > onl=0, arg=d8a171a0
>>>>>>>>> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
>>>>>>>>> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>>>> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>>>> > interface=, use=0, onl=0, arg=d8a17120
>>>>>>>>> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
>>>>>>>>> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>>>> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>>>> > interface=, use=0, onl=0, arg=d8a17180
>>>>>>>>> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
>>>>>>>>> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>>>> > use=0, onl=0 [84391.762675] audit: type=1701
>>>>>>>>> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
>>>>>>>>> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1
>>>>>>>>> [84391.764574]
>>>>>>>>> > gpib debug: pid 0, gpib: closing minor 0
>>>>>>>>> >
>>>>>>>>> > I've been debugging this for a week or so now. I'm fairly
>>>>>>>>> confident
>>>>>>>>> > that the probing of the dongle works. In fact, when I find the
>>>>>>>>> dongle
>>>>>>>>> > in the sys path, I see that the module driver is in that path of
>>>>>>>>> the
>>>>>>>>> > device itself: root@tester0:~# ls -ll
>>>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
>>>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
>>>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
>>>>>>>>> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
>>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
>>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
>>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
>>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
>>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
>>>>>>>>> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
>>>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
>>>>>>>>> > ../../../../../../../../../../bus/usb
>>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
>>>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
>>>>>>>>> >
>>>>>>>>> > root@tester0:~# grep ^
>>>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
>>>>>>>>> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
>>>>>>>>> >
>>>>>>>>> > The driver itself tells me that the interface registers properly
>>>>>>>>> too
>>>>>>>>> > (my apologies for the extra debug messages):
>>>>>>>>> > [85375.091233] ni_usb_gpib driver loading
>>>>>>>>> > [85375.098301] ni_usb_driver_probe
>>>>>>>>> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
>>>>>>>>> > [85375.107200] ni_usb_gpib: probe succeeded for path:
>>>>>>>>> > usb-xhci-hcd.1.auto-1.4
>>>>>>>>> > [85375.119145] usbcore: registered new interface driver
>>>>>>>>> ni_usb_gpib
>>>>>>>>> > [85375.128308] gpib: registered ni_usb_b interface
>>>>>>>>> >
>>>>>>>>> > However, everywhere I look in the code doesn't indicate to me
>>>>>>>>> where
>>>>>>>>> > the disconnect occurs. I'm fairly certain the issue is that the
>>>>>>>>> > /dev/gpib* section isn't pointing to the dongle area and that's
>>>>>>>>> my
>>>>>>>>> > problem. I've been trying to create a workaround to this that
>>>>>>>>> shows
>>>>>>>>> > the device working at all, but I'm not having any luck there.
>>>>>>>>> > So I'm at a loss for where to go next. Any suggestions? RIght
>>>>>>>>> now, I'm
>>>>>>>>> > trying to figure out why I'm getting "interface=". I feel like
>>>>>>>>> that's
>>>>>>>>> > the underlying problem, but I can't confirm it.
>>>>>>>>> > Just in case, here is some extra information about he system I'm
>>>>>>>>> on:
>>>>>>>>> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>>>>>>>>> >           Kernel: Linux 6.1.30-xilinx-v2023.2
>>>>>>>>> >     Architecture: arm64
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
>>>>>>>>> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
>>>>>>>>> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
>>>>>>>>> la...@dc...                    －​μ+－－+νν                 |E
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-gpib-general mailing list
>>>>>>>>> Lin...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-gpib-general mailing list
>>>>>>>> Lin...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>>>
>>>>>>>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[Michael J. <mgj...@gm...>]

Hey Dave,

The dmesg log I sent is currently using the sourceforge user/kernel
packages for tag v4_3_6.
Would you like me to send you the udev script rules? I did change them a
little bit to debug this issue, but it didn't improve things. It did prove
that the rules are being enacted (I changed the group and saw that
reflected in the /dev/gpib* files).

Thanks,
Michael

On Mon, Nov 11, 2024 at 10:25 PM dave penkler <dpe...@gm...> wrote:

> OK it is hitting EFAULT at the IBONL ioctl gpib_config. To be sure that
> everything is compatible, you can download, build and install the standard
> current combined  4.3.6 user and kernel packages from sourceforge
> <https://sourceforge.net/projects/linux-gpib/files/latest/download> and
> see if the problem persists. This package supports 6.1.xx kernels. BTW the
> /dev/gpib* files are set up by the gpib_common module and the access
> permissions in the  98-gpib-generic.rules udev script, so there should be
> no problem there.
> cheers,
> -Dave
>
> On Mon, 11 Nov 2024 at 21:43, Michael Jaggers <mgj...@gm...> wrote:
>
>> Yes, there is quite a bit in the console log. I have the debug turned on
>> (and added some statements in myself), but this is pretty much what happens
>> when I plug in the device:
>> [ 9748.976545] usb 1-1.4: new high-speed USB device number 5 using
>> xhci-hcd
>> [ 9749.084858] usb 1-1.4: config 1 interface 0 altsetting 0 endpoint 0x81
>> has an invalid bInterval 0, changing to 7
>> [ 9749.095353] usb 1-1.4: New USB device found, idVendor=3923,
>> idProduct=709b, bcdDevice= 1.01
>> [ 9749.103769] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [ 9749.111094] usb 1-1.4: Product: GPIB-USB-HS
>> [ 9749.115289] usb 1-1.4: Manufacturer: National Instruments
>> [ 9749.120690] usb 1-1.4: SerialNumber: 01D9F4A4
>> [ 9749.210590] Linux-GPIB 4.3.6 Driver
>> [ 9749.386255] ni_usb_gpib driver loading
>> [ 9749.402265] ni_usb_gpib: probe succeeded for path:
>> usb-xhci-hcd.1.auto-1.4
>> [ 9749.414241] usbcore: registered new interface driver ni_usb_gpib
>> [ 9749.423413] gpib: registered ni_usb_b interface
>> [ 9749.927552] gpib debug: pid 0, gpib: opening minor 0
>> [ 9749.935625] gpib debug: pid 0, gpib: request module returned 256
>> [ 9749.942207] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>> onl=0, arg=f523e908
>> [ 9749.970918] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>> onl=0
>> [ 9749.978472] gpib debug: pid 0, gpib: closing minor 0
>> [ 9808.492473] gpib debug: pid 0, gpib: opening minor 0
>> [ 9808.500324] gpib debug: pid 0, gpib: request module returned 256
>> [ 9808.506433] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>> onl=0, arg=fb3f8278
>>
>> When I try to run "gpib_config", it only shows this line:
>> [11325.680770] gpib debug: pid 0, gpib: opening minor 0
>> [11325.688909] gpib debug: pid 0, gpib: request module returned 256
>> [11325.695036] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>> onl=0, arg=ef9596d8
>> [11325.723526] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
>> onl=0
>> [11325.730940] gpib debug: pid 0, gpib: closing minor 0
>>
>> Best Regards,
>> Michael
>>
>> On Mon, Nov 11, 2024 at 1:28 PM dave penkler <dpe...@gm...> wrote:
>>
>>> Hi Michael,
>>> The gpib.conf looks perfect. Somewhere during the configure we are
>>> getting an EFAULT - Bad address. This would point to some incompatibility
>>> between user space gpib_config and the gpib_common kernel module. Is there
>>> anything in the console log (dmesg) ?
>>> cheers,
>>> -dave
>>>
>>>
>>>
>>> On Tue, 12 Nov 2024, 05:28 Michael Jaggers, <mgj...@gm...> wrote:
>>>
>>>> Hey Dave,
>>>>
>>>> I went back and double checked on the configure argument you asked for,
>>>> and I did provide the path to it. I also checked it by putting a syntax
>>>> error into the gpib.conf file and that output an error and the path it was
>>>> pointing to.
>>>>
>>>> Here is the conf file that I'm using:
>>>>
>>>> /* This section configures the configurable driver characteristics
>>>>  * for an interface board, such as board address, and interrupt level.
>>>>  * minor = 0 configures /dev/gpib0, minor = 1 configures /dev/gpib1,
>>>> etc.
>>>>  */
>>>>
>>>> interface {
>>>>     minor = 0
>>>>     board_type = "ni_usb_gpib"
>>>>     name = "gpib0"
>>>>     pad = 2
>>>>     timeout = T1s
>>>>     eos = 0x0A
>>>>     set-reos = yes
>>>>     set-bin = no
>>>>     master = yes
>>>>
>>>> }
>>>>
>>>> Thanks!
>>>> Michael
>>>>
>>>> On Sat, Nov 9, 2024 at 2:24 AM dave penkler <dpe...@gm...> wrote:
>>>>
>>>>> Hi Michael,
>>>>> It looks like a gpib.conf problem. Did you provide a sysconfdir
>>>>> argument to .configure ?
>>>>> Please send me your gpib.conf file.
>>>>> cheers,
>>>>> -dave
>>>>>
>>>>> On Sat, 9 Nov 2024, 04:38 Michael Jaggers, <mgj...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Dave,
>>>>>>
>>>>>> I've run the gpib_config, but no luck on that end. Here is what
>>>>>> happens to me:
>>>>>> 1. First, I restart the device without plugging in the gpib (drivers
>>>>>> aren't loaded).
>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>> failed to open device file '/dev/gpib0'
>>>>>> main: No such file or directory
>>>>>>
>>>>>> 2. Now, I plug the gpib dongle in.
>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>> failed to bring board offline
>>>>>> failed to configure board
>>>>>> main: Bad address
>>>>>>
>>>>>> 3. Finally, I unplug the gpib dongle.
>>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>>> failed to bring board offline
>>>>>> failed to configure board
>>>>>> main: Bad address
>>>>>>
>>>>>> To me, this looks like the dongle isn't attaching to /dev/gpib0. I
>>>>>> know the driver recognizes the device, it correctly starts the ni_usb_gpib
>>>>>> driver, and probes the correct location on the device tree, and the driver
>>>>>> in the device tree points to the correct place the dongle is attached to.
>>>>>> What's got me scratching my head is why it's not attached to gpib0 (or even
>>>>>> how to circumvent the need to attach to gpib0).
>>>>>>
>>>>>> Could it be related to my udev? In the rules, in file
>>>>>> "/etc/udev/rules.d/98-gpib-generic.rules" I added:
>>>>>> ACTION=="add|change",
>>>>>> DEVPATH=="/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0",
>>>>>> ENV{GPIB_CONFIG_OPTIONS}="--minor 0"
>>>>>>
>>>>>> That's the path that udev recognizes. When I run udevadm monitor, I
>>>>>> get this after plugging in the dongle:
>>>>>> KERNEL[1122.600699] add
>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>> (usb)
>>>>>> KERNEL[1122.650504] add
>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>> (usb)
>>>>>> KERNEL[1122.671551] bind
>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>> (usb)
>>>>>> KERNEL[1122.671684] bind
>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>> (usb)
>>>>>> UDEV  [1122.676333] add
>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>> (usb)
>>>>>> UDEV  [1122.769461] add
>>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>> (usb)
>>>>>> UDEV  [1122.772939] bind
>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>>> (usb)
>>>>>> UDEV  [1122.777553] bind
>>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>>> (usb)
>>>>>>
>>>>>> Could the version of udev be the cause?
>>>>>> root@tester0:~/git/linux-gpib-git# udevd --version
>>>>>> 251.8+
>>>>>> root@tester0:~/git/linux-gpib-git# udevadm --version
>>>>>> 251
>>>>>>
>>>>>> Thanks for your responses!
>>>>>> Michael
>>>>>>
>>>>>> On Thu, Nov 7, 2024 at 9:04 PM dave penkler <dpe...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> It looks like the board is not attached. Did you run # gpib_config ?
>>>>>>> Normally the supplied udev scripts do this for you.
>>>>>>> cheers,
>>>>>>> -dave
>>>>>>>
>>>>>>> On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:
>>>>>>>
>>>>>>>> Setting up the /dev/gpib* devices is something that
>>>>>>>> you might want to look at udev for...but as I recall
>>>>>>>> there's some problems. That isn't necessarily in the
>>>>>>>> linux-gpib git project, maybe in linux-gpib-packaging
>>>>>>>> project....where the idea is to wrap the linux-gpib
>>>>>>>> code in an rpm package (so that installation deals
>>>>>>>> with udev scripts, protection issues, etc)
>>>>>>>>
>>>>>>>> On Thu, 7 Nov 2024 09:51:32 -0700
>>>>>>>> Michael Jaggers <mgj...@gm...> wrote:
>>>>>>>>
>>>>>>>> > Hello,
>>>>>>>> >
>>>>>>>> > I'm working on installing the gpib kernel drivers to the Petalinux
>>>>>>>> > platform. So far, I've managed to get the headers and get the gpib
>>>>>>>> > drivers compiled + installed. The modules show up with modprobe,
>>>>>>>> and
>>>>>>>> > when I plug my gpib dongle in the driver loads properly and it
>>>>>>>> seems
>>>>>>>> > to recognize it. Below is the message I get when plugging in the
>>>>>>>> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device
>>>>>>>> number 11
>>>>>>>> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
>>>>>>>> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing
>>>>>>>> to 7
>>>>>>>> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
>>>>>>>> > idProduct=709b, bcdDevice= 1.01
>>>>>>>> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1,
>>>>>>>> Product=2,
>>>>>>>> > SerialNumber=3
>>>>>>>> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
>>>>>>>> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
>>>>>>>> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
>>>>>>>> >
>>>>>>>> > Here is where the issue comes up. When ibopen goes to set things
>>>>>>>> up
>>>>>>>> > with the dongle, the /dev/gpib0 doesn't seem to be properly
>>>>>>>> > configured. I get this message when I run the ibtest utility:
>>>>>>>> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
>>>>>>>> > [84391.696029] gpib debug: pid 0, gpib: request module returned
>>>>>>>> 256
>>>>>>>> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>>> use=0,
>>>>>>>> > onl=0, arg=d8a171a0
>>>>>>>> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
>>>>>>>> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>>> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>>> > interface=, use=0, onl=0, arg=d8a17120
>>>>>>>> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
>>>>>>>> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>>> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>>> > interface=, use=0, onl=0, arg=d8a17180
>>>>>>>> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
>>>>>>>> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>>> > use=0, onl=0 [84391.762675] audit: type=1701
>>>>>>>> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
>>>>>>>> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1
>>>>>>>> [84391.764574]
>>>>>>>> > gpib debug: pid 0, gpib: closing minor 0
>>>>>>>> >
>>>>>>>> > I've been debugging this for a week or so now. I'm fairly
>>>>>>>> confident
>>>>>>>> > that the probing of the dongle works. In fact, when I find the
>>>>>>>> dongle
>>>>>>>> > in the sys path, I see that the module driver is in that path of
>>>>>>>> the
>>>>>>>> > device itself: root@tester0:~# ls -ll
>>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
>>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
>>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
>>>>>>>> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
>>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
>>>>>>>> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
>>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
>>>>>>>> > ../../../../../../../../../../bus/usb
>>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
>>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
>>>>>>>> >
>>>>>>>> > root@tester0:~# grep ^
>>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
>>>>>>>> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
>>>>>>>> >
>>>>>>>> > The driver itself tells me that the interface registers properly
>>>>>>>> too
>>>>>>>> > (my apologies for the extra debug messages):
>>>>>>>> > [85375.091233] ni_usb_gpib driver loading
>>>>>>>> > [85375.098301] ni_usb_driver_probe
>>>>>>>> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
>>>>>>>> > [85375.107200] ni_usb_gpib: probe succeeded for path:
>>>>>>>> > usb-xhci-hcd.1.auto-1.4
>>>>>>>> > [85375.119145] usbcore: registered new interface driver
>>>>>>>> ni_usb_gpib
>>>>>>>> > [85375.128308] gpib: registered ni_usb_b interface
>>>>>>>> >
>>>>>>>> > However, everywhere I look in the code doesn't indicate to me
>>>>>>>> where
>>>>>>>> > the disconnect occurs. I'm fairly certain the issue is that the
>>>>>>>> > /dev/gpib* section isn't pointing to the dongle area and that's my
>>>>>>>> > problem. I've been trying to create a workaround to this that
>>>>>>>> shows
>>>>>>>> > the device working at all, but I'm not having any luck there.
>>>>>>>> > So I'm at a loss for where to go next. Any suggestions? RIght
>>>>>>>> now, I'm
>>>>>>>> > trying to figure out why I'm getting "interface=". I feel like
>>>>>>>> that's
>>>>>>>> > the underlying problem, but I can't confirm it.
>>>>>>>> > Just in case, here is some extra information about he system I'm
>>>>>>>> on:
>>>>>>>> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>>>>>>>> >           Kernel: Linux 6.1.30-xilinx-v2023.2
>>>>>>>> >     Architecture: arm64
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
>>>>>>>> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
>>>>>>>> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
>>>>>>>> la...@dc...                    －​μ+－－+νν                 |E
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-gpib-general mailing list
>>>>>>>> Lin...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-gpib-general mailing list
>>>>>>> Lin...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>>
>>>>>>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[dave p. <dpe...@gm...>]

OK it is hitting EFAULT at the IBONL ioctl gpib_config. To be sure that
everything is compatible, you can download, build and install the standard
current combined  4.3.6 user and kernel packages from sourceforge
<https://sourceforge.net/projects/linux-gpib/files/latest/download> and see
if the problem persists. This package supports 6.1.xx kernels. BTW the
/dev/gpib* files are set up by the gpib_common module and the access
permissions in the  98-gpib-generic.rules udev script, so there should be
no problem there.
cheers,
-Dave

On Mon, 11 Nov 2024 at 21:43, Michael Jaggers <mgj...@gm...> wrote:

> Yes, there is quite a bit in the console log. I have the debug turned on
> (and added some statements in myself), but this is pretty much what happens
> when I plug in the device:
> [ 9748.976545] usb 1-1.4: new high-speed USB device number 5 using xhci-hcd
> [ 9749.084858] usb 1-1.4: config 1 interface 0 altsetting 0 endpoint 0x81
> has an invalid bInterval 0, changing to 7
> [ 9749.095353] usb 1-1.4: New USB device found, idVendor=3923,
> idProduct=709b, bcdDevice= 1.01
> [ 9749.103769] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 9749.111094] usb 1-1.4: Product: GPIB-USB-HS
> [ 9749.115289] usb 1-1.4: Manufacturer: National Instruments
> [ 9749.120690] usb 1-1.4: SerialNumber: 01D9F4A4
> [ 9749.210590] Linux-GPIB 4.3.6 Driver
> [ 9749.386255] ni_usb_gpib driver loading
> [ 9749.402265] ni_usb_gpib: probe succeeded for path:
> usb-xhci-hcd.1.auto-1.4
> [ 9749.414241] usbcore: registered new interface driver ni_usb_gpib
> [ 9749.423413] gpib: registered ni_usb_b interface
> [ 9749.927552] gpib debug: pid 0, gpib: opening minor 0
> [ 9749.935625] gpib debug: pid 0, gpib: request module returned 256
> [ 9749.942207] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
> onl=0, arg=f523e908
> [ 9749.970918] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
> onl=0
> [ 9749.978472] gpib debug: pid 0, gpib: closing minor 0
> [ 9808.492473] gpib debug: pid 0, gpib: opening minor 0
> [ 9808.500324] gpib debug: pid 0, gpib: request module returned 256
> [ 9808.506433] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
> onl=0, arg=fb3f8278
>
> When I try to run "gpib_config", it only shows this line:
> [11325.680770] gpib debug: pid 0, gpib: opening minor 0
> [11325.688909] gpib debug: pid 0, gpib: request module returned 256
> [11325.695036] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
> onl=0, arg=ef9596d8
> [11325.723526] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
> onl=0
> [11325.730940] gpib debug: pid 0, gpib: closing minor 0
>
> Best Regards,
> Michael
>
> On Mon, Nov 11, 2024 at 1:28 PM dave penkler <dpe...@gm...> wrote:
>
>> Hi Michael,
>> The gpib.conf looks perfect. Somewhere during the configure we are
>> getting an EFAULT - Bad address. This would point to some incompatibility
>> between user space gpib_config and the gpib_common kernel module. Is there
>> anything in the console log (dmesg) ?
>> cheers,
>> -dave
>>
>>
>>
>> On Tue, 12 Nov 2024, 05:28 Michael Jaggers, <mgj...@gm...> wrote:
>>
>>> Hey Dave,
>>>
>>> I went back and double checked on the configure argument you asked for,
>>> and I did provide the path to it. I also checked it by putting a syntax
>>> error into the gpib.conf file and that output an error and the path it was
>>> pointing to.
>>>
>>> Here is the conf file that I'm using:
>>>
>>> /* This section configures the configurable driver characteristics
>>>  * for an interface board, such as board address, and interrupt level.
>>>  * minor = 0 configures /dev/gpib0, minor = 1 configures /dev/gpib1,
>>> etc.
>>>  */
>>>
>>> interface {
>>>     minor = 0
>>>     board_type = "ni_usb_gpib"
>>>     name = "gpib0"
>>>     pad = 2
>>>     timeout = T1s
>>>     eos = 0x0A
>>>     set-reos = yes
>>>     set-bin = no
>>>     master = yes
>>>
>>> }
>>>
>>> Thanks!
>>> Michael
>>>
>>> On Sat, Nov 9, 2024 at 2:24 AM dave penkler <dpe...@gm...> wrote:
>>>
>>>> Hi Michael,
>>>> It looks like a gpib.conf problem. Did you provide a sysconfdir
>>>> argument to .configure ?
>>>> Please send me your gpib.conf file.
>>>> cheers,
>>>> -dave
>>>>
>>>> On Sat, 9 Nov 2024, 04:38 Michael Jaggers, <mgj...@gm...> wrote:
>>>>
>>>>> Dave,
>>>>>
>>>>> I've run the gpib_config, but no luck on that end. Here is what
>>>>> happens to me:
>>>>> 1. First, I restart the device without plugging in the gpib (drivers
>>>>> aren't loaded).
>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>> failed to open device file '/dev/gpib0'
>>>>> main: No such file or directory
>>>>>
>>>>> 2. Now, I plug the gpib dongle in.
>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>> failed to bring board offline
>>>>> failed to configure board
>>>>> main: Bad address
>>>>>
>>>>> 3. Finally, I unplug the gpib dongle.
>>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>>> failed to bring board offline
>>>>> failed to configure board
>>>>> main: Bad address
>>>>>
>>>>> To me, this looks like the dongle isn't attaching to /dev/gpib0. I
>>>>> know the driver recognizes the device, it correctly starts the ni_usb_gpib
>>>>> driver, and probes the correct location on the device tree, and the driver
>>>>> in the device tree points to the correct place the dongle is attached to.
>>>>> What's got me scratching my head is why it's not attached to gpib0 (or even
>>>>> how to circumvent the need to attach to gpib0).
>>>>>
>>>>> Could it be related to my udev? In the rules, in file
>>>>> "/etc/udev/rules.d/98-gpib-generic.rules" I added:
>>>>> ACTION=="add|change",
>>>>> DEVPATH=="/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0",
>>>>> ENV{GPIB_CONFIG_OPTIONS}="--minor 0"
>>>>>
>>>>> That's the path that udev recognizes. When I run udevadm monitor, I
>>>>> get this after plugging in the dongle:
>>>>> KERNEL[1122.600699] add
>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>> (usb)
>>>>> KERNEL[1122.650504] add
>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>> (usb)
>>>>> KERNEL[1122.671551] bind
>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>> (usb)
>>>>> KERNEL[1122.671684] bind
>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>> (usb)
>>>>> UDEV  [1122.676333] add
>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>> (usb)
>>>>> UDEV  [1122.769461] add
>>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>> (usb)
>>>>> UDEV  [1122.772939] bind
>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>>> (usb)
>>>>> UDEV  [1122.777553] bind
>>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>>> (usb)
>>>>>
>>>>> Could the version of udev be the cause?
>>>>> root@tester0:~/git/linux-gpib-git# udevd --version
>>>>> 251.8+
>>>>> root@tester0:~/git/linux-gpib-git# udevadm --version
>>>>> 251
>>>>>
>>>>> Thanks for your responses!
>>>>> Michael
>>>>>
>>>>> On Thu, Nov 7, 2024 at 9:04 PM dave penkler <dpe...@gm...>
>>>>> wrote:
>>>>>
>>>>>> It looks like the board is not attached. Did you run # gpib_config ?
>>>>>> Normally the supplied udev scripts do this for you.
>>>>>> cheers,
>>>>>> -dave
>>>>>>
>>>>>> On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:
>>>>>>
>>>>>>> Setting up the /dev/gpib* devices is something that
>>>>>>> you might want to look at udev for...but as I recall
>>>>>>> there's some problems. That isn't necessarily in the
>>>>>>> linux-gpib git project, maybe in linux-gpib-packaging
>>>>>>> project....where the idea is to wrap the linux-gpib
>>>>>>> code in an rpm package (so that installation deals
>>>>>>> with udev scripts, protection issues, etc)
>>>>>>>
>>>>>>> On Thu, 7 Nov 2024 09:51:32 -0700
>>>>>>> Michael Jaggers <mgj...@gm...> wrote:
>>>>>>>
>>>>>>> > Hello,
>>>>>>> >
>>>>>>> > I'm working on installing the gpib kernel drivers to the Petalinux
>>>>>>> > platform. So far, I've managed to get the headers and get the gpib
>>>>>>> > drivers compiled + installed. The modules show up with modprobe,
>>>>>>> and
>>>>>>> > when I plug my gpib dongle in the driver loads properly and it
>>>>>>> seems
>>>>>>> > to recognize it. Below is the message I get when plugging in the
>>>>>>> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device number
>>>>>>> 11
>>>>>>> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
>>>>>>> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to
>>>>>>> 7
>>>>>>> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
>>>>>>> > idProduct=709b, bcdDevice= 1.01
>>>>>>> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>>>>>>> > SerialNumber=3
>>>>>>> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
>>>>>>> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
>>>>>>> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
>>>>>>> >
>>>>>>> > Here is where the issue comes up. When ibopen goes to set things up
>>>>>>> > with the dongle, the /dev/gpib0 doesn't seem to be properly
>>>>>>> > configured. I get this message when I run the ibtest utility:
>>>>>>> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
>>>>>>> > [84391.696029] gpib debug: pid 0, gpib: request module returned 256
>>>>>>> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>> use=0,
>>>>>>> > onl=0, arg=d8a171a0
>>>>>>> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
>>>>>>> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>>> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>> > interface=, use=0, onl=0, arg=d8a17120
>>>>>>> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
>>>>>>> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>>> > interface=, use=0, onl=0, arg=d8a17180
>>>>>>> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
>>>>>>> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>>> > use=0, onl=0 [84391.762675] audit: type=1701
>>>>>>> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
>>>>>>> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1
>>>>>>> [84391.764574]
>>>>>>> > gpib debug: pid 0, gpib: closing minor 0
>>>>>>> >
>>>>>>> > I've been debugging this for a week or so now. I'm fairly confident
>>>>>>> > that the probing of the dongle works. In fact, when I find the
>>>>>>> dongle
>>>>>>> > in the sys path, I see that the module driver is in that path of
>>>>>>> the
>>>>>>> > device itself: root@tester0:~# ls -ll
>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
>>>>>>> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
>>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
>>>>>>> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
>>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
>>>>>>> > ../../../../../../../../../../bus/usb
>>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
>>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
>>>>>>> >
>>>>>>> > root@tester0:~# grep ^
>>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
>>>>>>> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
>>>>>>> >
>>>>>>> > The driver itself tells me that the interface registers properly
>>>>>>> too
>>>>>>> > (my apologies for the extra debug messages):
>>>>>>> > [85375.091233] ni_usb_gpib driver loading
>>>>>>> > [85375.098301] ni_usb_driver_probe
>>>>>>> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
>>>>>>> > [85375.107200] ni_usb_gpib: probe succeeded for path:
>>>>>>> > usb-xhci-hcd.1.auto-1.4
>>>>>>> > [85375.119145] usbcore: registered new interface driver ni_usb_gpib
>>>>>>> > [85375.128308] gpib: registered ni_usb_b interface
>>>>>>> >
>>>>>>> > However, everywhere I look in the code doesn't indicate to me where
>>>>>>> > the disconnect occurs. I'm fairly certain the issue is that the
>>>>>>> > /dev/gpib* section isn't pointing to the dongle area and that's my
>>>>>>> > problem. I've been trying to create a workaround to this that shows
>>>>>>> > the device working at all, but I'm not having any luck there.
>>>>>>> > So I'm at a loss for where to go next. Any suggestions? RIght now,
>>>>>>> I'm
>>>>>>> > trying to figure out why I'm getting "interface=". I feel like
>>>>>>> that's
>>>>>>> > the underlying problem, but I can't confirm it.
>>>>>>> > Just in case, here is some extra information about he system I'm
>>>>>>> on:
>>>>>>> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>>>>>>> >           Kernel: Linux 6.1.30-xilinx-v2023.2
>>>>>>> >     Architecture: arm64
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Michael
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
>>>>>>> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
>>>>>>> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
>>>>>>> la...@dc...                    －​μ+－－+νν                 |E
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-gpib-general mailing list
>>>>>>> Lin...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-gpib-general mailing list
>>>>>> Lin...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>
>>>>>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[Michael J. <mgj...@gm...>]

Yes, there is quite a bit in the console log. I have the debug turned on
(and added some statements in myself), but this is pretty much what happens
when I plug in the device:
[ 9748.976545] usb 1-1.4: new high-speed USB device number 5 using xhci-hcd
[ 9749.084858] usb 1-1.4: config 1 interface 0 altsetting 0 endpoint 0x81
has an invalid bInterval 0, changing to 7
[ 9749.095353] usb 1-1.4: New USB device found, idVendor=3923,
idProduct=709b, bcdDevice= 1.01
[ 9749.103769] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 9749.111094] usb 1-1.4: Product: GPIB-USB-HS
[ 9749.115289] usb 1-1.4: Manufacturer: National Instruments
[ 9749.120690] usb 1-1.4: SerialNumber: 01D9F4A4
[ 9749.210590] Linux-GPIB 4.3.6 Driver
[ 9749.386255] ni_usb_gpib driver loading
[ 9749.402265] ni_usb_gpib: probe succeeded for path:
usb-xhci-hcd.1.auto-1.4
[ 9749.414241] usbcore: registered new interface driver ni_usb_gpib
[ 9749.423413] gpib: registered ni_usb_b interface
[ 9749.927552] gpib debug: pid 0, gpib: opening minor 0
[ 9749.935625] gpib debug: pid 0, gpib: request module returned 256
[ 9749.942207] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
onl=0, arg=f523e908
[ 9749.970918] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
onl=0
[ 9749.978472] gpib debug: pid 0, gpib: closing minor 0
[ 9808.492473] gpib debug: pid 0, gpib: opening minor 0
[ 9808.500324] gpib debug: pid 0, gpib: request module returned 256
[ 9808.506433] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
onl=0, arg=fb3f8278

When I try to run "gpib_config", it only shows this line:
[11325.680770] gpib debug: pid 0, gpib: opening minor 0
[11325.688909] gpib debug: pid 0, gpib: request module returned 256
[11325.695036] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
onl=0, arg=ef9596d8
[11325.723526] gpib debug: pid 0, minor 0, ioctl 39, interface=, use=0,
onl=0
[11325.730940] gpib debug: pid 0, gpib: closing minor 0

Best Regards,
Michael

On Mon, Nov 11, 2024 at 1:28 PM dave penkler <dpe...@gm...> wrote:

> Hi Michael,
> The gpib.conf looks perfect. Somewhere during the configure we are getting
> an EFAULT - Bad address. This would point to some incompatibility between
> user space gpib_config and the gpib_common kernel module. Is there anything
> in the console log (dmesg) ?
> cheers,
> -dave
>
>
>
> On Tue, 12 Nov 2024, 05:28 Michael Jaggers, <mgj...@gm...> wrote:
>
>> Hey Dave,
>>
>> I went back and double checked on the configure argument you asked for,
>> and I did provide the path to it. I also checked it by putting a syntax
>> error into the gpib.conf file and that output an error and the path it was
>> pointing to.
>>
>> Here is the conf file that I'm using:
>>
>> /* This section configures the configurable driver characteristics
>>  * for an interface board, such as board address, and interrupt level.
>>  * minor = 0 configures /dev/gpib0, minor = 1 configures /dev/gpib1, etc.
>>  */
>>
>> interface {
>>     minor = 0
>>     board_type = "ni_usb_gpib"
>>     name = "gpib0"
>>     pad = 2
>>     timeout = T1s
>>     eos = 0x0A
>>     set-reos = yes
>>     set-bin = no
>>     master = yes
>>
>> }
>>
>> Thanks!
>> Michael
>>
>> On Sat, Nov 9, 2024 at 2:24 AM dave penkler <dpe...@gm...> wrote:
>>
>>> Hi Michael,
>>> It looks like a gpib.conf problem. Did you provide a sysconfdir argument
>>> to .configure ?
>>> Please send me your gpib.conf file.
>>> cheers,
>>> -dave
>>>
>>> On Sat, 9 Nov 2024, 04:38 Michael Jaggers, <mgj...@gm...> wrote:
>>>
>>>> Dave,
>>>>
>>>> I've run the gpib_config, but no luck on that end. Here is what happens
>>>> to me:
>>>> 1. First, I restart the device without plugging in the gpib (drivers
>>>> aren't loaded).
>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>> failed to open device file '/dev/gpib0'
>>>> main: No such file or directory
>>>>
>>>> 2. Now, I plug the gpib dongle in.
>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>> failed to bring board offline
>>>> failed to configure board
>>>> main: Bad address
>>>>
>>>> 3. Finally, I unplug the gpib dongle.
>>>> root@tester0:~/git/linux-gpib-git# gpib_config
>>>> failed to bring board offline
>>>> failed to configure board
>>>> main: Bad address
>>>>
>>>> To me, this looks like the dongle isn't attaching to /dev/gpib0. I know
>>>> the driver recognizes the device, it correctly starts the ni_usb_gpib
>>>> driver, and probes the correct location on the device tree, and the driver
>>>> in the device tree points to the correct place the dongle is attached to.
>>>> What's got me scratching my head is why it's not attached to gpib0 (or even
>>>> how to circumvent the need to attach to gpib0).
>>>>
>>>> Could it be related to my udev? In the rules, in file
>>>> "/etc/udev/rules.d/98-gpib-generic.rules" I added:
>>>> ACTION=="add|change",
>>>> DEVPATH=="/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0",
>>>> ENV{GPIB_CONFIG_OPTIONS}="--minor 0"
>>>>
>>>> That's the path that udev recognizes. When I run udevadm monitor, I get
>>>> this after plugging in the dongle:
>>>> KERNEL[1122.600699] add
>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>> (usb)
>>>> KERNEL[1122.650504] add
>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>> (usb)
>>>> KERNEL[1122.671551] bind
>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>> (usb)
>>>> KERNEL[1122.671684] bind
>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>> (usb)
>>>> UDEV  [1122.676333] add
>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>> (usb)
>>>> UDEV  [1122.769461] add
>>>> /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>> (usb)
>>>> UDEV  [1122.772939] bind
>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
>>>> (usb)
>>>> UDEV  [1122.777553] bind
>>>>  /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
>>>> (usb)
>>>>
>>>> Could the version of udev be the cause?
>>>> root@tester0:~/git/linux-gpib-git# udevd --version
>>>> 251.8+
>>>> root@tester0:~/git/linux-gpib-git# udevadm --version
>>>> 251
>>>>
>>>> Thanks for your responses!
>>>> Michael
>>>>
>>>> On Thu, Nov 7, 2024 at 9:04 PM dave penkler <dpe...@gm...> wrote:
>>>>
>>>>> It looks like the board is not attached. Did you run # gpib_config ?
>>>>> Normally the supplied udev scripts do this for you.
>>>>> cheers,
>>>>> -dave
>>>>>
>>>>> On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:
>>>>>
>>>>>> Setting up the /dev/gpib* devices is something that
>>>>>> you might want to look at udev for...but as I recall
>>>>>> there's some problems. That isn't necessarily in the
>>>>>> linux-gpib git project, maybe in linux-gpib-packaging
>>>>>> project....where the idea is to wrap the linux-gpib
>>>>>> code in an rpm package (so that installation deals
>>>>>> with udev scripts, protection issues, etc)
>>>>>>
>>>>>> On Thu, 7 Nov 2024 09:51:32 -0700
>>>>>> Michael Jaggers <mgj...@gm...> wrote:
>>>>>>
>>>>>> > Hello,
>>>>>> >
>>>>>> > I'm working on installing the gpib kernel drivers to the Petalinux
>>>>>> > platform. So far, I've managed to get the headers and get the gpib
>>>>>> > drivers compiled + installed. The modules show up with modprobe, and
>>>>>> > when I plug my gpib dongle in the driver loads properly and it seems
>>>>>> > to recognize it. Below is the message I get when plugging in the
>>>>>> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device number
>>>>>> 11
>>>>>> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
>>>>>> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
>>>>>> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
>>>>>> > idProduct=709b, bcdDevice= 1.01
>>>>>> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>>>>>> > SerialNumber=3
>>>>>> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
>>>>>> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
>>>>>> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
>>>>>> >
>>>>>> > Here is where the issue comes up. When ibopen goes to set things up
>>>>>> > with the dongle, the /dev/gpib0 doesn't seem to be properly
>>>>>> > configured. I get this message when I run the ibtest utility:
>>>>>> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
>>>>>> > [84391.696029] gpib debug: pid 0, gpib: request module returned 256
>>>>>> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>> use=0,
>>>>>> > onl=0, arg=d8a171a0
>>>>>> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
>>>>>> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>>>>>> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>> > interface=, use=0, onl=0, arg=d8a17120
>>>>>> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
>>>>>> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
>>>>>> > interface=, use=0, onl=0, arg=d8a17180
>>>>>> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
>>>>>> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>>>>>> > use=0, onl=0 [84391.762675] audit: type=1701
>>>>>> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
>>>>>> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1 [84391.764574]
>>>>>> > gpib debug: pid 0, gpib: closing minor 0
>>>>>> >
>>>>>> > I've been debugging this for a week or so now. I'm fairly confident
>>>>>> > that the probing of the dongle works. In fact, when I find the
>>>>>> dongle
>>>>>> > in the sys path, I see that the module driver is in that path of the
>>>>>> > device itself: root@tester0:~# ls -ll
>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
>>>>>> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
>>>>>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
>>>>>> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
>>>>>> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
>>>>>> > ../../../../../../../../../../bus/usb
>>>>>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
>>>>>> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
>>>>>> >
>>>>>> > root@tester0:~# grep ^
>>>>>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
>>>>>> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
>>>>>> >
>>>>>> > The driver itself tells me that the interface registers properly too
>>>>>> > (my apologies for the extra debug messages):
>>>>>> > [85375.091233] ni_usb_gpib driver loading
>>>>>> > [85375.098301] ni_usb_driver_probe
>>>>>> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
>>>>>> > [85375.107200] ni_usb_gpib: probe succeeded for path:
>>>>>> > usb-xhci-hcd.1.auto-1.4
>>>>>> > [85375.119145] usbcore: registered new interface driver ni_usb_gpib
>>>>>> > [85375.128308] gpib: registered ni_usb_b interface
>>>>>> >
>>>>>> > However, everywhere I look in the code doesn't indicate to me where
>>>>>> > the disconnect occurs. I'm fairly certain the issue is that the
>>>>>> > /dev/gpib* section isn't pointing to the dongle area and that's my
>>>>>> > problem. I've been trying to create a workaround to this that shows
>>>>>> > the device working at all, but I'm not having any luck there.
>>>>>> > So I'm at a loss for where to go next. Any suggestions? RIght now,
>>>>>> I'm
>>>>>> > trying to figure out why I'm getting "interface=". I feel like
>>>>>> that's
>>>>>> > the underlying problem, but I can't confirm it.
>>>>>> > Just in case, here is some extra information about he system I'm on:
>>>>>> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>>>>>> >           Kernel: Linux 6.1.30-xilinx-v2023.2
>>>>>> >     Architecture: arm64
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
>>>>>> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
>>>>>> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
>>>>>> la...@dc...                    －​μ+－－+νν                 |E
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-gpib-general mailing list
>>>>>> Lin...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>>
>>>>> _______________________________________________
>>>>> Linux-gpib-general mailing list
>>>>> Lin...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>
>>>>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[Michael J. <mgj...@gm...>]

+ Mailing List
Dave,

I've run the gpib_config, but no luck on that end. Here is what happens to
me:
1. First, I restart the device without plugging in the gpib (drivers aren't
loaded).
root@tester0:~/git/linux-gpib-git# gpib_config
failed to open device file '/dev/gpib0'
main: No such file or directory

2. Now, I plug the gpib dongle in.
root@tester0:~/git/linux-gpib-git# gpib_config
failed to bring board offline
failed to configure board
main: Bad address

3. Finally, I unplug the gpib dongle.
root@tester0:~/git/linux-gpib-git# gpib_config
failed to bring board offline
failed to configure board
main: Bad address

To me, this looks like the dongle isn't attaching to /dev/gpib0. I know the
driver recognizes the device, it correctly starts the ni_usb_gpib driver,
and probes the correct location on the device tree, and the driver in the
device tree points to the correct place the dongle is attached to. What's
got me scratching my head is why it's not attached to gpib0 (or even how to
circumvent the need to attach to gpib0).

Could it be related to my udev? In the rules, in file
"/etc/udev/rules.d/98-gpib-generic.rules" I added:
ACTION=="add|change",
DEVPATH=="/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0",
ENV{GPIB_CONFIG_OPTIONS}="--minor 0"

That's the path that udev recognizes. When I run udevadm monitor, I get
this after plugging in the dongle:
KERNEL[1122.600699] add
/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
(usb)
KERNEL[1122.650504] add
/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
(usb)
KERNEL[1122.671551] bind
 /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
(usb)
KERNEL[1122.671684] bind
 /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
(usb)
UDEV  [1122.676333] add
/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
(usb)
UDEV  [1122.769461] add
/devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
(usb)
UDEV  [1122.772939] bind
 /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4/1-1.4:1.0
(usb)
UDEV  [1122.777553] bind
 /devices/platform/axi/ff9d0000.usb/fe200000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.4
(usb)

Could the version of udev be the cause?
root@tester0:~/git/linux-gpib-git# udevd --version
251.8+
root@tester0:~/git/linux-gpib-git# udevadm --version
251

Thanks for your responses!
Michael

On Thu, Nov 7, 2024 at 9:04 PM dave penkler <dpe...@gm...> wrote:

> It looks like the board is not attached. Did you run # gpib_config ?
> Normally the supplied udev scripts do this for you.
> cheers,
> -dave
>
> On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:
>
>> Setting up the /dev/gpib* devices is something that
>> you might want to look at udev for...but as I recall
>> there's some problems. That isn't necessarily in the
>> linux-gpib git project, maybe in linux-gpib-packaging
>> project....where the idea is to wrap the linux-gpib
>> code in an rpm package (so that installation deals
>> with udev scripts, protection issues, etc)
>>
>> On Thu, 7 Nov 2024 09:51:32 -0700
>> Michael Jaggers <mgj...@gm...> wrote:
>>
>> > Hello,
>> >
>> > I'm working on installing the gpib kernel drivers to the Petalinux
>> > platform. So far, I've managed to get the headers and get the gpib
>> > drivers compiled + installed. The modules show up with modprobe, and
>> > when I plug my gpib dongle in the driver loads properly and it seems
>> > to recognize it. Below is the message I get when plugging in the
>> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device number 11
>> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
>> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
>> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
>> > idProduct=709b, bcdDevice= 1.01
>> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
>> > SerialNumber=3
>> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
>> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
>> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
>> >
>> > Here is where the issue comes up. When ibopen goes to set things up
>> > with the dongle, the /dev/gpib0 doesn't seem to be properly
>> > configured. I get this message when I run the ibtest utility:
>> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
>> > [84391.696029] gpib debug: pid 0, gpib: request module returned 256
>> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0,
>> > onl=0, arg=d8a171a0
>> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
>> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
>> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
>> > interface=, use=0, onl=0, arg=d8a17120
>> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
>> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
>> > interface=, use=0, onl=0, arg=d8a17180
>> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
>> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
>> > use=0, onl=0 [84391.762675] audit: type=1701
>> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
>> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1 [84391.764574]
>> > gpib debug: pid 0, gpib: closing minor 0
>> >
>> > I've been debugging this for a week or so now. I'm fairly confident
>> > that the probing of the dongle works. In fact, when I find the dongle
>> > in the sys path, I see that the module driver is in that path of the
>> > device itself: root@tester0:~# ls -ll
>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
>> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
>> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
>> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
>> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
>> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
>> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
>> > ../../../../../../../../../../bus/usb
>> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
>> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
>> >
>> > root@tester0:~# grep ^
>> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
>> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
>> >
>> > The driver itself tells me that the interface registers properly too
>> > (my apologies for the extra debug messages):
>> > [85375.091233] ni_usb_gpib driver loading
>> > [85375.098301] ni_usb_driver_probe
>> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
>> > [85375.107200] ni_usb_gpib: probe succeeded for path:
>> > usb-xhci-hcd.1.auto-1.4
>> > [85375.119145] usbcore: registered new interface driver ni_usb_gpib
>> > [85375.128308] gpib: registered ni_usb_b interface
>> >
>> > However, everywhere I look in the code doesn't indicate to me where
>> > the disconnect occurs. I'm fairly certain the issue is that the
>> > /dev/gpib* section isn't pointing to the dongle area and that's my
>> > problem. I've been trying to create a workaround to this that shows
>> > the device working at all, but I'm not having any luck there.
>> > So I'm at a loss for where to go next. Any suggestions? RIght now, I'm
>> > trying to figure out why I'm getting "interface=". I feel like that's
>> > the underlying problem, but I can't confirm it.
>> > Just in case, here is some extra information about he system I'm on:
>> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>> >           Kernel: Linux 6.1.30-xilinx-v2023.2
>> >     Architecture: arm64
>> >
>> > Thanks,
>> > Michael
>>
>>
>>
>> --
>> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
>> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
>> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
>> la...@dc...                    －​μ+－－+νν                 |E
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[Michael J. <mgj...@gm...>]

+Mailing List
Charles,

I'm okay with circumventing the /dev/gpib* area if possible. I've only
checked out tag 4.3.6 of linux-gpib, so if that includes the packaging then
that might be where that's coming from. I'm not set on having that area,
and overall I'm pretty flexible on possible ideas for troubleshooting.
I tried to see if I could maybe go back to an earlier version of the
project, but I'm not sure which one would support my kernel and I only
found a reference to when the project was updated to support the latest
linux kernel.

On Thu, Nov 7, 2024 at 11:54 AM Charles Lane <la...@dc...> wrote:

> Setting up the /dev/gpib* devices is something that
> you might want to look at udev for...but as I recall
> there's some problems. That isn't necessarily in the
> linux-gpib git project, maybe in linux-gpib-packaging
> project....where the idea is to wrap the linux-gpib
> code in an rpm package (so that installation deals
> with udev scripts, protection issues, etc)
>
> On Thu, 7 Nov 2024 09:51:32 -0700
> Michael Jaggers <mgj...@gm...> wrote:
>
> > Hello,
> >
> > I'm working on installing the gpib kernel drivers to the Petalinux
> > platform. So far, I've managed to get the headers and get the gpib
> > drivers compiled + installed. The modules show up with modprobe, and
> > when I plug my gpib dongle in the driver loads properly and it seems
> > to recognize it. Below is the message I get when plugging in the
> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device number 11
> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
> > idProduct=709b, bcdDevice= 1.01
> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=3
> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
> >
> > Here is where the issue comes up. When ibopen goes to set things up
> > with the dongle, the /dev/gpib0 doesn't seem to be properly
> > configured. I get this message when I run the ibtest utility:
> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
> > [84391.696029] gpib debug: pid 0, gpib: request module returned 256
> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0,
> > onl=0, arg=d8a171a0
> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
> > interface=, use=0, onl=0, arg=d8a17120
> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
> > interface=, use=0, onl=0, arg=d8a17180
> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> > use=0, onl=0 [84391.762675] audit: type=1701
> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1 [84391.764574]
> > gpib debug: pid 0, gpib: closing minor 0
> >
> > I've been debugging this for a week or so now. I'm fairly confident
> > that the probing of the dongle works. In fact, when I find the dongle
> > in the sys path, I see that the module driver is in that path of the
> > device itself: root@tester0:~# ls -ll
> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
> > ../../../../../../../../../../bus/usb
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
> >
> > root@tester0:~# grep ^
> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
> >
> > The driver itself tells me that the interface registers properly too
> > (my apologies for the extra debug messages):
> > [85375.091233] ni_usb_gpib driver loading
> > [85375.098301] ni_usb_driver_probe
> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
> > [85375.107200] ni_usb_gpib: probe succeeded for path:
> > usb-xhci-hcd.1.auto-1.4
> > [85375.119145] usbcore: registered new interface driver ni_usb_gpib
> > [85375.128308] gpib: registered ni_usb_b interface
> >
> > However, everywhere I look in the code doesn't indicate to me where
> > the disconnect occurs. I'm fairly certain the issue is that the
> > /dev/gpib* section isn't pointing to the dongle area and that's my
> > problem. I've been trying to create a workaround to this that shows
> > the device working at all, but I'm not having any luck there.
> > So I'm at a loss for where to go next. Any suggestions? RIght now, I'm
> > trying to figure out why I'm getting "interface=". I feel like that's
> > the underlying problem, but I can't confirm it.
> > Just in case, here is some extra information about he system I'm on:
> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
> >           Kernel: Linux 6.1.30-xilinx-v2023.2
> >     Architecture: arm64
> >
> > Thanks,
> > Michael
>
>
>
> --
> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
> la...@dc...                    －​μ+－－+νν                 |E
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[dave p. <dpe...@gm...>]

It looks like the board is not attached. Did you run # gpib_config ?
Normally the supplied udev scripts do this for you.
cheers,
-dave

On Fri, 8 Nov 2024, 05:24 Charles Lane, <la...@dc...> wrote:

> Setting up the /dev/gpib* devices is something that
> you might want to look at udev for...but as I recall
> there's some problems. That isn't necessarily in the
> linux-gpib git project, maybe in linux-gpib-packaging
> project....where the idea is to wrap the linux-gpib
> code in an rpm package (so that installation deals
> with udev scripts, protection issues, etc)
>
> On Thu, 7 Nov 2024 09:51:32 -0700
> Michael Jaggers <mgj...@gm...> wrote:
>
> > Hello,
> >
> > I'm working on installing the gpib kernel drivers to the Petalinux
> > platform. So far, I've managed to get the headers and get the gpib
> > drivers compiled + installed. The modules show up with modprobe, and
> > when I plug my gpib dongle in the driver loads properly and it seems
> > to recognize it. Below is the message I get when plugging in the
> > dongle: [19163.768240] usb 1-1.4: new high-speed USB device number 11
> > using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
> > altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
> > [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
> > idProduct=709b, bcdDevice= 1.01
> > [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=3
> > [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
> > [19164.050739] usb 1-1.4: Manufacturer: National Instruments
> > [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
> >
> > Here is where the issue comes up. When ibopen goes to set things up
> > with the dongle, the /dev/gpib0 doesn't seem to be properly
> > configured. I get this message when I run the ibtest utility:
> > [84391.688217] gpib debug: pid 0, gpib: opening minor 0
> > [84391.696029] gpib debug: pid 0, gpib: request module returned 256
> > [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0,
> > onl=0, arg=d8a171a0
> > [84391.710090] gpib: no gpib board configured on /dev/gpib0
> > [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
> > use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
> > interface=, use=0, onl=0, arg=d8a17120
> > [84391.730218] gpib: no gpib board configured on /dev/gpib0
> > [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> > use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
> > interface=, use=0, onl=0, arg=d8a17180
> > [84391.750363] gpib: no gpib board configured on /dev/gpib0
> > [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> > use=0, onl=0 [84391.762675] audit: type=1701
> > audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
> > comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1 [84391.764574]
> > gpib debug: pid 0, gpib: closing minor 0
> >
> > I've been debugging this for a week or so now. I'm fairly confident
> > that the probing of the dongle works. In fact, when I find the dongle
> > in the sys path, I see that the module driver is in that path of the
> > device itself: root@tester0:~# ls -ll
> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
> > -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
> > lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
> > ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
> > drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
> > drwxr-xr-x 2 root root    0 Nov  7 16:25 power
> > lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
> > ../../../../../../../../../../bus/usb
> > -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
> > -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
> >
> > root@tester0:~# grep ^
> > /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
> > usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
> >
> > The driver itself tells me that the interface registers properly too
> > (my apologies for the extra debug messages):
> > [85375.091233] ni_usb_gpib driver loading
> > [85375.098301] ni_usb_driver_probe
> > [85375.101436] set bus interface 0 to address 0x00000000bca009b3
> > [85375.107200] ni_usb_gpib: probe succeeded for path:
> > usb-xhci-hcd.1.auto-1.4
> > [85375.119145] usbcore: registered new interface driver ni_usb_gpib
> > [85375.128308] gpib: registered ni_usb_b interface
> >
> > However, everywhere I look in the code doesn't indicate to me where
> > the disconnect occurs. I'm fairly certain the issue is that the
> > /dev/gpib* section isn't pointing to the dongle area and that's my
> > problem. I've been trying to create a workaround to this that shows
> > the device working at all, but I'm not having any luck there.
> > So I'm at a loss for where to go next. Any suggestions? RIght now, I'm
> > trying to figure out why I'm getting "interface=". I feel like that's
> > the underlying problem, but I can't confirm it.
> > Just in case, here is some extra information about he system I'm on:
> > Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
> >           Kernel: Linux 6.1.30-xilinx-v2023.2
> >     Architecture: arm64
> >
> > Thanks,
> > Michael
>
>
>
> --
> Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
> ======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
> Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
> la...@dc...                    －​μ+－－+νν                 |E
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Petalinux Kernel Compatability

[Charles L. <la...@dc...>]

Setting up the /dev/gpib* devices is something that 
you might want to look at udev for...but as I recall 
there's some problems. That isn't necessarily in the
linux-gpib git project, maybe in linux-gpib-packaging
project....where the idea is to wrap the linux-gpib 
code in an rpm package (so that installation deals 
with udev scripts, protection issues, etc) 

On Thu, 7 Nov 2024 09:51:32 -0700
Michael Jaggers <mgj...@gm...> wrote:

> Hello,
> 
> I'm working on installing the gpib kernel drivers to the Petalinux
> platform. So far, I've managed to get the headers and get the gpib
> drivers compiled + installed. The modules show up with modprobe, and
> when I plug my gpib dongle in the driver loads properly and it seems
> to recognize it. Below is the message I get when plugging in the
> dongle: [19163.768240] usb 1-1.4: new high-speed USB device number 11
> using xhci-hcd [19164.020393] usb 1-1.4: config 1 interface 0
> altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
> [19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
> idProduct=709b, bcdDevice= 1.01
> [19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [19164.046560] usb 1-1.4: Product: GPIB-USB-HS
> [19164.050739] usb 1-1.4: Manufacturer: National Instruments
> [19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4
> 
> Here is where the issue comes up. When ibopen goes to set things up
> with the dongle, the /dev/gpib0 doesn't seem to be properly
> configured. I get this message when I run the ibtest utility:
> [84391.688217] gpib debug: pid 0, gpib: opening minor 0
> [84391.696029] gpib debug: pid 0, gpib: request module returned 256
> [84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0,
> onl=0, arg=d8a171a0
> [84391.710090] gpib: no gpib board configured on /dev/gpib0
> [84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=,
> use=0, onl=0 [84391.722212] gpib debug: pid 0, minor 0, ioctl 5,
> interface=, use=0, onl=0, arg=d8a17120
> [84391.730218] gpib: no gpib board configured on /dev/gpib0
> [84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> use=0, onl=0 [84391.742357] gpib debug: pid 0, minor 0, ioctl 5,
> interface=, use=0, onl=0, arg=d8a17180
> [84391.750363] gpib: no gpib board configured on /dev/gpib0
> [84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=,
> use=0, onl=0 [84391.762675] audit: type=1701
> audit(1730996390.861:20): auid=0 uid=0 gid=0 ses=2 pid=10840
> comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1 [84391.764574]
> gpib debug: pid 0, gpib: closing minor 0
> 
> I've been debugging this for a week or so now. I'm fairly confident
> that the probing of the dongle works. In fact, when I find the dongle
> in the sys path, I see that the module driver is in that path of the
> device itself: root@tester0:~# ls -ll
> /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/ total 0
> -rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
> -r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
> lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
> ../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
> drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
> drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
> drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
> drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
> drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
> -r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
> drwxr-xr-x 2 root root    0 Nov  7 16:25 power
> lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
> ../../../../../../../../../../bus/usb
> -r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
> -rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent
> 
> root@tester0:~# grep ^
> /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
> usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00
> 
> The driver itself tells me that the interface registers properly too
> (my apologies for the extra debug messages):
> [85375.091233] ni_usb_gpib driver loading
> [85375.098301] ni_usb_driver_probe
> [85375.101436] set bus interface 0 to address 0x00000000bca009b3
> [85375.107200] ni_usb_gpib: probe succeeded for path:
> usb-xhci-hcd.1.auto-1.4
> [85375.119145] usbcore: registered new interface driver ni_usb_gpib
> [85375.128308] gpib: registered ni_usb_b interface
> 
> However, everywhere I look in the code doesn't indicate to me where
> the disconnect occurs. I'm fairly certain the issue is that the
> /dev/gpib* section isn't pointing to the dongle area and that's my
> problem. I've been trying to create a workaround to this that shows
> the device working at all, but I'm not having any luck there.
> So I'm at a loss for where to go next. Any suggestions? RIght now, I'm
> trying to figure out why I'm getting "interface=". I feel like that's
> the underlying problem, but I can't confirm it.
> Just in case, here is some extra information about he system I'm on:
> Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
>           Kernel: Linux 6.1.30-xilinx-v2023.2
>     Architecture: arm64
> 
> Thanks,
> Michael



-- 
Drexel University  |/             /    ·   ν ·   Chuck Lane   |D
======]－－－>－－－C－－－－－π+－－<                Disque 911  |U
Particle Physics    \             \    ~~ e+~~   215-895-1545 |N
la...@dc...                    －​μ+－－+νν                 |E

[Linux-gpib-general] Petalinux Kernel Compatability

[Michael J. <mgj...@gm...>]

Hello,

I'm working on installing the gpib kernel drivers to the Petalinux
platform. So far, I've managed to get the headers and get the gpib drivers
compiled + installed. The modules show up with modprobe, and when I plug my
gpib dongle in the driver loads properly and it seems to recognize it.
Below is the message I get when plugging in the dongle:
[19163.768240] usb 1-1.4: new high-speed USB device number 11 using xhci-hcd
[19164.020393] usb 1-1.4: config 1 interface 0 altsetting 0 endpoint 0x81
has an invalid bInterval 0, changing to 7
[19164.030876] usb 1-1.4: New USB device found, idVendor=3923,
idProduct=709b, bcdDevice= 1.01
[19164.039247] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[19164.046560] usb 1-1.4: Product: GPIB-USB-HS
[19164.050739] usb 1-1.4: Manufacturer: National Instruments
[19164.056138] usb 1-1.4: SerialNumber: 01D9F4A4

Here is where the issue comes up. When ibopen goes to set things up with
the dongle, the /dev/gpib0 doesn't seem to be properly configured. I get
this message when I run the ibtest utility:
[84391.688217] gpib debug: pid 0, gpib: opening minor 0
[84391.696029] gpib debug: pid 0, gpib: request module returned 256
[84391.702071] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0,
onl=0, arg=d8a171a0
[84391.710090] gpib: no gpib board configured on /dev/gpib0
[84391.715398] gpib debug: pid 0, minor 0, ioctl 3, interface=, use=0, onl=0
[84391.722212] gpib debug: pid 0, minor 0, ioctl 5, interface=, use=0,
onl=0, arg=d8a17120
[84391.730218] gpib: no gpib board configured on /dev/gpib0
[84391.735527] gpib debug: pid 0, minor 0, ioctl 5, interface=, use=0, onl=0
[84391.742357] gpib debug: pid 0, minor 0, ioctl 5, interface=, use=0,
onl=0, arg=d8a17180
[84391.750363] gpib: no gpib board configured on /dev/gpib0
[84391.755673] gpib debug: pid 0, minor 0, ioctl 5, interface=, use=0, onl=0
[84391.762675] audit: type=1701 audit(1730996390.861:20): auid=0 uid=0
gid=0 ses=2 pid=10840 comm="ibtest" exe="/usr/local/bin/ibtest" sig=6 res=1
[84391.764574] gpib debug: pid 0, gpib: closing minor 0

I've been debugging this for a week or so now. I'm fairly confident that
the probing of the dongle works. In fact, when I find the dongle in the sys
path, I see that the module driver is in that path of the device itself:
root@tester0:~# ls -ll /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/
total 0
-rw-r--r-- 1 root root 4096 Nov  7 16:25 authorized
-r--r--r-- 1 root root 4096 Nov  7 16:25 bAlternateSetting
-r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceClass
-r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceNumber
-r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceProtocol
-r--r--r-- 1 root root 4096 Nov  7 16:25 bInterfaceSubClass
-r--r--r-- 1 root root 4096 Nov  7 16:25 bNumEndpoints
lrwxrwxrwx 1 root root    0 Nov  7 16:25 driver ->
../../../../../../../../../../bus/usb/drivers/ni_usb_gpib
drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_02
drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_06
drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_81
drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_84
drwxr-xr-x 3 root root    0 Nov  7 16:25 ep_88
-r--r--r-- 1 root root 4096 Nov  7 16:25 modalias
drwxr-xr-x 2 root root    0 Nov  7 16:25 power
lrwxrwxrwx 1 root root    0 Nov  7 16:18 subsystem ->
../../../../../../../../../../bus/usb
-r--r--r-- 1 root root 4096 Nov  7 16:25 supports_autosuspend
-rw-r--r-- 1 root root 4096 Nov  7 16:18 uevent

root@tester0:~# grep ^  /sys/bus/usb/drivers/ni_usb_gpib/1-1.4\:1.0/modalias
usb:*v3923p709B*d0101dc00dsc00dp00icFFisc00ip00in00

The driver itself tells me that the interface registers properly too (my
apologies for the extra debug messages):
[85375.091233] ni_usb_gpib driver loading
[85375.098301] ni_usb_driver_probe
[85375.101436] set bus interface 0 to address 0x00000000bca009b3
[85375.107200] ni_usb_gpib: probe succeeded for path:
usb-xhci-hcd.1.auto-1.4
[85375.119145] usbcore: registered new interface driver ni_usb_gpib
[85375.128308] gpib: registered ni_usb_b interface

However, everywhere I look in the code doesn't indicate to me where the
disconnect occurs. I'm fairly certain the issue is that the /dev/gpib*
section isn't pointing to the dongle area and that's my problem. I've been
trying to create a workaround to this that shows the device working at all,
but I'm not having any luck there.
So I'm at a loss for where to go next. Any suggestions? RIght now, I'm
trying to figure out why I'm getting "interface=". I feel like that's the
underlying problem, but I can't confirm it.
Just in case, here is some extra information about he system I'm on:
Operating System: PetaLinux 2023.2+update-61_04172258- (langdale)
          Kernel: Linux 6.1.30-xilinx-v2023.2
    Architecture: arm64

Thanks,
Michael

Re: [Linux-gpib-general] WaitSRQ() or ibwait(dev, RQS)

[dave p. <dpe...@gm...>]

Using ibwait both with RQS for device and SRQI for board works fine.
/d

On Wed, 25 Sept 2024 at 13:41, Vladimir Vassilev via Linux-gpib-general <
lin...@li...> wrote:

> On 7/14/24 19:05, Michael Schwingen wrote:
>
> ...
> > I am unsure about SRQ interrupt handling, as I don't understand how this
> is
> > supposed to work and I can't test it, so I left that as-is.
> >
>
> We  would also like to put some resources into validation of the SRQ
> functionality.
>
> Would a testcase calling WaitSRQ() or ibwait(dev, RQS) and validating
> that the functions return when the SRQ line is pulled down by a peer be
> a sufficient test?
>
> /V
>
>
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] WaitSRQ() or ibwait(dev, RQS)

[Vladimir V. <vla...@li...>]

On 7/14/24 19:05, Michael Schwingen wrote:

...
> I am unsure about SRQ interrupt handling, as I don't understand how this is
> supposed to work and I can't test it, so I left that as-is.
>

We  would also like to put some resources into validation of the SRQ 
functionality.

Would a testcase calling WaitSRQ() or ibwait(dev, RQS) and validating 
that the functions return when the SRQ line is pulled down by a peer be 
a sufficient test?

/V

Re: [Linux-gpib-general] gpib_bitbang: problem with GPIO tables

[dave p. <dpe...@gm...>]

Hi Michael,
Yes that is normal - your Pi3 is probably based on a bcm2710 SoC which has
the same line-names as Pi4/5.
Raspberry Pi made a couple of Pi3 variants based on different SoCs. The
table labelled p3 is for the bcm2387 variant.
I should change the names of the table variables to be just 0,1 and 2 to
avoid confusion.
cheers,
-Dave

On Wed, 28 Aug 2024 at 19:00, Michael Schwingen <mi...@sc...>
wrote:

> On 28.08.24 15:37, dave penkler wrote:
> > Hi,
> > The tables come from the different RPi device trees. Earlier Pi3A+,
> > Pi3B+ based on bcm2837 had the same DT as Pi2B based on bcm2836 but
> > with gpio14 and 15 called TXD1 and RXD1 instead of TXD0 and RXD0 as
> > for the Pi2B. The bcm2710 and bcm2711 are all like table index 2. As
> > we have no clean way to test what system we are running on we try the
> > three different tables from the oldest to newest.
>
> That approach works fine for me - however, it feels strange that the Pi3
> uses the Pi4/5 table, while the attempt to use the Pi3 table fails.
>
> Is that normal?
>
>
> cu
>
> Michael
>
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] gpib_bitbang: problem with GPIO tables

[Michael S. <mi...@sc...>]

On 28.08.24 15:37, dave penkler wrote:
> Hi,
> The tables come from the different RPi device trees. Earlier Pi3A+, 
> Pi3B+ based on bcm2837 had the same DT as Pi2B based on bcm2836 but 
> with gpio14 and 15 called TXD1 and RXD1 instead of TXD0 and RXD0 as 
> for the Pi2B. The bcm2710 and bcm2711 are all like table index 2. As 
> we have no clean way to test what system we are running on we try the 
> three different tables from the oldest to newest.

That approach works fine for me - however, it feels strange that the Pi3 
uses the Pi4/5 table, while the attempt to use the Pi3 table fails.

Is that normal?


cu

Michael

Re: [Linux-gpib-general] Supporting C++ style comments in gpib.conf?

[dave p. <dpe...@gm...>]

Hi Dirk,
C++ style comments are easier to add and remove when editing gpib.conf
and any improvement to the error messages is helpful - please send a patch.
cheers,
-Dave

On Mon, 26 Aug 2024 at 16:38, Dirk Niggemann <dir...@gm...>
wrote:

> Hi,
>
> I modified the lexical analyzer for gpib.conf (ibConfLex.l) to support
> C++  style comments (// to end of line is a comment).
> The only real reason for doing it is that the output from gpib_config is
> totally unhelpful when you use this comment style not knowing any better
> and it breaks.
>
> Is the file modelled on any other system that this would be totally
> incompatible with?
>
> I‘m also thinking of going in and dealing with stray characters in the
> debug/error output as well since the parser seems very brittle and just
> tells you you have an error at line 0 when a stray character (like ‘/‘ from
> an incorrectly used c++ comment) turns up…
>
> Is there any value to this and should I submit a patch?
>
> Regards,
>
> Dirk Niggemann
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] gpib_bitbang: problem with GPIO tables

[dave p. <dpe...@gm...>]

Hi,
The tables come from the different RPi device trees. Earlier Pi3A+, Pi3B+
based on bcm2837 had the same DT as Pi2B based on bcm2836 but with gpio14
and 15 called TXD1 and RXD1 instead of TXD0 and RXD0 as for the Pi2B. The
bcm2710 and bcm2711 are all like table index 2. As we have no clean way to
test what system we are running on we try the three different tables from
the oldest to newest.
cheers,
-Dave

On Mon, 26 Aug 2024 at 14:20, Michael Schwingen <mi...@sc...>
wrote:

> Hi,
>
> since the conversion of gpib_bitbang to gpiod lookup tables for GPIO
> allocation (which I think is a good idea, since it gets rid of the
> gpio_offset hack), I am having (slight) problems, since some GPIOs are not
> found on my Pi 3B.
>
> The previous version (2ab64102a655fe183cf9653ab20b0511e95159fb) would
> simply
> fail on my RP3B due to "SPI_MISO" not being found. Using the RP5 table on
> my RP3B fixed this.
>
> The current code does this on its own: allocating SPI_MISO fails, and the
> code tries further tables until the RP45 table works - however, this raises
> the question why there is a separate table for RP3 if it does not work on a
> RP3B?
>
>
> Raspberry Pi 3B, git c2c696d3cb6a3bb81974688a85cdf40a815a9f7c
>
> [    0.000000] Linux version 6.6.31+rpt-rpi-v7 (se...@ra...)
> (gcc-12 (Raspbian 12.2.0-14+rpi1) 12.2.0, GNU ld (GNU Binutils for
> Raspbian) 2.40) #1 SMP Raspbian 1:6.6.31-1+rpt1 (2024-05-29)
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7),
> cr=10c5383d
>
> [11692.014745] Linux-GPIB 4.3.6 Driver
> [11692.032150] gpib: registered gpib_bitbang interface
> [11692.032174] gpib_bitbang:bb_init_module - module loaded with pin map
> "yoga"
> [11693.087510] gpib_bitbang:bb_attach - Using pin map "yoga"
> [11693.087545] gpib_bitbang:allocate_gpios - Allocating gpios using table
> index 0
> [11693.087562] gpib_bitbang:allocate_gpios - Allocating gpio GPIO20 pin no
> 20
> [11693.087607] gpib_bitbang:allocate_gpios - Allocating gpio GPIO26 pin no
> 26
> [11693.087633] gpib_bitbang:allocate_gpios - Allocating gpio GPIO13 pin no
> 13
> [11693.087658] gpib_bitbang:allocate_gpios - Allocating gpio GPIO12 pin no
> 12
> [11693.087681] gpib_bitbang:allocate_gpios - Allocating gpio GPIO21 pin no
> 21
> [11693.087705] gpib_bitbang:allocate_gpios - Allocating gpio GPIO19 pin no
> 19
> [11693.087729] gpib_bitbang:allocate_gpios - Allocating gpio GPIO6 pin no 6
> [11693.087751] gpib_bitbang:allocate_gpios - Allocating gpio GPIO5 pin no 5
> [11693.087773] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
> [11693.087796] gpib_common gpib0: cannot find GPIO line SPI_MISO, deferring
> [11693.087811] gpib_bitbang:allocate_gpios - Allocation failed,  now
> using table_index 1
> [11693.087823] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
> [11693.087840] gpib_common gpib0: cannot find GPIO line SPI_MISO, deferring
> [11693.087853] gpib_bitbang:allocate_gpios - Allocation failed,  now
> using table_index 2
> [11693.087864] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
> [11693.087887] gpib_bitbang:allocate_gpios - Allocating gpio GPIO24 pin no
> 24
> [11693.087911] gpib_bitbang:allocate_gpios - Allocating gpio GPIO22 pin no
> 22
> [11693.087935] gpib_bitbang:allocate_gpios - Allocating gpio GPIO25 pin no
> 25
> [11693.087959] gpib_bitbang:allocate_gpios - Allocating gpio GPIO27 pin no
> 27
> [11693.087983] gpib_bitbang:allocate_gpios - Allocating gpio GPIO10 pin no
> 10
> [11693.088005] gpib_bitbang:allocate_gpios - Allocating gpio GPIO23 pin no
> 23
> [11693.088029] gpib_bitbang:allocate_gpios - Allocating gpio GPIO11 pin no
> 11
> [11693.088052] gpib_bitbang:allocate_gpios - Allocating gpio GPIO18 pin no
> 18
> [11693.088172] gpib_bitbang:bb_attach - attached board 0
>
> gpioinfo shows:
>
> gpiochip0 - 54 lines:
>         line   0:     "ID_SDA"       unused   input  active-high
>         line   1:     "ID_SCL"       unused   input  active-high
>         line   2:      "GPIO2"       unused   input  active-high
>         line   3:      "GPIO3"       unused   input  active-high
>         line   4:      "GPIO4"    "hat_led"  output  active-high [used]
>         line   5:      "GPIO5"      "GPIO5"  output  active-high [used]
>         line   6:      "GPIO6"      "GPIO6"  output  active-high [used]
>         line   7:      "GPIO7"       unused   input  active-high
>         line   8:      "GPIO8"       unused   input  active-high
>         line   9:      "GPIO9"      "GPIO9"  output  active-high [used]
>         line  10:     "GPIO10"     "GPIO10"  output  active-high [used]
>         line  11:     "GPIO11"     "GPIO11"   input  active-high [used]
>         line  12:     "GPIO12"     "GPIO12"  output  active-high [used]
>         line  13:     "GPIO13"     "GPIO13"  output  active-high [used]
>         line  14:     "GPIO14"       unused   input  active-high
>         line  15:     "GPIO15"       unused   input  active-high
>         line  16:     "GPIO16"       unused   input  active-high
>         line  17:     "GPIO17"       unused   input  active-high
>         line  18:     "GPIO18"     "GPIO18"  output  active-high [used]
>         line  19:     "GPIO19"     "GPIO19"  output  active-high [used]
>         line  20:     "GPIO20"     "GPIO20"  output  active-high [used]
>         line  21:     "GPIO21"     "GPIO21"  output  active-high [used]
>         line  22:     "GPIO22"     "GPIO22"  output  active-high [used]
>         line  23:     "GPIO23"     "GPIO23"   input  active-high [used]
>         line  24:     "GPIO24"     "GPIO24"   input  active-high [used]
>         line  25:     "GPIO25"     "GPIO25"   input  active-high [used]
>         line  26:     "GPIO26"     "GPIO26"  output  active-high [used]
>         line  27:     "GPIO27"     "GPIO27"  output  active-high [used]
>         line  28: "HDMI_HPD_N"        "hpd"   input   active-low [used]
>         line  29: "STATUS_LED_G" "ACT" output active-high [used]
>         line  30:       "CTS0"       unused   input  active-high
>         line  31:       "RTS0"       unused   input  active-high
>         line  32:       "TXD0"       unused   input  active-high
>         line  33:       "RXD0"       unused   input  active-high
>         line  34:    "SD1_CLK"       unused   input  active-high
>         line  35:    "SD1_CMD"       unused   input  active-high
>         line  36:  "SD1_DATA0"       unused   input  active-high
>         line  37:  "SD1_DATA1"       unused   input  active-high
>         line  38:  "SD1_DATA2"       unused   input  active-high
>         line  39:  "SD1_DATA3"       unused   input  active-high
>         line  40:   "PWM0_OUT"       unused   input  active-high
>         line  41:   "PWM1_OUT"       unused   input  active-high
>         line  42:    "ETH_CLK"       unused   input  active-high
>         line  43:   "WIFI_CLK"       unused   input  active-high
>         line  44:       "SDA0"       unused   input  active-high
>         line  45:       "SCL0"       unused   input  active-high
>         line  46:   "SMPS_SCL"       unused   input  active-high
>         line  47:   "SMPS_SDA"       unused  output  active-high
>         line  48:   "SD_CLK_R"       unused   input  active-high
>         line  49:   "SD_CMD_R"       unused   input  active-high
>         line  50: "SD_DATA0_R"       unused   input  active-high
>         line  51: "SD_DATA1_R"       unused   input  active-high
>         line  52: "SD_DATA2_R"       unused   input  active-high
>         line  53: "SD_DATA3_R"       unused   input  active-high
> gpiochip1 - 8 lines:
>         line   0:      "BT_ON"       unused  output  active-high
>         line   1:      "WL_ON"       unused  output  active-high
>         line   2:  "PWR_LED_R"        "PWR"  output   active-low [used]
>         line   3:    "LAN_RUN"       unused  output  active-high
>         line   4:         "NC"       unused   input  active-high
>         line   5:  "CAM_GPIO0" "cam1_regulator" output active-high [used]
>         line   6:  "CAM_GPIO1"       unused  output  active-high
>         line   7:         "NC"       unused   input  active-high
>
>
> Where do these gpio_gpib_* tables come from?  It looks to me like we should
> be able to use generic names ("GPIO9" instead of "SPI_MISO") for all
> machines (ie.  simply use the rp45 table), since they are in the device
> tree
> - but I am no expert on this.  Are these different depending on OS version?
>
> Looking at the device tree files shows generic names (eg. GPIO9 instead of
> SPI_MISO):
>
> dtc -I dtb -O dts  /boot/firmware/bcm2711-rpi-4-b.dtb | grep
> gpio-line-names
> gpio-line-names =
> "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0RGMII_MDIO\0RGMIO_MDC\0CTS0\0RTS0\0TXD0\0RXD0\0SD1_CLK\0SD1_CMD\0SD1_DATA0\0SD1_DATA1\0SD1_DATA2\0SD1_DATA3\0PWM0_MISO\0PWM1_MOSI\0STATUS_LED_G_CLK\0SPIFLASH_CE_N\0SDA0\0SCL0\0RGMII_RXCLK\0RGMII_RXCTL\0RGMII_RXD0\0RGMII_RXD1\0RGMII_RXD2\0RGMII_RXD3\0RGMII_TXCLK\0RGMII_TXCTL\0RGMII_TXD0\0RGMII_TXD1\0RGMII_TXD2\0RGMII_TXD3";
>
> dtc -I dtb -O dts  /boot/firmware/bcm2710-rpi-3-b.dtb | grep
> gpio-line-names
> gpio-line-names =
> "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0NC\0LAN_RUN_BOOT\0CTS0\0RTS0\0TXD0\0RXD0\0SD1_CLK\0SD1_CMD\0SD1_DATA0\0SD1_DATA1\0SD1_DATA2\0SD1_DATA3\0PWM0_OUT\0PWM1_OUT\0ETH_CLK\0WIFI_CLK\0SDA0\0SCL0\0SMPS_SCL\0SMPS_SDA\0SD_CLK_R\0SD_CMD_R\0SD_DATA0_R\0SD_DATA1_R\0SD_DATA2_R\0SD_DATA3_R";
>
> dtc -I dtb -O dts  /boot/firmware/bcm2710-rpi-2-b.dtb | grep
> gpio-line-names
> gpio-line-names =
> "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0SDA0\0SCL0\0NC\0LAN_RUN\0CAM_GPIO1\0NC\0NC\0PWR_LOW_N\0NC\0NC\0USB_LIMIT\0NC\0PWM0_OUT\0CAM_GPIO0\0SMPS_SCL\0SMPS_SDA\0ETH_CLK\0PWM1_OUT\0HDMI_HPD_N\0STATUS_LED\0SD_CLK_R\0SD_CMD_R\0SD_DATA0_R\0SD_DATA1_R\0SD_DATA2_R\0SD_DATA3_R";
>
> cu
> Michael
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Supporting C++ style comments in gpib.conf?

[Dirk N. <dir...@gm...>]

Hi,

I modified the lexical analyzer for gpib.conf (ibConfLex.l) to support C++  style comments (// to end of line is a comment).
The only real reason for doing it is that the output from gpib_config is totally unhelpful when you use this comment style not knowing any better and it breaks.

Is the file modelled on any other system that this would be totally incompatible with?

I‘m also thinking of going in and dealing with stray characters in the debug/error output as well since the parser seems very brittle and just tells you you have an error at line 0 when a stray character (like ‘/‘ from an incorrectly used c++ comment) turns up…

Is there any value to this and should I submit a patch?

Regards,

Dirk Niggemann

[Linux-gpib-general] gpib_bitbang: problem with GPIO tables

[Michael S. <mi...@sc...>]

Hi,

since the conversion of gpib_bitbang to gpiod lookup tables for GPIO
allocation (which I think is a good idea, since it gets rid of the
gpio_offset hack), I am having (slight) problems, since some GPIOs are not
found on my Pi 3B.

The previous version (2ab64102a655fe183cf9653ab20b0511e95159fb) would simply
fail on my RP3B due to "SPI_MISO" not being found. Using the RP5 table on
my RP3B fixed this.

The current code does this on its own: allocating SPI_MISO fails, and the
code tries further tables until the RP45 table works - however, this raises
the question why there is a separate table for RP3 if it does not work on a
RP3B?


Raspberry Pi 3B, git c2c696d3cb6a3bb81974688a85cdf40a815a9f7c

[    0.000000] Linux version 6.6.31+rpt-rpi-v7 (se...@ra...) (gcc-12 (Raspbian 12.2.0-14+rpi1) 12.2.0, GNU ld (GNU Binutils for Raspbian) 2.40) #1 SMP Raspbian 1:6.6.31-1+rpt1 (2024-05-29)
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

[11692.014745] Linux-GPIB 4.3.6 Driver
[11692.032150] gpib: registered gpib_bitbang interface
[11692.032174] gpib_bitbang:bb_init_module - module loaded with pin map "yoga"
[11693.087510] gpib_bitbang:bb_attach - Using pin map "yoga" 
[11693.087545] gpib_bitbang:allocate_gpios - Allocating gpios using table index 0
[11693.087562] gpib_bitbang:allocate_gpios - Allocating gpio GPIO20 pin no 20
[11693.087607] gpib_bitbang:allocate_gpios - Allocating gpio GPIO26 pin no 26
[11693.087633] gpib_bitbang:allocate_gpios - Allocating gpio GPIO13 pin no 13
[11693.087658] gpib_bitbang:allocate_gpios - Allocating gpio GPIO12 pin no 12
[11693.087681] gpib_bitbang:allocate_gpios - Allocating gpio GPIO21 pin no 21
[11693.087705] gpib_bitbang:allocate_gpios - Allocating gpio GPIO19 pin no 19
[11693.087729] gpib_bitbang:allocate_gpios - Allocating gpio GPIO6 pin no 6
[11693.087751] gpib_bitbang:allocate_gpios - Allocating gpio GPIO5 pin no 5
[11693.087773] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
[11693.087796] gpib_common gpib0: cannot find GPIO line SPI_MISO, deferring
[11693.087811] gpib_bitbang:allocate_gpios - Allocation failed,  now  using table_index 1
[11693.087823] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
[11693.087840] gpib_common gpib0: cannot find GPIO line SPI_MISO, deferring
[11693.087853] gpib_bitbang:allocate_gpios - Allocation failed,  now  using table_index 2
[11693.087864] gpib_bitbang:allocate_gpios - Allocating gpio GPIO9 pin no 9
[11693.087887] gpib_bitbang:allocate_gpios - Allocating gpio GPIO24 pin no 24
[11693.087911] gpib_bitbang:allocate_gpios - Allocating gpio GPIO22 pin no 22
[11693.087935] gpib_bitbang:allocate_gpios - Allocating gpio GPIO25 pin no 25
[11693.087959] gpib_bitbang:allocate_gpios - Allocating gpio GPIO27 pin no 27
[11693.087983] gpib_bitbang:allocate_gpios - Allocating gpio GPIO10 pin no 10
[11693.088005] gpib_bitbang:allocate_gpios - Allocating gpio GPIO23 pin no 23
[11693.088029] gpib_bitbang:allocate_gpios - Allocating gpio GPIO11 pin no 11
[11693.088052] gpib_bitbang:allocate_gpios - Allocating gpio GPIO18 pin no 18
[11693.088172] gpib_bitbang:bb_attach - attached board 0

gpioinfo shows:

gpiochip0 - 54 lines:
	line   0:     "ID_SDA"       unused   input  active-high 
	line   1:     "ID_SCL"       unused   input  active-high 
	line   2:      "GPIO2"       unused   input  active-high 
	line   3:      "GPIO3"       unused   input  active-high 
	line   4:      "GPIO4"    "hat_led"  output  active-high [used]
	line   5:      "GPIO5"      "GPIO5"  output  active-high [used]
	line   6:      "GPIO6"      "GPIO6"  output  active-high [used]
	line   7:      "GPIO7"       unused   input  active-high 
	line   8:      "GPIO8"       unused   input  active-high 
	line   9:      "GPIO9"      "GPIO9"  output  active-high [used]
	line  10:     "GPIO10"     "GPIO10"  output  active-high [used]
	line  11:     "GPIO11"     "GPIO11"   input  active-high [used]
	line  12:     "GPIO12"     "GPIO12"  output  active-high [used]
	line  13:     "GPIO13"     "GPIO13"  output  active-high [used]
	line  14:     "GPIO14"       unused   input  active-high 
	line  15:     "GPIO15"       unused   input  active-high 
	line  16:     "GPIO16"       unused   input  active-high 
	line  17:     "GPIO17"       unused   input  active-high 
	line  18:     "GPIO18"     "GPIO18"  output  active-high [used]
	line  19:     "GPIO19"     "GPIO19"  output  active-high [used]
	line  20:     "GPIO20"     "GPIO20"  output  active-high [used]
	line  21:     "GPIO21"     "GPIO21"  output  active-high [used]
	line  22:     "GPIO22"     "GPIO22"  output  active-high [used]
	line  23:     "GPIO23"     "GPIO23"   input  active-high [used]
	line  24:     "GPIO24"     "GPIO24"   input  active-high [used]
	line  25:     "GPIO25"     "GPIO25"   input  active-high [used]
	line  26:     "GPIO26"     "GPIO26"  output  active-high [used]
	line  27:     "GPIO27"     "GPIO27"  output  active-high [used]
	line  28: "HDMI_HPD_N"        "hpd"   input   active-low [used]
	line  29: "STATUS_LED_G" "ACT" output active-high [used]
	line  30:       "CTS0"       unused   input  active-high 
	line  31:       "RTS0"       unused   input  active-high 
	line  32:       "TXD0"       unused   input  active-high 
	line  33:       "RXD0"       unused   input  active-high 
	line  34:    "SD1_CLK"       unused   input  active-high 
	line  35:    "SD1_CMD"       unused   input  active-high 
	line  36:  "SD1_DATA0"       unused   input  active-high 
	line  37:  "SD1_DATA1"       unused   input  active-high 
	line  38:  "SD1_DATA2"       unused   input  active-high 
	line  39:  "SD1_DATA3"       unused   input  active-high 
	line  40:   "PWM0_OUT"       unused   input  active-high 
	line  41:   "PWM1_OUT"       unused   input  active-high 
	line  42:    "ETH_CLK"       unused   input  active-high 
	line  43:   "WIFI_CLK"       unused   input  active-high 
	line  44:       "SDA0"       unused   input  active-high 
	line  45:       "SCL0"       unused   input  active-high 
	line  46:   "SMPS_SCL"       unused   input  active-high 
	line  47:   "SMPS_SDA"       unused  output  active-high 
	line  48:   "SD_CLK_R"       unused   input  active-high 
	line  49:   "SD_CMD_R"       unused   input  active-high 
	line  50: "SD_DATA0_R"       unused   input  active-high 
	line  51: "SD_DATA1_R"       unused   input  active-high 
	line  52: "SD_DATA2_R"       unused   input  active-high 
	line  53: "SD_DATA3_R"       unused   input  active-high 
gpiochip1 - 8 lines:
	line   0:      "BT_ON"       unused  output  active-high 
	line   1:      "WL_ON"       unused  output  active-high 
	line   2:  "PWR_LED_R"        "PWR"  output   active-low [used]
	line   3:    "LAN_RUN"       unused  output  active-high 
	line   4:         "NC"       unused   input  active-high 
	line   5:  "CAM_GPIO0" "cam1_regulator" output active-high [used]
	line   6:  "CAM_GPIO1"       unused  output  active-high 
	line   7:         "NC"       unused   input  active-high 


Where do these gpio_gpib_* tables come from?  It looks to me like we should
be able to use generic names ("GPIO9" instead of "SPI_MISO") for all
machines (ie.  simply use the rp45 table), since they are in the device tree
- but I am no expert on this.  Are these different depending on OS version?

Looking at the device tree files shows generic names (eg. GPIO9 instead of
SPI_MISO):

dtc -I dtb -O dts  /boot/firmware/bcm2711-rpi-4-b.dtb | grep gpio-line-names 
gpio-line-names = "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0RGMII_MDIO\0RGMIO_MDC\0CTS0\0RTS0\0TXD0\0RXD0\0SD1_CLK\0SD1_CMD\0SD1_DATA0\0SD1_DATA1\0SD1_DATA2\0SD1_DATA3\0PWM0_MISO\0PWM1_MOSI\0STATUS_LED_G_CLK\0SPIFLASH_CE_N\0SDA0\0SCL0\0RGMII_RXCLK\0RGMII_RXCTL\0RGMII_RXD0\0RGMII_RXD1\0RGMII_RXD2\0RGMII_RXD3\0RGMII_TXCLK\0RGMII_TXCTL\0RGMII_TXD0\0RGMII_TXD1\0RGMII_TXD2\0RGMII_TXD3";

dtc -I dtb -O dts  /boot/firmware/bcm2710-rpi-3-b.dtb | grep gpio-line-names
gpio-line-names = "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0NC\0LAN_RUN_BOOT\0CTS0\0RTS0\0TXD0\0RXD0\0SD1_CLK\0SD1_CMD\0SD1_DATA0\0SD1_DATA1\0SD1_DATA2\0SD1_DATA3\0PWM0_OUT\0PWM1_OUT\0ETH_CLK\0WIFI_CLK\0SDA0\0SCL0\0SMPS_SCL\0SMPS_SDA\0SD_CLK_R\0SD_CMD_R\0SD_DATA0_R\0SD_DATA1_R\0SD_DATA2_R\0SD_DATA3_R";

dtc -I dtb -O dts  /boot/firmware/bcm2710-rpi-2-b.dtb | grep gpio-line-names 
gpio-line-names = "ID_SDA\0ID_SCL\0GPIO2\0GPIO3\0GPIO4\0GPIO5\0GPIO6\0GPIO7\0GPIO8\0GPIO9\0GPIO10\0GPIO11\0GPIO12\0GPIO13\0GPIO14\0GPIO15\0GPIO16\0GPIO17\0GPIO18\0GPIO19\0GPIO20\0GPIO21\0GPIO22\0GPIO23\0GPIO24\0GPIO25\0GPIO26\0GPIO27\0SDA0\0SCL0\0NC\0LAN_RUN\0CAM_GPIO1\0NC\0NC\0PWR_LOW_N\0NC\0NC\0USB_LIMIT\0NC\0PWM0_OUT\0CAM_GPIO0\0SMPS_SCL\0SMPS_SDA\0ETH_CLK\0PWM1_OUT\0HDMI_HPD_N\0STATUS_LED\0SD_CLK_R\0SD_CMD_R\0SD_DATA0_R\0SD_DATA1_R\0SD_DATA2_R\0SD_DATA3_R";

cu
Michael

[Linux-gpib-general] gpib_bitbang patch: use LED triggers instead of direct GPIO access

[Michael S. <mi...@sc...>]

Hi,

here is a patch to use the kernel's LED trigger system instead of direct
GPIO access for the activity LED. This makes it possible to use an existing
LED that is not attached to the GPIB HAT, and a single LED can be used for
multiple functions.

To convert the HAT LED to a kernel LED:
echo "dtoverlay=gpio-led,gpio=4,trigger=heartbeat,label=hat_led" >>/boot/firmware/config.txt

load GPIB driver module
echo "gpib" >/sys/class/leds/hat_led/trigger


cu
Michael



>From 33923fc9e9176bbbb7a3d237d3f9f22b719cfc85 Mon Sep 17 00:00:00 2001
From: root <root@gpib-rp2>
Date: Sun, 18 Aug 2024 21:20:41 +0200
Subject: [PATCH] use LED trigger for GPIB activity LED instead of direct GPIO
 access

---
 .../drivers/gpib/gpio/gpib_bitbang.c            | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
index a393bb45..46c8ea5c 100644
--- a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
+++ b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
@@ -97,6 +97,7 @@
 #include <linux/gpio/machine.h>
 #include <linux/gpio.h>
 #include <linux/irq.h>
+#include <linux/leds.h>
 
 static int sn7516x_used=1, sn7516x;
 module_param(sn7516x_used,int,0660);
@@ -163,11 +164,12 @@ typedef enum {
  */
 
 #define GPIB_PINS 16
-#define SN7516X_PINS 4
+#define SN7516X_PINS 3
 #define NUM_PINS (GPIB_PINS + SN7516X_PINS)
 
-#define ACT_LED_ON  if (ACT_LED != NULL) gpiod_direction_output(ACT_LED, 1)
-#define ACT_LED_OFF if (ACT_LED != NULL) gpiod_direction_output(ACT_LED, 0)
+DEFINE_LED_TRIGGER(ledtrig_gpib);
+#define ACT_LED_ON  do {led_trigger_event(ledtrig_gpib, LED_FULL);} while(0)
+#define ACT_LED_OFF do {led_trigger_event(ledtrig_gpib, LED_OFF);} while(0)
 
 struct gpio_desc * all_descriptors[GPIB_PINS+SN7516X_PINS];
 
@@ -192,7 +194,6 @@ struct gpio_desc * all_descriptors[GPIB_PINS+SN7516X_PINS];
 #define PE all_descriptors[16]
 #define DC all_descriptors[17]
 #define TE all_descriptors[18]
-#define ACT_LED all_descriptors[19]
 
 /* YOGA dapter uses a global enable for the buffer chips, re-using the TE pin */
 #define YOGA_ENABLE TE
@@ -218,8 +219,7 @@ int gpios_vector[] = {
 
         PE_pin_nr,
         DC_pin_nr,
-        TE_pin_nr,
-        ACT_LED_pin_nr
+        TE_pin_nr
 };
 
 /* Lookup table for general GPIOs */
@@ -1197,6 +1197,8 @@ static int allocate_gpios(gpib_board_t *board) {
                 retval = -1;
         }
 	if (lookup_table) gpiod_remove_lookup_table(lookup_table);
+	// Initialize LED trigger
+	led_trigger_register_simple("gpib", &ledtrig_gpib);
         return retval;
 }
 
@@ -1207,6 +1209,8 @@ static void bb_detach(gpib_board_t *board)
 	dbg_printk(2, "Enter with data %p\n", board->private_data);
 	if (board->private_data == NULL) return;
 
+	led_trigger_unregister_simple(ledtrig_gpib);
+
         bb_free_irq(board, &priv->irq_DAV, NAME "_DAV");
         bb_free_irq(board, &priv->irq_NRFD, NAME "_NRFD");
         bb_free_irq(board, &priv->irq_NDAC, NAME "_NDAC");
@@ -1266,7 +1270,6 @@ static int bb_attach(gpib_board_t *board, const gpib_board_config_t *config)
                 gpios_vector[&(D06) - &(all_descriptors[0])] = YOGA_D06_pin_nr;
                 gpios_vector[&(PE)  - &(all_descriptors[0])] = -1;
                 gpios_vector[&(DC)  - &(all_descriptors[0])] = -1;
-		gpios_vector[&(ACT_LED)  - &(all_descriptors[0])] = -1;
         } else {
                 dbg_printk (0, "Unrecognized pin mapping.\n");
                 goto bb_attach_fail;
-- 
2.39.2

Re: [Linux-gpib-general] patch proposal

[Michael S. <mi...@sc...>]

On 29.07.24 00:24, marcello.carla wrote:
> It is a possibility and has been considered. The reason that led to
> prefer edge interupts to level ones is the unavoidable overhead that
> comes from the doubling of NRFD and NDAC interrupts. Not huge, but not
> negligible. In any case, hardware problems like a chattering interrupt
> or repeated interrupts due to line reflections cannot be handled in
> software. 

They can be handled in software, and IMHO they should be - that is part 
of designing robust software.

When dealing with an asynchronous bus mechanism like GPIB, such stuff 
can happen and software needs to cope with it.

The only overhead I see is that using level-triggered interrupts, I need 
to enable/disable the interrupts and re-program the level for each 
transfer. I don't know how costly those operations are, but since we are 
talking about a 800MHz clock CPU pushing data at something like 1MB/s, 
this should not be a huge problem.

cu

Michael

Re: [Linux-gpib-general] patch proposal

[Michael S. <mi...@sc...>]

On 28.07.24 23:07, marcello.carla via Linux-gpib-general wrote:
>
> 2)
> I see the problem of a buffer overflow while writing, but to reproduce
> repeated interrupts with slow edges I had to use rising and falling times
> longer than 100 us, a not common event, and only with RPi3b. RPi4 and
> RPi5 have Schmitt triggers on input, and this makes the event impossible.
> Yet, a good interlock between NDAC and NRFD interrupts is advisable, and
> the current implementation (for historical reasons) is a mess. Sorry for
> that and thanks again to Michael for signalling the problem. A revision
> of this part of the code was already on schedule. Asap, as usual.

What about my proposal of changing the interrupts to be level-triggered? 
I believe my code addresses these problems as well.

Should I prepare a clean patch for review?

cu

Michael

[Linux-gpib-general] patch proposal

[marcello.carla <mar...@gm...>]

Dear Michael and Dear David,

1)
here is a proposal for a patch to system hang in case of an off-line or
non existent device. Thanks to Michael for having spotted the problem.

When bb_write() is called, NDAC has to be already asserted low, or no
device is listening. This was not checked and made go crazy
bb_NRFD_interrupt().

In the patch, I have also moved to debug level 1 the (normally useless)
warnings for out of order or idle interrupts. But see also point 2.

--- gpib_bitbang.c-76c3dc    2024-07-27 23:35:01.412798005 +0200
+++ gpib_bitbang.c    2024-07-27 23:48:26.639818311 +0200
@@ -417,7 +417,7 @@
               int send_eoi, size_t *bytes_written)
  {
      unsigned long flags;
-        int retval = 0;
+        int retval = -1;

          bb_private_t *priv = board->private_data;

@@ -438,6 +438,7 @@

          dbg_printk(1,"Enabling interrupts - NRFD: %d   NDAC: %d\n",
                          gpiod_get_value(NRFD), gpiod_get_value(NDAC));
+        if (gpiod_get_value(NDAC)) goto write_end;

          spin_lock_irqsave (&priv->rw_lock, flags);
                  priv->w_busy = 1;          /* make the interrupt
routines active */
@@ -506,13 +507,13 @@
          if (priv->phase == 99)     ENABLE_IRQ (priv->irq_NRFD,
IRQ_TYPE_EDGE_RISING);

          if (priv->w_busy == 0) {
-                dbg_printk(0,"interrupt while idle after %zu/%zu at %d\n",
+                dbg_printk(1,"interrupt while idle after %zu/%zu at %d\n",
                                        priv->w_cnt, priv->length,
priv->phase);
          priv->nrfd_idle++;
                  goto nrfd_exit;  /* idle */
          }
          if (nrfd == 0) {
-                dbg_printk(0,"out of order interrupt after %zu/%zu at
%d cmd %d " LINFMT ".\n",
+                dbg_printk(1,"out of order interrupt after %zu/%zu at
%d cmd %d " LINFMT ".\n",
                                        priv->w_cnt, priv->length,
priv->phase, priv->cmd, LINVAL);
                  priv->phase = 3;
          priv->nrfd_seq++;
@@ -565,12 +566,12 @@
          irq, gpiod_get_value(NRFD), ndac, board->status,
priv->direction, priv->w_busy, priv->r_busy);

          if (priv->w_busy == 0) {
-                dbg_printk(0,"interrupt while idle.\n");
+                dbg_printk(1,"interrupt while idle.\n");
          priv->ndac_idle++;
                  goto ndac_exit;
          }
          if (ndac == 0) {
-                dbg_printk(0,"out of order interrupt at %zu:%d.\n",
priv->w_cnt, priv->phase);
+                dbg_printk(1,"out of order interrupt at %zu:%d.\n",
priv->w_cnt, priv->phase);
                  priv->phase = 5;
          priv->ndac_seq++;
                  goto ndac_exit;



2)
I see the problem of a buffer overflow while writing, but to reproduce
repeated interrupts with slow edges I had to use rising and falling times
longer than 100 us, a not common event, and only with RPi3b. RPi4 and
RPi5 have Schmitt triggers on input, and this makes the event impossible.
Yet, a good interlock between NDAC and NRFD interrupts is advisable, and
the current implementation (for historical reasons) is a mess. Sorry for
that and thanks again to Michael for signalling the problem. A revision
of this part of the code was already on schedule. Asap, as usual.

Bye

Marcello Carla'

On 7/28/24 21:17, Michael Schwingen wrote:
> On 26.07.24 17:48, marcello.carla via Linux-gpib-general wrote:
>> Dear Michael,
>>
>> bb_DAV_interrupt():
>>
>> the check for buffer overflow is at line 390 of current version
>> [76c3dc] (line 379 of last unpatched [b4cbd1]):
>>
>> priv->end_flag = ((priv->count >= priv->request) || priv->end);
>>
>> 'count' is the number of read character; 'request' is the buffer
>> length; when the buffer is full, the operation is terminated even
>> before an EOI or newline. Can you reproduce the conditions when
>> this mechanism does not work correctly?
>
> No, I currently can't reproduce it, but I am quite sure I had cases
> where the count incremented way beyond the expected transfer count.
>
> It might have been the write case:
>
> in bb_NRFD_interrupt, we have
>
>         set_data_lines(priv->w_buf[priv->w_cnt++]); // put the data on
> the lines
> with no check of the transfer size - it checks the size to assert EOI,
> but does not stop further interrupts from happening.
>
> The check to end the transfer is in bb_NDAC_interrupt.
>
> Now if you get lots of NRFD interrupts before NDAC interrupt is
> called, you will increment w_cnt without limit.
>
> Also, if you get multiple NRFD interrupts for one transfer (which can
> happen with sloppy rising/falling edges and reflections), you will get
> wrong data in the buffer. The NRFD interrupt should be locked out
> until the NDAC phase has happened (and vice-versa).
>
>
>>
>> system hang:
>>
>> yes, there is a problem; when you address a non existing device
>> with ibrd(), you correctly obtain a timeout error; when you try
>> an ibwrt() on a non existing device, the system hangs. I shall
>> try to spot the error and propose a remedy asap.
>
> The interesting thing is this only happens some of the time. i had to
> power-cycle the DMM about 5 times before I could catch the hang.
>
> cu
>
> Michael
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] New GPIO adapter / Patch submission guide?

[Michael S. <mi...@sc...>]

On 26.07.24 17:48, marcello.carla via Linux-gpib-general wrote:
> Dear Michael,
>
> bb_DAV_interrupt():
>
> the check for buffer overflow is at line 390 of current version
> [76c3dc] (line 379 of last unpatched [b4cbd1]):
>
> priv->end_flag = ((priv->count >= priv->request) || priv->end);
>
> 'count' is the number of read character; 'request' is the buffer
> length; when the buffer is full, the operation is terminated even
> before an EOI or newline. Can you reproduce the conditions when
> this mechanism does not work correctly?

No, I currently can't reproduce it, but I am quite sure I had cases 
where the count incremented way beyond the expected transfer count.

It might have been the write case:

in bb_NRFD_interrupt, we have

         set_data_lines(priv->w_buf[priv->w_cnt++]); // put the data on 
the lines
with no check of the transfer size - it checks the size to assert EOI, 
but does not stop further interrupts from happening.

The check to end the transfer is in bb_NDAC_interrupt.

Now if you get lots of NRFD interrupts before NDAC interrupt is called, 
you will increment w_cnt without limit.

Also, if you get multiple NRFD interrupts for one transfer (which can 
happen with sloppy rising/falling edges and reflections), you will get 
wrong data in the buffer. The NRFD interrupt should be locked out until 
the NDAC phase has happened (and vice-versa).


>
> system hang:
>
> yes, there is a problem; when you address a non existing device
> with ibrd(), you correctly obtain a timeout error; when you try
> an ibwrt() on a non existing device, the system hangs. I shall
> try to spot the error and propose a remedy asap.

The interesting thing is this only happens some of the time. i had to 
power-cycle the DMM about 5 times before I could catch the hang.

cu

Michael