commit 5cb4cc0d8211c490537c8568001958fc76741312
tree 3a3844a79cff56d84ecafd65ba5d8da25e158d2b
parent 0b2bfb4e7ff61f286676867c3508569bea6fbf7a
author Haren Myneni <haren@us.ibm.com> Wed, 03 Aug 2005 15:08:18 +1000
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 22:16:45 -0700

    [PATCH] Xmon bug fix for soft-reset
    
    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: Haren Myneni <hbabu@us.ibm.com>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

commit 0b2bfb4e7ff61f286676867c3508569bea6fbf7a
tree 39c39d75aa916afcc3a3f736d3a5fd00a48ea003
parent 71db63acff69618b3d9d3114bd061938150e146b
author Ivan Kokshaysky <ink@jurassic.park.msu.ru> Wed, 03 Aug 2005 03:09:03 +0400
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 18:21:25 -0700

    [PATCH] ACPI: increase PCIBIOS_MIN_IO on x86
    
    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: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

commit 71db63acff69618b3d9d3114bd061938150e146b
tree 49c43f9115648cd730e4a11e455877ad5ee680c5
parent 688d191821de7893043f5a37970472627aaffa4e
author Ivan Kokshaysky <ink@jurassic.park.msu.ru> Wed, 03 Aug 2005 02:59:47 +0400
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 18:21:25 -0700

    [PATCH] increase PCIBIOS_MIN_IO on x86
    
    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: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

commit 688d191821de7893043f5a37970472627aaffa4e
tree bee038b981147f4f9f3ac0ca23348376044678dd
parent d7ed538a02c219119adb20f1dccbf0f8015e53f3
author Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 14:55:40 -0700
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 14:55:40 -0700

    pci: make bus resource start address override minimum IO address
    
    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.

commit d7ed538a02c219119adb20f1dccbf0f8015e53f3
tree d716ae7dc2e986b36c8180333839312dc0eab7e2
parent f7c80c9f77b0e8a59a19506fd3caf323408a5166
author Jens Axboe <axboe@suse.de> Tue, 02 Aug 2005 20:08:02 +0200
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 11:19:18 -0700

    [PATCH] cfq-iosched: fix problem with barriers and max_depth == 1
    
    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: Jens Axboe <axboe@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

commit f7c80c9f77b0e8a59a19506fd3caf323408a5166
tree 5306a5d77d38b363a1f04abeaf4bb7a234037e87
parent f7d1d23c301e0ce82c801f3b5800be6341752a1f
author Olaf Hering <olh@suse.de> Tue, 19 Jul 2005 20:04:24 +0200
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 08:43:59 -0700

    [PATCH] aic byteorder fixes after recent cleanup
    
    Rebuild the aic7xxx firmware doesn't work anymore after this change
    which appeared int 2.6.13-rc1:
    
    [SCSI] aic7xxx/aic79xx: remove useless byte order macro cruft
    
    Two files did not include byteorder.h, resulting in aic dying with a panic
    
    "Unknown opcode encountered in seq program"
    
    This fixes it for me.
    
    Signed-off-by: Olaf Hering <olh@suse.de>
    Acked-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

commit f7d1d23c301e0ce82c801f3b5800be6341752a1f
tree 12095ed260df39f8ee870f38d108d90519feb32f
parent 9a351e30d72d409ec62c83f380e330e0baa584b4
author Paul Mackerras <paulus@samba.org> Tue, 02 Aug 2005 21:51:36 +1000
committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 02 Aug 2005 08:28:48 -0700

    [PATCH] Obvious bugfix for yenta resource allocation
    
    Recent changes (well, dating from 12 July) have broken cardbus on my
    powerbook: I get 3 messages saying "no resource of type xxx available,
    trying to continue", and if I plug in my wireless card, it complains
    that there are no resources allocated to the card.  This all worked in
    2.6.12.
    
    Looking at the code in yenta_socket.c, function yenta_allocate_res,
    it's obvious what is wrong: if we get to line 639 (i.e. there wasn't a
    usable preassigned resource), we will always flow through to line 668,
    which is the printk that I was seeing, even if a resource was
    successfully allocated.  It looks to me as though there should be a
    return statement after the two config_writel's in each of the 3
    branches of the if statements, so that the function returns after
    successfully setting up the resource.
    
    The patch below adds these return statements, and with this patch,
    cardbus works on my powerbook once again.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>