Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 03 1月, 2007 4 次提交
  3. 31 12月, 2006 2 次提交
  5. 30 12月, 2006 1 次提交
    • R
      [CPUFREQ] Longhaul - Fix up powersaver assumptions. · 264166e6
      由 Rafa Bilski 提交于 
      ACPI PM2 register was fallback for "Longhaul ver. 1" CPU's.
My assumption that this register isn't present at
"PowerSaver" motherboards is so far true, but current code
will not work correctly in other case. There are three possible
supports: ACPI C3, PM2 and northbridge. That was my assumption
that ACPI C3 and northbridge is for PS and northbridge and PM2
is for V1. In current code we can only check if it is ACPI
support or not by port22_en. So remove port22_en and add
longhaul_flags. If USE_ACPI_C3 and USE_NORTHBRIDGE are both
clear then it means ACPI PM2 support. Also change order of
support probe from ACPI C3, PM2, northbridge to ACPI C3,
northbridge, ACPI PM2. Paranoid protection against port 0x22
cast as ACPI PM2 register. Bit 1 clear in such case - lockup
on AGP DMA. And obvious (now) fixup for do_powersaver. Use
cx->address only for ACPI C3 ("PowerSaver" processor using
PM2 support).
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>
      264166e6
  7. 29 12月, 2006 1 次提交
  9. 24 12月, 2006 1 次提交
    • O
      [PATCH] arch/i386/pci/mmconfig.c tlb flush fix · 8d1c4819
      由 OGAWA Hirofumi 提交于 
      We use the fixmap for accessing pci config space in pci_mmcfg_read/write().
The problem is in pci_exp_set_dev_base(). It is caching a last
accessed address to avoid calling set_fixmap_nocache() whenever
pci_mmcfg_read/write() is used.

  static inline void pci_exp_set_dev_base(int bus, int devfn)
  {
	u32 dev_base = base | (bus << 20) | (devfn << 12);
	if (dev_base != mmcfg_last_accessed_device) {
		mmcfg_last_accessed_device = dev_base;
		set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
	}
  }

            cpu0                                        cpu1
  ---------------------------------------------------------------------------
    pci_mmcfg_read("device-A")
        pci_exp_set_dev_base()
            set_fixmap_nocache()
                                              pci_mmcfg_read("device-B")
                                                  pci_exp_set_dev_base()
                                                      set_fixmap_nocache()
    pci_mmcfg_read("device-B")
        pci_exp_set_dev_base()
            /* doesn't flush tlb */

But if cpus accessed the above order, the second pci_mmcfg_read() on
cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is
device-B.  So, second pci_mmcfg_read() on cpu0 accesses a device-A via
a previous TLB cache. This problem became the cause of several strange
behavior.

This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check.

[ Alternatively, we could make a per-cpu mapping area or something. Not
  that it's probably worth it, but if we wanted to avoid all locking and
  instead just disable preemption, that would be the way to go. --Linus ]
Signed-off-by: NOGAWA Hirofumi <hogawa@miraclelinux.com>
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d1c4819
  11. 23 12月, 2006 7 次提交
    • B
      [CPUFREQ] speedstep-centrino: missing space and bracket · d349c4a5
      由 Brice Goglin 提交于 
      A space and a bracket are missing (and indentation is wrong).
Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
Signed-off-by: NDave Jones <davej@redhat.com>
      d349c4a5
    • V
      [CPUFREQ] Bug fix for acpi-cpufreq and cpufreq_stats oops on frequency change notification · 8edc59d9
      由 Venkatesh Pallipadi 提交于 
      Fixes the oops in cpufreq_stats with acpi_cpufreq driver.  The issue was
that the frequency was reported as 0 in acpi-cpufreq.c.  The bug is due to
different indicies for freq_table and ACPI perf table.

Also adds a check in cpufreq_stats to check for error return from
freq_table_get_index() and avoid using the error return value.

