Hi,
I already mentioned a strange behavior, sometimes when running osmocom for a few days. I think this is a different issue, because it happens more frequently and the situation is a bit different. This problem does not occur with a binary from june 2012. So it has to be some change between june and now.
But now the problem: When running a phone with the main branch (only tested), it sometime come to the situation that the phone says "connection pending" and is not reacting anymore. osmocon only logs periodically this line:
TOA AVG is not 16 qbits, correcting (got 15)
And mobile says:
<0003> gsm322.c:474 Sync to ARFCN=694(DCS) rxlev=-80 (No sysinfo yet, ccch mode NONE) <000e> gsm48_mm.c:353 Periodic location update <0005> gsm48_mm.c:355 timer T3212 (periodic loc. upd. delay) has fired <0005> gsm48_mm.c:4338 (ms 1) Received 'MM_EVENT_TIMEOUT_T3212' event in state MM IDLE, normal service <000e> gsm48_mm.c:2222 Perform location update (MCC 262, MNC 07 LAC 0x27e9) <0005> gsm48_mm.c:2356 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2378 using LAI (mcc 262 mnc 07 lac 0x27e9) <0005> gsm48_mm.c:2386 using TMSI 0xXXXXXXXX <0005> gsm48_mm.c:917 new state MM IDLE, normal service -> wait for RR connection (location updating) <0001> gsm48_rr.c:5575 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1352 Establish radio link due to mobility management request <0003> gsm322.c:4049 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:829 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3665 Going to camping (normal) ARFCN 664(DCS). <0003> gsm322.c:452 Sync to ARFCN=664(DCS), but there is a sync already pending <0001> gsm48_rr.c:355 new state idle -> connection pending <0001> gsm48_rr.c:1504 CHANNEL REQUEST: 00 (Location Update no NECI)
Mobile says nothing when shutting the phone off or on:
OsmocomBB(ms)#shutdown OsmocomBB(ms)# OsmocomBB(ms)#no shutdown OsmocomBB(ms)#
Only logs:
<0005> gsm48_mm.c:4342 (ms 1) Received 'MM_EVENT_IMSI_DETACH' event in state wait for RR connection (location updating) <0005> gsm48_mm.c:1992 IMSI detach delayed.
Killing and restarting mobile leads to:
eeepc:~ # mobile -i 127.0.0.1 Copyright (C) 2008-2010 ... Contributions by ...
License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
<000f> sim.c:1223 init SIM client <0006> gsm48_cc.c:63 init Call Control <0007> gsm480_ss.c:231 init SS <0017> gsm411_sms.c:63 init SMS <0001> gsm48_rr.c:5626 init Radio Ressource process <0005> gsm48_mm.c:1327 init Mobility Management process <0005> gsm48_mm.c:1040 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:5037 init PLMN process <0003> gsm322.c:5038 init Cell Selection process <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=01 Germany, T-Mobile) <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=07 Germany, O2) Mobile '1' initialized, please start phone now! VTY available on port 4247.
And layer1 still logs some:
TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15)
Has anybody a clue how this could happen from time to time?
Cheers
Tim
On Fri, 11 Jan 2013, Tim Ehlers wrote:
Hi,
TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15)
Has anybody a clue how this could happen from time to time?
mhh, I reply to myself, since nobody seems to have that problem too?
In the meantime I made further inverstigations and came to the conclusion that theses crashes are related to the layer1. When using a new mobile and osmocon application, but the old layer1: no crash.
And I should mention that I have a C118 (e88) phone. I newly got a e99 phone and interestingly this phone doesn't crash with current layer1. But before you think the hardware is broken. I have several e88 phones and all of them behave the same.
In the past I used the pre-compiled cross-compiler gnuarm-3.4.3. According to the new Wiki-pages I compiled the combi binutils-2.21.1, newlib-1.19.0 and gcc-4.5.2. Tried it with e88 and e99 during the night. Today e88 crashed again.
So do I have a special cell here (SIMs are from german O2 prepaid platform) causing crashes to layer1 (e88)? Or what is special here?
I made a diff between working and not working compal_e88 directory, but the changes are only some kind of irq-changes, like:
- calypso_bootrom(1); + calypso_bootrom(with_irq);
and so on. I think this is not the problem, or could it open a race condition? But why am I the only one with this problem?
Has anybody a suggestion, what I could test to track the problem down?
Cheers
Tim
baseband-devel@lists.osmocom.org