commit 5cb4cc0d8211c490537c8568001958fc76741312 tree 3a3844a79cff56d84ecafd65ba5d8da25e158d2b parent 0b2bfb4e7ff61f286676867c3508569bea6fbf7a author Haren Myneni Wed, 03 Aug 2005 15:08:18 +1000 committer Linus Torvalds 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 Signed-off-by: Paul Mackerras Signed-off-by: Linus Torvalds commit 0b2bfb4e7ff61f286676867c3508569bea6fbf7a tree 39c39d75aa916afcc3a3f736d3a5fd00a48ea003 parent 71db63acff69618b3d9d3114bd061938150e146b author Ivan Kokshaysky Wed, 03 Aug 2005 03:09:03 +0400 committer Linus Torvalds 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 Signed-off-by: Linus Torvalds commit 71db63acff69618b3d9d3114bd061938150e146b tree 49c43f9115648cd730e4a11e455877ad5ee680c5 parent 688d191821de7893043f5a37970472627aaffa4e author Ivan Kokshaysky Wed, 03 Aug 2005 02:59:47 +0400 committer Linus Torvalds 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 Signed-off-by: Linus Torvalds commit 688d191821de7893043f5a37970472627aaffa4e tree bee038b981147f4f9f3ac0ca23348376044678dd parent d7ed538a02c219119adb20f1dccbf0f8015e53f3 author Linus Torvalds Tue, 02 Aug 2005 14:55:40 -0700 committer Linus Torvalds 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 Tue, 02 Aug 2005 20:08:02 +0200 committer Linus Torvalds 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 Signed-off-by: Linus Torvalds commit f7c80c9f77b0e8a59a19506fd3caf323408a5166 tree 5306a5d77d38b363a1f04abeaf4bb7a234037e87 parent f7d1d23c301e0ce82c801f3b5800be6341752a1f author Olaf Hering Tue, 19 Jul 2005 20:04:24 +0200 committer Linus Torvalds 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 Acked-by: Christoph Hellwig Signed-off-by: Linus Torvalds commit f7d1d23c301e0ce82c801f3b5800be6341752a1f tree 12095ed260df39f8ee870f38d108d90519feb32f parent 9a351e30d72d409ec62c83f380e330e0baa584b4 author Paul Mackerras Tue, 02 Aug 2005 21:51:36 +1000 committer Linus Torvalds 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 Acked-by: Dominik Brodowski Signed-off-by: Linus Torvalds