From laforge at gnumonks.org Tue Jan 15 12:29:19 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jan 2013 13:29:19 +0100 Subject: Error: PLEASE FIX Message-ID: <20130115122919.GS21525@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Jan 15 16:42:58 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jan 2013 17:42:58 +0100 Subject: Suspected memory leak in PCU Message-ID: <20130115164258.GG16852@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Tue Jan 15 17:18:38 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 15 Jan 2013 21:18:38 +0400 Subject: Suspected memory leak in PCU In-Reply-To: <20130115164258.GG16852@prithivi.gnumonks.org> References: <20130115164258.GG16852@prithivi.gnumonks.org> Message-ID: Harald, Thanks for the observation. It would be great if this is filed to a bag tracker. Could you please setup one for osmo-pcu and create this as a ticket there? On Tue, Jan 15, 2013 at 8:42 PM, Harald Welte wrote: > 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 http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From andreas at eversberg.eu Tue Jan 15 18:03:20 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 15 Jan 2013 19:03:20 +0100 Subject: Error: PLEASE FIX In-Reply-To: <20130115122919.GS21525@prithivi.gnumonks.org> References: <20130115122919.GS21525@prithivi.gnumonks.org> Message-ID: <50F599E8.6030603@eversberg.eu> Harald Welte wrote: > 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 > thanx for that info. will check that tomorrow. From andreas at eversberg.eu Tue Jan 15 18:47:47 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 15 Jan 2013 19:47:47 +0100 Subject: Suspected memory leak in PCU In-Reply-To: <20130115164258.GG16852@prithivi.gnumonks.org> References: <20130115164258.GG16852@prithivi.gnumonks.org> Message-ID: <50F5A453.3060509@eversberg.eu> Harald Welte wrote: > while running osmo-pcu, it appears that it is leaking memory. hmm, sounds strange, but i will check that too.... From andreas at eversberg.eu Wed Jan 16 08:25:18 2013 From: andreas at eversberg.eu (jolly) Date: Wed, 16 Jan 2013 09:25:18 +0100 Subject: Suspected memory leak in PCU In-Reply-To: <20130115164258.GG16852@prithivi.gnumonks.org> References: <20130115164258.GG16852@prithivi.gnumonks.org> Message-ID: <50F663EE.1030101@eversberg.eu> Harald Welte wrote: > 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. > > hi harald, i just pushed the fix to jolly_merge branch. the memory leak happened for each data message from SGSN to PCU. the bitvector used for parsing ms-class was not freed. additionally i included the bitvector's talloc context into the global PCU's talloc context, so one can find out if it leaks. regards, andreas From andreas at eversberg.eu Wed Jan 16 08:32:50 2013 From: andreas at eversberg.eu (jolly) Date: Wed, 16 Jan 2013 09:32:50 +0100 Subject: Error: PLEASE FIX In-Reply-To: <20130115122919.GS21525@prithivi.gnumonks.org> References: <20130115122919.GS21525@prithivi.gnumonks.org> Message-ID: <50F665B2.8050201@eversberg.eu> Harald Welte wrote: > 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 > > hi harald, please pull from jolly_merge branch. i applied several fixes to the multislot allocation algorithm. i just tested it with the fixes and it worked here. regards, andreas From hfreyther at sysmocom.de Wed Jan 16 10:06:11 2013 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 16 Jan 2013 11:06:11 +0100 Subject: Error: PLEASE FIX In-Reply-To: <50F665B2.8050201@eversberg.eu> References: <20130115122919.GS21525@prithivi.gnumonks.org> <50F665B2.8050201@eversberg.eu> Message-ID: <20130116100611.GD15420@xiaoyu.lan> On Wed, Jan 16, 2013 at 09:32:50AM +0100, jolly wrote: > please pull from jolly_merge branch. i applied several fixes to the > multislot allocation algorithm. i just tested it with the fixes and it > worked here. Hi, the commit 97644ed7 contains '#if 0' to remove the limit of four TS. Is this a left over from debugging? holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From laforge at gnumonks.org Wed Jan 16 10:31:11 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Jan 2013 11:31:11 +0100 Subject: Suspected memory leak in PCU In-Reply-To: <50F663EE.1030101@eversberg.eu> References: <20130115164258.GG16852@prithivi.gnumonks.org> <50F663EE.1030101@eversberg.eu> Message-ID: <20130116103111.GT16852@prithivi.gnumonks.org> Hi Jolly, On Wed, Jan 16, 2013 at 09:25:18AM +0100, jolly wrote: > the memory leak happened for each data message from SGSN to PCU. the > bitvector used for parsing ms-class was not freed. thanks for the quick fix. > additionally i included the bitvector's talloc context into the global > PCU's talloc context, so one can find out if it leaks. If you find the time (it's not urgent) it might be worth to audit the code to make sure that all allocations are part of the talloc context hierarchy. Given that the report only showed two allocations in the version I used yesterday, I think the ms-class bit-vector might not be the only data structure that is not properly referenced to the context. I would have expected to see at least some persistent structures like all the currently active TBFs. Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Wed Jan 16 12:54:47 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 16 Jan 2013 13:54:47 +0100 Subject: Suspected memory leak in PCU In-Reply-To: <20130116103111.GT16852@prithivi.gnumonks.org> References: <20130115164258.GG16852@prithivi.gnumonks.org> <50F663EE.1030101@eversberg.eu> <20130116103111.GT16852@prithivi.gnumonks.org> Message-ID: <50F6A317.2030805@eversberg.eu> Harald Welte wrote: > If you find the time (it's not urgent) it might be worth to audit the > code to make sure that all allocations are part of the talloc context > hierarchy. Given that the report only showed two allocations in the > version I used yesterday, I think the ms-class bit-vector might not be > the only data structure that is not properly referenced to the context. > I would have expected to see at least some persistent structures like > all the currently active TBFs. hi harald, the committed fix shows all bit-vector allocations in the report, not only ms-class' bit vector. additionally i checked that all allocated bit vectors are freed. (this is how i found the bug.) there is currently no other talloc (at run time) that does not use the global PCU's context, so a USR1 signal (or terminating the process) would show all leaking allocations. i just added the use of PCU's talloc context when creating libosmogb's NS instance. regards, andreas From andreas at eversberg.eu Wed Jan 16 12:57:32 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 16 Jan 2013 13:57:32 +0100 Subject: Error: PLEASE FIX In-Reply-To: <20130116100611.GD15420@xiaoyu.lan> References: <20130115122919.GS21525@prithivi.gnumonks.org> <50F665B2.8050201@eversberg.eu> <20130116100611.GD15420@xiaoyu.lan> Message-ID: <50F6A3BC.8000301@eversberg.eu> Holger Hans Peter Freyther wrote: > the commit 97644ed7 contains '#if 0' to remove the limit of four TS. Is > this a left over from debugging? hi holger, i removed the limit, because i just don't know why i added this in the past. in case there is a good reason to re-add this in the future, i wanted to keep that code. regards, andreas From laforge at gnumonks.org Wed Jan 16 17:01:54 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Jan 2013 18:01:54 +0100 Subject: Suspected memory leak in PCU In-Reply-To: <50F6A317.2030805@eversberg.eu> References: <20130115164258.GG16852@prithivi.gnumonks.org> <50F663EE.1030101@eversberg.eu> <20130116103111.GT16852@prithivi.gnumonks.org> <50F6A317.2030805@eversberg.eu> Message-ID: <20130116170154.GD8380@prithivi.gnumonks.org> Hi Andreas, just a quick feedback: I can confirm that the memory leak is gone. I can also confirm that GPRS operation on a single timeslot is working, too. Good work! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jan 16 21:35:41 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Jan 2013 22:35:41 +0100 Subject: lack of progress in PCU patch merging / git (ab)use In-Reply-To: <20121124215519.GA21201@prithivi.gnumonks.org> References: <20121124215519.GA21201@prithivi.gnumonks.org> Message-ID: <20130116213541.GC8380@prithivi.gnumonks.org> Hi all, jolly has gone through the effort to rebase all his changes on top of current master. How do we proceed from here? My understanding was so far that Ivan is maintaining the PCU and repsonsible for reviewing/merging any suggested changes. The current 'jolly_merge' branch seems to work quite fine, especially now with the fixes of the last two days. I would appreciate if we could get that merged, _before_ any other changes happen in master and again cause fragmentation. Alternatively, we could of course see if Jolly should be permitted to generally push directly to master, or if all patches should be sent via 'git send-email' to this list, or if Jolly (or even I, but I know the code not well and have too many other projects) should become a co-maintainer of the project. Let's work together to find a solution for the responsibilities and workflow. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Ivan.Kluchnikov at fairwaves.ru Thu Jan 17 10:21:27 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 17 Jan 2013 13:21:27 +0300 Subject: lack of progress in PCU patch merging / git (ab)use In-Reply-To: <20130116213541.GC8380@prithivi.gnumonks.org> References: <20121124215519.GA21201@prithivi.gnumonks.org> <20130116213541.GC8380@prithivi.gnumonks.org> Message-ID: Hi, Harald! I merged jolly_merge branch to master today, sorry for so long delay. I have done some tests and I think that now we have first stable version of osmo-pcu. So at this stage I guess that Andreas or you can commit or merge bug fixes to master without any approvals, I think that bug fixes shouldn't be stored in a private branches. But all features and fundamental changes in the code should be developed in a private branches and should be discussed in the mailing list before merging to master. I plan to resume the development of osmo-pcu soon, we should implement PCCCH/PBCCH support, so I will create new branch for this feature and at this stage I suggest to merge and commit only bug fixes to master branch. 2013/1/17 Harald Welte : > Hi all, > > jolly has gone through the effort to rebase all his changes on top of > current master. How do we proceed from here? > > My understanding was so far that Ivan is maintaining the PCU and > repsonsible for reviewing/merging any suggested changes. > > The current 'jolly_merge' branch seems to work quite fine, especially > now with the fixes of the last two days. I would appreciate if we could > get that merged, _before_ any other changes happen in master and again > cause fragmentation. > > Alternatively, we could of course see if Jolly should be permitted to > generally push directly to master, or if all patches should be sent via > 'git send-email' to this list, or if Jolly (or even I, but I know the > code not well and have too many other projects) should become a > co-maintainer of the project. > > Let's work together to find a solution for the responsibilities and > workflow. Thanks! > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -- Regards, Ivan Kluchnikov. http://fairwaves.ru From laforge at gnumonks.org Thu Jan 17 14:33:50 2013 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jan 2013 15:33:50 +0100 Subject: lack of progress in PCU patch merging / git (ab)use In-Reply-To: References: <20121124215519.GA21201@prithivi.gnumonks.org> <20130116213541.GC8380@prithivi.gnumonks.org> Message-ID: <20130117143350.GN8380@prithivi.gnumonks.org> Hi Ivan, On Thu, Jan 17, 2013 at 01:21:27PM +0300, Ivan Kluchnikov wrote: > I merged jolly_merge branch to master today, sorry for so long delay. > I have done some tests and I think that now we have first stable > version of osmo-pcu. FYI: I've applied some very minor fixes (copyright statement, printing of version information) and tagged the current master as 0.1. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sat Jan 19 18:04:02 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 19 Jan 2013 19:04:02 +0100 Subject: Default build is broken since the 17th of January Message-ID: <20130119180402.GA7640@xiaoyu.lan> 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_squeeze/ From alexander.chemeris at gmail.com Sun Jan 20 18:26:13 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 20 Jan 2013 22:26:13 +0400 Subject: Default build is broken since the 17th of January In-Reply-To: <20130119180402.GA7640@xiaoyu.lan> References: <20130119180402.GA7640@xiaoyu.lan> Message-ID: Hi Holger, Is there a way to receive fails of this build job to e-mail? On Sat, Jan 19, 2013 at 10:04 PM, Holger Hans Peter Freyther wrote: > 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_squeeze/ > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Sun Jan 20 19:47:54 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 20 Jan 2013 20:47:54 +0100 Subject: Default build is broken since the 17th of January In-Reply-To: References: <20130119180402.GA7640@xiaoyu.lan> Message-ID: <20130120194754.GJ13197@prithivi.gnumonks.org> Hi Alexander, On Sun, Jan 20, 2013 at 10:26:13PM +0400, Alexander Chemeris wrote: > Is there a way to receive fails of this build job to e-mail? I'm not sure of that, but you can subscribe a RSS feed: http://jenkins.osmocom.org/jenkins/job/osmo-pcu/rssFailed -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Sun Jan 20 19:52:19 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 20 Jan 2013 23:52:19 +0400 Subject: Default build is broken since the 17th of January In-Reply-To: <20130120194754.GJ13197@prithivi.gnumonks.org> References: <20130119180402.GA7640@xiaoyu.lan> <20130120194754.GJ13197@prithivi.gnumonks.org> Message-ID: On Sun, Jan 20, 2013 at 11:47 PM, Harald Welte wrote: > Hi Alexander, > > On Sun, Jan 20, 2013 at 10:26:13PM +0400, Alexander Chemeris wrote: >> Is there a way to receive fails of this build job to e-mail? > > I'm not sure of that, but you can subscribe a RSS feed: > http://jenkins.osmocom.org/jenkins/job/osmo-pcu/rssFailed Thanks! Though I prefer e-mails for notifications, as I check RSS not very often. I know Jenkins could send e-mails - we had such a setup at my previous company. So it's a question to Holger whether we configured this or not. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hfreyther at sysmocom.de Sun Jan 20 19:55:25 2013 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Sun, 20 Jan 2013 20:55:25 +0100 Subject: Default build is broken since the 17th of January In-Reply-To: References: <20130119180402.GA7640@xiaoyu.lan> Message-ID: <20130120195525.GC21666@xiaoyu.lan> On Sun, Jan 20, 2013 at 10:26:13PM +0400, Alexander Chemeris wrote: Hi, > Is there a way to receive fails of this build job to e-mail? yes, I would need to setup a MTA on this domain. Do you want emails to this list? Another list? I am using the RSS feature of Jenkins to see the build failures. holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From alexander.chemeris at gmail.com Sun Jan 20 20:23:02 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 21 Jan 2013 00:23:02 +0400 Subject: Default build is broken since the 17th of January In-Reply-To: <20130120195525.GC21666@xiaoyu.lan> References: <20130119180402.GA7640@xiaoyu.lan> <20130120195525.GC21666@xiaoyu.lan> Message-ID: On Sun, Jan 20, 2013 at 11:55 PM, Holger Hans Peter Freyther wrote: > On Sun, Jan 20, 2013 at 10:26:13PM +0400, Alexander Chemeris wrote: >> Is there a way to receive fails of this build job to e-mail? > > yes, I would need to setup a MTA on this domain. Do you want emails to > this list? Another list? I am using the RSS feature of Jenkins to see > the build failures. A special list for this would be perfect. Smth like osmocom-pcu-build@ or osmocom-pcu-jenkins@ -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Mon Jan 21 10:04:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 11:04:22 +0100 Subject: Default build is broken since the 17th of January In-Reply-To: References: <20130119180402.GA7640@xiaoyu.lan> <20130120195525.GC21666@xiaoyu.lan> Message-ID: <20130121100422.GQ13197@prithivi.gnumonks.org> Hi Alexander, On Mon, Jan 21, 2013 at 12:23:02AM +0400, Alexander Chemeris wrote: > > yes, I would need to setup a MTA on this domain. Do you want emails to > > this list? Another list? I am using the RSS feature of Jenkins to see > > the build failures. > > A special list for this would be perfect. Smth like osmocom-pcu-build@ > or osmocom-pcu-jenkins@ I think given the low traffic on this list, it would be best to simply send the mails here. Only build failure reports should be sufficient, build success is supposedly a normal event that needs no reporting here. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Jan 21 10:22:23 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 21 Jan 2013 14:22:23 +0400 Subject: Default build is broken since the 17th of January In-Reply-To: <20130121100422.GQ13197@prithivi.gnumonks.org> References: <20130119180402.GA7640@xiaoyu.lan> <20130120195525.GC21666@xiaoyu.lan> <20130121100422.GQ13197@prithivi.gnumonks.org> Message-ID: On Mon, Jan 21, 2013 at 2:04 PM, Harald Welte wrote: > Hi Alexander, > > On Mon, Jan 21, 2013 at 12:23:02AM +0400, Alexander Chemeris wrote: >> > yes, I would need to setup a MTA on this domain. Do you want emails to >> > this list? Another list? I am using the RSS feature of Jenkins to see >> > the build failures. >> >> A special list for this would be perfect. Smth like osmocom-pcu-build@ >> or osmocom-pcu-jenkins@ > > I think given the low traffic on this list, it would be best to simply > send the mails here. Only build failure reports should be sufficient, > build success is supposedly a normal event that needs no reporting here. I'm strongly against mixing human generated traffic and computer generated traffic at the same mailing list. Given the expected low traffic and low number of users, maintaining a mailing list should not be a problem. If it's hard to host it at lists.osmocom.org, I could host it on our domain, though having it at the same domain as this mailing list looks more logical. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Mon Jan 21 10:30:24 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 11:30:24 +0100 Subject: Default build is broken since the 17th of January In-Reply-To: References: <20130119180402.GA7640@xiaoyu.lan> <20130120195525.GC21666@xiaoyu.lan> <20130121100422.GQ13197@prithivi.gnumonks.org> Message-ID: <20130121103024.GT13197@prithivi.gnumonks.org> Hi Alexander, On Mon, Jan 21, 2013 at 02:22:23PM +0400, Alexander Chemeris wrote: > On Mon, Jan 21, 2013 at 2:04 PM, Harald Welte wrote: > > > > I think given the low traffic on this list, it would be best to simply > > send the mails here. Only build failure reports should be sufficient, > > build success is supposedly a normal event that needs no reporting here. > > I'm strongly against mixing human generated traffic and computer > generated traffic at the same mailing list. While I disagree, I respect your request (and will configure my incoming mail filter to file both lists into the same folder). > Given the expected low traffic and low number of users, maintaining a > mailing list should not be a problem. If it's hard to host it at > lists.osmocom.org, I could host it on our domain, though having it at > the same domain as this mailing list looks more logical. It is not a problem to set up another list, takes about 1 minute. It just means that people will have know about two lists and subscribe to two lists. But well, as indicated, I have no strong feelings about it. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Jan 21 11:13:41 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 21 Jan 2013 15:13:41 +0400 Subject: Default build is broken since the 17th of January In-Reply-To: <20130121103024.GT13197@prithivi.gnumonks.org> References: <20130119180402.GA7640@xiaoyu.lan> <20130120195525.GC21666@xiaoyu.lan> <20130121100422.GQ13197@prithivi.gnumonks.org> <20130121103024.GT13197@prithivi.gnumonks.org> Message-ID: On Mon, Jan 21, 2013 at 2:30 PM, Harald Welte wrote: > Hi Alexander, > > On Mon, Jan 21, 2013 at 02:22:23PM +0400, Alexander Chemeris wrote: >> On Mon, Jan 21, 2013 at 2:04 PM, Harald Welte wrote: >> > >> > I think given the low traffic on this list, it would be best to simply >> > send the mails here. Only build failure reports should be sufficient, >> > build success is supposedly a normal event that needs no reporting here. >> >> I'm strongly against mixing human generated traffic and computer >> generated traffic at the same mailing list. > > While I disagree, I respect your request (and will configure my incoming > mail filter to file both lists into the same folder). Thank you, I appreciate this. >> Given the expected low traffic and low number of users, maintaining a >> mailing list should not be a problem. If it's hard to host it at >> lists.osmocom.org, I could host it on our domain, though having it at >> the same domain as this mailing list looks more logical. > > It is not a problem to set up another list, takes about 1 minute. It > just means that people will have know about two lists and subscribe to > two lists. But well, as indicated, I have no strong feelings about it. Let me elaborate a bit more - not to start an argument, just to make my point to look less selfish. :) I believe that only few active developers are interested in receiving Jenkins traffic. Other "users" or less active developers will consider this as a spam. And I don't want our list to be even nearly considered as spammed. Using two lists is an "opt in" way, which is far more friendly. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From Ivan.Kluchnikov at fairwaves.ru Mon Jan 21 11:55:30 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Mon, 21 Jan 2013 14:55:30 +0300 Subject: Default build is broken since the 17th of January In-Reply-To: <20130119180402.GA7640@xiaoyu.lan> References: <20130119180402.GA7640@xiaoyu.lan> Message-ID: Hi, Holger Yes, you are right, building without enabling sysmobts is ok. 2013/1/19 Holger Hans Peter Freyther > 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_squeeze/ > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jan 29 10:22:31 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jan 2013 11:22:31 +0100 Subject: Idea for synchonous logging/review of debug + GSMTAP Message-ID: <20130129102231.GE6676@prithivi.gnumonks.org> Hi all, one of the problems when debugging PCU issues is: How to take proper logs on-site where a problem shows up and give them back to the developer(s) for analysis. If you capture the PCU stdout or configure file-based logging, you will have a hard time corellating that with PCAP traces taken on the RLC/MAC side and/or on the Gb side. Therefore I propose a new idea here and would like to get your review: What about implementing a "GSMTAP" log target for libosmocore? This way we could encapsulate the log messages into a special GSMTAP message, which would be sent synchronously in the GSMTAP stream together with RLC/MAC messages on the lower end. The same could in fact be utilized in osmo-bts, too. This way we could capture BTS log/debug output in-order to L1 messages that we receive and transmit. What do you think about it? I would be willing to draft the GSMTAP sub-header format and write + submit the wireshark dissector, if somebody wants to write libosmocore log target. Ideally we would log _all_ messages to that target, and include the subsystem and log level in a header field, so the log verbosity could still be adjusted at the point of review, instead only at the time of logging. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Tue Jan 29 12:11:26 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 29 Jan 2013 16:11:26 +0400 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: <20130129102231.GE6676@prithivi.gnumonks.org> References: <20130129102231.GE6676@prithivi.gnumonks.org> Message-ID: Hi Harald, On Tue, Jan 29, 2013 at 2:22 PM, Harald Welte wrote: > one of the problems when debugging PCU issues is: How to take proper > logs on-site where a problem shows up and give them back to the > developer(s) for analysis. If you capture the PCU stdout or configure > file-based logging, you will have a hard time corellating that with PCAP > traces taken on the RLC/MAC side and/or on the Gb side. > > Therefore I propose a new idea here and would like to get your review: > > What about implementing a "GSMTAP" log target for libosmocore? This way > we could encapsulate the log messages into a special GSMTAP message, > which would be sent synchronously in the GSMTAP stream together with > RLC/MAC messages on the lower end. Yes, debugging PCU is PITA and we've been discussing logging improvements with Ivan for some time already. From our discussions it seems that the biggest issue is to correlate log messages with the actual user and/or session. How do you want to solve this issue with the GSMTAP? PS In general, the proposal to use GSMTAP is ... interesting. :) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Tue Jan 29 12:33:14 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jan 2013 13:33:14 +0100 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: References: <20130129102231.GE6676@prithivi.gnumonks.org> Message-ID: <20130129123314.GM6676@prithivi.gnumonks.org> Hi Alexander, On Tue, Jan 29, 2013 at 04:11:26PM +0400, Alexander Chemeris wrote: > Yes, debugging PCU is PITA and we've been discussing logging > improvements with Ivan for some time already. From our discussions it > seems that the biggest issue is to correlate log messages with the > actual user and/or session. How do you want to solve this issue with > the GSMTAP? I would treat those two independent. The case for GSMTAP is simply to have a synchronous / monotonic log (pcap in this case) that combines both actual packets on Gb and Um, as well as the human-readable log messages generated by the PCU code in between. As for the human-readable PCU log messages, I would suggest something like pre-fixing all of them with the TLLI in the beginning like [1a2b3d4e] at the start of every line. I would guess that for most of the log messages, the TLLI to which they relate should be known. The same is not the case for other identifiers like the IMSI. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Tue Jan 29 12:37:38 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 29 Jan 2013 16:37:38 +0400 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: <20130129123314.GM6676@prithivi.gnumonks.org> References: <20130129102231.GE6676@prithivi.gnumonks.org> <20130129123314.GM6676@prithivi.gnumonks.org> Message-ID: On Tue, Jan 29, 2013 at 4:33 PM, Harald Welte wrote: > Hi Alexander, > > On Tue, Jan 29, 2013 at 04:11:26PM +0400, Alexander Chemeris wrote: > >> Yes, debugging PCU is PITA and we've been discussing logging >> improvements with Ivan for some time already. From our discussions it >> seems that the biggest issue is to correlate log messages with the >> actual user and/or session. How do you want to solve this issue with >> the GSMTAP? > > I would treat those two independent. The case for GSMTAP is simply to > have a synchronous / monotonic log (pcap in this case) that combines > both actual packets on Gb and Um, as well as the human-readable log > messages generated by the PCU code in between. Just to clarify. Do you just want to transfer a normal log string as a payload in a GSMTAP message, so that it'll be shown in Wireshark "Info" column? > As for the human-readable PCU log messages, I would suggest something > like pre-fixing all of them with the TLLI in the beginning like > [1a2b3d4e] at the start of every line. I would guess that for most of > the log messages, the TLLI to which they relate should be known. The > same is not the case for other identifiers like the IMSI. I'll let Ivan comment on that. My knowledge is somewhat lacking in this area. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Tue Jan 29 13:27:54 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jan 2013 14:27:54 +0100 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: References: <20130129102231.GE6676@prithivi.gnumonks.org> <20130129123314.GM6676@prithivi.gnumonks.org> Message-ID: <20130129132754.GN6676@prithivi.gnumonks.org> On Tue, Jan 29, 2013 at 04:37:38PM +0400, Alexander Chemeris wrote: > > I would treat those two independent. The case for GSMTAP is simply to > > have a synchronous / monotonic log (pcap in this case) that combines > > both actual packets on Gb and Um, as well as the human-readable log > > messages generated by the PCU code in between. > > Just to clarify. Do you just want to transfer a normal log string as a > payload in a GSMTAP message, so that it'll be shown in Wireshark > "Info" column? yes. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Ivan.Kluchnikov at fairwaves.ru Tue Jan 29 14:19:22 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Tue, 29 Jan 2013 17:19:22 +0300 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: <20130129132754.GN6676@prithivi.gnumonks.org> References: <20130129102231.GE6676@prithivi.gnumonks.org> <20130129123314.GM6676@prithivi.gnumonks.org> <20130129132754.GN6676@prithivi.gnumonks.org> Message-ID: Hi all, Yes, I actually have many problems when debugging PCU too, so I think that using GSMTAP is good solution, because it is fast solution, and it will be really helpful. About human-readable PCU log messages, I think that using prefixes is normal, but we should use TFI+TLLI for prefix, because especially for PCU debugging it is very important to have ability to control particular TBF. 2013/1/29 Harald Welte : > On Tue, Jan 29, 2013 at 04:37:38PM +0400, Alexander Chemeris wrote: >> > I would treat those two independent. The case for GSMTAP is simply to >> > have a synchronous / monotonic log (pcap in this case) that combines >> > both actual packets on Gb and Um, as well as the human-readable log >> > messages generated by the PCU code in between. >> >> Just to clarify. Do you just want to transfer a normal log string as a >> payload in a GSMTAP message, so that it'll be shown in Wireshark >> "Info" column? > > yes. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -- Regards, Ivan Kluchnikov. http://fairwaves.ru From andreas at eversberg.eu Wed Jan 30 06:57:54 2013 From: andreas at eversberg.eu (jolly) Date: Wed, 30 Jan 2013 07:57:54 +0100 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: <20130129102231.GE6676@prithivi.gnumonks.org> References: <20130129102231.GE6676@prithivi.gnumonks.org> Message-ID: <5108C472.70402@eversberg.eu> Harald Welte wrote: > What about implementing a "GSMTAP" log target for libosmocore? This way > we could encapsulate the log messages into a special GSMTAP message, > which would be sent synchronously in the GSMTAP stream together with > RLC/MAC messages on the lower end. > it would be nice, if the "GSMTAP" target is supported by all projects that generate gsmtap, like osmocom-bb, openbsc, ... as you said, the target should have header fields for logging catergory and level, so one can filter individually. there should be also a field which flags the logging messages that are actually displayed on the screen (filtered by the application), so one does not need to select the same filter in wireshark again. i doubt that wireshark supports colors, so i suggest to prefix the logging catergory in the summary (the list of packets shown in the upper part of wireshark's window) like this: ".... [DRLCMAC] gprs_rlcmac_data.cpp:100 [] Poll timeout for DL TBF=0". From laforge at gnumonks.org Wed Jan 30 12:18:49 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jan 2013 13:18:49 +0100 Subject: Idea for synchonous logging/review of debug + GSMTAP In-Reply-To: <5108C472.70402@eversberg.eu> References: <20130129102231.GE6676@prithivi.gnumonks.org> <5108C472.70402@eversberg.eu> Message-ID: <20130130121849.GR6676@prithivi.gnumonks.org> Hi Jolly, On Wed, Jan 30, 2013 at 07:57:54AM +0100, jolly wrote: > as you said, the target should have header fields for logging catergory > and level, so one can filter individually. there should be also a field > which flags the logging messages that are actually displayed on the > screen (filtered by the application), so one does not need to select the > same filter in wireshark again. good idea. yes, there should be a 'visible' flag, indeed. > i doubt that wireshark supports colors, it supports coloring, but the normal use case is to allow the user to specify coloring rules. They are actually very useful, e.g. for automatically displaying uplink messages with a different color compared to downlink messages. If you're not familiar with that feature yet, I recommend to try it. I don't yet know if a dissector plugin could overload the colors. It might be possible. But even if it is, I think it should be a preference of the gsmtap-log dissector, as e.g. yellow on white background doens't look nearly as well as the yellow-on-black we use on the terminal/console output... > so i suggest to prefix the logging catergory in the summary (the list > of packets shown in the upper part of wireshark's window) like this: > ".... [DRLCMAC] gprs_rlcmac_data.cpp:100 [] Poll timeout for DL > TBF=0". I was actually thinking of representing the category, filename and line number as separate "fields" in wireshark. This way, you can (or can not) add them as separate columns to your list of packtes in wireshark. I've hacked up most of the required libosmocore code, although the separation of filename/line-number needs some modifications to the current logging architecture (where the string-printing is done in the core and the plugins only get the final result as opposed to the input). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)