Bug #321

deadlock in access grant mechanism

Added by David Burgess over 4 years ago. Updated over 4 years ago.

Status:Closed Start date:
Priority:High Due date:
Assignee:David Burgess % Done:

0%
Category:-
Target version:to-be-decided
Resolution:fixed

Description

Control::AccessGrantResponder() sometimes deadlocks in gBTS::getSDCCH(), blocking on gBTS::mLock. This stalls the receive thread.

History

#1
Updated by David Burgess over 4 years ago

Two threads in deadlock.

One thread is blocked in gBTS::getSDCCH(), called by Control::AccessGrantResponder().

The other thread is blocked in TCHFACCHL1Encoder::sendFrame, being called by LogicalChannel::open() in gBTS::getTCH(), called at the highest level by Control::SDCCHDispatcher(). This other thread is attempting to send its idle frame when first opened. For some reason, the L2 idle frame is not getting pulled from TCHFACCHL1Encoder::mL2Q, and so the thread blocks waiting for mL2Q to empty.

This is related to attempts to recycle TCHs too rapidly.

#2
Updated by David Burgess over 4 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

This bug appears to have been due to the failure of TCHFACCHL1Encoder::sendFrame() to resync the TCH/FACCH L1 sending clock to the BTS clock, resulting in very long wait times prior to sending.

This is fixed in r10051.

Also available in: Atom PDF