linux.git/arch/x86/kernel, branch v2.6.28

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

Merge branch 'iommu-fixes-2.6.28' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu into x86/urgent

2008-12-18T12:28:11+00:00

x86 gart: don't complain if no AMD GART found

2008-12-18T12:26:23+00:00

Impact: remove annoying bootup printk

It's perfectly normal for no AMD GART to be present, e.g., if you have
Intel CPUs.  None of the other iommu_init() functions makes noise when
it finds nothing.

Signed-off-by: Bjorn Helgaas 
Acked-by: Joerg Roedel 
Signed-off-by: Ingo Molnar

AMD IOMMU: panic if completion wait loop fails

2008-12-17T15:36:44+00:00

Impact: prevents data corruption after a failed completion wait loop

Signed-off-by: Joerg Roedel

AMD IOMMU: set cmd buffer pointers to zero manually

2008-12-17T14:06:01+00:00

Impact: set cmd buffer head and tail pointers to zero in case nobody else did

Signed-off-by: Joerg Roedel

x86: re-enable MCE on secondary CPUS after suspend/resume

2008-12-16T22:03:02+00:00

Impact: fix disabled MCE after resume

Don't prevent multiple initialization of MCEs.

Back from early prehistory mcheck_init() has a reentry check. Presumably
that was needed in very old kernels to prevent it entering twice.

But as Andreas points out this prevents CPU hotplug (and therefore resume)
to correctly reinitialize MCEs when a AP boots again after being
offlined.

Just drop the check.

Reported-by: Andreas Herrmann 
Signed-off-by: Andi Kleen 
Tested-by: Andreas Herrmann 
Signed-off-by: Ingo Molnar

AMD IOMMU: allocate rlookup_table with __GFP_ZERO

2008-12-16T18:17:11+00:00

Impact: fix bug which can lead to panic in prealloc_protection_domains()

Signed-off-by: Joerg Roedel

x86 Fix VMI crash on boot in 2.6.28-rc8

2008-12-15T00:24:38+00:00

VMI initialiation can relocate the fixmap, causing early_ioremap to
malfunction if it is initialized before the relocation.  To fix this,
VMI activation is split into two phases; the detection, which must
happen before setting up ioremap, and the activation, which must happen
after parsing early boot parameters.

This fixes a crash on boot when VMI is enabled under VMware.

Signed-off-by: Zachary Amsden 
Signed-off-by: Linus Torvalds

x86: fix default_spin_lock_flags() prototype

2008-12-08T15:08:29+00:00

these warnings:

  arch/x86/kernel/paravirt-spinlocks.c: In function ‘default_spin_lock_flags’:
  arch/x86/kernel/paravirt-spinlocks.c:12: warning: passing argument 1 of ‘__raw_spin_lock’ from incompatible pointer type
  arch/x86/kernel/paravirt-spinlocks.c: At top level:
  arch/x86/kernel/paravirt-spinlocks.c:11: warning: ‘default_spin_lock_flags’ defined but not used

showed that the prototype of default_spin_lock_flags() was confused about
what type spinlocks have.

the proper type on UP is raw_spinlock_t.

Signed-off-by: Ingo Molnar

AMD IOMMU: __unmap_single: check for bad_dma_address instead of 0

2008-12-08T13:58:55+00:00

Impact: minor fix

Signed-off-by: Joerg Roedel