[asterisk-dev] help about 4E card design

Wed Mar 24 21:38:38 CDT 2010

Hello,
I am designing TE410P card. Now zap show status is OK, channel is OK, TS0 is
ok. I can capture it in driver like below.
[   81.563456] channel 1 sample readchunk 0 1B1B9B1B
[   81.563460] channel 1 sample readchunk 1 FFFFFFFF
[   81.564453] channel 1 sample readchunk 0 9B9B9B9B .
But when I enter into asterisk CLI, have alarm like below.

 [Mar 24 22:22:14] NOTICE[4661]: chan_dahdi.c:8703 pri_dchannel: PRI got
event: HDLC Abort (6) on Primary D-channel of span 4
 [Mar 24 22:22:14] NOTICE[4660]: chan_dahdi.c:8703 pri_dchannel: PRI got
event: HDLC Abort (6) on Primary D-channel of span 3
 [Mar 24 22:22:14] NOTICE[4660]: chan_dahdi.c:8703 pri_dchannel: PRI got
event: HDLC Abort (6) on Primary D-channel of span 3 
[Mar 24 22:22:14] NOTICE[4658]: chan_dahdi.c:8703 pri_dchannel: PRI got
event: HDLC Abort (6) on Primary D-channel of span 1

I don't know how to do with it? Who can give me some ideas?

Best Wishes,

Henry Lee

ATCOM Technology Co., Limited 

District C , east of 2nd floor , #3 , Crown industry buildings , Chegongmiao
Industry area , Futian district , Shenzhen , China

Direct: +86 755 23487618 |Fax: +86 755 83018389 |Mobile: +86 13798410169
|Email: leexx at atcom.com.cn |MSN: leexx at hotmail.com

www.ATCOM.cn | www.openippbx.org

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
asterisk-dev-request at lists.digium.com
Sent: Thursday, March 25, 2010 5:06 AM
To: asterisk-dev at lists.digium.com
Subject: asterisk-dev Digest, Vol 68, Issue 87

Send asterisk-dev mailing list submissions to
	asterisk-dev at lists.digium.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
	asterisk-dev-request at lists.digium.com

You can reach the person managing the list at
	asterisk-dev-owner at lists.digium.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of asterisk-dev digest..."

Today's Topics:

   1. [Bamboo] Asterisk - trunk - Linux - x86_64 build 308 was
      SUCCESSFUL (with 34 tests). Change made by Sean Bright (Bamboo)
   2. [Code Review] menuselect: add an --enable-all and
      --disable-all command line flags (Sean Bright)
   3. Re: [Code Review] menuselect: add an --enable-all and
      --disable-all command line flags (Kevin Fleming)
   4. Re: [Code Review] Fix invalid reads in main/pbx.c (Kevin Fleming)
   5. Re: [Code Review] remove unneeded explicit specification of
      channel in dahdi ioctls (Kevin Fleming)
   6. Re: [Code Review] Fix invalid reads in main/pbx.c (Mark Michelson)

----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Mar 2010 15:39:43 -0500 (CDT)
From: Bamboo <bamboo at asterisk.org>
Subject: [asterisk-dev] [Bamboo] Asterisk - trunk - Linux - x86_64
	build 308 was SUCCESSFUL (with 34 tests). Change made by Sean Bright
To: asterisk-dev at lists.digium.com
Message-ID:
	<1916349399.31.1269463183756.JavaMail.root at bamboo.asterisk.org>
Content-Type: text/plain; charset="utf-8"

-------------- next part --------------
-----------------------------------------------------------
AST-TRUNK-308 was successful.
-----------------------------------------------------------
Code has been updated by Sean Bright.
34 tests in total.

http://bamboo.asterisk.org/browse/AST-TRUNK-308/        

--------------
Code Changes
--------------
Sean Bright (727):

>Revert part of r726 that wasn't supposed to go yet

--------------
Tests
--------------
Fixed Tests (1)
   - AsteriskTestSuite: Blind-transfer-accountcode 

--------------
Error Summary
--------------
   src/lfs.c: In function 'lfs_g_setmode':
   src/lfs.c:235: warning: unused parameter 'f'
   src/lfs.c:235: warning: unused parameter 'arg'

--
This message is automatically generated by Atlassian Bamboo

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-dev/attachments/20100324/e31c57f7
/attachment-0001.htm 

------------------------------

Message: 2
Date: Wed, 24 Mar 2010 20:42:52 -0000
From: "Sean Bright" <sean.bright at gmail.com>
Subject: [asterisk-dev] [Code Review] menuselect: add an --enable-all
	and --disable-all command line flags
