linux-toradex.git/arch/x86_64/kernel, branch v2.6.17.3

[PATCH] Fix HPET operation on 64-bit NVIDIA platforms

2006-06-08T22:12:21+00:00

From: "Andy Currid" 

This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
that have HPET enabled.

When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
advertised as such in the ACPI APIC table - but an earlier workaround in the
kernel was ignoring this override.  The fix is to honor timer IRQ overrides
from ACPI when HPET is detected on an NVIDIA platform.

Signed-off-by: Andy Currid 
Cc: "Brown, Len" 
Cc: "Yu, Luming" 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Don't do syscall exit tracing twice

2006-05-31T03:31:06+00:00

int_ret_from_syscall already does syscall exit tracing, so
no need to do it again in the caller.

This caused problems for UML and some other special programs doing
syscall interception.

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Fix off by one in bad_addr checking in find_e820_area

2006-05-31T03:31:06+00:00

From: Robert Hentosh 

Actually, we just stumbled on a different bug found in find_e820_area() in
e820.c.  The following code does not handle the edge condition correctly:

   while (bad_addr(&addr, size) && addr+size < ei->addr + ei->size)
       ;
   last = addr + size;
   if ( last > ei->addr + ei->size )
       continue;

The second statement in the while loop needs to be a <= b so that it is the
logical negavite of the if (a > b) outside it. It needs to read:

   while (bad_addr(&addr, size) && addr+size <= ei->addr + ei->size)
       ;

In the case that failed bad_addr was returning an address that is exactly size
bellow the end of the e820 range.

AK: Again together with the earlier avoid edma fix this fixes
boot on a Dell PE6850/16GB

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Handle empty node zero

2006-05-31T03:31:06+00:00

From: Daniel Yeisley 

It is possible to boot a Unisys ES7000 with CPUs from multiple cells, and not
also include the memory from those cells.  This can create a scenario where
node 0 has cpus, but no associated memory.  The system will boot fine in a
configuration where node 0 has memory, but nodes 2 and 3 do not.

[AK: I rechecked the code and generic code seems to indeed handle that already.
Dan's original patch had a change for mm/slab.c that seems to be already in now.]

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: fix last_tsc calculation of PM timer

2006-05-31T03:31:05+00:00

From: "Jan Beulich" 

The PM timer code updates vxtime.last_tsc, but this update was done
incorrectly in two ways:
- offset_delay being in microseconds requires multiplying with cpu_mhz
  rather than cpu_khz
- the multiplication of offset_delay and cpu_khz (both being 32-bit
  values) on most current CPUs would overflow (observed value of the
  delay was approximately 4000us, yielding an overflow for frequencies
  starting a little above 1GHz)

Signed-off-by: Jan Beulich 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Fix no IOMMU warning in PCI-GART driver

2006-05-31T03:31:05+00:00

Complaining about the IOMMU not compiled in doesn't make sense
here because it is clearly compiled in.

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64

2006-05-21T19:59:21+00:00

Problem:

If we put a probe onto a callq instruction and the probe is executed,
kernel panic of Bad RIP value occurs.

Root cause:

If resume_execution() found 0xff at first byte of p->ainsn.insn, it must
check the _second_ byte.  But current resume_execution check _first_ byte
again.

I changed it checks second byte of p->ainsn.insn.

Kprobes on i386 don't have this problem, because the implementation is a
little bit different from x86_64.

Cc: Andi Kleen 
Signed-off-by: Satoshi Oshima 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Don't schedule on exception stack on preemptive kernels

2006-05-16T14:59:32+00:00

Extends an earlier patch from John Blackwood to more exception handlers
that also run on the exception stacks.

Expand the use of preempt_conditional_{sti,cli} to all cases where
interrupts are to be re-enabled during exception handling while running
on an IST stack.

Based on original patch from Jan Beulich.

Cc: John Blackwood 
Cc: jbeulich@novell.com
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Don't warn for overflow in nommu case when dma_mask is < 32bit

2006-05-16T14:59:31+00:00

This triggers for b44's 1GB DMA workaround which tries to map
first and then bounces.

The 32bit heuristic is reasonable because the IOMMU doesn't attempt
to handle < 32bit masks anyways.

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Avoid EBDA area in early boot allocator

2006-05-08T16:34:56+00:00

Based on analysis&patch from Robert Hentosch

Observed on a Dell PE6850 with 16GB

The problem occurs very early on, when the kernel allocates space for the
temporary memory map called bootmap. The bootmap overlaps the EBDA region.
EBDA region is not historically reserved in the e820 mapping. When the
bootmap is freed it marks the EBDA region as usable.

If you notice in setup.c there is already code to work around the EBDA
in reserve_ebda_region(), this check however occurs after the bootmap
is allocated and doesn't prevent the bootmap from using this range.

AK: I redid the original patch. Thanks also to Jan Beulich for
spotting some mistakes.

Cc: Robert_Hentosch@dell.com
Cc: jbeulich@novell.com
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds