1. 03 Aug, 2009 3 commits
    • Paul Mackerras's avatar
      x86: Make 64-bit efi_ioremap use ioremap on MMIO regions · 6a7bbd57
      Paul Mackerras authored
      Booting current 64-bit x86 kernels on the latest Apple MacBook
      (MacBook5,2) via EFI gives the following warning:
      
      [    0.182209] ------------[ cut here ]------------
      [    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
      [    0.182227] Hardware name: MacBook5,2
      [    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
      [    0.182236] Modules linked in:
      [    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
      [    0.182246] Call Trace:
      [    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
      [    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
      [    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
      [    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
      [    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
      [    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
      [    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
      [    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
      [    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
      [    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
      [    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
      [    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
      [    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
      [    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
      [    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
      [    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
      [    0.182993]  00ffffc000 - 0100000000 page 4k
      
      This happens because the 64-bit version of efi_ioremap calls
      init_memory_mapping for all addresses, regardless of whether they are
      RAM or MMIO.  The EFI tables on this machine ask for runtime access to
      some MMIO regions:
      
      [    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
      [    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
      [    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
      [    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
      [    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
      [    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
      [    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
      
      This arranges to pass the EFI memory type through to efi_ioremap, and
      makes efi_ioremap use ioremap rather than init_memory_mapping if the
      type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6a7bbd57
    • Paul Mackerras's avatar
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      Paul Mackerras authored
      The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
      under Linux; neither the EFI reboot method nor the default method
      using the keyboard controller works (the system just hangs and doesn't
      reset).  However, the method using the "PCI reset register" at 0xcf9
      does work.
      
      This adds a quirk to detect this machine via DMI and force the
      reboot_type to BOOT_CF9.  With this it reboots successfully without
      requiring a command-line option.  Note that the EFI code forces
      reboot_type to BOOT_EFI when the machine is booted via EFI, but this
      overrides that since the core_initcall runs after the EFI
      initialization code.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
    • Thomas Hellstrom's avatar
      x86: Fix CPA memtype reserving in the set_pages_array*() cases · 8523acfe
      Thomas Hellstrom authored
      The code was incorrectly reserving memtypes using the page
      virtual address instead of the physical address. Furthermore,
      the code was not ignoring highmem pages as it ought to.
      
      ( upstream does not pass in highmem pages yet - but upcoming
        graphics code will do it and there's no reason to not handle
        this properly in the CPA APIs.)
      
      Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>
      Cc: dri-devel@lists.sourceforge.net
      Cc: venkatesh.pallipadi@intel.com
      LKML-Reference: <1249284345-7654-1-git-send-email-thellstrom@vmware.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8523acfe
  2. 31 Jul, 2009 1 commit
    • Pallipadi, Venkatesh's avatar
      x86, pat: Fix set_memory_wc related corruption · bdc6340f
      Pallipadi, Venkatesh authored
      Changeset 3869c4aa
      that went in after 2.6.30-rc1 was a seemingly small change to _set_memory_wc()
      to make it complaint with SDM requirements. But, introduced a nasty bug, which
      can result in crash and/or strange corruptions when set_memory_wc is used.
      One such crash reported here
      http://lkml.org/lkml/2009/7/30/94
      
      Actually, that changeset introduced two bugs.
      * change_page_attr_set() takes &addr as first argument and can the addr value
        might have changed on return, even for single page change_page_attr_set()
        call. That will make the second change_page_attr_set() in this routine
        operate on unrelated addr, that can eventually cause strange corruptions
        and bad page state crash.
      * The second change_page_attr_set() call, before setting _PAGE_CACHE_WC, should
        clear the earlier _PAGE_CACHE_UC_MINUS, as otherwise cache attribute will not
        be WC (will be UC instead).
      
      The patch below fixes both these problems. Sending a single patch to fix both
      the problems, as the change is to the same line of code. The change to have a
      addr_copy is not very clean. But, it is simpler than making more changes
      through various routines in pageattr.c.
      
      A huge thanks to Jerome for reporting this problem and providing a simple test
      case that helped us root cause the problem.
      Reported-by: default avatarJerome Glisse <glisse@freedesktop.org>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20090730214319.GA1889@linux-os.sc.intel.com>
      Acked-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      bdc6340f
  3. 27 Jul, 2009 32 commits
  4. 26 Jul, 2009 4 commits