[asterisk-users] Connecting a Rolm CBX to Asterisk via T1?
Joshua Kinard
jkinard at closeup.org
Tue Feb 19 16:22:56 CST 2008
Okay, some more interesting tidbits to throw out incase someone has run into this before.
I've found out that th D100P has been EOL'ed by Digium due to it being a bit weird with certain systems, and I suspect my HP Proliant DL385 server may be one of those. Anyone used this card on such a system, running Suse (or at minimum, kernel 2.6.16.5x), and seen either PCI Master Aborts or NMI Errors being fired around in dmesg?
I moved the the D110P card out of what was a 100MHz PCI Slot and into a 133MHz PCI slot. The PCI Master Aborts vanish, but get replaced by this:
Do you have a strange power saving mode enabled?
Uhhuh. NMI received for unknown reason 00 on CPU 1.
Uhhuh. NMI received for unknown reason 21 on CPU 0.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Ad infinium.
The interesting part of all of this? The whole T1-PRI Bridge setup works now. I dial my test extension, and a fax modem comes screaming back at me a few seconds later. That timing oddity with my Rolm system vanished with moving this to the PCI 133MHz slot I guess. The downside is my server locked up a few times until I passed a couple of options given to me by Digium's tech support.
I'm going to go run some hardware diagnostics on the server itself to make sure it's not going all emo on me or something, and then see what Digium can maybe help with. But I thought I'd see if anyone's had similar or other odd cases on DL385 hardware.
Cheers!,
--jkinard
-----Original Message-----
Okay, so I've been toying around on the Rolm side, and still getting nothing. Took another look on Asterisk, finally figured out where the debugging could be enabled on the console, and finding a lot of interesting things.
Running 'dmesg' simply shows the entire buffer is flooded with 'PCI Master Aborts', and they appear as soon as the zaptel driver tries to do anything in conjunction with asterisk. Further more, there seems to be a problem with chan_zap and the my_zt_write function, in that it gets a -1 return code, "Resource temporarily unavailable" (which comprised the bulk of the asterisk debugging output).
I've attached a snipped version of that output, notably removing about 2000 lines of chan_zap repeating the "Resource temporarily unavailable" error. Do I need to look at downgrading asterisk and zaptel to 1.2.x, or might this be some conflict with the Proliant DL385 hardware that currently hosts the T1 Card?
FYI, asterisk-1.4.18 and zaptel-1.4.8.
More information about the asterisk-users
mailing list