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

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

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

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

It might have been the write case:

in bb_NRFD_interrupt, we have

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

The check to end the transfer is in bb_NDAC_interrupt.

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

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


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

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

cu

Michael