Hi,
I have a git clone from 23.01.2012 and a current git clone.
When I compile both and use the mobile appliation, I have a strange problem in the current code. Very often I can't send USSD codes (and maybe also can't communicate in other ways; USSD is the costless way to check whether I am connected or not).
Ok, this is what I do: I send "service 1 *#21#", wait the answer and the string "% On Network, normal service: Germany, O2". Then send it again and so on.
With the old code, I reliable get the answer e.g. "% Status: deactivated". With the new code, I very often (sometime already when trying first time) get nothing back and after some seconds only "% Service connection terminated.".
Can someone confirm this behavior?
Thanks
Tim
On Sun, 19 Feb 2012, Tim Ehlers wrote:
Hi,
(just to tell everyone)
When I compile both and use the mobile appliation, I have a strange problem
I can now say its not the mobile application (layer23). Its the new layer1. When using the current mobile application with the old layer1.compalram.bin, its working.
Cheers
Tim
On Sun, 19 Feb 2012, Sylvain Munaut wrote:
Hi Sylvain,
I can now say its not the mobile application (layer23). Its the new layer1. When using the current mobile application with the old layer1.compalram.bin, its working.
Define "old" ....
Are you using the sylvain/testing branch in both case ?
no, shall I? :)
I just checked out the main branch:
git clone git://git.osmocom.org/osmocom-bb.git
The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds.
Cheers
Tim
Hi,
Are you using the sylvain/testing branch in both case ?
no, shall I? :)
Yes :)
there is an ugly hack to workaround a known issue ...
The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
Cheers,
Sylvain
Sylvain Munaut wrote:
The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
Run e.g. git show and it's the first line.
//Peter
On Sun, 19 Feb 2012, Peter Stuge wrote:
The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
Run e.g. git show and it's the first line.
ahh, you mean the commit id from working tree? It should be 2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't know since when (after this commit) the problem exists.
Cheers
Tim
Tim Ehlers wrote:
Do you have commit id ?
Run e.g. git show and it's the first line.
ahh, you mean the commit id from working tree? It should be 2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't know since when (after this commit) the problem exists.
In the newer clone you can also check the commit id, then git bisect can be used to find which commit introduced the problem.
http://book.git-scm.com/5_finding_issues_-_git_bisect.html http://progit.org/book/ch6-5.html
//Peter
On Sun, 19 Feb 2012, Sylvain Munaut wrote:
Are you using the sylvain/testing branch in both case ?
no, shall I? :)
Yes :)
there is an ugly hack to workaround a known issue ...
ok, I try that tomorrow.
The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds.
Do you have commit id ?
no, thats the problem. I checked out at 23.01. and the current git. I know, the tree from 23.01. has a working layer1 (what I wrote in first mail).
I would tip, that it has to do with the 'git-subtree' update from Harald, where he wrote:
Nonetheless, if you experience strange new problems, the libosmocore update might be a possible cause.
But its just a guess.
Tim
Le 19/02/12 18:30, Tim Ehlers a écrit :
Hi,
I have a git clone from 23.01.2012 and a current git clone.
When I compile both and use the mobile appliation, I have a strange problem in the current code. Very often I can't send USSD codes (and maybe also can't communicate in other ways; USSD is the costless way to check whether I am connected or not).
Ok, this is what I do: I send "service 1 *#21#", wait the answer and the string "% On Network, normal service: Germany, O2". Then send it again and so on.
With the old code, I reliable get the answer e.g. "% Status: deactivated". With the new code, I very often (sometime already when trying first time) get nothing back and after some seconds only "% Service connection terminated.".
Can someone confirm this behavior?
Hi,
I have the same problem (testing with a C123). When this problem occurs, I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: 24". With git bisect, I localize the first commit showing this issue as 7cc4a4b ( Improvement of neighbour cell power measurement task).
Hope this help,
Cheers,
Jean-Pierre
Hi,
I have the same problem (testing with a C123). When this problem occurs, I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: 24". With git bisect, I localize the first commit showing this issue as 7cc4a4b ( Improvement of neighbour cell power measurement task).
Oh yes, that commit looks like a very bad idea ... neigh measurement should always be on TN 0 ...
Can you try to undo that chunk :
diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c index 07b7209..1630600 100644 --- a/src/target/firmware/layer1/prim_pm.c +++ b/src/target/firmware/layer1/prim_pm.c
@@ -175,7 +175,8 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas, * num_meas > 1 */ /* do measurement dummy, in case l1s.neigh_pm.n == 0 */ l1s_rx_win_ctrl((l1s.neigh_pm.n) ? - l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0); + l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, + L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]);
/* restore last gain */ rffe_set_gain(last_gain);
And check if it improves things.
Cheers,
Sylvain
Le 20/02/12 13:14, Sylvain Munaut a écrit :
Hi,
I have the same problem (testing with a C123). When this problem occurs, I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: 24". With git bisect, I localize the first commit showing this issue as 7cc4a4b ( Improvement of neighbour cell power measurement task).
Oh yes, that commit looks like a very bad idea ... neigh measurement should always be on TN 0 ...
Can you try to undo that chunk :
Hi Sylvain,
I applied this patch:
diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index 3af2f67..0e0ec8b 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -95,7 +95,7 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm -include Makefile.inc
# Uncomment this line if you want to enable Tx (Transmit) Support. -#CFLAGS += -DCONFIG_TX_ENABLE +CFLAGS += -DCONFIG_TX_ENABLE
# Uncomment this line if you want to write to flash. #CFLAGS += -DCONFIG_FLASH_WRITE diff --git a/src/target/firmware/board/compal/highram.lds b/src/target/firmware/board/compal/highram.lds index 498a2fa..41786d3 100644 --- a/src/target/firmware/board/compal/highram.lds +++ b/src/target/firmware/board/compal/highram.lds @@ -16,9 +16,9 @@ MEMORY /* lowram: could be anything, we place exception vectors here */ XRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 /* highram binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00014000 + LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00015000 /* highram binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00834000, LENGTH = 0x0000c000 + IRAM (rw) : ORIGIN = 0x00835000, LENGTH = 0x0000c000 } SECTIONS { diff --git a/src/target/firmware/board/compal/ram.lds b/src/target/firmware/board/compal/ram.lds index 9503ede..acc72ca 100644 --- a/src/target/firmware/board/compal/ram.lds +++ b/src/target/firmware/board/compal/ram.lds @@ -11,9 +11,9 @@ ENTRY(_start) MEMORY { /* compal-loaded binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00014000 + LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00015000 /* compal-loaded binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00814000, LENGTH = 0x0000c000 + IRAM (rw) : ORIGIN = 0x00815000, LENGTH = 0x0000c000 } SECTIONS { diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c index 1630600..84b5161 100644 --- a/src/target/firmware/layer1/prim_pm.c +++ b/src/target/firmware/layer1/prim_pm.c @@ -175,8 +175,7 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas, * num_meas > 1 */ /* do measurement dummy, in case l1s.neigh_pm.n == 0 */ l1s_rx_win_ctrl((l1s.neigh_pm.n) ? - l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, - L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]); + l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0);
/* restore last gain */ rffe_set_gain(last_gain);
The issue is not solved with this. I still have plenty DSP Error Status in the Layer1 output (in attachment). And I can not request any service (*#21# for exemple).
Cheers,
Jean-Pierre
On Mon, 20 Feb 2012, Jean-Pierre Szikora wrote:
Hi,
I have the same problem (testing with a C123). When this problem occurs, I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: 24". With git bisect, I localize the first commit showing this issue as 7cc4a4b ( Improvement of neighbour cell power measurement task).
Hope this help,
yes, very much. I had problems with bisect. It told me, that there are more than 550 revisions to check and most of them where older than the bad one... So you findings helped me to track the problem down to this:
--- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100 +++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100 @@ -200,7 +200,11 @@
/* Measurement for MF 51 */ static const struct mframe_sched_item mf_neigh_pm51[] = { - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 }, { .sched_set = NULL } };
in the changeset 7cc4a4b324bcf65b5d383faf2b3e727953c8df81.
Not that I would understand what this means... :)
Harald can you fix your changes with that info?
Thanks
Tim
On Mon, 20 Feb 2012, Sylvain Munaut wrote:
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning current git, reverting the part from the commit I wrote, I made 10 "service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
Cheers
Tim
Le 20/02/12 20:23, Tim Ehlers a écrit :
On Mon, 20 Feb 2012, Sylvain Munaut wrote:
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning current git, reverting the part from the commit I wrote, I made 10 "service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
I tested it also. Service and SMS sending is working, but regular call is still broken (still plenty DSP Error Status in Layer1 output).
Cheers,
Jean-Pierre
On Tue, 21 Feb 2012, Jean-Pierre Szikora wrote:
Hi,
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning current git, reverting the part from the commit I wrote, I made 10 "service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
I tested it also. Service and SMS sending is working, but regular call is still broken (still plenty DSP Error Status in Layer1 output).
yesterday I made a quick call test and you are right, calling is still broken. I could call a number, it is ringing and after pickup the call is released (that happend in my quick test yesterday; I didn't have the time to test more/again).
Could someone check this too? Is there someone, not having problems in the current git?
Cheers,
Tim
yesterday I made a quick call test and you are right, calling is still broken. I could call a number, it is ringing and after pickup the call is released (that happend in my quick test yesterday; I didn't have the time to test more/again).
Did you use the sylvain/testing branch as a base this time ?
Cheers,
Sylvain
On Thu, 23 Feb 2012, Sylvain Munaut wrote:
Hi Sylvain,
yesterday I made a quick call test and you are right, calling is still broken. I could call a number, it is ringing and after pickup the call is released (that happend in my quick test yesterday; I didn't have the time to test more/again).
Did you use the sylvain/testing branch as a base this time ?
as I can see you mean this patch, right?:
http://bb.osmocom.org/trac/changeset/fe3c81ecc454266b0ccd14a3c0f502db1413f04...
It's the only difference between master and sylvain/testing.
This patch I tried. It doesn't change a thing in this issue. And the call yesterday was your testing branch plus:
--- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100 +++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100 @@ -200,7 +200,11 @@ /* Measurement for MF 51 */ static const struct mframe_sched_item mf_neigh_pm51[] = { + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 }, { .sched_set = NULL } };
Cheers
Tim
On Thu, 23 Feb 2012, Tim Ehlers wrote:
Hi,
So reverting that commit fixes your issues ?
yes, it seems so. I mean I don't have longterm tests now, but cloning current git, reverting the part from the commit I wrote, I made 10 "service 2 *#21#" in a row without problems.
So I assume, that this fixes the issue.
I tested it also. Service and SMS sending is working, but regular call is still broken (still plenty DSP Error Status in Layer1 output).
yesterday I made a quick call test and you are right, calling is still broken. I could call a number, it is ringing and after pickup the call is released (that happend in my quick test yesterday; I didn't have the time to test more/again).
Could someone check this too? Is there someone, not having problems in the current git?
just to acknowledge this patch from Andreas:
http://bb.osmocom.org/trac/changeset/e7997163b240168301d7d2988f2cd74ae1f397e...
it fixes the issues I had. Now everything is working again.
Thanks Andreas.
Tim
baseband-devel@lists.osmocom.org
-
Jean-Pierre Szikora -
Peter Stuge -
Sylvain Munaut -
Tim Ehlers