1. 06 Jun, 2012 1 commit
    • Feng Tang's avatar
      x86/reboot: Fix a warning message triggered by stop_other_cpus() · 55c844a4
      Feng Tang authored
      When rebooting our 24 CPU Westmere servers with 3.4-rc6, we
      always see this warning msg:
      
      Restarting system.
      machine restart
      ------------[ cut here ]------------
      WARNING: at arch/x86/kernel/smp.c:125
      native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN
      Modules linked in: igb [last unloaded: scsi_wait_scan]
      Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22
      Call Trace:
       <IRQ>  [<ffffffff8102a41f>] warn_slowpath_common+0x7e/0x96
       [<ffffffff8102a44c>] warn_slowpath_null+0x15/0x17
       [<ffffffff81018cf7>] native_smp_send_reschedule+0x74/0xa7
       [<ffffffff810561c1>] trigger_load_balance+0x279/0x2a6
       [<ffffffff81050112>] scheduler_tick+0xe0/0xe9
       [<ffffffff81036768>] update_process_times+0x60/0x70
       [<ffffffff81062f2f>] tick_sched_timer+0x68/0x92
       [<ffffffff81046e33>] __run_hrtimer+0xb3/0x13c
       [<ffffffff81062ec7>] ? tick_nohz_handler+0xd0/0xd0
       [<ffffffff810474f2>] hrtimer_interrupt+0xdb/0x198
       [<ffffffff81019a35>] smp_apic_timer_interrupt+0x81/0x94
       [<ffffffff81655187>] apic_timer_interrupt+0x67/0x70
       <EOI>  [<ffffffff8101a3c4>] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4
       [<ffffffff8101c680>] physflat_send_IPI_allbutself+0x12/0x14
       [<ffffffff81018db4>] native_nmi_stop_other_cpus+0x8a/0xd6
       [<ffffffff810188ba>] native_machine_shutdown+0x50/0x67
       [<ffffffff81018926>] machine_shutdown+0xa/0xc
       [<ffffffff8101897e>] native_machine_restart+0x20/0x32
       [<ffffffff810189b0>] machine_restart+0xa/0xc
       [<ffffffff8103b196>] kernel_restart+0x47/0x4c
       [<ffffffff8103b2e6>] sys_reboot+0x13e/0x17c
       [<ffffffff8164e436>] ? _raw_spin_unlock_bh+0x10/0x12
       [<ffffffff810fcac9>] ? bdi_queue_work+0xcf/0xd8
       [<ffffffff810fe82f>] ? __bdi_start_writeback+0xae/0xb7
       [<ffffffff810e0d64>] ? iterate_supers+0xa3/0xb7
       [<ffffffff816547a2>] system_call_fastpath+0x16/0x1b
      ---[ end trace 320af5cb1cb60c5b ]---
      
      The root cause seems to be the
      default_send_IPI_mask_allbutself_phys() takes quite some time (I
      measured it could be several ms) to complete sending NMIs to all
      the other 23 CPUs, and for HZ=250/1000 system, the time is long
      enough for a timer interrupt to happen, which will in turn
      trigger to kick load balance to a stopped CPU and cause this
      warning in native_smp_send_reschedule().
      
      So disabling the local irq before stop_other_cpu() can fix this
      problem (tested 25 times reboot ok), and it is fine as there
      should be nobody caring the timer interrupt in such reboot
      stage.
      
      The latest 3.4 kernel slightly changes this behavior by sending
      REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR
      fails, and this patch is still needed to prevent the problem.
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      55c844a4
  2. 04 Jun, 2012 1 commit
  3. 08 May, 2012 2 commits
  4. 07 Feb, 2012 2 commits
  5. 30 Jan, 2012 2 commits
    • Michael D Labriola's avatar
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola authored
      This commit removes the reboot quirk originally added by commit
      e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").
      
      Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
      6.5.102) revealed the following regarding the reboot hang
      problem:
      
      - v2.6.37 reboot=bios was needed.
      
      - v2.6.38-rc1: behavior changed, reboot=acpi is needed,
        reboot=kbd and reboot=bios results in system hang.
      
      - v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
        VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
        patch sets a quirk for VersaLogic Menlow boards that forces the use
        of reboot=bios, which doesn't work anymore.
      
      - v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method
        preferences") changed the default reboot method to acpi prior to
        v3.0-rc1, which means the default behavior is appropriate for the
        Ocelot.  No VersaLogic quirk is required.
      
      The Ocelot board used for testing can successfully reboot w/out
      having to pass any reboot= arguments for all 3 current versions
      of the BIOS.
      Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e6d36a65
    • Michael D Labriola's avatar
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola authored
      Skip DMI checks for vendor specific reboot quirks if the user
      passed in a reboot= arg on the command line - we should never
      override user choices.
      Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5955633e
  6. 05 Dec, 2011 2 commits
  7. 09 Oct, 2011 1 commit
  8. 21 Jul, 2011 2 commits
  9. 12 Jul, 2011 1 commit
  10. 05 Jul, 2011 1 commit
  11. 06 Apr, 2011 1 commit
    • Matthew Garrett's avatar
      x86: Reorder reboot method preferences · 660e34ce
      Matthew Garrett authored
      We have a never ending stream of 'reboot quirks' for new boxes
      that will not reboot properly under Linux (they will hang on
      reboot).
      
      The reason is widespread 'Windows compatible' assumption of modern
      x86 hardware, which expects the following reboot sequence:
      
       - hitting the ACPI reboot vector (if available)
       - trying the keyboard controller
       - hitting the ACPI reboot vector again
       - then giving the keyboard controller one last go
      
      This sequence expectation gets more and more embedded in modern
      hardware, which often lacks a keyboard controller and may even
      lock up if the legacy io ports are hit - and which hardware is
      often not tested with Linux during development.
      
      The end result is that reboot works under Windows-alike OSs but not
      under Linux.
      
      Rework our reboot process to meet this hardware externality a little
      better and match this assumption of newer x86 hardware.
      
      In addition to the ACPI,kbd,ACPI,kbd sequence we'll still fall
      through to attempting a legacy triple fault if nothing else
      works - and keep trying that and the kbd reset.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      [ this commit will also save special casing Oaktrail boards ]
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Leann Ogasawara <leann.ogasawara@canonical.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      LKML-Reference: <1301939705-2404-1-git-send-email-mjg@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      660e34ce
  12. 29 Mar, 2011 1 commit
    • Jean Delvare's avatar
      x86: Stop including <linux/delay.h> in two asm header files · ca444564
      Jean Delvare authored
      Stop including <linux/delay.h> in x86 header files which don't
      need it. This will let the compiler complain when this header is
      not included by source files when it should, so that
      contributors can fix the problem before building on other
      architectures starts to fail.
      
      Credits go to Geert for the idea.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Cc: James E.J. Bottomley <James.Bottomley@suse.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20110325152014.297890ec@endymion.delvare>
      [ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ca444564
  13. 21 Feb, 2011 1 commit
  14. 17 Feb, 2011 1 commit
  15. 07 Jan, 2011 2 commits
    • Don Zickus's avatar
      x86, NMI: Remove DIE_NMI_IPI · c410b830
      Don Zickus authored
      With priorities in place and no one really understanding the difference between
      DIE_NMI and DIE_NMI_IPI, just remove DIE_NMI_IPI and convert everyone to DIE_NMI.
      
      This also simplifies default_do_nmi() a little bit.  Instead of calling the
      die_notifier in both the if and else part, just pull it out and call it before
      the if-statement.  This has the side benefit of avoiding a call to the ioport
      to see if there is an external NMI sitting around until after the (more frequent)
      internal NMIs are dealt with.
      Patch-Inspired-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-5-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c410b830
    • Don Zickus's avatar
      x86, NMI: Add priorities to handlers · 166d7514
      Don Zickus authored
      In order to consolidate the NMI die_chain events, we need to setup the priorities
      for the die notifiers.
      
      I started by defining a bunch of common priorities that can be used by the
      notifier blocks.  Then I modified the notifier blocks to use the newly created
      priorities.
      
      Now that the priorities are straightened out, it should be easier to remove the
      event DIE_NMI_IPI.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      166d7514
  16. 21 Oct, 2010 1 commit
    • Alok Kataria's avatar
      x86, kexec: Make sure to stop all CPUs before exiting the kernel · 76fac077
      Alok Kataria authored
      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: default avatarAlok 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: default avatarH. Peter Anvin <hpa@linux.intel.com>
      76fac077
  17. 20 Oct, 2010 1 commit
  18. 12 Aug, 2010 1 commit
  19. 20 Jun, 2010 1 commit
  20. 17 Feb, 2010 1 commit
  21. 27 Jan, 2010 1 commit
  22. 04 Dec, 2009 1 commit
    • Leann Ogasawara's avatar
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara authored
      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: default avatarLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
  23. 08 Nov, 2009 1 commit
    • FUJITA Tomonori's avatar
      x86: Use x86_platform for iommu_shutdown · 338bac52
      FUJITA Tomonori authored
      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: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: joerg.roedel@amd.com
      LKML-Reference: <20091027163358F.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      338bac52
  24. 02 Nov, 2009 1 commit
  25. 11 Oct, 2009 1 commit
  26. 01 Sep, 2009 1 commit
  27. 10 Aug, 2009 1 commit
  28. 08 Aug, 2009 1 commit
  29. 03 Aug, 2009 1 commit
    • Paul Mackerras's avatar
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      Paul Mackerras authored
      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: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
  30. 21 Jul, 2009 1 commit
    • Joseph Cihula's avatar
      x86, intel_txt: Intel TXT reboot/halt shutdown support · 840c2baf
      Joseph Cihula authored
      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: default avatarJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: default avatarShane Wang <shane.wang@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      840c2baf
  31. 20 Jul, 2009 1 commit
  32. 07 Jun, 2009 1 commit
  33. 22 May, 2009 1 commit
  34. 08 Apr, 2009 1 commit