1. 22 10月, 2010 1 次提交
    • A
      x86, kexec: Make sure to stop all CPUs before exiting the kernel · 76fac077
      Alok Kataria 提交于
      x86 smp_ops now has a new op, stop_other_cpus which takes a parameter
      "wait" this allows the caller to specify if it wants to stop until all
      the cpus have processed the stop IPI.  This is required specifically
      for the kexec case where we should wait for all the cpus to be stopped
      before starting the new kernel.  We now wait for the cpus to stop in
      all cases except for panic/kdump where we expect things to be broken
      and we are doing our best to make things work anyway.
      
      This patch fixes a legitimate regression, which was introduced during
      2.6.30, by commit id 4ef702c1.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: <stable@kernel.org> v2.6.30-36
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      76fac077
  2. 20 6月, 2010 1 次提交
  3. 17 2月, 2010 1 次提交
  4. 28 1月, 2010 1 次提交
  5. 05 12月, 2009 1 次提交
    • L
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara 提交于
      Bug reporter noted their system with an ASUS P4S800 motherboard would
      hang when rebooting unless reboot=b was specified.  Their dmidecode
      didn't contain descriptive System Information for Manufacturer or
      Product Name, so I used their Base Board Information to create a
      reboot quirk patch.  The bug reporter confirmed this patch resolves
      the reboot hang.
      
      Handle 0x0001, DMI type 1, 25 bytes
      System Information
             Manufacturer: System Manufacturer
             Product Name: System Name
             Version: System Version
             Serial Number: SYS-1234567890
             UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F
             Wake-up Type: Power Switch
      
      Handle 0x0002, DMI type 2, 8 bytes
      Base Board Information
           Manufacturer: ASUSTeK Computer INC.
           Product Name: P4S800
           Version: REV 1.xx
           Serial Number: xxxxxxxxxxx
      
      BugLink: http://bugs.launchpad.net/bugs/366682
      
      ASUS P4S800 will hang when rebooting unless reboot=b is specified.
      Add a quirk to reboot through the bios.
      Signed-off-by: NLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
  6. 08 11月, 2009 1 次提交
    • F
      x86: Use x86_platform for iommu_shutdown · 338bac52
      FUJITA Tomonori 提交于
      This patch cleans up pci_iommu_shutdown() a bit to use
      x86_platform (similar to how IA64 initializes an IOMMU driver).
      
      This adds iommu_shutdown() to x86_platform to avoid calling
      every IOMMUs' shutdown functions in pci_iommu_shutdown() in
      order. The IOMMU shutdown functions are platform specific (we
      don't have multiple different IOMMU hardware) so the current way
      is pointless.
      
      An IOMMU driver sets x86_platform.iommu_shutdown to the shutdown
      function if necessary.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: joerg.roedel@amd.com
      LKML-Reference: <20091027163358F.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      338bac52
  7. 02 11月, 2009 1 次提交
  8. 12 10月, 2009 1 次提交
  9. 02 9月, 2009 1 次提交
  10. 11 8月, 2009 1 次提交
  11. 08 8月, 2009 1 次提交
  12. 04 8月, 2009 1 次提交
    • P
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      Paul Mackerras 提交于
      The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
      under Linux; neither the EFI reboot method nor the default method
      using the keyboard controller works (the system just hangs and doesn't
      reset).  However, the method using the "PCI reset register" at 0xcf9
      does work.
      
      This adds a quirk to detect this machine via DMI and force the
      reboot_type to BOOT_CF9.  With this it reboots successfully without
      requiring a command-line option.  Note that the EFI code forces
      reboot_type to BOOT_EFI when the machine is booted via EFI, but this
      overrides that since the core_initcall runs after the EFI
      initialization code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
  13. 22 7月, 2009 1 次提交
    • J
      x86, intel_txt: Intel TXT reboot/halt shutdown support · 840c2baf
      Joseph Cihula 提交于
      Support for graceful handling of kernel reboots after an Intel(R) TXT launch.
      
      Without this patch, attempting to reboot or halt the system will cause the
      TXT hardware to lock memory upon system restart because the secrets-in-memory
      flag that was set on launch was never cleared.  This will in turn cause BIOS
      to execute a TXT Authenticated Code Module (ACM) that will scrub all of memory
      and then unlock it.  Depending on the amount of memory in the system and its type,
      this may take some time.
      
      This patch creates a 1:1 address mapping to the tboot module and then calls back
      into tboot so that it may properly and securely clean up system state and clear
      the secrets-in-memory flag.  When it has completed these steps, the tboot module
      will reboot or halt the system.
      
       arch/x86/kernel/reboot.c |    8 ++++++++
       init/main.c              |    3 +++
       2 files changed, 11 insertions(+)
      Signed-off-by: NJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: NShane Wang <shane.wang@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      840c2baf
  14. 21 7月, 2009 1 次提交
  15. 07 6月, 2009 1 次提交
  16. 22 5月, 2009 1 次提交
  17. 08 4月, 2009 1 次提交
  18. 05 3月, 2009 1 次提交
  19. 18 2月, 2009 2 次提交
  20. 29 1月, 2009 2 次提交
  21. 08 1月, 2009 1 次提交
  22. 04 1月, 2009 1 次提交
  23. 31 12月, 2008 1 次提交
    • E
      x86: disable VMX on all CPUs on reboot · d176720d
      Eduardo Habkost 提交于
      On emergency_restart, we may need to use an NMI to disable virtualization
      on all CPUs. We do that using nmi_shootdown_cpus() if VMX is enabled.
      
      Note: With this patch, we will run the NMI stuff only when the CPU where
      emergency_restart() was called has VMX enabled. This should work on most
      cases because KVM enables VMX on all CPUs, but we may miss the small
      window where KVM is doing that. Also, I don't know if all code using
      VMX out there always enable VMX on all CPUs like KVM does. We have two
      other alternatives for that:
      
      a) Have an API that all code that enables VMX on any CPU should use
         to tell the kernel core that it is going to enable VMX on the CPUs.
      b) Always call nmi_shootdown_cpus() if the CPU supports VMX. This is
         a bit intrusive and more risky, as it would run nmi_shootdown_cpus()
         on emergency_reboot() even on systems where virtualization is never
         enabled.
      
      Finding a proper point to hook the nmi_shootdown_cpus() call isn't
      trivial, as the non-emergency machine_restart() (that doesn't need the
      NMI tricks) uses machine_emergency_restart() directly.
      
      The solution to make this work without adding a new function or argument
      to machine_ops was setting a 'reboot_emergency' flag that tells if
      native_machine_emergency_restart() needs to do the virt cleanup or not.
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      d176720d
  24. 30 12月, 2008 1 次提交
  25. 27 12月, 2008 1 次提交
  26. 24 11月, 2008 1 次提交
    • H
      x86: drop REBOOT_CF9_COND from reboot fallback chain · b47b9288
      H. Peter Anvin 提交于
      Impact: Reverts sequence of reboot fallbacks
      
      Checkin 14d7ca5c changed the default
      reboot method to "pci", a.k.a. port CF9.  Unfortunately this has been
      shown to cause lockups on at least two systems for which REBOOT_KBD
      worked, both Thinkpads with Intel chipsets.  Checkin
      3889d0ce reverted the default, but did
      not revert the fallback chain.  This checkin reverts the fallback
      chain; port CF9 is now only done by explicit "reboot=pci" or a future
      potential DMI key.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      b47b9288
  27. 23 11月, 2008 1 次提交
    • H
      x86: revert default reboot method to REBOOT_KBD · 3889d0ce
      H. Peter Anvin 提交于
      Impact: Reverts default reboot method.
      
      Checkin 14d7ca5c changed the default
      reboot method to "pci", a.k.a. port CF9.  Unfortunately this has been
      shown to cause lockups on at least two systems for which REBOOT_KBD
      worked, both Thinkpads with Intel chipsets.  This reverts the default
      to REBOOT_KBD, while leaving the option to have "reboot=pci" specified
      explicitly or via a DMI match.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      3889d0ce
  28. 19 11月, 2008 1 次提交
  29. 13 11月, 2008 3 次提交
  30. 12 11月, 2008 1 次提交
    • H
      x86: attempt reboot via port CF9 if we have standard PCI ports · 14d7ca5c
      H. Peter Anvin 提交于
      Impact: Changes reboot behavior.
      
      If port CF9 seems to be safe to touch, attempt it before trying the
      keyboard controller.  Port CF9 is not available on all chipsets (a
      significant but decreasing number of modern chipsets don't implement
      it), but port CF9 itself should in general be safe to poke (no ill
      effects if unimplemented) on any system which has PCI Configuration
      Method #1 or #2, as it falls inside the PCI configuration port range
      in both cases.  No chipset without PCI is known to have port CF9,
      either, although an explicit "pci=bios" would mean we miss this and
      therefore don't use port CF9.  An explicit "reboot=pci" can be used to
      force the use of port CF9.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      14d7ca5c
  31. 11 11月, 2008 1 次提交
    • I
      x86: call machine_shutdown and stop all CPUs in native_machine_halt · d3ec5cae
      Ivan Vecera 提交于
      Impact: really halt all CPUs on halt
      
      Function machine_halt (resp. native_machine_halt) is empty for x86
      architectures. When command 'halt -f' is invoked, the message "System
      halted." is displayed but this is not really true because all CPUs are
      still running.
      
      There are also similar inconsistencies for other arches (some uses
      power-off for halt or forever-loop with IRQs enabled/disabled).
      
      IMO there should be used the same approach for all architectures OR
      what does the message "System halted" really mean?
      
      This patch fixes it for x86.
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3ec5cae
  32. 06 11月, 2008 1 次提交
  33. 25 8月, 2008 1 次提交
    • A
      x86: default to reboot via ACPI · c7ffa6c2
      Avi Kivity 提交于
      Triple-fault and keyboard reset may assert INIT instead of RESET; however
      INIT is blocked when Intel VT is enabled.  This leads to a partially reset
      machine when invoking emergency_restart via sysrq-b: the processor is still
      working but other parts of the system are dead.
      
      Default to rebooting via ACPI, which correctly asserts RESET and reboots the
      machine.
      
      This is safe since we will fall back to keyboard reset and triple fault if
      acpi is not enabled or if the reset is not successful.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7ffa6c2
  34. 26 7月, 2008 1 次提交
  35. 19 7月, 2008 1 次提交
    • M
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      Mike Travis 提交于
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
          with new cpumask_of_cpu_ptr macros.  These are patterned after the
          node_to_cpumask_ptr macros.
      
          In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
          the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
          is provided when there is a large NR_CPUS count, reducing
          greatly the amount of code generated and stack space used for
          cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
          calling set_cpus_allowed_ptr() to reduce the amount of stack space
          needed to pass the cpumask_t value.
      
          If there isn't a cpumask_of_cpu_map[], then a temporary variable is
          declared and filled in with value from cpumask_of_cpu(cpu) as well as
          a pointer variable pointing to this temporary variable.  Afterwards,
          the pointer is used to reference the cpumask value.  The compiler
          will optimize out the extra dereference through the pointer as well
          as the stack space used for the pointer, resulting in identical code.
      
          A good example of the orthogonal usages is in net/sunrpc/svc.c:
      
      	case SVC_POOL_PERCPU:
      	{
      		unsigned int cpu = m->pool_to[pidx];
      		cpumask_of_cpu_ptr(cpumask, cpu);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, cpumask);
      		return 1;
      	}
      	case SVC_POOL_PERNODE:
      	{
      		unsigned int node = m->pool_to[pidx];
      		node_to_cpumask_ptr(nodecpumask, node);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, nodecpumask);
      		return 1;
      	}
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      65c01184
  36. 17 7月, 2008 1 次提交