1. 04 8月, 2005 2 次提交
  2. 03 8月, 2005 5 次提交
    • H
      [PATCH] Xmon bug fix for soft-reset · 5cb4cc0d
      Haren Myneni 提交于
      For soft reset during system hang, got an error "CPU did not take
      control" for some CPUs even though they responded to soft-reset (called
      SystemReset, die and called debugger - xmon).   First these CPUs entered
      into xmon by IPI callback and then got a soft-reset exception and
      re-entered into xmon again. The first CPU which re-entered into xmon got
      the output lock and made into xmon successfully without unlocking.
      Hence, the next CPU(s) which re-entered into xmon try to acquire a lock
      (get_output_lock). Therefore, we can not view state of those CPU(s).
      
      [This is a simple, very low risk, obvious fix for an obvious bug, and
      should go into 2.6.13.  -- paulus]
      Signed-off-by: NHaren Myneni <hbabu@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cb4cc0d
    • I
      [PATCH] ACPI: increase PCIBIOS_MIN_IO on x86 · 0b2bfb4e
      Ivan Kokshaysky 提交于
      We have increased PCIBIOS_MIN_IO to 0x4000, but still want
      motherboard resources to be allocated properly. So we need
      to state 0x1000 (according to the comment) limit explicitely.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b2bfb4e
    • I
      [PATCH] increase PCIBIOS_MIN_IO on x86 · 71db63ac
      Ivan Kokshaysky 提交于
      There is a number of x86 laptops that have some non-PCI IO ports
      in the 0x1000-0x1fff range, and it's quite hard to control the correct
      order of resource allocation between PCI and other subsystems controlling
      these ports. Especially with modular kernel.
      
      So just increase PCIBIOS_MIN_IO to 0x4000 to prevent any new PCI
      resource allocations in the problematic range (this limitation must
      apply _only_ to the root bus resources - see Linus' change in
      pci_bus_alloc_resource).  As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO
      are the same now on i386 and x86-64, we can remove the latter.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      71db63ac
    • L
      pci: make bus resource start address override minimum IO address · 688d1918
      Linus Torvalds 提交于
      The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because
      we want to protect badly documented motherboard PCI resources and thus
      don't want to allocate new resources in low IO/MEM space.
      
      However, if we have already discovered a PCI bridge with a specified
      resource base, that should override that decision.
      
      This change will allow us to move the "careful" region upwards without
      resulting in problems allocating resources in low mappings.  This was
      brought on by us having allocated a bus resource at 0x1000, conflicting
      with a undocumented VAIO Sony PI resources.
      688d1918
    • J
      [PATCH] cfq-iosched: fix problem with barriers and max_depth == 1 · d7ed538a
      Jens Axboe 提交于
      CFQ will currently stall when using write barriers and the default
      max_depth setting of 1, since we artificially need a depth of 2 when
      pre-pending the first flush. So never deny the barrier request going to
      the device.
      
      This is a regression since 2.6.12, it was found in SUSE testing.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d7ed538a
  3. 02 8月, 2005 33 次提交