From: Stefan O. <ste...@jh...> - 2023-01-30 17:59:36
|
Hello Frank, I went through the setups and digging in the config. I have disabled MSI via quirk.c module. But still the troubles. I have no idea where to look now. 2.180894] pcieport 0000:00:00.0: assign IRQ: got 232 [ 2.181046] pcieport 0000:00:00.0: PME: Signaling with IRQ 233 [ 2.182215] pcieport 0000:00:00.0: AER: enabled with IRQ 233 [ 2.182282] pcieport 0000:00:00.0: saving config space at offset 0x0 (reading 0xabcd16c3) [ 2.182286] pcieport 0000:00:00.0: saving config space at offset 0x4 (reading 0x100507) [ 2.182291] pcieport 0000:00:00.0: saving config space at offset 0x8 (reading 0x6040001) [ 2.182295] pcieport 0000:00:00.0: saving config space at offset 0xc (reading 0x10000) [ 2.182299] pcieport 0000:00:00.0: saving config space at offset 0x10 (reading 0x18000000) [ 2.182303] pcieport 0000:00:00.0: saving config space at offset 0x14 (reading 0x0) [ 2.182307] pcieport 0000:00:00.0: saving config space at offset 0x18 (reading 0xff0100) [ 2.182311] pcieport 0000:00:00.0: saving config space at offset 0x1c (reading 0x200000f0) [ 2.182316] pcieport 0000:00:00.0: saving config space at offset 0x20 (reading 0x18101810) [ 2.182320] pcieport 0000:00:00.0: saving config space at offset 0x24 (reading 0xfff0) [ 2.182324] pcieport 0000:00:00.0: saving config space at offset 0x28 (reading 0x0) [ 2.182328] pcieport 0000:00:00.0: saving config space at offset 0x2c (reading 0x0) [ 2.182332] pcieport 0000:00:00.0: saving config space at offset 0x30 (reading 0x0) [ 2.182336] pcieport 0000:00:00.0: saving config space at offset 0x34 (reading 0x40) [ 2.182340] pcieport 0000:00:00.0: saving config space at offset 0x38 (reading 0x0) [ 2.182344] pcieport 0000:00:00.0: saving config space at offset 0x3c (reading 0x201e8) [ 2.182381] pci 0000:01:00.0: TI XIO2000a quirk detected; secondary bus fast back-to-back transfers disabled *[ 2.182394] pci 0000:01:00.0: MSI quirk detected; MSI disabled* [ 2.182449] pcieport 0000:01:00.0: assign IRQ: got 0 [ 5.765586] gpib: registered ni_pci interface [ 5.771144] gpib: registered ni_pci_accel interface [ 6.394826] pci 0000:01:00.0: enabling device (0000 -> 0002) [ 6.436520] pci 0000:01:00.0: enabling bus mastering Stefan On 1/18/23 22:06, Stefan Olejnik wrote: > > *CAUTION:*This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > Hello Frank > > You are right, I have checked generated interrupts, and there in no > 232 interrupt in the list after communication is done: > > 69: 117 0 0 0 GICv3 35 Level galcore:0 > 70: 2 0 0 0 GICv3 57 > Level galcore:2d > 74: 2 0 0 0 gpio-mxc 3 Edge > ads7846 > 78: 0 0 0 0 gpio-mxc 7 Edge > 1-0020 > 81: 0 0 0 0 gpio-mxc 10 > Edge 30b50000.mmc cd > 82: 0 0 0 0 gpio-mxc 11 > Edge extcon_usb1 > 111: 0 0 0 0 gpio-mxc 8 Level > bd718xx-irq > 203: 0 0 0 0 gpio-mxc 4 Edge > edt-ft5206 > 231: 0 0 0 0 bd718xx-irq 5 > Edge gpio_keys > *232: 0 0 0 0 GICv3 157 Level > ni-pci-gpib* > 233: 0 0 0 0 PCI-MSI 0 Edge > PCIe PME, aerdrv > 234: 0 0 0 0 1-0020 1 Edge > Back > 235: 0 0 0 0 1-0020 2 Edge > Home > 236: 0 0 0 0 1-0020 3 Edge > Menu > 237: 329 0 0 0 GICv3 138 > Level 30902000.jr > 238: 0 0 0 0 GICv3 146 > Level 30903000.jr > > I am right trying to set "pci=nomsi" in Yocto image, but I am beginner > in kernel commandline set. I will try to do It. Thanks for advise. > > Stefan > > On 1/17/23 19:20, Frank Mori Hess wrote: >> You might want to check that your board is generating interrupts. I >> had to set the "pci=nomsi" kernel command line option in order to get >> interrupts working with an ARM SOC system. >> >> On Mon, Jan 16, 2023 at 12:38 PM Stefan Olejnik >> <ste...@jh...> wrote: >>> Hi Dave, >>> >>> I have the same results with slave_test2 : >>> >>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test2 >>> [ 135.918117] tnt4882: minor 0 read timed out >>> [ 135.922325] tnt4882: read timed out >>> Got *IDN? >>> >>> [ 138.990013] tnt4882: write timed out >>> error: ibwrt fail >>> - EABO 6: Operation aborted >>> root@imx8mm-var-dart:/home/stefan/bin# >>> >>> >>> I am using computer with Win10 and National Instruments GPIB packages -> NI-VISA interactive control program for GPIB. As a commands I am using "query", send the request and waiting for the answer. This Win10 computer is connected to HW (Variscite board with NI PCIe-GPIB (rev 02)) with Yocto linux 5.10 image via NI GPIB-USB-HS+ connector. >>> >>> I am handling scenarios as follows: >>> >>> No TACS or LACS is set => use poll timer to check if It is any change - 1second. >>> >>> LACS is set => use poll timer 200ms to check if read ( ibrd ) returns any data. If yes, read till end-of-the data and save them. Set flag to answer. When CIC do not address slave as a TACS ( use e.g. only write command ) I am getting, of course, read time out. But this is OK, no data on the GPIB bus. >>> >>> TACS is set => try send the data back to the master - CIC. Clear flag to send data. >>> >>> I am not getting any notifier from the kernel to activate communication. Therefore I am using polling mechanism. It is OK for me now. >>> >>> As I have mentioned already. Reading seems to me OK. When data are on the GPIB bus, I am reading them. When no data, I am getting read time out. But I have somehow to check, if any data are ready to be read => poll mechanism. >>> >>> Write seems to me bigger problem, as I have already described. >>> >>> Stefan >>> >>> >>> On 1/16/23 14:01, dave penkler wrote: >>> >>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>> >>> >>> >>> Hi Stefan, >>> It looks like in your case the slave board was already addressed as a listener before you started slave_test which is why you got the timeout. >>> Here is a new version that deals with this case. It loops until it reads a string when addressed as a listener and then writes back that string when addressed as talker. If the read times out it prints "read timeout" and goes back to the loop. >>> On the master side once a string has been written the response must be read before writing another. Are you using ibterm on the master or something else ? >>> >>> $ ./slave_test2 >>> read timeout >>> read timeout >>> Got hello >>> Got bye >>> Got quit >>> slave done >>> $ >>> >>> cheers, >>> -Dave >>> >>> On Sun, 15 Jan 2023 at 09:46, Stefan Olejnik<ste...@jh...> wrote: >>>> Hi, Dave >>>> >>>> Thanks a lot for Your effort. >>>> >>>> I have tested Your program, but it is almost the same as I have used. The result are as follows: >>>> >>>> root@imx8mm-var-dart:/home/stefan/bin# >>>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test >>>> [ 124.896503] tnt4882: minor 0 read timed out >>>> [ 124.900712] tnt4882: read timed out >>>> Got hello >>>> [ 127.968496] tnt4882: write timed out >>>> error: ibwrt fail >>>> - EABO 6: Operation aborted >>>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test >>>> [ 187.105354] tnt4882: minor 0 read timed out >>>> [ 187.109563] tnt4882: read timed out >>>> Got *IDN? >>>> >>>> [ 190.177371] tnt4882: write timed out >>>> error: ibwrt fail >>>> - EABO 6: Operation aborted >>>> root@imx8mm-var-dart:/home/stefan/bin# >>>> >>>> READING: >>>> >>>> Interesting is that during "ibrd" even read timeout is coming from TNT4882, the data are read OK. I am using reading per char, till END or END-OF-STRING => "\n" and I am getting no time-out during reading. >>>> >>>> WRITTING: >>>> >>>> First "ibwrt" is always time-outed, the second also, but data are delivered, as I am already described. Therefore I am using short TIMO ( e.g. 10ms ) for ibwrt, and on the receiver device is TIMO set to 3s, and I am getting the data. Of course from second "ibwrt". >>>> >>>> Stefan. >>>> >>>> >>> _______________________________________________ >>> Linux-gpib-general mailing list >>> Lin...@li... >>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dStM8yAfuh3c-g2DADHbI16c9tjl3JGNosqI3Iot8J8ca4a2dFSpRfVPrlbgFg5WJ_2JeC33Gjy440iMy6p_$ >>> >>> _______________________________________________ >>> Linux-gpib-general mailing list >>> Lin...@li... >>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dL-ipEp1pt_XUmuO6ksxUAyCAbK3Xy5EHGSA1xgni4Kv2Xj_ib-kNilY-ezJtoZel4f58xAoNvz-A9JR4s4vHIrtRfdtithG1Q$ |