- 28 2月, 2006 2 次提交
-
-
由 Zhang, Yanmin 提交于
unaligned_access does fetch cr.ipsr, then calls dispatch_unaligned_handler, but dispatch_unaligned_handler fetches cr.ipsr again, so delete the first one. Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Jes Sorensen 提交于
Adrian> On architectures like i386, the "Multimedia Capabilities Port Adrian> drivers" menu is visible, but it can't be visited since it Adrian> contains nothing usable for CONFIG_SGI_SN=n. Jes> Thats only a third of the patch, if you want to do that, you should Jes> remove the redundant SGI_SN checks below. Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 27 2月, 2006 23 次提交
-
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
Commit 9ec4b1f3 made kprobes not compile without module support, so just make that clear in the Kconfig file. Also, since it's marked EXPERIMENTAL, make that dependency explicit too. Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 David S. Miller 提交于
The change to kernel/sched.c's init code to use for_each_cpu() requires that the cpu_possible_map be setup much earlier. Set it up via setup_arch(), constrained to NR_CPUS, and later constrain it to max_cpus in smp_prepare_cpus(). This fixes SMP booting on sparc64. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 James Bottomley 提交于
Commit 9c869eda broke voyager again rather subtly because it already had its own topology exporting functions, so now each CPU gets registered twice. I think we can actually use the generic ones, so I don't propose reverting it. The attached should eliminate the voyager topology functions in favour of the generic ones. I also added a define to ensure voyager is never hotplug CPU (we don't have the support in the SMP harness). Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Brian Magnuson 提交于
The commit e2c03888 added setup_additional_cpus to setup.c but this is only defined if CONFIG_HOTPLUG_CPU is set. This patch changes the #ifdef to reflect that. Signed-off-by: NBrian Magnuson <magnuson@rcn.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
RTC_IRQP_SET/RTC_EPOCH_SET don't take a pointer to an argument, but the argument itself. This actually simplifies the code and makes it work. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
The previous experiment for using apicmaintimer on ATI systems didn't work out very well. In particular laptops with C2/C3 support often don't let it tick during idle, which makes it useless. There were also some other bugs that made the apicmaintimer often not used at all. I tried some other experiments - running timer over RTC and some other things but they didn't really work well neither. I rechecked the specs now and it turns out this simple change is actually enough to avoid the double ticks on the ATI systems. We just turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC. I tested it on a few ATI systems and it worked there. In fact it worked on all chipsets (NVidia, Intel, AMD, ATI) I tried it on. According to the ACPI spec routing should always work through the IO-APIC so I think it's the correct thing to do anyways (and most of the old gunk in check_timer should be thrown away for x86-64). But for 2.6.16 it's best to do a fairly minimal change: - Use the known to be working everywhere-but-ATI IRQ0 both over 8254 and IO-APIC setup everywhere - Except on ATI disable IRQ0 in the 8254 - Remove the code to select apicmaintimer on ATI chipsets - Add some boot options to allow to override this (just paranoia) In 2.6.17 I hope to switch the default over to this for everybody. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
SMP time selection originally ran after all CPUs were brought up because it needed to know the number of CPUs to decide if it needs an MP safe timer or not. This is not needed anymore because we know present CPUs early. This fixes a couple of problems: - apicmaintimer didn't always work because it relied on state that was set up time_init_gtod too late. - The output for the used timer in early kernel log was misleading because time_init_gtod could actually change it later. Now always print the final timer choice Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
It didn't set up the CPU possible map early enough, so the option didn't actually work. Noticed by Heiko Carstens Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
ACPI is initialized very early on x86-64, before the DMI code is initialized. This means it would often discover a 0 year and then turn off ACPI because it thought the BIOS was too old. Some systems don't boot without ACPI so this was a problem. I have a full fix by adding new very early DMI detection, but it needs more testing before it can be merged. For 2.6.16 let's just turn the check off. It never made much sense anyways because there are no x86-64 systems older than 2002 or so and they generally all have working ACPI. Cc: len.brown@intel.com Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Chris McDermott 提交于
[description from AK] Old check for the IO-APIC watchdog during the timer check was wrong - it obviously should only drop into this if the IO-APIC watchdog is used. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
This makes x86-64 use the common X86_PM_TIMER Kconfig entry in drivers/acpi And since PM timer is needed for correct timing on a lot of systems now (e.g. AMD dual cores) and we often get bug reports from people who forgot to set it make it depend on CONFIG_EMBEDDED. x86-64 had this change before and it's a good thing. I also fixed the description slightly to make this more clear. Cc: len.brown@intel.com Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andreas Deresch 提交于
[description from AK] This fixes booting in APIC mode on some ACER laptops. x86-64 did a similar change some time ago. See http://bugzilla.kernel.org/show_bug.cgi?id=4700 for details Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
Big Unisys systems have multiple clusters too, but they have an synchronized TSC. I'm using the SMBIOS to check for vendor == IBM. Cc: Chris McDermott <lcm@us.ibm.com> Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Suresh Siddha 提交于
Fixes a local DOS on Intel systems that lead to an endless recursive fault. AMD machines don't seem to be affected. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jan Beulich 提交于
The value, while currently unused in the native kernel, was off by one. Signed-Off-By: NJan Beulich <jbeulich@novell.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Mason 提交于
In previous versions of pci-gart.c, no_iommu was used to determine if IOMMU was disabled in the GART DMA mapping functions. This changed in 2.6.16 and now gart_xxx() functions are only called if gart is enabled. Therefore, uses of no_iommu in the GART code are no longer necessary and can be removed. Also, it removes double deceleration of no_iommu and force_iommu in pci.h and proto.h, by removing the deceleration in pci.h. Lastly, end_pfn off by one error. Tested (along with patch 1/2) on dual opteron with gart enabled, iommu=soft, and iommu=off. Signed-off-by: NJon Mason <jdmason@us.ibm.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Marc Zyngier 提交于
As the (probably) last user of a Specialix SI board, I noticed that recent kernels would fail to probe the sucker. Quick investigation indicate a few missing braces... I left the double probing in place, as it looks like it's been here forever. Signed-off-by: NMarc Zyngier <maz@misterjones.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Al Viro 提交于
There's a problem in sd where we blindly believe the length of the headers and block descriptors. Some devices return insane values for these and cause our length to end up greater than the actual buffer size, so check to make sure. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Also removed the buffer size magic number (512) and added DPOFUA of zero to the defaults Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 2月, 2006 4 次提交
-
-
由 Daniele Venzano 提交于
Fix two bugs in the WoL implementation of sis900. The first causes hangs on some system on driver load, the second causes troubles when disabling WoL support. Both fixes are one liner and really simple. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NDaniele Venzano <venza@brownhat.org>
-
由 Tejun Heo 提交于
Silicon Image has disclosed a new sil3114/3152 errata and workaround which causes the controller to return R_ERR on DMA activate FIS if the FIS is received while the next PRD is being fetched. This patch implements the workaround. This errata results in lock up and doesn't trigger if m15w workaround is in effect. We stopped applying m15w to 3512 and 3114 in 2.6.14-rc1 which makes 3512/3114 lock up with some drives on all kernel versions since 2.6.14-rc1 upto now (2.6.16-rc4). This patch should fix the regression. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Tejun Heo 提交于
3512 is slightly different from 3112 errata-wise. Differentiate it. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Dave Jones 提交于
Commit 9c869eda moved the i386 topology.c file. That change broke x86-64 compiles, as it uses the same file. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 25 2月, 2006 11 次提交
-
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
-
由 Kumar Gala 提交于
mem= command line option was being ignored in arch/powerpc if we were not a CONFIG_MULTIPLATFORM (which is handled via prom_init stub). The initial command line extraction and parsing needed to be moved earlier in the boot process and have code to actual parse mem= and do something about it. Also, fixed a compile warning in the file. Signed-off-by: NKumar Gala <galak@kernel.crashing.org> Acked-by: NSegher Boessenkool <segher@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
-
由 Zachary Amsden 提交于
When compiling a non-default subarch, topology.c is missing from the kernel build. This causes builds with CONFIG_HOTPLUG_CPU to fail. In addition, on Intel processors with cpuid level > 4, it causes intel_cacheinfo.c to reference uninitialized data that should have been set up by the initcall in topology.c which calls register_cpu. This causes a kernel panic on boot on newer Intel processors. Moving topology.c to arch/i386/kernel fixes both of these problems. Thanks to Dan Hecht for finding and fixing this problem. Signed-off-by: NZachary Amsden <zach@vmware.com> Signed-off-by: NDan Hecht <dhect@vmware.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Hugh Dickins 提交于
akpm points out that switching to a non-NUMA kernel could be irritating if mounting tmpfs fails on an mpol option: tmpfs.txt recommend remount. Signed-off-by: NHugh Dickins <hugh@veritas.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jun'ichi Nomura 提交于
Minor number should be freed after del_gendisk(). Otherwise, there could be a window where 2 registered gendisk has same minor number. Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com> Acked-by: NAlasdair G Kergon <agk@redhat.com> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jun'ichi Nomura 提交于
Need to unfreeze and release bdev otherwise the bdev inode with inconsistent state is reused later and cause problem. Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com> Acked-by: NAlasdair G Kergon <agk@redhat.com> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andrew Morton 提交于
Phil Marek <philipp.marek@bmlv.gv.at> points out that ramfs forgets to update a directory's mtime and ctime when it is modified. Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Christoph Lameter 提交于
- PF_SWAPWRITE needs to be set for RECLAIM_SWAP to be able to write out pages to swap. Currently RECLAIM_SWAP may not do that. - remove setting nr_reclaimed pages after slab reclaim since the slab shrinking code does not use that and the nr_reclaimed pages is just right for the intended follow up action. Signed-off-by: NChristoph Lameter <clameter@sgi.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-