1. 30 Oct, 2008 4 commits
  2. 29 Oct, 2008 3 commits
    • Gary Hade's avatar
      x86: remove debug code from arch_add_memory() · fe8b868e
      Gary Hade authored
      Impact: remove incorrect WARN_ON(1)
      
      Gets rid of dmesg spam created during physical memory hot-add which
      will very likely confuse users.  The change removes what appears to
      be debugging code which I assume was unintentionally included in:
      
        x86: arch/x86/mm/init_64.c printk fixes
        commit 10f22ddeSigned-off-by: default avatarGary Hade <garyhade@us.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fe8b868e
    • Harvey Harrison's avatar
      x86: start annotating early ioremap pointers with __iomem · 1d6cf1fe
      Harvey Harrison authored
      Impact: some new sparse warnings in e820.c etc, but no functional change.
      
      As with regular ioremap, iounmap etc, annotate with __iomem.
      
      Fixes the following sparse warnings, will produce some new ones
      elsewhere in arch/x86 that will get worked out over time.
      
      arch/x86/mm/ioremap.c:402:9: warning: cast removes address space of expression
      arch/x86/mm/ioremap.c:406:10: warning: cast adds address space to expression (<asn:2>)
      arch/x86/mm/ioremap.c:782:19: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1d6cf1fe
    • Harvey Harrison's avatar
      x86: two trivial sparse annotations · 9352f569
      Harvey Harrison authored
      Impact: fewer sparse warnings, no functional changes
      
      arch/x86/kernel/vsmp_64.c:87:14: warning: incorrect type in argument 1 (different address spaces)
      arch/x86/kernel/vsmp_64.c:87:14:    expected void const volatile [noderef] <asn:2>*addr
      arch/x86/kernel/vsmp_64.c:87:14:    got void *[assigned] address
      arch/x86/kernel/vsmp_64.c:88:22: warning: incorrect type in argument 1 (different address spaces)
      arch/x86/kernel/vsmp_64.c:88:22:    expected void const volatile [noderef] <asn:2>*addr
      arch/x86/kernel/vsmp_64.c:88:22:    got void *
      arch/x86/kernel/vsmp_64.c:100:23: warning: incorrect type in argument 2 (different address spaces)
      arch/x86/kernel/vsmp_64.c:100:23:    expected void volatile [noderef] <asn:2>*addr
      arch/x86/kernel/vsmp_64.c:100:23:    got void *
      arch/x86/kernel/vsmp_64.c:101:23: warning: incorrect type in argument 1 (different address spaces)
      arch/x86/kernel/vsmp_64.c:101:23:    expected void const volatile [noderef] <asn:2>*addr
      arch/x86/kernel/vsmp_64.c:101:23:    got void *
      arch/x86/mm/gup.c:235:6: warning: incorrect type in argument 1 (different base types)
      arch/x86/mm/gup.c:235:6:    expected void const volatile [noderef] <asn:1>*<noident>
      arch/x86/mm/gup.c:235:6:    got unsigned long [unsigned] [assigned] start
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9352f569
  3. 28 Oct, 2008 11 commits
  4. 27 Oct, 2008 3 commits
    • Yinghai Lu's avatar
      x86: keep the /proc/meminfo page count correct · 3afa3949
      Yinghai Lu authored
      Impact: get correct page count in /proc/meminfo
      
      found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4
      
      # cat /proc/meminfo
      MemTotal:        1017508 kB
      MemFree:          822700 kB
      Buffers:            1456 kB
      Cached:            26632 kB
      SwapCached:            0 kB
      ...
      Hugepagesize:       2048 kB
      DirectMap4k:      4032 kB
      DirectMap2M:  18446744073709549568 kB
      
      with this patch get:
      ...
      DirectMap4k:      4032 kB
      DirectMap2M:   1044480 kB
      
      which is consistent to kernel_page_tables
      ---[ Low Kernel Mapping ]---
      0xffff880000000000-0xffff880000001000           4K     RW     PCD     GLB x  pte
      0xffff880000001000-0xffff88000009f000         632K     RW             GLB x  pte
      0xffff88000009f000-0xffff8800000a0000           4K     RW     PCD     GLB x  pte
      0xffff8800000a0000-0xffff880000200000        1408K     RW             GLB x  pte
      0xffff880000200000-0xffff88003fe00000        1020M     RW         PSE GLB x  pmd
      0xffff88003fe00000-0xffff88003fff0000        1984K     RW             GLB NX pte
      0xffff88003fff0000-0xffff880040000000          64K                           pte
      0xffff880040000000-0xffff888000000000         511G                           pud
      0xffff888000000000-0xffffc20000000000       58880G                           pgd
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3afa3949
    • Cliff Wickman's avatar
      x86/uv: memory allocation at initialization · ef020ab0
      Cliff Wickman authored
      Impact: on SGI UV platforms, fix boot crash
      
      UV initialization is currently called too late to call alloc_bootmem_pages().
      The current sequence is:
      
       start_kernel()
         mem_init()
           free_all_bootmem()           <--- discard of bootmem
         rest_init()
           kernel_init()
             smp_prepare_cpus()
             native_smp_prepare_cpus()
               uv_system_init()         <--- uses alloc_bootmem_pages()
      
      It should be calling kmalloc().
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ef020ab0
    • Chris Lalancette's avatar
      xen: fix Xen domU boot with batched mprotect · 9f32d21c
      Chris Lalancette authored
      Impact: fix guest kernel boot crash on certain configs
      
      Recent i686 2.6.27 kernels with a certain amount of memory (between
      736 and 855MB) have a problem booting under a hypervisor that supports
      batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
      any 3.3 or later Xen hypervisor).
      
      The problem ends up being that xen_ptep_modify_prot_commit() is using
      virt_to_machine to calculate which pfn to update.  However, this only
      works for pages that are in the p2m list, and the pages coming from
      change_pte_range() in mm/mprotect.c are kmap_atomic pages.  Because of
      this, we can run into the situation where the lookup in the p2m table
      returns an INVALID_MFN, which we then try to pass to the hypervisor,
      which then (correctly) denies the request to a totally bogus pfn.
      
      The right thing to do is to use arbitrary_virt_to_machine, so that we
      can be sure we are modifying the right pfn.  This unfortunately
      introduces a performance penalty because of a full page-table-walk,
      but we can avoid that penalty for pages in the p2m list by checking if
      virt_addr_valid is true, and if so, just doing the lookup in the p2m
      table.
      
      The attached patch implements this, and allows my 2.6.27 i686 based
      guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
      Thanks to Jeremy for the suggestions about how to fix this particular
      issue.
      Signed-off-by: default avatarChris Lalancette <clalance@redhat.com>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9f32d21c
  5. 26 Oct, 2008 19 commits