Skip to content

L
linux-davinci
Switch branch/tag
  1. 24 Dec, 2008 1 commit
    • Ingo Molnar's avatar
      x86: disable X86_PTRACE_BTS · 40f15ad8
      Ingo Molnar authored 
      there's a new ptrace arch level feature in .28:

  config X86_PTRACE_BTS
  bool "Branch Trace Store"

it has broken fork() handling: the old DS area gets copied over into
a new task without clearing it.

Fixes exist but they came too late:

  c5dee617: x86, bts: memory accounting
  bf53de90: x86, bts: add fork and exit handling

and are queued up for v2.6.29. This shows that the facility is still not
tested well enough to release into a stable kernel - disable it for now and
reactivate in .29. In .29 the hardware-branch-tracer will use the DS/BTS
facilities too - hopefully resulting in better code.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      40f15ad8
  3. 20 Dec, 2008 1 commit
    • Dmitry Adamushko's avatar
      x86: fix resume (S2R) broken by Intel microcode module, on A110L · 280a9ca5
      Dmitry Adamushko authored 
      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 <andi@lisas.de>
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko <dmitry.adamushko@gmail.com>

[ 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: default avatarAndreas Mohr <andi@lisas.de>
Signed-off-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
Tested-by: default avatarAndreas Mohr <andi@lisas.de>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      280a9ca5
  5. 18 Dec, 2008 2 commits
  7. 17 Dec, 2008 2 commits
  9. 16 Dec, 2008 23 commits
  11. 15 Dec, 2008 8 commits
  13. 14 Dec, 2008 3 commits