linux-toradex.git/arch/x86/kernel, branch v2.6.33.9

x86: Cleanup highmap after brk is concluded

2011-03-28T14:31:23+00:00

commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream.

Now cleanup_highmap actually is in two steps: one is early in head64.c
and only clears above _end; a second one is in init_memory_mapping() and
tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently
does not.
Also init_memory_mapping() is called several times for numa or memory
hotplug, so we really should not handle initial kernel mappings there.

This patch moves cleanup_highmap() down after _brk_end is settled so
we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.

Signed-off-by: Yinghai Lu 
Signed-off-by: Stefano Stabellini 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, binutils, xen: Fix another wrong size directive

2011-03-28T14:31:18+00:00

commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.

The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
yet another time, under CONFIG_XEN=y due to a .size directive that
refers to a slightly differently named (hence, to the now very
strict and unforgiving assembler, non-existent) symbol.

[ mingo:

   This unnecessary build breakage caused by new binutils
   version 2.21 gets escallated back several kernel releases spanning
   several years of Linux history, affecting over 130,000 upstream
   kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
   affecting all major Linux distro kernel configs).

   Git annotate tells us that this slight debug symbol code mismatch
   bug has been introduced in 2008 in commit 3d75e1b8:

     3d75e1b8        (Jeremy Fitzhardinge    2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)

   The 'bug' is just a slight assymetry in ENTRY()/END()
   debug-symbols sequences, with lots of assembly code between the
   ENTRY() and the END():

     ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
       ...
     END(do_hypervisor_callback)

   Human reviewers almost never catch such small mismatches, and binutils
   never even warned about it either.

   This new binutils version thus breaks the Xen build on all upstream kernels
   since v2.6.27, out of the blue.

   This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
   impossible on such binutils, for a bisection window of over hundred
   thousand historic commits. (!)

   This is a major fail on the side of binutils and binutils needs to turn
   this show-stopper build failure into a warning ASAP. ]

Signed-off-by: Alexander van Heukelum 
Cc: Jeremy Fitzhardinge 
Cc: Jan Beulich 
Cc: H.J. Lu 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: "H. Peter Anvin" 
Cc: Kees Cook 
LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, quirk: Fix SB600 revision check

2011-03-21T19:45:39+00:00

commit 1d3e09a304e6c4e004ca06356578b171e8735d3c upstream.

Commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12
(x86 quirk: Fix polarity for IRQ0 pin2 override on SB800
systems) introduced a regression. It removed some SB600 specific
code to determine the revision ID without adapting a
corresponding revision ID check for SB600.

See this mail thread:

  http://marc.info/?l=linux-kernel&m=129980296006380&w=2

This patch adapts the corresponding check to cover all SB600
revisions.

Tested-by: Wang Lei 
Signed-off-by: Andreas Herrmann 
Cc: Andrew Morton 
LKML-Reference: <20110315143137.GD29499@alberich.amd.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: Emit "mem=nopentium ignored" warning when not supported

2011-03-21T19:45:38+00:00

commit 9a6d44b9adb777ca9549e88cd55bd8f2673c52a2 upstream.

Emit warning when "mem=nopentium" is specified on any arch other
than x86_32 (the only that arch supports it).

Signed-off-by: Kamal Mostafa 
BugLink: http://bugs.launchpad.net/bugs/553464
Cc: Yinghai Lu 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
LKML-Reference: <1296783486-23033-2-git-send-email-kamal@canonical.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: Fix panic when handling "mem={invalid}" param

2011-03-21T19:45:38+00:00

commit 77eed821accf5dd962b1f13bed0680e217e49112 upstream.

Avoid removing all of memory and panicing when "mem={invalid}"
is specified, e.g. mem=blahblah, mem=0, or mem=nopentium (on
platforms other than x86_32).

Signed-off-by: Kamal Mostafa 
BugLink: http://bugs.launchpad.net/bugs/553464
Cc: Yinghai Lu 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
LKML-Reference: <1296783486-23033-1-git-send-email-kamal@canonical.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems

2011-03-21T19:45:20+00:00

commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 upstream.

On some SB800 systems polarity for IOAPIC pin2 is wrongly
specified as low active by BIOS. This caused system hangs after
resume from S3 when HPET was used in one-shot mode on such
systems because a timer interrupt was missed (HPET signal is
high active).

For more details see:

  http://marc.info/?l=linux-kernel&m=129623757413868

Tested-by: Manoj Iyer 
Tested-by: Andre Przywara 
Signed-off-by: Andreas Herrmann 
Cc: Borislav Petkov 
LKML-Reference: <20110224145346.GD3658@alberich.amd.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/pvclock: Zero last_value on resume