Patch fixes the issue reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0629.html
and also other similar issue here
http://bugme.osdl.org/show_bug.cgi?id=7383 comment 53
Signed-off-by: NDhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDave Jones <davej@redhat.com>
      8edc59d9
    • I
      [PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code · 0888f06a
      由 Ingo Molnar 提交于 
      Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
xruns starting at the 2.6.18-rt kernel, and those problems persisted all
until current -rt kernels. The latencies were serious and unjustified by
system load, often in the milliseconds range.

After a patient and heroic multi-month effort of Fernando, where he
tested dozens of kernels, tried various configs, boot options,
test-patches of mine and provided latency traces of those incidents, the
following 'smoking gun' trace was captured by him:

                 _------=> CPU#
                / _-----=> irqs-off
               | / _----=> need-resched
               || / _---=> hardirq/softirq
               ||| / _--=> preempt-depth
               |||| /
               |||||     delay
   cmd     pid ||||| time  |   caller
      \   /    |||||   \   |   /
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup <<...>-5856> (37 0)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (c01262ba 0 0)
  IRQ_19-1479  1D..1    0us : resched_task (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __spin_unlock_irqrestore (try_to_wake_up)
  ...
  <idle>-0     1...1   11us!: default_idle (cpu_idle)
  ...
  <idle>-0     0Dn.1  602us : smp_apic_timer_interrupt (c0103baf 1 0)
  ...
   <...>-5856  0D..2  618us : __switch_to (__schedule)
   <...>-5856  0D..2  618us : __schedule <<idle>-0> (20 162)
   <...>-5856  0D..2  619us : __spin_unlock_irq (__schedule)
   <...>-5856  0...1  619us : trace_stop_sched_switched (__schedule)
   <...>-5856  0D..1  619us : trace_stop_sched_switched <<...>-5856> (37 0)

what is visible in this trace is that CPU#1 ran try_to_wake_up() for
PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
for CPU#0. But it decided to not send an IPI that no CPU - due to
TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
result was a 600+ usecs latency and a missed wakeup!

the bug turned out to be an idle-wakeup bug introduced into the mainline
kernel this summer via an optimization in the x86_64 tree:

    commit 495ab9c0
    Author: Andi Kleen <ak@suse.de>
    Date:   Mon Jun 26 13:59:11 2006 +0200

    [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status

    During some profiling I noticed that default_idle causes a lot of
    memory traffic. I think that is caused by the atomic operations
    to clear/set the polling flag in thread_info. There is actually
    no reason to make this atomic - only the idle thread does it
    to itself, other CPUs only read it. So I moved it into ti->status.

the problem is this type of change:

        if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
-               clear_thread_flag(TIF_POLLING_NRFLAG);
+               current_thread_info()->status &= ~TS_POLLING;
                smp_mb__after_clear_bit();
                while (!need_resched()) {
                        local_irq_disable();

this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
clear_thread_flag() is defined as:

        clear_bit(flag, &ti->flags);

and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:

  static inline void clear_bit(int nr, volatile unsigned long * addr)
  {
          __asm__ __volatile__( LOCK_PREFIX
                  "btrl %1,%0"

hence smp_mb__after_clear_bit() is defined as a simple compile barrier:

  #define smp_mb__after_clear_bit()       barrier()

but the explicit TS_POLLING clearing introduced by the patch:

+               current_thread_info()->status &= ~TS_POLLING;

is not an atomic op! So the clearing of the TS_POLLING bit is freely
reorderable with the reading of the NEED_RESCHED bit - and both now
reside in different memory addresses.

CPU idle wakeup very much depends on ordered memory ops, the clearing of
the TS_POLLING flag must always be done before we test need_resched()
and hit the idle instruction(s). [Symmetrically, the wakeup code needs
to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
ordering is paramount.]

Fernando's dual-core Athlon64 system has a sufficiently advanced memory
ordering model so that it triggered this scenario very often.

( And it also turned out that the reason why these latencies never
  triggered on my testsystems is that i routinely use idle=poll, which
  was the only idle variant not affected by this bug. )

The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
act as an absolute barrier between the TS_POLLING write and the
NEED_RESCHED read. This affects almost all idling methods (default,
ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Tested-by: NFernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0888f06a
    • J
      [PATCH] ptrace: Fix EFL_OFFSET value according to i386 pda changes · 8701ea95
      由 Jeremy Fitzhardinge 提交于 
      The PDA patches introduced a bug in ptrace: it reads eflags from the wrong
place on the target's stack, but writes it back to the correct place.  The
result is a corrupted eflags, which is most visible when it turns interrupts
off unexpectedly.

This patch fixes this by making the ptrace code a little less fragile.  It
changes [gs]et_stack_long to take a straightforward byte offset into struct
pt_regs, rather than requiring all callers to do a sizeof(struct pt_regs)
offset adjustment.  This means that the eflag's offset (EFL_OFFSET) on the
target stack can be simply computed with offsetof().
Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
Cc: Frederik Deweerdt <deweerdt@free.fr>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8701ea95
    • Y
      [PATCH] memory hotplug: fix compile error for i386 with NUMA config · 7c7e9425
      由 Yasunori Goto 提交于 
      Fix compile error when config memory hotplug with numa on i386.

The cause of compile error was missing of arch_add_memory(),
remove_memory(), and memory_add_physaddr_to_nid().
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Acked-by: NDavid Rientjes <rientjes@cs.washington.edu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7c7e9425
    • J
      [PATCH] microcode: fix mc_cpu_notifier section warning · be31f9cb
      由 Jean Delvare 提交于 
      Structure mc_cpu_notifier references a __cpuinit function, but isn't
declared __cpuinitdata itself:

WARNING: arch/i386/kernel/microcode.o - Section mismatch: reference
to .init.text: from .data after 'mc_cpu_notifier' (at offset 0x118)
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      be31f9cb
    • Y
      [PATCH] compile error of register_memory() · 5c95da9f
      由 Yasunori Goto 提交于 
      register_memory() becomes double definition in 2.6.20-rc1.  It is defined
in arch/i386/kernel/setup.c as static definition in 2.6.19.  But it is
moved to arch/i386/kernel/e820.c in 2.6.20-rc1.  And same name function is
defined in driver/base/memory.c too.  So, it becomes cause of compile error
of duplicate definition if memory hotplug option is on.
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5c95da9f
  13. 21 12月, 2006 1 次提交
    • A
      PCI: Fix multiple problems with VIA hardware · 1597cacb
      由 Alan Cox 提交于 
      This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM

The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.

The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.

From: Jean Delvare <khali@linux-fr.org>

Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.

[akpm@osdl.org: fix const warning]
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1597cacb
  15. 18 12月, 2006 3 次提交
  17. 16 12月, 2006 2 次提交
  19. 14 12月, 2006 4 次提交
  21. 13 12月, 2006 6 次提交
  23. 10 12月, 2006 7 次提交
    • R
      [PATCH] x86-64: no paravirt for X86_VOYAGER or X86_VISWS · f0f32fcc
      由 Randy Dunlap 提交于 
      Since Voyager and Visual WS already define ARCH_SETUP,
it looks like PARAVIRT shouldn't be offered for them.

In file included from arch/i386/kernel/setup.c:63:
include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefin=
ed
In file included from include/asm/msr.h:5,
                 from include/asm/processor.h:17,
                 from include/asm/thread_info.h:16,
                 from include/linux/thread_info.h:21,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:49,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:46,
                 from arch/i386/kernel/setup.c:26:
include/asm/paravirt.h:163:1: warning: this is the location of the previous=
 definition
In file included from arch/i386/kernel/setup.c:63:
include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefin=
ed
In file included from include/asm/msr.h:5,
                 from include/asm/processor.h:17,
                 from include/asm/thread_info.h:16,
                 from include/linux/thread_info.h:21,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:49,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:46,
                 from arch/i386/kernel/setup.c:26:
include/asm/paravirt.h:163:1: warning: this is the location of the previous=
 definition
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      f0f32fcc
    • A
      [PATCH] i386: Fix io_apic.c warning · 306a22c2
      由 Andi Kleen 提交于 
      gcc 4.2 warns

linux/arch/i386/kernel/io_apic.c: In function ‘create_irq’:
linux/arch/i386/kernel/io_apic.c:2488: warning: ‘vector’ may be used uninitialized in this function

The warning is false, but somewhat legitimate so work around it.
Signed-off-by: NAndi Kleen <ak@suse.de>
      306a22c2
    • R
      [PATCH] i386: export smp_num_siblings for oprofile · 7e74437c
      由 Randy Dunlap 提交于 
      oprofile uses smp_num_siblings without testing for CONFIG_X86_HT.
I looked at modifying oprofile, but this way is cleaner & simpler
and I didn't see a good reason not to just export it when CONFIG_SMP.

WARNING: "smp_num_siblings" [arch/i386/oprofile/oprofile.ko] undefined!
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      7e74437c
    • A
      [PATCH] x86: Work around gcc 4.2 over aggressive optimizer · 1bac3b38
      由 Andi Kleen 提交于 
      The new PDA code uses a dummy _proxy_pda variable to describe
memory references to the PDA. It is never referenced
in inline assembly, but exists as input/output arguments.
gcc 4.2 in some cases can CSE references to this which causes
unresolved symbols.  Define it to zero to avoid this.
Signed-off-by: NAndi Kleen <ak@suse.de>
      1bac3b38
    • 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
    • A
      [PATCH] x86: Fix verify_quirk_intel_irqbalance() · 16d279d2
      由 Andi Kleen 提交于 
      Fix verify_quirk_intel_irqbalance(). genapic checks should really
happen only on affected versions of the E7520/E7320/E7525 based platforms.

AK: This should akpm's Coyote SDV
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      16d279d2
    • A
      [PATCH] i386: Update defconfig · e0f27981
      由 Andi Kleen 提交于 
      Signed-off-by: NAndi Kleen <ak@suse.de>
      e0f27981
  25. 09 12月, 2006 1 次提交