1. 07 12月, 2006 5 次提交
  2. 04 12月, 2006 2 次提交
  3. 02 12月, 2006 8 次提交
  4. 18 11月, 2006 2 次提交
    • L
      x86: be more careful when walking back the frame pointer chain · 808dbbb6
      Linus Torvalds 提交于
      When showing the stack backtrace, make sure that we never accept not
      only an unchanging frame pointer, but also a frame pointer that moves
      back down the stack frame.  It must always grow up (toward older stack
      frames).
      
      I doubt this has triggered, but a subtly corrupt stack with extremely
      unlucky contents could cause us to loop forever on a bogus endless frame
      pointer chain.
      
      This review was triggered by much worse problems happening in some of
      the other stack unwinding code.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      808dbbb6
    • 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
  5. 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
  6. 15 11月, 2006 1 次提交
  7. 14 11月, 2006 1 次提交
    • 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
  8. 09 11月, 2006 5 次提交
  9. 04 11月, 2006 1 次提交
  10. 03 11月, 2006 1 次提交
  11. 02 11月, 2006 2 次提交
    • L
      i386: write IO APIC irq routing entries in correct order · f9dadfa7
      Linus Torvalds 提交于
      Since the "mask" bit is in the low word, when we write a new entry, we
      need to write the high word first, before we potentially unmask it.
      
      The exception is when we actually want to mask the interrupt, in which
      case we want to write the low word first to make sure that the high word
      doesn't change while the interrupt routing is still active.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f9dadfa7
    • L
      i386: clean up io-apic accesses · 130fe05d
      Linus Torvalds 提交于
      This is preparation for fixing the ordering of the accesses that
      got broken by the commit cf4c6a2f when
      factoring out the "common" io apic routing entry accesses.
      
      Move the accessor function (that were only used by io_apic.c) out
      of a header file, and use proper memory-mapped accesses rather than
      making up our own "volatile" pointers.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      130fe05d
  12. 31 10月, 2006 1 次提交
  13. 29 10月, 2006 2 次提交
  14. 28 10月, 2006 2 次提交
  15. 22 10月, 2006 6 次提交