From: git repository hosting Precedence: list To: osmocom-commitlog@lists.osmocom.org Date: Fri, 25 Jan 2013 21:37:10 +0100 Message-ID: Subject: osmo-bts.git branch zecke/channel-release updated. 0.1.0-70-g2c6c3a6 Message: 5 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, zecke/channel-release has been updated discards 0a0e6dcb66650e6f14760a7c43d0bf59e92e59fc (commit) discards 6f3f9a2ab1ae77a2dc7d290ba825e7af2eeb40da (commit) discards 22f646d24d0549a12029fd76a7beb46c39ad6e05 (commit) discards 36b7f0800b1dc9815833107d26376cbc428eede6 (commit) discards f266b38ced6ede774b0a1d998c81b44947211e50 (commit) discards 69221f499fbd30f1f60c60ba2fe08be1066026d7 (commit) discards 1050c078ae3bd16e0d491c58fdf3112a8108666c (commit) via 2c6c3a6aead6bf88a40ea28d45a7a6ba113bcda5 (commit) via a1c1d2d15c9fdef0fce535b0e040285c51f2d7f4 (commit) via 8963a2dbebe106ddf5f6ac7d68cd4ad92b07bfa5 (commit) via 3a41be4c71c92369052e561f2137247a033294fd (commit) via 511b4d36ea6d86c47f2dfbb118a8e7a333502c30 (commit) via d09e52a4fb9184d35c627f42277eee7359fa8a8a (commit) This update added new revisions after undoing existing revisions. That is to say, the old revision is not a strict subset of the new revision. This situation occurs when you --force push a change and generate a repository containing something like this: * -- * -- B -- O -- O -- O (0a0e6dcb66650e6f14760a7c43d0bf59e92e59fc) \ N -- N -- N (2c6c3a6aead6bf88a40ea28d45a7a6ba113bcda5) When this happens we assume that you've already had alert emails for all of the O revisions, and so we here report only the revisions in the N branch from the common base, B. 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/osmo-bts/commit/?id=2c6c3a6aead6bf88a40ea28d45a7a6ba113bcda5 commit 2c6c3a6aead6bf88a40ea28d45a7a6ba113bcda5 Author: Holger Hans Peter Freyther Date: Fri Jan 25 19:17:13 2013 +0100 wip http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=a1c1d2d15c9fdef0fce535b0e040285c51f2d7f4 commit a1c1d2d15c9fdef0fce535b0e040285c51f2d7f4 Author: Holger Hans Peter Freyther Date: Fri Jan 25 18:55:50 2013 +0100 sysmobts: Do not re-configure the mode when we are disabling the channel The common/rsl.c is already acking the channel modification and we can simply not queue anything when we are in the process of shutting down the lchan SAPIs. http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=8963a2dbebe106ddf5f6ac7d68cd4ad92b07bfa5 commit 8963a2dbebe106ddf5f6ac7d68cd4ad92b07bfa5 Author: Holger Hans Peter Freyther Date: Fri Jan 25 18:43:20 2013 +0100 oml: Only shut the bts down once If the shutdown timer is already running do not deactivate the RF and do not close the trx. This is addressing another instance of the following warning: [ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=3a41be4c71c92369052e561f2137247a033294fd commit 3a41be4c71c92369052e561f2137247a033294fd Author: Holger Hans Peter Freyther Date: Wed Jan 23 17:36:14 2013 +0100 WIP... try to overcome the short coming http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=511b4d36ea6d86c47f2dfbb118a8e7a333502c30 commit 511b4d36ea6d86c47f2dfbb118a8e7a333502c30 Author: Holger Hans Peter Freyther Date: Wed Jan 16 14:14:36 2013 +0100 DEBUGGING HELP release... WIP... http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=d09e52a4fb9184d35c627f42277eee7359fa8a8a commit d09e52a4fb9184d35c627f42277eee7359fa8a8a Author: Holger Hans Peter Freyther 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. ----------------------------------------------------------------------- Summary of changes: hooks/post-receive -- Osmocom BTS-side code (Abis, scheduling, ...)