1. 08 7月, 2010 1 次提交
    • H
      x86, alternatives: Use 16-bit numbers for cpufeature index · 83a7a2ad
      H. Peter Anvin 提交于
      We already have cpufeature indicies above 255, so use a 16-bit number
      for the alternatives index.  This consumes a padding field and so
      doesn't add any size, but it means that abusing the padding field to
      create assembly errors on overflow no longer works.  We can retain the
      test simply by redirecting it to the .discard section, however.
      
      [ v3: updated to include open-coded locations ]
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      LKML-Reference: <tip-f88731e3068f9d1392ba71cc9f50f035d26a0d4f@git.kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      83a7a2ad
  2. 19 6月, 2010 1 次提交
  3. 11 6月, 2010 1 次提交
  4. 10 6月, 2010 1 次提交
    • E
      x86, irq: Rename gsi_end gsi_top, and fix off by one errors · a4384df3
      Eric W. Biederman 提交于
      When I introduced the global variable gsi_end I thought gsi_end on
      io_apics was one past the end of the gsi range for the io_apic.  After
      it was pointed out the the range on io_apics was inclusive I changed
      my global variable to match.  That was a big mistake.  Inclusive
      semantics without a range start cannot describe the case when no gsi's
      are allocated.  Describing the case where no gsi's are allocated is
      important in sfi.c and mpparse.c so that we can assign gsi numbers
      instead of blindly copying the gsi assignments the BIOS has done as we
      do in the acpi case.
      
      To keep from getting the global variable confused with the gsi range
      end rename it gsi_top.
      
      To allow describing the case where no gsi's are allocated have gsi_top
      be one place the highest gsi number seen in the system.
      
      This fixes an off by one bug in sfi.c:
      Reported-by: Njacob pan <jacob.jun.pan@linux.intel.com>
      
      This fixes the same off by one bug in mpparse.c:
      
      This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
      Reported-by: NYinghai <yinghai.lu@oracle.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4384df3
  5. 09 6月, 2010 1 次提交
  6. 08 6月, 2010 2 次提交
  7. 28 5月, 2010 6 次提交
  8. 25 5月, 2010 1 次提交
  9. 21 5月, 2010 2 次提交
  10. 20 5月, 2010 1 次提交
    • H
      ACPI, APEI, Generic Hardware Error Source memory error support · d334a491
      Huang Ying 提交于
      Generic Hardware Error Source provides a way to report platform
      hardware errors (such as that from chipset). It works in so called
      "Firmware First" mode, that is, hardware errors are reported to
      firmware firstly, then reported to Linux by firmware. This way, some
      non-standard hardware error registers or non-standard hardware link
      can be checked by firmware to produce more valuable hardware error
      information for Linux.
      
      Now, only SCI notification type and memory errors are supported. More
      notification type and hardware error type will be added later. These
      memory errors are reported to user space through /dev/mcelog via
      faking a corrected Machine Check, so that the error memory page can be
      offlined by /sbin/mcelog if the error count for one page is beyond the
      threshold.
      
      On some machines, Machine Check can not report physical address for
      some corrected memory errors, but GHES can do that. So this simplified
      GHES is implemented firstly.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d334a491
  11. 19 5月, 2010 9 次提交
  12. 18 5月, 2010 2 次提交
  13. 17 5月, 2010 12 次提交