1. 04 Aug, 2006 1 commit
    • Ilpo Järvinen's avatar
      [PKT_SCHED] RED: Fix overflow in calculation of queue average · c4c0ce5c
      Ilpo Järvinen authored
      
      
      Overflow can occur very easily with 32 bits, e.g., with 1 second
      us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue
      length. Since the EWMA exponent is typically around 9, queue
      lengths larger than 2^2 cause overflow. Whether the affected
      branch is taken when us_idle is as high as 1 second, depends on
      Scell_log, but with rather reasonable configuration Scell_log is
      large enough to cause p->Stab to have zero index, which always
      results zero shift (typically also few other small indices result
      in zero shift).
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4c0ce5c
  2. 03 Aug, 2006 11 commits
  3. 02 Aug, 2006 15 commits
  4. 31 Jul, 2006 11 commits
  5. 29 Jul, 2006 2 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Fix swiotlb=force · 65f87d8a
      Andi Kleen authored
      
      
      It was broken before. But having it is important as possible hardware
      bug workaround.
      
      And previously there was no way to force swiotlb if there is another IOMMU.
      Side effect is that iommu=force won't force swiotlb anymore even if there
      isn't another IOMMU.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      65f87d8a
    • Jon Mason's avatar
      [PATCH] x86_64: Calgary IOMMU - Multi-Node NULL pointer dereference fix · d2105b10
      Jon Mason authored
      
      
      Calgary hits a NULL pointer dereference when booting in a multi-chassis
      NUMA system.  See Redhat bugzilla number 198498, found by Konrad
      Rzeszutek (konradr@redhat.com).
      
      There are many issues that had to be resolved to fix this problem.
      Firstly when I originally wrote the code to handle NUMA systems, I
      had a large misunderstanding that was not corrected until now.  That was
      that I thought the "number of nodes online" referred to number of
      physical systems connected.  So that if NUMA was disabled, there
      would only be 1 node and it would only show that node's PCI bus.
      In reality if NUMA is disabled, the system displays all of the
      connected chassis as one node but is only ignorant of the delays
      in accessing main memory.  Therefore, references to num_online_nodes()
      and MAX_NUMNODES are incorrect and need to be set to the maximum
      number of nodes that can be accessed (which are 8).  I created a
      variable, MAX_NUM_CHASSIS, and set it to 8 to fix this.
      
      Secondly, when walking the PCI in detect_calgary, the code only
      checked the first "slot" when looking to see if a device is present.
      This will work for most cases, but unfortunately it isn't always the
      case.  In the NUMA MXE drawers, there are USB devices present on the
      3rd slot (with slot 1 being empty).  So, to work around this, all
      slots (up to 8) are scanned to see if there are any devices present.
      
      Lastly, the bus is being enumerated on large systems in a different
      way the we originally thought.  This throws the ugly logic we had
      out the window.  To more elegantly handle this, I reorganized the
      kva array to be sparse (which removed the need to have any bus number
      to kva slot logic in tce.c) and created a secondary space array to
      contain the bus number to phb mapping.
      
      With these changes Calgary boots on an x460 with 4 nodes with and
      without NUMA enabled.
      Signed-off-by: default avatarJon Mason <jdmason@us.ibm.com>
      Signed-off-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d2105b10