To: "Russell Bryant" <russell at digium.com>
Cc: Asterisk Developers <asterisk-dev at lists.digium.com>
Message-ID: <20100324204252.23152.28706 at hotblack.digium.internal>
Content-Type: text/plain; charset="utf-8"

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/587/
-----------------------------------------------------------

Review request for Asterisk Developers and Russell Bryant.

Summary
-------

Similar to the flags added by russellb, this adds --enable-all and
--disable-all to menuselect to either enable all available options or
disable them all.

Diffs
-----

  /trunk/menuselect.c 727 

Diff: https://reviewboard.asterisk.org/r/587/diff

Testing
-------

Ran `menuselect --enable-all menuselect.makeopts` and `menuselect
--disable-all menuselect.makeopts` followed by 'menuselect
menuselect.makeopts' to verify it enabled and disabled everything.

Screenshots
-----------

menuselect
  https://reviewboard.asterisk.org/r/587/s/2/

Thanks,

Sean

------------------------------

Message: 3
Date: Wed, 24 Mar 2010 20:55:06 -0000
From: "Kevin Fleming" <kpfleming at digium.com>
Subject: Re: [asterisk-dev] [Code Review] menuselect: add an
	--enable-all and --disable-all command line flags
To: "Russell Bryant" <russell at digium.com>
Cc: Kevin Fleming <kpfleming at digium.com>,	Asterisk Developers
	<asterisk-dev at lists.digium.com>
Message-ID: <20100324205506.23315.83490 at hotblack.digium.internal>
Content-Type: text/plain; charset="utf-8"

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/587/#review1742
-----------------------------------------------------------

Ship it!

Sneaky use of '^'.

- Kevin

On 2010-03-24 15:42:52, Sean Bright wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/587/
> -----------------------------------------------------------
> 
> (Updated 2010-03-24 15:42:52)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> Similar to the flags added by russellb, this adds --enable-all and
--disable-all to menuselect to either enable all available options or
disable them all.
> 
> 
> Diffs
> -----
> 
>   /trunk/menuselect.c 727 
> 
> Diff: https://reviewboard.asterisk.org/r/587/diff
> 
> 
> Testing
> -------
> 
> Ran `menuselect --enable-all menuselect.makeopts` and `menuselect
--disable-all menuselect.makeopts` followed by 'menuselect
menuselect.makeopts' to verify it enabled and disabled everything.
> 
> 
> Screenshots
> -----------
> 
> menuselect
>   https://reviewboard.asterisk.org/r/587/s/2/
> 
> 
> Thanks,
> 
> Sean
> 
>

------------------------------

Message: 4
Date: Wed, 24 Mar 2010 20:58:23 -0000
From: "Kevin Fleming" <kpfleming at digium.com>
Subject: Re: [asterisk-dev] [Code Review] Fix invalid reads in
	main/pbx.c
To: "Kevin Fleming" <kpfleming at digium.com>,	"Asterisk Developers"
	<asterisk-dev at lists.digium.com>,	"Mark Michelson"
	<mmichelson at digium.com>
Message-ID: <20100324205823.23802.42800 at hotblack.digium.internal>
Content-Type: text/plain; charset="utf-8"

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/585/#review1743
-----------------------------------------------------------

Ship it!

The pbx.c changes look fine to me. The dialplan functions changes look
irrelevant, so I'd prefer you didn't include them in the commit :-)

- Kevin

On 2010-03-24 15:11:23, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/585/
> -----------------------------------------------------------
> 
> (Updated 2010-03-24 15:11:23)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This past weekend, Russell ran our current suite of unit tests for
Asterisk under valgrind. The PBX pattern match test caused valgrind to spew
forth two invalid read errors. This patch contains two changes that shut
valgrind up and do not cause any new memory leaks.
> 
> Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one
of the the strcmp calls in the loop control was reading invalid memory. This
was because the caller of ast_context_remove_extension_callerid2
(__ast_context destroy in this case) passed as a parameter a shallow copy of
an ast_exten's exten field. This same ast_exten was what was destroyed
inside the for loop, thus any iterations of the for loop beyond the
destruction of the ast_exten would result in invalid reads. My fix for this
is to make a copy of the ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.
> 
> Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the
hashtab over which we were iterating was an ast_exten's peer_table. Inside
of ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit
less straightforward. With each iteration over the hashtab's contents, we
set a variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and
instead call ast_free on the hashtab iterator.
> 
> I could use some opinions to determine if my approaches to both fixes are
ideal or could be improved. Thanks!
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/sip/dialplan_functions.c 254276 
>   /trunk/main/pbx.c 254276 
> 
> Diff: https://reviewboard.asterisk.org/r/585/diff
> 
> 
> Testing
> -------
> 
> I have rerun the pattern match test under valgrind to ensure that no
invalid memory access occurs. In addition, I also used the "memory show
summary" command after running the test to ensure that running the test
causes no memory leaks to occur in test_pbx.c and pbx.c
> 
> 
> Thanks,
> 
> Mark
> 
>

