From: git repository hosting Precedence: list To: osmocom-commitlog@lists.osmocom.org Date: Wed, 27 Feb 2013 11:07:06 +0100 Message-ID: Subject: osmo-bts.git branch zecke/channel-release updated. 0.1.0-81-ge012c60 Message: 12 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 2775e3adadcbd29f84fbd87bc7b53a2347e693b8 (commit) discards 24c5844b8e621437f65e5532d0813956453a9516 (commit) discards cc1aecfa6818aaf67bad65dce36bd864cc077dbb (commit) discards 3c6856ddc2b65f6e3acd0323e9fb9d480d2a8a13 (commit) discards 4d5455e19a3ae7840341e781d72bc77606593d61 (commit) discards d09e52a4fb9184d35c627f42277eee7359fa8a8a (commit) discards 483fb36c9fedd530dcdc640b0645b4264933954e (commit) discards 78a6d278499f417d074385590cc69d53da1b39fa (commit) discards fb8e1ba71fbe64f0dff6116cf057c4f15513be94 (commit) discards bd4105de56f0ebd5a49218576741fda76a58071d (commit) discards 7403542a6672d59ee6c91a6b85149a21ca8509e3 (commit) discards bef4b895d55d6b0d2e1bf60d92f5e66d9645c2be (commit) discards 0d2e5d95697e3cedb1d1a7032fd59bdb2f13befb (commit) discards 2cdf0f5f8d4fd68aa2b46faba52d44a5dcd6c7f1 (commit) discards 451afe2e6caa1c5896cd9d837fe51225486d9cd9 (commit) discards 18d42b6845f22131a1eb31fe7f62cba28d83e9ee (commit) discards 78516650d1b5ab536f5ecfb8cc25aec12aa3e0eb (commit) discards 5a7eebb8f83d3f08cba76decc75be951304cbeb5 (commit) discards 1c69633314768ee3472b2adca6c21dcdf263784e (commit) discards 2ad2f88d9d2aa9f44204f494c2fafe3051acd1d0 (commit) discards 79cb61a276538bfdc5ee7881393757ff91260a00 (commit) discards ff8244751f456777675cbb53fbaeae38cb1ddac1 (commit) discards 67b711bbf9f3898ab229d6bcfd98596f132bf425 (commit) discards 00111ee41f72a754dca1c57510989f7171aa9996 (commit) via e012c60a0ac2631697878c9e3d486ac8c6dcdd4a (commit) via bc8fe424924ed2a032e35ae962088dc7bbde9562 (commit) via b96eb1a4092d2016cbc51940f915fb1d9bdada84 (commit) via 9d9db3b7fb34d361a9c429c52ce3b5979180b2aa (commit) via e887928cc99da33b3030aef394c2ddd4efbdd599 (commit) via f30c6d706e8387d9259d57e009390f79cc74b30d (commit) via 9f123eb2a866e9201e3d82e4116a5fd8f7bef6d8 (commit) via 8f72c5945cbcc862e9b85f54f8fc83da02ffd83d (commit) via a742f09e07051be7bd2d24d9ce0565f6fff5c93e (commit) via 57b17f7a02fb9e53257651e20d9cf79b8c801d07 (commit) via b6af3629cd51ef300d51266c5b5a0b6fec0f08fd (commit) via 76f4037ed523d2283ab6f05333950c64263d05be (commit) via d8ef5c0aa96fef9c99e1afd04f8e48a5e29c2158 (commit) via dd2a51ed32959033cf965dfb243dd8fa44574f59 (commit) via faba73a81230db1e549aa43b6a5ee7902b45f919 (commit) via 305d8314bce8f10d9c42aa8e19ccd7960fc5f194 (commit) via 5e46e4b4880f01eed508d49b66d96c1f7475ab89 (commit) via 3d383c22c7d1d290e498c7db652e7d1888245e43 (commit) via 654fe73b78993c6e421162c8a7b41f009d7d2e40 (commit) via 6142f9262adf197d60a31ab4636ac0886dc32316 (commit) via 64c5e3a19c94c29331414da30e9d8eca81a70fce (commit) via b6942ffeb9c5b742ca111a8c2b49a98e102da2fe (commit) via ff4f789249e9c26f268abd2e47f39627f4bbdd9d (commit) via 0890e274b1a1e82907dfa56a4f4bb067d22dca4c (commit) via 60b090ac5377e29ff5f2dc50cd19e81189dbbd73 (commit) via dc9148d0351878a79d689a9c6f60aff21b9d5b81 (commit) via 1897f03d4c854a0b74a92eb1f846ee1f0f81382b (commit) via 6ac2e684678a27f13966b7ae8d9937f43cb7adc9 (commit) via 225cf8229020e5474a5dc9824d012e50c2aa2ad8 (commit) via 18708dd3b60fa27e6a7121b686f11ee8c8069a4b (commit) via 98407bd457b88c1a26de2a9955de3de9846e4f68 (commit) via 0bb2974b370080b43282323364ebc6b0b6480803 (commit) via 550d22be5b2ddc376ccae937bd34c921dcf4a071 (commit) via 6a2d89f48d0727238eb2c14c7bfb4f0517d3be81 (commit) via 3ff2fc437884cc12633f15e51f9d4ce1053c857b (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 (2775e3adadcbd29f84fbd87bc7b53a2347e693b8) \ N -- N -- N (e012c60a0ac2631697878c9e3d486ac8c6dcdd4a) 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=e012c60a0ac2631697878c9e3d486ac8c6dcdd4a commit e012c60a0ac2631697878c9e3d486ac8c6dcdd4a 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=bc8fe424924ed2a032e35ae962088dc7bbde9562 commit bc8fe424924ed2a032e35ae962088dc7bbde9562 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=b96eb1a4092d2016cbc51940f915fb1d9bdada84 commit b96eb1a4092d2016cbc51940f915fb1d9bdada84 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=9d9db3b7fb34d361a9c429c52ce3b5979180b2aa commit 9d9db3b7fb34d361a9c429c52ce3b5979180b2aa Author: Holger Hans Peter Freyther 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/osmo-bts/commit/?id=e887928cc99da33b3030aef394c2ddd4efbdd599 commit e887928cc99da33b3030aef394c2ddd4efbdd599 Author: Holger Hans Peter Freyther 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/osmo-bts/commit/?id=f30c6d706e8387d9259d57e009390f79cc74b30d commit f30c6d706e8387d9259d57e009390f79cc74b30d 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. http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=9f123eb2a866e9201e3d82e4116a5fd8f7bef6d8 commit 9f123eb2a866e9201e3d82e4116a5fd8f7bef6d8 Author: Daniel Willmann Date: Fri Jan 4 00:14:11 2013 +0100 oml: Print out power setting in txpower completion callback http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=8f72c5945cbcc862e9b85f54f8fc83da02ffd83d commit 8f72c5945cbcc862e9b85f54f8fc83da02ffd83d Author: Daniel Willmann 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/osmo-bts/commit/?id=a742f09e07051be7bd2d24d9ce0565f6fff5c93e commit a742f09e07051be7bd2d24d9ce0565f6fff5c93e Author: Daniel Willmann Date: Thu Jan 3 20:55:12 2013 +0100 oml: Enqueue ciphering message through sapi cmd queue as well http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=57b17f7a02fb9e53257651e20d9cf79b8c801d07 commit 57b17f7a02fb9e53257651e20d9cf79b8c801d07 Author: Daniel Willmann 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/osmo-bts/commit/?id=b6af3629cd51ef300d51266c5b5a0b6fec0f08fd commit b6af3629cd51ef300d51266c5b5a0b6fec0f08fd Author: Holger Hans Peter Freyther 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/osmo-bts/commit/?id=76f4037ed523d2283ab6f05333950c64263d05be commit 76f4037ed523d2283ab6f05333950c64263d05be Author: Holger Hans Peter Freyther Date: Thu Jan 24 12:00:14 2013 +0100 sysmobts: Re-load the FPGA image and let some time pass before continuing We are not cleanly shutting down the DSP on exit so let us reset both the DSP and the FPGA. Also let some time pass to allow the DSP to properly initialize itself before starting to use it. This is not a fix but a band-aid for the unclean shutdown. http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=d8ef5c0aa96fef9c99e1afd04f8e48a5e29c2158 commit d8ef5c0aa96fef9c99e1afd04f8e48a5e29c2158 Author: Holger Hans Peter Freyther Date: Tue Jan 22 15:45:14 2013 +0100 sysmobts: Prepare to address the documented limitation of this code ----------------------------------------------------------------------- Summary of changes: contrib/sysmobts-calib/Makefile | 2 +- contrib/sysmobts-calib/sysmobts-calib.c | 53 +++++++++++++++++++++++-- contrib/sysmobts-calib/sysmobts-layer1.c | 29 ++++++++++---- contrib/sysmobts-calib/sysmobts-layer1.h | 3 +- include/osmo-bts/gsm_data.h | 1 - src/common/rsl.c | 64 ++++++++++++++++++++++++----- src/common/vty.c | 13 +----- src/osmo-bts-sysmo/l1_if.c | 2 +- 8 files changed, 130 insertions(+), 37 deletions(-) hooks/post-receive -- Osmocom BTS-side code (Abis, scheduling, ...)