Tony Mountifield
2018-Apr-03 21:38 UTC
[asterisk-users] Strange problem with PRI on 64-bit?
In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg at mail.gmail.com>, Matt Fredrickson <creslin at digium.com> wrote:> On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield <tony at softins.co.uk> wrote: > > I have some more investigation to do on this, but I wanted to see if anyone > > here had any insight into the issue I've run into. > > > > The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one > > of several systems that have been running without issue since 2010/2011. They > > have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen > > 5 card), libpri 1.2.8 and asterisk 1.2.32. > > > > Having taken this particular system out of production, I updated it to CentOS > > 6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version > > of Asterisk is required at the moment due to custom modifications). > > This appears to work fine. > > > > In order to reduce the number of different versions we support, I reinstalled > > the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using > > the same versions as above. > > > > However, for reasons I don't understand, the 64-bit version was logging > > frequent PRI errors every few minutes: > > > > [Apr 1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > [Apr 1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > [Apr 1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > [Apr 1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > [Apr 1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > [Apr 1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) > > > > This left the PRIs in strange states - trying to make a call failed with cause 101. > > > > So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs > > were no longer present, and the system operated normally again. > > > > So my question is: does anyone have any clues why there would be a difference > > in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into > > anything similar? > > > That does seem quite odd. If I remember right, those messages would > come up if it looked like the other end hadn't received a message when > it thought it should have. I can't think of anything that would > particularly impact 64 bit systems versus 32 bit systems in that > domain (ISDN real time message timing, etc). Are you sure there's > nothing else different (kernel version or something else like that)? > Maybe also run a patlooptest on the spans in question to make sure > that they're running cleanly.Hi Matt, thanks for the reply. Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9 from online repositories using a kickstart build. I'm going to try installing the 64-bit version again tomorrow to see if the problem re-appears, just to be certain it wasn't anything transient. I don't think there is anything unclean about the spans, because they were running fine on CentOS 4 with the versions I mentioned, and are now running well again with 32-bit CentOS 6. Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - softins.co.uk Play: tony at mountifield.org - tony.mountifield.org
Matt Fredrickson
2018-Apr-03 21:57 UTC
[asterisk-users] Strange problem with PRI on 64-bit?
On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield <tony at softins.co.uk> wrote:> In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg at mail.gmail.com>, > Matt Fredrickson <creslin at digium.com> wrote: >> On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield <tony at softins.co.uk> wrote: >> > I have some more investigation to do on this, but I wanted to see if anyone >> > here had any insight into the issue I've run into. >> > >> > The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one >> > of several systems that have been running without issue since 2010/2011. They >> > have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen >> > 5 card), libpri 1.2.8 and asterisk 1.2.32. >> > >> > Having taken this particular system out of production, I updated it to CentOS >> > 6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version >> > of Asterisk is required at the moment due to custom modifications). >> > This appears to work fine. >> > >> > In order to reduce the number of different versions we support, I reinstalled >> > the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using >> > the same versions as above. >> > >> > However, for reasons I don't understand, the 64-bit version was logging >> > frequent PRI errors every few minutes: >> > >> > [Apr 1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > [Apr 1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > [Apr 1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > [Apr 1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > [Apr 1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > [Apr 1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame established) >> > >> > This left the PRIs in strange states - trying to make a call failed with cause 101. >> > >> > So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs >> > were no longer present, and the system operated normally again. >> > >> > So my question is: does anyone have any clues why there would be a difference >> > in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into >> > anything similar? >> >> >> That does seem quite odd. If I remember right, those messages would >> come up if it looked like the other end hadn't received a message when >> it thought it should have. I can't think of anything that would >> particularly impact 64 bit systems versus 32 bit systems in that >> domain (ISDN real time message timing, etc). Are you sure there's >> nothing else different (kernel version or something else like that)? >> Maybe also run a patlooptest on the spans in question to make sure >> that they're running cleanly. > > Hi Matt, thanks for the reply. > > Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9 from > online repositories using a kickstart build. I'm going to try installing the > 64-bit version again tomorrow to see if the problem re-appears, just to be > certain it wasn't anything transient. I don't think there is anything unclean > about the spans, because they were running fine on CentOS 4 with the versions > I mentioned, and are now running well again with 32-bit CentOS 6.Hey Tony, The paylooptest recommendation wasn't necessarily about screening hardware problems but weeding out that there weren't any potential driver issues on the 64bit install. -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Richard Mudgett
2018-Apr-03 22:30 UTC
[asterisk-users] Strange problem with PRI on 64-bit?
On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson <creslin at digium.com> wrote:> On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield <tony at softins.co.uk> > wrote: > > In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg@ > mail.gmail.com>, > > Matt Fredrickson <creslin at digium.com> wrote: > >> On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield <tony at softins.co.uk> > wrote: > >> > I have some more investigation to do on this, but I wanted to see if > anyone > >> > here had any insight into the issue I've run into. > >> > > >> > The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. > It is one > >> > of several systems that have been running without issue since > 2010/2011. They > >> > have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with > patch for gen > >> > 5 card), libpri 1.2.8 and asterisk 1.2.32. > >> > > >> > Having taken this particular system out of production, I updated it > to CentOS > >> > 6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 > (this version > >> > of Asterisk is required at the moment due to custom modifications). > >> > This appears to work fine. > >> > > >> > In order to reduce the number of different versions we support, I > reinstalled > >> > the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, > using > >> > the same versions as above. > >> > > >> > However, for reasons I don't understand, the 64-bit version was > logging > >> > frequent PRI errors every few minutes: > >> > > >> > [Apr 1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > [Apr 1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > [Apr 1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > [Apr 1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > [Apr 1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > [Apr 1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 > MDL-ERROR (A): Got supervisory frame with F=1 in state 7(Multi-frame > established) > >> > > >> > This left the PRIs in strange states - trying to make a call failed > with cause 101. > >> > > >> > So I re-installed the 32-bit OS again, and rebuilt, and the above > MDL-ERRORs > >> > were no longer present, and the system operated normally again. > >> > > >> > So my question is: does anyone have any clues why there would be a > difference > >> > in PRI behaviour between 32-bit and 64-bit builds? Has anyone else > run into > >> > anything similar? > >> > >> > >> That does seem quite odd. If I remember right, those messages would > >> come up if it looked like the other end hadn't received a message when > >> it thought it should have. I can't think of anything that would > >> particularly impact 64 bit systems versus 32 bit systems in that > >> domain (ISDN real time message timing, etc). Are you sure there's > >> nothing else different (kernel version or something else like that)? > >> Maybe also run a patlooptest on the spans in question to make sure > >> that they're running cleanly. > > > > Hi Matt, thanks for the reply. > > > > Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9 > from > > online repositories using a kickstart build. I'm going to try installing > the > > 64-bit version again tomorrow to see if the problem re-appears, just to > be > > certain it wasn't anything transient. I don't think there is anything > unclean > > about the spans, because they were running fine on CentOS 4 with the > versions > > I mentioned, and are now running well again with 32-bit CentOS 6. >The libpri makefile doesn't install things for 64 bit systems in the right place [1] without your help. You'll need to specify where to install the library on the command line for your system: sudo make install libdir=/usr/lib64 Richard [1] issues.asterisk.org/jira/browse/PRI-100 -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.digium.com/pipermail/asterisk-users/attachments/20180403/7faff3c9/attachment.html>
Tony Mountifield
2018-Apr-04 11:18 UTC
[asterisk-users] Strange problem with PRI on 64-bit?
In article <CAHZ_z=wt3SAQnDOy26umPeC9=UNS8zg_WOofMnGuD=yntAmHPg at mail.gmail.com>, Matt Fredrickson <creslin at digium.com> wrote:> On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield <tony at softins.co.uk> wrote: > > In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg at mail.gmail.com>, > > Matt Fredrickson <creslin at digium.com> wrote: > >> That does seem quite odd. If I remember right, those messages would > >> come up if it looked like the other end hadn't received a message when > >> it thought it should have. I can't think of anything that would > >> particularly impact 64 bit systems versus 32 bit systems in that > >> domain (ISDN real time message timing, etc). Are you sure there's > >> nothing else different (kernel version or something else like that)? > >> Maybe also run a patlooptest on the spans in question to make sure > >> that they're running cleanly. > > > > Hi Matt, thanks for the reply. > > > > Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9 from > > online repositories using a kickstart build. I'm going to try installing the > > 64-bit version again tomorrow to see if the problem re-appears, just to be > > certain it wasn't anything transient. I don't think there is anything unclean > > about the spans, because they were running fine on CentOS 4 with the versions > > I mentioned, and are now running well again with 32-bit CentOS 6. > > Hey Tony, > > The paylooptest recommendation wasn't necessarily about screening > hardware problems but weeding out that there weren't any potential > driver issues on the 64bit install.Ok, sure. I assumed that DAHDI would have had a lot of use on 64-bit by now, especially since RHEL 7 is 64-bit only (although I believe CentOS 7 has been made available also in 32-bit). I've just done a 64-bit rebuild again, so will do some tests. Thanks Tony -- Tony Mountifield Work: tony at softins.co.uk - softins.co.uk Play: tony at mountifield.org - tony.mountifield.org