1. 14 Jan, 2009 31 commits
  2. 13 Jan, 2009 9 commits
    • Linus Torvalds's avatar
      Merge branch 'x86-pat-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip · a6525042
      Linus Torvalds authored
      * 'x86-pat-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86 PAT: remove CPA WARN_ON for zero pte
        x86 PAT: return compatible mapping to remap_pfn_range callers
        x86 PAT: change track_pfn_vma_new to take pgprot_t pointer param
        x86 PAT: consolidate old memtype new memtype check into a function
        x86 PAT: remove PFNMAP type on track_pfn_vma_new() error
      a6525042
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · b9a0d06a
      Linus Torvalds authored
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        TWL4030: fix clk API usage
        [ARM] 5364/1: allow flush_ioremap_region() to be used from modules
        [ARM] w90x900: fix build errors and warnings
        [ARM] i.MX add missing include
        [ARM] i.MX: fix breakage from commit 27889273
        [ARM] i.MX: remove LCDC controller register definitions from imx-regs.h
      b9a0d06a
    • Bernd Schmidt's avatar
      Fix timeouts in sys_pselect7 · 62568510
      Bernd Schmidt authored
      Since we (Analog Devices) updated our Blackfin kernel to 2.6.28, we've
      seen occasional 5-second hangs from telnet.  telnetd calls select with a
      NULL timeout, but with the new kernel, the system call occasionally
      returns 0, which causes telnet to call sleep (5).  This did not happen
      with earlier kernels.
      
      The code in sys_pselect7 looks a bit strange, in particular the variable
      "to" is initialized to NULL, then changed if a non-null timeout was
      passed in, but not used further.  It needs to be passed to
      core_sys_select instead of &end_time.
      
      This bug was introduced by 8ff3e8e8
      ("select: switch select() and poll() over to hrtimers").
      Signed-off-by: default avatarBernd Schmidt <bernd.schmidt@analog.com>
      Reviewed-by: default avatarUlrich Drepper <drepper@redhat.com>
      Tested-by: default avatarRobin Getz <rgetz@blackfin.uclinux.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62568510
    • Helge Deller's avatar
      fix early_serial_setup() regression · 125c97d8
      Helge Deller authored
      Commit b430428a ("8250: Don't clobber
      spinlocks.") introduced a regression on the parisc architecture, which
      broke the handover to the serial port at boottime.
      
      early_serial_setup() was changed to only copy a subset of the uart_port
      fields, and sadly the "type" and "line" fields were forgotten and thus
      the serial port was not initialized and could not be used for a
      handover.  This patch fixes this by copying the missing fields.
      
      As this change to early_serial_setup() doesn't need an initialized
      spinlock in the uart_port struct any longer, we can drop the spinlock
      initialization in the superio driver.
      
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Tomaso Paoletti <tpaoletti@caviumnetworks.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Acked-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      125c97d8
    • Russell King's avatar
      TWL4030: fix clk API usage · e6b50c8d
      Russell King authored
      Always pass a struct device if one is available; and there's really
      no reason for the processor specific stuff in this file if only
      people would follow the API usage properly by using the struct device.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e6b50c8d
    • venkatesh.pallipadi@intel.com's avatar
      x86 PAT: remove CPA WARN_ON for zero pte · 58dab916
      venkatesh.pallipadi@intel.com authored
      Impact: reduce scope of debug check - avoid warnings
      
      The logic to find whether identity map exists or not using
      high_memory or max_low_pfn_mapped/max_pfn_mapped are not complete
      as the memory withing the range may not be mapped if there is a
      unusable hole in e820.
      
      Specifically, on my test system I started seeing these warnings with
      tools like hwinfo, acpidump trying to map ACPI region.
      
      [   27.400018] ------------[ cut here ]------------
      [   27.400344] WARNING: at /home/venkip/src/linus/linux-2.6/arch/x86/mm/pageattr.c:560 __change_page_attr_set_clr+0xf3/0x8b8()
      [   27.400821] Hardware name: X7DB8
      [   27.401070] CPA: called for zero pte. vaddr = ffff8800cff6a000 cpa->vaddr = ffff8800cff6a000
      [   27.401569] Modules linked in:
      [   27.401882] Pid: 4913, comm: dmidecode Not tainted 2.6.28-05716-gfe0bdec6 #586
      [   27.402141] Call Trace:
      [   27.402488]  [<ffffffff80237c21>] warn_slowpath+0xd3/0x10f
      [   27.402749]  [<ffffffff80274ade>] ? find_get_page+0xb3/0xc9
      [   27.403028]  [<ffffffff80274a2b>] ? find_get_page+0x0/0xc9
      [   27.403333]  [<ffffffff80226425>] __change_page_attr_set_clr+0xf3/0x8b8
      [   27.403628]  [<ffffffff8028ec99>] ? __purge_vmap_area_lazy+0x192/0x1a1
      [   27.403883]  [<ffffffff8028eb52>] ? __purge_vmap_area_lazy+0x4b/0x1a1
      [   27.404172]  [<ffffffff80290268>] ? vm_unmap_aliases+0x1ab/0x1bb
      [   27.404512]  [<ffffffff80290105>] ? vm_unmap_aliases+0x48/0x1bb
      [   27.404766]  [<ffffffff80226d28>] change_page_attr_set_clr+0x13e/0x2e6
      [   27.405026]  [<ffffffff80698fa7>] ? _spin_unlock+0x26/0x2a
      [   27.405292]  [<ffffffff80227e6a>] ? reserve_memtype+0x19b/0x4e3
      [   27.405590]  [<ffffffff80226ffd>] _set_memory_wb+0x22/0x24
      [   27.405844]  [<ffffffff80225d28>] ioremap_change_attr+0x26/0x28
      [   27.406097]  [<ffffffff80228355>] reserve_pfn_range+0x1a3/0x235
      [   27.406427]  [<ffffffff80228430>] track_pfn_vma_new+0x49/0xb3
      [   27.406686]  [<ffffffff80286c46>] remap_pfn_range+0x94/0x32c
      [   27.406940]  [<ffffffff8022878d>] ? phys_mem_access_prot_allowed+0xb5/0x1a8
      [   27.407209]  [<ffffffff803e9bf4>] mmap_mem+0x75/0x9d
      [   27.407523]  [<ffffffff8028b3b4>] mmap_region+0x2cf/0x53e
      [   27.407776]  [<ffffffff8028b8cc>] do_mmap_pgoff+0x2a9/0x30d
      [   27.408034]  [<ffffffff8020f4a4>] sys_mmap+0x92/0xce
      [   27.408339]  [<ffffffff8020b65b>] system_call_fastpath+0x16/0x1b
      [   27.408614] ---[ end trace 4b16ad70c09a602d ]---
      [   27.408871] dmidecode:4913 reserve_pfn_range ioremap_change_attr failed write-back for cff6a000-cff6b000
      
      This is wih track_pfn_vma_new trying to keep identity map in sync.
      The address cff6a000 is the ACPI region according to e820.
      
      [    0.000000] BIOS-provided physical RAM map:
      [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
      [    0.000000]  BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
      [    0.000000]  BIOS-e820: 00000000000cc000 - 00000000000d0000 (reserved)
      [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
      [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cff60000 (usable)
      [    0.000000]  BIOS-e820: 00000000cff60000 - 00000000cff69000 (ACPI data)
      [    0.000000]  BIOS-e820: 00000000cff69000 - 00000000cff80000 (ACPI NVS)
      [    0.000000]  BIOS-e820: 00000000cff80000 - 00000000d0000000 (reserved)
      [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
      [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
      [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
      [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
      [    0.000000]  BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
      
      And is not mapped as per init_memory_mapping.
      
      [    0.000000] init_memory_mapping: 0000000000000000-00000000cff60000
      [    0.000000] init_memory_mapping: 0000000100000000-0000000230000000
      
      We can add logic to check for this. But, there can also be other holes in
      identity map when we have 1GB of aligned reserved space in e820.
      
      This patch handles it by removing the WARN_ON and returning a specific
      error value (EFAULT) to indicate that the address does not have any
      identity mapping.
      
      The code that tries to keep identity map in sync can ignore
      this error, with other callers of cpa still getting error here.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      58dab916
    • venkatesh.pallipadi@intel.com's avatar
      x86 PAT: return compatible mapping to remap_pfn_range callers · cdecff68
      venkatesh.pallipadi@intel.com authored
      Impact: avoid warning message, potentially solve 3D performance regression
      
      Change x86 PAT code to return compatible memtype if the exact memtype that
      was requested in remap_pfn_rage and friends is not available due to some
      conflict.
      
      This is done by returning the compatible type in pgprot parameter of
      track_pfn_vma_new(), and the caller uses that memtype for page table.
      
      Note that track_pfn_vma_copy() which is basically called during fork gets the
      prot from existing page table and should not have any conflict. Hence we use
      strict memtype check there and do not allow compatible memtypes.
      
      This patch fixes the bug reported here:
      
        http://marc.info/?l=linux-kernel&m=123108883716357&w=2
      
      Specifically the error message:
      
        X:5010 map pfn expected mapping type write-back for d0000000-d0101000,
        got write-combining
      
      Should go away.
      Reported-and-bisected-by: default avatarKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cdecff68
    • venkatesh.pallipadi@intel.com's avatar
      x86 PAT: change track_pfn_vma_new to take pgprot_t pointer param · e4b866ed
      venkatesh.pallipadi@intel.com authored
      Impact: cleanup
      
      Change the protection parameter for track_pfn_vma_new() into a pgprot_t pointer.
      Subsequent patch changes the x86 PAT handling to return a compatible
      memtype in pgprot_t, if what was requested cannot be allowed due to conflicts.
      No fuctionality change in this patch.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e4b866ed
    • venkatesh.pallipadi@intel.com's avatar
      x86 PAT: consolidate old memtype new memtype check into a function · afc7d20c
      venkatesh.pallipadi@intel.com authored
      Impact: cleanup
      
      Move the new memtype old memtype allowed check to header so that is can be
      shared by other users. Subsequent patch uses this in pat.c in remap_pfn_range()
      code path. No functionality change in this patch.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      afc7d20c