Sharing interrupts between a soundcard and some other device
============================================================

There is no way to share interrupts between two ISA cards or
between an ISA card and some other device.

Interrupt sharing between two PCI devices is supported under Linux
and Solaris. We don't support interrupt sharing under any other
operating systems.

Possible problems caused by interrupt sharing
=============================================

In general interrupt sharing should be avoided if possible. While interrupt
sharing works without problems in many cases there are many situations
where it doesn't work (see below).

Unfortunately there is no simple way to resolve PCI interrupt conflicts.
PCI interrupts are allocated by machine's BIOS and OSS doesn't have any way to
affect the allocation. There are no configuration options in soundconf that can
be used to solve the conflict.

Some BIOSes allow manual PCI interrupt configuration. In this case the
task is easy. Just change the PCI/PnP setup so that the soundcard has a private
interrupt.

Unfortunately most BIOSes only perform automatic interrupt allocation. In
this case there is no easy way to do this. First of all you should enable
PCI/PnP resource allocations made by BIOS. This can be done by telling that
the operating system cannot do them. So set the "PnP compatible OS installed"
(or whatever else) option to NO, OFF or Disabled (depending on the machine).

Next make sure that most of the interrupts are marked as "PCI/PnP" instead of
"Legacy/ISA". Only the interrupts that are required for some (old and obsolete)
non-PnP ISA devices (you probably don't have any of them) should be left for
Legacy/ISA.

The last hope is that moving the cards to different PCI slots helps (this is
not possible with notebooks).

If any of the above methods work the only choice is resolving the problems
if they get encountered.


OSS fails to start because the interrupt is busy.
-------------------------------------------------

This problem is caused because some other device driver (the one that already
has the interrupt allocated) is not designed to share interrupts. It keeps
the IRQ allocated for itself so that OSS cannot get access to it. The only
ways to fix this problem is trying to change the IRQ or fixing the conflicting
driver so that it can share interrupts. In Linux the conflicting driver
can be found out by looking at /proc/interrupts.

OSS doesn't work because of interrupt problems
----------------------------------------------

Audio recording and playback as well as MIDI recording require that
interrupts are working properly. Without interrupts the device will return
I/O errors and messages about input/output timeouts are printed on console.
Usually /proc/interrupts shows 0 as the interrupt count. There doesn't seem to
be any other workaround to this problem than solving the interrupt conflict.

Random system lockups
---------------------

It's possible that interrupt sharing causes lockups when a driver is loaded for
some of the devices but not all of them. The lockup will occur when a device
raises an interrupt but there is no driver loaded to handle it. The drivers for
the other devices cannot clear the interrupt and their interrupt handlers will
get called in tight loop which locks the system.

Note that the real cause to this problem is buggy hardware that could cause
interrupts before being enabled by the driver.

In many cases this kind of lockup occurs immediately when soundon is executed or
few seconds or minutes after that. However it's possible that the lockup never
happens after soundoff is executed.

This problem is known to happen with the original NVidia Riva chip when
the X server is running at the same time when OSS is loaded (latest X11
versions may have fixed this).

The possible workarounds (in case the IRQ conflict cannot be resolved) are:

1) Disable any conflicting motherboard devices you don't need them. There is
probably a BIOS setup option for doing this (at least with USB devices).
1b) Use the "setpci" utility in Linux and try to disable the conflicting
device this may work even there is no way to disable the device in BIOS.
To use this method you should know exactly what you do since there is a chance
that you cause damage to your system.
2) Avoid "warm" booting to Linux/Unix after running Windows. You should power
off the machine so that all devices get completely reset. Otherwise the device
may be left partially active after Windows and it may try to raise an
interrupt.
3) Try to find working drivers for all conflicting devices. Install them and
ensure that they are loaded before running soundon. The order when the drivers
are loaded may be important. Try different order if you encounter a lockup.