1. 29 5月, 2009 4 次提交
  2. 26 5月, 2009 13 次提交
  3. 22 5月, 2009 5 次提交
  4. 21 5月, 2009 4 次提交
  5. 19 5月, 2009 2 次提交
  6. 18 5月, 2009 10 次提交
    • M
      microblaze: Fix kind-of-intr checking against number of interrupts · 7b7210d7
      Michal Simek 提交于
      + Fix typographic fault.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      7b7210d7
    • M
      microblaze: Update Microblaze defconfig · 3026589c
      Michal Simek 提交于
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      3026589c
    • P
    • M
      [ARM] Double check memmap is actually valid with a memmap has unexpected holes V2 · eb33575c
      Mel Gorman 提交于
      pfn_valid() is meant to be able to tell if a given PFN has valid memmap
      associated with it or not. In FLATMEM, it is expected that holes always
      have valid memmap as long as there is valid PFNs either side of the hole.
      In SPARSEMEM, it is assumed that a valid section has a memmap for the
      entire section.
      
      However, ARM and maybe other embedded architectures in the future free
      memmap backing holes to save memory on the assumption the memmap is never
      used. The page_zone linkages are then broken even though pfn_valid()
      returns true. A walker of the full memmap must then do this additional
      check to ensure the memmap they are looking at is sane by making sure the
      zone and PFN linkages are still valid. This is expensive, but walkers of
      the full memmap are extremely rare.
      
      This was caught before for FLATMEM and hacked around but it hits again for
      SPARSEMEM because the page_zone linkages can look ok where the PFN linkages
      are totally screwed. This looks like a hatchet job but the reality is that
      any clean solution would end up consumning all the memory saved by punching
      these unexpected holes in the memmap. For example, we tried marking the
      memmap within the section invalid but the section size exceeds the size of
      the hole in most cases so pfn_valid() starts returning false where valid
      memmap exists. Shrinking the size of the section would increase memory
      consumption offsetting the gains.
      
      This patch identifies when an architecture is punching unexpected holes
      in the memmap that the memory model cannot automatically detect and sets
      ARCH_HAS_HOLES_MEMORYMODEL. At the moment, this is restricted to EP93xx
      which is the model sub-architecture this has been reported on but may expand
      later. When set, walkers of the full memmap must call memmap_valid_within()
      for each PFN and passing in what it expects the page and zone to be for
      that PFN. If it finds the linkages to be broken, it assumes the memmap is
      invalid for that PFN.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eb33575c
    • B
      powerpc: Explicit alignment for .data.cacheline_aligned · 0e337b42
      Benjamin Herrenschmidt 提交于
      I don't think anything guarantees that the objects in data.page_aligned
      are a multiple of PAGE_SIZE, thus the section may end on any boundary.
      
      So the following section, .data.cacheline_aligned needs an explicit
      alignment.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0e337b42
    • G
      powerpc/ps3: Update ps3_defconfig · dc892288
      Geoff Levand 提交于
      Refresh and set these options:
      
       CONFIG_SYSFS_DEPRECATED_V2: y -> n
       CONFIG_INPUT_JOYSTICK:      y -> n
       CONFIG_HID_SONY:            n -> m
       CONFIG_RTC_DRV_PS3:         - -> m
      Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      dc892288
    • S
      powerpc/ftrace: Fix constraint to be early clobber · c3cf8667
      Steven Rostedt 提交于
      After upgrading my distcc boxes from gcc 4.2.2 to 4.4.0, the function
      graph tracer broke. This was discovered on my x86 boxes.
      
      The issue is that gcc used the same register for an output as it did for
      an input in an asm statement. I first thought this was a bug in gcc and
      reported it. I was notified that gcc was correct and that the output had
      to be flagged as an "early clobber".
      
      I noticed that powerpc had the same issue and this patch fixes it.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c3cf8667
    • M
      powerpc/ftrace: Use pr_devel() in ftrace.c · 021376a3
      Michael Ellerman 提交于
      pr_debug() can now result in code being generated even when #DEBUG
      is not defined. That's not really desirable in the ftrace code
      which we want to be snappy.
      
      With CONFIG_DYNAMIC_DEBUG=y:
      
      size before:
         text	   data	    bss	    dec	    hex	filename
         3334	    672	      4	   4010	    faa	arch/powerpc/kernel/ftrace.o
      
      size after:
         text	   data	    bss	    dec	    hex	filename
         2616	    360	      4	   2980	    ba4	arch/powerpc/kernel/ftrace.o
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      021376a3
    • M
      powerpc: Do not assert pte_locked for hugepage PTE entries · af3e4aca
      Mel Gorman 提交于
      With CONFIG_DEBUG_VM, an assertion is made when changing the protection
      flags of a PTE that the PTE is locked. Huge pages use a different pagetable
      format and the assertion is bogus and will always trigger with a bug looking
      something like
      
       Unable to handle kernel paging request for data at address 0xf1a00235800006f8
       Faulting instruction address: 0xc000000000034a80
       Oops: Kernel access of bad area, sig: 11 [#1]
       SMP NR_CPUS=32 NUMA Maple
       Modules linked in: dm_snapshot dm_mirror dm_region_hash
        dm_log dm_mod loop evdev ext3 jbd mbcache sg sd_mod ide_pci_generic
        pata_amd ata_generic ipr libata tg3 libphy scsi_mod windfarm_pid
        windfarm_smu_sat windfarm_max6690_sensor windfarm_lm75_sensor
        windfarm_cpufreq_clamp windfarm_core i2c_powermac
       NIP: c000000000034a80 LR: c000000000034b18 CTR: 0000000000000003
       REGS: c000000003037600 TRAP: 0300   Not tainted (2.6.30-rc3-autokern1)
       MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 28002484  XER: 200fffff
       DAR: f1a00235800006f8, DSISR: 0000000040010000
       TASK = c0000002e54cc740[2960] 'map_high_trunca' THREAD: c000000003034000 CPU: 2
       GPR00: 4000000000000000 c000000003037880 c000000000895d30 c0000002e5a2e500
       GPR04: 00000000a0000000 c0000002edc40880 0000005700000393 0000000000000001
       GPR08: f000000011ac0000 01a00235800006e8 00000000000000f5 f1a00235800006e8
       GPR12: 0000000028000484 c0000000008dd780 0000000000001000 0000000000000000
       GPR16: fffffffffffff000 0000000000000000 00000000a0000000 c000000003037a20
       GPR20: c0000002e5f4ece8 0000000000001000 c0000002edc40880 0000000000000000
       GPR24: c0000002e5f4ece8 0000000000000000 00000000a0000000 c0000002e5f4ece8
       GPR28: 0000005700000393 c0000002e5a2e500 00000000a0000000 c000000003037880
       NIP [c000000000034a80] .assert_pte_locked+0xa4/0xd0
       LR [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
       Call Trace:
       [c000000003037880] [c000000003037990] 0xc000000003037990 (unreliable)
       [c000000003037910] [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
       [c0000000030379b0] [c00000000014bef8] .hugetlb_cow+0x124/0x674
       [c000000003037b00] [c00000000014c930] .hugetlb_fault+0x4e8/0x6f8
       [c000000003037c00] [c00000000013443c] .handle_mm_fault+0xac/0x828
       [c000000003037cf0] [c0000000000340a8] .do_page_fault+0x39c/0x584
       [c000000003037e30] [c0000000000057b0] handle_page_fault+0x20/0x5c
       Instruction dump:
       7d29582a 7d200074 7800d182 0b000000 3c004000 3960ffff 780007c6 796b00c4
       7d290214 7929a302 1d290068 7d6b4a14 <800b0010> 7c000074 7800d182 0b000000
      
      This patch fixes the problem by not asseting the PTE is locked for VMAs
      backed by huge pages.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      af3e4aca
    • R
      [ARM] realview: fix broadcast tick support · ee348d5a
      Russell King 提交于
      Having discussed broadcast tick support with Thomas Glexiner, the
      broadcast tick devices should be registered with a higher rating
      than the global tick device, and it should have the ONESHOT and
      PERIODIC feature flags set.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NThomas Glexiner <tglx@linutronix.de>
      ee348d5a
  7. 17 5月, 2009 2 次提交