1. 04 10月, 2006 1 次提交
    • E
      [PATCH] genirq: msi: simplify the msi irq limit policy · 92db6d10
      Eric W. Biederman 提交于
      Currently we attempt to predict how many irqs we will be able to allocate with
      msi using pci_vector_resources and some complicated accounting, and then we
      only allow each device as many irqs as we think are available on average.
      
      Only the s2io driver even takes advantage of this feature all other drivers
      have a fixed number of irqs they need and bail if they can't get them.
      
      pci_vector_resources is inaccurate if anyone ever frees an irq.  The whole
      implmentation is racy.  The current irq limit policy does not appear to make
      sense with current drivers.  So I have simplified things.  We can revisit this
      we we need a more sophisticated policy.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      92db6d10
  2. 03 7月, 2006 1 次提交
  3. 01 7月, 2006 1 次提交
  4. 23 6月, 2006 2 次提交
  5. 28 4月, 2006 1 次提交
  6. 15 4月, 2006 1 次提交
    • G
      [PATCH] arch/i386/pci/irq.c - new VIA chipsets (fwd) · 40d8b89b
      Grzegorz Janoszka 提交于
      I use 2.6.15.6 Linux kernel and found some problems. I have about 100
      Linux boxes (all with the same (binary the same) kernel). Last time I have
      upgraded all those boxes from 2.4.32 to 2.6.15.6 (first 2.6.15.1, next .2,
      .4 and .6) and I have found some problems on VIA based PC's. Probably the
      reason of this is that some VIA chipsets are unrecognized by IRQ router.
      
      In line 586 there is: /* FIXME: add new ones for 8233/5 */
      
      There were only a few of chipsets ID's there, some of my VIA chipsets were
      not present and kernel used default IRQ router.
      
      I have added three entries, so that the code looks like:
      
              case PCI_DEVICE_ID_VIA_82C596:
              case PCI_DEVICE_ID_VIA_82C686:
              case PCI_DEVICE_ID_VIA_8231:
              case PCI_DEVICE_ID_VIA_8233A:
              case PCI_DEVICE_ID_VIA_8235:
              case PCI_DEVICE_ID_VIA_8237:
              case PCI_DEVICE_ID_VIA_8237_SATA:
                      /* FIXME: add new ones for 8233/5 */
                      r->name = "VIA";
                      r->get = pirq_via_get;
                      r->set = pirq_via_set;
                      return 1;
              }
      
      The kernel goes fine but I haven't testes it for weeks, I'm just a moment
      after reboot :)
      One thing is different (better?):
      Using previus kernel I had:
      PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0
      now I have:
      PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 11
      
      Maybe it is good idea to add there some more VIA chipsets?
      The ones I have added seem to be OK.
      
      From: Grzegorz Janoszka <Grzegorz@Janoszka.pl>
      Acked-by: NMartin Mares <mj@ucw.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      40d8b89b
  7. 01 2月, 2006 1 次提交
  8. 10 1月, 2006 1 次提交
  9. 07 1月, 2006 1 次提交
  10. 31 10月, 2005 1 次提交
  11. 01 10月, 2005 1 次提交
  12. 27 9月, 2005 1 次提交
  13. 26 8月, 2005 1 次提交
  14. 30 7月, 2005 1 次提交
  15. 28 7月, 2005 1 次提交
  16. 12 7月, 2005 1 次提交
  17. 28 6月, 2005 1 次提交
    • J
      [PATCH] PCI Allow OutOfRange PIRQ table address · 120bb424
      jayalk@intworks.biz 提交于
      I updated this to remove unnecessary variable initialization, make
      check_routing be inline only and not __init, switch to strtoul, and
      formatting fixes as per Randy Dunlap's recommendations.
      
      I updated this to change pirq_table_addr to a long, and to add a warning
      msg if the PIRQ table wasn't found at the specified address, as per thread
      with Matthew Wilcox.
      
      In our hardware situation, the BIOS is unable to store or generate it's PIRQ
      table in the F0000h-100000h standard range. This patch adds a pci kernel
      parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
      the kernel where the PIRQ table got stored. A beneficial side-effect is that,
      if one's BIOS uses a static address each time for it's PIRQ table, then
      pirqaddr can be used to avoid the $pirq search through that address block each
      time at boot for normal PIRQ BIOSes.
      Signed-off-by: NJaya Kumar <jayalk@intworks.biz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      120bb424
  18. 24 6月, 2005 1 次提交
  19. 27 5月, 2005 1 次提交
  20. 01 5月, 2005 1 次提交
  21. 17 4月, 2005 2 次提交