Hi,
the default build is broken since the 17th of october. Anynone
feels responsible to fix it after the merge?
Build results can be seen here[1]. It probably has to with enabling
sysmobts support but not direct PDCH queue access.
holger
[1] http://jenkins.osmocom.org/jenkins/job/osmo-pcu/label=linux_i386_debian_squ…
Dear all,
it is a pity to see that since many weeks there has been no progress on
merging any of Andreas' work. I think everyone involved is to be
blamed to some extent. Andreas because the provided branches are not
kept clean, Ivan probably for lack of time, and me for not paying more
attention and helping this process along.
The general life-cycle in any project, including osmo-pcu, should be as
follows:
* contributor starts on some improvements, creates private branch
* master advances meanwhile
* contributor rebases (not merges!) his changes on top of more recent
master
* contributor indicates that his branch is ready for merge
* maintainer merges (some of?) the commits of the contributor branch
* contributor re-bases remaining commits on new master
* contributor requests merge of remaing patches
...
If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I
get grey hair (to say the least). One would normally expect:
1) 'jolly' to be based on some (maybe not current) master
2) 'jolly_dsp' to be based on 'jolly'
Neither of the two is the case. I've tried to
* rebase jolly on top of master
as well as
* rebase jolly_dsp on top of jolly
and both are impossible due to the series of merges and the unclear
ancestry / relationship of the branches. Or, just for fun, try 'git
diff origin/jolly..origin/jolly_dsp. It shows you anything else but
what one would expect
Andreas: Please take some time to clean up the mess. Your 'jolly'
branch should contain a series of clean per-feature commit's on top of
current master, and 'jolly_dsp' should be a set of few patches on top of
'jolly'.
This way there is always a clean queue of changesets that Ivan can merge
(or cherry-pick). I can understand that if I was in Ivan's place, I
would not really know where to even start merging some of those
contributions.
Thanks for everyone's attention. Please take some time to get this
resolved. Let me know if you have some questions. There are plenty of
people with lots of git experience around (Holger, Pablo, myself) who
can help if something is unclear.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
while running osmo-pcu, it appears that it is leaking memory. At
startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2),
while after about 8MBytes of data transfer of a single GPRS-MS over 48
hours, the virtual size has expanded to 8584 kBytes.
Now I know that VSS is not RSS, etc. - but the fact that it always only
increasees, and increases with traffic is a clear indication of some
leakage somewehere.
Unfortunately it also seems talloc is not used correctly in osmo-pcu, as
a USR1 signal doesn't really show any allocated objects beyond two. So
somehow either not all allocations are done with talloc, or the
allocation hierarchy does not link the objects to the root talloc
context.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Not sure if this is expected or not, I thought it might be useful to
report it here:
<0001> pcu_l1_if.cpp:295 RACH request received: sapi=1 qta=2, ra=121, fn=12615
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for DL TBF=1
<0005> gprs_rlcmac_data.cpp:872 Got RACH from TLLI=0xc65c8728 while DL TBF=1 still exists. Killing pending DL TBF
<0002> gprs_rlcmac.cpp:905 Software error: Pending downlink assignment. This may not happen, because the assignment message never gets transmitted. Please be shure not to free in this state. PLEASE FIX!
This is a single BTS with a single GPRS-capable MS, using TS6+TS7 for
PDCH
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi,
i get wrong decoding of RLCMAC control block.
the decoder of osmo-pcu is decoding following sequence:
0x40,0x16,0x76,0x67,0x74,0x02,0x26,0x64,0xe8,0x65,0x64,0x69,0x00,0x3e,0x4c,0x00,0x2b,0x2b,0x2b,0x2b,0x2b,0x2b,0x2
this is the result:
PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
Exist_ACCESS_TYPE = 1 | ACCESS_TYPE = 0 | : ID | Choice
PacketResourceRequestID = 1 | u.TLLI = 0xd99dd008 | : End ID |
Exist_MS_Radio_Access_capability = 1 | : MS_Radio_Access_capability |
MS_RA_capability_value[0] { | Choice MS_RA_capability_value_Choice = 3 |
u.Content length = 25
... at this point, the length of the content is 25 bits:
| RF_Power_Capability = 1 | Exist_A5_bits = 1 | A5_bits = 80 | ES_IND =
1 | PS = 1 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 | :
Multislot_capability | Exist_HSCSD_multislot_class = 0 |
Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 12 |
GPRS_Extended_Dynamic_Allocation_Capability = 1 | Exist_SM = 0
... at this point all 25 bits are decoded, so the decoder must abort
decoding of content of Multislot_capability_t (see gsm_rlcmac.cpp).
instead, it continues with the data found after these 25 bits: (all crap
from now on)
| Exist_ECSD_multislot_class = 0 | Exist_EGPRS_multislot_class = 0 |
Exist_DTM_GPRS_multislot_class = 1 | DTM_GPRS_multislot_class = 2 |
Single_Slot_DTM = 1 | : DTM_EGPRS_Params |
Exist_DTM_EGPRS_multislot_class = 0 | : End DTM_EGPRS_Params | : End
Multislot_capability | Exist_Eight_PSK_Power_Capability = 0 |
COMPACT_Interference_Measurement_Capability = 1 |
Revision_Level_Indicator = 0 |
UMTS_FDD_Radio_Access_Technology_Capability = 0 |
UMTS_384_TDD_Radio_Access_Technology_Capability = 0 |
CDMA2000_Radio_Access_Technology_Capability = 0 |
UMTS_128_TDD_Radio_Access_Technology_Capability = 0 |
GERAN_Feature_Package_1 = 0 | Exist_Extended_DTM_multislot_class = 0 |
Modulation_based_multislot_class_support = 0 |
Exist_HighMultislotCapability = 0 | Exist_GERAN_lu_ModeCapability = 0 |
GMSK_MultislotPowerProfile = 3 | EightPSK_MultislotProfile = 3 |
MultipleTBF_Capability = 1 | DownlinkAdvancedReceiverPerformance = 0 |
ExtendedRLC_MAC_ControlMessageSegmentionsCapability = 1 |
DTM_EnhancementsCapability = 0 | Exist_DTM_GPRS_HighMultislotClass = 0 |
PS_HandoverCapability = 1 | MS_RA_capability_value[0] } |
MS_RA_capability_value[0] { | Choice MS_RA_capability_value_Choice = 0 |
u.Content length = 0 | RF_Power_Capability = 2 | Exist_A5_bits = 1 |
A5_bits = 50 | ES_IND = 1 | PS = 0 | VGCS = 1 | VBS = 1 |
Exist_Multislot_capability = 0 | Exist_Eight_PSK_Power_Capability = 0 |
COMPACT_Interference_Measurement_Capability = 1 |
Revision_Level_Indicator = 0 |
UMTS_FDD_Radio_Access_Technology_Capability = 1 |
UMTS_384_TDD_Radio_Access_Technology_Capability = 0 |
CDMA2000_Radio_Access_Technology_Capability = 1 |
UMTS_128_TDD_Radio_Access_Technology_Capability = 1 |
GERAN_Feature_Package_1 = 0 | Exist_Extended_DTM_multislot_class = 0 |
Modulation_based_multislot_class_support = 1 |
Exist_HighMultislotCapability = 0 | Exist_GERAN_lu_ModeCapability = 1 |
GERAN_lu_ModeCapability = 6 | GMSK_MultislotPowerProfile = 1 |
EightPSK_MultislotProfile = 1 | MultipleTBF_Capability = 0 |
DownlinkAdvancedReceiverPerformance = 3 |
ExtendedRLC_MAC_ControlMessageSegmentionsCapability = 0 |
DTM_EnhancementsCapability = 0 | Exist_DTM_GPRS_HighMultislotClass = 1 |
DTM_GPRS_HighMultislotClass = 2 | : DTM_EGPRS_HighMultislotClass |
Exist_DTM_EGPRS_HighMultislotClass = 1 | : End
DTM_EGPRS_HighMultislotClass | : End MS_Radio_Access_capability |
there are two problems with the decoder:
- it does not check if the length has been exceeded while decoding
Multislot_capability_t content. if the length is lower than all elements
in Multislot_capabilit_t, the decoder must abort decoding the content.
this is no bug. (the definition used at that point should be
M_NEXT_EXIST_OR_NULL instead of M_NEXT_EXIST, see gsm_rlcmac.cpp)
- even if the correct definition is used, the csn1 decoder will not use
the length given at "u.Content length" to abort. instead it checks for
reaching total length of coded data.
i played a bit with the code, but could not fix it without breaking
other things. but decoding with wireshark works. would it be possible to
port latest wireshark code?
regards,
andreas
hi,
just experiences some problems with my jolly branch (osmo-pcu):
commit e6228b34a75efcb6b0700ac29672d62539860fbf
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Tue Jul 3 13:36:03 2012 +0200
TBF acknowledged mode finished for both link directions
commit c7e7f6868b6f24346424dee904f4e76d3f216ff4
Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com>
Date: Fri Jun 29 22:53:15 2012 +0400
Implemented Paging procedure on CCCH.
Added functions:
- gprs_bssgp_pcu_rx_paging_ps() for handling paging message from BSSGP;
- write_paging_request() for writing paging request message;
- gprs_rlcmac_paging_request() and pcu_l1if_tx_pch() for sending
paging request message to BTS.
the lower commit adds paging procedure, but if i diff between these
commits, i see that my upper commit removes the paging procedure. but i
don't see it, if i "git show e6228b...". any ideas?
regards,
andreas