Asterisk PCI bus Troubleshooting

This information mostly pertains to IRQ and PCI bus availability problems with the Digium TDM400P. I am not sure about other Digium or 3rd party cards.


Verify that your Digium hardware is not sharing an IRQ on your
system. You can accomplish this by running "cat /proc/interrupts". Do
not solely rely on "cat /proc/interrupts" to determine whether your
Digium hardware is sharing an IRQ on your system. Make sure your Digium
hardware is on its own IRQ by itself and that it is taking interrupts.
You can determine whether it is taking interrupts from the 2nd column of
output from "cat /proc/interrupts". This should be something other
than zero. You will also need to verify that your Digium hardware is
not sharing an IRQ by examining the output after running"lspci -v" and
"lspci -vb". Using lspci is the best way to determine whether or not
your Digium hardware is sharing an IRQ on your system. Please verify
that all Digium hardware is on its very own IRQ by itself. You may need
to disable unnecessary hardware on your machine such as sound
controllers, USB controllers, extra ethernet controllers, firewire,
parallel ports, and/or serial ports. You should try moving and swapping
the Digium card to different PCI slots in order to get it on it's own IRQ.
Some BIOS's will allow you to specify an IRQ for each PCI slot and/or
onboard devices.

If you are running an IDE hard drive please verify that you are using
DMA mode with a UDMA setting of no lower than 2 or higher than 3. UDMA
mode 2 is ATA33. UDMA mode 3 is ATA44. This can be done using hdparm.
Digium suggests using "hdparm -d 1 -X udma2 -c 3 /dev/IDE Device". You
can check the status using "hdparm /dev/IDE Device" and "hdparm -i
/dev/IDE Device". If you make modifications to your IDE hard drive
settings they will only be kept until you reboot. You will need to add
the hdparm command you executed to one of your distribution's startup
scripts. This way the IDE hard drive settings will be updated on each
reboot.

You can check whether or not your Digium hardware on your system is
experiencing IRQ misses by using the zttest application which should be
located in yourzaptel source directory. Do not solely rely on zttest to
determine whether you are having IRQ misses with your Digium hardware on
your system. Optimally, we are looking for output of 100% from zttest.
Digium cards will function properly as long as they do not report back less
than 99.98%. Some people have reported no apparent problems with output
as low as 99.975%, while others will have many apparent problems with an
output as low 99.975%. You are almost guaranteed to have many apparent
problems with an output lower than 99.975%. Digium strongly suggest doing
everything possible in order to obtain at least 99.98% output from
zttest. I would watch the output over a 5 minutes period to check for
spikes on intervals. You may also look for IRQ misses using the zttool
application. Do not solely rely on zttool to determine whether you are
having IRQ misses with your Digium hardware on your system. This
application should be built while compiling zaptel. zttool requires the
libnewt development package to be installed on your system in order to
compile properly.

IRQ misses with your Digium hardware can be due to I/O problems on your
system. You may test if you are having I/O problems on your system by
running "hdparm -t /dev/Hard Drive Device". This will causes massive
amounts of I/O on your system. The symptoms of an I/O problem on your
system could be cracklingand/or static on the line while running "hdparm
-t /dev/Hard Drive Device". If you are having an I/O problem on your
system and run this command it could result in dropped calls
temporarily. If you are experiencing those symptoms while running
"hdparm -t /dev/Hard Drive Device" it is likely that you havean I/O
problem on your system. We would suggest using an IDE harddrive rather
than SCSI or SATA in order to configure your hard drive to UDMA2.
Configuring a SCSI or SATA hard drive to UDMA2 is not possible. This is
only possible on an IDE hard drive. Do not solely rely on "hdparm -t
/dev/Hard Drive Device" to determine whether or not you have an I/O
problem on your system.

Please ensure that you are not running X-Windows, frame-buffer, or
serial console, as these will cause problems with our hardware. You can
disable frame-buffer by supplying the "vga=normal" option to your kernel
at boot time. Frame-buffer may start your console with a high
resolution and a logo that is alongthe top of the screen.

If you are still having IRQ misses with our hardware you could try
booting your kernel with "acpi=off" and/or "noapic" to disable ACPI
power management andAPIC. These has been known to cause interrupt
sharing problems as well.

If your system supports Hyper-Threading Technology, you should disable
it in your BIOS to see if it resolves your problems.


