asterisk users - Nov 2005 - Intel Desktop MotherBoards Unsuitable for Digium Boards

FYI:

We're trying to standardise on a tier one motherboard for the Asterisk 
boxes we build for customers and thought we'd try to use a low-end Intel 
Desktop Board since even a low-end Celeron has more than enough 
horsepower to handle a typical 8x32 PBX.

To make a long story short, according to Intel Dealer Technical Support 
(we became Intel dealers in order to get answers to our questions) there 
is no Intel motherboard that permits the IRQs to be configured uniquely. 
They are all hardwired and shared. This information applies to both the 
Intel Desktop Board and Server Board product lines.

Please let me know if your experience differs from what I've been told 
by Intel.

Otherwise, you've been warned -- Intel mobos appear to be unsuitable for 
use with Digium hardware.

-- 
George Pajari, netVOICE communications    604 484 VOIP (484 8647 x102)
Open Source VoIP/Telephony Specialists  1 877 NET VOIP (638 8647 x102)
                  www.netvoice.ca  www.ip-centrex.ca
      www.digium.ca www.grandstream.ca www.sipura.ca www.snom.ca

Please clarify,

are you referring to a motherboard with an "intel chipset" or an
"Intel
Motherboard"?

Am currently putting together some desktop machines to run * on that are
Asus, but with an intel chipset.

If you could clarify this, it would be a great help.

ta

Mark

On 11/9/05, George Pajari <George.Pajari@netvoice.ca>
wrote:
>
> FYI:
>
> We're trying to standardise on a tier one motherboard for the Asterisk
> boxes we build for customers and thought we'd try to use a low-end
Intel
> Desktop Board since even a low-end Celeron has more than enough
> horsepower to handle a typical 8x32 PBX.
>
> To make a long story short, according to Intel Dealer Technical Support
> (we became Intel dealers in order to get answers to our questions) there
> is no Intel motherboard that permits the IRQs to be configured uniquely.
> They are all hardwired and shared. This information applies to both the
> Intel Desktop Board and Server Board product lines.
>
> Please let me know if your experience differs from what I've been told
> by Intel.
>
> Otherwise, you've been warned -- Intel mobos appear to be unsuitable
for
> use with Digium hardware.
>
> --
> George Pajari, netVOICE communications 604 484 VOIP (484 8647 x102)
> Open Source VoIP/Telephony Specialists 1 877 NET VOIP (638 8647 x102)
> www.netvoice.ca <http://www.netvoice.ca>
www.ip-centrex.ca<http://www.ip-centrex.ca>
> www.digium.ca <http://www.digium.ca>
www.grandstream.ca<http://www.grandstream.ca>
> www.sipura.ca <http://www.sipura.ca> www.snom.ca
<http://www.snom.ca>
>
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com
<http://Easynews.com>--
>
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>


--
regards,

Mark P. Edwards
FWD: 667917
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20051108/a9b72d8c/attachment.htm

I have come across things like this before, but it's generally not an issue
if
you simply disable the onboard stuff that you don't need and select the PCI 
slot(s) wisely.

I had the situation where my mobo allocated fixed IRQs to each slot, and shared 
  IRQs between some of them (I can't remember the exact IRQs, but for
arguments
sake; 10, 11, 3, 5, 10, 11 in slot order - 6 slots, 2 sharing IRQs.)

In most cases, IRQ 5 will be unused by anything on the mobo, giving one
"fixed,
unused" interrupt. This is where I placed my zaptel card.

By disabling my COM ports, I was able to free IRQ3. You can also disable stuff 
like USB, Parallel, Audio, secondary IDE, etc. etc, which can all free-up IRQs.


=========================================Rod Bacon
Empowered Communications
Ground Floor, 102 York St. South Melbourne
Victoria, Australia. 3205
Phone: +613 99401600    Fax: +613 99401650
FWD: 512237                   ICQ: 5662270
=========================================

