| 00:32.49 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 00:44.09 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 01:10.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 01:15.20 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:15.20 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 01:26.26 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:26.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:57.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 02:36.26 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 02:39.05 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 03:02.31 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:02.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:26.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 03:31.14 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 04:09.54 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:16.01 | *** join/#asterisk-dev irroot (~gregory@41.51.171.129) |
| 04:18.00 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 04:44.01 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 04:44.38 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 06:15.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 07:24.39 | *** join/#asterisk-dev micols (~ident@rlogin.dk) |
| 07:25.49 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 07:25.50 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 07:31.20 | *** join/#asterisk-dev irroot (~gregory@196-215-57-105.dynamic.isadsl.co.za) |
| 07:38.12 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 07:51.43 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 08:17.54 | *** join/#asterisk-dev micols (~ident@rlogin.dk) |
| 08:20.46 | *** join/#asterisk-dev micols (~ident@rlogin.dk) |
| 08:39.24 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:40.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:40.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:52.37 | *** join/#asterisk-dev micols (~ident@rlogin.dk) |
| 08:53.46 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6110:ec21:d6ac:2537) |
| 09:01.52 | *** join/#asterisk-dev happylife (~happylife@212.92.145.7) |
| 09:48.17 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 09:48.19 | schmidts | good morning |
| 10:40.17 | *** join/#asterisk-dev fazool (~ada_has@203.130.22.202) |
| 10:40.26 | fazool | hello |
| 10:40.31 | fazool | any one there |
| 10:40.58 | fazool | i am working on call center application |
| 10:41.09 | fazool | using Asterisk.net library |
| 10:41.35 | fazool | i want to know calltransfer event |
| 10:41.39 | fazool | in library |
| 10:42.21 | fazool | can any one help |
| 10:50.16 | fazool | qasim bhaiiiiiiiiiiiiiiiiiiiiii |
| 10:50.23 | fazool | koi help nai kar raha yahan |
| 10:51.45 | schmidts | fazool hello |
| 10:52.27 | schmidts | i dont know anything about the asterisk.net library and for me this doesnt sound like a typical asterisk project, do you have access to the source code of it or not? |
| 10:59.37 | schmidts | would a module reload res_rtp_asterisk.so kill rtp streams? i have taken a look in the rtp_reload function and i dont see that any rtp threads would be killed but i am not sure, and i dont want to try this on a production server ;) |
| 11:10.53 | *** join/#asterisk-dev black187 (~black187@93-103-22-42.static.t-2.net) |
| 11:14.44 | *** join/#asterisk-dev befazool (~ada_has@203.130.22.202) |
| 11:15.37 | befazool | can anyone tell me transferEvent handler in asterisk.net 104 |
| 11:15.44 | befazool | *1.4 |
| 11:20.31 | schmidts | befazool you are asking the wrong questions ;) |
| 11:21.22 | schmidts | befazool http://www.voip-info.org/wiki/view/Asterisk+manager+Example:+Transfer |
| 11:43.18 | befazool | no i am asking |
| 11:44.11 | befazool | which event will teell me in my application that i have a call that is transfered from someone to me |
| 11:44.21 | befazool | using asterisk.net lib |
| 11:45.03 | schmidts | befazool i have understand your question, but the answer you can found in the asterisk.lib source code and if this source isnt available for you cause its not open source maybe, then you have to ask the developer of asterisk.net |
| 11:45.25 | schmidts | i can tell you the exactly part of the asterisk source code where this event will come from, but i guess this doesnt help you |
| 11:45.47 | befazool | i am developer actually |
| 11:45.58 | befazool | <PROTECTED> |
| 11:46.34 | befazool | <PROTECTED> |
| 11:47.53 | befazool | actully i want to show a pop up masg on agent screen when agent rungs |
| 11:48.46 | befazool | so in normal call its easily caught by using AgentCalled event |
| 11:48.56 | befazool | and i show information |
| 11:49.00 | befazool | in popup |
| 11:49.29 | befazool | but whent transfer call comes i dunt know how to handle it |
| 11:49.52 | befazool | me i want call information |
| 11:51.03 | befazool | <schmidts> can u tell me exact part of source code |
| 11:51.04 | befazool | ?? |
| 11:59.44 | irroot | so when do our friends across the pond murder turkeys ?? tommorow or today ? |
| 12:01.13 | schmidts | befazool http://www.asterisk.org/doxygen/asterisk1.4/manager_8c-source.html#l01721 |
| 12:02.01 | schmidts | irroot i dont know :D |
| 12:21.42 | pabelanger | irroot: thursday I think for the US. |
| 12:21.56 | pabelanger | Canada was a 6 weeks ago |
| 12:22.09 | irroot | cool yeah remember seen that |
| 12:22.43 | irroot | thx pabelanger |
| 12:22.58 | pabelanger | befazool: like schmidts, you're in the wrong channel. We know nothing about the asterisk.net lib; different project |
| 12:25.59 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 12:35.46 | *** join/#asterisk-dev eliel_ (~quassel@200.32.121.66) |
| 12:37.06 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 12:37.06 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:27.03 | irroot | quite impresed with the HP print package for ubuntu using HP-6500 all in one with a linksys 2102 |
| 13:28.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mjfrogphhsepnbwj) |
| 13:28.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:03.56 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 14:08.54 | *** join/#asterisk-dev VPeralta (~VPeralta@99-157-188-60.lightspeed.miamfl.sbcglobal.net) |
| 14:29.38 | Kobaz | okay |
| 14:29.47 | Kobaz | i figured out the deadlock |
| 14:30.25 | Kobaz | ast_restart_monitor is doing a masquerade, and autoservice is processing a masquerade for the same channel at the same time |
| 14:31.40 | Kobaz | ast_do_masq should check to see if it's already running |
| 14:31.42 | Kobaz | somehow |
| 14:31.43 | *** join/#asterisk-dev VPeralta (~VPeralta@199.27.100.5) |
| 14:31.57 | jsmith | Kobaz: Glad to hear you were able to track it down |
| 14:32.14 | Kobaz | http://pastebin.com/jHpame2R |
| 14:32.22 | Kobaz | Thread ID: 0xb5effb70 (do_monitor started at [25386] chan_sip.c restart_monitor()) |
| 14:32.25 | Kobaz | === ---> Lock #0 (chan_sip.c): MUTEX 24901 handle_request_do &netlock 0xb6b26700 (1) |
| 14:32.30 | Kobaz | and then in that same thread |
| 14:32.35 | Kobaz | === ---> Waiting for Lock #1 (channel.c): MUTEX 6785 ast_do_masquerade channels 0x84d2728 (1) |
| 14:32.43 | Kobaz | and then |
| 14:32.46 | Kobaz | === Thread ID: 0xb5086b70 (autoservice_run started at [ 218] autoservice.c ast_autoservice_start()) |
| 14:32.49 | Kobaz | === ---> Lock #0 (channel.c): MUTEX 6785 ast_do_masquerade channels 0x84d2728 (1) |
| 14:32.52 | Kobaz | that's the problem |
| 14:33.47 | Kobaz | ast_do_masquerade running twice for the same channel |
| 14:34.54 | Kobaz | well the problem is the other lock, lock #1 |
| 14:34.57 | Kobaz | but it's the double masq |
| 14:35.01 | irroot | Kobaz ast_do_masquerade can run for the same channel and it should be safe |
| 14:35.11 | Kobaz | well it's not safe in this case |
| 14:35.21 | irroot | kobaz only one will succeed |
| 14:35.40 | Kobaz | because ast restart monitor locked something |
| 14:35.51 | Kobaz | er, restart_monitor |
| 14:36.28 | Kobaz | damn, i should have attached and dumped core |
| 14:37.24 | irroot | core dump will help show locks shows a block not a deadlock |
| 14:37.33 | irroot | follow for a minute please |
| 14:37.55 | irroot | 1st thread is locking netlock |
| 14:38.07 | irroot | and waiting for channels container |
| 14:38.28 | irroot | 2nd is holding channels and 2 channel locks and not waiting on any lock |
| 14:38.59 | jsmith | (Maybe in Asterisk 20 we'll completely get rid of masquerades) |
| 14:39.05 | irroot | all other threads are waiting for locks without holding any |
| 14:39.21 | irroot | kobaz you agree ?? |
| 14:39.26 | Kobaz | yeah |
| 14:39.30 | Kobaz | all the others are just waiting |
| 14:40.19 | irroot | yes so there is no deadlock where one is waiting for another while holding one the other is looking for |
| 14:40.41 | irroot | so in the masq thread there is something blocking with locks held |
| 14:40.57 | irroot | a BT of this will show the problem |
| 14:43.10 | schmidts | irroot + kobaz i am not sure if masquerade is the real problem |
| 14:43.39 | Kobaz | it may not be |
| 14:43.49 | irroot | i suspect the loop in autoservice |
| 14:43.54 | Kobaz | but that's what it's running, it just struck me ofdd that it's running twice |
| 14:44.08 | acidfoo | Hi folks, what could cause `ast_module_info` to be NULL (not initialized) ? Because when I try to do ast_rtp_glue_register(...) it invoke ast_module_info->self... but since ast_module_info is NULL... well it doesn't work :) |
| 14:44.14 | irroot | autoservice_stop |
| 14:44.34 | file | it is NULL if you are not doing that from within a module |
| 14:44.35 | schmidts | it looks like a lock on the dialog container |
| 14:44.41 | file | acidfoo, ^^^ |
| 14:44.41 | Kobaz | there was another deadlock i fixed before |
| 14:44.52 | acidfoo | erm |
| 14:44.59 | acidfoo | I do |
| 14:45.03 | Kobaz | ast_bridge was running, doing a masq, and autoservice was also doing a masq |
| 14:45.13 | Kobaz | so i put in an autoservice_stop at the top of ast_bridge |
| 14:45.33 | Kobaz | dont know if that fixed anything |
| 14:45.52 | Kobaz | rephrased to "another deadlock i tried to fix before" |
| 14:45.57 | schmidts | ;) |
| 14:46.31 | schmidts | why should autoservice do a masq? isnt it the other way that masq will stop autoservice after the masq? |
| 14:46.49 | Kobaz | no idea |
| 14:46.59 | Kobaz | don't know much about the masq stuff |
| 14:47.15 | Kobaz | seems to be that more than one masq shouldn't run at a time, it should say, fail, already running |
| 14:47.29 | irroot | schmidts want to see the backtrace there is a while() {sleep 1000;} in autoservice_stop that has got me before |
| 14:47.47 | schmidts | cool, looks like high performance stuff :D |
| 14:48.06 | Kobaz | yeah |
| 14:48.43 | schmidts | kobaz irroot just brought in a patch some weeks ago to make sure a masq really only could be active once on a channel but there is a point until one channel could be locked, when both are waiting to start the masq |
| 14:48.45 | irroot | kobaz with the locking in the masq only one will succeed once the masq is done and locks released the 2nd masq will return |
| 14:48.51 | schmidts | if one channel get the lock, the other one will fail |
| 14:49.22 | Kobaz | it should trylock |
| 14:49.28 | Kobaz | and then if it fails you cant masq |
| 14:50.07 | irroot | the masq has to finish before it can return it changes sets ->masq to NULL using trylock will not have any effect |
| 14:50.23 | irroot | kobaz if you can get a BT of this id like to see it |
| 14:50.38 | Kobaz | yeah, if it happens again i will |
| 14:51.06 | Kobaz | but in the masq can't you lock a new lock, like channel->masqlock |
| 14:51.21 | Kobaz | and then at the top of masq, trylock it, if it doesnt lock you bail |
| 14:52.19 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 14:52.33 | irroot | Kobaz yes you could but would have the same net effect and add to the locking complexity |
| 14:52.40 | Kobaz | [2011-11-23 09:22:18] -- <SIP/602-000010cf> -- autoservice starting 1 |
| 14:52.48 | Kobaz | [2011-11-23 09:22:18] -- <SIP/602-000010cf> SIP attended transfer attempt: SIP/602-000010bc transferring its peer SIP/pbx-sip-t1-kwi-gw1-000010ba, (SIP/pbx-sip-t1-kwi-gw1-0000\ |
| 14:52.53 | Kobaz | 10ba will replace SIP/602-000010cf) |
| 14:53.13 | Kobaz | should transfers stop autoservice? |
| 14:54.11 | acidfoo | file, ah, what happen is that I have two .c files, and I call ast_rtp_glue_register() from the second one... ;/ |
| 14:54.37 | irroot | Kobaz likely they about to be bridged and should be running autoservice while not bridged so should stop it when about to bridge id say but that is guess |
| 14:54.42 | acidfoo | file, it seems that ast_module_info is not null from only the files that hold the load_module stuff |
| 14:54.52 | Kobaz | on the surface level that seems to be the problem |
| 14:55.03 | Kobaz | processing a transfer while autoservice is running |
| 14:55.26 | Kobaz | could it hurt? |
| 14:55.32 | Kobaz | stop autoservice on transfer processing? |
| 14:55.43 | Kobaz | i need to try something... |
| 14:56.07 | schmidts | Kobaz thats just the normal way if you have a 4 channel masquerade, at least one of them is normally on hold -> autoservice is running |
| 14:56.22 | Kobaz | ah okay |
| 14:56.49 | schmidts | and as far as i remember after the masq was successfull, or even just before the autoservice will be stopped |
| 14:57.39 | Kobaz | well i have debugs in stop and start |
| 14:58.13 | Kobaz | so it started on SIP/602-000010cf |
| 14:58.15 | Kobaz | and then xfer |
| 14:58.51 | Kobaz | and then autoservice is started on SIP/pbx-sip-t1-kwi-gw1-000010ba<MASQ> |
| 14:59.12 | Kobaz | and then stopped right away |
| 15:01.01 | Kobaz | fuck another one |
| 15:01.33 | schmidts | get the backtrace ;) |
| 15:01.57 | Kobaz | i think i did |
| 15:06.21 | Kobaz | http://pastebin.com/5RzjjJVh |
| 15:07.15 | Kobaz | i didn't get core show locks from that one though |
| 15:08.06 | Kobaz | #1 0xb75933e6 in nanosleep () at ../sysdeps/unix/syscall-template.S:82 |
| 15:08.06 | Kobaz | #2 0xb75c25ec in usleep (useconds=1000) at ../sysdeps/unix/sysv/linux/usleep.c:33 |
| 15:08.09 | Kobaz | #3 0x0808bc5f in ast_autoservice_stop (chan=0x86d7010) at autoservice.c:281 |
| 15:09.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 15:14.24 | Kobaz | woah |
| 15:14.32 | Kobaz | every time you trylock it starts and stops autoservice? |
| 15:15.00 | Kobaz | i took out one of my trylocks that I don't need |
| 15:15.42 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:16.43 | schmidts | ouch |
| 15:17.09 | Kobaz | what's it need that for? |
| 15:17.39 | Kobaz | i'm gonna try and take out the other trylock i use |
| 15:19.07 | Kobaz | anything good in the backtrace? |
| 15:19.48 | Kobaz | i think this may be a problem |
| 15:19.55 | Kobaz | #21 0x0808b47a in autoservice_run (ign=0x0) at autoservice.c:127 so autoservice starts |
| 15:20.07 | Kobaz | runs an agi command |
| 15:20.10 | Kobaz | #9 0xb6df9b58 in agi_handle_command (chan=0x86d7010, agi=0xaf3d8480, buf=0xaf3d7ba4 "GET", dead=1) at res_agi.c:3445 |
| 15:20.23 | Kobaz | which is a trylock |
| 15:20.24 | Kobaz | #4 0xb645f28a in trylock_read (chan=0x86d7010, cmd=0xaf3d7760 "TRYLOCK", |
| 15:20.38 | Kobaz | which then tries to stop autoservice |
| 15:21.12 | Kobaz | and probably blocks forever in there, since it's currently *inside* the autoservice |
| 15:23.16 | Kobaz | <PROTECTED> |
| 15:23.16 | Kobaz | <PROTECTED> |
| 15:23.19 | Kobaz | and here we wait |
| 15:23.56 | Kobaz | i took out the trylock, turns out i don't need it, lemme try and reproduce this |
| 15:31.59 | Kobaz | so maybe it's a problem with do_masq being called from autoservice, which then hops into dialplan causing autoservice to stop |
| 15:32.19 | irroot | Kobaz this is what i suspected |
| 15:33.14 | irroot | it needs autoservice_run to complete a loop this is where the key to solving this lies i believe |
| 15:39.14 | Kobaz | i hope i fixed it |
| 15:39.26 | Kobaz | i'm running core show locks every few minutes, i'm hoping for the best |
| 15:39.32 | Kobaz | well "fixed it" by not using trylock |
| 15:41.53 | irroot | on way home have another massive storm coming through ill look at it when i get there cheers folks |
| 15:42.34 | jsmith | irroot: Be safe! |
| 15:44.01 | irroot | will do these storms are awesome highway closed in one spot for flooding tree blown down arround the corner ... yesterdays storm shifted the concrete slab |
| 15:44.03 | irroot | over storm water drain |
| 15:45.06 | jsmith | Wow... |
| 15:48.54 | Qwell | wdoekes2: ping |
| 15:49.46 | Qwell | wdoekes2: as it turns out, there is a lot of stuff that uses the LOG_* stuff. As I recall, the reason we changed them, was libc-client. |
| 15:50.20 | Qwell | your change is fine of course - just a short history lesson |
| 16:23.01 | wdoekes2 | http://lists.digium.com/pipermail/asterisk-commits/2008-April/022016.html <-- which turned out to be the syslog definitions (googled it just now) |
| 16:23.28 | Qwell | ahh, the imap stuff uses syslog. That makes sense then. |
| 16:23.46 | Qwell | I stand corrected then. |
| 16:24.20 | wdoekes2 | in any case.. I was looking at the comments and thought "nah.. this was probably in the past" and I removed all AST_*.. but first up the cdr_syslog broke |
| 16:24.58 | Qwell | yeah, it's messy |
| 16:25.12 | wdoekes2 | I tried to work around it, but it became worse.. so I figured I'd just update the comments |
| 16:25.35 | wdoekes2 | and perhaps replace all LOG_* with AST_LOG_* in one giant patch instead |
| 16:28.04 | *** join/#asterisk-dev irroot (~gregory@41.49.35.38) |
| 16:37.59 | leifmadsen | I need to get better at LDAP stuff |
| 16:39.51 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:39.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:41.09 | anonymouz666 | leifmadsen: chapter 18 ;) |
| 16:42.28 | *** join/#asterisk-dev vpopov (~happylife@46.251.83.126) |
| 17:08.48 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 17:08.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:09.56 | irroot | leifmadsen LDAP is your friend ..... |
| 17:12.06 | *** join/#asterisk-dev hardwire (~spencersr@cl-36.anc-01.us.sixxs.net) |
| 17:13.47 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 17:15.59 | leifmadsen | irroot: which is why I need to get better with it ;) |
| 17:16.11 | leifmadsen | anonymouz666: ya :) just in general though so I can do more systems integrations with it |
| 17:16.54 | irroot | leifmadsen the job we doing for walter sisulu university they want as much done in ldap as possible |
| 17:17.07 | leifmadsen | irroot: yep |
| 17:17.17 | leifmadsen | I want to integration with egroupware |
| 17:17.24 | leifmadsen | s/integration/integrate/ |
| 17:17.25 | irroot | use it to do all user auth RADIUS/Mail/SAMBA |
| 17:17.43 | irroot | leifmadsen also look at www.sogo.nu as groupware |
| 17:17.50 | leifmadsen | ya, my problem is I'm not good with managing ldap, especially from the console. Documentation for openldap is... less than ideal |
| 17:17.57 | irroot | the next gen will be native exchange |
| 17:18.15 | leifmadsen | irroot: yes I looked and it contains significantly less functionality than egw |
| 17:18.39 | irroot | yes openldap not so clear |
| 17:18.49 | leifmadsen | which is pretty much almost all of what I integrate with |
| 17:19.11 | leifmadsen | I haven't even found a good, "getting started with openldap" website to just get connected/authenticated after install |
| 17:19.14 | irroot | once you have your schemas and config you on your way |
| 17:19.24 | leifmadsen | that is like step 7 |
| 17:19.52 | irroot | happy to help ... you using source or package ?? |
| 17:19.58 | leifmadsen | package |
| 17:20.34 | irroot | so steps 1-3 done no need to config make install |
| 17:21.40 | irroot | you going to use SSL ? |
| 17:21.59 | irroot | SSL/TLS |
| 17:23.07 | leifmadsen | possiblyu |
| 17:23.12 | leifmadsen | I just want to get connected and start managing first |
| 17:30.06 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 17:30.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:50.39 | irroot | kobaz ping |
| 17:51.47 | irroot | there should never be a path where autoservice_stop is called from autoservice_run thread |
| 18:09.58 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 18:10.02 | tzafrir | sruffell, here? |
| 18:10.17 | sruffell | Hello |
| 18:11.13 | tzafrir | What are the plans for 2.5? Is there a minor release expected before 2.6.0? After? |
| 18:12.09 | sruffell | could be anytime. There is only one more commit sitting on the branch that isn't on the last release. |
| 18:12.42 | tzafrir | we have one or two things here pendingg testing |
| 18:13.11 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 18:13.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:13.48 | sruffell | ok…no problem. I have one troubling report with 2.6.0-rc1 that I'm chasing down on that front as well. |
| 18:13.57 | sruffell | but our board specific it sounds like. |
| 18:15.39 | oron_laptop | sruffell: that problem has anything to do with panic during driver unloading, by any chance? |
| 18:15.50 | sruffell | hmm..no…it was noise on a PRI line. |
| 18:16.09 | sruffell | I haven't see any panics (but then I haven't been stressing any of the new interfaces) |
| 18:21.26 | oron_laptop | sruffell: the panic is a bit hard to reproduce, but easy to understand (methink), |
| 18:22.26 | oron_laptop | sruffell: spans are unassigned just a bit before process_masterspan(), than a dahdi_receive() call from the... |
| 18:22.55 | oron_laptop | sruffell: low-level driver catches process_masterspan() midway and boom. |
| 18:23.39 | sruffell | hmm….I'll have to look..I though the chan_lock protects from that? |
| 18:25.00 | oron_laptop | sruffell: The chan_lock protects against assign/unassign during process_masterspan(), the problem is |
| 18:25.43 | oron_laptop | sruffell: that dahdi_receive() is called from low-level driver that may not know yet that this span is illegal. |
| 18:26.19 | oron_laptop | sruffell: I haven't dived into it too much, since I'm looking for a good way to reproduce this. |
| 18:27.30 | sruffell | dahdi_recieve is legal to be called regardless of whether a span is registered I believe….do you have a backtrace from the panic? |
| 18:28.14 | oron_laptop | sruffell: Yes, I'll try to send it with some explanations of the scenario, but I hope I'll be able to reproduce this more (un)reliably |
| 18:28.22 | sruffell | ok |
| 18:30.37 | oron_laptop | sruffell: On another topic. What about channel sysfs representation. I'd like to proceed with this. How would you like to do this? |
| 18:32.51 | sruffell | oron_laptop: any problems getting the user space scripts sorted out in 2.7 first? |
| 18:33.34 | sruffell | not to say that the channel representation can't be in 2.7 as well…but I think revamping dahdi_genconf and updating the /etc/dahdi/system.conf will have some requirements for the channels fall out. |
| 18:34.50 | oron_laptop | sruffell: 1. No ref-counting of channels. 2. Having structured metada in sysfs would simplify user-space (especially dahdi_genconf) |
| 18:35.31 | sruffell | no ref-counting of channels…don't we eventually want to move the channel allocation into the core of dahdi and out of the board drivers? |
| 18:36.05 | sruffell | (which will mean adding a private pointer back into the channels..but…meh) |
| 18:36.09 | oron_laptop | sruffell: In any case you'd need to create objects to represent them. |
| 18:37.16 | sruffell | true…but at least when they are in the core…we don't have to make the board drivers stick around to free them when the refcount drops to zero….and dahdi should be loaded when any of the structures are visible in sysfs. |
| 18:37.56 | *** join/#asterisk-dev otherwiseguy_ (~otherwise@69.76.221.79) |
| 18:40.06 | oron_laptop | sruffell: Hmmm... I think board drivers would need to stay around anyway to process other dahdi callbacks. |
| 18:40.50 | oron_laptop | sruffell: (not that I object in any way to move channel allocation to core) |
| 18:43.00 | oron_laptop | sruffell: What's not clear to me, is how to move on both fronts (tools for current trunk, sysfs-chan for next) |
| 18:43.26 | oron_laptop | sruffell: (because the format we worked on pinned-spans, looked very good to me) |
| 18:44.38 | sruffell | I just need time to look at it…and I haven't been focusing on that too much until after 2.6.0 is out. |
| 18:46.49 | oron_laptop | sruffell: OK, so RSN (after 2.6.0) can we try and push these goals? |
| 18:47.19 | sruffell | yes….definitely |
| 18:47.30 | sruffell | I currently am not aware of anything that would prevent that. |
| 18:47.56 | oron_laptop | sruffell: OK, I'll keep my patches synced to trunk meanwhile... |
| 18:49.00 | sruffell | speaking of that..one other thing that might be worth is talking about switching to git for DAHDI…and figuring out where all the firmware is going to reside and how to build the "complete" package that has all the firmware so nothing else needs to be fetched from servers during a build from a "complete" tarball. |
| 18:49.21 | sruffell | just FYI…nothing to discuss currently. tzafrir was going to put on his Debian maintainers hat when we started looking at that again. |
| 18:51.30 | oron_laptop | sruffell: Yes, I know, thanks. |
| 18:51.55 | tzafrir | switching to git is orthogonal to the placement of the firmwares, right? |
| 18:52.07 | sruffell | yes…a little bit of free association there... |
| 19:04.44 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 19:04.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:14.48 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 19:14.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:16.25 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 19:16.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:21.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 19:21.37 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 19:22.44 | *** join/#asterisk-dev otherwiseguy_ (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 19:24.29 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:01.46 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 20:01.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:04.45 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mjfrogphhsepnbwj) |
| 20:41.33 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 20:41.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:45.33 | *** join/#asterisk-dev oej (~oej@190.194.1.87) |
| 20:45.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:05.38 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 22:05.55 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 22:51.04 | *** join/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 23:11.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 23:11.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:22.49 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 23:59.26 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 23:59.26 | *** mode/#asterisk-dev [+o file] by ChanServ |