This information mostly pertains to IRQ and PCI bus availability problems with the Digium TDM400P. I am not sure about other Digium or 3rd party cards.


Verify that your Digium hardware is not sharing an IRQ on your
system. You can accomplish this by running "cat /proc/interrupts". Do
not solely rely on "cat /proc/interrupts" to determine whether your
Digium hardware is sharing an IRQ on your system. Make sure your Digium
hardware is on its own IRQ by itself and that it is taking interrupts.
You can determine whether it is taking interrupts from the 2nd column of
output from "cat /proc/interrupts". This should be something other
than zero. You will also need to verify that your Digium hardware is
not sharing an IRQ by examining the output after running"lspci -v" and
"lspci -vb". Using lspci is the best way to determine whether or not
your Digium hardware is sharing an IRQ on your system. Please verify
that all Digium hardware is on its very own IRQ by itself. You may need
to disable unnecessary hardware on your machine such as sound
controllers, USB controllers, extra ethernet controllers, firewire,
parallel ports, and/or serial ports. You should try moving and swapping
the Digium card to different PCI slots in order to get it on it's own IRQ.
Some BIOS's will allow you to specify an IRQ for each PCI slot and/or
onboard devices.

If you are running an IDE hard drive please verify that you are using
DMA mode with a UDMA setting of no lower than 2 or higher than 3. UDMA
mode 2 is ATA33. UDMA mode 3 is ATA44. This can be done using hdparm.
Digium suggests using "hdparm -d 1 -X udma2 -c 3 /dev/IDE Device". You
can check the status using "hdparm /dev/IDE Device" and "hdparm -i
/dev/IDE Device". If you make modifications to your IDE hard drive
settings they will only be kept until you reboot. You will need to add
the hdparm command you executed to one of your distribution's startup
scripts. This way the IDE hard drive settings will be updated on each
reboot.

You can check whether or not your Digium hardware on your system is
experiencing IRQ misses by using the zttest application which should be
located in yourzaptel source directory. Do not solely rely on zttest to
determine whether you are having IRQ misses with your Digium hardware on
your system. Optimally, we are looking for output of 100% from zttest.
Digium cards will function properly as long as they do not report back less
than 99.98%. Some people have reported no apparent problems with output
as low as 99.975%, while others will have many apparent problems with an
output as low 99.975%. You are almost guaranteed to have many apparent
problems with an output lower than 99.975%. Digium strongly suggest doing
everything possible in order to obtain at least 99.98% output from
zttest. I would watch the output over a 5 minutes period to check for
spikes on intervals. You may also look for IRQ misses using the zttool
application. Do not solely rely on zttool to determine whether you are
having IRQ misses with your Digium hardware on your system. This
application should be built while compiling zaptel. zttool requires the
libnewt development package to be installed on your system in order to
compile properly.

IRQ misses with your Digium hardware can be due to I/O problems on your
system. You may test if you are having I/O problems on your system by
running "hdparm -t /dev/Hard Drive Device". This will causes massive
amounts of I/O on your system. The symptoms of an I/O problem on your
system could be cracklingand/or static on the line while running "hdparm
-t /dev/Hard Drive Device". If you are having an I/O problem on your
system and run this command it could result in dropped calls
temporarily. If you are experiencing those symptoms while running
"hdparm -t /dev/Hard Drive Device" it is likely that you havean I/O
problem on your system. We would suggest using an IDE harddrive rather
than SCSI or SATA in order to configure your hard drive to UDMA2.
Configuring a SCSI or SATA hard drive to UDMA2 is not possible. This is
only possible on an IDE hard drive. Do not solely rely on "hdparm -t
/dev/Hard Drive Device" to determine whether or not you have an I/O
problem on your system.

Please ensure that you are not running X-Windows, frame-buffer, or
serial console, as these will cause problems with our hardware. You can
disable frame-buffer by supplying the "vga=normal" option to your kernel
at boot time. Frame-buffer may start your console with a high
resolution and a logo that is alongthe top of the screen.

If you are still having IRQ misses with our hardware you could try
booting your kernel with "acpi=off" and/or "noapic" to disable ACPI
power management andAPIC. These has been known to cause interrupt
sharing problems as well.

If your system supports Hyper-Threading Technology, you should disable
it in your BIOS to see if it resolves your problems.


Created by: mustardman, Last modification: Mon 29 of Aug, 2005 (22:19 UTC)
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+