| 00:16.11 | *** join/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 00:18.14 | seanbright | codefreeze-lap: nice work |
| 00:19.41 | codefreeze-lap | seanbright: txs! |
| 00:19.59 | seanbright | codefreeze-lap: is CEL still in the works? |
| 00:31.05 | codefreeze-lap | seanbright: Oh, most certainly yes. |
| 00:32.44 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:41.39 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584664.dsl.bell.ca) |
| 01:26.23 | *** join/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 01:41.15 | *** join/#asterisk-dev qdk (n=qdk@87.48.132.114) |
| 02:04.19 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 02:19.46 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 03:49.37 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584664.dsl.bell.ca) |
| 03:59.37 | file | runs around |
| 04:01.33 | Corydon76-dig | tickles file |
| 04:02.11 | file | did some Mantis stuff earlier, yay |
| 04:05.23 | Corydon76-dig | yay |
| 04:17.39 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 04:17.39 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 04:17.39 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 04:17.39 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 04:17.39 | *** mode/#asterisk-dev [+oo tzafrir_laptop mvanbaak] by irc.freenode.net |
| 04:18.19 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 04:18.19 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 04:23.38 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 04:26.28 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 04:29.04 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 04:29.04 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 04:29.04 | *** mode/#asterisk-dev [+oo mvanbaak tzafrir_laptop] by irc.freenode.net |
| 04:33.43 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 04:33.43 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 04:41.45 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 04:43.24 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 04:44.05 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 04:44.52 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 04:51.34 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584664.dsl.bell.ca) |
| 06:29.54 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582384.dsl.bell.ca) |
| 06:38.25 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 07:06.09 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:06.10 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:24.25 | *** join/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 08:27.56 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 08:59.25 | *** join/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 09:03.07 | *** join/#asterisk-dev cabbiepete (n=cabbiepe@83-244-133-169.cust-83.exponential-e.net) |
| 09:22.52 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:37.27 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:37.46 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:39.38 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582384.dsl.bell.ca) |
| 09:47.03 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:06.50 | *** join/#asterisk-dev Fuzix (n=fuzix@250-118.citynet.ftth.internl.net) |
| 10:26.17 | *** join/#asterisk-dev shtoom (n=shtoom@121.246.167.147) |
| 10:26.33 | shtoom | asterisk has VAD support ? |
| 10:54.50 | *** join/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 11:05.36 | *** join/#asterisk-dev ccesario (n=ccesario@189.19.9.100) |
| 11:25.50 | *** join/#asterisk-dev jeffg (i=QMeSIZih@pdpc/supporter/active/jeffg) |
| 11:27.05 | *** part/#asterisk-dev billybigpotatoes (n=billybig@92-233-110-32.cable.ubr11.nmal.blueyonder.co.uk) |
| 11:31.59 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:33.46 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:49.49 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582384.dsl.bell.ca) |
| 11:51.01 | *** join/#asterisk-dev agallo (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:22.08 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583156.dsl.bell.ca) |
| 12:32.08 | kamanashisroy | hi, when we are executing ast_bridge_call(), we are blocked, is there any way I can play with channels at this time ? I want to send text to the ipphones at that time, as the text can vary I like to execute AGI script to give people the freedom to do anything .. I tried to do things in separate thread, but it seems that agi application is not running because of some thread issue, Please give me a design of how I can implement this .. |
| 12:35.14 | *** join/#asterisk-dev dsfr (n=dsfr@pdpc/sponsor/digium/dsfr) |
| 12:35.33 | *** join/#asterisk-dev juanjoc (n=juanjoc@200.69.219.113) |
| 12:37.22 | *** part/#asterisk-dev KenLee (n=k3leland@bg-fw2out.monmouth.com) |
| 12:40.26 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 12:56.05 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 13:28.45 | kamanashisroy | I think I need a monitor after the call is bridged .. or can feature help ? |
| 13:38.48 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 13:48.41 | *** join/#asterisk-dev mbwjr12 (n=kvirc@pal-179-077.itap.purdue.edu) |
| 13:49.17 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-981cac1034c0c151) |
| 13:53.39 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:53.39 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:59.33 | mbwjr12 | any chan_mobile developers here? I'm constantly getting "sco_write()" not ready and same for sco_read(). Digging through the source hasn't offered many clues... |
| 14:02.41 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 14:02.41 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 14:08.04 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.228.111) |
| 14:13.22 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:13.22 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:20.32 | *** join/#asterisk-dev qdk (n=qdk@87.48.132.114) |
| 14:24.57 | *** join/#asterisk-dev qdk (n=qdk@87.48.132.114) |
| 14:26.18 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 14:40.33 | shido6 | does that use bluetooth? |
| 14:44.43 | putnopvut | codefreeze-lap: is M12982 something covered in your CDRFix4 merge? |
| 14:47.41 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:05.05 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:05.05 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:09.11 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 15:19.23 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:19.23 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 15:19.32 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:25.13 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 15:25.37 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 15:54.41 | kpfleming | tzafrir_laptop: ping |
| 15:54.51 | tzafrir_laptop | pong |
| 15:55.18 | kpfleming | the second hunk of your 1.4 patch for 12911 seems unnecessary, as it is already doing the same thing |
| 15:55.45 | kpfleming | tonezone_extra is already being set to the same thing that should be in DAHDI_INCLUDE |
| 15:55.53 | kpfleming | and then that is passed to AST_EXT_LIB_CHECK |
| 15:55.55 | kpfleming | is that not working? |
| 15:56.27 | kpfleming | oh wait... doh |
| 15:56.35 | kpfleming | the AST_EXT_LIB_CHECK in 1.4 doesn't work that way |
| 15:57.04 | kpfleming | ok, will fix the right way |
| 15:57.46 | tzafrir_laptop | This is needed in order for the test in the configure script itself to pass |
| 15:58.06 | kpfleming | yes, i see that now |
| 15:58.11 | kpfleming | but there is a better way to fix it |
| 15:58.24 | kpfleming | we don't want DAHDI_INCLUDE in the CPPFLAGS for the rest of the configure script |
| 15:58.28 | kpfleming | commit coming shortly |
| 15:58.28 | MuffinMan | Invalid repository given. |
| 15:59.24 | tzafrir_laptop | commit dahdi test |
| 15:59.24 | MuffinMan | Invalid repository given. |
| 16:00.32 | Qwell | file: ^^? :D |
| 16:01.46 | file | commit dahdi test |
| 16:01.47 | MuffinMan | You should specify a valid revision, you will actually get what you seek that way. |
| 16:02.02 | tzafrir_laptop | that was quick |
| 16:03.43 | Qwell | file: so, I was thinking (like 8 seconds ago).. dahdi by itself may not work |
| 16:03.56 | Qwell | well, I guess it would |
| 16:04.05 | file | it would. |
| 16:04.06 | Qwell | nevermind! |
| 16:04.18 | Qwell | for some reason, I was thinking you were specifying a branch |
| 16:06.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:06.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:10.17 | sruffell | kpfleming: regardin |
| 16:10.20 | sruffell | darn it |
| 16:10.24 | kpfleming | lol |
| 16:10.33 | sruffell | anyway...let me type up what I was going to say... |
| 16:11.49 | sruffell | I'm running into problems with the upgrade from zaptel to dahdi even removing all the current .ko files that are due to be installed. Since zaptel.ko is not in that list, all the board drivers will be installed from dahdi properly, but dahdi.ko and zaptel.ko still export the same symbols, so depmod loads zaptel.ko to resolve the referrence. |
| 16:12.32 | sruffell | So..unless we want to change all those symbols, how about this: throwing in another script into build_tools that will search for every module that has a dependency on zaptel, and remove all those, including zaptel before proceeding with the dahdi installation. |
| 16:12.32 | sruffell | ? |
| 16:13.29 | kpfleming | well, i was planning on just hardcoding a list of modules that we know we need to remove, even if we aren't installing them now |
| 16:13.37 | kpfleming | zaptel, ztdummy, ztd-eth, ztd-loc, etc. |
| 16:13.55 | kpfleming | wait.. how can dahdi and zaptel be exporting the same symbols? all the names should have been changed |
| 16:14.31 | sruffell | hmm...ok...let me look into that first....but after running dep mod, I'm getting dadhi/wctdm24xxp.ko has a dependancy on misc/zaptel.ko |
| 16:14.38 | kpfleming | wow |
| 16:14.46 | kpfleming | something is badly wrong then |
| 16:14.48 | tzafrir_laptop | any common alias? |
| 16:15.43 | sruffell | wait...might be operator error...the modules.dep keeps getting changed.... |
| 16:17.06 | kpfleming | tzafrir_laptop: your trunk patch for 12911 really shouldn't be necessary, as the same thing was already being done, and AST_EXT_LIB_CHECK would then have included the contents of DAHDI_INCLUDE into TONEZONE_INCLUDE in the makeopts file if necessary |
| 16:18.27 | kpfleming | sruffell: but even if you do figure out what is wrong there, i still think that upgrading from zaptel to dahdi should remove all zaptel modules, and downgrading to zaptel should remove all dahdi modules |
| 16:18.32 | kpfleming | just for safety's sake |
| 16:19.53 | sruffell | ok |
| 16:20.26 | kpfleming | so we'll make one more zaptel 1.4 release before dahdi is released, so that there is a version out there that knows how to properly perform the downgrade |
| 16:25.22 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:26.19 | oej | Evening |
| 16:26.30 | Qwell | oej: afternoon |
| 16:27.20 | kpfleming | Qwell: morning! |
| 16:28.08 | oej | The Asterisk project has to standardise on a time zone. Let's pick GMT-1 |
| 16:28.33 | kpfleming | GMT-24 |
| 16:28.40 | oej | That's a good one. |
| 16:28.46 | oej | Good yesterday afternoon. |
| 16:28.47 | Qwell | GMT+42 |
| 16:29.09 | oej | Asterisk - the project that always have today ahead of us! |
| 16:31.59 | outtolunc | BC+48192 (ish) |
| 16:32.54 | outtolunc | yeah, that way too silly <G> |
| 16:33.25 | oej | Ok, fixed a problem with session-timers in 1.6 |
| 16:33.39 | oej | I got a require: timer on a MESSAGE, which broke communication totally. |
| 16:46.39 | Qwell | # we use /sbin, rather than configure's $(sbindir) because we use /sbin for historical reasons. |
| 16:46.45 | Qwell | Can we change that? :) dahdi-tools |
| 17:03.08 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 17:03.08 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 17:03.21 | Qwell | pokes jtodd |
| 17:03.39 | jets | Howdy! |
| 17:03.43 | jtodd | dodges poke. |
| 17:03.46 | Qwell | You sir, are not on jabber. :) |
| 17:03.55 | mvanbaak | I am |
| 17:03.58 | jtodd | Howdy, y'all. |
| 17:04.03 | file | nods to jtodd |
| 17:04.10 | mvanbaak | heya jtodd |
| 17:05.09 | jtodd | How I long for the days when I could actually find time to do stuff in dialplan, and work on testing. Now, I am merely an email drone. |
| 17:07.30 | mvanbaak | [macro-doemail] |
| 17:07.39 | mvanbaak | exten => _X.,1,Hangup() |
| 17:07.42 | mvanbaak | there you go |
| 17:08.33 | jtodd | I find /dev/null to be a much more willing recipient of email than my inbox. |
| 17:09.20 | tzafrir_laptop | kpfleming, sorry, will try to test that later, need to go now |
| 17:11.24 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 17:11.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:17.59 | *** join/#asterisk-dev ctaloi (n=ctaloi@nat-66-218-1-176.usadatanet.com) |
| 17:34.03 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 17:34.16 | putnopvut | app_voicemail makes me cringe sometimes. |
| 17:35.21 | seanbright | rewrite |
| 17:35.23 | seanbright | ;) |
| 17:35.28 | putnopvut | srsly |
| 17:35.54 | putnopvut | I just looooove finding logic that accomplishes nothing. |
| 17:36.40 | seanbright | you just summed up my life |
| 17:36.42 | seanbright | heh |
| 17:36.43 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 17:37.55 | putnopvut | gyros, on the other hand, make me happy. |
| 17:40.10 | mcargile | putnopvut: now I have to drive 5 miles to the gyros shop to get lunch or I will not be satisfied. I hope your happy. |
| 17:40.43 | putnopvut | :) |
| 17:59.01 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 17:59.48 | bbryant | has anyone used gdb breakpoints with asterisk before? |
| 18:00.27 | putnopvut | bbryant: I have, and jpeeler has. |
| 18:00.54 | kpfleming | me too... but it's tough to use, since asterisk is threaded so heavily |
| 18:01.26 | bbryant | putnopvut: well, i'm trying to set a breakpoint in chan_sip and i can't seem to get it to stop... i'm assuming because that's because a thread is handling the cli stuff |
| 18:01.49 | kpfleming | no, any breakpoint you set should trigger |
| 18:01.50 | putnopvut | I don't understand the explanation... |
| 18:02.04 | bbryant | that's what i though |
| 18:02.33 | jpeeler | yeah i've had that problem before too |
| 18:03.01 | jpeeler | certainly related to the threading |
| 18:03.07 | putnopvut | I have not. I find it curious that you have. |
| 18:04.11 | jpeeler | you could do something like setting the breakpoint in the calling function and see if it gets caught there |
| 18:04.43 | putnopvut | bbryant: perhaps the line where you're setting the breakpoint has been optimized out by the compiler? Maybe turn optimizations off? |
| 18:05.08 | bbryant | i'm setting it on a function |
| 18:05.18 | kpfleming | yeah... optimizations will play havoc with breakpoints and gdb |
| 18:05.26 | bbryant | with dont optimize set |
| 18:05.31 | kpfleming | what function? |
| 18:05.34 | bbryant | sip_hangup |
| 18:05.51 | kpfleming | hmm |
| 18:05.58 | kpfleming | don't see any reason why a breakpoint there should fail |
| 18:06.34 | Qwell | kpfleming: when you get a second, could you take a look at my comment above about /sbin/? |
| 18:07.01 | kpfleming | dont see it |
| 18:07.01 | Qwell | that's from dahdi-tools/Makefile |
| 18:07.08 | Qwell | # we use /sbin, rather than configure's $(sbindir) because we use /sbin |
| 18:07.08 | Qwell | # for historical reasons. |
| 18:07.14 | Qwell | Can we change that? |
| 18:07.16 | *** join/#asterisk-dev pputman- (n=centrex@c-68-62-214-146.hsd1.al.comcast.net) |
| 18:07.26 | kpfleming | yes |
| 18:07.28 | kpfleming | go ahead |
| 18:07.40 | Qwell | excellent |
| 18:08.54 | kpfleming | dahdi-tools still needs a lot of work to get ready for release... feel free to fix up anything you want |
| 18:09.08 | kpfleming | 'make config' needs to exist there, and install the sample configs and init script, like it did in zaptel |
| 18:20.58 | davevg-btwtech | non-dev related load testing question (probably a dumb question), using a slightly modified uac_pcap scenerio to establish a baseline for a customer, when we hit 5k active channels i get not RTP ports remaining, does it use 2 ports per channel? |
| 18:21.11 | Qwell | yep |
| 18:21.15 | davevg-btwtech | thanks |
| 18:21.23 | Qwell | (sort of) |
| 18:21.33 | Qwell | ((but for your purposes, yes)) |
| 18:22.04 | davevg-btwtech | thanks, this server isn't really flinching with that load with playback(), figured it was using 2 ports, just verifying |
| 18:22.28 | Qwell | one port is for rtcp. it's consecutive |
| 18:38.52 | oej | qwell: It's not any more, consecutive I mean... Not always because of NATs |
| 18:45.49 | *** join/#asterisk-dev anthm (n=anthm@mbc0736d0.tmodns.net) |
| 19:12.22 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 19:20.28 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 19:22.17 | *** part/#asterisk-dev shtoom (n=shtoom@121.246.167.147) |
| 19:28.05 | *** join/#asterisk-dev wedhorn (n=nwedhorn@123-243-209-34.static.tpgi.com.au) |
| 19:35.04 | *** join/#asterisk-dev docelmo (n=brian@206.248.239.194) |
| 19:35.25 | docelmo | Is there anyway from a CDR module to access channel variables? |
| 19:35.41 | kpfleming | no, we have custom CDR variables for that purpose |
| 19:36.17 | docelmo | How would I go about getting the dialstatus variable from the channel in a cdr module? |
| 19:36.18 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.228.111) |
| 19:36.57 | docelmo | I was doing a Set(CDR(dialstatus)=${DIALSTATUS}) but its not functioning now for some reason. I havent changed the core code of asterisk |
| 19:37.01 | docelmo | not sure why its not working now |
| 19:37.14 | kpfleming | what version of asterisk? |
| 19:37.47 | docelmo | 1.4 |
| 19:37.57 | docelmo | 16.2 |
| 19:40.45 | seanbright | i hope we never get to 16.2 |
| 19:44.12 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 19:47.57 | kpfleming | docelmo: the cdr_custom module has an example of how to get the data from the custom cdr variables |
| 19:49.03 | Corydon76-dig | or cdr_adaptive_odbc |
| 19:49.14 | kpfleming | not in 1.4 |
| 19:49.21 | Corydon76-dig | backport on svncommunity |
| 19:49.35 | kpfleming | yeah.. well seeing the relevant bit of code in there would be a bit harder :-) |
| 19:50.51 | Corydon76-dig | thought I'd mention it... it might already do what he wants without changing any CDR code |
| 19:51.12 | kpfleming | yep |
| 19:55.48 | anonymouz666 | would be strace a good tool to understand why an asterisk process consumes about 9%/12% of CPU in a totally fresh install (and no users or activity)? |
| 19:56.30 | kpfleming | only if it is making lots of system calls |
| 19:56.30 | Corydon76-dig | Not really, no |
| 19:56.51 | Corydon76-dig | Use a profiler to determine where it's spending its time |
| 20:29.44 | docelmo | Thanks kevin! |
| 20:30.54 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.151.76.105) |
| 20:32.31 | jpeeler | if core show locks shows some garbage, that definitely means memory corruption right? |
| 20:33.57 | putnopvut | jpeeler: yep. |
| 20:34.09 | putnopvut | Where's that happening? |
| 20:35.17 | jpeeler | during a session of ~60 calls over E1 spans |
| 20:35.42 | putnopvut | ew... |
| 20:35.52 | putnopvut | The problem is that it could be happening in several places. |
| 20:36.00 | putnopvut | I say, "valgrind to the rescue!!" |
| 20:36.03 | jpeeler | perhaps not even related to the bug |
| 20:36.13 | jpeeler | yeah i'm about to head that route now |
| 20:39.18 | jpeeler | would it be considered a bug to be experiencing lock contention simply from a lot of ast_log output? |
| 20:39.39 | jpeeler | though i don't think that is the real problem |
| 20:41.49 | putnopvut | jpeeler: what branch are you testing? |
| 20:41.59 | jpeeler | putnopvut: 1.4 |
| 20:42.22 | putnopvut | It does seem weird to see lock contention from ast_log output. |
| 20:42.35 | putnopvut | Especially since I think there's only one lock obtained in an ast_log call. |
| 20:42.46 | jpeeler | i'm not sure about that actually, locking a list may work differently than i thought |
| 20:43.54 | putnopvut | The list locking macro just calls ast_mutex_lock on the list's lock. |
| 21:21.31 | sruffell | Qwell: are you working on the config scripts for dahdi-tools? |
| 21:21.58 | Qwell | sruffell: nope |
| 21:22.11 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 21:22.12 | sruffell | ok...just wanted to make sure I wasn't going to step on anything you might already be doing....thx |
| 21:42.09 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 21:49.31 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 21:55.13 | snuff-home | kpfleming: any stuff you would like me to test in relation to alignment / unions etc.. let me know i'll be happy to compile on the sparc i have availible to me |
| 21:55.23 | kpfleming | great |
| 21:55.54 | kpfleming | right now the only work has been done on the transcoder modules, but if you can confirm that they still compile cleanly and that you can transcode between ulaw and GSM (for example), then i'll be happy that the code works |
| 21:57.38 | snuff-home | fair enough.. i know the union stuff i initially did worked.. but couldn't do the test on an actual sparc (transcode) because i dont have physical access and behind fw.. |
| 21:57.49 | snuff-home | but i have another machine at work which should work just fine |
| 21:58.10 | kpfleming | ok, cool |
| 21:58.17 | kpfleming | wait... we have one here |
| 21:58.19 | kpfleming | Qwell: ping |
| 21:58.21 | Qwell | pong |
| 21:58.29 | kpfleming | do you have linux on the T2000? |
| 21:58.36 | Qwell | umm |
| 21:58.48 | Qwell | I want to say yes |
| 21:58.52 | snuff-home | heh |
| 21:58.59 | Qwell | I think I installed Debian a while back |
| 21:59.06 | kpfleming | snuff-home: shouldn't matter linux or solaris, right? the alignment issues are the same |
| 21:59.34 | snuff-home | uhm.. solaris seems more picky.. and i dont have a linux sparc to test |
| 21:59.39 | kpfleming | ok |
| 22:00.09 | kpfleming | we may need to reinstall solaris on the box then |
| 22:00.11 | snuff-home | can we also approve some sort of change from #11885 |
| 22:00.18 | Qwell | kpfleming: there's also that ss20 |
| 22:00.23 | Qwell | slow as dirt, but it's running solaris |
| 22:00.32 | kpfleming | right... it will finish compiling in 2009 |
| 22:00.38 | snuff-home | aka make a decision on the uint32_t vs u_int32_t |
| 22:00.42 | Qwell | somewhere around there |
| 22:00.47 | mvanbaak | wont be as bad as the hppa box I had for a week |
| 22:01.28 | mvanbaak | box had a whopping 25 bogomips |
| 22:02.09 | kpfleming | uint32_t is the standards-compliant (sort of) way to do it |
| 22:02.11 | Qwell | let me go see what that t2000 is running, and get the ip |
| 22:02.29 | kpfleming | so whatever headers are needed in editline to use that, we should fix it |
| 22:03.51 | mvanbaak | asking a friend who works at sun if he can borrow me a box |
| 22:04.13 | mvanbaak | if so, you have root access :) |
| 22:04.23 | Qwell | and I suddenly remembered why I never use that box |
| 22:04.26 | kpfleming | snuff-home: db1-ast has tons of u_int32_t as well... how are those compiling? |
| 22:04.33 | Qwell | the awesome lack of a video card |
| 22:04.42 | snuff-home | yep... qwell.. |
| 22:04.47 | mvanbaak | Qwell: duh, use a serial console |
| 22:04.47 | kpfleming | we need to just buy one |
| 22:04.48 | snuff-home | its called a 'console' |
| 22:04.55 | snuff-home | then u ssh to it |
| 22:05.00 | snuff-home | after setup :) |
| 22:05.16 | kpfleming | we don't like serial consoles |
| 22:05.20 | kpfleming | we are new-school |
| 22:05.42 | kpfleming | we have a fancy KVM and rack-mounted LCD, but the T2000 doesn't get to use it |
| 22:05.45 | Qwell | kpfleming: you'd have to look at it to determine what kind of card it needs |
| 22:05.50 | snuff-home | hehe.. |
| 22:06.02 | kpfleming | it will have to be a sun-branded card or it won't work with the BIOS or solaris anyway |
| 22:06.09 | Qwell | ahh, right |
| 22:07.24 | kpfleming | we are lucky it doesn't require the old proprietary sun 20 pin video connection :-) |
| 22:07.31 | Qwell | sbus |
| 22:07.32 | Qwell | I have one |
| 22:07.38 | Qwell | we'd be lucky if it did |
| 22:07.48 | Qwell | (not really - it's *SLOW*) |
| 22:07.53 | kpfleming | no, i mean the external connector |
| 22:08.03 | Qwell | oh, of course |
| 22:08.05 | kpfleming | with big fat pins for RGB and other stufff |
| 22:08.14 | Qwell | the ss20 has one of those |
| 22:09.17 | mvanbaak | a T1000 starts at 2800 dollar |
| 22:09.18 | mvanbaak | not bad |
| 22:09.30 | Qwell | mvanbaak: nope, it's decent |
| 22:09.35 | Qwell | that's like 4 core though |
| 22:09.53 | snuff-home | good enough for base testing.. :) |
| 22:11.01 | Qwell | mvanbaak: check out the t5140 |
| 22:11.18 | Qwell | (and 5240) |
| 22:11.43 | snuff-home | we are getting a x4500 in our office in a few weeks.. mm storage |
| 22:11.49 | Qwell | thumper? |
| 22:11.52 | snuff-home | yep |
| 22:11.55 | Qwell | nice |
| 22:12.31 | snuff-home | shame its lower end of the spec only 12tb one |
| 22:12.39 | Qwell | only |
| 22:13.05 | snuff-home | least as time goes on we can just put in 1tb drives :P |
| 22:13.15 | snuff-home | instead of the failed 250's |
| 22:21.07 | snuff-home | ok.. iso std had u_int32_t and then changed their minds to uint32_t and the typedef for that on linux is in stdint.h |
| 22:21.20 | kpfleming | something like that, yeah |
| 22:21.55 | mvanbaak | # Supports up to 16x 2.0 TB UltraSCSI drives |
| 22:22.00 | mvanbaak | # Includes 36 PCI slots |
| 22:22.04 | mvanbaak | holy shit |
| 22:22.13 | *** join/#asterisk-dev jeffg (i=MFxZREmd@pdpc/supporter/active/jeffg) |
| 22:22.18 | Qwell | 36? that can't be right |
| 22:22.30 | snuff-home | what is that.. e25k ? |
| 22:22.34 | mvanbaak | Primepower 900 |
| 22:22.52 | mvanbaak | snuff-home: "Contact Sun for prices" |
| 22:23.05 | bkruse | mvanbaak: ! |
| 22:23.07 | snuff-home | mm.. well they are about 2mill a pop |
| 22:23.12 | mvanbaak | bkruse: ! |
| 22:23.17 | mvanbaak | yeah, I should be in bed |
| 22:23.18 | mvanbaak | I know |
| 22:23.22 | mvanbaak | ;) |
| 22:23.23 | Qwell | that thing is like 16U |
| 22:23.26 | bkruse | mvanbaak: How was the brothers visit? |
| 22:23.32 | mvanbaak | it was great |
| 22:23.38 | snuff-home | working on a e2900 with a 6tb array atm.. that costs 400k au |
| 22:23.39 | mvanbaak | damn she's pregnant |
| 22:23.41 | kpfleming | mvanbaak: don't worry about it, tomorrow is a holiday :-) |
| 22:23.44 | snuff-home | gotta go to work |
| 22:23.47 | snuff-home | :) |
| 22:23.48 | bkruse | heh |
| 22:23.52 | mvanbaak | it's not a footbal, it's a skippyball |
| 22:24.10 | bkruse | I am about to commit a small change in appdocsxml (todo list, script to pull out xml) |
| 22:24.12 | Qwell | 752mm... 1U is...1.5"? |
| 22:24.28 | mvanbaak | the scans really say one kid, but if it was me to guess I would say at least 2 |
| 22:25.00 | mvanbaak | Qwell: I used to have a small netra server |
| 22:25.08 | mvanbaak | one they sold for 999 euro |
| 22:25.18 | mvanbaak | but cant find it in their product list anymore |
| 22:25.23 | Qwell | Max. PCI Slots: 320 |
| 22:25.32 | Qwell | Primepower 2500 |
| 22:26.29 | mvanbaak | Qwell: yeah, that one is insane |
| 22:26.38 | mvanbaak | btw, mine was a netra 100 |
| 22:26.54 | kpfleming | 1U == 1.75" |
| 22:27.01 | mvanbaak | I loved it |
| 22:27.24 | Qwell | 30" / 1.75" = ~17U |
| 22:27.33 | mvanbaak | but the psu died, and replacing that was more expensive then buying a X2200 M2 |
| 22:29.04 | mvanbaak | now we run Debian linux with xen on them |
| 22:30.21 | mvanbaak | bkruse: nice |
| 22:32.48 | mvanbaak | any of you run ubuntu 8.05 ? |
| 22:35.20 | bkruse | does on his lappy |
| 22:35.27 | mvanbaak | ok |
| 22:35.38 | mvanbaak | you have repotools installed on it as well ? |
| 22:36.05 | kpfleming | 8.05? what is that? |
| 22:36.24 | mvanbaak | or 8.04 |
| 22:36.28 | mvanbaak | hardy heron |
| 22:36.44 | kpfleming | yes |
| 22:36.50 | mvanbaak | I think the repotools svnmerge has a problem |
| 22:36.51 | kpfleming | i have three boxes with kubuntu 8.04 on them |
| 22:36.56 | kpfleming | i do all my work on them |
| 22:37.05 | mvanbaak | for example |
| 22:37.45 | mvanbaak | if I do a clean checkout of https://origsvn.digium.com/svn/asterisk/team/group/appdocsxml |
| 22:38.01 | mvanbaak | run the repotools 'svnmerge merge' on it |
| 22:38.19 | mvanbaak | it only merges apps/Makefile and Makefile |
| 22:38.26 | mvanbaak | and then exits cleanly |
| 22:38.44 | putnopvut | mvanbaak: did you svnmerge init? |
| 22:38.46 | mvanbaak | but it does not merge main/editline/np/vis.c nor update props |
| 22:39.09 | mvanbaak | if I run '/usr/bin/svnmerge.real merge' it works fine |
| 22:39.15 | mvanbaak | take around 2 minutes here |
| 22:39.31 | kpfleming | that might be the expect script timing out |
| 22:39.33 | kpfleming | i've seen that happen |
| 22:39.38 | mvanbaak | yeah |
| 22:39.51 | kpfleming | you can change the timeout in the svnmerge wrapper to some big number |
| 22:39.51 | mvanbaak | but looking at the expect man page I see no timeout stuff |
| 22:40.00 | kpfleming | it's there |
| 22:43.38 | mvanbaak | hhmm |
| 22:43.54 | mvanbaak | <PROTECTED> |
| 22:44.06 | kpfleming | yes, the default timeout is 30 seconds |
| 22:44.34 | putnopvut | mvanbaak: the timeout is at the top of the mergetool expect script. |
| 22:45.04 | mvanbaak | yup |
| 22:45.06 | mvanbaak | noticed that |
| 22:45.20 | mvanbaak | can I set it to 60 ? |
| 22:45.31 | mvanbaak | it never ever runs in 30 seconds here |
| 22:45.36 | Qwell | or 900 |
| 22:45.52 | mvanbaak | I bet it is fast in your internal network |
| 22:45.54 | mvanbaak | but |
| 22:46.05 | mvanbaak | I always used the svnmerge.real version |
| 22:46.53 | mvanbaak | I would say, raise it |
| 22:47.45 | mvanbaak | I have an 8mbit dsl line |
| 22:47.57 | mvanbaak | fast enough if you ask me ;) |
| 22:48.02 | Qwell | mvanbaak: it's not so much the speed, but the latency |
| 22:48.48 | mvanbaak | you guys block icmp |
| 22:48.57 | mvanbaak | 11. orc2.apid.com 0.0% 14 132.4 133.1 132.4 134.1 0.5 |
| 22:49.04 | mvanbaak | last hop before origsvn |
| 22:49.48 | mvanbaak | 133ms avg, and it stays that way |
| 22:50.03 | mvanbaak | you ok if I raise it to 60 ? |
| 22:51.11 | mvanbaak | (the timeout) |
| 22:53.08 | mvanbaak | fixes it on all stuff I tried now |
| 22:53.58 | kpfleming | you can just raise it locally |
| 22:54.08 | kpfleming | and yes... on our network, it's rarely a problem :-) |
| 22:54.16 | *** join/#asterisk-dev qdk (n=qdk@87.48.132.114) |
| 22:54.29 | mvanbaak | moves to huntsville |
| 22:54.30 | kpfleming | or you can modify the script to read it from a config file in /etc or ~ if you want to get fancy |
| 22:55.34 | bkruse | yay! |
| 22:55.50 | bkruse | Digium LAN = awesome, unless those PQ guys are clogging up the pipes |
| 22:55.52 | bkruse | ducks |
| 22:56.01 | kpfleming | s/pipes/tubes/ |
| 22:59.14 | file | puts bkruse on a separate VLAN that goes nowhere |
| 23:00.27 | bkruse | cannot ping google.com |
| 23:01.46 | bkruse | Actually, that will happen soon, at least, our own network :/ |
| 23:04.33 | bkruse | mvanbaak: Do you have time to talk? |
| 23:07.26 | mvanbaak | 5 minutes |
| 23:07.30 | mvanbaak | then I'll go to bed |
| 23:07.40 | mvanbaak | past 1 AM here |
| 23:07.59 | mvanbaak | and first business meeting tomorrow is at 8 AM |
| 23:08.06 | mvanbaak | have to leave home at 7 AM |
| 23:23.54 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 23:24.17 | mvanbaak | bkruse: sorry, I'm really going to bed now |
| 23:25.01 | mvanbaak | latero all |
| 23:26.15 | bkruse | mvanbaak: hah, see ya tomorrow |
| 23:56.24 | bkruse | does asterisk have a MAX_FILE_SIZE type definition equivalent ? |
| 23:56.47 | *** join/#asterisk-dev jeffspeff (n=jeff@c-98-240-112-228.hsd1.ky.comcast.net) |