Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preventing Lpl getting stuck after shutdown #263

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

preventing Lpl getting stuck after shutdown #263

wants to merge 5 commits into from

Conversation

mszczodrak
Copy link
Contributor

proposing changes to DefaultLPL from cc2420 radio stack, that fix the problem of the module getting stuck after radio is turned off as a result of the ActiveMessage SplitControl.stop() call.

@mszczodrak
Copy link
Contributor Author

This commit fixes the problem of DefaultLpl from cc2420 getting stuck in EBUSY state after the radio is turned off. The update solves a bug that I observed and the fix takes care of it. The fix also addresses one potential bug that I haven't seen (thou I had not run enough experiments to wait for it to happen).

Both situations occur when the cc2420 radio is turned off from the ActiveMessage layer while sending a packet. Both bugs are presented on the figures from the files uploaded to: http://www.cs.columbia.edu/~msz/wsn/default_lpl_bug/

The first bug ( on the figures with the files named DefaultLpl_bug.* ) happens when Csma completes transmission of a packet and reports sendDone followed by stopDone. The sendDone signal is used by DefaultLpl to clear its S_LPL_SENDING state; however, it does not go to the idle state if the last transmission before shutting down was not acknowledged, while it should be. This results from DefaultLpl getting stuck in S_LPL_SENDING.

The second (potential) bug ( on figures with the files named DefaultLPL_potential_bug.* ) may happen when DefaultLpl received sendDone and goes to the idle state, but before it receives the stopDone signal from the PowerCycle, it already receives send call to transmit another message, which again keeps this module in S_LPL_SENDING state.

These bugs have a wider impact that just the scope of this module. When DefaultLpl stays in S_LPL_SENDING state, it does not signal sendDone. As a result of that, the UniqueSend is also stuck in a busy state, as well as other modules that are waiting for the sendDone signal; example AMQueueImplP stays EBUSY until it receives sendDone.

Best,
Marcin

@phil-levis
Copy link
Contributor

This looks like a reasonable patch. One suggested change: could you change the name of SplitControlState to SubControlState so the binding between the two is clearer? I'll merge the pull once you do. Thanks!

Marcin K Szczodral and others added 2 commits September 3, 2014 15:53
@mszczodrak
Copy link
Contributor Author

The name change has been applied and tested. It's ready to be merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants