1. 08 3月, 2008 1 次提交
    • R
      x86_64: make ptrace always sign-extend orig_ax to 64 bits · 84c6f604
      Roland McGrath 提交于
      This makes 64-bit ptrace calls setting the 64-bit orig_ax field for a
      32-bit task sign-extend the low 32 bits up to 64.  This matches what a
      64-bit debugger expects when tracing a 32-bit task.
      
      This follows on my "x86_64 ia32 syscall restart fix".  This didn't
      matter until that was fixed.
      
      The debugger ignores or zeros the high half of every register slot it
      sets (including the orig_rax pseudo-register) uniformly.  It expects
      that the setting of the low 32 bits always has the same meaning as a
      32-bit debugger setting those same 32 bits with native 32-bit
      facilities.
      
      This never arose before because the syscall restart check never
      matched any -ERESTART* values due to lack of sign extension.  Before
      that fix, even 32-bit ptrace setting orig_eax to -1 failed to trigger
      the restart check anyway.  So this was never noticed as a regression
      of 64-bit debuggers vs 32-bit debuggers on the same 64-bit kernel.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      [ Changed to just do the sign-extension unconditionally on x86-64,
        since orig_ax is always just a small integer and doesn't need
        the full 64-bit range ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84c6f604
  2. 07 3月, 2008 11 次提交
    • P
      x86-boot: don't request VBE2 information · 1722770f
      Peter Korsgaard 提交于
      The new x86 setup code (4fd06960) broke booting on an old P3/500MHz
      with an onboard Voodoo3 of mine. After debugging it, it turned out
      to be caused by the fact that the vesa probing now asks for VBE2 data.
      
      Disassembing the video BIOS shows that it overflows the vesa_general_info
      structure when VBE2 data is requested because the source addresses for the
      information strings which get strcpy'ed to the buffer lie outside the 32K
      BIOS code (and hence contain long sequences of 0xff's).
      
      E.G.:
      
      get_vbe_controller_info:
      00002A9C  60                pushaw
      00002A9D  1E                push ds
      00002A9E  0E                push cs
      00002A9F  1F                pop ds
      00002AA0  2BC9              sub cx,cx
      00002AA2  6626813D56424532  cmp dword [es:di],0x32454256 ; "VBE2"
      00002AAA  7501              jnz .1
      00002AAC  41                inc cx
      .1:
      00002AAD  51                push cx
      00002AAE  B91400            mov cx,0x14
      00002AB1  BED47F            mov si, controller_header
      00002AB4  57                push di
      00002AB5  F3A4              rep movsb ; copy vbe1.2 header
      
      00002AB7  B9EC00            mov cx,0xec
      00002ABA  2AC0              sub al,al
      00002ABC  F3AA              rep stosb ; zero pad remainder
      
      00002ABE  5F                pop di
      00002ABF  E8EB0D            call word get_memory
      00002AC2  C1E002            shl ax,0x2
      00002AC5  26894512          mov [es:di+0x12],ax ; total memory
      00002AC9  26C745040003      mov word [es:di+0x4],0x300 ; VBE version
      00002ACF  268C4D08          mov [es:di+0x8],cs
      00002AD3  268C4D10          mov [es:di+0x10],cs
      00002AD7  59                pop cx
      00002AD8  E361              jcxz .done ; VBE2 requested?
      00002ADA  8D9D0001          lea bx,[di+0x100]
      00002ADE  53                push bx
      00002ADF  87DF              xchg bx,di ; di now points to 2nd half
      00002AE1  26C747140001      mov word [es:bx+0x14],0x100 ; sw rev
      
      00002AE7  26897F06          mov [es:bx+0x6],di		; oem string
      00002AEB  268C4708          mov [es:bx+0x8],es
      00002AEF  BE5280            mov si,0x8052 ; oem string
      00002AF2  E87A1B            call word strcpy
      
      00002AF5  26897F0E          mov [es:bx+0xe],di ; video mode list
      00002AF9  268C4710          mov [es:bx+0x10],es
      00002AFD  B91E00            mov cx,0x1e
      00002B00  BEE87F            mov si,vidmodes
      00002B03  F3A5              rep movsw
      
      00002B05  26897F16          mov [es:bx+0x16],di ; oem vendor
      00002B09  268C4718          mov [es:bx+0x18],es
      00002B0D  BE2480            mov si,0x8024 ; oem vendor
      00002B10  E85C1B            call word strcpy
      
      00002B13  26897F1A          mov [es:bx+0x1a],di ; oem product
      00002B17  268C471C          mov [es:bx+0x1c],es
      00002B1B  BE3880            mov si,0x8038 ; oem product
      00002B1E  E84E1B            call word strcpy
      
      00002B21  26897F1E          mov [es:bx+0x1e],di ; oem product rev
      00002B25  268C4720          mov [es:bx+0x20],es
      00002B29  BE4580            mov si,0x8045 ; oem product rev
      00002B2C  E8401B            call word strcpy
      
      00002B2F  58                pop ax
      00002B30  B90001            mov cx,0x100
      00002B33  2BCF              sub cx,di
      00002B35  03C8              add cx,ax
      00002B37  2AC0              sub al,al
      00002B39  F3AA              rep stosb ; zero pad
      .done:
      00002B3B  1F                pop ds
      00002B3C  61                popaw
      00002B3D  B84F00            mov ax,0x4f
      00002B40  C3                ret
      
      (The full BIOS can be found at http://peter.korsgaard.com/vgabios.bin
      if interested).
      
      The old setup code didn't ask for VBE2 info, and the new code doesn't
      actually do anything with the extra information, so the fix is to simply
      not request it. Other BIOS'es might have the same problem.
      Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1722770f
    • I
      x86: re-add reboot fixups · 7432d149
      Ingo Molnar 提交于
      Jan Beulich noticed that the reboot fixups went missing during
      reboot.c unification.
      
      (commit 4d022e35)
      
      Geode and a few other rare boards with special reboot quirks are
      affected.
      Reported-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7432d149
    • J
      x86: fix typo in step.c · d032b31a
      Jan Beulich 提交于
      TIF_DEBUGCTLMSR has no meaning in the actual MSR...
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d032b31a
    • J
      x86: fix merge mistake in i387.c · 609b5297
      Jan Beulich 提交于
      convert_fxsr_to_user() in 2.6.24's i387_32.c did this, and
      convert_to_fxsr() also does the inverse, so I assume it's an oversight
      that it is no longer being done.
      
      [ mingo@elte.hu:
      
        we encode it this way because there's no space for the 'FPU Last
        Instruction Opcode' (->fop) field in the legacy user_i387_ia32_struct
        that PTRACE_GETFPREGS/PTRACE_SETFPREGS uses.
      
        it's probably pure legacy - i'd be surprised if any user-space relied on
        the FPU Last Opcode in any way. But indeed we used to do it previously
        so the most conservative thing is to preserve that piece of information.
      ]
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      609b5297
    • A
      x86: clear DF before calling signal handler · e40cd10c
      Aurelien Jarno 提交于
      The Linux kernel currently does not clear the direction flag before
      calling a signal handler, whereas the x86/x86-64 ABI requires that.
      
      Linux had this behavior/bug forever, but this becomes a real problem
      with gcc version 4.3, which assumes that the direction flag is
      correctly cleared at the entry of a function.
      
      This patches changes the setup_frame() functions to clear the
      direction before entering the signal handler.
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      e40cd10c
    • H
      [IA64] kprobes arch consolidation build fix · 45e18c22
      Harvey Harrison 提交于
      ia64 named their handler kprobes_fault_handler while all other
      arches used kprobe_fault_handler.  Change the function definition
      and header declaration.
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      45e18c22
    • S
      [IA64] update efi region debugging to use MB, GB and TB as well as KB · 818c7e86
      Simon Horman 提交于
      When EFI_DEBUG is defined to a non-zero value in arch/ia64/kernel/efi.c,
      the efi memory regions are displayed. This patch enhances the
      display code in a few ways:
      
      1. Use TB, GB and MB as well as KB as units.
         Although this introduces rounding errors (KB doesn't as
         size is always a multiple of 4Kb), it does make
         things a lot more readable.
      
         Also as the range is also shown, it is possible to note the exact size
         if it is important. In my experience, the size field is mostly useful
         for getting a general idea of the size of a region.
      
         On the rx2620 that I use, there actually is an 8TB region (though not
         backed by physical memory, and 8TB really is a lot more readable than
         8589934592KB.
      
      2. pad the size field with leading spaces to further improve readability
      
         ...
         ... (   8MB)
         ... ( 928MB)
         ... (   3MB)
         ...
      
         vs
      
         ...
         ... (8MB)
         ... (928MB)
         ... (3MB)
         ...
      
      3. Pad the attr field out to 64bits using leading zeros,
         to further improve readability.
      
         ...
         mem05: type= 2, attr=0x0000000000000008, range=[0x0000000004000000-0x000000000481f000) (   8MB)
         mem06: type= 7, attr=0x0000000000000008, range=[0x000000000481f000-0x000000003e876000) ( 928MB)
         mem07: type= 5, attr=0x8000000000000008, range=[0x000000003e876000-0x000000003eb8e000) (   3MB)
         mem08: type= 4, attr=0x0000000000000008, range=[0x000000003eb8e000-0x000000003ee7a000) (   2MB)
         ...
      
         ...
         mem05: type= 2, attr=0x8, range=[0x0000000004000000-0x000000000481f000) (   8MB)
         mem06: type= 7, attr=0x8, range=[0x000000000481f000-0x000000003e876000) ( 928MB)
         mem07: type= 5, attr=0x8000000000000008, range=[0x000000003e876000-0x000000003eb8e000) (   3MB)
         mem08: type= 4, attr=0x8, range=[0x000000003eb8e000-0x000000003ee7a000) (   2MB)
         ...
      
      4. Use %d instead of %u for the index field, as i is a signed int.
      
      N.B: This code is not compiled unless EFI_DEBUG is non 0.
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      818c7e86
    • B
      [IA64] use dev_printk in video quirk · 1ab40ec8
      Bjorn Helgaas 提交于
      Convert quirk printks to dev_printk().
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1ab40ec8
    • H
      [IA64] remove remaining __FUNCTION__ occurrences · d4ed8084
      Harvey Harrison 提交于
      __FUNCTION__ is gcc-specific, use __func__
      
      Long lines have been kept where they exist, some small spacing changes
      have been done.
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      d4ed8084
    • K
      [IA64] remove unnecessary nfs includes from sys_ia32.c · 2d9b06c7
      KOSAKI Motohiro 提交于
      Compilation of 2.6.25-rc2-mm1 on ia64 generates many warnings.
      
      IA64 support 2 ELF format (IA64 binary and IA32 binary),
      thus if 2 elf related header included, cause many warning or error.
      
      about 2 week ago, J. Bruce Fields proposed this problem fixed patch.
      (http://marc.info/?l=linux-ia64&m=120329313305695&w=2)
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      2d9b06c7
    • B
      [IA64] remove CONFIG_SMP ifdef in ia64_send_ipi() · cd3244e6
      Bjorn Helgaas 提交于
      When !CONFIG_SMP, cpu_physical_id() is ia64_get_lid(), which is
      functionally identical to
      
          (ia64_getreg(_IA64_REG_CR_LID) >> 16) & 0xffff
      
      so there's no need for two versions of this code.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      cd3244e6
  3. 06 3月, 2008 19 次提交
  4. 05 3月, 2008 9 次提交