David,
Sorry, I was getting issues confused. Yes, I think the change does seem to
prevent the deadlock issue in my use. The issue of not receiving ACKS seems
to have something to do with the base station mote not being able to keep up
with the transmit rate of the host (115.2kbaud) and dropping an inordinately
high number of characters (which is how I found the deadlock in the first
place).
Thanks for the help,
Steve
On Friday 13 July 2007 04:12:37 pm Steve McKown wrote:
> On Friday 13 July 2007 12:35:07 pm David Gay wrote:
> > On 7/3/07, Steve McKown <[EMAIL PROTECTED]> wrote:
> > > In TinyOS 2.0.x, the C SDK's serialsource.c contains a logic error in
> > > write_serial_packet() that can cause a deadlock. This situation occurs
> > > when write_serial_packet() is called by the host and the attached mote
> > > fails to see the ending SYNC delimiter sent (due to a communication
> > > error). The host waits in read_and_process() for an ack from the mote,
> > > and the mote waits in RXSTATE_INFO for more data from the host. The
> > > deadlock is broken if the mote forwards a radio packet to the host.
> >
> > I've checked in a fix for this - I believe the problem is that
> > write_serial_packet should always be checking for acks in non-blocking
> > mode even when the serial_source isn't non-blocking (as far as I can
> > tell, the old code would never deadlock with a non-blocking serial
> > source). So the fix is slightly different from the one below.
> >
> > Let me know if the modified version (in CVS on the tinyos 2.x tree)
> > still doesn't work...
>
> Some more information. With DEBUG enabled, the latest code never shows
> receipt of ack frames:
>
> ----------------------
> resp [1250]: frame=93 guid=9100000027c1aa24 frame=93 sample=0
> metadata=invalid time=Fri Jul 13 15:46:21 2007
> writing 44 26 00 ff ff 00 00 1b 00 96 00 00 00 5d 24 aa c1 27 00 00 00 91
> 00 00 00 5d 00 00 00 00 04 e2 46 97 f2 ad 00
> encoded 7e 44 26 00 ff ff 00 00 1b 00 96 00 00 00 5d 24 aa c1 27 00 00 00
> 91 00 00 00 5d 00 00 00 00 04 e2 46 97 f2 ad 00 4c 2f 7e
> *** write_serial_packet 1 ***
>
> raw 7e 45 00 00 00 04 e2 0c 04 96 00 00 00 5e 24 aa c1 27 00 00 00 91 c6 3f
> 7e received 45 00 00 00 04 e2 0c 04 96 00 00 00 5e 24 aa c1 27 00 00 00 91
> c6 3f crc 3fc6 comp 3fc6
> time [1250]: frame=94 guid=9100000027c1aa24 exists
> resp [1250]: frame=94 guid=9100000027c1aa24 frame=94 sample=0
> metadata=invalid time=Fri Jul 13 15:46:29 2007
> writing 44 27 00 ff ff 00 00 1b 00 96 00 00 00 5e 24 aa c1 27 00 00 00 91
> 00 00 00 5e 00 00 00 00 04 e2 46 97 f2 b5 00
> encoded 7e 44 27 00 ff ff 00 00 1b 00 96 00 00 00 5e 24 aa c1 27 00 00 00
> 91 00 00 00 5e 00 00 00 00 04 e2 46 97 f2 b5 00 4d d0 7e
> *** write_serial_packet 1 ***
> ----------------------
>
> With the older code, the ACK is received, and the dialog continues more
> normally:
>
> ----------------------
> resp [1185]: frame=536 guid=8200000027bc8524 frame=536 sample=0
> metadata=invalid
> time=Fri Jul 13 16:05:26 2007
> writing 44 26 00 ff ff 00 00 1b 00 96 00 00 02 18 24 85 bc 27 00 00 00 82
> 00 00 02 18 00 00 00 00 04 a1 46 97 f7 26 00
> encoded 7e 44 26 00 ff ff 00 00 1b 00 96 00 00 02 18 24 85 bc 27 00 00 00
> 82 00 00 02 18 00 00 00 00 04 a1 46 97 f7 26 00 58 84 7e
> raw 7e 43 26 3b 1c 7e
> received 43 26 3b 1c
> crc 1c3b comp 1c3b
> raw 7e 45 00 00 00 04 a1 20 04 90 00 00 02 19 24 85 bc 27 00 00 00 82 00 07
> 00 10 6d 56 20 20 20 20 20 20 20 20 20 20 20 20 20 20 c9 96 7e
> received 45 00 00 00 04 a1 20 04 90 00 00 02 19 24 85 bc 27 00 00 00 82 00
> 07 00 10 6d 56 20 20 20 20 20 20 20 20 20 20 20 20 20 20 c9 96
> crc 96c9 comp 96c9
> dtyp [1185]: frame=537 guid=8200000027bc8524
> dtype_guid=7 name=mV type=int16 (0)
> raw 7e 45 00 00 00 04 a1 20 04 90 00 00 02 1a 24 85 bc 27 00 00 00 82 00 04
> 01 10 25 2a 31 30 30 20 20 20 20 20 20 20 20 20 20 20 4c 51 7e 7e 45 00 00
> 00 04 a1 20 04 90 00 00 02 1b
> received 45 00 00 00 04 a1 20 04 90 00 00 02 1a 24 85 bc 27 00 00 00 82 00
> 04 01 10 25 2a 31 30 30 20 20 20 20 20 20 20 20 20 20 20 4c 51
> crc 514c comp 514c
> ----------------------
>
> Thanks,
> Steve
>
> > David Gay
> >
> > > The patch below may be a suitable resolution.
> > >
> > > Cheers,
> > > Steve
> > >
> > > Index: serialsource.c
> > > ===================================================================
> > > --- serialsource.c (revision 1024)
> > > +++ serialsource.c (working copy)
> > > @@ -768,6 +768,9 @@
> > > {
> > > struct packet_list *entry;
> > >
> > > + if (source_wait(src, &deadline) < 0)
> > > + return 1;
> > > +
> > > read_and_process(src);
> > > entry = pop_protocol_packet(src, P_ACK);
> > > if (entry)
> > > @@ -779,8 +782,6 @@
> > > if (acked == src->send.seqno)
> > > return 0;
> > > }
> > > - else if (source_wait(src, &deadline) < 0)
> > > - return 1;
> > > }
> > > }
> > >
> > > _______________________________________________
> > > Tinyos-help mailing list
> > > [email protected]
> > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he
> > >lp
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> !DSPAM:4697fb0638711804284693!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
