| 00:04.51 | snuff-work | mmm life on sparc.. troublesome for poor * :( |
| 00:05.25 | snuff-work | easiest way to make happy is void * :P |
| 00:10.47 | codefreeze | Trying to keep the clock accurate in a vmware virtual machine is useless. |
| 00:19.41 | blitzrage | totally |
| 00:24.23 | Corydon76-lap | codefreeze: did you install the vmware tools? |
| 00:24.32 | Corydon76-lap | Because the tools keep the clock accurate |
| 00:33.16 | codefreeze | Corydon76-dig: yeah, went to thier website and played with settings. Went from running like 1 hour late per hour to like 1 hour ahead per hour. |
| 00:39.34 | *** join/#asterisk-dev RoyK (n=roy@91.149.31.174) |
| 00:43.19 | *** part/#asterisk-dev RoyK (n=roy@91.149.31.174) |
| 00:53.46 | snuff-work | mm.. time to try a different method to fix these sparc issues.. pragma ... |
| 01:13.02 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:26.44 | *** join/#asterisk-dev bkruse_home (n=kruz@76.73.154.120) |
| 01:26.44 | *** mode/#asterisk-dev [+o bkruse_home] by ChanServ |
| 02:02.41 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 02:27.51 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 02:27.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 02:32.04 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 03:41.13 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 04:12.03 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 04:12.03 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:33.46 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 05:13.52 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 05:13.52 | *** join/#asterisk-dev steliosk (n=Stelios@ipa226.211.tellas.gr) |
| 05:13.53 | *** join/#asterisk-dev brookshire (i=mbrooks@hijacked.us) |
| 06:02.40 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:02.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:07.39 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:18.07 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 07:15.47 | *** join/#asterisk-dev bkw_ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 08:10.41 | *** join/#asterisk-dev fadey (n=fadey@239.Red-80-36-91.staticIP.rima-tde.net) |
| 08:12.16 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:12.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:58.21 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:58.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:05.50 | tzafrir | oej, I wonder what could be the effect of 'echo [ >>/etc/asterisk/users.conf' to whoever uses the asterisk-gui |
| 09:06.09 | tzafrir | Should probably make the GUI immediately inaccessible.... |
| 09:08.46 | oej | The users.conf stuff is totally bad... |
| 09:09.05 | tzafrir | oej, oh well, make that manager.conf . Still applies |
| 10:23.25 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 10:23.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:25.18 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:55.15 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 11:13.40 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 11:26.03 | *** join/#asterisk-dev snuff-work (n=bradl@197.36.168.202.static.comindico.com.au) |
| 11:26.03 | *** join/#asterisk-dev snuff-away (n=nffot@220-253-12-190.VIC.netspace.net.au) |
| 11:26.03 | *** join/#asterisk-dev wedhorn (n=nnnwedho@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 11:32.00 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:59.37 | *** join/#asterisk-dev dklima (n=daniel@200.195.161.164) |
| 12:23.07 | *** join/#asterisk-dev shazaum (n=shazaum@200.175.61.250.static.gvt.net.br) |
| 12:55.40 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:06.27 | tzanger | morning |
| 13:06.49 | tzanger | guess what I learned last night |
| 13:08.25 | snuff-away | nothing? |
| 13:08.37 | tzanger | no, I learned something obvious |
| 13:09.07 | snuff-away | mm i only learnt pain last 2 days.. damn sparc :) |
| 13:09.24 | tzanger | if you don't schedule a workqueue into a thread, it wont' run. :-) |
| 13:09.55 | tzanger | I so completely tore apart my driver that I cut out the schedule_work() line |
| 13:10.11 | tzanger | and spent all day looking at my GPIO trying to figure out why it coudln't see hookstate changes anymore |
| 13:10.14 | snuff-away | mm sounds good... |
| 13:10.25 | tzanger | only to discover that it wasn't seeing them because it wasn't actually querying the hardware |
| 13:10.43 | tzanger | of course, I'm figuring this out on the other side of the world (Israel) |
| 13:11.05 | snuff-away | fair enough ;) |
| 13:11.08 | tzanger | it worked fine locally because I don't have hardware with hookstates so I was just verifying that the TDM side worked |
| 13:17.51 | *** join/#asterisk-dev eliel (n=eliel@200.59.172.38) |
| 13:29.51 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:02.03 | *** join/#asterisk-dev fadey (n=fadey@239.Red-80-36-91.staticIP.rima-tde.net) |
| 14:17.37 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:17.37 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 14:19.47 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-22e2b49f5f69c3b7) |
| 14:19.47 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:31.54 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.125.196) |
| 14:44.51 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:44.51 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:47.55 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 14:50.36 | *** join/#asterisk-dev festr_ (n=festr@ns.regnet.cz) |
| 14:51.11 | festr_ | hi. i'm debugging deadlocks (the latest 1.4 svn). core show locks show me this: |
| 14:51.14 | festr_ | === ---> Tried and failed to get Lock #0 (channel.c): MUTEX 5045 ast_channel_trylock &chan->lock 0x83846b8 (0) |
| 14:51.17 | festr_ | is it wrong? |
| 14:51.25 | festr_ | anyone have some time to discuss this? |
| 14:51.50 | blitzrage | morning all |
| 14:51.53 | festr_ | the line before this: |
| 14:51.53 | festr_ | === Thread ID: 3083357104 (do_devstate_changes started at [ 378] devicestate.c ast_device_state_engine_init()) |
| 14:52.07 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 14:52.21 | blitzrage | festr_: it's not quite 9am in HSV, so you might be better off posting a bug and waiting an hour? |
| 14:52.52 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 14:52.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:53.03 | festr_ | here is 15:50 :) i'll post it to wxisting bug on muntis |
| 14:53.09 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 15:04.12 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-864e584ba312d501) |
| 15:04.12 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 15:18.48 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 15:24.38 | *** part/#asterisk-dev bkw_ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 15:27.18 | *** join/#asterisk-dev bkw__ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 15:30.53 | eliel | festr_: do you have a core show locks? |
| 15:31.39 | *** part/#asterisk-dev bkw__ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 15:37.21 | festr_ | eliel: when this deadlock occurs, all CLI is locked |
| 15:37.44 | festr_ | eliel: http://bugs.digium.com/view.php?id=11080#bugnotes |
| 15:42.38 | eliel | festr_: ok, mmm, I think we have two deadlocks reported on the same issue... |
| 15:44.21 | eliel | or, I am going crazy... |
| 15:45.25 | blitzrage | eliel: I'm going to go with... crazy |
| 16:00.34 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-242.sw.biz.rr.com) |
| 16:05.06 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 16:06.31 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-7b6aa62d3e88f8a9) |
| 16:06.31 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:09.03 | *** join/#asterisk-dev russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:09.03 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:14.04 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-52f7cce372307ef9) |
| 16:14.04 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:28.19 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:35.20 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:52.21 | dklima | eliel, blitzrage, I'm going to crazy too... |
| 16:53.32 | dklima | that deadlock or deadlocks are so frustrading |
| 17:02.59 | tzafrir | M10329 |
| 17:03.00 | MuffinMan | [new] [Zaptel] NewFeature 0010329: [patch] show zaptel sync master reported by tzafrir http://bugs.digium.com/view.php?id=10329 |
| 17:03.07 | tzafrir | Any reason for not commiting it? |
| 17:04.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 17:24.05 | tzanger | if I have the equivalent to a FXS port pick up |
| 17:24.05 | Corydon76-vcch | tzafrir: nope |
| 17:24.18 | tzanger | asterisk should allocate a new channel in AST_STATE_OFFHOOK, right? |
| 17:24.25 | tzanger | s/asterisk/my channel driver/ |
| 17:24.36 | tzanger | cute, jbot |
| 17:24.38 | tzafrir | Corydon76-dig, you were answering me? |
| 17:24.45 | Corydon76-vcch | Yes |
| 17:25.54 | putnopvut | tzanger: that sounds intuitive. |
| 17:25.59 | *** join/#asterisk-dev ta^3 (n=tacvbo@1005hostc7.starwoodbroadband.com) |
| 17:26.48 | tzanger | yes it does, doesn't mean it's right though :-) |
| 17:28.19 | tzanger | hmm I thought the pbx thread played dialtone and waited for digits |
| 17:28.25 | tzanger | it looks like the channel driver's responsible for that |
| 17:28.45 | tzanger | AST_STATE_RESERVED, tone_play_tone(), createa switch thread |
| 17:31.16 | tzanger | wow the softswitch thread is HUGE |
| 17:33.50 | *** join/#asterisk-dev callguy (n=callguy@pool-71-162-97-18.bstnma.east.verizon.net) |
| 17:35.20 | tzanger | that can't be right |
| 17:35.33 | tzanger | asterisk must be able to play a dialtone and wait for digits on other channeltypes |
| 17:35.36 | tzanger | zaptel does it by hand |
| 17:35.48 | tzanger | what about MGCP or OSS? |
| 17:38.22 | tzanger | yup they alls eem to have their own softswitches |
| 17:38.24 | tzanger | damn |
| 17:39.17 | Corydon76-vcch | tzanger: In trunk, I have altered WaitExten to be able to generate dialtone |
| 17:39.38 | tzanger | hmm |
| 17:39.48 | tzanger | I guess I coudl run it like a batphne |
| 17:39.50 | tzanger | that'd work |
| 17:40.13 | eliel | Is there any possibility of deadlock on local_queue_frame() [chan_local.c] when locking 'us' channel and then p->lock? if the first trylock(other) fails? |
| 17:40.18 | Corydon76-vcch | Basically, immediate=yes, and at s extension, put WaitExten(,d) |
| 17:40.24 | tzanger | yeah |
| 17:41.44 | festr_ | i've catched deadlock (1.4 svn). i've core show locks and gd snapshot all threads. i'm not sure, where to paste these informations on mantis. i'm monitoring some bugs with sip deadlocks. anyone could help? |
| 17:42.21 | festr_ | core show locks shows Lok #0,1,2 in thread do_devstate_changes |
| 17:42.36 | festr_ | Waiting for Lock #3 (chan_sip.c): MUTEX 7226 transmit_state_notify |
| 17:43.01 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 17:43.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:43.10 | Corydon76-vcch | You need to upload the entire output AS A FILE to the relevant bug |
| 17:43.21 | festr_ | i'm routing calls through queue to several phones with ringall strategy |
| 17:44.15 | festr_ | Corydon76-vcch: i could search on mantis, if there is some bug releated to this. but if i dont, i could create one. but i'm risking to be panished because of duplicate bug :) thats why i'm asking.. |
| 17:45.02 | Corydon76-vcch | festr_: try in 11080 |
| 17:45.04 | eliel | Everyone is reporting deadlock related to sip in 11080 |
| 17:45.17 | festr_ | thank you |
| 17:45.17 | eliel | But I think we have more than one true deadlock there... |
| 17:46.08 | festr_ | i've seen today two strange deadlocks. one dedalock does not allow me to do anything on CLI. another deadlocks have the same symptoms, chan_sip is not doing anything |
| 17:46.40 | festr_ | i will report it on 11080 |
| 17:46.46 | dklima | good luck |
| 17:47.10 | dklima | any help, any info is welcome |
| 17:48.03 | dklima | a lot of deadlock are popping around world |
| 17:48.04 | caio1982 | those tons of deadlocks just recently reported could be related to some infrastructure change commited without much review or simply due high traffic and heavy testing by users? |
| 17:48.04 | dklima | everywhere |
| 17:48.04 | Corydon76-vcch | caio1982: if we knew what the problem was, we would have fixed it already |
| 17:48.17 | Corydon76-vcch | caio1982: we do not know the cause |
| 17:48.33 | caio1982 | i didnt mean that, I was just wondering about... |
| 17:49.10 | *** join/#asterisk-dev Victor_Yure (n=aaa@postfix.tradein.com.br) |
| 17:49.36 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 17:51.08 | *** join/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 17:54.58 | festr_ | caio1982: i'm sure, that this deadlocks are releated to some infrastructure chnges. this deadlocks never occurs on my asterisk in the office and the traffic and configuration is the same over 1/2 year. i can also reproduce it randomly very often. |
| 17:55.49 | dklima | festr_, which version? |
| 17:55.54 | dklima | festr_, did you remember ? |
| 17:56.06 | festr_ | dklima: which version was stable? |
| 17:56.22 | dklima | dklima, yes |
| 17:56.30 | *** join/#asterisk-dev markwii (n=marcos@postfix.tradein.com.br) |
| 17:57.10 | festr_ | i've tryied to downgrade from 1.4.15 to 1.4.14 without success. |
| 17:57.19 | festr_ | i'm sure that some of 1.4.13 was not doing this |
| 17:57.30 | dklima | festr_, I'm sure it is |
| 17:58.15 | festr_ | but i could be wrong |
| 17:58.15 | dklima | festr_, I'm having that kind of deadlock since 1.4.11... |
| 17:58.28 | callguy | dklima: we saw a relative decrease in stability after 1.4.9, however, several other deadlocks we were hitting more frequently were resolved after 1.4.12 |
| 17:58.35 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 17:59.33 | festr_ | i'm using revision SVN-branch-1.4-r87262M on primary SIP server with parallel ~ 30 calls and deadlock never occurs |
| 17:59.47 | festr_ | i'm not sure what version is this revision |
| 17:59.53 | callguy | dklima: i suspect whatever it is we're hitting (our traces look similar as do festr's) was probably there all along, but only made apparent after some other fixes/changes went in |
| 18:00.17 | dklima | callguy, I have a custommer with more than 500 calls per min, its running 1.4.2, asterisk is up for 5 months... |
| 18:00.57 | festr_ | dklima: 1.4.13 this version is stable for me, i've checked it now on several servers where there are no locks |
| 18:01.57 | dklima | but downgrading to that version, more problems that was resolved in early version will appear |
| 18:02.11 | dklima | thats the question... |
| 18:02.49 | *** join/#asterisk-dev myiagy (n=Jose@200.215.59.133) |
| 18:03.47 | callguy | dklima: it definitely has to do with use case. we have certain boxes running 150+ concurrent calls all day, we never encounter this issue. it appears to be related to hints/buddy watch |
| 18:04.01 | callguy | though obviously the source is pretty elusive |
| 18:04.43 | callguy | the two things we have done is attempt to stay away from chan_local and distribute hints across servers, which has reduced the freqeuency of the deadlocks by several orders of magnitude |
| 18:04.49 | eliel | maybe related to transfers? |
| 18:05.03 | dklima | I got some <ZOMBIE> in transfer.... |
| 18:05.34 | eliel | because transfers create a local channel (attended transfer) |
| 18:08.27 | dklima | that's the scenario: all features like transfer to queues, queues, queues penalties, transfer to extension, extension to queue, dynamic queue member, voicemails, music on hold... all features are used... it will be a little difficult do isolate what is causing what... |
| 18:09.31 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 18:10.02 | eliel | I discard queues |
| 18:10.09 | eliel | also music on hold |
| 18:10.19 | dklima | we have a heavy use of queues |
| 18:10.26 | eliel | but not transfers |
| 18:10.34 | dklima | and transfer from extensions to queues |
| 18:10.43 | dklima | *transfers |
| 18:10.57 | eliel | I have seen some core show locks hunging in local_queue_frame |
| 18:11.05 | eliel | also in devicestate |
| 18:11.13 | _ys | murf here? |
| 18:11.19 | eliel | but never something regarding to queues, at least in 11080 |
| 18:11.38 | dklima | right... I'm just saying my scenario... |
| 18:13.41 | *** join/#asterisk-dev alepaes_ (n=alepaes@200-170-190-097.xf-static.ctbcnetsuper.com.br) |
| 18:16.00 | callguy | eliel: if you look at both 11080 and 11165 they are pretty much the same thing - and i believe that dklima and festr are hitting the same thing as us (deadlock in devicestate) |
| 18:16.07 | Qwell | M11538 |
| 18:16.08 | MuffinMan | [assigned] [Asterisk-GUI] Ztscan/Digital Cards 0011538: PCI Frontend not enabled in Xen DomU images reported by riddles http://bugs.digium.com/view.php?id=11538 |
| 18:16.09 | callguy | on our side we don't make particularly heavy use of queues at all |
| 18:16.16 | Qwell | Does Xen even support PCI-passthrough? |
| 18:17.01 | dklima | Qwell, yes, it support |
| 18:17.24 | Qwell | funky |
| 18:18.02 | Qwell | I wish vmware could |
| 18:19.10 | callguy | eliel: but it seems like there is memory corruption happening sometime before that - so it's tough to say what's cause and effect, there is some stuff going on in the code that's pretty confusing |
| 18:20.18 | eliel | Yes it could be a memory corruption because of the MUTEX id being locked... |
| 18:21.32 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-4379297447b6cc81) |
| 18:21.32 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 18:35.24 | oej | Evening folks |
| 18:36.07 | *** join/#asterisk-dev fadey (n=fadey@84.76.46.249) |
| 18:39.29 | dklima | night |
| 18:42.13 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 18:42.40 | *** join/#asterisk-dev MikeJ (n=MikeJ@d149-67-220-106.try.wideopenwest.com) |
| 18:46.38 | dklima | M11080 |
| 18:46.40 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0011080: SIP channel stops processing calls, but no apparent deadlock reported by callguy http://bugs.digium.com/view.php?id=11080 |
| 18:48.34 | *** join/#asterisk-dev fadey (n=fadey@84.76.46.249) |
| 18:55.44 | *** part/#asterisk-dev jmls (n=jmls@62.49.235.130) |
| 19:16.18 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:16.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:22.03 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 19:26.41 | *** part/#asterisk-dev myiagy (n=Jose@200.215.59.133) |
| 19:28.01 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 19:33.03 | *** part/#asterisk-dev markwii (n=marcos@postfix.tradein.com.br) |
| 19:40.25 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 19:51.49 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 20:12.11 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 20:14.05 | Damin | Ho hum.. |
| 20:16.08 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 20:18.40 | *** join/#asterisk-dev mog (i=mog@nat/digium/x-5b2078bbbb11d46c) |
| 20:18.40 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 20:21.15 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 20:29.27 | russellb | festr_: thanks for posting that debug info to 11080 |
| 20:29.30 | russellb | i think i can fix that deadlock. |
| 20:31.20 | putnopvut | w00t |
| 20:31.51 | russellb | actually ... festr_ what version are you using? |
| 20:33.56 | russellb | === ---> Waiting for Lock #3 (chan_sip.c): MUTEX 7226 transmit_state_notify &iflock 0xb66c3080 (1) |
| 20:34.08 | russellb | i don't see where that function locks iflock ... |
| 20:34.31 | MikeJ | russellb: try looking in his code :D |
| 20:36.13 | oej | try locking in his code... |
| 20:36.16 | oej | Sorry ;-) |
| 20:39.21 | russellb | hardy har har |
| 20:44.46 | Qwell | oej: You didn't reply to my email on -dev. Thoughts? |
| 20:45.05 | oej | Have been out all day. A reply to my flame mail? |
| 20:45.13 | Qwell | oej: yes :) |
| 20:46.22 | oej | Yes, it's wrong in TRUNK and 1.4 - the move of the code. |
| 20:46.41 | Qwell | well, I didn't move the code in trunk, only 1.4 - I just copied what was there in trunk |
| 20:46.52 | oej | I agree with you that the config bug is a huge problem, so add it to the CHANGES etc files so it's very clear |
| 20:47.16 | oej | I haven't got time to revert that in trunk and 1.4 - can you please do that? |
| 20:47.24 | oej | Gotta enter a phone conference soon |
| 20:50.13 | Qwell | oej: the stuff in trunk was part of a much larger commit, for the config loading stuff |
| 20:51.25 | oej | Ok, will have to look at that, missed that change. Who did that? |
| 20:51.41 | Qwell | if it's the change I'm thinking it is, Tilghman did, about 2 months ago |
| 20:51.58 | oej | Ah, that figures. I was off line then... |
| 20:52.15 | oej | But please change 1.4 back and I'll try to fix trunk later. It's trunk after all. |
| 20:52.43 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-242.sw.biz.rr.com) |
| 20:54.24 | Qwell | I'm not sure I understand why it's bad. That code was already being done on reload, we're just using it on initial load too now. |
| 20:58.46 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 20:59.25 | Qwell | surely there won't be any active registrations on load, before the config is parsed |
| 21:10.03 | Corydon76-vcch | Shouldn't be... and don't call me Shirley |
| 21:10.46 | Corydon76-vcch | wakka wakka |
| 21:13.10 | jsmith | Corydon76-vcch: Rodger, Rodger! |
| 21:13.34 | Corydon76-vcch | What's our vector, Victor? |
| 21:14.18 | jsmith | Ah, it's been too long since I saw that movie |
| 21:31.51 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 21:51.32 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-c15e8520a33b536d) |
| 21:51.32 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 21:58.43 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 22:01.12 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:01.12 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:24.25 | mvanbaak | any of you going to FOSDEM ? |
| 22:25.54 | file | negative |
| 22:26.17 | putnopvut | I'm going nowhere. |
| 22:26.28 | russellb | mvanbaak: get them to invite me to speak :-p |
| 22:26.34 | mvanbaak | wim@openbsd.org just offered me a place to sleep so I'm there for sure |
| 22:26.37 | Qwell | *cough*us*cough* |
| 22:26.48 | russellb | oh, right, um, all of us to speak :-p |
| 22:27.05 | mvanbaak | guess I'll have to sleep in a pile of openbsd t-shirts or something, but that's fine ;) |
| 22:27.11 | russellb | heh |
| 22:27.14 | Qwell | mvanbaak: they're probably used... |
| 22:27.21 | file | Brussels eh? |
| 22:27.23 | Qwell | and I wouldn't want to be anywhere NEAR a used openbsd shirt |
| 22:27.28 | mvanbaak | brussels yup |
| 22:28.11 | putnopvut | Mmmm. graufres... |
| 22:28.21 | putnopvut | s/graufres/gaufres |
| 22:29.18 | mvanbaak | most importantly, I'll also be at friday's beerparty |
| 22:29.22 | mvanbaak | \o/ |
| 22:29.38 | russellb | now i really want to go :( |
| 22:29.45 | file | russellb: :( |
| 22:37.35 | *** join/#asterisk-dev ctooley_ (n=ctooley@rrcs-71-42-115-242.sw.biz.rr.com) |
| 22:49.04 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:49.04 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:15.43 | Corydon76-vcch | Qwell: you rock |
| 23:16.27 | Corydon76-vcch | M11543 |
| 23:16.27 | MuffinMan | [new] [Asterisk] PBX/pbx_config 0011543: Issue #10690 breaks compatibility with FreePBX and other types of configurations. reported by francesco_r http://bugs.digium.com/view.php?id=11543 |
| 23:26.49 | *** join/#asterisk-dev Laureano (n=chatzill@92-237-114-200.fibertel.com.ar) |
| 23:36.59 | tzafrir_home | russellb, there has already been a warning in that case |
| 23:37.34 | tzafrir_home | freepbx always #include-s a bunch of _custom files . Those files are not generated by default |
| 23:39.48 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 23:43.49 | Corydon76-vcch | tzafrir_home: well, they should be |
| 23:45.15 | tzafrir_home | First-off, they aren't. This breaks existing configurations |
| 23:46.13 | tzafrir_home | And common ones |
| 23:46.15 | tzafrir_home | Makes me a bit scared to upgrade on a stable branch |
| 23:47.33 | Corydon76-vcch | I dunno. I think not hosing your system is a better idea |
| 23:48.19 | tzafrir_home | Why is including a non-existing file an error? |
| 23:50.49 | tzafrir_home | Also, what happens if I write on the asterisk-gui config editor in users.conf the line: [abc=def |
| 23:51.06 | tzafrir_home | will it be written? |
| 23:52.24 | Corydon76-vcch | Written, yes. Used, no. |
| 23:52.46 | tzafrir_home | What do you mean? |
| 23:53.15 | blitzrage | why does Qwell rock? |
| 23:53.21 | tzafrir_home | Assuming that my manager user is actually from users.conf? |
| 23:53.21 | Corydon76-vcch | tzafrir_home: if you include an nonexistant file, it's clear that you meant something to happen. If nothing happens, that's an error |
| 23:53.44 | Corydon76-vcch | blitzrage: he broke FreePBX. ;-) |
| 23:53.49 | blitzrage | oh hawt :) |
| 23:53.51 | tzafrir_home | Corydon76-dig, well, in that case it isn't: it is an optional file. A hook |
| 23:54.08 | Corydon76-vcch | tzafrir_home: how are we supposed to know that? |
| 23:54.34 | tzafrir_home | So why fail so badly if it is missing? |
| 23:55.01 | Corydon76-vcch | How do we know the difference between a file that has a typo in the name and will fail spectacularly versus an optional file? |
| 23:55.44 | Corydon76-vcch | and if it truly is optional, what is wrong with forcing you to create an empty file, so that the parser registers an OK? |
| 23:55.56 | tzafrir_home | My view is that Asterisk should be running. An issue with config files could be handled with a reload. But by totally not processing things, a reload may not be possible |
| 23:56.11 | Corydon76-vcch | A reload is always possible |
| 23:56.19 | Corydon76-vcch | as long as the configs validate |
| 23:56.21 | tzafrir_home | If you can access the box |
| 23:56.52 | Corydon76-vcch | Why would you stop being able to access the box if a file load fails? |
| 23:57.17 | Corydon76-vcch | Think about it. Generally, if the file load fails, then you continue with the existing config. |
| 23:57.18 | tzafrir_home | And this is where the excessive dependency on users.conf and of accessing to anything through asterisk itself will be a big problem |
| 23:58.14 | Corydon76-vcch | Why would accessing things through asterisk be a big problem? I don't follow the logic. |
| 23:58.48 | tzafrir_home | Authenticating me requires parsing users.conf at some stage |
| 23:59.10 | Qwell | Corydon76-vcch: yeah, we were talking about it upstairs... |
| 23:59.17 | *** part/#asterisk-dev MikeJ (n=MikeJ@d149-67-220-106.try.wideopenwest.com) |
| 23:59.30 | Corydon76-vcch | tzafrir_home: and? |