[Hamlib-developer] Problems with tranceive mode

[Chuck H. <n2...@am...>]

In changing my software to be using transceive using sigio, I've run across a
bug that I've been able to duplicate using testtrn.  When/if hamlib gets a
tranceive frame it processes it correctly, but it ends up back in icom_decode
and gets struck in there and never returns back to the main program.

To duplicate using testtrn:

First, I changed testtrn's loop to print out something:

        for (i=0;i<12;i++)
          {
            printf("Loop pass %d\n",i);
            sleep(10);  /* or anything smarter */
          }

Then I ran it:

./testtrn 340
testrig:hello, I am your main() !
rig:rig_init called 
rig: loading backend icom
icom: _init called
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (319)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (334)
rig_register (344)
rig_register (335)
rig_register (340)
rig_register (342)
rig_register (304)
rig_register (307)
rig_register (300)
rig:rig_open called 
Port /dev/ttyS0 opened ok
TX 12 bytes
0000     ff fe fe 08 e0 05 00 00 70 39 04 fd    ........p9..
RX 12 bytes
0000     ff fe fe 08 e0 05 00 00 70 39 04 fd    ........p9..
RX 6 bytes
0000     fe fe e0 08 fb fd      ......
Loop pass 0                               (didn't touch the radio for
Loop pass 1                                one pass and it works fine)
sa_sigioaction: activity detected         
icom: icom_decode called                  (bumped tuning knob one step) 
RX 6 bytes
0000     fe fe 00 08 00 00      ......
RX 1 bytes
0000     01     .
RX 1 bytes
0000     70     p
RX 1 bytes
0000     39     9
RX 1 bytes
0000     04     .
RX 1 bytes
0000     fd     .
Rig changed freq to 439700100Hz
sa_sigioaction: activity detected
icom: icom_decode called

(and it stays there no matter how long you wait.)

---

To trace it down futher, In fread_block, I changed the first fread to be:
(Added printf's, and change count to 1)

  printf("fread_block: before first fread\n");
        rd_count = fread(rxbuffer, 1, 1, p->stream);
  printf("fread_block: after first fread\n");

Repeating the last test I, in the last part I got this:

Rig changed freq to 439700100Hz
sa_sigioaction: activity detected
icom: icom_decode called
fread_block: before first fread

---

This is telling me that it's hanging in the first fread in fread_block.
This has me confused because:
1. Why are we getting a SIGIO after we have read the last frame.
2. Why are we getting a SIGIO if there are 0 charaters in the input buffer.
3. Why is fread_block not timing out.  It times out fine if you try to command
   a radio that is off for example.

I would have loved to send in a patch that fixes the problem, but it has me
confused.

---

The particular machine I'm debugging this on is a RedHat 7.1 with a
custom compiled kernel version 2.4.14.  Problem is also there with the redhat
supplied 2.4.2-2.

---

If nobody else has any ideas, I'll dig into in further.  I did notice the
comments in read_icom_frame:

        /*
         * buffered read are quite helpful here!
         * However, an automate with a state model would be more efficient..
         */

I was wondering if there was a problem doing non-buffered reads?  If there is
a problem with fread and timeouts and/or signals, would read be better?  Just
wondering if there was a previous problem?