1. 20 3月, 2014 1 次提交
    • V
      x86, boot: Create a separate string.h file to provide standard string functions · c041b5ad
      Vivek Goyal 提交于
      Create a separate arch/x86/boot/string.h file to provide declaration of
      some of the common string functions.
      
      By default memcpy, memset and memcmp functions will default to gcc
      builtin functions. If code wants to use an optimized version of any
      of these functions, they need to #undef the respective macro and link
      against a local file providing definition of undefed function.
      
      For example, arch/x86/boot/* code links against copy.S to get memcpy()
      and memcmp() definitions. arch/86/boot/compressed/* links against
      compressed/string.c.
      
      There are quite a few places in arch/x86/ where these functions are
      used. Idea is to try to consilidate  their declaration and possibly
      definitions so that it can be reused.
      
      I am planning to reuse boot/string.h in arch/x86/purgatory/ and use
      gcc builtin functions for memcpy, memset and memcmp.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Link: http://lkml.kernel.org/r/1395170800-11059-3-git-send-email-vgoyal@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c041b5ad
  2. 10 4月, 2009 1 次提交
  3. 04 10月, 2008 2 次提交
  4. 06 9月, 2008 1 次提交
    • A
      x86: fix ghost EDD devices in /sys again · 464f04c9
      Andrey Borzenkov 提交于
      > This is regression but old enough. Apparently I had for whatever reasons
      > EDD turned off till recently. This is 2.6.27-rc5 just in case.
      >
      > In 2006 I fixed ghost devices due to buggy BIOS:
      >
      > http://marc.info/?l=linux-kernel&m=114087765422490&w=2
      >
      > Later edd.S has been rewritten in C, and apparently this patch has been
      > lost:
      >
      > {pts/1}% ls /sys/firmware/edd
      > int13_dev80/  int13_dev84/  int13_dev88/  int13_dev8c/
      > int13_dev81/  int13_dev85/  int13_dev89/  int13_dev8d/
      > int13_dev82/  int13_dev86/  int13_dev8a/  int13_dev8e/
      > int13_dev83/  int13_dev87/  int13_dev8b/  int13_dev8f/
      >
      > But I have just a single disk. This is the same system BTW.
      
      Some BIOSes do not always set CF on error before return from int13.
      The patch adds additional check for status being zero (AH == 0).
      
      This was fixed for edd.S in
      http://marc.info/?l=linux-kernel&m=114087765422490&w=2, but lost
      again when edd.S was rewritten in C.
      Signed-off-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      464f04c9
  5. 19 7月, 2008 1 次提交
  6. 29 4月, 2008 1 次提交
  7. 20 4月, 2008 1 次提交
  8. 30 1月, 2008 3 次提交
  9. 11 10月, 2007 1 次提交
  10. 24 8月, 2007 1 次提交
    • H
      [x86 setup] Volatilize asm() statements · b015124e
      H. Peter Anvin 提交于
      asm() statements need to be volatile when:
      
      a. They have side effects (other than value returned).
      b. When the value returned can vary over time.
      c. When they have ordering constraints that cannot be expressed to gcc.
      
      In particular, the keyboard and timer reads were violating constraint (b),
      which resulted in the keyboard/timeout poll getting
      loop-invariant-removed when compiling with gcc 4.2.0.
      
      Thanks to an anonymous bug reporter for pointing this out.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      b015124e
  11. 15 8月, 2007 2 次提交
    • H
      [x86 setup] edd.c: make sure MBR signatures actually get reported · 9a5f35d4
      H. Peter Anvin 提交于
      When filling in the MBR signature array, the setup code failed to advance
      boot_params.edd_mbr_sig_buf_entries, which resulted in the valid data
      being ignored.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      9a5f35d4
    • H
      [x86 setup] Don't use EDD to get the MBR signature · c1a6e2b0
      H. Peter Anvin 提交于
      At least one machine has been identified in the field which advertises
      EDD for all drives but locks up if one attempts an extended read from
      a non-primary drive.
      
      The MBR is always at CHS 0-0-1, so there is no reason to use an
      extended read, other than the possibility that the BIOS cannot handle
      it.
      
      Although this might break as many machines as it fixes (a small number
      either way), the current state is a regression but the reverse is not.
      Therefore revert to the previous state of not using extended read.
      
      Quite probably the Right Thing to do is to read using plain (CHS) read
      and extended read on failure, but that change would definitely have to
      go through -mm first.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      c1a6e2b0
  12. 03 8月, 2007 1 次提交
  13. 01 8月, 2007 1 次提交
  14. 13 7月, 2007 1 次提交