Re: Agilent 82350b can't recover from read timeout?

On Mon, Jul 29, 2019 at 8:17 AM Frank Mori Hess <[email protected]> wrote:
>
> On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <[email protected]> wrote:
> >
> > Hi,
> >
> > I have a strange difference in behaviour between the Agilent 82357a and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on a 32-bit kernel  4.4.0-157-generic.
> >
> > Sending an invalid command ('ID' instead of '*IDN?') to a specific device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be cleared using ibclr() but on the 82350b the lockup can only be cleared by reinitialising the board with gpib_config.
> >
> > Any other command aborts immediately with iberr set to 14  EBUS until the board is reinitialised.
> >
> > The EBUS error is directly translated ETIMEDOUT error from the ibcmd ioctl,
> >
> > This error occurs immediately, even if the timeout is set to 10s, so it's almost like the timer can't  successfully restart after a timeout.
> >
> > I can't figure why nothing clears this error on the 82350b.
>
>
> It's probably a bug in the tms9914 module.  My guess the chip is
> raising an error interrupt (HR_ERR) to try to indicate a data byte got
> discarded without being read.  Hmm actually try adding the change I
> just added in svn commit 1821.  It looks like the tms9914 command
> coded needed to clear the bus error state.

Hmm, actually from what you said it the timeout must be coming when
the board tries to assert the ATN line.  So in the kernel drivers,
ibcmd is calling ibcac is calling tms9914_take_control which is timing
out.  It makes sense the synchronous attempt to take control would
fail, but it should be falling back to asynchronous which should not
fail (but apparently it is).

-- 
Frank