[Asterisk-Users] Re: Booting error - Unable to specify channel 2:

[Rich Adamson]

> > I just went through all this as well. The best thing to do IMHO is to
> > try to find a way to manually assign IRQ in the BIOS. Also, and this is
> > what I didn't see at first, some slots SHARE IRQ. Avoid this! If you are
> > not using USB at all, turn it off in BIOS if possible. Tell the BIOS
> > "NOT INSTALLED" for any peripherals not installed. I was able to remove
> > parallel and serial interfaces as well since nothing is connect to this
> > box. Here's what I have now:
> >
> >    0:   27713309          XT-PIC  timer
> >    1:        167          XT-PIC  keyboard
> >    2:          0          XT-PIC  cascade
> >    3:  277073215          XT-PIC  wctdm  <------ TDM410
> >    4:    1114724          XT-PIC  eth0
> >    7:  277082652          XT-PIC  wcfxo  <------ X100P
> >    8:          1          XT-PIC  rtc
> >    9:  277077218          XT-PIC  wcfxo  <------ X100P
> >   12:          0          XT-PIC  PS/2 Mouse
> >   14:     102780          XT-PIC  ide0
> >   15:          3          XT-PIC  ide1
> >
> > hth
> Thank you.  Unfortunately, I do not have * running on a box dedicated to it (for now).
> So, I do need to use USP, serial, and the printer port.
> 
> I wonder though, if my install of * works well while sharing IRQ's, is there really
> any compelling reason to get the Zap cards on their own IRQ's?

No, there is no compelling reason at all.

Some folks have had IRQ sharing problems, but the majority do not. Yet,
the few keep repeating it as though its a major issue for everyone, which
is not even close to the truth.

Here's one example...
  9:  871579742          XT-PIC  ehci-hcd, eth0, wcfxo, Intel ICH4
 10:          0          XT-PIC  usb-uhci
 11: 3631482514          XT-PIC  usb-uhci, wcfxo
where the same interrupt is shared by several devices with absolutely
no problems whatsoever. (Notice the 100 meg nic card is sharing with a
x100p card, etc.)

The bottom line for sharing interrupts involves having some technical
knowledge as to which devices "actually" use interrupts in the first place
(even though an interrupt might be allocated to a card, doesn't mean 
its actually used for anything), the ability of the cards and drivers 
to handle sharing, motherboard, etc.

Without that knowledge, it boils down to simply trying it. If the cards
work at all, there is a high probability they will continue to work without
messing around with that stuff.

Rich