1. 06 10月, 2013 1 次提交
  2. 25 9月, 2013 1 次提交
  3. 23 9月, 2013 1 次提交
  4. 10 7月, 2013 2 次提交
  5. 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
  6. 04 10月, 2012 1 次提交
  7. 21 6月, 2012 1 次提交
  8. 18 6月, 2012 1 次提交
  9. 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
  10. 05 6月, 2012 1 次提交
  11. 09 5月, 2012 2 次提交
  12. 07 2月, 2012 2 次提交
  13. 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
  14. 05 12月, 2011 2 次提交
  15. 10 10月, 2011 1 次提交
  16. 22 7月, 2011 2 次提交
  17. 13 7月, 2011 1 次提交
  18. 06 7月, 2011 1 次提交
  19. 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
  20. 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
  21. 21 2月, 2011 1 次提交
  22. 18 2月, 2011 1 次提交
  23. 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
  24. 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
  25. 21 10月, 2010 1 次提交
  26. 13 8月, 2010 1 次提交
  27. 20 6月, 2010 1 次提交
  28. 17 2月, 2010 1 次提交
  29. 28 1月, 2010 1 次提交
  30. 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
  31. 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
  32. 02 11月, 2009 1 次提交