2011-03-21T19:45:05+00:00

commit e7a3481c0246c8e45e79c629efd63b168e91fcda upstream.

If the guest domain has been suspend/resumed or migrated, then the
system clock backing the pvclock clocksource may revert to a smaller
value (ie, can be non-monotonic across the migration/save-restore).

Make sure we zero last_value in that case so that the domain
continues to see clock updates.

Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, mtrr: Avoid MTRR reprogramming on BP during boot on UP platforms

2011-03-21T19:44:55+00:00

commit f7448548a9f32db38f243ccd4271617758ddfe2c upstream.

Markus Kohn ran into a hard hang regression on an acer aspire
1310, when acpi is enabled. git bisect showed the following
commit as the bad one that introduced the boot regression.

	commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3
	Author: Suresh Siddha 
	Date:   Wed Aug 19 18:05:36 2009 -0700

	    x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init

Because of the UP configuration of that platform,
native_smp_prepare_cpus() bailed out (in smp_sanity_check())
before doing the set_mtrr_aps_delayed_init()

Further down the boot path, native_smp_cpus_done() will call the
delayed MTRR initialization for the AP's (mtrr_aps_init()) with
mtrr_aps_delayed_init not set. This resulted in the boot
processor reprogramming its MTRR's to the values seen during the
start of the OS boot. While this is not needed ideally, this
shouldn't have caused any side-effects. This is because the
reprogramming of MTRR's (set_mtrr_state() that gets called via
set_mtrr()) will check if the live register contents are
different from what is being asked to write and will do the actual
write only if they are different.

BP's mtrr state is read during the start of the OS boot and
typically nothing would have changed when we ask to reprogram it
on BP again because of the above scenario on an UP platform. So
on a normal UP platform no reprogramming of BP MTRR MSR's
happens and all is well.

However, on this platform, bios seems to be modifying the fixed
mtrr range registers between the start of OS boot and when we
double check the live registers for reprogramming BP MTRR
registers. And as the live registers are modified, we end up
reprogramming the MTRR's to the state seen during the start of
the OS boot.

During ACPI initialization, something in the bios (probably smi
handler?) don't like this fact and results in a hard lockup.

We didn't see this boot hang issue on this platform before the
commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3, because only
the AP's (if any) will program its MTRR's to the value that BP
had at the start of the OS boot.

Fix this issue by checking mtrr_aps_delayed_init before
continuing further in the mtrr_aps_init(). Now, only AP's (if
any) will program its MTRR's to the BP values during boot.

Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393

  [ By the way, this behavior of the bios modifying MTRR's after the start
    of the OS boot is not common and the kernel is not prepared to
    handle this situation well. Irrespective of this issue, during
    suspend/resume, linux kernel will try to reprogram the BP's MTRR values
    to the values seen during the start of the OS boot. So suspend/resume might
    be already broken on this platform for all linux kernel versions. ]

Reported-and-bisected-by: Markus Kohn 
Tested-by: Markus Kohn 
Signed-off-by: Suresh Siddha 
Cc: Thomas Renninger 
Cc: Rafael Wysocki 
Cc: Venkatesh Pallipadi 
LKML-Reference: <1296694975.4418.402.camel@sbsiddha-MOBL3.sc.intel.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode

2011-03-21T19:44:28+00:00

commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream.

In x2apic mode, we need to set the upper address register of the fault
handling interrupt register of the vt-d hardware. Without this
irq migration of the vt-d fault handling interrupt is broken.

Signed-off-by: Kenji Kaneshige 
LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3>
Signed-off-by: Suresh Siddha 
Acked-by: Chris Wright 
Tested-by: Takao Indoh 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: Enable the intr-remap fault handling after local APIC setup

2011-03-21T19:44:28+00:00

commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream.

Interrupt-remapping gets enabled very early in the boot, as it determines the
apic mode that the processor can use. And the current code enables the vt-d
fault handling before the setup_local_APIC(). And hence the APIC LDR registers
and data structure in the memory may not be initialized. So the vt-d fault
handling in logical xapic/x2apic modes were broken.

Fix this by enabling the vt-d fault handling in the end_local_APIC_setup()

A cleaner fix of enabling fault handling while enabling intr-remapping
will be addressed for v2.6.38. [ Enabling intr-remapping determines the
usage of x2apic mode and the apic mode determines the fault-handling
configuration. ]

Signed-off-by: Kenji Kaneshige 
LKML-Reference: <20101201062244.541996375@intel.com>
Signed-off-by: Suresh Siddha 
Acked-by: Chris Wright 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman