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

x86: microcode_amd: fix wrong handling of equivalent CPU id

2009-02-17T17:29:05+00:00

commit 3c763fd77e66e55d029052da31df0abd9920cb1e upstream.

Impact: fix bug resulting in non-loaded AMD microcode

mc_header->processor_rev_id is a 2 byte value. Similar is true for
equiv_cpu in an equiv_cpu_entry -- only 2 bytes are of interest.

Signed-off-by: Andreas Herrmann 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, vmi: put a missing paravirt_release_pmd in pgd_dtor

2009-02-17T17:28:43+00:00

commit 55a8ba4b7f76bebd7e8ce3f74c04b140627a1bad upstream.

Commit 6194ba6ff6ccf8d5c54c857600843c67aa82c407 ("x86: don't special-case
pmd allocations as much") made changes to the way we handle pmd allocations,
and while doing that it dropped a call to  paravirt_release_pd on the
pgd page from the pgd_dtor code path.

As a result of this missing release, the hypervisor is now unaware of the
pgd page being freed, and as a result it ends up tracking this page as a
page table page.

After this the guest may start using the same page for other purposes, and
depending on what use the page is put to, it may result in various performance
and/or functional issues ( hangs, reboots).

Since this release is only required for VMI, I now release the pgd page from
the (vmi)_pgd_free hook.

Signed-off-by: Alok N Kataria 
Acked-by: Jeremy Fitzhardinge 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: APIC: enable workaround on AMD Fam10h CPUs

2009-02-12T17:50:27+00:00

commit 858770619debfb9269add63e4ba8b7c6b5538dd1 upstream.

Impact: fix to enable APIC for AMD Fam10h on chipsets with a missing/b0rked
	ACPI MP table (MADT)

Booting a 32bit kernel on an AMD Fam10h CPU running on chipsets with
missing/b0rked MP table leads to a hang pretty early in the boot process
due to the APIC not being initialized. Fix that by falling back to the
default APIC base address in 32bit code, as it is done in the 64bit
codepath.

Signed-off-by: Borislav Petkov 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

ACPI: Avoid array address overflow when _CST MWAIT hint bits are set

2009-02-06T21:47:23+00:00

commit 13b40a1a065824d2d4e55c8b48ea9f3f9d162929 upstream.

The Cx Register address obtained from the _CST object is used as the MWAIT
hints if the register type is FFixedHW. And it is used to check whether
the Cx type is supported or not.

On some boxes the following Cx state package is obtained from _CST object:
    >{
                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x01,               // Bit Width
                        0x02,               // Bit Offset
                        0x0000000000889759, // Address
                        0x03,               // Access Size
                        )
                },

                0x03,
                0xF5,
                0x015E }

   In such case we should use the bit[7:4] of Cx address to check whether
the Cx type is supported or not.

mask the MWAIT hint to avoid array address overflow

Signed-off-by: Zhao Yakui 
Acked-by:Venki Pallipadi 
Signed-off-by: Len Brown 
Cc: Thomas Renninger

x86: fix RIP printout in early_idt_handler

2009-01-18T18:44:02+00:00

commit 7aed55d1085f71241284a30af0300feea48c36db upstream.

Impact: fix debug/crash printout

Since errorcode is popped out, RIP is on the top of the stack.
Use real RIP value instead of wrong CS.

Signed-off-by: Jiri Slaby 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Rename old_readdir to sys_old_readdir

2009-01-18T18:43:51+00:00

commit e55380edf68796d75bf41391a781c68ee678587d upstream.

This way it matches the generic system call name convention.

Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

x86: fix incorrect __read_mostly on _boot_cpu_pda

2009-01-18T18:43:46+00:00

commit 26799a63110dcbe81291ea53178f6b4810d07424 upstream.

The pda rework (commit 3461b0af025251bbc6b3d56c821c6ac2de6f7209)
to remove static boot cpu pdas introduced a performance bug.

_boot_cpu_pda is the actual pda used by the boot cpu and is definitely
not "__read_mostly" and ended up polluting the read mostly section with
writes.  This bug caused regression of about 8-10% on certain syscall
intensive workloads.

Signed-off-by: Ravikiran Thirumalai 
Acked-by: Mike Travis 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, UV: remove erroneous BAU initialization

2009-01-18T18:43:45+00:00

commit 46814dded1b972a07b1609d81632eef3009fbb10 upstream.

Impact: fix crash on x86/UV

UV is the SGI "UltraViolet" machine, which is x86_64 based.
BAU is the "Broadcast Assist Unit", used for TLB shootdown in UV.

This patch removes the allocation and initialization of an unused table.

This table is left over from a development test mode.  It is unused in
the present code.

And it was incorrectly initialized: 8 entries allocated but 17 initialized,
causing slab corruption.

This patch should go into 2.6.27 and 2.6.28 as well as the current tree.

Diffed against 2.6.28 (linux-next, 12/30/08)

Signed-off-by: Cliff Wickman 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix intel x86_64 llc_shared_map/cpu_llc_id anomolies

2009-01-18T18:43:44+00:00

commit 345077cd98ff5532b2d1158013c3fec7b1ae85ec upstream.

Impact: fix wrong cache sharing detection on platforms supporting > 8 bit apicid's

In the presence of extended topology eumeration leaf 0xb provided
by cpuid, 32bit extended initial_apicid in cpuinfo_x86 struct will be
updated by detect_extended_topology(). At this instance, we should also
reinit the apicid (which could also potentially be extended to 32bit).

With out this there will potentially be duplicate apicid's populated in the
per cpu's cpuinfo_x86 struct, resulting in wrong cache sharing topology etc
detected by init_intel_cacheinfo().

Reported-by: Dimitri Sivanich 
Signed-off-by: Suresh Siddha 
Acked-by: Dimitri Sivanich 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix resume (S2R) broken by Intel microcode module, on A110L

2008-12-20T13:29:20+00:00

Impact: fix deadlock

This is in response to the following bug report:

Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12100
Subject         : resume (S2R) broken by Intel microcode module, on A110L
Submitter       : Andreas Mohr 
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko 

[ The deadlock scenario has been discovered by Andreas Mohr ]

I think I might have a logical explanation why the system:

  (http://bugzilla.kernel.org/show_bug.cgi?id=12100)

might hang upon resuming, OTOH it should have likely hanged each and every time.

(1) possible deadlock in microcode_resume_cpu() if either 'if' section is
taken;

(2) now, I don't see it in spec. and can't experimentally verify it (newer
ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
be back to its original one (we need to reload ucode anyway so it doesn't seem
logical if a cpu doesn't drop the version)... if so, the comparison with
memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
the aforementioned 'if' sections might have been triggered - leading to a
deadlock.

Obviously, in my tests I simulated loading/resuming with the ucode of the same
version (just to see that the file is loaded/re-loaded upon resuming) so this
issue has never popped up.

I'd appreciate if someone with an appropriate system might give a try to the
2nd patch (titled "fix a comparison && deadlock...").

In any case, the deadlock situation is a must-have fix.

Reported-by: Andreas Mohr 
Signed-off-by: Dmitry Adamushko 
Tested-by: Andreas Mohr 
Signed-off-by: Ingo Molnar 
Cc: 

Signed-off-by: Ingo Molnar