1. 24 2月, 2010 2 次提交
  2. 23 2月, 2010 3 次提交
  3. 22 2月, 2010 1 次提交
  4. 21 2月, 2010 1 次提交
    • R
      ARM: allow alignment fault mode to be configured at kernel boot · d944d549
      Russell King 提交于
      Some glibc versions intentionally create lots of alignment faults in
      their gconv code, which if not fixed up, results in segfaults during
      boot.  This can prevent systems booting properly.
      
      There is no clear hard-configurable default for this; the desired
      default depends on the nature of the userspace which is going to be
      booted.
      
      So, provide a way for the alignment fault handler to be configured via
      the kernel command line.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d944d549
  5. 20 2月, 2010 5 次提交
    • R
      ARM: Update mach-types · 0fa11802
      Russell King 提交于
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0fa11802
    • A
      ARM: 5950/1: ARM: Fix build error for arm1026ej-s processor · 1c8e170a
      Abdoulaye Walsimou Gaye 提交于
      This patch fix the below build error for arm1026ej-s processor (IntegratorCP/arm1026ej-s board).
        CC      init/main.o
      In file included from include/linux/highmem.h:8,
                       from include/linux/pagemap.h:10,
                       from include/linux/mempolicy.h:62,
                       from init/main.c:52:
      arch/arm/include/asm/cacheflush.h:134:2: error: #error Unknown cache maintainence model
      make[1]: *** [init/main.o] Erreur 1
      make: *** [init] Erreur 2
      Signed-off-by: NAbdoulaye Walsimou Gaye <walsimou@walsimou.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1c8e170a
    • D
      sparc64: Fix sun4u execute bit check in TSB I-TLB load. · 1f474646
      David S. Miller 提交于
      Thanks to testcase and report from Brad Spengler:
      
      --------------------
      #include <stdio.h>
      
      typedef int (* _wee)(void);
      
      int main(void)
      {
              char buf[8] = { '\x81', '\xc7', '\xe0', '\x08', '\x81', '\xe8',
                              '\x00', '\x00' };
              _wee wee;
              printf("%p\n", &buf);
              wee = (_wee)&buf;
              wee();
      
              return 0;
      }
      --------------------
      
      TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U bit,
      but that's bit 12 so it gets sign extended all the way up to bit 63
      and the test nearly always passes as a result.
      
      Use sethi to fix the bug.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f474646
    • F
      hw-breakpoint: Keep track of dr7 local enable bits · 326264a0
      Frederic Weisbecker 提交于
      When the user enables breakpoints through dr7, he can choose
      between "local" or "global" enable bits but given how linux is
      implemented, both have the same effect.
      
      That said we don't keep track how the user enabled the breakpoints
      so when the user requests the dr7 value, we only translate the
      "enabled" status using the global enabled bits. It means that if
      the user enabled a breakpoint using the local enabled bit, reading
      back dr7 will set the global bit and clear the local one.
      
      Apps like Wine expect a full dr7 POKEUSER/PEEKUSER match for emulated
      softwares that implement old reverse engineering protection schemes.
      
      We fix that by keeping track of the whole dr7 value given by the user
      in the thread structure to drop this bug. We'll think about
      something more proper later.
      
      This fixes a 2.6.32 - 2.6.33-x ptrace regression.
      Reported-and-tested-by: NMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NK.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Maneesh Soni <maneesh@linux.vnet.ibm.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      326264a0
    • F
      hw-breakpoints: Accept breakpoints on NULL address · 84d71092
      Frederic Weisbecker 提交于
      Before we had a generic breakpoint API, ptrace was accepting
      breakpoints on NULL address in x86. The new API refuse them,
      without given strong reasons. We need to follow the previous
      behaviour as some userspace apps like Wine need such NULL
      breakpoints to ensure old emulated software protections
      are still working.
      
      This fixes a 2.6.32 - 2.6.33-x ptrace regression.
      Reported-and-tested-by: NMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NK.Prasad <prasad@linux.vnet.ibm.com>
      Acked-by: NRoland McGrath <roland@redhat.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Maneesh Soni <maneesh@linux.vnet.ibm.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      84d71092
  6. 19 2月, 2010 2 次提交
  7. 18 2月, 2010 4 次提交
  8. 17 2月, 2010 2 次提交
  9. 16 2月, 2010 1 次提交
  10. 15 2月, 2010 1 次提交
    • P
      sh64: fix tracing of signals. · 4b505db9
      Paul Mundt 提交于
      This follows the parisc change to ensure that tracehook_signal_handler()
      is aware of when we are single-stepping in order to ptrace_notify()
      appropriately. While this was implemented for 32-bit SH, sh64 neglected
      to make use of TIF_SINGLESTEP when it was folded in with the 32-bit code,
      resulting in ptrace_notify() never being called.
      
      As sh64 uses all of the other abstractions already, this simply plugs in
      the thread flag in the appropriate enable/disable paths and fixes up the
      tracehook notification accordingly. With this in place, sh64 is brought
      in line with what 32-bit is already doing.
      Reported-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      4b505db9
  11. 14 2月, 2010 2 次提交
    • P
      powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem · d1d47ec6
      Peter Tyser 提交于
      Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
      the "cpu-release-addr" device tree property to contain the physical RAM
      location that secondary cores were spinning at.  Previously, the
      "cpu-release-addr" property contained a value referencing the boot page
      translation address range of 0xfffffxxx, which then indirectly accessed
      RAM.
      
      The "cpu-release-addr" is currently ioremapped and the secondary cores
      kicked.  However, due to the recent change in "cpu-release-addr", it
      sometimes points to a memory location in low memory that cannot be
      ioremapped.  For example on a P2020-based board with 512MB of RAM the
      following error occurs on bootup:
      
        <...>
        mpic: requesting IPIs ...
        __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
        Unable to handle kernel paging request for data at address 0x00000014
        Faulting instruction address: 0xc05df9b0
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2 P2020 RDB
        Modules linked in:
        <... eventual kernel panic>
      
      Adding logic to conditionally ioremap or access memory directly resolves
      the issue.
      Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
      Signed-off-by: NNate Case <ncase@xes-inc.com>
      Reported-by: NDipen Dudhat <B09055@freescale.com>
      Tested-by: NDipen Dudhat <B09055@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      d1d47ec6
    • A
      powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards · fa644298
      Anton Vorontsov 提交于
      MPC85xx chips report the wrong value in feature reporting register,
      and that causes the following oops:
      
       Unable to handle kernel paging request for data at address 0x00000c00
       Faulting instruction address: 0xc0019294
       Oops: Kernel access of bad area, sig: 11 [#1]
       MPC8569 MDS
       Modules linked in:
       [...]
       NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
       LR [c0019124] mpic_set_irq_type+0x180/0x368
       Call Trace:
       [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
       [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
       [ef851db0] [c007b550] set_irq_type+0x40/0x7c
       [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
       [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
       [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
       [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
       [...]
      
      This is because mpic_alloc() assigns wrong values to
      mpic->isu_{size,shift,mask}, and things eventually break when
      _mpic_irq_read() is trying to use them.
      
      This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      fa644298
  12. 13 2月, 2010 3 次提交
  13. 12 2月, 2010 1 次提交
  14. 11 2月, 2010 6 次提交
  15. 10 2月, 2010 6 次提交