George Pajari wrote:
> FYI:
> 
> We're trying to standardise on a tier one motherboard for the Asterisk 
> boxes we build for customers and thought we'd try to use a low-end
Intel
> Desktop Board since even a low-end Celeron has more than enough 
> horsepower to handle a typical 8x32 PBX.
> 
> To make a long story short, according to Intel Dealer Technical Support 
> (we became Intel dealers in order to get answers to our questions) there 
> is no Intel motherboard that permits the IRQs to be configured uniquely. 
> They are all hardwired and shared. This information applies to both the 
> Intel Desktop Board and Server Board product lines.
> 
> Please let me know if your experience differs from what I've been told 
> by Intel.
> 
> Otherwise, you've been warned -- Intel mobos appear to be unsuitable
for
> use with Digium hardware.
>

George Pajari wrote:
> FYI:
> 
> We're trying to standardise on a tier one motherboard for the Asterisk
> boxes we build for customers and thought we'd try to use a low-end
Intel
> Desktop Board since even a low-end Celeron has more than enough
> horsepower to handle a typical 8x32 PBX.
> 
> To make a long story short, according to Intel Dealer Technical Support
> (we became Intel dealers in order to get answers to our questions) there
> is no Intel motherboard that permits the IRQs to be configured uniquely.
> They are all hardwired and shared. This information applies to both the
> Intel Desktop Board and Server Board product lines.
So just install Digium cards and disable anything you don't need.  You only
need to change IRQs if you have an unresolvable conflict.

-- 
Cheers,

Matt Riddell
_______________________________________________

http://www.sineapps.com/news.php (Daily Asterisk News - html)
http://freevoip.gedameurope.com (Free Asterisk Voip Community)
http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss)

On Tuesday 08 November 2005 18:20, George Pajari wrote:
> To make a long story short, according to Intel Dealer Technical Support
> (we became Intel dealers in order to get answers to our questions) there
> is no Intel motherboard that permits the IRQs to be configured uniquely.
> They are all hardwired and shared. This information applies to both the
> Intel Desktop Board and Server Board product lines.
I find this almost impossible to believe.

In XT-PIC mode, absolutely.  However every modern chipset utilizes an IOAPIC 
now and every device has its own IRQ line.  When the IOAPIC is in emulation 
(XT-PIC) mode, then yes many of the interrupts get "merged" into the
standard
16 interrupts.

However, if your Linux kernel is utilizing the IOAPIC's native mode things 
change drastically:

# cat /proc/interrupts
           CPU0
  0:  942314955    IO-APIC-edge  timer
  1:         10    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:        111    IO-APIC-edge  i8042
 14:     496236    IO-APIC-edge  ide0
177:  211098355   IO-APIC-level  eth0
185:          2   IO-APIC-level  ehci_hcd:usb1
193:          0   IO-APIC-level  ohci_hcd:usb2
201:          0   IO-APIC-level  ohci_hcd:usb3
209:         86   IO-APIC-level  ohci_hcd:usb4
217: 3769265646   IO-APIC-level  wct4xxp

As you can see on this particular system (not an Intel reference board, 
granted, but my Intel boards do work similarly) everything is on its own 
interrupt, and the interrupt numbers don't stop at 15.

I'd really like some clarification on that...  Do Intel reference boards 
actually tie the physical INT# signals of peripherals together, or are they 
just stating that unless you use the native IO-APIC mode you will have shared 
interrupts due to the "emulation"?

Hopefully someone from Digium will step in and give the official word, because 
I have it on good authority that Digium hardware on Intel motherboards work 
well together.  Hell, I've had my old P4 Intel reference board (with RamBus 
memory) work just fine without shared interrupts.

-A.

Rod Bacon wrote:
> By disabling my COM ports, I was able to free IRQ3. You can also disable
stuff
> like USB, Parallel, Audio, secondary IDE, etc. etc, which can all free-up
IRQs.
This is exactly what I did on a mobo that shared irqs without recourse, 
and it caused me to find out that if you disable the audio device, 
ztmonitor fails as it requires /dev/dsp.  So get your gains and echo 
problems resolved before you disable the sound chip ;)

