forked from luck/tmp_suning_uos_patched
fbab41ccc4
CONFIG_PCI=n, CONFIG_HT_IRQ=y results in the following compile error: ... LD vmlinux arch/i386/mach-generic/built-in.o: In function `apicid_to_node': summit.c:(.text+0x53): undefined reference to `apicid_2_node' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf79): undefined reference to `write_ht_irq_low' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf85): undefined reference to `write_ht_irq_high' arch/i386/kernel/built-in.o: In function `k7nops': alternative.c:(.data+0x1358): undefined reference to `mask_ht_irq' alternative.c:(.data+0x1360): undefined reference to `unmask_ht_irq' make[1]: *** [vmlinux] Error 1 Bug report by Jesper Juhl. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
63 lines
2.1 KiB
Plaintext
63 lines
2.1 KiB
Plaintext
#
|
|
# PCI configuration
|
|
#
|
|
config PCI_MSI
|
|
bool "Message Signaled Interrupts (MSI and MSI-X)"
|
|
depends on PCI
|
|
depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
|
|
help
|
|
This allows device drivers to enable MSI (Message Signaled
|
|
Interrupts). Message Signaled Interrupts enable a device to
|
|
generate an interrupt using an inbound Memory Write on its
|
|
PCI bus instead of asserting a device IRQ pin.
|
|
|
|
Use of PCI MSI interrupts can be disabled at kernel boot time
|
|
by using the 'pci=nomsi' option. This disables MSI for the
|
|
entire system.
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
config PCI_MULTITHREAD_PROBE
|
|
bool "PCI Multi-threaded probe (EXPERIMENTAL)"
|
|
depends on PCI && EXPERIMENTAL
|
|
help
|
|
Say Y here if you want the PCI core to spawn a new thread for
|
|
every PCI device that is probed. This can cause a huge
|
|
speedup in boot times on multiprocessor machines, and even a
|
|
smaller speedup on single processor machines.
|
|
|
|
But it can also cause lots of bad things to happen. A number
|
|
of PCI drivers can not properly handle running in this way,
|
|
some will just not work properly at all, while others might
|
|
decide to blow up power supplies with a huge load all at once,
|
|
so use this option at your own risk.
|
|
|
|
It is very unwise to use this option if you are not using a
|
|
boot process that can handle devices being created in any
|
|
order. A program that can create persistant block and network
|
|
device names (like udev) is a good idea if you wish to use
|
|
this option.
|
|
|
|
Again, use this option at your own risk, you have been warned!
|
|
|
|
When in doubt, say N.
|
|
|
|
config PCI_DEBUG
|
|
bool "PCI Debugging"
|
|
depends on PCI && DEBUG_KERNEL
|
|
help
|
|
Say Y here if you want the PCI core to produce a bunch of debug
|
|
messages to the system log. Select this if you are having a
|
|
problem with PCI support and want to see more of what is going on.
|
|
|
|
When in doubt, say N.
|
|
|
|
config HT_IRQ
|
|
bool "Interrupts on hypertransport devices"
|
|
default y
|
|
depends on PCI && X86_LOCAL_APIC && X86_IO_APIC
|
|
help
|
|
This allows native hypertransport devices to use interrupts.
|
|
|
|
If unsure say Y.
|