- 17 Apr, 2008 38 commits
-
-
Glauber Costa authored
Signed-off-by:
Glauber Costa <gcosta@redhat.com> Signed-off-by:
Ravikiran Thirumalai <kiran@scalemp.com> Acked-by:
Shai Fultheim <shai@scalemp.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Glauber Costa authored
Signed-off-by:
-
Glauber Costa authored
It becomes to early for ioremap, so we use early_ioremap Signed-off-by:
-
Glauber Costa authored
Signed-off-by:
-
Glauber Costa authored
Change Makefile so vsmp_64.o object is dependent on PARAVIRT, rather than X86_VSMP Signed-off-by:
-
Robert Richter authored
Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Yinghai Lu authored
we don't need get that so early. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
I found it strange that the struct sk_buff definition was found inside the DWARF debugging sections in the generated object, so I verified and found that there is no need for the files that bring struct sk_buff definition into this file and verified also that sk_buff is not brought in indirectly too, thru other headers. I went on and removed many other unneeded includes and the end result is: [acme@doppio net-2.6]$ l /tmp/sys_ia32.o.before /tmp/sys_ia32.o.after -rw-rw-r-- 1 acme acme 185240 2008-02-06 19:19 /tmp/sys_ia32.o.after -rw-rw-r-- 1 acme acme 248328 2008-02-06 19:00 /tmp/sys_ia32.o.before Almost 64KB only on this object file! There were no other side effects from this change: [acme@doppio net-2.6]$ objcopy -j "text" /tmp/sys_ia32.o.before /tmp/text.before [acme@doppio net-2.6]$ objcopy -j "text" /tmp/sys_ia32.o.after /tmp/text.after [acme@doppio net-2.6]$ md5sum /tmp/text.before /tmp/text.after b7ac9b17942add68494e698e4f965d36 /tmp/text.before b7ac9b17942add68494e698e4f965d36 /tmp/text.after One of the complaints about using tools such as systemtap is that one has to install the huge kernel-debuginfo package: [acme@doppio net-2.6]$ rpm -q --qf "%{size}\n" kernel-rt-debuginfo 471737710 543867594 [acme@doppio net-2.6]$ Signed-off-by:Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Ian Campbell authored
Signed-off-by:
-
Ian Campbell authored
Signed-off-by:
Ian Campbell <ijc@hellion.org.uk> Cc: Ian Campbell <ijc@hellion.org.uk> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: virtualization@lists.linux-foundation.org Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: virtualization@lists.linux-foundation.org Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
[ tglx@linutronix.de: cleanup the other structs as well ] Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
[ tglx@linutronix.de: simplified ] Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Andi Kleen authored
The extended century readout does not solve the year 2038 problem on 32bit! v2: Fix compilation on !ACPI, pointed out by tglx Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
We assume that the RTC clock is BCD, so print a warning if it claims to be binary. [ tglx@linutronix.de: changed to WARN_ON - we want to know that! If no one reports it we can remove the complete if (RTC_ALWAYS_BCD) magic, which has RTC_ALWAYS_BCD defined to 1 since Linux 1.0 ... ] Signed-off-by:
-
Andi Kleen authored
We know it is already after 2000. Use the year 2000 offset for both 32 and 64 bit, which removes ifdefs and the 1970 magic. [ tglx@linutronix.de: remove 1970 magic, replace bogus commit message ] Signed-off-by:
-
Yinghai Lu authored
Change size to unsigned long, becase caller and user all used unsigned long. Also make bad_addr take an alignment parameter. Signed-off-by:
-
Andi Kleen authored
The AMD Fam10h CPUs support new Gigabyte page table entry for mapping 1GB at a time. Use this for the kernel direct mapping. Only done for 64bit because i386 does not support GB page tables. This only applies to the data portion of the direct mapping; the kernel text mapping stays with 2MB pages because the AMD Fam10h microarchitecture does not support GB ITLBs and AMD recommends against using GB mappings for code. Can be disabled with disable_gbpages on the kernel command line [ tglx@linutronix.de: simplify enable code ] [ Yinghai Lu <yinghai.lu@sun.com>: boot fix on 256 GB RAM ] Signed-off-by:
-
Ingo Molnar authored
These new controls toggle experimental support for a new CPU feature, the straightforward extension of largepages from the pmd level to the pud level, which allows 1GB (kernel) TLBs instead of 2MB TLBs. Turn it off by default, as this code has not been tested well enough yet. Use the CONFIG_DIRECT_GBPAGES=y .config option or gbpages on the boot line can be used to enable it. If enabled in the .config then nogbpages boot option disables it. Signed-off-by:
-
H. Peter Anvin authored
Clean up the page table dumper (fix boundary conditions, table driven address ranges, some formatting changes since it is no longer using the kernel log but a separate virtual file), and generalize to 32 bits. [ mingo@elte.hu: x86: fix the pagetable dumper ] Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Arjan van de Ven authored
This patch adds code to the kernel to have an (optional) /proc/kernel_page_tables debug file that basically dumps the kernel pagetables; this allows us kernel developers to verify that nothing fishy is going on and that the various mappings are set up correctly. This was quite useful in finding various change_page_attr() bugs, and is very likely to be useful in the future as well. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: mingo@elte.hu Cc: tglx@tglx.de Cc: hpa@zytor.com Signed-off-by:
-
H. Peter Anvin authored
Unify arch/x86/mm/Makefile between 32 and 64 bits. All configuration variables that are protected by Kconfig constraints have been put in the common part of the Makefile; however, the NUMA files are totally different between 32 and 64 bits and are handled via an ifdef. Signed-off-by:
-
Thomas Gleixner authored
Add debug information for DEBUG_PAGEALLOC to get some statistics about the pool usage and split status. Signed-off-by:
-
Roland McGrath authored
We map a VMA for the 32-bit vDSO even when it's disabled, which is stupid. For the 32-bit kernel it's the vdso_enabled boot parameter/sysctl and for the 64-bit kernel it's the vdso32 boot parameter/syscall32 sysctl. When it's disabled, we don't pass AT_SYSINFO_EHDR so processes don't use the vDSO for anything, but we still map it. For the non-compat vDSO, this means we're always putting an extra VMA somewhere, maybe lousing up the control of the address space the user was hoping for. Honor the setting by doing nothing in arch_setup_additional_pages. [ also see: "x86 vDSO: don't use disabled vDSO for signal trampoline" ] Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Roland McGrath authored
If the vDSO was not mapped, don't use it as the "restorer" for a signal handler. Whether we have a pointer in mm->context.vdso depends on what happened at exec time, so we shouldn't check any global flags now. Background: Currently, every 32-bit exec gets the vDSO mapped even if it's disabled (the process just doesn't get told about it). Because it's in fact always there, the bug that this patch fixes cannot happen now. With the second patch, it won't be mapped at all when it's disabled, which is one of the things that people might really want when they disable it (so nothing they didn't ask for goes into their address space). The 32-bit signal handler setup when SA_RESTORER is not used refers to current->mm->context.vdso without regard to whether the vDSO has been disabled when the process was exec'd. This patch fixes this not to use it when it's null, which becomes possible after the second patch. (This never happens in normal use, because glibc's sigaction call uses SA_RESTORER unless glibc detected the vDSO.) Signed-off-by:
-
Ingo Molnar authored
people sometimes do crazy stuff like building really large static arrays into their kernels or building allyesconfig kernels. Give more space to the kernel and push modules up a bit: kernel has 512 MB and modules have 1.5 GB. Should be enough for a few years ;-) Signed-off-by: -
Ingo Molnar authored
these build-time and link-time checks would have prevented the vmlinux size regression. Signed-off-by: -
Björn Steinbrink authored
fix bogus pirq warnings reported in: http://bugzilla.kernel.org/show_bug.cgi?id=10366 safe to be backported to v2.6.25 and earlier. Cc: stable@kernel.org Signed-off-by:
Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: it821x: do not describe noraid parameter with its value Pb1200/DBAu1200: fix bad IDE resource size Au1200: IDE driver build fix Au1200: kill IDE driver function prototypes avr32 mustn't select HAVE_IDE
-
- 16 Apr, 2008 2 commits
-
-
Paul Bolle authored
Describe noraid parameter with its name (and not its value). Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Sergei Shtylyov authored
The header files for the Pb1200/DBAu1200 boards have wrong definition for the IDE interface's decoded range length -- it should be 512 bytes according to what the IDE driver does. In addition, the IDE platform device claims 1 byte too many for its memory resource -- fix the platform code and the IDE driver in accordance. Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