George Pajari wrote:
> To make a long story short, according to Intel Dealer Technical 
> Support (we became Intel dealers in order to get answers to our 
> questions) there is no Intel motherboard that permits the IRQs to be 
> configured uniquely. They are all hardwired and shared. This 
> information applies to both the Intel Desktop Board and Server Board 
> product lines.
I have been using a D945GNT with great success, even with shared 
interrupts. But read on for a solution I just found..

I shared your frustration with not being able to get the interrupts to 
move to not being shared.   What is more frustrating is that I knew with 
almost certainty that every device had a distinct interrupt line wired 
into the APIC, and that linux wasn't moving the interrupts off of a 
single interrupt.... Or stated differently, I knew, with reasonable 
certainty, that the hardware of the machine was capable of moving any 
device to almost any interrupt, but the software wasn't asking the 
hardware to do so.  This functionality is available in almost every 
reasonably modern intel chipset.

My interrupts looked something like this:
# cat /proc/interrupts
           CPU0      
  0: 1507033453          XT-PIC  timer
  1:        730          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  acpi, ehci_hcd, uhci_hcd
 10:    1169132          XT-PIC  libata, uhci_hcd
 11: 1593809534          XT-PIC  eth0, uhci_hcd, uhci_hcd, wct4xxp
 12:         66          XT-PIC  i8042
NMI:          0
ERR:          0

Didn't matter if I moved the card to a different slot, etc. etc. etc. 
etc..   Always on interrupt 11.

In short, the motherboard was putting everything on interrupt 11 in 
XT-PIC mode.  This was a *software* issue.

Someone mentioned IO-APIC in this thread, and it lit up a different part 
of my brain for me to be able to search around the net and find that at 
least under CentOS, you have to be running a SMP kernel (even on a UP 
machine) to be able to get the IO-APIC functionality.

Now, with a SMP kernel I get:

# cat /proc/interrupts
           CPU0      
  0:      55935    IO-APIC-edge  timer
  1:          8    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:         66    IO-APIC-edge  i8042
169:          0   IO-APIC-level  uhci_hcd
185:          0   IO-APIC-level  uhci_hcd
193:          0   IO-APIC-level  uhci_hcd
201:          0   IO-APIC-level  ehci_hcd, uhci_hcd
209:      17700   IO-APIC-level  wct4xxp
217:        201   IO-APIC-level  eth0
233:       5187         PCI-MSI  libata
NMI:          0
LOC:      55761
ERR:          0
MIS:          0

Much Better.  

For reference:
  Linux  2.6.9-22.0.1.ELsmp #1 SMP Thu Oct 27 13:14:25 CDT 2005 i686 
i686 i386 GNU/Linux

-forrest

Forrest W Christian wrote:
>
>
> Someone mentioned IO-APIC in this thread, and it lit up a different 
> part of my brain for me to be able to search around the net and find 
> that at least under CentOS, you have to be running a SMP kernel (even 
> on a UP machine) to be able to get the IO-APIC functionality. 
This is not true from my experience.  I enable IO-APIC in the kernel 
without enabling SMP and I get IO-APIC.

Cheers,
Kevin
--
Optimacy Communications, LLC
http://www.optimacycomm.com

Kevin Hanson wrote:
> Forrest W Christian wrote:
> 
>>
>>
>> Someone mentioned IO-APIC in this thread, and it lit up a different 
>> part of my brain for me to be able to search around the net and find 
>> that at least under CentOS, you have to be running a SMP kernel (even 
>> on a UP machine) to be able to get the IO-APIC functionality. 
> 
> This is not true from my experience.  I enable IO-APIC in the kernel 
> without enabling SMP and I get IO-APIC.
That depends on how the kernel is built by the distro.