1. 18 7月, 2008 1 次提交
    • M
      x86: APIC: remove apic_write_around(); use alternatives · 593f4a78
      Maciej W. Rozycki 提交于
      Use alternatives to select the workaround for the 11AP Pentium erratum
      for the affected steppings on the fly rather than build time.  Remove the
      X86_GOOD_APIC configuration option and replace all the calls to
      apic_write_around() with plain apic_write(), protecting accesses to the
      ESR as appropriate due to the 3AP Pentium erratum.  Remove
      apic_read_around() and all its invocations altogether as not needed.
      Remove apic_write_atomic() and all its implementing backends.  The use of
      ASM_OUTPUT2() is not strictly needed for input constraints, but I have
      used it for readability's sake.
      
      I had the feeling no one else was brave enough to do it, so I went ahead
      and here it is.  Verified by checking the generated assembly and tested
      with both a 32-bit and a 64-bit configuration, also with the 11AP
      "feature" forced on and verified with gdb on /proc/kcore to work as
      expected (as an 11AP machines are quite hard to get hands on these days).
      Some script complained about the use of "volatile", but apic_write() needs
      it for the same reason and is effectively a replacement for writel(), so I
      have disregarded it.
      
      I am not sure what the policy wrt defconfig files is, they are generated
      and there is risk of a conflict resulting from an unrelated change, so I
      have left changes to them out.  The option will get removed from them at
      the next run.
      
      Some testing with machines other than mine will be needed to avoid some
      stupid mistake, but despite its volume, the change is not really that
      intrusive, so I am fairly confident that because it works for me, it will
      everywhere.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      593f4a78
  2. 03 7月, 2008 2 次提交
  3. 26 6月, 2008 1 次提交
  4. 18 6月, 2008 3 次提交
  5. 13 5月, 2008 1 次提交
    • V
      x86: remove 6 bank limitation in 64 bit MCE reporting code · 8edc5cc5
      Venki Pallipadi 提交于
      Eliminate the 6 bank restriction in 64 bit mce reporting code. This
      restriction is artificial (due to static creation of sysfs files) and 32
      bit code does not have any such restriction.
      
      This change helps in reporting the details of machine checks on a
      machine check exception with errors in bank 6 and above on CPUs that
      support those banks. Without the patch, machine check errors in those
      banks are not reported.
      
      We still have 128 (MCE_EXTENDED_BANK) bank restriction instead of max
      256 supported in hardware. That is not changed in the patch below as it
      will have some user level mcelog utility dependency, with bank 128 being
      used for thermal reporting currently.
      
      The patch below does not create sysfs control (bankNctl) for banks
      higher than 6 as well. That needs some pre-cleanup in /sysfs mce layout,
      removal of per cpu /sysfs entries for bankctl as they are really global
      system level control today. That change will follow. This basic change
      is critical to report the detailed errors on banks higher than 6.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8edc5cc5
  6. 26 4月, 2008 1 次提交
    • J
      x86-64: extend MCE CPU quirk handling · 911f6a7b
      Jan Beulich 提交于
      At least on my Barcelona, I see MCE log entries after cold boot caused
      by BIOS not properly clearing the respective registers. Therefore, this
      patch extends the workaround to families 0x10 and 0x11 (the latter just
      for completeness, I have nothing to verify this against).
      At the same time, provide a way to make these entries visible via the
      'mce=bootlog' command line option even on these machines.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      911f6a7b
  7. 20 4月, 2008 2 次提交
  8. 17 4月, 2008 5 次提交
  9. 10 2月, 2008 1 次提交
  10. 30 1月, 2008 15 次提交
  11. 28 1月, 2008 1 次提交
    • G
      x86: fix runtime error in arch/x86/kernel/cpu/mcheck/mce_amd_64.c · 404aae5d
      Greg Kroah-Hartman 提交于
      This problem is due to the kobject rework recently done in this file.
      
      The mce_amd_64.c code uses some wierd forward calls to back out of the
      recursive way the code creates kobjects.  Because of this, we need to
      verify that we have really created a kobject before calling
      kobject_uevent().
      
      Many thanks to Yinghai Lu <yhlu.kernel@gmail.com> for reporting the
      problem and testing.
      
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jacob Shin <jacob.shin@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      404aae5d
  12. 25 1月, 2008 4 次提交
  13. 17 11月, 2007 1 次提交
    • A
      x86: fix cpu-hotplug regression · 90367556
      Andreas Herrmann 提交于
      Commit d435d862
      ("cpu hotplug: mce: fix cpu hotplug error handling")
      changed the error handling in mce_cpu_callback.
      
      In cases where not all CPUs are brought up during
      boot (e.g. using maxcpus and additional_cpus parameters)
      mce_cpu_callback now returns NOTFIY_BAD because
      for such CPUs cpu_data is not completely filled when
      the notifier is called. Thus mce_create_device fails right
      at its beginning:
      
              if (!mce_available(&cpu_data[cpu]))
                      return -EIO;
      
      As a quick fix I suggest to check boot_cpu_data for MCE.
      
      To reproduce this regression:
      
      (1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system
      (2) # echo 1 >/sys/devices/system/cpu/cpu2/online
        -bash: echo: write error: Invalid argument
      
      dmesg shows:
      
      _cpu_up: attempt to bring up CPU 2 failed
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      90367556
  14. 15 11月, 2007 1 次提交
    • A
      x86: don't call mce_create_device on CPU_UP_PREPARE · bae19fe0
      Andreas Herrmann 提交于
      Fix regression introduced with d435d862
      ("cpu hotplug: mce: fix cpu hotplug error handling").
      
      A CPU which was not brought up during boot (using maxcpus and
      additional_cpus parameters) couldn't be onlined anymore.  For such a CPU it
      seemed that MCE was not supported during CPU_UP_PREPARE-time which caused
      mce_cpu_callback to return NOTIFY_BAD to notifier_call_chain.  To fix this
      we:
      
       - call mce_create_device for CPU_ONLINE event (instead of CPU_UP_PREPARE),
       - avoid mce_remove_device() for the CPU that is not correctly initialized
         by mce_create_device() failure,
       - make mce_cpu_callback always return NOTIFY_OK for CPU_ONLINE event.
         Because CPU_ONLINE callback return value is always ignored.
      
      [akinobu.mita@gmail.com: avoid mce_remove_device() for not initialized device]
      [akinobu.mita@gmail.com: make mce_cpu_callback always return NOTIFY_OK]
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bae19fe0
  15. 24 10月, 2007 1 次提交