linux-stable.git/arch/x86, branch linux-2.6.26.y

x86: avoid dereferencing beyond stack + THREAD_SIZE

2008-10-22T21:13:25+00:00

commit 60e6258cd43f9b06884f04f0f7cefb9c40f17a32 upstream

It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE
while iterating through instruction pointers if fp equals the upper boundary,
causing a kernel panic.

Signed-off-by: David Rientjes 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86, early_ioremap: fix fencepost error

2008-10-22T21:13:13+00:00

commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream

The x86 implementation of early_ioremap has an off by one error. If we get
an object which ends on the first byte of a page we undermap by one page and
this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
this alignment.

The size computation is currently

	last_addr = phys_addr + size - 1;
	npages = (PAGE_ALIGN(last_addr) - phys_addr)

(Consider a request for 1 byte at alignment 0...)

Closes #11693

Debugging work by Ian Campbell/Felix Geyer

Signed-off-by: Alan Cox 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: improve UP kernel when CPU-hotplug and SMP is enabled

2008-10-22T21:13:12+00:00

commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream

num_possible_cpus() can be > 1 when disabled CPUs have been accounted.

Disabled CPUs are not in the cpu_present_map, so we can use
num_present_cpus() as a safe indicator to switch to UP alternatives.

Reported-by: Chuck Ebbert 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.

2008-10-22T21:13:11+00:00

Not in upstream above 2.6.27 due to change in the way this code works
(has been fixed differently there.)

Someone from the community found out, that after repeatedly unloading
and loading a device driver that uses MSI IRQs, the system eventually
assigned the vector initially reserved for IRQ0 to the device driver.

The reason for this is, that although IRQ0 is tied to the
FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
corresponding bit in the used_vectors map is not set. So, if vectors are
released and assigned often enough, the vector will get assigned to
another interrupt. This happens more often with MSI interrupts as those
are exclusively using a vector.

Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.

Signed-off-by: Stefan Bader 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: HPET: read back compare register before reading counter

2008-10-09T03:23:05+00:00

commit 72d43d9bc9210d24d09202eaf219eac09e17b339 upstream

After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
with small deltas. There seems to be a delay between writing the compare
register and the transffer to the internal register which triggers the
interrupt. Reading back the value makes sure, that it hit the internal
match register befor we compare against the counter value.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86: HPET fix moronic 32/64bit thinko

2008-10-09T03:23:05+00:00

commit f7676254f179eac6b5244a80195ec8ae0e9d4606 upstream

We use the HPET only in 32bit mode because:
1) some HPETs are 32bit only
2) on i386 there is no way to read/write the HPET atomic 64bit wide

The HPET code unification done by the "moron of the year" did
not take into account that unsigned long is different on 32 and
64 bit.

This thinko results in a possible endless loop in the clockevents
code, when the return comparison fails due to the 64bit/332bit
unawareness.

unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit.
but the final compare will fail and return -ETIME causing endless
loops.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

HPET: make minimum reprogramming delta useful

2008-10-09T03:23:04+00:00

commit 7cfb0435330364f90f274a26ecdc5f47f738498c upstream

The minimum reprogramming delta was hardcoded in HPET ticks,
which is stupid as it does not work with faster running HPETs.
The C1E idle patches made this prominent on AMD/RS690 chipsets,
where the HPET runs with 25MHz. Set it to 5us which seems to be
a reasonable value and fixes the problems on the bug reporters
machines. We have a further sanity check now in the clock events,
which increases the delta when it is not sufficient.

Signed-off-by: Thomas Gleixner 
Tested-by: Luiz Fernando N. Capitulino 
Tested-by: Dmitry Nezhevenko 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix memmap=exactmap boot argument

2008-10-09T03:23:01+00:00

Backport of d6be118a97ce51ca84035270f91c2bccecbfac5f by Chuck Ebbert

When using kdump modifying the e820 map is yielding strange results.

For example starting with

 BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000100 - 0000000000093400 (usable)
 BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
 BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data)
 BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
 BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)

and booting with args

memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K

resulted in:

 user-defined physical RAM map:
 user: 0000000000000000 - 0000000000093400 (usable)
 user: 0000000000093400 - 00000000000a0000 (reserved)
 user: 0000000000100000 - 000000003fee0000 (usable)
 user: 000000003fee0000 - 000000003fef3000 (ACPI data)
 user: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
 user: 000000003ff80000 - 0000000040000000 (reserved)
 user: 00000000e0000000 - 00000000f0000000 (reserved)
 user: 00000000fec00000 - 00000000fec10000 (reserved)
 user: 00000000fee00000 - 00000000fee01000 (reserved)
 user: 00000000ff000000 - 0000000100000000 (reserved)

But should have resulted in:

 user-defined physical RAM map:
 user: 0000000000000000 - 00000000000a0000 (usable)
 user: 0000000001000000 - 000000000151b000 (usable)
 user: 00000000015bb000 - 0000000008ffc000 (usable)
 user: 000000003fee0000 - 000000003ff80000 (ACPI data)

This is happening because of an improper usage of strcmp() in the
e820 parsing code.  The strcmp() always returns !0 and never resets the
value for e820.nr_map and returns an incorrect user-defined map.

This patch fixes the problem.

Signed-off-by: Prarit Bhargava 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: add io delay quirk for Presario F700

2008-10-09T03:23:01+00:00

commit e6a5652fd156a286faadbf7a4062b5354d4e346e upstream

Manually adding "io_delay=0xed" fixes system lockups in ioapic
mode on this machine.

System Information
	Manufacturer: Hewlett-Packard
	Product Name: Presario F700 (KA695EA#ABF)

Base Board Information
	Manufacturer: Quanta
	Product Name: 30D3

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=459546

Signed-off-by: Chuck Ebbert 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: fix SMP alternatives: use mutex instead of spinlock, text_poke is sleepable

2008-10-09T03:23:01+00:00

commit 2f1dafe50cc4e58a239fd81bd47f87f32042a1ee upstream

text_poke is sleepable.
The original fix by Mathieu Desnoyers .

Signed-off-by: Pekka Paalanen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman