Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 2月, 2008 1 次提交
  3. 30 1月, 2008 2 次提交
  5. 25 1月, 2008 1 次提交
  7. 05 12月, 2007 1 次提交
  9. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      由 Dave Jones 提交于 
      Since the x86 merge, lots of files that referenced their own filenames
are no longer correct.  Rather than keep them up to date, just delete
them, as they add no real value.

Additionally:
- fix up comment formatting in scx200_32.c
- Remove a credit from myself in setup_64.c from a time when we had no SCM
- remove longwinded history from tsc_32.c which can be figured out from
  git.
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  11. 13 10月, 2007 1 次提交
    • T
      x86: Fix irq0 / local apic timer accounting · 4e77ae3e
      由 Thomas Gleixner 提交于 
      The clock events merge introduced a change to the nmi watchdog code to
handle the not longer increasing local apic timer count in the
broadcast mode. This is fine for UP, but on SMP it pampers over a
stuck CPU which is not handling the broadcast interrupt due to the
unconditional sum up of local apic timer count and irq0 count.

To cover all cases we need to keep track on which CPU irq0 is
handled. In theory this is CPU#0 due to the explicit disabling of irq
balancing for irq0, but there are systems which ignore this on the
hardware level. The per cpu irq0 accounting allows us to remove the
irq0 to CPU0 binding as well.

Add a per cpu counter for irq0 and evaluate this instead of the global
irq0 count in the nmi watchdog code.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      4e77ae3e
  13. 11 10月, 2007 2 次提交
  15. 19 8月, 2007 1 次提交
  17. 23 7月, 2007 1 次提交
  19. 18 7月, 2007 1 次提交
  21. 09 5月, 2007 1 次提交
    • C
      move die notifier handling to common code · 1eeb66a1
      由 Christoph Hellwig 提交于 
      This patch moves the die notifier handling to common code.  Previous
various architectures had exactly the same code for it.  Note that the new
code is compiled unconditionally, this should be understood as an appel to
the other architecture maintainer to implement support for it aswell (aka
sprinkling a notify_die or two in the proper place)

arm had a notifiy_die that did something totally different, I renamed it to
arm_notify_die as part of the patch and made it static to the file it's
declared and used at.  avr32 used to pass slightly less information through
this interface and I brought it into line with the other architectures.

[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix vmalloc_sync_all bustage]
[bryan.wu@analog.com: fix vmalloc_sync_all in nommu]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: <linux-arch@vger.kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NBryan Wu <bryan.wu@analog.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eeb66a1
  23. 03 5月, 2007 2 次提交
    • A
      [PATCH] x86-64: Use the 32bit wd_ops for 64bit too. · 05cb007d
      由 Andi Kleen 提交于 
      This mainly removes a lot of code, replacing it with calls into the new 32bit
perfctr-watchdog.c
Signed-off-by: NAndi Kleen <ak@suse.de>
      05cb007d
    • S
      [PATCH] x86-64: x86_64 make NMI use PERFCTR1 for architectural perfmon (take 2) · 405e494d
      由 Stephane Eranian 提交于 
      Hello,

This patch against 2.6.20-git14 makes the NMI watchdog use PERFSEL1/PERFCTR1
instead of PERFSEL0/PERFCTR0 on processors supporting Intel architectural
perfmon, such as Intel Core 2. Although all PMU events can work on
both counters, the Precise Event-Based Sampling (PEBS) requires that the
event be in PERFCTR0 to work correctly (see section 18.14.4.1 in the
IA32 SDM Vol 3b). This versions has 3 chunks compared to previous where
we had missed on check.

Changelog:
        - make the x86-64 NMI watchdog use PERFSEL1/PERFCTR1 instead of PERFSEL0/PERFCTR0
          on processors supporting the Intel architectural perfmon (e.g. Core 2 Duo).
          This allows PEBS to work when the NMI watchdog is active.
