1. 19 Nov, 2007 1 commit
  2. 22 Oct, 2007 1 commit
  3. 19 Oct, 2007 1 commit
  4. 17 Oct, 2007 2 commits
  5. 11 Oct, 2007 2 commits
  6. 20 Aug, 2007 1 commit
    • Len Brown's avatar
      ACPI: boot correctly with "nosmp" or "maxcpus=0" · 61ec7567
      Len Brown authored
      In MPS mode, "nosmp" and "maxcpus=0" boot a UP kernel with IOAPIC disabled.
      However, in ACPI mode, these parameters didn't completely disable
      the IO APIC initialization code and boot failed.
      
      init/main.c:
      	Disable the IO_APIC if "nosmp" or "maxcpus=0"
      	undefine disable_ioapic_setup() when it doesn't apply.
      
      i386:
      	delete ioapic_setup(), it was a duplicate of parse_noapic()
      	delete undefinition of disable_ioapic_setup()
      
      x86_64:
      	rename disable_ioapic_setup() to parse_noapic() to match i386
      	define disable_ioapic_setup() in header to match i386
      
      http://bugzilla.kernel.org/show_bug.cgi?id=1641Acked-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      61ec7567
  7. 12 Aug, 2007 1 commit
  8. 21 Jul, 2007 1 commit
    • Eric W. Biederman's avatar
      x86_64: check remote IRR bit before migrating level triggered irq · ef3e28c5
      Eric W. Biederman authored
      On x86_64 kernel, level triggered irq migration gets initiated in the
      context of that interrupt(after executing the irq handler) and following
      steps are followed to do the irq migration.
      
      1. mask IOAPIC RTE entry;     // write to IOAPIC RTE
      2. EOI;                       // processor EOI write
      3. reprogram IOAPIC RTE entry // write to IOAPIC RTE with new destination and
                                    // and interrupt vector due to per cpu vector
                                    // allocation.
      4. unmask IOAPIC RTE entry;   // write to IOAPIC RTE
      
      Because of the per cpu vector allocation in x86_64 kernels, when the irq
      migrates to a different cpu, new vector(corresponding to the new cpu) will
      get allocated.
      
      An EOI write to local APIC has a side effect of generating an EOI write for
      level trigger interrupts (normally this is a broadcast to all IOAPICs).
      The EOI broadcast generated as a side effect of EOI write to processor may
      be delayed while the other IOAPIC writes (step 3 and 4) can go through.
      
      Normally, the EOI generated by local APIC for level trigger interrupt
      contains vector number.  The IOAPIC will take this vector number and search
      the IOAPIC RTE entries for an entry with matching vector number and clear
      the remote IRR bit (indicate EOI).  However, if the vector number is
      changed (as in step 3) the IOAPIC will not find the RTE entry when the EOI
      is received later.  This will cause the remote IRR to get stuck causing the
      interrupt hang (no more interrupt from this RTE).
      
      Current x86_64 kernel assumes that remote IRR bit is cleared by the time
      IOAPIC RTE is reprogrammed.  Fix this assumption by checking for remote IRR
      bit and if it still set, delay the irq migration to the next interrupt
      arrival event(hopefully, next time remote IRR bit will get cleared before
      the IOAPIC RTE is reprogrammed).
      
      Initial analysis and patch from Nanhai.
      
      Clean up patch from Suresh.
      
      Rewritten to be less intrusive, and to contain a big fat comment by Eric.
      
      [akpm@linux-foundation.org: fix comments]
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Nanhai Zou <nanhai.zou@intel.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Keith Packard <keith.packard@intel.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef3e28c5
  9. 26 Jun, 2007 1 commit
  10. 08 May, 2007 2 commits
  11. 02 May, 2007 3 commits
  12. 05 Mar, 2007 1 commit
  13. 28 Feb, 2007 1 commit
    • Eric W. Biederman's avatar
      [PATCH] x86_64/i386 irq: Fix !CONFIG_SMP compilation · 2ff7354f
      Eric W. Biederman authored
      When removing set_native_irq I missed the fact that it was
      called in a couple of places that were compiled even when
      SMP support is disabled.  And since the irq_desc[].affinity
      field only exists in SMP things broke.
      
      Thanks to Simon Arlott <simon@arlott.org> for spotting this.
      
      There are a couple of ways to fix this but the simplest one
      is to just remove the assignments.  The affinity field is only
      used to display a value to the user, and nothing on either i386
      or x86_64 reads it or depends on it being any particlua value,
      so skipping the assignment is safe.  The assignment that
      is being removed is just for the initial affinity value before
      the user explicitly sets it.  The irq_desc array initializes
      this field to CPU_MASK_ALL so the field is initialized to
      a reasonable value in the SMP case without being set.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2ff7354f
  14. 26 Feb, 2007 12 commits
  15. 16 Feb, 2007 1 commit
  16. 13 Feb, 2007 1 commit
    • Benjamin Romer's avatar
      [PATCH] x86-64: update IO-APIC dest field to 8-bit for xAPIC · ee4eff6f
      Benjamin Romer authored
      On the Unisys ES7000/ONE system, we encountered a problem where performing
      a kexec reboot or dump on any cell other than cell 0 causes the system
      timer to stop working, resulting in a hang during timer calibration in the
      new kernel.
      
      We traced the problem to one line of code in disable_IO_APIC(), which needs
      to restore the timer's IO-APIC configuration before rebooting.  The code is
      currently using the 4-bit physical destination field, rather than using the
      8-bit logical destination field, and it cuts off the upper 4 bits of the
      timer's APIC ID.  If we change this to use the logical destination field,
      the timer works and we can kexec on the upper cells.  This was tested on
      two different cells (0 and 2) in an ES7000/ONE system.
      
      For reference, the relevant Intel xAPIC spec is kept at
      ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
      specifically on page 334.
      Signed-off-by: default avatarBenjamin M Romer <benjamin.romer@unisys.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      ee4eff6f
  17. 07 Feb, 2007 1 commit
  18. 08 Jan, 2007 1 commit
  19. 06 Dec, 2006 4 commits
  20. 28 Nov, 2006 1 commit
  21. 15 Nov, 2006 1 commit
    • Eric W. Biederman's avatar
      [PATCH] Use delayed disable mode of ioapic edge triggered interrupts · 45c99533
      Eric W. Biederman authored
      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: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Acked-by: default avatarKomuro <komurojun-mbn@nifty.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      45c99533