| 00:08.29 | *** join/#asterisk-dev bbryant1 (~brett@c-174-56-132-225.hsd1.sc.comcast.net) |
| 00:08.29 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 00:17.03 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:17.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:44.15 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 00:44.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:44.53 | sruffell | seanbright: still here? |
| 00:47.04 | seanbright | sruffell: i am |
| 00:47.16 | seanbright | i don't want to be a support vampire |
| 00:47.26 | seanbright | the second i annoy you, send me to digium support |
| 00:47.28 | seanbright | please |
| 00:47.32 | sruffell | no..no problem. For you there isn't anything that you would bring up that wouldn't come to me. |
| 00:48.13 | sruffell | Was that with 2.5.0? |
| 00:48.21 | sruffell | and could you tell me what was happening? |
| 00:48.39 | seanbright | DAHDI Version: 2.4.1.2 |
| 00:49.19 | sruffell | okâ¦.let me check if there is a path through the code that would block in that down call... |
| 00:49.21 | seanbright | i wish i could, i had to reboot the machine to get things going again and i lost everything but what i sent you |
| 00:49.55 | seanbright | that machine is simple stupid - accepts a call via SIP/ulaw and sends it over an IAX2/g729 trunk |
| 00:50.13 | seanbright | no recording, no local channels or fancy dialplan |
| 01:00.38 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 01:07.19 | sruffell | hmmâ¦.I don't see a way that could happen. Even if the card dies and stops responding to commands for channel setup / teardown, any pending commands should be timed out and the card marked dead. Soâ¦I'm probably missing something. |
| 01:07.39 | sruffell | seanbright: You pretty much run these cards constantly? mostly trouble free? |
| 01:07.48 | sruffell | and how many do you have in production? |
| 01:12.47 | seanbright | sruffell: in that machine, just 1 |
| 01:12.59 | seanbright | we have 4 more floating around |
| 01:13.26 | seanbright | and yeah, the run constantly |
| 01:13.31 | seanbright | they* |
| 01:14.05 | sruffell | one theory is that mod_timer(&wc->watchdog, jiffies+1) is racingâ¦so that it's in the past by the time the timer runs. I can't say if that is safe off the top of my head. But that hang on the down you sent was the first time I've ever seen something like that from the field. |
| 01:14.27 | sruffell | â¦so I'm looking in the kernel sources to see if that can happen. |
| 01:14.34 | seanbright | is there anything i can send you that would be useful? dmidecode output or anything? |
| 01:14.46 | sruffell | yesâ¦and the kernel version would help on that machine. |
| 01:15.08 | seanbright | anything in dmidecode i wouldn't want to pastebin? |
| 01:15.59 | sruffell | could you email me the entire output? |
| 01:16.10 | seanbright | sure |
| 01:16.15 | sruffell | thanks |
| 01:18.18 | seanbright | sruffell: sent. |
| 01:28.01 | seanbright | sruffell: i thought it was sent... having mail server problems at the moment |
| 01:28.07 | seanbright | Linux bz-pbx 2.6.31-23-generic #75-Ubuntu SMP Fri Mar 18 18:16:06 UTC 2011 x86_64 GNU/Linux |
| 01:29.44 | sruffell | hmm..ok. The doc says it safe to set times in the pastâ¦but I thought I ran into a problem in the past with that in another context but I haven't found any commit message to that effect yet. |
| 01:30.57 | seanbright | yuck... just realized this machine is still karmic |
| 01:35.26 | seanbright | sruffell: i sent that from my @malleable.com account for some reason, just fyi |
| 01:35.35 | seanbright | i'm a bit out of it |
| 01:35.48 | sruffell | hehâ¦I just noticed that I got it, thanks |
| 01:39.16 | seanbright | sruffell: i hate to ask for help and then leave, but i'm an hours drive from home so i'm going to jet |
| 01:39.26 | seanbright | if you need more info from me, just shoot me an email |
| 01:39.29 | seanbright | i appreciate you taking a look |
| 01:39.31 | sruffell | oh..no problemâ¦..I'll talk to you tomorrow |
| 01:39.35 | sruffell | 'night |
| 01:53.14 | sruffell | seanbright: I imagine you're already gone but rhttp://svnview.digium.com/svn/dahdi?view=revision&revision=8868 is what I was looking for. |
| 03:41.05 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 04:26.25 | *** join/#asterisk-dev irroot (~irroot@41.122.164.84) |
| 04:39.06 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 04:39.06 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 04:50.29 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 04:50.31 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 04:50.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:50.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 04:55.31 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 05:23.25 | *** join/#asterisk-dev irroot (~irroot@41.122.210.137) |
| 06:00.01 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:24.05 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:03.33 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:04.13 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:04.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:11.22 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:68bd:652:f770:b2e7) |
| 08:32.26 | *** join/#asterisk-dev kaii (~kh@ciphron.de) |
| 10:41.30 | *** join/#asterisk-dev oej (~olle@46-22-127-214.bredband.alvsjo.qonet.se) |
| 10:41.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:43.48 | oej | Hello folks |
| 10:46.47 | *** join/#asterisk-dev Fritz09 (~Adium@pop1-1207.catv.wtnet.de) |
| 11:08.12 | *** join/#asterisk-dev razu (~razu@2001:ad0:1:1:202:b3ff:fe36:921c) |
| 11:32.05 | *** join/#asterisk-dev droemel (~droemel@p4FCAD476.dip.t-dialin.net) |
| 11:34.27 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 11:49.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:49.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:08.34 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 12:23.27 | *** join/#asterisk-dev droemel (~droemel@p4FCAD621.dip.t-dialin.net) |
| 12:48.26 | *** join/#asterisk-dev droemel (~droemel@p4FCADC9D.dip.t-dialin.net) |
| 13:05.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ikrmpdexujhefehu) |
| 13:05.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mqvwyqutqtrpfhun) |
| 13:05.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:08.55 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:08.55 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:09.26 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:09.26 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:01.10 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:01.10 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:12.47 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:12.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:14.53 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 14:21.49 | seanbright | sruffell: both the machine that you wrote that initial patch for and the machine that ran into some trouble yesterday were the same specs, just different boxes |
| 14:22.05 | sruffell | same kernel? |
| 14:22.07 | seanbright | both running karmic, although the kernel versions were probably different |
| 14:22.12 | sruffell | hmm... |
| 14:22.13 | sruffell | ok |
| 14:22.18 | seanbright | i don't have access to that original machine anymore |
| 14:22.23 | seanbright | it's in pakistan |
| 14:22.29 | seanbright | probably being used as a paper weight |
| 14:23.19 | sruffell | heh..ok, I'll need to look into that some more then. Best guess is that the system gets loaded, and is hitting a condition where a timer is set in the past and for some reason your kernel configuration isn't allowing it to run on the next timer tick. |
| 14:24.59 | seanbright | i am headed down to belize on sunday so i may just in-place upgrade to lucid when i'm there |
| 14:25.19 | seanbright | although historically when i do updates i end up breaking something |
| 14:38.58 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:43.10 | sruffell | seanbright: I think I could give you a patch that might test this theory and work around it. Your error was generated because the task was blocked on the semaphone for 120 seconds. I could change the two down() calls to something with a timeout, and if they timeout after a second, re-schedule the timer, log a message and return -EGAIN. So, if you hit this there would still be a pause in all setup / teardowns of channels for a secon |
| 14:44.07 | sruffell | butâ¦that's not a fixâ¦.but I don't have the time right now to completely try to recreate your setup here and see if I can induce what you're seeing. (and I do not currently use any of the Ubuntu kernels in my test environment) |
| 14:44.15 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:44.15 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:44.37 | sruffell | something else I was thinking I could do is just use the generic timer on the AN983 to handle this polling mode and not rely on the kernel timersâ¦.but that seems more risky if you need to deploy on Sunday. |
| 14:45.20 | sruffell | finallyâ¦you could disable the polling mode entirely by setting the "POLLING_CALL_THRESHOLD" value in wctc4xxp/base.c to something high like 999. |
| 14:48.03 | irroot | sruffell see sangoma have a 2.5.0 friendly driver out seems to work well FYI |
| 14:51.31 | sruffell | cool, although I generally only concern myself with drivers shipped in the DAHDI repos. |
| 14:52.00 | pabelanger | I'm pretty surprise to find there is no CDR events fired with Asterisk writes one, making it a little difficult to test with. So, using mjordan new TestEvent AMI event, I'm considering adding something to help notify the testsuite of it |
| 14:52.00 | irroot | sruffell understandable :P |
| 14:52.12 | seanbright | sruffell: so of those options - what is your recommendation? |
| 14:52.21 | seanbright | i don't _have_ to deploy on sunday fwiw |
| 14:52.43 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 14:53.05 | sruffell | wellâ¦the engineer in me wants to go with the first one to confirm the theory. the systems integrator in me would recommend the third one if time is tight. |
| 14:53.23 | seanbright | i like to fix things |
| 14:53.25 | seanbright | so first one it is |
| 14:53.26 | seanbright | :-) |
| 14:58.01 | seanbright | sruffell: the volume on that machine is relatively light, ~40 people log on around the same time and in theory they don't disconnect for 2 to 3 hours at a time |
| 14:58.48 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 14:58.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:58.52 | sruffell | okâ¦.then I'll open a DAHLIN issue for this and email you the issue number. |
| 14:59.03 | sruffell | won't be until tomorrow that I could send you anythin.g |
| 14:59.08 | seanbright | no worries |
| 14:59.11 | seanbright | i appreciate your help |
| 15:14.32 | oej | Afternoon folks |
| 15:15.17 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 15:22.21 | irroot | evening oej happy spring day tommorow :P |
| 15:31.06 | oej | Tomorrow? |
| 15:35.35 | seanbright | sruffell: at minimum i will upgrade to 2.5.0 on sunday |
| 15:36.36 | irroot | oej yeah its 1sept getting warmer already ofcourse season changes 1week of aug |
| 15:36.50 | irroot | swiming pools open tommorow |
| 15:36.56 | oej | he he |
| 15:37.04 | oej | We're going the other direction :-) |
| 15:37.18 | oej | I'm looking for customers in sunny places for december-march |
| 15:38.30 | anonymouz666 | Brazil then |
| 15:39.23 | anonymouz666 | And I am going to Sweden for dec-march |
| 15:40.25 | anonymouz666 | oej: "hur mar du? mycket bra tack" :P |
| 15:42.09 | irroot | south africa we got lions :P |
| 15:42.39 | oej | I always wanted to get down to South Africa, but my friends at Connection Telecom says that there's no market for my trainings there. |
| 15:43.06 | oej | Anyone wanting to go to Sweden during the dark times is strange. But feel welcome :-) |
| 15:44.20 | irroot | oej yeah do come rob and steve are good guys indeed you over skilled :P |
| 15:44.41 | sruffell | seanbright: ok |
| 15:45.00 | oej | It's a long flight down to the sunshine :-) |
| 15:45.14 | sruffell | seanbright: just a heads up (but it shouldn't really impact you much) there will be a 2.5.x.y release started early next week. |
| 15:45.47 | sruffell | there is one thing tzafrir_laptop is chasing down, but once that's resolved, we'll roll it out. |
| 15:46.01 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:46.01 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:48.01 | seanbright | sruffell: cool |
| 15:49.19 | oej | I'm envious of that Laptop that tzafrir has, a laptop that chases bugs. Impressive. |
| 15:51.01 | sruffell | :) |
| 15:51.14 | sruffell | If I had one of those I would just drink margerita's all day. |
| 15:51.56 | kpfleming | oej: that 3Com thing was especially bad since the message body isn't even tagged with MIME encapsulation telling you what it is... it's just lines of stuff. terrible implementation. |
| 15:52.32 | oej | kpfleming: Yes, I've seen worse stuff while testing at SIPit with them. Not very surprised. |
| 15:53.58 | oej | I just got good ideas from Terry on how to move forward now that we have sqlite. We can finally stop using astdb from chan_sip and store the regs in a proper database format. |
| 15:54.28 | kpfleming | you could... although there are probably applications out there that expect them to be in astdb |
| 15:54.34 | jsmith | oej: Now you're starting to scare me :-) |
| 15:54.56 | jsmith | Before you know it, we'll have queued calls in the database as well... |
| 15:55.01 | oej | Yes, but they can still reach it over astdb/realtime that I have |
| 15:55.15 | jsmith | ... and just think of the can of worms that will create :-) |
| 15:55.15 | kpfleming | but the format will be different... so yeah. who knows. |
| 15:55.32 | jsmith | is only half-joking, of course |
| 15:55.34 | oej | I think we should send media over mysql. I mean, there are stored procedures and variables. And the replication is great and fast! |
| 15:55.56 | oej | kpfleming: It could be a configuration option. Using realtime would give more functionality. |
| 15:55.57 | *** join/#asterisk-dev gnuday (~gnuday@79.135.102.11) |
| 15:56.07 | gnuday | Hi I'm looking for a site with some examples for py-asterisk. Any suggestions? Thanks |
| 15:56.15 | Qwell | gnuday: Wrong channel - try #asterisk. |
| 15:56.24 | oej | The pain of having to be backwards compatible... |
| 15:56.35 | oej | Sometimes we just need to move forward! |
| 15:56.51 | kpfleming | or at least sideways |
| 15:56.55 | oej | And hide from Ward Mundy (you here Ward?) |
| 15:59.58 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 16:23.34 | oej | So why does AST.pdf in 1.8 include 1.10 docs and notes about conferences and Fosdem 2011? |
| 16:24.53 | oej | And I can't open AST.txt in vi? Something's very broken. |
| 16:26.04 | otherwiseguy | oej: If my day is any indication, I'd say it is the world that is broken. |
| 16:26.23 | jsmith | otherwiseguy: +1 |
| 16:26.25 | oej | otherwiseguy: I told you already. You need cinnamon buns. |
| 16:26.42 | otherwiseguy | oej: I am doing my best to earn them right now. ;-) |
| 16:35.37 | oej | otherwiseguy: Why don't you trust me when I say you've earned them? :-) |
| 16:36.11 | oej | Got a project today which might mean that I have to complete more parts of mini-voicemail. I propably want to rename it then. |
| 16:36.37 | oej | mega-voicemail :-) |
| 16:36.48 | otherwiseguy | oej: Too much work to do to indulge now. The U.S. was settled by those damned Puritans. It has completely warped us as a civilization. ;-) |
| 16:37.21 | oej | he he. You should really come to Europe to get a decent break. |
| 16:37.42 | otherwiseguy | I have a friend who is trying to convince me to go to Germany with him for a week sometime. |
| 16:38.11 | file | otherwiseguy, what doesn't he try to get you to do?!? |
| 16:38.48 | otherwiseguy | file: he has never tried to get me to dance with a frog whilst eating a burrito and playing the tambourines. |
| 16:39.00 | otherwiseguy | there are probably other examples. |
| 16:41.29 | oej | otherwiseguy: Go to Germany for the beer and up here for nice company, hacking and a nice country in general :-) |
| 16:42.12 | oej | otherwiseguy: Why don't you just dance with a frog whilst eating a burrito and playing the tambourines? Sounds like a fun project. |
| 16:42.42 | otherwiseguy | next idea: "realtime export <filename>" that calls a callback in the realtime driver that dumps that actively loaded ast_config for the filename to the realtime backend. |
| 16:42.51 | otherwiseguy | (for static realtime stuff) |
| 16:43.25 | otherwiseguy | oej: I may have to do that. |
| 16:43.36 | otherwiseguy | (the travel, not the frog) :-) |
| 16:43.48 | oej | I don't think it should be "realtime" but "config export realtime ..." |
| 16:44.08 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 16:44.45 | oej | Corydon has done amazing work with realtime, so I guess you can actually create the tables that way now. Very nice for stuff like FreePBX and alikes. |
| 16:45.06 | otherwiseguy | oej: agreed. config export would be better. |
| 16:46.17 | otherwiseguy | oej: and with built-in sqlite3 and realtime AMI commands over http, you wouldn't even need a back-end scripting language, but could still do SQL-y kinds of things. The AMI config handling stuff is so horribleâ¦using realtime commands seems like it would be so much better. |
| 16:46.53 | oej | Absolutely. Agree. Another cinnamon bun for you. Seems to work well to bribe you :-) |
| 16:47.42 | oej | Going out for a while. I like your realtime ideas there, Terry. That will improve things a lot. |
| 16:48.27 | otherwiseguy | Of course, if we allow things like that we will need to watch for SQL-injection like attacks, etc. |
| 16:48.41 | otherwiseguy | oej: thanks. Have a nice night. |
| 16:48.46 | oej | Security - who needs it? |
| 16:48.48 | oej | :-) |
| 16:48.53 | oej | Thanks. The same! |
| 16:50.21 | otherwiseguy | I would also like to see the realtime api alternate fields like column, operation, value instead of what we do now and add "column LIKE", value and have to parse the text into something non-sql for some things, etc. It is messy. |
| 16:51.02 | *** join/#asterisk-dev irroot (~irroot@41.122.201.125) |
| 16:51.03 | otherwiseguy | operation could be RT_EQUAL/LT/GT/LIKE, etc. and the drivers could then translate those as they see fit. |
| 16:57.05 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 16:59.11 | oron_laptop | sruffell: about sysfs-t1e1, the current plan won't work with span auto assignment |
| 17:01.53 | sruffell | :/ why? |
| 17:02.37 | sruffell | as you pinged me I'm moving those changes onto the working sysfs branch... |
| 17:03.11 | oron_laptop | sruffell: because the device registers and the spans are immediatly assigned -- there's no time for user-space to write the sysfs attribute. |
| 17:03.35 | sruffell | ohâ¦yeahâ¦.in that case, it'll just have to use what the default_lineconfig setting was. |
| 17:03.53 | sruffell | soâ¦when the device is registered, it will have a linemode setâ¦just not what the user may want. |
| 17:03.58 | sruffell | but that'll be completely backwards compatible. |
| 17:04.05 | oron_laptop | sruffell: It's just occured to me there's an alternative... a bit crazy though... |
| 17:04.12 | sruffell | I'm thinking that this next release will have all the hooksâ¦but the *normal* behavior will be just like what it is now. |
| 17:04.48 | oron_laptop | sruffell: what do you think about the following: |
| 17:05.20 | oron_laptop | sruffell: * device registers, dahdi issues a "request_firmware" for all the E1/T1 spans |
| 17:06.01 | oron_laptop | sruffell: * The "firmware" name should be something like "<hardware/location>_<offset>_e1t1" |
| 17:06.34 | oron_laptop | sruffell: * administrator can create/symlink the proper names to a file containing E1 or T1 string |
| 17:06.59 | oron_laptop | sruffell: * If there's no file the defaults apply. |
| 17:07.07 | oron_laptop | sruffell: What do you think? |
| 17:08.03 | sruffell | how is that different then the driver sets defaults (based on jumpers, module parameters) and then udev / dahdi_cfg (in udev mode) / wrapper script writes the /sys/bus/dahdi_devices/<x>/spantype[linemode] register if there is a setting configured? |
| 17:08.46 | sruffell | when the udev scripts are smart enough to set the linemode by defaultâ¦it'll be smart enough to load the driver with auto_register_spans off by default, right? |
| 17:09.23 | oron_laptop | sruffell: In that the request_firmware would work with/without auto_register_spans |
| 17:09.50 | oron_laptop | sruffell: the driver would know if/when the "firmware" was loaded and can decide if defaults should be applied |
| 17:10.52 | sruffell | thinks |
| 17:11.50 | oron_laptop | sruffell: an advantage of current script method, is that its more flexible (e.g: I implemented wildcards) |
| 17:12.02 | sruffell | although when we eventually drop the auto_register spans..the request_firmware link wouldn't be able to go into the configuration files like all the other span configurationâ¦it would need to be this extra files sysadmins / installation scripts need to maintain? (just thinking out loud) |
| 17:12.45 | sruffell | I'm hoping we can consolidate the configuration of dahdi devices moving forward. (I'm most exicited about the prospect of dropping the blacklist that has to be installed) |
| 17:13.47 | oron_laptop | sruffell: If the idea is to deprecate auto_register_spans, than current plan is OK. |
| 17:14.37 | sruffell | that's my thoughtâ¦that evntually down the line we would like to remove thatâ¦it's just something to hold us over for a year or five to maintain backwards compatibility. What do you think? |
| 17:14.49 | oron_laptop | sruffell: did you move the sysfs attribute from the span to the device after all? |
| 17:15.00 | sruffell | is for eliminating any knob or switch that is reasonable. |
| 17:15.30 | sruffell | I moved the unregister out of the span and into the deviceâ¦.yes. Is that what you're talking about? |
| 17:15.40 | sruffell | so the register / unregister for spans is an attribute on the device. |
| 17:15.41 | oron_laptop | sruffell: yes, good. |
| 17:18.01 | oron_laptop | sruffell: Do you have this code up yet? I want to update my "unassign" code for this. |
| 17:18.26 | sruffell | oron_laptop: not yetâ¦so just move all the sysfs-t1e1 down onto the sysfs branch? I can do that right now if you want? |
| 17:18.52 | sruffell | againâ¦we'll clean it all up on the sysfs-for-trunk before committingâ¦.which I still think Tzafrir's going to need to do... |
| 17:19.02 | sruffell | the committingâ¦not the cleanpu. |
| 17:19.03 | sruffell | cleanu |
| 17:19.07 | sruffell | :( cleanup |
| 17:19.18 | oron_laptop | sruffell: sounds good. |
| 17:20.47 | sruffell | okâ¦https://github.com/sruffell/dahdi-linux/commits/sysfs/ has all the recent changesâ¦I'll fixup the for-trunk branch as best I can right now. |
| 17:21.29 | sruffell | (note..I haven't run that since merging in the recent trunk changesâ¦â¦which I'll also do here in a bit) |
| 17:21.44 | oron_laptop | start testing the new code... |
| 17:23.24 | sruffell | and I should have said "the assign / unassign for spans is an attribute on the device" :) |
| 17:30.27 | oron_laptop | sruffell: smoke testing looks good so far. |
| 17:30.44 | sruffell | \o/ |
| 17:31.16 | oron_laptop | sruffell: small unrelated human factor: span offset are numbered from 0, span numbers from 1 -- that's a mess... |
| 17:31.48 | sruffell | yeahâ¦.think we should do offsets from 1 as attributes? it's inconsistent even in the code. |
| 17:32.12 | oron_laptop | sruffell: agreed, |
| 17:32.13 | sruffell | the <offset>:<val> on the attributes is a bit messy too. |
| 17:32.54 | oron_laptop | sruffell: In what way? |
| 17:33.08 | sruffell | okâ¦unless you beat me to itâ¦I'll change the span offsets to start at 1 for places where humans would look. |
| 17:33.26 | oron_laptop | sruffell: I'll pass (this time ;-) |
| 17:33.56 | sruffell | it doesn't follow the attributes should only have one value. We have this protocol in the sysfs attributesâ¦but the alternative is to have span subdirectories that will then be duplicated by the real span objects on the dahdi_span busâ¦.blech. |
| 17:38.23 | oron_laptop | sruffell: Well if DAHDI controlled the span allocation, it could have preallocated spans on device registration (without channels yet)... |
| 17:38.31 | irroot | ok who wants me to work on what this jack daniels is good :P |
| 17:39.26 | oron_laptop | sruffell: so you would have half-prepared span directories. |
| 17:40.05 | oron_laptop | sruffell: after the span are assigned, it could send a udev ONLINE event, to notify user space that everything is ready. |
| 17:40.30 | sruffell | wouldn't we then be back where we started where we might have to rename these span objects if we want the "span-x" name to match the span number that asterisk is currently used to? |
| 17:41.38 | sruffell | I did look to see if the dahdi_spans directory could just contain symlinks that had a *different* name from the span-x objects that were children of their devices but I didn't see how I could do that. |
| 17:41.43 | sruffell | that would have solved the problem though... |
| 17:42.10 | sruffell | then all the spans would be named purely by their offset on their device, and not the global spanno that the core has assigned them.... |
| 17:47.08 | oron_laptop | sruffell: about span-x pre-creation, you are correct of course (head not working...) |
| 17:49.48 | sruffell | wellâ¦the true endgame for all of this is all your -by-name workâ¦.then the spanno would be vestigial |
| 17:51.14 | oron_laptop | sruffell: I intend to retrofit the kernel part on top of pinned-spans. Regardless of "by-name" it'll give us sysfs channel representation. |
| 17:51.37 | sruffell | nods |
| 17:51.38 | oron_laptop | sruffell: (just retrofitting dahdi-sysfs-chans.c) |
| 18:00.08 | sruffell | oron_laptop: just a heads up for youâ¦.since I do not think there will be time for a complete solution (the user space parts all defined) before we'll need to pull the 2.6 trigger I'm thinking 2.6 will have the new code in their operating in auto_[register|assign]_spans mode by default. Then someone could hand switch things around if they wanted to but we wouldn't really recommend anyone do that until the user space parts are done. |
| 18:00.12 | sruffell | any problems with that? |
| 18:01.05 | sruffell | wellâ¦the -k option to dahdi_cfg should go into the next release thoughâ¦even though it too wouldn't be set by default. |
| 18:01.10 | oron_laptop | sruffell: I think that's reasonable. |
| 18:52.34 | mickecarlsson | sends a virtual beer to Matt Jordan re ASTERISK-1728 |
| 18:52.53 | mickecarlsson | Hmm, ASTERISK-17288 that is |
| 18:58.23 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 18:59.45 | mickecarlsson | WARNING[32319] loader.c: Error loading module 'res_config_odbc.so': /usr/lib/asterisk/modules/res_config_odbc.so: undefined symbol: ast_odbc_clear_cache |
| 18:59.59 | mickecarlsson | Does res_config_odbc be preloaded? |
| 19:00.08 | mickecarlsson | need to be preloaded? |
| 19:00.41 | mickecarlsson | In log file I get this a couple of times, then it is loaded OK |
| 19:00.46 | mickecarlsson | In 1.8.6.0 |
| 19:06.15 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 19:07.55 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 19:08.29 | mickecarlsson | After some testing: Yes, as stated in modules.conf.samples, odbc needs to be preloaded |
| 19:09.27 | pabelanger | pretty sure that will not be an issue in Asterisk 10, I thought Corydon76-home added some magic to handle that |
| 19:10.12 | Corydon76-home | res_odbc.so needs to load prior to res_config_odbc.so |
| 19:10.48 | Corydon76-home | If you preload any modules, then you have to preload all modules in the right order |
| 19:11.30 | Corydon76-home | Preloads are sorted by themselves, before other modules |
| 19:12.01 | pabelanger | All I remember is you doing some work some month ago about loading modules, I though part of it was if a module needed another module, it automatically preloaded it |
| 19:12.05 | pabelanger | must have been wrong |
| 19:16.00 | Corydon76-home | No, it's just about sorting the modules to make them load in the correct order, so that preload is no longer necessary |
| 19:17.34 | oron_laptop | sruffell: I have a the "dial_byname" channels on top of your sysfs branch, want to test it? (seems to work) |
| 19:18.20 | sruffell | eekâ¦I won't be able to right nowâ¦. |
| 19:18.26 | sruffell | (but in general, yes) |
| 19:20.26 | pabelanger | Corydon76-home: right, so in Asterisk 10 would you still see: Error loading module 'res_config_odbc.so': /usr/lib/asterisk/modules/res_config_odbc.so: undefined symbol: ast_odbc_clear_cache |
| 19:21.16 | Corydon76-home | pabelanger: shouldn't, as long as you haven't 'noload'ed res_odbc.so or 'preload'ed res_config_odbc.so without also 'preload'ing res_odbc.so |
| 19:21.34 | pabelanger | okay cool |
| 19:21.35 | pabelanger | thanks |
| 19:22.10 | Corydon76-home | Also, if you have autoload off, then you need to load all modules... |
| 19:22.21 | Corydon76-home | but I don't think many people turn autoload off |
| 19:23.27 | Corydon76-home | All that it really does is to ensure that of the modules that are loaded at a certain time, they are loaded in a particular order, based upon a defined level |
| 19:24.05 | Corydon76-home | If not otherwise specified, everything is at level 128 (0-255) |
| 19:24.37 | mickecarlsson | So in 10 there is no need to preload? |
| 19:24.49 | Corydon76-home | Not anymore |
| 19:25.21 | Corydon76-home | For backwards compatibility, if you've done that, it will continue to work, but the idea is to make it easier for new users |
| 19:25.26 | oron_laptop | sruffell: I'll send it to you anyway ;-) |
| 19:25.50 | mickecarlsson | Hmm, need to test that as we need to preload chan_local before queues module |
| 19:25.56 | oron_laptop | sruffell: The nice thing is that it's orthognal to pinned-spans: |
| 19:25.57 | sruffell | heh..yes..please doâ¦I can mix it in even if I don't try to use the features specifically. |
| 19:26.24 | oron_laptop | sruffell: 1. pinned-spans does its magic before span assignment. |
| 19:26.46 | oron_laptop | sruffell: 2. dial_byname works on the spans *after* they are assigned. |
| 19:26.54 | oron_laptop | sruffell: looks nice. |
| 19:26.56 | Corydon76-home | mickecarlsson: right, and if you're doing chan_local, then you also need pbx_config before app_queue |
| 19:27.19 | mickecarlsson | yes, discovered that the hard way about a year ago |
| 19:27.36 | mickecarlsson | Our support queue was to quiet |
| 19:28.06 | Corydon76-home | Actually, all of this is in 1.8, too |
| 19:28.30 | mickecarlsson | Oh, is it? Nice |
| 19:29.20 | Corydon76-home | They are the MODPRI constants in include/asterisk/module.h |
| 19:29.32 | mickecarlsson | is looking |
| 19:30.47 | mickecarlsson | So all modules now has a tag attached to them |
| 19:31.17 | Corydon76-home | It's a priority number, in the module header, yes |
| 19:32.34 | mickecarlsson | load_pri, found it |
| 19:37.50 | mickecarlsson | ok, so I cleaned out modules.conf, no more preloads, still complaints about undefined symbol in res_config_odbc |
| 19:40.58 | Corydon76-home | Did you noload res_odbc.so ? |
| 19:42.51 | pabelanger | leifmadsen: kicking of bamboo for asterisk 1.8.6.0 release :) Lets see the results |
| 19:44.56 | leifmadsen | pabelanger: niiiice -- next time we'll run it before the release :) |
| 19:45.11 | leifmadsen | you'll have to show me how to trigger it after tagging |
| 19:45.40 | pabelanger | leifmadsen: well, at that point we already have, rc-1, rc-2. etc |
| 19:45.41 | mickecarlsson | <Corydon76-home>: no, I don't think so (checking) |
| 19:46.17 | pabelanger | moving from rcX -> release will not break a test, because we are just rebuilding the tarball from the last rc |
| 19:46.20 | pabelanger | no code changes |
| 19:46.24 | pabelanger | ideally |
| 19:47.17 | leifmadsen | pabelanger: true true, just would be good to know how to trigger them once I create an RC I guess |
| 19:47.33 | mickecarlsson | Corydon76-home: I only have [modules] and autoload=yes in my modules.conf |
| 19:47.44 | mickecarlsson | Still complaining |
| 19:48.24 | Corydon76-home | Weird |
| 19:48.37 | Corydon76-home | mickecarlsson: you sure it's the only modules.conf on your system? |
| 19:49.20 | Corydon76-home | It has happened that somebody installed to both /etc/asterisk and /usr/local/etc/asterisk and was modifying the wrong copy |
| 19:49.35 | pabelanger | leifmadsen: indeed. Still working out that process, I suspect it will be a manual one. Something I can show you or document how to do |
| 19:49.52 | leifmadsen | pabelanger: yep I should be able to follow some documentation :) |
| 19:49.55 | leifmadsen | I figured it'd be manual |
| 19:50.37 | mickecarlsson | Corydon76-home: checking |
| 19:52.30 | kpfleming | leifmadsen: i am investigating ASTERISK-18394, so you probably don't need to handle it as a normal issue. i suspect there is no bug there, it's just a configuration problem (and general T.38 stupidity) |
| 19:52.40 | kpfleming | i had not yet assigned it to myself, i was in a meeting :-) |
| 19:53.01 | leifmadsen | kpfleming: fair enough :) I just saw the fax issue, and those are hard for me to triage in general :) |
| 19:53.16 | kpfleming | yep |
| 19:56.23 | mickecarlsson | Corydon76-home: only one modules.conf, I even emptied it |
| 19:56.35 | mickecarlsson | [modules] |
| 19:56.35 | mickecarlsson | autoload=yes |
| 19:56.45 | mickecarlsson | Still complaining (1.8.6.0) |
| 19:57.04 | Corydon76-home | mickecarlsson: File a bug; I'm not sure what's wrong, but it bears investigating |
| 19:57.14 | mickecarlsson | OK, will do. Thanks |
| 19:59.59 | Corydon76-home | mickecarlsson: include all troubleshooting steps from here, because those are likely the first steps in triage |
| 20:00.10 | mickecarlsson | Will do |
| 20:02.11 | Corydon76-home | mickecarlsson: I'm assuming there were no messages preceding this from res_odbc, right? |
| 20:02.37 | mickecarlsson | Hmm, looking |
| 20:02.48 | mickecarlsson | NOTICE[860] loader.c: 195 modules will be loaded. |
| 20:02.56 | mickecarlsson | WARNING[860] loader.c: Error loading module 'res_config_odbc.so': |
| 20:02.58 | mickecarlsson | No |
| 20:03.03 | Corydon76-home | Okay |
| 20:03.27 | Corydon76-home | and res_odbc.so exists in the modules directory, right? |
| 20:03.59 | mickecarlsson | Yes |
| 20:04.08 | mickecarlsson | NOTICE[860] config.c: Registered Config Engine odbc |
| 20:04.08 | mickecarlsson | [Aug 31 21:54:45] VERBOSE[860] res_config_odbc.c: res_config_odbc loaded. |
| 20:04.20 | mickecarlsson | A couple of lines down |
| 20:04.46 | mickecarlsson | I will include my full log file in the ticket |
| 20:04.57 | mickecarlsson | Should I zip it? |
| 20:05.07 | mickecarlsson | 261kb |
| 20:05.17 | Corydon76-home | Trim it down, first |
| 20:05.24 | mickecarlsson | ok |
| 20:06.08 | Corydon76-home | WTF? You should never get that message about res_config_odbc loaded if res_odbc did not load first |
| 20:06.46 | mickecarlsson | :-) |
| 20:07.12 | *** part/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 20:08.37 | wdoekes2 | Corydon76-home: I can reproduce (with res_sqlite) both with autoload=yes and no |
| 20:08.48 | wdoekes2 | we were talking about features loading from disk instead of staticrt right? |
| 20:10.49 | Corydon76-home | mickecarlsson: I think I know what the problem is, but it's not solveable, because it's a bug in the DL library |
| 20:10.56 | mickecarlsson | ok |
| 20:11.14 | Corydon76-home | Specifically, the DL library is not paying attention to the RTLD_LAZY flag |
| 20:11.18 | mickecarlsson | I will file a ticket for it, but I am setting it to trivial |
| 20:11.56 | Corydon76-home | That flag should force the library not to try to resolve symbols until they're actually referenced |
| 20:13.49 | Corydon76-home | mickecarlsson: What's your distribution and version? |
| 20:14.27 | mickecarlsson | Centos 6.0, x64 |
| 20:14.40 | mickecarlsson | Linux localhost.localdomain 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux |
| 20:15.15 | mickecarlsson | https://issues.asterisk.org/jira/browse/ASTERISK-18399 |
| 20:23.34 | mickecarlsson | Corydon76-home: bedtime in Sweden, if you need more from me just ping me or update the ticket. Good night |
| 20:23.37 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 20:27.50 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:27.50 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 21:10.50 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 21:44.07 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mqvwyqutqtrpfhun) |