Re: Problem with Ines PCI gpib board on AlmaLinux 9 (RHEL 9 clone)

--===============6339098845344248523==
Content-Type: multipart/alternative; boundary="0000000000004fd77706483032b2"

--0000000000004fd77706483032b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi George,
Thank you very much for the information. This is most helpful as I do not
have an INES card to test with.
The analysis so far:
The INES GPIB chip (one of the best) has two modes - NEC7210 mode and
extended mode.
The Bus Control line  Monitor (BCM) register is only accessible in extended
mode.
From the lspci we see that we are dealing with the full capability INES
gpib chip PCI_DEVICE_ID_INES_GPIB_QL5030 0x0011.
The driver enables it in extended mode. *write_byte(nec_priv,
INES_AUX_XMODE, AUXMR);*
The hypothesis is that extended mode, for some reason to be determined, is
not being enabled.
In support of this hypothesis we have
- When reading the Bus Control Monitor register 0x13 we get rubbish (ibtest
(l)ines output)
- We get the fifo failed message even if no fifo access has happened
- The accel interface does not work (using extended mode fifos)
- The unaccel interface, which works, uses only the NEC7210 registers.
In order to verify this hypothesis we could perform the following
experiment which checks whether
register 0x13 (BCM) is being mapped to 0x3 (serial poll response), (high
order register address bits being ignored) because the NEC7210 has only 8
registers.:
1 Set the *master =3D *configuration parameter in gpib.conf to *no*
  (this is to be able to set the serial poll response register)
2 sudo gpib_config
3 ibtest, open board, and try these commands
  *v* request ser(v)ice (board only)
  enter new status byte (bit 0x40 requests service): *0x07*
* l *get bus (l)ine status
  If we see DAV, NRFD and NDAC on (the others off) the hypothesis is not
refuted.
  *v* request ser(v)ice (board only)
  enter new status byte (bit 0x40 requests service): *0x00*
  *l* get bus (l)ine status
  If now we see all lines off (in particular DAV, NRFD and NDAC) then the
hypothesis is confirmed.
If it is confirmed it remains to figure out why extended mode is not being
enabled.
=CE=95=CF=85=CF=87=CE=B1=CF=81=CE=B9=CF=83=CF=84=CF=8E,
-Dave

--0000000000004fd77706483032b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi=C2=A0George,<div>Thank you very much for the informatio=
n. This is most helpful as I do not have an INES card to test with.</div><d=
iv>The analysis so far:</div><div>The INES GPIB chip (one of the best) has =
two modes - NEC7210 mode and extended mode.=C2=A0</div><div>The Bus Control=
 line=C2=A0 Monitor (BCM) register is only accessible in extended mode.</di=
v><div>From the lspci we see that we are dealing with the full capability I=
NES gpib chip=C2=A0PCI_DEVICE_ID_INES_GPIB_QL5030 0x0011.</div><div>The dri=
ver enables it in extended mode.=C2=A0<font face=3D"monospace"><b>write_byt=
e(nec_priv, INES_AUX_XMODE, AUXMR);</b></font></div><div>The hypothesis is =
that extended mode, for some reason to be determined, is not being enabled.=
</div><div>In support of this hypothesis we have</div><div>- When reading t=
he Bus Control Monitor register 0x13 we get rubbish (ibtest (l)ines output)=
</div><div>- We get the fifo failed message even if no fifo access has happ=
ened</div><div>- The accel interface does not work (using extended mode fif=
os)</div><div>- The unaccel interface, which works, uses only the NEC7210 r=
egisters.</div><div>In order to verify this hypothesis we could perform the=
 following experiment which checks whether</div><div>register 0x13 (BCM) is=
 being mapped to 0x3 (serial poll response), (high order register address b=
its being ignored) because the NEC7210 has only 8 registers.:</div><div>1 S=
et the <b>master =3D </b>configuration parameter in gpib.conf to <b>no</b>=
=C2=A0</div><div>=C2=A0=C2=A0(this is to be able to set the serial poll res=
ponse register)</div><div>2 sudo gpib_config</div><div>3 ibtest, open board=
, and try these commands</div><div>=C2=A0 <b>v</b>=C2=A0request ser(v)ice (=
board only)</div>=C2=A0 enter new status byte (bit 0x40 requests service): =
<b><font face=3D"monospace">0x07</font></b><br><div><b><font face=3D"monosp=
ace">=C2=A0l=C2=A0</font></b>get bus (l)ine status<b><font face=3D"monospac=
e"><br></font></b></div><div>=C2=A0 If we see DAV, NRFD and NDAC on (the ot=
hers off) the hypothesis is not refuted.</div><div>=C2=A0 <b>v</b> request =
ser(v)ice (board only)</div><div>=C2=A0 enter new status byte (bit 0x40 req=
uests service): <font face=3D"monospace"><b>0x00</b></font></div><div>=C2=
=A0 <b><font face=3D"monospace">l</font></b> get bus (l)ine status<br>=C2=
=A0 If now we see all lines off (in particular DAV, NRFD and NDAC) then the=
 hypothesis is confirmed.</div><div>If it is confirmed it remains to figure=
 out why extended mode is not being enabled.</div><div>=CE=95=CF=85=CF=87=
=CE=B1=CF=81=CE=B9=CF=83=CF=84=CF=8E,</div><div>-Dave</div><div><font face=
=3D"monospace"><b><br></b></font></div><div>=C2=A0 =C2=A0</div></div>

--0000000000004fd77706483032b2--


--===============6339098845344248523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6339098845344248523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Linux-gpib-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

--===============6339098845344248523==--