Subject: osmo-bts.git branch master updated. 0.1.0-91-g636cad9
From: [email-masked]
To: [email-masked]
Date: Fri, 5 Apr 2013 16:39:00 GMT

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom BTS-side code (Abis, scheduling, ...)".

The branch, master has been updated
       via  636cad95a7e1fe7fa79823b1ba3745b2f029e349 (commit)
       via  0809ae69415d90c2777eec58bd2d5e3485e880fb (commit)
       via  4c4fd284aec75ab8cc2f415a8a4491fd03a5a190 (commit)
       via  42cc93efb667fae331a0e6221e864a9692139363 (commit)
       via  4e46cb8961b7f6e4f62d29e332f18743a9144173 (commit)
       via  564313066464197af58b02152c379e1c02336bcf (commit)
       via  376183fcf05c84a26e6ccb96d033ed569c84473c (commit)
       via  fb0c9f06132769336ab2f01f6b01e369f48f3575 (commit)
       via  9d91c60875548cb7e74b51a3d6bb0ec1b001a672 (commit)
      from  470a6ced9a76812127ce538f124ae41564fd10de (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=636cad95a7e1fe7fa79823b1ba3745b2f029e349

commit 636cad95a7e1fe7fa79823b1ba3745b2f029e349
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Wed Jan 30 09:29:52 2013 +0100

    sysmobts: Document the known MphConfig conflict in the code
    
    Right now changing the TxPower through the VTY could conflict with
    a channel activation.

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=0809ae69415d90c2777eec58bd2d5e3485e880fb

commit 0809ae69415d90c2777eec58bd2d5e3485e880fb
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Fri Jan 25 18:55:50 2013 +0100

    sysmobts: Do not re-configure the channel on non-active channels
    
    In case the channel is not active we can omit the external requests
    to modify it. For the channel modification the higher level is already
    acking it and for the ciphering it is probably too late to do anything.

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=4c4fd284aec75ab8cc2f415a8a4491fd03a5a190

commit 4c4fd284aec75ab8cc2f415a8a4491fd03a5a190
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Sun Jan 13 09:47:52 2013 +0100

    oml: Use the queue for the release handling of a channel
    
    There are three new commands. There are two markers and a deactivate
    command. The markers are used to wait until all previous commands are
    executed and then to decide if the SAPI needs to be released at all.
    
    When asked to release the SACCH the marker will be queued, then on
    execution of the marker the SACCH in Up-/Downlink will be released.
    
    For the RF Channel Release we use another marker, when the marker is
    executed we check all the SAPIs we want to release. It is possible that
    the queue looks like this:
       (SACCH_REL_MARKER is done) REL_MARKER, SACCH DEACT, SACCH DEACT
    
    This could happen if a BSC sends SACCH Deactivate and RF Channel Release
    at the same time. We deal with issue by changing the SAPI state to the
    REL_REQ state and check_sapi_release will not ask for another release. So
    after the execution the queue will look like this:
    
      SACCH DEACT, FACCH DEACT, TCHF DEACT..
    
    This code does not check that all allocated SAPIs are released. The
    lchan_deactivate_sapis could be changed to go through all sapis_dl
    and sapis_ul to fix that.
    
    The normal flow should now be:
    1.)  lchan_deactivate
    2.)  Check if the queue is empty then go to 4
    3.)  REL_MARKER is executed and lchan_deactivate_sapis is called
    4.)  For all SAPIs to be released, check if they are allocated and
         then schedule a CMD_DEACTIVATE. If there is an error remember
         something went wrong but continue.
    5.)  Once all commands are executed send the channel release ack.
    
    For the release markers we need to be careful as they might not schedule
    any work. E.g. if the BSC sends two SACCH DEACTIVATE the second marker
    will not generate any release requests and we should proceed with the
    next command. Make sapi_queue_command return 1 in case the command has
    been directly executed. So a queue like SACCH_REL_MARKER, LOGCH will
    result in LOGCH, SACCH DEACT Rx, SACCH DEACT Tx but a 0 will be returned
    and the sapi_queue_next will then call sapi_queue_exeute again.
    
    NITB has been modified to trigger these corner cases more easily.
    * Do not send IMM.ASSIGNMENT for some timeslots to go through the
    error path
    * Issue multile SACCH deactivates in the normal release mode
    * Send rsl_chan_mode_modify_req before the SACCH DEACT and also when
    the RLL is being released.

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=42cc93efb667fae331a0e6221e864a9692139363

commit 42cc93efb667fae331a0e6221e864a9692139363
Author: Daniel Willmann <[email-masked]>
Date:   Fri Jan 4 00:14:11 2013 +0100

    oml: Print out power setting in txpower completion callback

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=4e46cb8961b7f6e4f62d29e332f18743a9144173

commit 4e46cb8961b7f6e4f62d29e332f18743a9144173
Author: Daniel Willmann <[email-masked]>
Date:   Thu Jan 3 23:35:12 2013 +0100

    oml: Use sapi command queue for setting the logical channel params

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=564313066464197af58b02152c379e1c02336bcf

commit 564313066464197af58b02152c379e1c02336bcf
Author: Daniel Willmann <[email-masked]>
Date:   Thu Jan 3 20:55:12 2013 +0100

    oml: Enqueue ciphering message through sapi cmd queue as well

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=376183fcf05c84a26e6ccb96d033ed569c84473c

commit 376183fcf05c84a26e6ccb96d033ed569c84473c
Author: Daniel Willmann <[email-masked]>
Date:   Thu Jan 3 17:37:59 2013 +0100

    oml: Introduce a SAPI queue for activation and deactivation of SAPIs
    
    Put all SAPI requests into a queue and handle them one after another.
    Begin with the channel activation. Once the queue is empty the channel
    activate will be sent. For the BCCH activation we do not want to send
    a channel activation message and this is why we set the lchan->state
    to NONE.
    
    One change is that we do not attempt to call the ciphering routines on
    the BCCH anymore.
    
    This change is necessary to fix issues with LCHANs staying open and being
    marked as broken by the BSC and will help in implementing handover support
    as this requires a re-configuration of the lchan on the fly.

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=fb0c9f06132769336ab2f01f6b01e369f48f3575

commit fb0c9f06132769336ab2f01f6b01e369f48f3575
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Sun Jan 20 11:35:48 2013 +0100

    measurement: Add debug helper when we have a report for an inactive channel

http://cgit.osmocom.org/cgit//usr/local/git/repositories/osmo-bts/commit/?id=9d91c60875548cb7e74b51a3d6bb0ec1b001a672

commit 9d91c60875548cb7e74b51a3d6bb0ec1b001a672
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Tue Jan 22 15:45:14 2013 +0100

    sysmobts: Prepare to address the documented limitation of this code

-----------------------------------------------------------------------

Summary of changes:
 README                            |   2 +
 src/common/measurement.c          |   5 +
 src/osmo-bts-sysmo/l1_if.c        |  15 +-
 src/osmo-bts-sysmo/oml.c          | 563 +++++++++++++++++++++++++++++++-------
 src/osmo-bts-sysmo/sysmobts_vty.c |   2 +-
 5 files changed, 478 insertions(+), 109 deletions(-)

hooks/post-receive
-- 
Osmocom BTS-side code (Abis, scheduling, ...)