- 22 Jul, 2007 40 commits
-
-
Andreas Mohr authored
Add cpu_relax() to cmos_lock() inline function for faster operation on SMT CPUs and less power consumption on others in case of lock contention (which probably doesn't happen too often, so admittedly this patch is not too exciting). [akpm@linux-foundation.org: Include the header file for cpu_relax()] Signed-off-by:
Andreas Mohr <andi@lisas.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
mm/vmalloc.c: In function 'unmap_kernel_range': mm/vmalloc.c:75: warning: unused variable 'start' make it a C function so that the compiler thinks it used its arguments. Signed-off-by:
-
Yinghai Lu authored
This function is called via dma_ops->.., so change it to static Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Jiri Kosina authored
The function name is set_fixmap(), not fixmap_set() as stated in the comment. Also fix a typo, punctuation and lower/uppercase a bit. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Dan Aloni authored
Signed-off-by:
Dan Aloni <da-x@monatomic.org> Signed-off-by:
-
Alessio Igor Bogani authored
Signed-off-by:
Alessio Igor Bogani <abogani@texware.it> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Thomas Gleixner authored
Replace the pcspkr private PIT lock by the global PIT lock to serialize the PIT access all over the place. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Will Schmidt authored
During a VM oom condition, kill all threads in the process group. We have had complaints where a threaded application is left in a bad state after one of it's threads is killed when we hit a VM: out_of_memory condition. Killing just one of the process threads can leave the application in a bad state, whereas killing the entire process group would allow for the application to restart, or otherwise handled, and makes it very obvious that something has gone wrong. This change allows the entire process group to be taken down, rather than just the one thread. Signed-off-by:
Will <will_schmidt@vnet.ibm.com> Signed-off-by:
-
Glauber de Oliveira Costa authored
Some interrupt entry points are currently defined in i8259.c They probably belong in a header. Right now, their only user is init_IRQ, justifying their declaration in-file. But when virtualization comes in, we may be interested in using that functions in late initializations. Signed-off-by:
Glauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by:
-
Andy Whitcroft authored
We are seeing corruption of the decompressed kernel. It is suspected that this is platform specific as it has yet to be seen on any other x86. Move the kernel to the 16MB boundary. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
-
Jesper Juhl authored
Remove unneeded test of task != NULL from arch/i386/kernel/traps.c::dump_trace() At the start of the function we have this test: if (!task) task = current; so further down there's no need to test 'task'. Signed-off-by:Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
William Lee Irwin III authored
PAE is useful for more than supporting more than 4GB RAM. It supports expanded swapspace and NX executable protections. Some users may want NX or expanded swapspace support without the overhead or instability of highmem. For these reasons, the following patch divorces CONFIG_X86_PAE from CONFIG_HIGHMEM64G. Cc: Mark Lord <lkml@rtr.ca> Signed-off-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Thomas Gleixner authored
Some systems have a HPET which is not incrementing, which leads to a complete hang. Detect it during HPET setup. Signed-off-by:
-
James Jarvis authored
The following patch enables reboot through BIOS on the Dell Optiplex 745 Small Form Factor base, on which reboot hangs. The larger form factor does not require this, hence the match on DMI_BOARD_NAME. Signed-off-by:
-
Rafael J. Wysocki authored
On some systems the ACPI NVS area is located in the first 1 MB of RAM and it is overwritten by the i386 code during the restore after hibernation. This confuses the ACPI platform firmware that doesn't update the AC adapter status appropriately as a result (http://bugzilla.kernel.org/show_bug.cgi?id=7995). The solution is to register the reserved memory in the first 1 MB as 'nosave', so that swsusp doesn't touch it during the restore. Also, this has been done on x86_64 for a long time now, so this patch makes the i386 restore code behave like the x86_64 one. [akpm@linux-foundation.org: build fix] Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Pavel Machek <pavel@ucw.cz> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: arch/i386/kernel/built-in.o(.init.text+0x3818): Section mismatch: reference to .exit.text:cache_remove_dev (between 'cacheinfo_cpu_callback' and 'cache_sysfs_init') It points out that a function marked __cpuexit is calling a function marked __cpuinit => oops. The call happens only in an error-condition which may explain why we have not seen it before. The offending function was not used anywhere else - so marked it __cpuexit. Note: This warning triggers only with a local copy of modpost but that version will soon be pushed out. Signed-off-by:Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Adrian Bunk authored
pgd_{c,d}tor() can now become static. Signed-off-by:Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Muli Ben-Yehuda authored
After the bitmap changes we can get rid of the unlocked versions of calgary_unmap_sg and iommu_free. Fold __calgary_unmap_sg and __iommu_free into their calgary_unmap_sg and iommu_free, respectively. Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by:
-
Yinghai Lu authored
there function are called via dma_ops->.., so change them to static Signed-off-by:
-
Muli Ben-Yehuda authored
Currently the IOMMU table's lock protects both the bitmap and access to the hardware's TCE table. Access to the TCE table is synchronized through the bitmap; therefore, only hold the lock while modifying the bitmap. This gives a yummy 10-15% reduction in CPU utilization for netperf on a large SMP machine. Signed-off-by:
-
Muli Ben-Yehuda authored
No actual code was harmed in the production of this patch. Thanks to Andrew Morton <akpm@linux-foundation.org> for telling me about checkpatch.pl. Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Guillaume Thouvenin authored
Cleanup unneeded macros used for register space address calculation. Now we are using the EBDA to find the space address. Signed-off-by:
Guillaume Thouvenin <guillaume.thouvenin@bull.net> Signed-off-by:
-
Muli Ben-Yehuda authored
This works around a bug where DMAs that have the same addresses as some MEM regions do not go through. Not clear yet if this is due to a mis-configuration or something deeper. [akpm@linux-foundation.org: coding style fixlet] Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Muli Ben-Yehuda authored
Provide seperate versions for Calgary and CalIOC2 Also print out the PCIe Root Complex Status on CalIOC2 errors Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Muli Ben-Yehuda authored
[akpm@linux-foundation.org>: make calioc2_chip_ops static] Signed-off-by:
-
Muli Ben-Yehuda authored
CalIOC2 is a PCI-e implementation of the Calgary logic. Most of the programming details are the same, but some differ, e.g., TCE cache flush. This patch introduces CalIOC2 support - detection and various support routines. It's not expected to work yet (but will with follow-on patches). Signed-off-by:
-
Muli Ben-Yehuda authored
... in preparation for doing it differently for CalIOC2. Signed-off-by:
-
Muli Ben-Yehuda authored
Calgary and CalIOC2 share most of the same logic. Introduce struct cal_chipset_ops for quirks and tce flush logic which are [akpm@linux-foundation.org: make calgary_chip_ops static] Signed-off-by:
-
Muli Ben-Yehuda authored
Move the aic94xx split completion timeout handling there. Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Muli Ben-Yehuda authored
... will be used by CalIOC2 later Signed-off-by:
-
Adrian Bunk authored
The Rise CPUs were only very short-lived, and there are no reports of anyone both owning one and running Linux on it. Googling for the printk string "CPU: Rise iDragon" didn't find any dmesg available online. If it turns out that against all expectations there are actually users reverting this patch would be easy. This patch will make the kernel images smaller by a few bytes for all i386 users. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Eric W. Biederman authored
On x86_64 kernel, level triggered irq migration gets initiated in the context of that interrupt(after executing the irq handler) and following steps are followed to do the irq migration. 1. mask IOAPIC RTE entry; // write to IOAPIC RTE 2. EOI; // processor EOI write 3. reprogram IOAPIC RTE entry // write to IOAPIC RTE with new destination and // and interrupt vector due to per cpu vector // allocation. 4. unmask IOAPIC RTE entry; // write to IOAPIC RTE Because of the per cpu vector allocation in x86_64 kernels, when the irq migrates to a different cpu, new vector(corresponding to the new cpu) will get allocated. An EOI write to local APIC has a side effect of generating an EOI write for level trigger interrupts (normally this is a broadcast to all IOAPICs). The EOI broadcast generated as a side effect of EOI write to processor may be delayed while the other IOAPIC writes (step 3 and 4) can go through. Normally, the EOI generated by local APIC for level trigger interrupt contains vector number. The IOAPIC will take this vector number and search the IOAPIC RTE entries for an entry with matching vector number and clear the remote IRR bit (indicate EOI). However, if the vector number is changed (as in step 3) the IOAPIC will not find the RTE entry when the EOI is received later. This will cause the remote IRR to get stuck causing the interrupt hang (no more interrupt from this RTE). Current x86_64 kernel assumes that remote IRR bit is cleared by the time IOAPIC RTE is reprogrammed. Fix this assumption by checking for remote IRR bit and if it still set, delay the irq migration to the next interrupt arrival event(hopefully, next time remote IRR bit will get cleared before the IOAPIC RTE is reprogrammed). Initial analysis and patch from Nanhai. Clean up patch from Suresh. Rewritten to be less intrusive, and to contain a big fat comment by Eric. [akpm@linux-foundation.org: fix comments] Acked-by:Ingo Molnar <mingo@elte.hu> Cc: Nanhai Zou <nanhai.zou@intel.com> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Keith Packard <keith.packard@intel.com> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Venki Pallipadi authored
This helps to reduce the frequency at which the CPU must be taken out of a lower-power state. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by:
Tim Hockin <thockin@hockin.org> Signed-off-by:
-
