mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-19 10:44:14 +08:00
b02aae9cf5
x86: provide a DMI based port 0x80 I/O delay override.
Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the "alternate
diagnostic port" 0xed (as used by some BIOSes as well) for these.
David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.
Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.
First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...
Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.
Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.
This also introduces a command-line parameter "io_delay" to override
the DMI based choice again:
io_delay=<standard|alternate>
where "standard" means using the standard port 0x80 and "alternate"
port 0xed.
This retains the udelay method as a config (CONFIG_UDELAY_IO_DELAY) and
command-line ("io_delay=udelay") choice for testing purposes as well.
This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as David P. Reed reported the problem was already gone after using the
udelay version. He moreover reported that booting with "acpi=off" also
fixed things and seeing as how ACPI isn't touched until after this DMI
based I/O port switch I believe it's safe to leave the ones in the boot
code be.
The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.
This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.
Signed-off-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
125 lines
4.1 KiB
Plaintext
125 lines
4.1 KiB
Plaintext
menu "Kernel hacking"
|
|
|
|
config TRACE_IRQFLAGS_SUPPORT
|
|
def_bool y
|
|
|
|
source "lib/Kconfig.debug"
|
|
|
|
config EARLY_PRINTK
|
|
bool "Early printk" if EMBEDDED && DEBUG_KERNEL && X86_32
|
|
default y
|
|
help
|
|
Write kernel log output directly into the VGA buffer or to a serial
|
|
port.
|
|
|
|
This is useful for kernel debugging when your machine crashes very
|
|
early before the console code is initialized. For normal operation
|
|
it is not recommended because it looks ugly and doesn't cooperate
|
|
with klogd/syslogd or the X server. You should normally N here,
|
|
unless you want to debug such a crash.
|
|
|
|
config DEBUG_STACKOVERFLOW
|
|
bool "Check for stack overflows"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
This option will cause messages to be printed if free stack space
|
|
drops below a certain limit.
|
|
|
|
config DEBUG_STACK_USAGE
|
|
bool "Stack utilization instrumentation"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Enables the display of the minimum amount of free stack which each
|
|
task has ever had available in the sysrq-T and sysrq-P debug output.
|
|
|
|
This option will slow down process creation somewhat.
|
|
|
|
comment "Page alloc debug is incompatible with Software Suspend on i386"
|
|
depends on DEBUG_KERNEL && HIBERNATION
|
|
depends on X86_32
|
|
|
|
config DEBUG_PAGEALLOC
|
|
bool "Debug page memory allocations"
|
|
depends on DEBUG_KERNEL && !HIBERNATION && !HUGETLBFS
|
|
depends on X86_32
|
|
help
|
|
Unmap pages from the kernel linear mapping after free_pages().
|
|
This results in a large slowdown, but helps to find certain types
|
|
of memory corruptions.
|
|
|
|
config DEBUG_RODATA
|
|
bool "Write protect kernel read-only data structures"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Mark the kernel read-only data as write-protected in the pagetables,
|
|
in order to catch accidental (and incorrect) writes to such const
|
|
data. This option may have a slight performance impact because a
|
|
portion of the kernel code won't be covered by a 2MB TLB anymore.
|
|
If in doubt, say "N".
|
|
|
|
config 4KSTACKS
|
|
bool "Use 4Kb for kernel stacks instead of 8Kb"
|
|
depends on DEBUG_KERNEL
|
|
depends on X86_32
|
|
help
|
|
If you say Y here the kernel will use a 4Kb stacksize for the
|
|
kernel stack attached to each process/thread. This facilitates
|
|
running more threads on a system and also reduces the pressure
|
|
on the VM subsystem for higher order allocations. This option
|
|
will also use IRQ stacks to compensate for the reduced stackspace.
|
|
|
|
config X86_FIND_SMP_CONFIG
|
|
def_bool y
|
|
depends on X86_LOCAL_APIC || X86_VOYAGER
|
|
depends on X86_32
|
|
|
|
config X86_MPPARSE
|
|
def_bool y
|
|
depends on X86_LOCAL_APIC && !X86_VISWS
|
|
depends on X86_32
|
|
|
|
config DOUBLEFAULT
|
|
default y
|
|
bool "Enable doublefault exception handler" if EMBEDDED
|
|
depends on X86_32
|
|
help
|
|
This option allows trapping of rare doublefault exceptions that
|
|
would otherwise cause a system to silently reboot. Disabling this
|
|
option saves about 4k and might cause you much additional grey
|
|
hair.
|
|
|
|
config IOMMU_DEBUG
|
|
bool "Enable IOMMU debugging"
|
|
depends on GART_IOMMU && DEBUG_KERNEL
|
|
depends on X86_64
|
|
help
|
|
Force the IOMMU to on even when you have less than 4GB of
|
|
memory and add debugging code. On overflow always panic. And
|
|
allow to enable IOMMU leak tracing. Can be disabled at boot
|
|
time with iommu=noforce. This will also enable scatter gather
|
|
list merging. Currently not recommended for production
|
|
code. When you use it make sure you have a big enough
|
|
IOMMU/AGP aperture. Most of the options enabled by this can
|
|
be set more finegrained using the iommu= command line
|
|
options. See Documentation/x86_64/boot-options.txt for more
|
|
details.
|
|
|
|
config IOMMU_LEAK
|
|
bool "IOMMU leak tracing"
|
|
depends on DEBUG_KERNEL
|
|
depends on IOMMU_DEBUG
|
|
help
|
|
Add a simple leak tracer to the IOMMU code. This is useful when you
|
|
are debugging a buggy device driver that leaks IOMMU mappings.
|
|
|
|
config UDELAY_IO_DELAY
|
|
bool "Delay I/O through udelay instead of outb"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Make inb_p/outb_p use udelay() based delays by default. Please note
|
|
that udelay() does not have the same bus-level side-effects that
|
|
the normal outb based delay does meaning this could cause drivers
|
|
to change behaviour and/or bugs to surface.
|
|
|
|
endmenu
|