------------------------------

Message: 5
Date: Wed, 24 Mar 2010 20:59:04 -0000
From: "Kevin Fleming" <kpfleming at digium.com>
Subject: Re: [asterisk-dev] [Code Review] remove unneeded explicit
	specification of channel in dahdi ioctls
To: "Kevin Fleming" <kpfleming at digium.com>,	"Asterisk Developers"
	<asterisk-dev at lists.digium.com>,	"Tzafrir Cohen"
	<tzafrir.cohen at xorcom.com>
Message-ID: <20100324205904.23963.96807 at hotblack.digium.internal>
Content-Type: text/plain; charset="utf-8"

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/584/#review1744
-----------------------------------------------------------

Ship it!

- Kevin

On 2010-03-24 14:14:55, Tzafrir Cohen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/584/
> -----------------------------------------------------------
> 
> (Updated 2010-03-24 14:14:55)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Several DAHDI ioctls allow passing the channel numbers explicitly through
one of the fields in the struct that is passed in the system call. This will
override the actual file descriptor used. In some cases this is really
needed. But in most cases it merely opens the door to unexpected bugs.
> 
> This patch removes a few such calls in Asterisk while not actually
changing the behavior. The gain setting functions passed around a channel
which is always 0, and thus this parameter is simply dropped.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_dahdi.c 254360 
> 
> Diff: https://reviewboard.asterisk.org/r/584/diff
> 
> 
> Testing
> -------
> 
> So far: minimal: Does not seem to break anything here.
> 
> 
> Thanks,
> 
> Tzafrir
> 
>

------------------------------

Message: 6
Date: Wed, 24 Mar 2010 21:05:41 -0000
From: "Mark Michelson" <mmichelson at digium.com>
Subject: Re: [asterisk-dev] [Code Review] Fix invalid reads in
	main/pbx.c
To: "Kevin Fleming" <kpfleming at digium.com>,	"Asterisk Developers"
	<asterisk-dev at lists.digium.com>,	"Mark Michelson"
	<mmichelson at digium.com>
Message-ID: <20100324210541.24220.52416 at hotblack.digium.internal>
Content-Type: text/plain; charset="utf-8"

> On 2010-03-24 15:58:23, Kevin Fleming wrote:
> > The pbx.c changes look fine to me. The dialplan functions changes look
irrelevant, so I'd prefer you didn't include them in the commit :-)

Ah yes, I shall not be committing that.

- Mark

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/585/#review1743
-----------------------------------------------------------

On 2010-03-24 15:11:23, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/585/
> -----------------------------------------------------------
> 
> (Updated 2010-03-24 15:11:23)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This past weekend, Russell ran our current suite of unit tests for
Asterisk under valgrind. The PBX pattern match test caused valgrind to spew
forth two invalid read errors. This patch contains two changes that shut
valgrind up and do not cause any new memory leaks.
> 
> Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one
of the the strcmp calls in the loop control was reading invalid memory. This
was because the caller of ast_context_remove_extension_callerid2
(__ast_context destroy in this case) passed as a parameter a shallow copy of
an ast_exten's exten field. This same ast_exten was what was destroyed
inside the for loop, thus any iterations of the for loop beyond the
destruction of the ast_exten would result in invalid reads. My fix for this
is to make a copy of the ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.
> 
> Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the
hashtab over which we were iterating was an ast_exten's peer_table. Inside
of ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit
less straightforward. With each iteration over the hashtab's contents, we
set a variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and
instead call ast_free on the hashtab iterator.
> 
> I could use some opinions to determine if my approaches to both fixes are
ideal or could be improved. Thanks!
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/sip/dialplan_functions.c 254276 
>   /trunk/main/pbx.c 254276 
> 
> Diff: https://reviewboard.asterisk.org/r/585/diff
> 
> 
> Testing
> -------
> 
> I have rerun the pattern match test under valgrind to ensure that no
invalid memory access occurs. In addition, I also used the "memory show
summary" command after running the test to ensure that running the test
causes no memory leaks to occur in test_pbx.c and pbx.c
> 
> 
> Thanks,
> 
> Mark
> 
>

------------------------------

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

End of asterisk-dev Digest, Vol 68, Issue 87
********************************************