Hi there, I'm having some fairly serious asterisk problems, which seem to be spread quite liberally across all asterisk versions, I've tried 1.4.2, 1.6.0.10, 1.6.2beta4 and still had exactly the same problem with static and echo on the line when using the PRI interface. A little background: Server: HP DL145 G3 Dual Opteron 246 with 2GB ram and a brand new OpenVox D110P http://www.voipon.co.uk/openvox-d110p-pci-isdn-pri-card-p-658.html Dual 250GB SATA disks in Software Raid 1 Running Ubuntu 9.04 Jaunty, but I had the same problems on Intrepid and Hardy. Versions: Asterisk: 1.4.2, 1.6.0.10, 1.6.2beta4 libpri: 1.4.10 dahdi: 2.2.0-current Asterisk works fine for SIP calls, as long as they don't touch the outside world via the PRI card. This pastebin contains the console log from asterisk -vvvvvvvvvvvvvvvvvvvvvcg http://pastebin.com/f780c591e There are lots of chan_dahdi errors. Occasionally, it claims to run out of channels and terminates the active calls. This is the contents of /etc/dahdi/system.conf http://pastebin.com/f1f654235 This is the contents of /etc/asterisk/chan_dahdi.conf http://pastebin.com/f7ef35e72 This is /proc/interrupts http://pastebin.com/f61cd8398 This is lsmod http://pastebin.com/m56105bf5 I've tried stuff like binding the processor affinity of the modules to one or the other processor, I've tried changing the slot the card is in. I asked similar questions on #asterisk, and tried their suggestions. Nothing seems to work. Any help would be graciously recieved. I'm pretty much all out of ideas. Tom -- Tom O'Connor http://www.twinhelix.org tom at twinhelix.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090630/e5dc27b8/attachment.htm
Hi, I'm aware you didn't get a response. But please only post once, or at least leave a day or two. Is the PRI a known-good? i.e. tested with other stuff and error free? Steve On 30 Jun 2009, at 11:45, Tom O'Connor wrote:> > Hi there, > > I'm having some fairly serious asterisk problems, which seem to be > spread quite liberally across all asterisk versions, I've tried > 1.4.2, 1.6.0.10, 1.6.2beta4 and still had exactly the same problem > with static and echo on the line when using the PRI interface. > > A little background: > Server: HP DL145 G3 Dual Opteron 246 with 2GB ram and a brand new > OpenVox D110P http://www.voipon.co.uk/openvox-d110p-pci-isdn-pri-card-p-658.html > Dual 250GB SATA disks in Software Raid 1 > Running Ubuntu 9.04 Jaunty, but I had the same problems on Intrepid > and Hardy. > > Versions: > Asterisk: 1.4.2, 1.6.0.10, 1.6.2beta4 > libpri: 1.4.10 > dahdi: 2.2.0-current > > > Asterisk works fine for SIP calls, as long as they don't touch the > outside world via the PRI card. > > This pastebin contains the console log from asterisk - > vvvvvvvvvvvvvvvvvvvvvcg > http://pastebin.com/f780c591e > > There are lots of chan_dahdi errors. Occasionally, it claims to run > out of channels and terminates the active calls. > > This is the contents of /etc/dahdi/system.conf > http://pastebin.com/f1f654235 > > This is the contents of /etc/asterisk/chan_dahdi.conf > http://pastebin.com/f7ef35e72 > > This is /proc/interrupts > http://pastebin.com/f61cd8398 > > This is lsmod > http://pastebin.com/m56105bf5 > > I've tried stuff like binding the processor affinity of the modules > to one or the other processor, I've tried changing the slot the card > is in. > I asked similar questions on #asterisk, and tried their suggestions. > > Nothing seems to work. > > Any help would be graciously recieved. I'm pretty much all out of > ideas. > > Tom > > > -- > Tom O'Connor > > http://www.twinhelix.org > tom at twinhelix.org > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
On Tue, Jun 30, 2009 at 6:45 AM, Tom O'Connor<tom.bioinf at gmail.com> wrote:> I'm having some fairly serious asterisk problems, which seem to be spread > quite liberally across all asterisk versions, I've tried 1.4.2, 1.6.0.10, > 1.6.2beta4 and still had exactly the same problem with static and echo on > the line when using the PRI interface.In my experience, static and echo can be related to bad cables or bad physical telco wiring. This would explain why the problem affected every asterisk version you tried. Do you have any other gear you can terminate the PRI into for a comparison test? I would suspect a bad PRI.
> Could someone tell me how to set which IRQ the ISDN card picks up?It's a multi-stage process. Each PCI slot has four interrupt pins: INTA through INTD. A PCI card can choose to use any of these four (or even more than one of them, as some multi-port serial cards do). Most PCI cards use only one pin: usually INTA. The motherboard routes four interrupt lines between the pins in the slots it provides. The motherboard usually does *not* route a line to the same pin on all slots... for example, INTA on slot 1 might be routed to INTB on slot 2 and INTC on slot 3, and then back to INTA on slot 4. This "mix 'em up" routing is done to help compensate for the fact that most PCI cards use only INTA - it keeps all the cards from pounding on the same interrupt line. This is also why one way to move a PCI card to a different IRQ, is to move it to a different slot. The motherboard must then route the interrupt lines to one or more IRQs. On "classic" PCI motherboards, with traditional PC interrupt controllers, there are only a very limited number of IRQs available (up through IRQ15) and many of these IRQs have dedicated functions and cannot be shared (e.g. any IRQ assigned to an ISA device can't be shared). As a result, these motherboards tend to route multiple PCI interrupts to only one or two IRQs - as in your case, where a whole boatload of things are being routed to IRQ11. On these traditional motherboards, all of the IRQ routing is under the control of the BIOS. Hence, the second way to un-burden IRQ11 would be to change your BIOS settings (as previously suggested). You would want to disable any unused devices - in particular, any IRQ-using ISA devices such as the parallel and serial ports - and mark these IRQs as "available, not reserved for ISA". A good BIOS would then change the PCI-INT-to-IRQ routing and spread out the interrupt load. Unfortunately, it sounds as if the HP BIOS is of the "Father Knows Best" variety, and won't let you control your settings. Unless you can find an "expert" menu, or a separate configuration program for the BIOS data (sometimes vendors make a DOS or self-booting program available, rather than putting the full BIOS configuration in the BIOS itself) you're stuck here. There's a third possibility: APIC, the "Advanced Programmable Interrupt Controller". This is a newer interrupt-controller architecture, present on SMP systems and on many modern uniprocessor systems. It provides the hardware and the OS with much more flexibility, and with quite a few additional IRQ numbers not supported by the traditional controller. You could try building a custom Linux kernel for your system, using a current stable kernel version (a 2.6 spin, at the moment). Enable APIC support, including the "APIC on uniprocessor" and "local APIC" support features. Boot this kernel, do an lspci -v, and see where your various cards and devices end up IRQ'ing. You may find that the APIC support has allowed the kernel to map these devices onto a wider range of IRQ numbers than previously. Unfortunately even this approach may not help on some motherboards. If the vendor has wired all of the INTA pins on the slots to the same line, and has also used this same line for the interrupts from the internal (non-slotted) PCI devices, then you'd be completely out of luck - it would be physically impossible to distribute the interrupts from these devices to different IRQs. My guess is that your biggest conflict is between the PRI card, and the network interfaces, since both are likely to be generators of lots of interrupts. Ugh... I just noticed something else... it looks as if the motherboard in question is using at least one PCI-to-PCI bridge: 81:01.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface Note the bus number: 81 hex. I think that this means that the card is sitting on the far side of a bridge chip... these are often used if a system has more PCI devices or slots than a single bus can support. I've had some bad experiences with bridged PCI systems in the past - some bridge chips seem to add quite a bit of latency to PCI bus access, or reduce bus throughput by quite a lot. Apparently the individual read and write transactions through the bridge suffer from a significant per-transaction overhead. I wonder whether IRQ latency/delay might not also be a problem here, or whether the bridge architecture might be forcing interrupts from some cards to use a single line/IRQ.
On Thu, Jul 2, 2009 at 4:41 PM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>wrote:> On Thu, Jul 02, 2009 at 04:15:13PM +0100, Tom O'Connor wrote: > > > I have tried all suggestions given. It just happens that none of them > have > > been much use. I'm very constrained by time on this project, less than > 11 > > days before i leave the company, so i'd like to have it in a workable > > state. Buying a better server, although it would probably work, would > > inevitably cost more money than they're willing to spend. > > You might notice that the OpenVox cards they bought are the cheapest on > the > > market? Coincidence.. no. > > Cheap? yes. Cheapest? Almost. Have you contacted their support? > > > (I'm completely unafiliated with them etc. etc.)I tried, I got passed around from person to person until i'd heard the script at least 4 times, so I gave up. Might try again tomorrow. I'm currently testing the same card in a different server, with a Tyan Intel chipset board, as opposed to a HP / AMD chipset. I'm somewhat more hopeful about this. I was told that newer servers have some proprietary PCI bus chips, which are optimised to deal with RAID cards and suchlike, which can be problematic when handing IRQ-heavy cards such as these. I think this is actually interesting, because the current Asterisk server is actually a Dell Optiplex desktop with a Pentium 150 in it. Can't get much more basic, but it works pretty well. (the only reason we're attempting an upgrade, is because the old asterisk 1.0 can't support features that the management want to implement, and the physical box is taking up too much space in the already cramped server room!) -- Tom O'Connor http://www.twinhelix.org tom at twinhelix.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090702/bb586740/attachment.htm