| 00:07.54 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 00:22.39 | jtodd | icmp echo reply via private channel. |
| 00:30.12 | jets | destination unreachable! |
| 00:30.16 | jets | TTL expired! |
| 00:56.08 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 00:56.12 | wwalker | what file contains the inband audio decoder? |
| 01:05.32 | wwalker | dsp.c, duh |
| 01:14.36 | *** join/#asterisk-dev mosty (n=mosty@ppp191-34.static.internode.on.net) |
| 01:14.43 | jsmith | jtodd: 486 Busy Here? |
| 01:52.46 | seanbright | Corydon76-dig: ping? |
| 02:14.29 | Corydon76-dig | pong |
| 02:19.45 | lmadsen | ping |
| 02:22.40 | Corydon76-dig | lmadsen: to whom? |
| 02:23.48 | lmadsen | whoever wishes to reply |
| 02:24.03 | Corydon76-dig | whomever |
| 02:24.12 | lmadsen | don't correct me coder! |
| 02:24.24 | lmadsen | :D |
| 02:24.29 | Corydon76-dig | :P |
| 02:24.49 | seanbright | Corydon76-dig: you're the stdtime/localtime.c guy, yeah? |
| 02:25.00 | Corydon76-dig | Um, kind of |
| 02:25.18 | seanbright | well |
| 02:25.24 | seanbright | i guess it doesn't really matter |
| 02:25.28 | Corydon76-dig | It's mostly written by the government, but I've adapted it |
| 02:25.40 | seanbright | but i've been playing around with valgrind |
| 02:26.08 | Corydon76-dig | and you've found that it doesn't free some structures |
| 02:26.12 | Corydon76-dig | Ever |
| 02:26.13 | seanbright | correct. |
| 02:26.16 | seanbright | and that's ok |
| 02:26.18 | seanbright | i'm guessing |
| 02:26.18 | seanbright | :) |
| 02:26.24 | Corydon76-dig | Indeed |
| 02:26.27 | seanbright | the zonelist esp. |
| 02:26.43 | Corydon76-dig | Parsing the timezone files is a rather expensive operation, so we cache the results |
| 02:26.44 | seanbright | its not leaking because there is a fixed list of things that get allocated |
| 02:27.12 | Corydon76-dig | Right, there's no leak, because the pointers are kept in a list |
| 02:27.19 | seanbright | indeed. |
| 02:27.28 | Corydon76-dig | and each pointer is continuously reachable |
| 02:27.37 | seanbright | and there isn't a point in "properly" disposing of the list since it all gets dumped at shutdown anyway |
| 02:27.44 | Corydon76-dig | Right |
| 02:27.48 | seanbright | good times |
| 02:28.04 | seanbright | i put most of that together after the 'ping' but thanks for clearing it up |
| 02:28.38 | Corydon76-dig | The difference between that cache code and the government code is that the government code only keeps one timezone in memory |
| 02:28.54 | Corydon76-dig | and if you change the timezone, it dumps what was there before and parses a new file |
| 02:29.13 | Corydon76-dig | Obviously not optimal for people who use two or more timezones on their Asterisk box |
| 02:29.38 | seanbright | right |
| 02:32.25 | Corydon76-dig | The other major difference in that code is that we pass around a pointer to the timezone, instead of relying on an env var |
| 02:32.42 | Corydon76-dig | Basically, for thread safety |
| 02:32.52 | seanbright | speaking of thread safety |
| 02:32.58 | seanbright | i was looking at db-lib in freetds |
| 02:33.25 | seanbright | the way they do message and error handling isn't thread-safe |
| 02:33.35 | Corydon76-dig | Are you sure? |
| 02:33.43 | seanbright | 94% sure |
| 02:33.59 | seanbright | i think if you only have cdr_tds.so loaded, it wouldn't be a problem |
| 02:34.06 | Corydon76-dig | errno, for example, looks completely unsafe |
| 02:34.23 | seanbright | but i think if you loaded another module that used it, you would run into problems |
| 02:34.45 | Corydon76-dig | because of a singular mutex for accessing the code? |
| 02:35.18 | seanbright | let me find the relevant docs... |
| 02:36.14 | seanbright | http://www.freetds.org/userguide/samplecode.htm#SAMPLECODE.INIT |
| 02:36.23 | seanbright | take a look at part 2 of example 11-4 |
| 02:37.55 | Corydon76-dig | Callback? |
| 02:37.58 | seanbright | aye |
| 02:38.25 | seanbright | if two threads install competing callbacks, the second wipes out the first |
| 02:38.46 | seanbright | and looking at the source of that function in the library, i don't see any magic tls or anything |
| 02:41.52 | seanbright | its also conceivable i am talking out of my ass |
| 02:43.47 | Corydon76-dig | tls? |
| 02:44.53 | seanbright | thread local storage |
| 02:59.37 | seanbright | so am i right? |
| 03:19.05 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 03:32.19 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 04:01.05 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 04:22.24 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 04:54.25 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 06:09.14 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:59.50 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:58.22 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 10:11.56 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:23.30 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 10:51.46 | *** part/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 10:52.27 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 10:57.58 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:14.39 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 12:02.52 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:13.34 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:25.33 | *** join/#asterisk-dev juanjoc (n=juanjoc@host190.190-225-197.telecom.net.ar) |
| 12:46.08 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 12:51.44 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:02.10 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 13:02.10 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 13:16.54 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 13:18.48 | *** join/#asterisk-dev ZaVoid (n=zavoid@75.147.121.177) |
| 13:27.40 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 13:31.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.140.193) |
| 13:52.38 | *** join/#asterisk-dev __ys (i=yuri@91.151.196.254) |
| 13:56.37 | *** join/#asterisk-dev KenLee (n=k3leland@bg-fw2out.monmouth.com) |
| 14:20.26 | *** join/#asterisk-dev jeffg (i=VtJ1ILK5@pdpc/supporter/active/jeffg) |
| 14:34.23 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:34.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:38.09 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 14:55.04 | snuff-home | mm anyone seen 12872.. has 'addr out of bounds' on opt_args.. |
| 14:55.13 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:55.13 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:55.26 | snuff-home | ello jpeeler |
| 14:55.51 | jpeeler | hello |
| 14:56.37 | snuff-home | still working on that dadhi transformation stuff i assume? |
| 14:57.23 | snuff-home | mm.. 12872 is interesting.. args/options is ok but opt_args is bad |
| 14:57.37 | jpeeler | snuff-home: yeah... i'm going to do 1.6.0 today hopefully |
| 14:57.45 | jpeeler | M12872 |
| 14:57.47 | MuffinMan | [new] [Asterisk] Applications/app_dial 0012872: Asterisk -1.4.21 gives core dump reported by destiny6628 (Karma: neutral) http://bugs.digium.com/view.php?id=12872 |
| 14:58.31 | snuff-home | mm need snooze time.. later ppls |
| 15:04.40 | *** join/#asterisk-dev _foxfire_ (n=_foxfire@cica-adm.fe.up.pt) |
| 15:04.48 | tzafrir_laptop | Does DAHDI actually have a different ABI? |
| 15:07.16 | tzafrir_laptop | If I symlink /dev/zap ->dahdi and use /usr/include/zaptel/zaptel.h from zaptel 1.4.11 to build Asterisk, will it work with dahdi 2.0.0? |
| 15:07.51 | tzafrir_laptop | That is: with dahdi kernel modules loaded, configured by dahdi tools |
| 15:09.49 | jpeeler | i don't know if there have been any changes or not |
| 15:09.59 | jpeeler | it might work now, but certainly won't later |
| 15:13.35 | tzafrir_laptop | My near-future motivation is how to get DAHDI into Debian Lenny, that is in a process of freezing |
| 15:14.05 | tzafrir_laptop | I can't just kick out Zaptel, as it breaks things that use it |
| 15:14.30 | tzafrir_laptop | OTOH, I don't want to maintain zaptel 1.4 on my own for 2+ years |
| 15:15.33 | tzafrir_laptop | Waiting for everything to support dahdi may prove over-optimistic at this point |
| 15:17.33 | jpeeler | i see the nastiness |
| 15:18.34 | jpeeler | i could be wrong about the ABI though |
| 15:19.50 | ctooley | Zaptel 1.4 won't be "maintained" for bug fixes and security issues? |
| 15:20.50 | jpeeler | i didn't say that |
| 15:21.19 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:21.19 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:21.30 | ctooley | I didn't mean it that way, It appeared that tzafrir_laptop might be implying it. |
| 15:21.37 | ctooley | I was clarifying. |
| 15:22.53 | jpeeler | russellb: there is no plan to maintain ABI compatibility between DAHDI and Zaptel right? |
| 15:23.03 | russellb | correct |
| 15:23.08 | tzafrir_laptop | ctooley, if a package is included in Debian stable, it should get security fixes and critical bug fixes for the time it is stable + 1 year |
| 15:23.12 | russellb | quite the opposite |
| 15:23.18 | jpeeler | but Zaptel will still receive security fixes? |
| 15:23.32 | tzafrir_laptop | zaptel: 1.2? 1.4? |
| 15:23.54 | russellb | i'm not sure that has been decided ... I actually would expect zaptel 1.4 to get all bug fixes, too |
| 15:27.01 | seanbright | so i think i found a memory leak in astobj2 |
| 15:27.24 | seanbright | which was causing that http memory leak... |
| 15:28.37 | seanbright | could someone review a patch for me? i have to run to a meeting but i will pb it |
| 15:28.37 | russellb | orly |
| 15:28.50 | seanbright | the issue is container_destruct |
| 15:28.56 | seanbright | the buckets themselves are never freed |
| 15:29.38 | seanbright | since cb_cb always returns no match |
| 15:29.45 | seanbright | this patch seems to fix it here (against 1.4) |
| 15:29.47 | seanbright | http://pastebin.ca/1049187 |
| 15:29.50 | seanbright | gotta run for a bit |
| 15:29.54 | seanbright | back soon |
| 15:29.57 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:29.57 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:31.33 | russellb | seanbright: nice catch |
| 15:31.58 | russellb | seanbright: there is a simpler way to write that though ... |
| 15:32.41 | *** join/#asterisk-dev outtolunc (n=me@66.218.53.172) |
| 15:40.00 | russellb | seanbright: actually ... i don't think that is valid |
| 15:40.18 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 15:41.58 | russellb | seanbright: i take that back. you're right, but there is an easier way :) |
| 15:42.57 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 15:48.34 | russellb | ... not as easier as I originally thought ... |
| 15:51.19 | *** join/#asterisk-dev ccesario (n=ccesario@189.20.219.10) |
| 15:52.38 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 15:56.27 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 15:59.15 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 16:02.31 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.106.165) |
| 16:12.13 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 16:12.13 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 16:12.44 | seanbright | heh |
| 16:13.15 | seanbright | awww man... you applied it? weak |
| 16:13.15 | seanbright | heh |
| 16:14.33 | seanbright | russellb: thanks! |
| 16:14.42 | KenLee | seanbright: i submitted the http leak.. im going to apply your patch tonight |
| 16:14.55 | seanbright | KenLee: use the one from russell's commit |
| 16:15.02 | russellb | same end result |
| 16:15.04 | russellb | less lines of code, heh |
| 16:15.11 | seanbright | KenLee: i'm 94% sure that was your problem |
| 16:15.13 | russellb | i thought i could use an ao2 api call to do it |
| 16:15.15 | russellb | failed |
| 16:15.18 | russellb | seanbright: nice. |
| 16:15.40 | KenLee | cool thanks! |
| 16:15.47 | seanbright | KenLee: what was the bug number? |
| 16:16.13 | seanbright | is trying to think of other places where containers are created and destroyed with some frequency |
| 16:16.42 | Qwell | Tupperware factory. |
| 16:16.50 | KenLee | seanbright: 0012871 |
| 16:17.05 | ctooley_ | Qwell, or the lower quality Gladware |
| 16:17.13 | seanbright | slaps Qwell |
| 16:18.44 | seanbright | valgrind makes finding stuff like that *much* easier |
| 16:18.53 | seanbright | still took me a few hours though |
| 16:19.01 | seanbright | seeing as i'm not too smart and all. |
| 16:20.54 | KenLee | seabright: did the experimental memory leak detector catch it? |
| 16:21.26 | Corydon76-dig | seanbright: you sure fooled me |
| 16:25.04 | tzafrir_laptop | I try to use ./configure --with-dahdi=/path/to/dahdi/linuxtrunk |
| 16:25.41 | tzafrir_laptop | This properly sets DAHDI_INCLUDE, but aparantly it never gets used in the dahdi tools build |
| 16:25.53 | tzafrir_laptop | Fix that? |
| 16:38.08 | JerJer | who's your dahdi? |
| 16:41.25 | seanbright | KenLee: ummm, i did this |
| 16:41.37 | seanbright | valgrind -v --show-reachable=yes --leak-check=full --leak-resolution=high asterisk -cvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvg |
| 16:41.43 | seanbright | likes v's |
| 16:41.46 | seanbright | Corydon76-dig: thanks :) |
| 16:41.55 | JerJer | seanbright: i guess you do |
| 16:44.38 | Deeewayne | I like v's too! |
| 16:44.44 | putnopvut | I like V2's! |
| 16:46.10 | Qwell | that reminds me of a very very random thought I had the other day |
| 16:46.19 | Qwell | cars need a variable number of cylinders |
| 16:46.38 | Qwell | rather, need to run on a variable number. ie; have 8 in the car, but sometimes use 4 |
| 16:46.40 | jsmith | Qwell: Some engines allow you turn on and off different cylinders depending on engine load |
| 16:46.46 | Qwell | well then |
| 16:46.53 | jsmith | Qwell: but it's not too common |
| 16:46.53 | seanbright | hearts his v6 |
| 16:46.53 | Qwell | goes back to his hole |
| 16:46.56 | Deeewayne | how about: have 12 but sometimes use 8 |
| 16:47.01 | Qwell | Deeewayne: even better |
| 16:47.07 | Qwell | or, have 12, but sometimes use 3 |
| 16:47.15 | putnopvut | jsmith: the thing I've always wondered is if the same cylinders are always the ones that get shut off. |
| 16:47.45 | jsmith | putnopvut: Yes, that's my understanding. Which isn't ideal, but you wouldn't want two cylinders in a row turned off, know what I mean? |
| 16:48.09 | putnopvut | jsmith: right, I can't claim to know a lot about cars, but if the wear could be distributed somewhat, then I think it would be best. |
| 16:48.14 | seanbright | Corydon76-dig: did you have a chance to look at/think about what i was talking about last night re: freetds? |
| 16:49.13 | jsmith | putnopvut: I would tend to agree |
| 16:54.06 | Corydon76-dig | seanbright: thought about it, yes |
| 16:54.39 | Corydon76-dig | seanbright: but it may be no different from libcurl, for example, which has a global init |
| 16:54.59 | seanbright | its the global callback that worries me |
| 16:55.36 | Corydon76-dig | seanbright: question is, when an error occurs, is it just an error to report, or is it something you might be able to adjust a particular thread for? |
| 16:56.23 | seanbright | Corydon76-dig: true. for all intents and purposes we may be able to ignore the handlers completely. |
| 16:56.38 | seanbright | Corydon76-dig: assuming we get failure/success from the function calls |
| 16:56.43 | Corydon76-dig | Well, ignore the handlers in terms of thread-work |
| 16:56.46 | seanbright | Corydon76-dig: ah |
| 16:56.56 | seanbright | well i'll keep plugging away at it |
| 16:57.05 | Corydon76-dig | You can still set up the handlers during initialization, though |
| 17:34.42 | seanbright | must... do... work work... |
| 17:38.13 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 17:40.08 | kpfleming | tzafrir_laptop: you are going to move all the XPP perl modules and init/config stuff to dahdi-tools, right? |
| 17:41.00 | tzafrir_laptop | yes |
| 17:41.09 | kpfleming | excellent, thanks |
| 17:41.39 | tzafrir_laptop | not the module init scripts, though, as they are too tied up to the kernel modules |
| 17:43.05 | kpfleming | do they use the perl modules, or do they just use bash? |
| 17:49.33 | tzafrir_laptop | they use perl. But just one specific perl module which is included in that same directory |
| 17:49.40 | kpfleming | ugh |
| 17:49.46 | tzafrir_laptop | no dependency on the tools |
| 17:49.55 | kpfleming | so that module doesn't need to be 'installed'? |
| 17:50.16 | tzafrir_laptop | Will be in the same directory as the scripts |
| 17:50.38 | kpfleming | ok |
| 17:50.52 | tzafrir_laptop | That directory is set in a kernel module parameter, and defaults to /usr/share/zaptel |
| 17:51.44 | tzafrir_laptop | still zaptel? |
| 17:52.08 | kpfleming | are you asking me? |
| 17:53.22 | tzafrir_laptop | yup, still zaptel. One more thing to change |
| 17:55.01 | tzafrir_laptop | We originally used bash (/bin/sh, actually). Perl turned out to be faster |
| 17:55.36 | *** join/#asterisk-dev Burlington (n=Burlingt@fw01ext.voicepulse.com) |
| 17:56.09 | tzafrir_laptop | anyway, will the tools and drivers be distributed in separate tarballs? |
| 17:56.20 | tzafrir_laptop | What happens at the next API change? |
| 17:56.34 | kpfleming | yes, they will be in separate tarballs |
| 17:56.55 | kpfleming | as we've discussed many times before, API changes are backwards compatible, so older tools will work with newer modules |
| 18:02.43 | tzafrir_laptop | Another thing: is libtonezone actually being used in Asterisk? |
| 18:03.07 | tzafrir_laptop | because it is now responsible for a chain of dependencies: |
| 18:03.49 | tzafrir_laptop | asterisk->libtonezone(dahdi-toole), dahdi-tools->dahdi-linux |
| 18:06.35 | jpeeler | russellb: after i make this merge (and things appear to be sane) i think the request for testing needs to be announced |
| 18:08.33 | *** join/#asterisk-dev Burlington2 (n=burlingt@fw01ext.voicepulse.com) |
| 18:09.11 | russellb | jpeeler: k |
| 18:10.01 | russellb | jpeeler: kevin brought up one thing we have to fix in dahdi though ... firmware handling is broken |
| 18:10.29 | russellb | jpeeler: in the kernel package makefile ... it still tries to use menuselect stuff to decide what firmware it needs |
| 18:10.34 | russellb | jpeeler: and menuselect isn't there anymore |
| 18:10.38 | russellb | so that needs to be looked at and fixed |
| 18:10.50 | jpeeler | right |
| 18:10.54 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 18:11.19 | jpeeler | russellb: so are you saying that the testing should be delayed? i would think that just provides more time for those that don't depend on firmware |
| 18:11.43 | russellb | i suppose ... but it affects a pretty significant portion of our customers |
| 18:11.53 | russellb | so we should wait, i think |
| 18:13.07 | _ys | hi, please commit trivial patch from #12835 ? |
| 18:18.09 | putnopvut | _ys: I was just about to do that, actually :) |
| 18:18.28 | Corydon76-dig | putnopvut: you were? |
| 18:18.48 | Corydon76-dig | So was I, actually |
| 18:18.51 | putnopvut | Corydon76-dig: heh |
| 18:18.55 | putnopvut | Corydon76-dig: go ahead. |
| 18:19.22 | kpfleming | yeah, dahdi testing needs to wait a couple more days, i think |
| 18:20.03 | seanbright | dahdi doesn't have menuselect?! |
| 18:20.10 | seanbright | i'm done |
| 18:20.14 | _ys | have |
| 18:20.41 | kpfleming | the kernel module package doesn't, the userspace tools package does |
| 18:20.45 | seanbright | ohhh |
| 18:20.46 | seanbright | phew |
| 18:21.37 | seanbright | nmenuselect <3 |
| 18:23.28 | *** join/#asterisk-dev ccesario_ (n=ccesario@linux.unialco.com.br) |
| 18:25.04 | putnopvut | nmenuselect is pretty hawt. |
| 18:25.20 | seanbright | all the cool kids are using it |
| 18:25.44 | russellb | it's hawt ... except for some of the key bindings :-p |
| 18:25.53 | seanbright | blame redhat |
| 18:26.10 | russellb | blames microsoft |
| 18:26.12 | seanbright | menuselect is hawt... except for the numbering on the main menu... |
| 18:26.17 | seanbright | take that! |
| 18:26.25 | russellb | harsh |
| 18:26.57 | Corydon76-dig | seanbright: you disconnected kpfleming! |
| 18:27.21 | seanbright | hmmm |
| 18:27.23 | seanbright | take that! |
| 18:27.38 | seanbright | nope |
| 18:27.47 | seanbright | doesn't appear to work |
| 18:27.54 | Corydon76-dig | Well, he's still disconnected... |
| 18:28.00 | seanbright | true |
| 18:28.10 | seanbright | no reason to place blame |
| 18:28.26 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:28.26 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:28.33 | seanbright | there he is |
| 18:28.37 | seanbright | crisis averted |
| 18:29.00 | kpfleming | who, me? no crisis |
| 18:30.00 | russellb | you had the channel in tears |
| 18:30.16 | kpfleming | it was time for a reboot |
| 18:30.22 | kpfleming | something was very hosed in my X server |
| 18:30.38 | russellb | stupid open source software |
| 18:30.42 | russellb | can't rely on it for anything |
| 18:53.39 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:54.02 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 18:55.35 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 18:57.27 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 19:04.22 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-913882c10d68a9eb) |
| 19:20.03 | tzafrir_laptop | anyway, any change in the firmwares license? is it actually clarified anywhere? redistribution allowed? |
| 19:21.05 | Qwell | tzafrir_laptop: that's a kpfleming question |
| 19:21.15 | kpfleming | no changes at this time |
| 19:21.23 | kpfleming | still unclear, not well specified, etc. |
| 19:21.32 | tzafrir_laptop | the usual |
| 19:22.01 | kpfleming | yes, i have not been able to achieve anything useful in that area |
| 19:25.28 | russellb | Corydon76-dig: as I pointed out on the -dev list the last time you made those changes to chan_iax2, there is _NO_ deadlock avoidance that could cause that to happen |
| 19:26.00 | russellb | Corydon76-dig: it would be lack of the object being locked allowing it to change in between referencing the call number stored in the object |
| 19:26.25 | russellb | the only deadlock avoidance done in iax2_destroy is between the pvt and the ast_channel, which has nothing to do with what happens to the peer, registration, etc. objects |
| 19:27.12 | russellb | i just want to make sure we understand the issue you're fixing. |
| 19:27.22 | russellb | because the commit messages are not correct |
| 19:29.48 | Corydon76-dig | Oh, right, sorry |
| 19:35.24 | kpfleming | tzafrir_laptop: is there any point in descending into xpp/ at all if there is no USB support in the kernel? isn't USB support mandatory for xpp? |
| 19:36.08 | tzafrir_laptop | In the kernel or tools? |
| 19:36.11 | kpfleming | kernel |
| 19:37.09 | tzafrir_laptop | mostly yes. |
| 19:37.24 | kpfleming | i am building a Kconfig setup for dahdi-linux as well, for those people who want to drop DAHDI into a kernel tree |
| 19:37.26 | kpfleming | so just wondering |
| 19:37.34 | tzafrir_laptop | Depends how easy it is to override |
| 19:38.00 | kpfleming | for Kconfig purposes then, if USB is turned off, there's no point in descending, because the user could just turn USB on |
| 19:38.23 | tzafrir_laptop | because we have a non-USB backend for it as well |
| 19:38.30 | kpfleming | ahh |
| 19:38.36 | kpfleming | in the driver tree already? |
| 19:38.45 | tzafrir_laptop | Only internally |
| 19:38.50 | kpfleming | gotcha |
| 19:39.00 | tzafrir_laptop | But commit it and we'll see how it goes |
| 19:39.12 | kpfleming | well, you'll see what i've built in a few minutes... there's no need for anyone to use it though, the existing build system will still be in place |
| 19:39.13 | tzafrir_laptop | It can always be reverted |
| 19:40.48 | kpfleming | ahh... i see, the parport_debug module |
| 19:42.14 | tzafrir_laptop | no. |
| 19:42.28 | tzafrir_laptop | something different |
| 19:42.40 | russellb | well now you have to tell us :-p |
| 19:43.24 | tzafrir_laptop | the backend used in the blackfin appliance . It's called xpp_mmap . Basically similar to xpp_usb |
| 19:43.33 | tzafrir_laptop | But using a different "pipe" |
| 19:43.39 | russellb | gotcha. |
| 19:43.47 | kpfleming | that makes sense |
| 19:44.23 | kpfleming | well, this will make your life (and ours) somewhat easier, because my goal is to make it so that the dahdi-linux tree can be just 'plugged in' to the blackfin uclinux-dist kernel tree and be part of the kernel |
| 19:47.04 | tzafrir_laptop | Right. There were all sorts of small patches we needed to apply to the octasic part of the zaptel tree to make it build on blackfin |
| 19:47.04 | tzafrir_laptop | Some silly ifdef-s |
| 19:47.12 | kpfleming | yeah, we don't use that stuff on blackfin |
| 19:47.30 | kpfleming | feel free to send them my way and i'll put them into our branch of the octasic kit |
| 19:52.47 | tzafrir_laptop | ok, sent |
| 19:53.22 | Corydon76-dig | issue 12744#88783 |
| 19:53.29 | Qwell | M |
| 19:53.41 | seanbright | M12744#88783 |
| 19:53.44 | MuffinMan | [12744#0088783] Commented by reallost1 on 06-16-08 at 17:53: I'll be doing that this week, I hope. I've been sandbagging levees. |
| 19:53.56 | seanbright | if i had a dime... |
| 19:54.02 | Qwell | seanbright: you'd have $.20 |
| 19:54.18 | seanbright | Qwell: i want to fist fight you today for some reason |
| 19:54.27 | Corydon76-dig | Somebody needs to fix the help system on Muffinman |
| 19:54.32 | putnopvut | seanbright: you insensitive clod! Qwell has no fists! |
| 19:56.11 | seanbright | well then it should be a quick fight |
| 19:56.44 | Corydon76-dig | Make love, not war |
| 19:56.58 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 19:57.41 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 19:57.55 | putnopvut | Corydon76-dig: you insensitive clod! Qwell has no fists! |
| 19:58.07 | putnopvut | Yeah! I went there! |
| 19:58.51 | Corydon76-dig | putnopvut: oooooooookay... /me notes that it's not past 6 pm yet... |
| 19:59.03 | putnopvut | It is somewhere. |
| 19:59.52 | seanbright | over the atlantic |
| 20:00.03 | Corydon76-dig | over the rainbow |
| 20:00.07 | seanbright | way up high |
| 20:00.18 | putnopvut | there's a land that I heard of once in a lullabye |
| 20:00.38 | seanbright | some day i'll wish upon a star and wake up where the clouds are far behinnnnddd meeee |
| 20:00.57 | Corydon76-dig | Okay, Dorothy |
| 20:01.02 | seanbright | heh |
| 20:01.09 | putnopvut | was the lion in his sixth grade Wizard of Oz play. |
| 20:01.10 | Corydon76-dig | or 'friend of' |
| 20:01.15 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 20:02.23 | seanbright | codefreeze-lap: that's why you're supposed to 'stop now' |
| 20:02.49 | Corydon76-dig | The US military once launched an investigation into who this Dorothy was, so they could figure out why so many enlisted men turned out to be 'a friend of Dorothy' |
| 20:03.32 | Qwell | Corydon76-dig: do I dare ask what 'a friend of Dorothy' is? |
| 20:03.41 | Corydon76-dig | Google. ;-) |
| 20:03.49 | Qwell | so, no |
| 20:04.38 | seanbright | punches Qwell in the face |
| 20:04.50 | Corydon76-dig | putnopvut: so you were a dandy lion? |
| 20:05.13 | Corydon76-dig | http://en.wikipedia.org/wiki/Friend_of_Dorothy |
| 20:06.41 | codefreeze-lap | seanbright: lol |
| 20:09.44 | seanbright | codefreeze-lap: i don't get how that could happen... |
| 20:10.04 | seanbright | codefreeze-lap: if load succeeds, 'settings' should be *something* |
| 20:11.44 | seanbright | oh well, i'll test better next time. |
| 20:25.54 | codefreeze-lap | seanbright: mine is not to question why. I went out and fetched all the libs needed for all the cdr backends, and load 'em all. Either there's no config file for it, or it's nonsense... the changes should be harmless to folks really using the tds backend. |
| 20:26.11 | codefreeze-lap | wonders who got the 123456 revision! |
| 20:26.27 | Qwell | putnopvut |
| 20:26.28 | seanbright | putnopvut :) |
| 20:26.42 | putnopvut | Heck yeah I did. |
| 20:27.00 | jsmith | putnopvut: And I'll bet you weren't even trying, were you... |
| 20:27.01 | codefreeze-lap | the lucky bum! |
| 20:27.34 | codefreeze-lap | Naw, just noticing it was coming up. |
| 20:27.40 | codefreeze-lap | then gone. |
| 20:27.44 | putnopvut | I think I did that with another nicely numbered revision. |
| 20:27.48 | putnopvut | Like 90000 maybe. |
| 20:30.04 | Qwell | putnopvut: why not just make ast_skip_nonblanks take a const char *? |
| 20:30.29 | Qwell | I guess that would be an API change though. |
| 20:30.30 | putnopvut | Qwell: Because that would create tons more warnings to have to fix. |
| 20:30.47 | russellb | no it wouldn't |
| 20:30.58 | russellb | you can pass a char * to a func expecting const char * |
| 20:30.59 | russellb | no warning |
| 20:31.03 | russellb | it's the other way around that will give warnings |
| 20:31.09 | putnopvut | Oh, I was thinking the other way around. |
| 20:31.12 | russellb | nods |
| 20:32.30 | jpeeler | that's good to know |
| 20:49.23 | smth | hi, how can I collect the "--" leading message of asterisk. are they only available on cli ? |
| 21:10.16 | jpeeler | what does it mean to specify a channel on /dev/dahdi/channel? |
| 21:12.24 | Corydon76-dig | smth: Those are verbose level 3 messages |
| 21:13.06 | Corydon76-dig | smth: you can collect them by turning on verbose logging in logger.conf, but remember that you have to keep the console verbose level at 3 or higher |
| 21:13.24 | kpfleming | jpeeler: so you can actually connect to a channel |
| 21:13.29 | Corydon76-dig | If you drop the console verbosity, it'll also drop the messages to the log |
| 21:13.38 | kpfleming | instead of opening /dev/dahdi/N, you open /dev/dahdi/channel, then 'switch' to channel N |
| 21:13.53 | kpfleming | so you don't actually need device nodes for all the channels |
| 21:18.16 | jpeeler | once you switch to the numbered channel, nothing else has access to it? |
| 21:18.27 | jpeeler | and in this case, what is a channel defined as? |
| 21:18.53 | kpfleming | a channel is dahdi channel, same as opening /dev/dahdi/1, or 2, or 3, .etc |
| 21:19.09 | kpfleming | a channel on a span, either physical or virtual |
| 21:19.28 | kpfleming | yes, normally channels are opened in exclusive mode, i don't think it is possible to have multiple opens on the same channel |
| 21:22.12 | codefreeze-lap | Anybody know off-hand, of problems with the sip qualify=... and qualifyreq=... for a peer? I'm trying to find the poison in 12484, and these seem to trigger some really spicy lockups. |
| 21:25.36 | jsmith | codefreeze-lap: The only thing that I know about is that if you have qualify=yes for a large number of peers, then Asterisk tries to send out all the SIP OPTIONS packets at the same time |
| 21:25.53 | jsmith | codefreeze-lap: Which can have interesting results |
| 21:25.53 | lmadsen | is there a scheduler that would help that? |
| 21:26.59 | codefreeze-lap | uh, I meant qualifyfreq previous, j.i.c. I only have 7 peers. |
| 21:27.45 | codefreeze-lap | I have qualify=4000 |
| 21:27.45 | codefreeze-lap | qualifyfreq=20 |
| 21:28.36 | codefreeze-lap | Oh, and this is in trunk, so there may be a regression there in this respect. |
| 21:29.33 | codefreeze-lap | lmadsen: a scheduler? as in "have your people call my people, and let's have lunch" ? |
| 21:31.42 | lmadsen | codefreeze-lap: exactly :) |
| 21:31.59 | lmadsen | codefreeze-lap: I meant something that would make the OPTIONS play nice and schedule them to go out at sane intervals |
| 21:33.57 | codefreeze-lap | Well, that kind of situation is done in other parts, methinks. When I had like 4700 peers, I noticed that the scheduler got loaded with 4700 events, spaced like 100 msec apart, smearing events over like 8 minutes. |
| 21:34.16 | codefreeze-lap | I'm probably somewhat off on all numbers, but the idea is there. |
| 21:35.04 | lmadsen | aye |
| 21:50.51 | *** join/#asterisk-dev lateil (n=oz@88.239.82.46) |
| 22:06.59 | lateil | hello, if i see %99 cpu usage on asterisk... do you think it might be about a deadlock? or is there a way which i can see what is eating cpu on asterisk |
| 22:15.44 | lmadsen | lateil: you can enable the debugging option "DEBUG_LOCKS" (I think that's what it's called...), recompile and install, then you can do a 'core show locks' from the CLI |
| 22:15.56 | lmadsen | sorry... DEBUG_CHANNEL_LOCKS |
| 22:16.22 | lmadsen | asterisk -rx "core show locks" > /tmp/locks_output.txt |
| 22:17.14 | lmadsen | I'm pretty sure that's the method... someone will correct me if I'm wrong I'm sure :) |
| 22:17.34 | lateil | got it .. |
| 22:18.11 | lateil | actually i tried this .. but when i compile with this.. i can not reproduce the err :( |
| 22:20.18 | lmadsen | :( |
| 22:20.24 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 22:20.41 | lmadsen | I love when adding debugging info causes the issue to go away... |
| 22:22.09 | lateil | i will be happy to run with debuging version :) it it wasn't effect performance |
| 22:22.31 | lmadsen | you should not notice it |
| 22:22.49 | lmadsen | its not super heavy from what I understand |
| 22:23.30 | lateil | actually i am .. customers start complain about line cuts, wrong dtmf sounds while talks ... |
| 22:23.41 | putnopvut | lmadsen and lateil: The correct compiler flag needed for core show locks is DEBUG_THREADS |
| 22:23.53 | lmadsen | putnopvut: well that seems counter intuitive :) |
| 22:24.16 | lmadsen | my apologies for the wrong info |
| 22:24.44 | russellb | we could add DEBUG_LOCKS as an alias ... |
| 22:24.46 | russellb | that's what it really is |
| 22:24.49 | lateil | nope, that what is DEBUG_CHANNEL_LOCKS used for? |
| 22:24.51 | russellb | but DEBUG_THREADS has been around so long |
| 22:24.58 | russellb | i don't want to remove it |
| 22:30.00 | lateil | Corydon76-dig: i saw #0012795 , it seems symptoms are match with my problem... but i check the logs and don't see any iax activity.. do you think this deadlock can happen without active iax channel? |
| 22:47.39 | Corydon76-dig | lateil: without seeing a 'core show locks', I have no idea |
| 22:48.19 | lateil | that is a problem cuz i can not reporduce it with debug_thread :) |
| 22:48.32 | Corydon76-dig | Then just run with that flag, then |
| 22:49.13 | lateil | i do but , customers start complain about line cuts, wrong dtmf sounds while talks ... :) |
| 22:55.24 | lateil | guys i need your opinion here, i am in need of a parent state on agent channel.When customer logins via agentcallback, i will change that agent channel status with its parent channel status. |
| 22:56.17 | lateil | i am thinking like this... i will add a devicestate thread on chan_agent .. it will loop over agents , looks if the change is agents parent .. and changes the agent channel state .. |
| 22:56.36 | smth | Corydon76-dig, got "--" messages in file messages after enabled the verbose on logger.conf. another question is if these messges are also available through AMI ? |
| 22:56.46 | lateil | is that sounds good? i think i can borrow code from app_queue |
| 22:57.05 | Corydon76-dig | smth: Pretty sure they aren't |
| 22:57.34 | smth | Ok, I see. many thanks |
| 22:57.54 | Corydon76-dig | smth: however, you can generate your own special events from the dialplan with UserEvent |
| 23:05.22 | seanbright | newbie question... |
| 23:05.39 | seanbright | how does one do the mojo after the username? i.e. russell@asterisk/developer-and-stable-maintainer/drumkilla |
| 23:07.09 | smth | Corydon76-dig, that may be helpful. actually, I am thinking how to make a test a voicemail box. and test check a voicemail since the voicemail build with IMAP sometimes got into crash ;). only the --leading messages can give out notes where the call is. especially the call already into voicemailmain. |
| 23:11.38 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 23:16.45 | Corydon76-dig | seanbright: Have you made a donation to Freenode? |
| 23:17.25 | seanbright | Corydon76-dig: i just found it. no, i haven't. |
| 23:17.33 | Corydon76-dig | seanbright: if you have, all you need to do is contact an IRCop in #freenode-social and request a custom hostmask |
| 23:18.56 | Corydon76-dig | Treat them like their time is more important than yours, "Please", and "Thank you" gets you what you want almost immediately. |
| 23:19.35 | seanbright | well i want an asterisk one |
| 23:19.38 | Corydon76-dig | Interestingly, almost nobody tells them 'thank you', so they love you when you say it. |
| 23:19.51 | seanbright | the web page suggests i need to speak to my "project contact" |
| 23:20.06 | seanbright | or project leader, rather |
| 23:20.10 | Corydon76-dig | That would be Russell, I think |
| 23:20.17 | seanbright | excellent |
| 23:20.21 | seanbright | i will donate, of course. |
| 23:21.21 | Corydon76-dig | Mine just says 'pdpc/supporter/bronze' |
| 23:38.47 | seanbright | yeah i saw that |
| 23:38.56 | *** join/#asterisk-dev Cobra2599 (i=user@cpe-69-205-158-227.stny.res.rr.com) |
| 23:39.03 | Cobra2599 | Hello all |
| 23:46.11 | *** part/#asterisk-dev Cobra2599 (i=user@cpe-69-205-158-227.stny.res.rr.com) |