| 00:12.28 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:12.29 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:35.38 | snuff-home | mm.. what's best way to determine if a confbridge exists.. atm i use return val from CONFBRIDGE_INFO(marked,${EXTEN}) |
| 00:39.08 | pabelanger | So, should I be worried about this flooding dmesg |
| 00:39.09 | pabelanger | [25279.471246] wct4xxp 0000:05:08.0: 2G: Got interrupt, status = 0013000a, CIS = 0080 |
| 00:39.18 | pabelanger | Then my PRI drops |
| 01:01.48 | pabelanger | For DAHDI timing, if I sync internal, would IRQ's affect that or not? |
| 01:01.58 | pabelanger | version slaving clock from the network? |
| 02:05.54 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 02:05.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:20.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:20.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:37.25 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:37.25 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:45.44 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcylpqwbhnlssylq) |
| 02:45.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:17.02 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bcylpqwbhnlssylq) |
| 06:30.57 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 06:30.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:32.37 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1005) |
| 07:32.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:36.08 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:04.53 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:04.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:25.15 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8064:c60a:b7ad:204f) |
| 09:11.53 | *** join/#asterisk-dev hurdman (~ygcheny@c3p0.r0b0t.fr) |
| 09:14.21 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 11:45.05 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 11:51.26 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:51.26 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:48.25 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 12:48.36 | bombev | hii guys :) |
| 12:52.09 | oej | hi |
| 13:14.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:14.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:47.26 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hewvwpqluxecnwxe) |
| 13:47.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:50.33 | mjordan | wdoekes: DUMMY? |
| 13:53.17 | tonyclewis | mjordan: ping |
| 13:53.25 | tonyclewis | I was told you were looking for me yesterday |
| 13:53.32 | mjordan | hm. I think Rusty was |
| 13:53.35 | mjordan | let me find the issue |
| 13:55.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mzawzeyvpnlziycm) |
| 14:06.42 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 14:16.02 | file | mjordan, yow'sa |
| 14:24.04 | mjordan | ? |
| 14:24.34 | file | @ calendar commit |
| 14:24.45 | mjordan | o |
| 14:24.59 | mjordan | yeah. The issue reporter is still seeing some small leak, but it's possible that it's just the caching of the ao2 object |
| 14:25.06 | mjordan | but he had a valgrind dump! |
| 14:25.24 | mjordan | how can you pass up a memory leak with an actual valgrind output :-D |
| 14:46.53 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:46.53 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:53.56 | pabelanger | DAHDI peeps |
| 14:54.04 | pabelanger | Asked last night, but was too late |
| 14:54.33 | pabelanger | if I get clocking for my interface from internal, will process involve the IRQ? |
| 14:54.49 | pabelanger | And if I use external timing, same question. |
| 14:55.00 | pabelanger | or, does my question not even make sense |
| 14:55.23 | pabelanger | I am trying to figure out why, if I take clocking from the CO do I see all sorts of CRC errors |
| 14:55.30 | pabelanger | but as soon as I change to internal, they go away |
| 15:27.36 | Kobaz | yeah |
| 15:31.58 | *** join/#asterisk-dev Tim_Toady (~fuzzy@194.50.55.245) |
| 15:59.10 | rmeyerriecks | pabelanger: which card? |
| 16:16.38 | pabelanger | rmeyerriecks, Found a Wildcard: Wildcard TE220 (5th Gen) |
| 16:17.39 | rmeyerriecks | pabelanger: and no crc errors if it's on local timing? |
| 16:17.45 | pabelanger | rmeyerriecks, right |
| 16:17.54 | pabelanger | but as soon as we change to network, tons |
| 16:18.00 | rmeyerriecks | what about slips? |
| 16:18.13 | pabelanger | telco insists the circuit is clean |
| 16:18.50 | rmeyerriecks | do you see any slips? |
| 16:18.52 | pabelanger | rmeyerriecks, where do you want me to check that |
| 16:18.57 | pabelanger | I just see a flood of |
| 16:18.58 | pabelanger | [2013-01-29 13:33:46.130] NOTICE[1532] chan_dahdi.c: PRI got event: HDLC Abort (6) on D-channel of span 1 |
| 16:19.04 | rmeyerriecks | use dahdi_maint in dahdi-tools |
| 16:19.12 | rmeyerriecks | or I think it's in /proc/dahdi/<span no> |
| 16:20.13 | pabelanger | rmeyerriecks, http://pastebin.com/bZWiH9G9 |
| 16:20.16 | pabelanger | that was from yesterday |
| 16:20.50 | pabelanger | http://pastebin.com/cFGEjmeV |
| 16:20.52 | pabelanger | is right now |
| 16:24.23 | rmeyerriecks | pabelanger: Looks like DAHDI-1013 :O( |
| 16:25.08 | pabelanger | rmeyerriecks, https://issues.asterisk.org/jira/browse/DAHDI-1013 ? |
| 16:25.20 | rmeyerriecks | pabelanger: aye |
| 16:25.28 | pabelanger | I don't have permission to view it |
| 16:26.48 | pabelanger | must be an internal issue |
| 16:27.16 | pabelanger | rmeyerriecks, what does the ticket talk about? |
| 16:33.41 | rmeyerriecks | pabelanger: Another customer had a similar issue, we're still trying to resolve it. Do you have physical access to the card? |
| 16:33.57 | pabelanger | rmeyerriecks, yes, I can |
| 16:34.17 | pabelanger | rmeyerriecks, what me to contact digium support? |
| 16:34.56 | pabelanger | Also, is it card specific? EG: if I change to an older 1 port TE, would it be affected |
| 16:37.14 | rmeyerriecks | pabelanger: not sure, is this a production system, can you get a /var/log/messages snapshot with module parameter debug=1 set? |
| 16:37.54 | pabelanger | rmeyerriecks, Ya, it is production. I can get anything you need, but need to schedule it with the client |
| 16:38.13 | pabelanger | so, if you let me know what you all want, I can schedule some time to do it |
| 16:40.21 | rmeyerriecks | I see, I'd like to see that snapshot and maybe a photo of the white sticker on the back of the card with the bar code |
| 16:41.00 | pabelanger | rmeyerriecks, okay. I can get the photo now, will ask client |
| 16:41.12 | pabelanger | then schedule some time for debug message |
| 16:41.24 | pabelanger | that will likely happen at 5:30pm EST |
| 16:41.43 | pabelanger | rmeyerriecks, Is there a digium support ticket ID for this |
| 16:41.46 | rmeyerriecks | okay, great, sorry your having troubles |
| 16:42.01 | pabelanger | going to see about calling in and getting more details about it and add my name to the ticket too |
| 16:43.26 | rmeyerriecks | not that I'm aware of |
| 16:47.09 | rmeyerriecks | pabelanger: You should probably call digium support anyway and open a ticket |
| 17:08.50 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1003) |
| 17:08.51 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 17:15.41 | pabelanger | rmeyerriecks, will do. Is the issue board specific? |
| 17:28.44 | seanbright | so a few times a day, the 1 minute load average on our asterisk servers climbs to over 4.0 and within a minute or so drops back down to 1.0 |
| 17:29.23 | seanbright | i have a script that monitors the load average, but in order to determine what is causing the load increase, what information should i collect from asterisk during these heavy periods? |
| 17:34.37 | rmeyerriecks | pabelanger: I'm not sure |
| 18:25.56 | leifmadsen | seanbright: I think starting with a 'core show locks' is probably a good idea |
| 18:26.08 | leifmadsen | perhaps there is an influx of calls or somethign that ends up causing lots of locking? |
| 18:26.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:51.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 18:51.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 18:56.16 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:56.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:58.16 | *** join/#asterisk-dev Corydon76-home (six@c-69-137-80-31.hsd1.tn.comcast.net) |
| 18:58.16 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 19:03.26 | pabelanger | Calling Digium support |
| 19:03.33 | pabelanger | first time for everything |
| 19:03.41 | pabelanger | quick, what is the backdoor for the support queue |
| 19:08.53 | opticron | shibboleet |
| 19:10.33 | Marquis42 | opticron: Well played |
| 19:16.47 | pabelanger | rmeyerriecks, issue opened |
| 19:19.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:19.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:35.47 | *** join/#asterisk-dev Simon-- (~sim@2606:6a00:0:28:5604:a6ff:fe02:702b) |
| 20:21.14 | seanbright | leifmadsen: core show locks requires a recompile right? |
| 20:21.36 | leifmadsen | seanbright: don't think so |
| 20:21.49 | leifmadsen | could be wrong... |
| 20:22.38 | seanbright | DEBUG_THREADS |
| 20:22.54 | seanbright | i wonder how big a performance hit that would be |
| 20:23.46 | leifmadsen | oh is that required? huh... |
| 20:24.00 | leifmadsen | ya I'm not sure what the performance hit on that is... I'd be curious too |
| 20:24.26 | leifmadsen | I feel like I should already know that answer :) |
| 20:24.27 | leifmadsen | Corydon76-home: ?? |
| 20:25.01 | Corydon76-home | It requires a bunch of extra memory per lock |
| 20:25.22 | leifmadsen | other than memory, any performance hit in terms of number of calls / cpu power? |
| 20:25.51 | Corydon76-home | I'm sure there's a little, but it shouldn't have a big impact. |
| 20:25.55 | leifmadsen | cool |
| 20:26.01 | seanbright | nice |
| 20:26.03 | seanbright | thanks guys |
| 20:27.06 | Corydon76-home | Every time you lock a mutex, it does a new memory allocation, I believe |
| 20:27.41 | leifmadsen | Every time you lock a mutex, a kitten dies. |
| 20:28.45 | Corydon76-home | This is exactly why we have non-tracking mutexes, otherwise there'd be a potential loop between memory allocation debugging and lock debugging |
| 20:57.37 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:57.37 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:59.57 | wdoekes | seanbright: I tried debug_threads for the core show locks |
| 21:00.06 | wdoekes | it was horrible |
| 21:00.28 | newtonr | seanbright: I saw that it really wasn't clear anywhere , so I just created this page here based on the chat. https://wiki.asterisk.org/wiki/display/AST/CLI+commands+useful+for+debugging |
| 21:00.57 | *** join/#asterisk-dev alsuren_ (~dlaban@188-221-138-117.zone12.bethere.co.uk) |
| 21:01.04 | newtonr | didn't add a whole lot to it. You guys add more! |
| 21:01.21 | wdoekes | restarting several live systems without it again was not fun |
| 21:02.33 | mjordan | yeah... DEBUG_THREADS has a very large performance hit |
| 21:03.16 | wdoekes | leifmadsen: chown of the asterisk binary? |
| 21:04.01 | leifmadsen | eh? |
| 21:04.26 | wdoekes | asterisk-Install page |
| 21:04.30 | newtonr | mjordan: would BETTER_BACKTRACES enhance 'core show locks' output as well? |
| 21:05.27 | leifmadsen | wdoekes: I'm not sure if you're asking if I should be doing that, or if you think I'm bat shit crazy for doing it :) |
| 21:05.37 | mjordan | newtonr: significantly |
| 21:05.45 | wdoekes | crazy? |
| 21:06.11 | leifmadsen | wdoekes: mind leaving a note about that? I'll be reviewing everything tomorrow morning. I;d clean things up now if I had the time |
| 21:06.24 | leifmadsen | and it'll be at 7:15am tomorrow, so I'll likely be in some stupor and not remember about this :) |
| 21:06.41 | newtonr | mjordan: cool, i'll mention that on the page i just added then |
| 21:06.48 | wdoekes | done. |
| 21:06.53 | leifmadsen | wdoekes: rock, thanks |
| 21:09.14 | seanbright | ok, so core show locks is out |
| 21:09.28 | seanbright | can you make a process dump a core file without killing it? |
| 21:09.36 | seanbright | and would that even be useful? |
| 21:10.30 | seanbright | i guess core show threads might help |
| 21:11.15 | seanbright | ah, yes, i see the docs on getting a "live" backtrace |
| 21:21.33 | tzafrir_laptop | rmeyerriecks, I could not the new version in (as expected). So no need for a special tarball of 2.6.2-rc1 just that. |
| 21:24.19 | rmeyerriecks | tzafrir_laptop: Sorry, what? |
| 21:26.21 | newtonr | https://wiki.asterisk.org/wiki/display/AST/CLI+commands+useful+for+debugging now that page looks a little better, and added an example 'core show locks' with BETTER_BACKTRACES enabled |
| 21:41.40 | Qwell | wdoekes: Something like this is what I was referring to on r2304. I'd be interested in hearing your thoughts. http://pastebin.com/tLUPEwGd |
| 21:44.44 | Corydon76-home | newtonr: the only reason BETTER_BACKTRACES isn't enabled by default is the license |
| 21:47.19 | Qwell | Corydon76-home: ? |
| 21:47.27 | Corydon76-home | It's GPL |
| 21:47.53 | Corydon76-home | So any of the non-GPL licensees cannot use it |
| 21:50.08 | newtonr | Corydon76-home: silly licenses, always getting in the way of things |
| 21:50.25 | Corydon76-home | I enjoy that he was able to get equivalent backtraces for exactly the same lock scenario, and the addresses all line up neatly |
| 21:51.25 | newtonr | Corydon76-home: i was labbing up a feature code attended xfer problem, so i was already setup to do it :D |
| 21:51.51 | Corydon76-home | btw, I recommend never looking into what the better backtrace code is doing. It will drive you batty for a week or more |
| 21:52.25 | newtonr | well, i'm not a developer, so it would probably drive me mad immediately |
| 21:52.42 | Qwell | newtonr: You're already mad. |
| 21:52.51 | Corydon76-home | The story for why the library is named "BFD" is amusing... |
| 21:54.19 | newtonr | Qwell: agreed |
| 22:06.05 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 22:12.42 | wdoekes | Qwell: I could certainly dig the conditional make_version |
| 22:13.15 | wdoekes | running that when we're doing clean/distclean didn't make sense |
| 22:14.09 | wdoekes | your paste could use some work. it's doing an infloop here ;) |
| 22:14.22 | Qwell | infloop? |
| 22:14.27 | Qwell | oh |
| 22:14.46 | Corydon76-home | I could see it when we're running clean; but that you have to run configure in order to make distclean is very illogical to me |
| 22:17.41 | Qwell | wdoekes: I'm not sure what might be causing that. |
| 22:17.53 | Qwell | Corydon76-home: This is a different thing |
| 22:18.34 | Qwell | wdoekes: this patch is supposed to be against my current branch. could that be where the loop is coming from? |
| 22:19.44 | wdoekes | it looped both on r2291+2192 and on a clean 11.x |
| 22:19.52 | wdoekes | s/2192/2292 |
| 22:19.57 | Qwell | weird |
| 22:19.59 | *** part/#asterisk-dev Simon-- (~sim@2606:6a00:0:28:5604:a6ff:fe02:702b) |
| 22:20.22 | Qwell | There's not a whole lot to it, dependency-wise |
| 22:22.43 | wdoekes | you're including a file which doesn't exist. then you make it, but don't get it included immediately.. right? |
| 22:23.03 | Qwell | It's a -include though |
| 22:24.35 | wdoekes | aside from the loop. how do we get it included first? |
| 22:25.03 | Qwell | the -include. If it doesn't exist, it'll get built, and then included. In theory. |
| 22:25.52 | wdoekes | hm |
| 22:26.08 | Qwell | Mind pastebin'ing a make -n? |
| 22:26.43 | wdoekes | removing the FORCE makes it work |
| 22:26.55 | Qwell | it needs to be forced though |
| 22:28.29 | Qwell | actually, .PHONY should work there |
| 22:28.39 | wdoekes | tried that |
| 22:29.07 | wdoekes | make -n sits quietly. -d shows me this: |
| 22:29.26 | wdoekes | <PROTECTED> |
| 22:29.26 | wdoekes | <PROTECTED> |
| 22:29.26 | wdoekes | <PROTECTED> |
| 22:29.26 | wdoekes | <PROTECTED> |
| 22:30.22 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:30.22 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:32.07 | Qwell | wth |
| 22:34.33 | wdoekes | http://fpaste.org/UOOG/ |
| 22:34.40 | Qwell | oh. targets prefixed with @ don't show up in debug either |
| 22:35.27 | wdoekes | enough for today. ciao |
| 22:52.12 | mjordan | bah, stupid lower casing |
| 22:53.13 | file | yes. |
| 23:36.50 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hewvwpqluxecnwxe) |