[Tinyos-help] CTP: CtpForwardingEngineP component error
-- Forwarded message --
From: Philip Levis
Date: 2010/10/23
Subject: Re: [Tinyos-devel] CTP: CtpForwardingEngineP component error
To: Dongyu Yang
Cc: tinyos-de...@millennium.berkeley.edu
Please send questions to tinyos-help.
Phil
On Oct 22, 2010, at 10:12 PM, Dongyu Yang wrote:
>
> Hello!
> I set up one network containing four Node and one Root, and use "drip" to
> disseminate command, and use "ctp" to collect data.The Root disseminates
> command every 200 ~ 700 ms (randomly), and the Node use "ctp" to send
> data to the Root when receive the command from the Root. I find the Node
> can receive the Root dissemination command, but can nerver send out data
> after about several minutes (about 5 minutes). And I find ever time when
> call Send.send(), the return value is EBUSY. And I find every time it
return form
> the Send.send() command in the component CtpForwardingEngineP as bellow:
>
>
> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
> ctp_data_header_t* hdr;
> fe_queue_entry_t *qe;
> dbg("Forwarder", "%s: sending packet from client %hhu: %x, len
%hhu\n", __FUNCTION__, client, msg, len);
> if (!hasState(ROUTING_ON)) {return EOFF;}
> if (len > call Send.maxPayloadLength[client]()) {return ESIZE;}
> ..
>
> if (clientPtrs[client] == NULL) {
> dbg("Forwarder", "%s: send failed as client is busy.\n",
__FUNCTION__);
> return EBUSY;
> }
> ..
> }
>
>
> I find in the task sendTask(), when the subsendResult value is not SUCCESS
> or ESIZE, the phenomenon mentioned above will happen, as below:
>
>
> task void sendTask() {
>
> ..
> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
> if (subsendResult == SUCCESS) {
> // Successfully submitted to the data-link layer.
> setState(SENDING);
> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
__FUNCTION__, qe->msg);
> return;
> }
> // The packet is too big: truncate it and retry.
> else if (subsendResult == ESIZE) {
> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
packet.\n", __FUNCTION__);
> call Packet.setPayloadLength(qe->msg, call
Packet.maxPayloadLength());
> post sendTask();
> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
> }
> else {
> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
(int)subsendResult);
> }
> ..
> }
>
>
> I find the code didn't deal with when the subsendResult value is not
SUCCESS
> or ESIZE. And when I add "post sendTask();" in the "else" path as below,
it is
> OK and do not appear the above phenomenon (I test about one hour).
>
>
> task void sendTask() {
>
> ..
> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
> if (subsendResult == SUCCESS) {
> // Successfully submitted to the data-link layer.
> setState(SENDING);
> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
__FUNCTION__, qe->msg);
> return;
> }
> // The packet is too big: truncate it and retry.
> else if (subsendResult == ESIZE) {
> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
packet.\n", __FUNCTION__);
> call Packet.setPayloadLength(qe->msg, call
Packet.maxPayloadLength());
> post sendTask();
> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
> }
> else {
> post sendTask();
> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
(int)subsendResult);
> }
> ..
> }
>
>
> I think it's may be forget to add the code "post sendTask();", because
some reason.
>
>
> Best regards!
> ___
> Tinyos-devel mailing list
> tinyos-de...@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
On Fri, Oct 22, 2010 at 9:37 PM, Dongyu Yang wrote:
>>
>> Hello!
>> I set up one network containing four Node and one Root, and use "drip" to
>> disseminate command, and use "ctp" to collect data.The Root disseminates
>> command every 200 ~ 700 ms (randomly), and the Node use "ctp" to send
>> data to the Root when receive the command from the Root. I find the Node
>> can receive the Root dissemination command, but can nerver send out data
>> after about several minutes (about 5 minutes). And I find ever time when
>> call Send.send(), the return value is EBUSY. And I find every time it
>> return form
>> the Send.send() command in the component CtpForwardingEngineP as bellow:
>>
>>
>> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
>> ctp_data_header_t* hdr;
>> fe_queue_entry_t *qe;
>> dbg("Forwarder", "%s: sending packet from client %hhu: %x, len
>> %hhu\n", __FUNCTION__, client, msg, len);
>> if (!hasState(ROUTING_ON)) {return EOFF;}
>> if (len > call Send.maxPayloadLength[client]()) {return ESIZE;}
>> ..
>>
>> if (clientPtrs[client] == NULL) {
>> dbg("Forwarder", "%s: send failed as client is busy.\n",
>> __FUNCTION__);
>> return EBUSY;
>> }
>> ..
>> }
>>
>>
>> I find in the task sendTask(), when the subsendResult value is not SUCCESS
>> or ESIZE, the phenomenon mentioned above will happen, as below:
>>
>>
>> task void sendTask() {
>>
>> ..
>> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
>> if (subsendResult == SUCCESS) {
>> // Successfully submitted to the data-link layer.
>> setState(SENDING);
>> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
>> __FUNCTION__, qe->msg);
>> return;
>> }
>> // The packet is too big: truncate it and retry.
>> else if (subsendResult == ESIZE) {
>> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
>> packet.\n", __FUNCTION__);
>> call Packet.setPayloadLength(qe->msg, call
>> Packet.maxPayloadLength());
>> post sendTask();
>> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
>> }
>> else {
>> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
>> (int)subsendResult);
>> }
>> ..
>> }
>>
>>
>> I find the code didn't deal with when the subsendResult value is not
>> SUCCESS
>> or ESIZE. And when I add "post sendTask();" in the "else" path as below,
>> it is
>> OK and do not appear the above phenomenon (I test about one hour).
>>
>>
>> task void sendTask() {
>>
>> ..
>> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
>> if (subsendResult == SUCCESS) {
>> // Successfully submitted to the data-link layer.
>> setState(SENDING);
>> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
>> __FUNCTION__, qe->msg);
>> return;
>> }
>> // The packet is too big: truncate it and retry.
>> else if (subsendResult == ESIZE) {
>> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
>> packet.\n", __FUNCTION__);
>> call Packet.setPayloadLength(qe->msg, call
>> Packet.maxPayloadLength());
>> post sendTask();
>> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
>> }
>> else {
>> post sendTask();
>> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
>> (int)subsendResult);
>> }
>> ..
>> }
>>
>>
>> I think it's may be forget to add the code "post sendTask();", because
>> some reason.
That else condition gets executed if the return value is BUSY or FAIL.
We should not post sendTask() if the return value is BUSY because that
means we have already called Send and we are trying to call another
Send before the sendDone is signaled.
You might be trying to send the packets too fast for the channel
capacity remaining after accounting for what is used by Drip. Can you
try reducing your dissemination rate to once every 10 seconds and see
if you still have the same problem?
- om_p
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
On Sat, Oct 23, 2010 at 12:25 AM, Dongyu Yang wrote:
> I have tested this: when one Node (A) happened this phenomenon, I reduce
> the dissemination rate
> to once ever 10 seconds, and stop the other Nodes, this phenomenon exist
> still, the Node (A) can
> only receive the dissemination command, but can never send out data!
> I think it is not cased by the channel capacity, but because in Send.send()
> the
> clientPtrs[client] be set NULL;
>
> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
> ..
> if (call SendQueue.enqueue(qe) == SUCCESS) {
> if (radioOn && !call RetxmitTimer.isRunning()) {
> post sendTask();
> }
> clientPtrs[client] = NULL;
> return SUCCESS;
> }
> ..
> }
> if it do not deal with the EBUSY and FAIL state in the else condition, it
> will remain NULL. So the
> next when call Send.send() it return EBUSY, because the "clientPtrs[client]"
> only be reseted
> in the "void packetComplete()" function which be called in the "event void
> SubSend.sendDone()"
> as below:
>
> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
>
> ..
>
> if (clientPtrs[client] == NULL) {
> dbg("Forwarder", "%s: send failed as client is busy.\n",
> __FUNCTION__);
> return EBUSY;
> }
> ..
> }
>
>
> void packetComplete(fe_queue_entry_t* qe, message_t* msg, bool success) {
>
> if (qe->client < CLIENT_COUNT) {
> clientPtrs[qe->client] = qe;
>
>
> }
>
> }
> because the command SubSend.send() return not SUCCESS, so the event
> SubSend.sendDone() will not signal, so the "clientPtrs[client]" remain NULL.
The return value is either FAIL or EBUSY in that else block.
If it is FAIL, we should wait until the condition that resulted in
FAIL is repaired. If it is EBUSY, that means we should wait
until sendDone.
I think we are handing the EBUSY case properly.
There is a possibility that we are not handing all the possible cases
that can result in FAIL.
I understand posting sendTask solved your problem but I want to
understand why it works and if there is any FAIL condition that we do
not handle properly before committing the fix. Do you know what return
value you were getting when this bug is triggered? If it is FAIL, what
caused that FAIL return value?
- om_p
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
Hello!
The return value is EBUSY. The AM layer do not promise signal
AMSend.sendDone
event, if the return value is not SUCCESS when call AMSend.send().
Because in the component AMQueueImplP, when call Send.send() it may
return
EBUSY in two place, as show below:
generic module AMQueueImplP(int numClients) @safe() {
provides interface Send[uint8_t client];
uses{
interface AMSend[am_id_t id];
interface AMPacket;
interface Packet;
}
}implementation {
..
command error_t Send.send[uint8_t clientId](message_t* msg, uint8_t
len) {
if (clientId >= numClients) {
return FAIL;
}
if (queue[clientId].msg != NULL) {
return EBUSY; //
.(1)
}
dbg("AMQueue", "AMQueue: request to send from %hhu (%p): passed
checks\n", clientId, msg);
queue[clientId].msg = msg;
call Packet.setPayloadLength(msg, len);
if (current >= numClients) { // queue empty
error_t err;
am_id_t amId = call AMPacket.type(msg);
am_addr_t dest = call AMPacket.destination(msg);
dbg("AMQueue", "%s: request to send from %hhu (%p): queue
empty\n", __FUNCTION__, clientId, msg);
current = clientId;
err = call AMSend.send[amId](dest, msg,
len);//.(2)
if (err != SUCCESS) {
dbg("AMQueue", "%s: underlying send failed.\n",
__FUNCTION__);
current = numClients;
queue[clientId].msg = NULL;
}
return err;
}
else {
dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
queue not empty\n", clientId, msg);
}
return SUCCESS;
}
..
}
If the EBUSY is returned from (1), it is OK, and the Send.sendDone
event will be
signaled for the client who call it later; but if the EBUSY is returned from
(2), the
problem arise, it do not signal the Send.sendDone event for the client who
call it, but
it will only signal the Send.sendDone event for another client whose AM ID
is different
from the current client later.
I find this phenomenon arises when the EBUSY value return from (2). So
it may be
the component AMQueueImplP have some problem, it can not guarantee the same
semantic for the EBUSY.
Best regards!
2010/10/30 Omprakash Gnawali
> On Sat, Oct 23, 2010 at 12:25 AM, Dongyu Yang
> wrote:
> > I have tested this: when one Node (A) happened this phenomenon, I reduce
> > the dissemination rate
> > to once ever 10 seconds, and stop the other Nodes, this phenomenon exist
> > still, the Node (A) can
> > only receive the dissemination command, but can never send out data!
> > I think it is not cased by the channel capacity, but because in
> Send.send()
> > the
> > clientPtrs[client] be set NULL;
> >
> > command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
> > ..
> > if (call SendQueue.enqueue(qe) == SUCCESS) {
> > if (radioOn && !call RetxmitTimer.isRunning()) {
> > post sendTask();
> > }
> > clientPtrs[client] = NULL;
> > return SUCCESS;
> > }
> > ..
> > }
> > if it do not deal with the EBUSY and FAIL state in the else condition, it
> > will remain NULL. So the
> > next when call Send.send() it return EBUSY, because the
> "clientPtrs[client]"
> > only be reseted
> > in the "void packetComplete()" function which be called in the "event
> void
> > SubSend.sendDone()"
> > as below:
> >
> > command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
> >
> > ..
> >
> > if (clientPtrs[client] == NULL) {
> > dbg("Forwarder", "%s: send failed as client is busy.\n",
> > __FUNCTION__);
> > return EBUSY;
> > }
> > ..
> > }
> >
> >
> > void packetComplete(fe_queue_entry_t* qe, message_t* msg, bool success) {
> >
> > if (qe->client < CLIENT_COUNT) {
> > clientPtrs[qe->client] = qe;
> >
> >
> >}
> >
> > }
> > because the command SubSend.send() return not SUCCESS, so the event
> > SubSend.sendDone() will not signal, so the "clientPtrs[client]" remain
> NULL.
>
> The return value is either FAIL or EBUSY in that else block.
> If it is FAIL, we should wait until the condition that resulted in
> FAIL is repaired. If it is EBUSY, that means we should wait
> until sendDone.
>
> I think we are handing the EBUSY case properly.
>
> There is a possibility that we are not handing all the possible cases
> that can result in FAIL.
>
> I understand posting sendTask solved your problem but I want to
> understand why it works and if there is any F
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
> Hello!
>
> The return value is EBUSY. The AM layer do not promise signal
> AMSend.sendDone
> event, if the return value is not SUCCESS when call AMSend.send().
> Because in the component AMQueueImplP, when call Send.send() it may
> return
> EBUSY in two place, as show below:
>
> generic module AMQueueImplP(int numClients) @safe() {
> provides interface Send[uint8_t client];
> uses{
> interface AMSend[am_id_t id];
> interface AMPacket;
> interface Packet;
> }
> }implementation {
> ..
> command error_t Send.send[uint8_t clientId](message_t* msg, uint8_t
> len) {
> if (clientId >= numClients) {
> return FAIL;
> }
> if (queue[clientId].msg != NULL) {
> return EBUSY; //
> .(1)
> }
> dbg("AMQueue", "AMQueue: request to send from %hhu (%p): passed
> checks\n", clientId, msg);
>
> queue[clientId].msg = msg;
> call Packet.setPayloadLength(msg, len);
>
> if (current >= numClients) { // queue empty
> error_t err;
> am_id_t amId = call AMPacket.type(msg);
> am_addr_t dest = call AMPacket.destination(msg);
>
> dbg("AMQueue", "%s: request to send from %hhu (%p): queue
> empty\n", __FUNCTION__, clientId, msg);
> current = clientId;
>
> err = call AMSend.send[amId](dest, msg,
> len);//.(2)
> if (err != SUCCESS) {
> dbg("AMQueue", "%s: underlying send failed.\n",
> __FUNCTION__);
> current = numClients;
> queue[clientId].msg = NULL;
>
> }
> return err;
> }
> else {
> dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
> queue not empty\n", clientId, msg);
> }
> return SUCCESS;
> }
> ..
> }
>
> If the EBUSY is returned from (1), it is OK, and the Send.sendDone event
> will be
> signaled for the client who call it later; but if the EBUSY is returned from
> (2), the
> problem arise, it do not signal the Send.sendDone event for the client who
> call it, but
> it will only signal the Send.sendDone event for another client whose AM ID is
> different
> from the current client later.
> I find this phenomenon arises when the EBUSY value return from (2). So it
> may be
> the component AMQueueImplP have some problem, it can not guarantee the same
> semantic for the EBUSY.
>
>
> Best regards!
Except that EBUSY should never be returned in this case. EBUSY is only for when
the AM layer is already sending a packet. If you're getting an EBUSY in (2),
this implies a component is *not* going through the AM queue and instead
directly accessing the active message layer: this breaks the queue's semantics
and implementation.
Can you determine why the active message layer is returning EBUSY?
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
Hello!
I fine this is cased by the component LowPowerListeningLayerP, and this
has been fixed by mmaroti on Nov 13, 2010, Revision: r5220. And when I
update the LowPowerListeningLayerP, it is OK!
Thanks for you attention! Best regards!
2010/11/16 Philip Levis
>
> On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
>
> > Hello!
> >
> > The return value is EBUSY. The AM layer do not promise signal
> AMSend.sendDone
> > event, if the return value is not SUCCESS when call AMSend.send().
> > Because in the component AMQueueImplP, when call Send.send() it may
> return
> > EBUSY in two place, as show below:
> >
> > generic module AMQueueImplP(int numClients) @safe() {
> > provides interface Send[uint8_t client];
> > uses{
> > interface AMSend[am_id_t id];
> > interface AMPacket;
> > interface Packet;
> > }
> > }implementation {
> > ..
> > command error_t Send.send[uint8_t clientId](message_t* msg, uint8_t
> len) {
> > if (clientId >= numClients) {
> > return FAIL;
> > }
> > if (queue[clientId].msg != NULL) {
> > return EBUSY; //
> .(1)
> > }
> > dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
> passed checks\n", clientId, msg);
> >
> > queue[clientId].msg = msg;
> > call Packet.setPayloadLength(msg, len);
> >
> > if (current >= numClients) { // queue empty
> > error_t err;
> > am_id_t amId = call AMPacket.type(msg);
> > am_addr_t dest = call AMPacket.destination(msg);
> >
> > dbg("AMQueue", "%s: request to send from %hhu (%p):
> queue empty\n", __FUNCTION__, clientId, msg);
> > current = clientId;
> >
> > err = call AMSend.send[amId](dest, msg,
> len);//.(2)
> > if (err != SUCCESS) {
> > dbg("AMQueue", "%s: underlying send failed.\n",
> __FUNCTION__);
> > current = numClients;
> > queue[clientId].msg = NULL;
> >
> > }
> > return err;
> > }
> > else {
> > dbg("AMQueue", "AMQueue: request to send from %hhu
> (%p): queue not empty\n", clientId, msg);
> > }
> > return SUCCESS;
> > }
> > ..
> > }
> >
> > If the EBUSY is returned from (1), it is OK, and the Send.sendDone
> event will be
> > signaled for the client who call it later; but if the EBUSY is returned
> from (2), the
> > problem arise, it do not signal the Send.sendDone event for the client
> who call it, but
> > it will only signal the Send.sendDone event for another client whose AM
> ID is different
> > from the current client later.
> > I find this phenomenon arises when the EBUSY value return from (2).
> So it may be
> > the component AMQueueImplP have some problem, it can not guarantee the
> same
> > semantic for the EBUSY.
> >
> >
> > Best regards!
>
> Except that EBUSY should never be returned in this case. EBUSY is only for
> when the AM layer is already sending a packet. If you're getting an EBUSY in
> (2), this implies a component is *not* going through the AM queue and
> instead directly accessing the active message layer: this breaks the queue's
> semantics and implementation.
>
> Can you determine why the active message layer is returning EBUSY?
>
> Phil
>
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
Excellent, great news. Best, Miklos
On Tue, Nov 16, 2010 at 5:56 PM, Dongyu Yang wrote:
> Hello!
>
> I fine this is cased by the component LowPowerListeningLayerP, and this
> has been fixed by mmaroti on Nov 13, 2010, Revision: r5220. And when I
> update the LowPowerListeningLayerP, it is OK!
> Thanks for you attention! Best regards!
>
> 2010/11/16 Philip Levis
>>
>> On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
>>
>> > Hello!
>> >
>> > The return value is EBUSY. The AM layer do not promise signal
>> > AMSend.sendDone
>> > event, if the return value is not SUCCESS when call AMSend.send().
>> > Because in the component AMQueueImplP, when call Send.send() it may
>> > return
>> > EBUSY in two place, as show below:
>> >
>> > generic module AMQueueImplP(int numClients) @safe() {
>> > provides interface Send[uint8_t client];
>> > uses{
>> > interface AMSend[am_id_t id];
>> > interface AMPacket;
>> > interface Packet;
>> > }
>> > }implementation {
>> > ..
>> > command error_t Send.send[uint8_t clientId](message_t* msg,
>> > uint8_t len) {
>> > if (clientId >= numClients) {
>> > return FAIL;
>> > }
>> > if (queue[clientId].msg != NULL) {
>> > return EBUSY; //
>> > .(1)
>> > }
>> > dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
>> > passed checks\n", clientId, msg);
>> >
>> > queue[clientId].msg = msg;
>> > call Packet.setPayloadLength(msg, len);
>> >
>> > if (current >= numClients) { // queue empty
>> > error_t err;
>> > am_id_t amId = call AMPacket.type(msg);
>> > am_addr_t dest = call AMPacket.destination(msg);
>> >
>> > dbg("AMQueue", "%s: request to send from %hhu (%p):
>> > queue empty\n", __FUNCTION__, clientId, msg);
>> > current = clientId;
>> >
>> > err = call AMSend.send[amId](dest, msg,
>> > len);//.(2)
>> > if (err != SUCCESS) {
>> > dbg("AMQueue", "%s: underlying send failed.\n",
>> > __FUNCTION__);
>> > current = numClients;
>> > queue[clientId].msg = NULL;
>> >
>> > }
>> > return err;
>> > }
>> > else {
>> > dbg("AMQueue", "AMQueue: request to send from %hhu
>> > (%p): queue not empty\n", clientId, msg);
>> > }
>> > return SUCCESS;
>> > }
>> > ..
>> > }
>> >
>> > If the EBUSY is returned from (1), it is OK, and the Send.sendDone
>> > event will be
>> > signaled for the client who call it later; but if the EBUSY is returned
>> > from (2), the
>> > problem arise, it do not signal the Send.sendDone event for the client
>> > who call it, but
>> > it will only signal the Send.sendDone event for another client whose AM
>> > ID is different
>> > from the current client later.
>> > I find this phenomenon arises when the EBUSY value return from (2).
>> > So it may be
>> > the component AMQueueImplP have some problem, it can not guarantee the
>> > same
>> > semantic for the EBUSY.
>> >
>> >
>> > Best regards!
>>
>> Except that EBUSY should never be returned in this case. EBUSY is only for
>> when the AM layer is already sending a packet. If you're getting an EBUSY in
>> (2), this implies a component is *not* going through the AM queue and
>> instead directly accessing the active message layer: this breaks the queue's
>> semantics and implementation.
>>
>> Can you determine why the active message layer is returning EBUSY?
>>
>> Phil
>>
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
