[test-results] [Bamboo] Asterisk - 1.8 > Mac OS X Snow Leopard (10.6) > #259 has FAILED. Change made by Terry Wilson and rmudgett.
Bamboo
bamboo at asterisk.org
Wed Aug 17 12:59:09 CDT 2011
-----------------------------------------------------------------------
Asterisk - 1.8 > Mac OS X Snow Leopard (10.6) > #259 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST18-LUCID-660.
No failed tests found, a possible compilation error.
http://bamboo.asterisk.org/browse/AST18-SNOWLEOPARD-259/
--------------
Failing Jobs
--------------
- x86_64 (Default Stage): No tests found.
--------------
Code Changes
--------------
rmudgett (332264):
>Outgoing BRI calls fail when using Asterisk 1.8 with HA8, HB8, and B410P cards.
>
>France Telecom brings layer 2 and layer 1 down on BRI lines when the line
>is idle. When layer 1 goes down Asterisk cannot make outgoing calls and
>the HA8 and HB8 cards also get IRQ misses.
>
>The inability to make outgoing calls is because the line is in red alarm
>and Asterisk will not make calls over a line it considers unavailable.
>The IRQ misses for the HA8 and HB8 card are because the hardware is
>switching clock sources from the line which just brought layer 1 down to
>internal timing.
>
>There is a DAHDI option for the B410P card to not tell Asterisk that layer
>1 went down so Asterisk will allow outgoing calls: "modprobe wcb4xxp
>teignored=1". There is a similar DAHDI option for the HA8 and HB8 cards:
>"modprobe wctdm24xxp bri_teignored=1". Unfortunately that will not clear
>up the IRQ misses when the telco brings layer 1 down.
>
>* Add layer 2 persistence option to customize the layer 2 behavior on BRI
>PTMP lines. The new option has three settings: 1) Use libpri default
>layer 2 setting. 2) Keep layer 2 up. Bring layer 2 back up when the peer
>brings it down. 3) Leave layer 2 down when the peer brings it down.
>Layer 2 will be brought up as needed for outgoing calls.
>
>JIRA AST-598
>
Terry Wilson (332320):
>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-1842, ASTERISK-18197, ASTERISK-18166, AST-486
>AST-495, AST-507 and possibly others.
>
--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20110817/da60ca76/attachment-0001.htm>
More information about the Test-results
mailing list