You can subscribe to this list here.
2002 |
Jan
(2) |
Feb
(2) |
Mar
(22) |
Apr
(24) |
May
(7) |
Jun
(44) |
Jul
(16) |
Aug
(2) |
Sep
(13) |
Oct
(11) |
Nov
(19) |
Dec
(25) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(16) |
Feb
(27) |
Mar
(5) |
Apr
(20) |
May
(17) |
Jun
(34) |
Jul
(29) |
Aug
(22) |
Sep
(25) |
Oct
(11) |
Nov
(13) |
Dec
(18) |
2004 |
Jan
(25) |
Feb
(22) |
Mar
(33) |
Apr
(15) |
May
(37) |
Jun
(15) |
Jul
(12) |
Aug
(22) |
Sep
(18) |
Oct
(45) |
Nov
(19) |
Dec
(30) |
2005 |
Jan
(31) |
Feb
(35) |
Mar
(27) |
Apr
(22) |
May
(9) |
Jun
(13) |
Jul
(13) |
Aug
(9) |
Sep
(25) |
Oct
(25) |
Nov
(12) |
Dec
(20) |
2006 |
Jan
(14) |
Feb
(16) |
Mar
(17) |
Apr
(8) |
May
(7) |
Jun
(20) |
Jul
(21) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(23) |
Dec
(15) |
2007 |
Jan
(13) |
Feb
(14) |
Mar
(24) |
Apr
(21) |
May
(9) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
(21) |
Oct
(5) |
Nov
(30) |
Dec
(9) |
2008 |
Jan
(15) |
Feb
(18) |
Mar
(4) |
Apr
(11) |
May
(3) |
Jun
(14) |
Jul
(12) |
Aug
(1) |
Sep
(31) |
Oct
(10) |
Nov
(9) |
Dec
(2) |
2009 |
Jan
(9) |
Feb
(6) |
Mar
(9) |
Apr
(2) |
May
(7) |
Jun
(22) |
Jul
(5) |
Aug
(1) |
Sep
(26) |
Oct
(13) |
Nov
(2) |
Dec
(10) |
2010 |
Jan
(29) |
Feb
(2) |
Mar
(23) |
Apr
(9) |
May
(7) |
Jun
(8) |
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(9) |
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(25) |
May
(2) |
Jun
(19) |
Jul
(6) |
Aug
(4) |
Sep
(9) |
Oct
(3) |
Nov
(8) |
Dec
(7) |
2012 |
Jan
(5) |
Feb
(10) |
Mar
(10) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(18) |
Dec
(10) |
2013 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
(26) |
Aug
(13) |
Sep
(24) |
Oct
(2) |
Nov
(1) |
Dec
(4) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(5) |
2015 |
Jan
(1) |
Feb
(8) |
Mar
(7) |
Apr
(30) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(6) |
Oct
(13) |
Nov
(9) |
Dec
(2) |
2016 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
(2) |
Jun
(16) |
Jul
(2) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(7) |
2017 |
Jan
(9) |
Feb
(25) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(14) |
Sep
(23) |
Oct
(3) |
Nov
|
Dec
(4) |
2018 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
(20) |
Dec
(10) |
2019 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(7) |
May
(2) |
Jun
(14) |
Jul
(17) |
Aug
(8) |
Sep
(9) |
Oct
(2) |
Nov
(2) |
Dec
(5) |
2020 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(6) |
May
|
Jun
(7) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(11) |
Dec
(4) |
2021 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
(7) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
|
Dec
(3) |
2022 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
|
Aug
(10) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(4) |
2023 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
(6) |
Aug
(4) |
Sep
(28) |
Oct
(8) |
Nov
(2) |
Dec
(1) |
2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Hernán F. <hj...@hj...> - 2025-06-12 14:15:56
|
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 >> > |
From: dave p. <dpe...@gm...> - 2025-06-12 12:06:40
|
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 > |
From: Hernán F. <hj...@hj...> - 2025-06-11 20:40:29
|
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 |
From: dave p. <dpe...@gm...> - 2024-11-12 22:06:16
|
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 >>>>>>>> >>>>>>> |
From: Michael J. <mgj...@gm...> - 2024-11-12 19:42:11
|
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 >>>>>>> >>>>>> |
From: dave p. <dpe...@gm...> - 2024-11-12 05:26:00
|
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 >>>>>> >>>>> |
From: Michael J. <mgj...@gm...> - 2024-11-11 20:44:03
|
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 >>>>> >>>> |
From: Michael J. <mgj...@gm...> - 2024-11-11 20:37:13
|
+ 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 > |
From: Michael J. <mgj...@gm...> - 2024-11-11 20:36:46
|
+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 > |
From: dave p. <dpe...@gm...> - 2024-11-08 04:03:48
|
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 > |
From: Charles L. <la...@dc...> - 2024-11-07 18:54:23
|
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 |
From: Michael J. <mgj...@gm...> - 2024-11-07 16:51:55
|
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 |
From: dave p. <dpe...@gm...> - 2024-09-25 14:30:35
|
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 > |
From: Vladimir V. <vla...@li...> - 2024-09-25 11:40:53
|
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 |
From: dave p. <dpe...@gm...> - 2024-09-03 15:00:38
|
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 > |
From: Michael S. <mi...@sc...> - 2024-08-28 17:00:12
|
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 |
From: dave p. <dpe...@gm...> - 2024-08-28 13:46:35
|
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 > |
From: dave p. <dpe...@gm...> - 2024-08-28 13:38:17
|
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 > |
From: Dirk N. <dir...@gm...> - 2024-08-26 14:38:15
|
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 |
From: Michael S. <mi...@sc...> - 2024-08-26 12:20:11
|
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 |
From: Michael S. <mi...@sc...> - 2024-08-26 12:05:18
|
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 |
From: Michael S. <mi...@sc...> - 2024-07-29 06:30:16
|
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 |
From: Michael S. <mi...@sc...> - 2024-07-28 22:00:17
|
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 |
From: marcello.carla <mar...@gm...> - 2024-07-28 21:08:10
|
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 |
From: Michael S. <mi...@sc...> - 2024-07-28 19:35:37
|
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 |