Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi Harald,
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
> Can you or somebody else interested in getting this resolved provide a
> full bug report, including
> * debug log output on OsmoNITB side for for the rsl and nm
> * debug log output on OsmoBTS side for oml / transceiver interface or
> anything else related
> * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
> the control commands between osmo-bts-trx and osmo-trx
Attached are the logs for master branches of OpenBSC, OsmoBTS, and
OsmoTRX leading up to the following RACH access behavior.
<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2
Hopefully, somebody more familiar than myself with A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging. I'll be happy to test any
subsequent changes or look into specific parts of the A-bis code.
-TT
> Date: Fri, 27 May 2016 18:02:28 +0200
> From: Pierre Baudry <pierre.baudry(a)diateam.net>
> I noticed that since several weeks that osmo-pcu did not work as good as
> previously.
Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses NuRAN hardware with osmo-bts-sysmo
> The latest "good" revision I am aware of is commit
> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
This is a useful information for us that the above mentioned commit works for GPRS.
> Can somebody confirm or reproduce this attitude ?
The PCU log that we have during failure matches with the one you have reported.
We have tried a workaround for this GPRS call failure by forcing two-phase-access in osmo-pcu.cfg.
Based on our analysis done till now it seems One phase access of GPRS is broken.
> I will try to provide more logs and a pcap capture as soon as I get
> hands back on the hardware.
It will be quite useful to narrow down the issue, so please share the relevant logs collected
Regards
Saurabh
Hi,
we have the first round of contributions through Gerrit and maybe now is a good time to look at the mail setup. My goal was to:
* Have diff's/patches be sent to the MailingList to see what is going on
* Have comments be sent to the MailingList to have people learn from feedback
In terms of technology Gerrit offers us the following notifications[1]
new_changes Somebody created a new change
new_patchsets Somebody updated/added a patch(set) to a change
all_comments Somebody but jenkins commented
submitted_changes Somebody has pushed the submit button and it is in
abandoned_changes Somebody gave up on the change
all Everything
Currently we are using "all" and maybe we want to limit it to "new_patchsets" and "all_comments". "all_comments" is a bit troublesome as it includes empty messages like "+2" with actual review comments.
What would be the close to ideal solution?
* Be able to reply by mail to changes (most likely not to come)
* Mails sent have the author name as From (but gerrit mail address)?
* Empty mails like "+2" not sent to the Mailinglist?
* Subject changed? [PATCH] and omit branch name? Or omit project name?
Other proposals? Move it to a new mailinglist and leave OpenBSC as low-volume mailinglist?
comments? feedback? ideas?
holger
[1] https://gerrit-review.googlesource.com/Documentation/user-notify.html#notif…
Hi all,
I have just changed the access configuration of gerrit.osmocom.org:
* added a group of "known users"
* allow create+push to refs/heads/users/* to this group
* disallow access to refs/users/* (except to admins for cleanup)
* added a sysmocom group
* allow create+push to refs/heads/sysmocom/* to this group
Questions:
* allow global namespace access to "known users"?
* or move old user branches to users/?
Causality:
Previously, gerrit granted create+push access to refs/users/* (note: no
"heads") to anybody. However, branches pushed there were not being replicated
to git.osmocom.org. IMHO we should not have this fragmentation of repositories.
Instead, we could allow create+push to refs/heads/users/* (note: "heads") to
any registered user. The refs/heads/users/* namespace will replicate to
git.osmocom.org repositories automatically. But:
Before gerrit, anyone would be able to push to any branch. We relied on trust
that we wouldn't mess with other devs' branches or push to master without
review. That worked out pretty well. But, before gerrit, we would actively
enable users we trust. With gerrit, ANYONE can register without any project
member even noticing, and start pushing right away. Thus we should rather
limit the push access, e.g. to refs/heads/users/*
When granting push access to the users/* namespace to ANYONE, one problem
remains: any troll could commit any amount of completely unrelated data, and we
would readily replicate it to our "upstream" git.osmocom.org repositories.
So, actually, instead of allowing push access to users/* to anyone, I have
added a group "known users" to gerrit, which should typically contain anyone we
trust not to be a troll. I have added all gerrit users I know to this group.
Anyone who wishes to push to a users/* branch must request to be added to the
"known users" group. The threshold to join this group should be low.
(The ability to push patches for review is not affected.)
Since certain subgroups like to collaborate on given branches (e.g. fairwaves,
sysmocom, ...), we can add specific namespaces for these groups. I have so far
added a refs/heads/sysmocom/* namespace and a "sysmocom group access" gerrit
group. I can add more groups on request. The only advantage here is that you
can drop the "users/" path element. Any "known users" member can collaborate on
users/* branches already, e.g. refs/heads/users/sysmocom/topic.
To make this less config prone, we could go one step further and allow global
push access to the group of known users, going back to the model of trust that
users take care not to push nonsense. That would include access to master. We
also still have various branches in git.osmocom.org that don't have the 'users'
path element. If we grant global namespace access to known users, these would
continue to be useful. If not, we could rename these to users/ to allow further
access.
Opinions welcome!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi all,
I have a Osmocom setup running with a Ettus B200
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
The latest "good" revision I am aware of is commit
d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
I tried again today with commit 2fcfc29020c81891d7888ddc7ddbcd866bcd406d
(2016/05/24) and not a single handset could establish data communication
Reading osmo-pcu logs show that T6169 timeouts during TBF assignment :
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:479 MS requests UL TBF on RACH, so we provide one:
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here **********
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:407 Searching for first unallocated TFI: TRX=0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:417 Found TFI=0.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)".CCCCCCC"(TS=7)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"...U...."(TS=7), single
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 3 for UL
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"...C...."(TS=7)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 3
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 3, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 3
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 08, dl_slots = 00
> Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:523 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:527 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x7b, Fn=1607859 (28,33,19)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:529 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:542 - TRX=0 (128) TS=3 TA=0 TSC=3 TFI=0 USF=0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired.
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free
Every element of the stack is running with today's revision on master
(cheers for making it happen without specific branches by the way).
With the same setup with
osmo-pcu@d87e1d6ab747423d3668c74d16201a5d967accf0, I get solid data
rates around 40 Kbits/s.
I haven't seen anybody on the mailing list experiencing the same
behavior, making me believe that it could be specific to osmo-bts-trx /
osmo-trx users.
Can somebody confirm or reproduce this attitude ?
I will try to provide more logs and a pcap capture as soon as I get
hands back on the hardware.