1. 23 9月, 2008 1 次提交
    • S
      signals: demultiplexing SIGTRAP signal · da654b74
      Srinivasa Ds 提交于
      Currently a SIGTRAP can denote any one of below reasons.
      	- Breakpoint hit
      	- H/W debug register hit
      	- Single step
      	- Signal sent through kill() or rasie()
      
      Architectures like powerpc/parisc provides infrastructure to demultiplex
      SIGTRAP signal by passing down the information for receiving SIGTRAP through
      si_code of siginfot_t structure. Here is an attempt is generalise this
      infrastructure by extending it to x86 and x86_64 archs.
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: akpm@linux-foundation.org
      Cc: paulus@samba.org
      Cc: linuxppc-dev@ozlabs.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      da654b74
  2. 21 9月, 2008 4 次提交
  3. 20 9月, 2008 6 次提交
  4. 18 9月, 2008 5 次提交
  5. 17 9月, 2008 4 次提交
  6. 16 9月, 2008 1 次提交
  7. 15 9月, 2008 1 次提交
  8. 14 9月, 2008 7 次提交
  9. 13 9月, 2008 2 次提交
    • D
      sparc: Fix user_regset 'n' field values. · 7d4ee289
      David S. Miller 提交于
      As noticed by Russell King, we were not setting this properly
      to the number of entries, but rather the total size.
      
      This results in the core dumping code allocating waayyyy too
      much memory.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4ee289
    • D
      sparc64: Fix PCI error interrupt registry on PSYCHO. · 80a56ab6
      David S. Miller 提交于
      We need to pass IRQF_SHARED, otherwise we get things like:
      
      IRQ handler type mismatch for IRQ 33
      current handler: PSYCHO_UE
      Call Trace:
       [000000000048394c] request_irq+0xac/0x120
       [00000000007c5f6c] psycho_scan_bus+0x98/0x158
       [00000000007c2bc0] pcibios_init+0xdc/0x12c
       [0000000000426a5c] do_one_initcall+0x1c/0x160
       [00000000007c0180] kernel_init+0x9c/0xfc
       [0000000000427050] kernel_thread+0x30/0x60
       [00000000006ae1d0] rest_init+0x10/0x60
      
      on e3500 and similar systems.
      
      On a single board, the UE interrupts of two Psycho nodes
      are funneled through the same interrupt, from of_debug=3
      dump:
      
      /pci@b,4000: direct translate 2ee --> 21
       ...
      /pci@b,2000: direct translate 2ee --> 21
      
      Decimal "33" mentioned above is the hex "21" mentioned here.
      
      Thanks to Meelis Roos for dumps and testing.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80a56ab6
  10. 12 9月, 2008 2 次提交
    • J
      x86: fix possible x86_64 and EFI regression · 0ad5bce7
      Jeremy Fitzhardinge 提交于
      Russ Anderson reported a boot crash with EFI and latest mainline:
      
       BIOS-e820: 00000000fffa0000 - 00000000fffac000 (reserved)
      Pid: 0, comm: swapper Not tainted 2.6.27-rc5-00100-gec0c15af-dirty #5
      
      Call Trace:
       [<ffffffff80849195>] early_idt_handler+0x55/0x69
       [<ffffffff80313e52>] __memcpy+0x12/0xa4
       [<ffffffff80859015>] efi_init+0xce/0x932
       [<ffffffff80869c83>] setup_early_serial8250_console+0x2d/0x36a
       [<ffffffff80238688>] __insert_resource+0x18/0xc8
       [<ffffffff8084f6de>] setup_arch+0x3a7/0x632
       [<ffffffff808499ed>] start_kernel+0x91/0x367
       [<ffffffff80849393>] x86_64_start_kernel+0xe3/0xe7
       [<ffffffff808492b0>] x86_64_start_kernel+0x0/0xe7
      
       RIP 0x10
      
      Such a crash is possible if the CPU in this system is a 64-bit
      processor which doesn't support NX (ie, old Intel P4 -based64-bit
      processors).
      
      Certainly, if we support such processors, then we should start with
      _PAGE_NX initially clear in __supported_pte_flags, and then set it once
      we've established that the processor does indeed support NX.  That will
      prevent early_ioremap - or anything else - from trying to set it.
      
      The simple fix is to simply call check_efer() earlier.
      Reported-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0ad5bce7
    • D
      MN10300: Change the fault handler to check in_atomic() not in_interrupt() · d1c6d2e5
      David Howells 提交于
      Change the MN10300 fault handler to make it check in_atomic() rather than
      in_interrupt() as commit 6edaf68a did for other
      architectures:
      
      	Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      	Date:   Wed Dec 6 20:32:18 2006 -0800
      
      	[PATCH] mm: arch do_page_fault() vs in_atomic()
      
      	In light of the recent pagefault and filemap_copy_from_user work I've
      	gone through all the arch pagefault handlers to make sure the
      	inc_preempt_count() 'feature' works as expected.
      
      	Several sections of code (including the new filemap_copy_from_user)
      	rely on the fact that faults do not take locks under increased preempt
      	count.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d1c6d2e5
  11. 11 9月, 2008 7 次提交