25 Commits (master)

Author	SHA1	Message	Date
Walter Doekes	3fab8212e3	res_timing: Don't close FD 0 when out of open files. ... This fixes so a failure to get a timer file descriptor does not cascade to closing FD 0. On error, both res_timing_kqueue and res_timing_timerfd would call the destructor before setting the file handle. The file handle had been initialized to 0, causing FD 0 to be closed. This in turn, resulted in floods of "CLI>" messages and an unusable terminal. ASTERISK-19277 #close Reported by: Barry Chern For the master branch, this was already fixed. This patch only ensures that we do not attempt to close a negative file descriptor. Change-Id: I147d7e33726c6e5a2751928d56561494f5800350	10 years ago
Rodrigo Ramírez Norambuena	eec010829a	AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro. ... Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723	10 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	e8e2f91bba	timing: Improve performance for most timing implementations. ... This change allows timing implementation data to be stored directly on the timer itself thus removing the requirement for many implementations to do a container lookup for the same information. This means that API calls into timing implementations can directly access the information they need instead of having to find it. Review: https://reviewboard.asterisk.org/r/3175/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407749 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	a0c363e227	Refactor ast_timer_ack to return an error and handle the error in timer users ... Currently, if an acknowledgement of a timer fails Asterisk will not realize that a serious error occurred and will continue attempting to use the timer's file descriptor. This can lead to situations where errors stream to the CLI/log file. This consumes significant resources, masks the actual problem that occurred (whatever caused the timer to fail in the first place), and can leave channels in odd states. This patch propagates the errors in the timing resource modules up through the timer core, and makes users of these timers handle acknowledgement failures. It also adds some defensive coding around the use of timers to prevent using bad file descriptors in off nominal code paths. Note that the patch created by the issue reporter was modified slightly for this commit and backported to 1.8, as it was originally written for Asterisk 10. Review: https://reviewboard.asterisk.org/r/2178/ (issue ASTERISK-20032) Reported by: Jeremiah Gowdy patches: jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358) ........ Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 375895 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	d9651f2be9	Fix timing source dependency issues with MOH ... Prior to this patch, res_musiconhold existed at the same module priority level as the timing sources that it depends on. This would cause a problem when music on hold was reloaded, as the timing source could be changed after res_musiconhold was processed. This patch adds a new module priority level, AST_MODPRI_TIMING, that the various timing modules are now loaded at. This now occurs before loading other resource modules, such that the timing source is guaranteed to be set prior to resolving the timing source dependencies. (closes issue ASTERISK-17474) Reporter: Luke H Tested by: Luke H, Vladimir Mikhelson, zzsurf, Wes Van Tlghem, elguero, Thomas Arimont Patches: asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-1.8.diff uploaded by elguero (License #5026) asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-10.diff uploaded by elguero (License #5026) asterisk-17474-dahdi_timing-infinite-wait-fix_v3.diff uploaded by elguero (License #5026) Review: https://reviewboard.asterisk.org/r/1578/ ........ Merged revisions 349194 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 349195 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Terry Wilson	c38cb95863	Merged revisions 332321 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/10 ................ r332321 | twilson | 2011-08-17 13:09:49 -0500 (Wed, 17 Aug 2011) | 17 lines Merged revisions 332320 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r332320 | twilson | 2011-08-17 12:35:27 -0500 (Wed, 17 Aug 2011) | 10 lines Don't read from a disarmed or invalid timerfd Numerous isues have been reported for deadlocks that are caused by a blocking read in res_timing_timerfd on a file descriptor that will never be written to. This patch adds some checks to make sure that the timerfd is both valid and armed before calling read(). Should fix: ASTERISK-18142, ASTERISK-18166, ASTERISK-18197, AST-486, AST-495, AST-507 and possibly others. Review: https://reviewboard.asterisk.org/r/1361/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@332337 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Leif Madsen	a525edea59	Merged revisions 328247 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.10 ................ r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines Merged revisions 328209 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines Introduce <support_level> tags in MODULEINFO. This change introduces MODULEINFO into many modules in Asterisk in order to show the community support level for those modules. This is used by changes committed to menuselect by Russell Bryant recently (r917 in menuselect). More information about the support level types and what they mean is available on the wiki at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328259 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	6e62aa2c7d	Merged revisions 326484 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r326484 | dvossel | 2011-07-06 10:26:49 -0500 (Wed, 06 Jul 2011) | 10 lines Reverts fix for timerfd locking issue. jrose discovered a performance issue with this fix that prevents his analog phones from working when using timerfd as a timing source. Until it is understood what is causing this performance problem, this patch is being reverted. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326485 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	317c631ac1	Merged revisions 325673 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r325673 | dvossel | 2011-06-29 13:59:33 -0500 (Wed, 29 Jun 2011) | 6 lines Fixes timerfd locking issue. (closes ASTERISK-17867, ASTERISK-17415) Patches: fix uploaded by kobaz Review: https://reviewboard.asterisk.org/r/1255/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@325674 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Paul Belanger	9d6cbe222c	Merged revisions 302462 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r302462 | pabelanger | 2011-01-19 12:09:35 -0500 (Wed, 19 Jan 2011) | 9 lines Merged revisions 302461 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r302461 | pabelanger | 2011-01-19 12:08:01 -0500 (Wed, 19 Jan 2011) | 2 lines Handle 'Resource temporarily unavailable' error more gracefully. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302463 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Jeff Peeler	9a257b9f97	Merged revisions 294313 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r294313 | jpeeler | 2010-11-08 16:32:13 -0600 (Mon, 08 Nov 2010) | 9 lines Merged revisions 294312 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294312 | jpeeler | 2010-11-08 16:30:49 -0600 (Mon, 08 Nov 2010) | 1 line add missing unlock not present in 294277 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294314 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	12a40275f2	Merged revisions 294278 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines Merged revisions 294277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines Fix playback failure when using IAX with the timerfd module. To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue #18110) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294279 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	b4e18d5660	Add load priority order, such that preload becomes unnecessary in most cases ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Sean Bright	a60935478b	Clarify error message in res_timing_timerfd. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@240505 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Sean Bright	cd2ba30e9e	If we aren't running on a machine that support CLOCK_MONOTONIC, don't load. ... Group developed and tested by seanbright, Corydon76, Kobaz, and Amorsen. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@240226 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	d532cbcd8a	module load priority ... This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty. (closes issue #15191) Reported by: alecdavis Tested by: dvossel Review: https://reviewboard.asterisk.org/r/262/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199743 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	174697b7d1	Fix some timer state corruption. ... In res_timer_timerfd, handle the case that set_rate gets called while a timer is still in continuous mode. In this case, we want to remember the configured rate, but not actually set it until continuous mode has been disabled. Thanks to dvossel for finding and helping to debug the problem. (closes issue #15080) Reported by: dvossel Tested by: dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193718 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	d6652e9760	Fix a reference leak in timerfd_set_rate(). ... (found during a debugging session with dvossel and mmichelson.) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179465 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	c461d29b0b	Update the timing API to have better support for multiple timing interfaces. ... 1) Add module use count handling so that timing modules can be unloaded. 2) Implement unload_module() functions for the timing interface modules. 3) Allow multiple timing modules to be loaded, and use the one with the highest priority value. 4) Report which timing module is being use in the "timing test" CLI command. (closes issue #14489) Reported by: russell Review: http://reviewboard.digium.com/r/162/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	e2f49af37f	Fix a logic error that occur when using the timerfd interface ... This sequence of events posed a problem timerfd_timer_open timerfd_timer_enable_continuous timerfd_timer_set_rate timerfd_timer_disable_continuous The reason was that the timing module was written under the assumption that timerfd_timer_set_rate would not be called between enabling and disabling continuous mode. What happened in this situation was that timerfd_timer_enable_continuous saved off our previously set timer (in this situation a 0 timer, meaning it never runs out). Then timerfd_timer_disable_continuous would restore this 0 timer, even though it logically should set the timer to be whatever was set in timerfd_timer_set_rate. Now the behavior in timerfd_timer_set_rate is to overwrite the saved timer that may or may not have been set in timerfd_timer_enable_continuous. Even if timerfd_timer_enable_continuous has not been previously called, this will not harm the operation. Thanks to Terry Wilson for discovering the problem and giving me a really great debug capture that pointed out the problem clearly git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168898 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	fd8caa1778	This is basically a complete rollback of r155401, as it was determined that ... it would be best to maintain API compatibility. Instead, this commit introduces ao2_callback_data() which is functionally identical to ao2_callback() except that it allows you to pass arbitrary data to the callback. Reviewed by Mark Michelson via ReviewBoard: http://reviewboard.digium.com/r/64 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158959 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	ebe533b83b	Fix compiling ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157973 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	da33129373	Cast this value since a uint64_t is not the same ... as an unsigned long long on a 64-bit machine. Reported by kpfleming on IRC git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157874 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	0e5367f7eb	Merge the changes from the res_timing_timerfd branch. ... This provides a new timing interface. In order to use it, you must be running a Linux with a kernel version of 2.6.25 or newer and glibc 2.8 or newer. This timing interface is a good alternative if a timing source is necessary (e.g. for IAX trunking) but DAHDI is otherwise unnecessary for the system. For now, this commit contains the actual work done in the res_timing_timerfd branch. There are no notices in the README or CHANGES files yet, but they will be added in my next commit. The timing API of Asterisk also needs to have a bit of work done with regards to choosing which timing interface to use. This commit makes the choice a build-time decision, by only allowing one of the timer interfaces to be chosen in menuselect. It would be preferable if the choice could be made at run-time, however. The preferred timing interface could be loaded and tested, and if it does not work, choice number two may be used instead. That sort of thing. That is beyond the scope of work in this branch though. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157820 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago