Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 5月, 2007 25 次提交
  3. 26 4月, 2007 3 次提交
  5. 09 4月, 2007 1 次提交
  7. 02 4月, 2007 1 次提交
    • A
      [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E · 3556ddfa
      由 Andi Kleen 提交于 
      AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper.  But not all of these systems report support C2.

Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.

This supercedes an earlier workaround using DMI detection of specific systems.

Thanks to Mark Langsdorf for the detection snippet.
Signed-off-by: NAndi Kleen <ak@suse.de>
      3556ddfa
  9. 28 3月, 2007 1 次提交
  11. 24 3月, 2007 2 次提交
    • R
      [PATCH] i386: clear segment register padding in core dumps · 6ea65ff7
      由 Roland McGrath 提交于 
      The segment register slots in struct pt_regs are padded to 32 bits.
Some of these are stored with instructions like "pushl %es", which
leaves the high 16 bits as they were.  So the high bits of these
fields in struct pt_regs contain kernel stack garbage.  These bits are
ignored by everything and never leak to user space, except in core
dumps.  The user struct pt_regs is always at the base of the thread's
kernel stack and so it seems unlikely the information that leaks from
here is ever worthwhile so as to be a security concern, but I'm not
sure about that.  It has been this way for ages; userland consumers of
core dumps all mask off these high bits themselves.  So it is not urgent.

This change masks off the padding bits of the segment register slots
in core dumps.  ptrace already masks off these high bits, so this
makes the values in core dumps consistent with what ptrace would
report just before the process died.

As I read the processor manuals, the cs and ss values will always be
padded with zero bits rather than stack garbage.  But unlike "pushl %es",
this is not simple to test with a userland program.  So I added the two
instructions rather than wonder if they are really never necessary.

I think that x86_64 does not have this problem (for either 32-bit or
64-bit processes).  It only uses "mov" instructions from segment
registers, which zero-extend.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6ea65ff7
    • T
      [PATCH] i386: add command line option "local_apic_timer_c2_ok" · e585bef8
      由 Thomas Gleixner 提交于 
      It turned out that it is almost impossible to trust ACPI, BIOS & Co.
regarding the C states. This was the reason to switch the local apic
timer off in C2 state already. OTOH there are sane and well behaving
systems, which get punished by that decision.

Allow the user to confirm that the local apic timer is trustworthy in C2
state. This keeps the default behaviour on the safe side.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e585bef8
  13. 17 3月, 2007 1 次提交
  15. 15 3月, 2007 2 次提交
  17. 13 3月, 2007 1 次提交
  19. 07 3月, 2007 2 次提交
  21. 06 3月, 2007 1 次提交
    • I
      [PATCH] disable NMI watchdog by default · 6ebf622b
      由 Ingo Molnar 提交于 
      there's a new NMI watchdog related problem: KVM crashes on certain
bzImages because ... we enable the NMI watchdog by default (even if the
user does not ask for it) , and no other OS on this planet does that so
KVM doesnt have emulation for that yet. So KVM injects a #GP, which
crashes the Linux guest:

 general protection fault: 0000 [#1]
 PREEMPT SMP
 Modules linked in:
 CPU:    0
 EIP:    0060:[<c011a8ae>]    Not tainted VLI
 EFLAGS: 00000246   (2.6.20-rc5-rt0 #3)
 EIP is at setup_apic_nmi_watchdog+0x26d/0x3d3

and no, i did /not/ request an nmi_watchdog on the boot command line!

Solution: turn off that darn thing! It's a debug tool, not a 'make life
harder' tool!!

with this patch the KVM guest boots up just fine.

And with this my laptop (Lenovo T60) also stopped its sporadic hard
hanging (sometimes in acpi_init(), sometimes later during bootup,
sometimes much later during actual use) as well. It hung with both
nmi_watchdog=1 and nmi_watchdog=2, so it's generally the fact of NMI
injection that is causing problems, not the NMI watchdog variant, nor
any particular bootup code.

[ NMI breaks on some systems, esp in combination with SMM -Arjan ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6ebf622b