| 02:16.48 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 02:16.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 04:44.59 | *** join/#asterisk-dev Guest87710 (~Freeaqing@2001:980:45b3:1:216:3eff:fe00:5) |
| 05:17.29 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 05:30.31 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:30.31 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 07:16.50 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:16.52 | schmidts | good morning |
| 08:10.50 | *** join/#asterisk-dev lftsy (~lftsy@212-147-16-108.fix.access.vtx.ch) |
| 08:29.13 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:42.12 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c43a:3510:fed4:ff0f) |
| 08:52.32 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 08:52.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 09:10.11 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.206.10) |
| 09:28.33 | *** join/#asterisk-dev frawd (~francois@3.Red-81-44-76.dynamicIP.rima-tde.net) |
| 10:45.05 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.206.10) |
| 11:49.32 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 12:08.59 | *** join/#asterisk-dev Shazaum (~1@unaffiliated/shazaum) |
| 12:10.37 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:10.37 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:06.11 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 14:18.33 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:18.33 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:40.36 | tzafrir_laptop | Is asterisk 1.4 still officially supported? |
| 14:41.00 | tzafrir_laptop | AST-2011-003 didn't even mention it |
| 14:41.51 | russellb | it is, yes |
| 14:41.54 | russellb | it wasn't affected |
| 14:41.59 | russellb | the advisiory should have said that, sorry. |
| 14:42.11 | tzafrir_laptop | why isn't it affected? |
| 14:42.21 | russellb | because it isn't? |
| 14:42.26 | russellb | I didn't work on the code |
| 14:42.37 | russellb | but I made sure that was checked, the code is very different |
| 14:47.11 | tzafrir_laptop | I actually don't understand the description. |
| 14:47.39 | tzafrir_laptop | The description of the commit that fixed it is " Don't keep trying to write to a closed connection" |
| 14:47.42 | russellb | I don't see Terry Wilson online, so I guess email the -dev list with any questions |
| 14:47.53 | tzafrir_laptop | But you actually loop reading from the connection, right? |
| 14:55.39 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:55.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:16.16 | *** join/#asterisk-dev marv (~timr@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 15:42.34 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:40.59 | Kobaz | wedhorn: i updated the skinny bug, it's thread 3 that crashed |
| 17:00.07 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:44.55 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:44.55 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:20.51 | *** join/#asterisk-dev alecdavis (~sivad@202-78-149-14.cable.telstraclear.net) |
| 19:24.35 | alecdavis | sruffell: wctdm24xxp_cmdlist, guess you seen my review, but have been tripped up, wait_access will wait until the indirect register has been updated, this happens at 16Khz rate, so the interuupt is going to pause for each indirect register I need to update..how do we now go about waiting in an interrupt |
| 19:25.17 | sruffell | I saw that you opened itâ¦and when I read the email I was not following. I haven't opened it up yet /me does so now.... |
| 19:31.33 | alecdavis | for the direct register updates, the wctdm_set_ring_generator_mode should be calling wctdm_setreg_intr, but wctdm_proslic_setreg_indirect doesn't yet have a version that can be called from within an interrupt. |
| 19:32.26 | alecdavis | ^^ as I understand it. |
| 19:33.13 | sruffell | yesâ¦.I seeâ¦.wait_access won't work in ISR context. |
| 19:33.59 | sruffell | but if you're just setting (and don't need the result of an indirect register returned) could the "_intr" version just queue that out the the system work queue? |
| 19:34.34 | sruffell | â¦and there never was an indirect register read that worked from ISR contextâ¦this is all new, right? |
| 19:34.55 | sruffell | as opposed to being a side effect of the switch to lists for the commands? |
| 19:36.53 | alecdavis | the way the datasheet reads for the 3215, for indirect updates, suggests the first byte 'indirect' IDA iirc, needs to be sent first. |
| 19:37.49 | sruffell | isn't it? IDA_LO, IDA_HI, then IAA? |
| 19:38.46 | sruffell | Looking on line 418 of wctdm24xxp/base.c: http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=blob;f=drivers/dahdi/wctdm24xxp/base.c;h=5f867c8a;hb=wctdm24xxp-cmdlist#l1418 |
| 19:39.34 | alecdavis | A |
| 19:39.34 | alecdavis | write to IDA followed by a write to IAA is interpreted as a write request to an indirect register. In this case, the |
| 19:39.34 | alecdavis | contents of IDA are written to indirect memory at the location referenced by IAA at the next indirect register update. |
| 19:39.42 | alecdavis | ^^ copy from data sheet |
| 19:40.32 | sruffell | and IDA is 16-bit right? So we wait for access, then write 16-bits to IDA, and then the 8-bit address to IAA. |
| 19:42.34 | alecdavis | you're right ;), but then why wait_access |
| 19:43.31 | sruffell | to synchronize access since those indirect operations aren't atomic... |
| 19:48.27 | alecdavis | in theory then, it should just work, given I ignore wait_access, and change to using an _intr version of wctdm_proslic_setreg_indirect and use the existing wctdm_setreg_intr |
| 19:48.52 | alecdavis | practice is always different! |
| 19:50.25 | sruffell | still looking... |
| 19:51.55 | sruffell | If I give you a patchâ¦are you able to test it right now? |
| 19:52.19 | sruffell | I have no way (that I know of) to test any of this.... |
| 19:54.07 | alecdavis | eating breakfast, but yes i a few minutes. |
| 19:54.21 | sruffell | ok..... |
| 19:54.55 | sruffell | btwâ¦how about those new driver load times? |
| 19:55.17 | alecdavis | much better. |
| 19:56.24 | alecdavis | but the lockups I saw, repeated messages to console, no way to reboot, power off :(. fsck, 20 minutes... |
| 19:56.53 | alecdavis | all due to my stuff, not your. |
| 19:57.26 | sruffell | heh |
| 19:59.06 | alecdavis | atomic messages, flying by so fast. probly cause i havn't fixed my code. |
| 19:59.45 | kpfleming | alecdavis: were there any effects from the tsunami in Kiwiland? |
| 20:03.48 | alecdavis | kpfleming: no, but it was a heads up, as to what disater recvoery proceedures we have in place, from many aspects. |
| 20:03.58 | kpfleming | sure |
| 20:04.13 | kpfleming | the wave was probably pretty small when it got there, like it was on our west coast |
| 20:04.19 | kpfleming | still enough to cause some damage, though |
| 20:05.25 | alecdavis | from what I heard, at the north there was a small wave. |
| 20:09.24 | sruffell | alecdavis: What I "would like" to do is move the complete "isr_misc" out of the interrupt handlerâ¦.why I haven't done that yet is I'm not sure if it's safe to slow down the rate at which that runsâ¦. |
| 20:09.36 | sruffell | do you have any thoughts about that? |
| 20:10.21 | sruffell | i.eâ¦would that processing be safe to run at 100ms intervals? Would we potentially miss a ring or anything like that? |
| 20:10.45 | sruffell | but otherwiseâ¦I'll keep making a patch that just allows indirect writes from ISR context. |
| 20:13.53 | alecdavis | I don't need 1ms resolution, which we have right now. It seems like overkill, but no sure what might be missed. |
| 20:15.35 | alecdavis | I'm of the opinion, that doing LineFeed operations instantly is a waste of time, where within 100ms doesn't seem unreasonable. |
| 20:17.45 | alecdavis | ^^ instantly = 1ms |
| 20:27.26 | alecdavis | sruffell: which direction? I've just done the _intr changes that I hadn't done last night, and now I have a system that doesn't seize. |
| 20:28.05 | alecdavis | but does it light a neon phone? don't know yet. |
| 20:28.41 | sruffell | alecdavis: hmmâ¦and actually, I just walked back to my desk to let you know that I'm servicing an interruptâ¦so it'll be 15-30 mins here for me. |
| 20:29.51 | alecdavis | NMI for me too. |
| 20:44.24 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 20:47.36 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:10.10 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 22:48.17 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@pool-71-111-114-150.ptldor.dsl-w.verizon.net) |
| 23:05.12 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@pool-71-111-114-150.ptldor.dsl-w.verizon.net) |
| 23:25.59 | alecdavis | sruffell: it's working - lights neon bulb when messages are present:) |
| 23:32.40 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@pool-71-111-114-150.ptldor.dsl-w.verizon.net) |
| 23:55.15 | sruffell | alecdavis: \o/ so what change did you make? |
| 23:55.56 | sruffell | umm..as I catch up with my information sources, I see you've updated the review. |