signed-off-by: Nstephane eranian <eranian@hpl.hp.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      405e494d
  25. 16 4月, 2007 1 次提交
  27. 02 4月, 2007 2 次提交
  29. 15 3月, 2007 1 次提交
  31. 13 2月, 2007 3 次提交
    • A
      [PATCH] x86: Enable NMI watchdog for AMD Family 0x10 CPUs · 0a4599c8
      由 Andi Kleen 提交于 
      For i386/x86-64.

Straight forward -- just reuse the Family 0xf code.
Signed-off-by: NAndi Kleen <ak@suse.de>
      0a4599c8
    • I
      [PATCH] x86: fix laptop bootup hang in init_acpi() · 5d0e600d
      由 Ingo Molnar 提交于 
      During kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about
10%-20% of the time in acpi_init():

 Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
 Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c()
 Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175()
 Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17()
 Calling initcall 0xc0569f99: init_bio+0x0/0xf4()
 Calling initcall 0xc056b865: genhd_device_init+0x0/0x50()
 Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87()
 Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee()

It's a hard hang that not even an NMI could punch through!  Frustratingly,
adding printks or function tracing to the ACPI code made the hangs go away
...

After some time an additional detail emerged: disabling the NMI watchdog
made these occasional hangs go away.

So i spent the better part of today trying to debug this and trying out
various theories when i finally found the likely reason for the hang: if
acpi_ns_initialize_devices() executes an _INI AML method and an NMI
happens to hit that AML execution in the wrong moment, the machine would
hang.  (my theory is that this must be some sort of chipset setup method
doing stores to chipset mmio registers?)

Unfortunately given the characteristics of the hang it was sheer
impossible to figure out which of the numerous AML methods is impacted
by this problem.

As a workaround i wrote an interface to disable chipset-based NMIs while
executing _INI sections - and indeed this fixed the hang.  I did a
boot-loop of 100 separate reboots and none hung - while without the patch
it would hang every 5-10 attempts.  Out of caution i did not touch the
nmi_watchdog=2 case (it's not related to the chipset anyway and didnt
hang).

I implemented this for both x86_64 and i686, tested the i686 laptop both
with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and
tested an Athlon64 box with the 64-bit kernel as well. Everything builds
and works with the patch applied.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      5d0e600d
    • V
      [PATCH] x86-64: Handle 32 bit PerfMon Counter writes cleanly in x86_64 nmi_watchdog · 16761939
      由 Venkatesh Pallipadi 提交于 
      P6 CPUs and Core/Core 2 CPUs which has 'architectural perf mon' feature,
only supports write of low 32 bits in Performance Monitoring Counters.
Bits 32..39 are sign extended based on bit 31 and bits 40..63 are reserved
and should be zero.

This patch:

Change x86_64 nmi handler to handle this case cleanly.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      16761939
  33. 23 1月, 2007 1 次提交
  35. 10 12月, 2006 1 次提交
    • R
      [PATCH] x86: Fix boot hang due to nmi watchdog init code · 92715e28
      由 Ravikiran G Thirumalai 提交于 
      2.6.19  stopped booting (or booted based on build/config) on our x86_64
systems due to a bug introduced in 2.6.19.  check_nmi_watchdog schedules an
IPI on all cpus to  busy wait on a flag, but fails to set the busywait
flag if NMI functionality is disabled.  This causes the secondary cpus
to spin in an endless loop, causing the kernel bootup to hang.
Depending upon the build, the  busywait flag got overwritten (stack variable)
and caused  the kernel to bootup on certain builds.  Following patch fixes
the bug by setting the busywait flag before returning from check_nmi_watchdog.
I guess using a stack variable is not good here as the calling function could
potentially return while the busy wait loop is still spinning on the flag.

AK: I redid the patch significantly to be cleaner
Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: NShai Fultheim <shai@scalex86.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
      92715e28
  37. 07 12月, 2006 1 次提交
  39. 30 9月, 2006 1 次提交
  41. 26 9月, 2006 10 次提交
  43. 04 7月, 2006 1 次提交
  45. 01 7月, 2006 1 次提交
  47. 29 6月, 2006 1 次提交
  49. 27 6月, 2006 1 次提交