1. 07 12月, 2006 23 次提交
  2. 29 11月, 2006 3 次提交
  3. 21 11月, 2006 2 次提交
  4. 18 11月, 2006 2 次提交
    • I
      [PATCH] i386/x86_64: ACPI cpu_idle_wait() fix · dc1829a4
      Ingo Molnar 提交于
      The scheduler on Andreas Friedrich's hyperthreading system stopped
      working properly: the scheduler would never move tasks to another CPU!
      The lask known working kernel was 2.6.8.
      
      After a couple of attempts to corner the bug, the following smoking gun
      was found:
      
        BIOS reported wrong ACPI idfor the processor
        CPU#1: set_cpus_allowed(), swapper:1, 3 -> 2
         [<c0103bbe>] show_trace_log_lvl+0x34/0x4a
         [<c0103ceb>] show_trace+0x2c/0x2e
         [<c01045f8>] dump_stack+0x2b/0x2d
         [<c0116a77>] set_cpus_allowed+0x52/0xec
         [<c0101d86>] cpu_idle_wait+0x2e/0x100
         [<c0259c57>] acpi_processor_power_exit+0x45/0x58
         [<c0259752>] acpi_processor_remove+0x46/0xea
         [<c025c6fb>] acpi_start_single_object+0x47/0x54
         [<c025cee5>] acpi_bus_register_driver+0xa4/0xd3
         [<c04ab2d7>] acpi_processor_init+0x57/0x77
         [<c01004d7>] init+0x146/0x2fd
         [<c0103a87>] kernel_thread_helper+0x7/0x10
      
      a quick look at cpu_idle_wait() shows how broken that code is
      on i386: it changes the init task's affinity map but never
      restores it ...
      
      and because all userspace tasks get forked by init, they all
      inherited that single-CPU affinity mask. x86_64 cloned this
      bug too.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Andreas Friedrich <andreas.friedrich@fujitsu-siemens.com>
      Cc: Wolfgang Erig <Wolfgang.Erig@fujitsu-siemens.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dc1829a4
    • I
      [PATCH] x86_64: stack unwinder crash fix · 0796bdb7
      Ingo Molnar 提交于
      the new dwarf2 unwinder crashes while trying to dump the stack:
      
        Leftover inexact backtrace:
      
        Unable to handle kernel paging request at ffffffff82800000 RIP:
         [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        PGD 203027 PUD 205027 PMD 0
        Oops: 0000 [2] PREEMPT SMP
        CPU 0
        Modules linked in:
        Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
        RIP: 0010:[<ffffffff8026cf26>]  [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        RSP: 0000:ffff81003fb9d848  EFLAGS: 00010006
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffffffff805b3520 RDI: 0000000000000000
        RBP: ffffffff827ffff9 R08: ffffffff80aad000 R09: 0000000000000005
        R10: ffffffff80aae000 R11: ffffffff8037961b R12: ffff81003fb9d858
        R13: 0000000000000000 R14: ffffffff80598460 R15: ffffffff80ab1fc0
        FS:  0000000000000000(0000) GS:ffffffff806c4200(0000) knlGS:0000000000000000
        CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        CR2: ffffffff82800000 CR3: 0000000000201000 CR4: 00000000000006e0
      
      this crash happened because it did not sanitize the dwarf2 data it
      got, and got an unaligned stack pointer - which happily walked past
      the process stack (and eventually reached the end of kernel memory
      and pagefaulted there) due to this naive iteration condition:
      
              HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);
      
      note that i386 is alot more conservative when it comes to trusting
      stack pointers:
      
        static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
        {
               return  p > (void *)tinfo &&
                       p < (void *)tinfo + THREAD_SIZE - 3;
        }
      
      but the x86_64 code did not take this bit of i386 code.
      
      The fix is to align the stack pointer.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0796bdb7
  5. 17 11月, 2006 1 次提交
  6. 16 11月, 2006 1 次提交
    • E
      [PATCH] Use delayed disable mode of ioapic edge triggered interrupts · 45c99533
      Eric W. Biederman 提交于
      Komuro reports that ISA interrupts do not work after a disable_irq(),
      causing some PCMCIA drivers to not work, with messages like
      
      	eth0: Asix AX88190: io 0x300, irq 3, hw_addr xx:xx:xx:xx:xx:xx
      	eth0: found link beat
      	eth0: autonegotiation complete: 100baseT-FD selected
      	eth0: interrupt(s) dropped!
      	eth0: interrupt(s) dropped!
      	eth0: interrupt(s) dropped!
      	...
      
      Linus Torvalds <torvalds@osdl.org> said:
      
        "Now, edge-triggered interrupts are a _lot_ harder to mask, because the
         Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic
         _before_ the mask logic, so if a edge happens _while_ the device is
         masked, you'll never ever see the edge ever again (unmasking will not
         cause a new edge, so you simply lost the interrupt).
      
         So when you "mask" an edge-triggered IRQ, you can't really mask it at all,
         because if you did that, you'd lose it forever if the IRQ comes in while
         you masked it. Instead, we're supposed to leave it active, and set a flag,
         and IF the IRQ comes in, we just remember it, and mask it at that point
         instead, and then on unmasking, we have to replay it by sending a
         self-IPI."
      
      This trivial patch solves the problem.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Acked-by: NKomuro <komurojun-mbn@nifty.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      45c99533
  7. 14 11月, 2006 5 次提交
    • A
      [PATCH] x86-64: Fix race in exit_idle · 9446868b
      Andi Kleen 提交于
      When another interrupt happens in exit_idle the exit idle notifier
      could be called an incorrect number of times.
      
      Add a test_and_clear_bit_pda and use it handle the bit
      atomically against interrupts to avoid this.
      
      Pointed out by Stephane Eranian
      Signed-off-by: NAndi Kleen <ak@suse.de>
      9446868b
    • A
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen 提交于
      The vgetcpu per CPU initialization previously relied on CPU hotplug
      events for all CPUs to initialize the per CPU state. That only
      worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
      others some CPUs didn't get their state initialized properly
      and vgetcpu wouldn't work.
      
      Change the initialization sequence to instead run in a normal
      initcall (which runs after the normal CPU bootup) and initialize
      all running CPUs there. Later hotplug CPUs are still handled
      with an hotplug notifier.
      
      This actually simplifies the code somewhat.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8c131af1
    • A
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      Andi Kleen 提交于
      Timer overrides are normally disabled on Nvidia board because
      they are commonly wrong, except on new ones with HPET support.
      Unfortunately there are quite some Asus boards around that
      don't have HPET, but need a timer override.
      
      We don't know yet how to handle this transparently,
      but at least add a command line option to force the timer override
      and let them boot.
      
      Cc: len.brown@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      fa18f477
    • M
      [PATCH] x86-64: setup saved_max_pfn correctly (kdump) · 15803a43
      Magnus Damm 提交于
      x86_64: setup saved_max_pfn correctly
      
      2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
      to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
      to zero instead of the max_pfn value before the user map is setup.
      
      This happens because saved_max_pfn is initialized at parse_early_param() time,
      and at this time no active regions have been registered. save_max_pfn is setup
      from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
      returns 0 because no regions exist.
      
      This patch fixes this by registering before and removing after the call
      to e820_end_of_ram().
      Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      15803a43
    • A
      [PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable. · 14f448e3
      Aaron Durbin 提交于
      Fix partial page check in e820_register_active_regions to ensure
      partial pages are
      not being marked as active in the memory pool.
      Signed-off-by: NAaron Durbin <adurbin@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      14f448e3
  8. 09 11月, 2006 3 次提交