1. 06 3月, 2014 1 次提交
    • L
      x86, reboot: Add EFI and CF9 reboot methods into the default list · a4f1987e
      Li, Aubrey 提交于
      Reboot is the last service linux OS provides to the end user. We are
      supposed to make this function more robust than today. This patch adds
      all of the known reboot methods into the default attempt list. The
      machines requiring reboot=efi or reboot=p or reboot=bios get a chance
      to reboot automatically now.
      
      If there is a new reboot method emerged, we are supposed to add it to
      the default list as well, instead of adding the endless dmidecode entry.
      
      If one method required is in the default list in this patch but the
      machine reboot still hangs, that means some methods ahead of the
      required method cause the system hangs, then reboot the machine by
      passing reboot= arguments and submit the reboot dmidecode table quirk.
      
      We are supposed to remove the reboot dmidecode table from the kernel,
      but to be safe, we keep it. This patch prevents us from adding more.
      If you happened to have a machine listed in the reboot dmidecode
      table and this patch makes reboot work on your machine, please submit
      a patch to remove the quirk.
      
      The default reboot order with this patch is now:
      
          ACPI > KBD > ACPI > KBD > EFI > CF9_COND > BIOS
      
      Because BIOS and TRIPLE are mutually exclusive (either will either
      work or hang the machine) that method is not included.
      
      [ hpa: as with any changes to the reboot order, this patch will have
        to be monitored carefully for regressions. ]
      Signed-off-by: NAubrey Li <aubrey.li@intel.com>
      Acked-by: NMatthew Garrett <mjg59@srcf.ucam.org>
      Link: http://lkml.kernel.org/r/53130A46.1010801@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4f1987e
  2. 05 12月, 2013 1 次提交
  3. 07 11月, 2013 1 次提交
  4. 25 10月, 2013 1 次提交
  5. 06 10月, 2013 1 次提交
  6. 02 10月, 2013 1 次提交
  7. 27 9月, 2013 1 次提交
  8. 26 9月, 2013 1 次提交
    • L
      reboot: Allow specifying warm/cold reset for CF9 boot type · 16c21ae5
      Li Fei 提交于
      In current implementation for reboot type CF9 and CF9_COND,
      warm and cold reset are not differentiated, and both are
      performed by writing 0x06 to port 0xCF9.
      
      This commit will differentiate warm and cold reset:
      
      For warm reset, write 0x06 to port 0xCF9;
      For cold reset, write 0x0E to port 0xCF9.
      
      [ hpa: This meaning of "cold" and "warm" reset is different from other
        reboot types use, where "warm" means "bypass BIOS POST".  It is also
        not entirely clear that it actually solves any actual problem.  However,
        it would seem fairly harmless to offer this additional option.
      
        Also note that we do not mask bit 3 in the "warm reset" case.  This
        preserves the behavior on existing systems, including ones quirked
        to use CF9.  It seems reasonable that on any system where the
        warm/cold distinction actually matters that bit 3 would be read as
        zero. ]
      
      From: Liu Chuansheng <chuansheng.liu@intel.com>
      Signed-off-by: NLi Fei <fei.li@intel.com>
      Link: http://lkml.kernel.org/r/1377072837.24556.2.camel@fli24-HP-Compaq-8100-Elite-CMT-PCSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      16c21ae5
  9. 25 9月, 2013 1 次提交
  10. 23 9月, 2013 1 次提交
  11. 10 7月, 2013 2 次提交
  12. 31 1月, 2013 1 次提交
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  13. 04 10月, 2012 1 次提交
  14. 21 6月, 2012 1 次提交
  15. 18 6月, 2012 1 次提交
  16. 06 6月, 2012 2 次提交
    • F
      x86/reboot: Fix a warning message triggered by stop_other_cpus() · 55c844a4
      Feng Tang 提交于
      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: NFeng Tang <feng.tang@intel.com>
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7Signed-off-by: NIngo Molnar <mingo@kernel.org>
      55c844a4
    • J
      x86/debug: Add KERN_<LEVEL> to bare printks, convert printks to pr_<level> · c767a54b
      Joe Perches 提交于
      Use a more current logging style:
      
       - Bare printks should have a KERN_<LEVEL> for consistency's sake
       - Add pr_fmt where appropriate
       - Neaten some macro definitions
       - Convert some Ok output to OK
       - Use "%s: ", __func__ in pr_fmt for summit
       - Convert some printks to pr_<level>
      
      Message output is not identical in all cases.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Cc: levinsasha928@gmail.com
      Link: http://lkml.kernel.org/r/1337655007.24226.10.camel@joe2Laptop
      [ merged two similar patches, tidied up the changelog ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c767a54b
  17. 05 6月, 2012 1 次提交
  18. 09 5月, 2012 2 次提交
  19. 07 2月, 2012 2 次提交
  20. 30 1月, 2012 2 次提交
    • M
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola 提交于
      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: NMichael 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: NIngo Molnar <mingo@elte.hu>
      e6d36a65
    • M
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola 提交于
      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: NMichael 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: NIngo Molnar <mingo@elte.hu>
      5955633e
  21. 05 12月, 2011 2 次提交
  22. 10 10月, 2011 1 次提交
  23. 22 7月, 2011 2 次提交
  24. 13 7月, 2011 1 次提交
  25. 06 7月, 2011 1 次提交
  26. 06 4月, 2011 1 次提交
    • M
      x86: Reorder reboot method preferences · 660e34ce
      Matthew Garrett 提交于
      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: NMatthew Garrett <mjg@redhat.com>
      [ this commit will also save special casing Oaktrail boards ]
      Acked-by: NAlan 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: NIngo Molnar <mingo@elte.hu>
      660e34ce
  27. 29 3月, 2011 1 次提交
    • J
      x86: Stop including <linux/delay.h> in two asm header files · ca444564
      Jean Delvare 提交于
      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: NJean 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: NIngo Molnar <mingo@elte.hu>
      ca444564
  28. 21 2月, 2011 1 次提交
  29. 18 2月, 2011 1 次提交
  30. 07 1月, 2011 2 次提交
    • D
      x86, NMI: Remove DIE_NMI_IPI · c410b830
      Don Zickus 提交于
      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: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-5-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c410b830
    • D
      x86, NMI: Add priorities to handlers · 166d7514
      Don Zickus 提交于
      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: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      166d7514
  31. 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
  32. 21 10月, 2010 1 次提交