- 22 10月, 2010 1 次提交
-
-
由 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>
-
- 20 6月, 2010 1 次提交
-
-
由 Thomas Backlund 提交于
Dell Precision WorkStation T7400 freezes on reboot unless reboot=b is used. Reference: https://qa.mandriva.com/show_bug.cgi?id=58017Signed-off-by: NThomas Backlund <tmb@mandriva.org> LKML-Reference: <4C1CC6E9.6000701@mandriva.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 17 2月, 2010 1 次提交
-
-
由 Justin P. Mattock 提交于
On the iMac9,1 /sbin/reboot results in a black mangled screen. Adding this DMI entry gets the machine to reboot cleanly as it should. Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com> LKML-Reference: <1266362249-3337-1-git-send-email-justinmattock@gmail.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 28 1月, 2010 1 次提交
-
-
由 Leann Ogasawara 提交于
Dell OptiPlex 760 hangs on reboot unless reboot=bios is used. Add quirk to reboot through the BIOS. BugLink: https://bugs.launchpad.net/bugs/488319Signed-off-by: NLeann Ogasawara <leann.ogasawara@canonical.com> LKML-Reference: <1264634958.27335.1091.camel@emiko> Cc: <stable@kernel.org> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 05 12月, 2009 1 次提交
-
-
由 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>
-
- 08 11月, 2009 1 次提交
-
-
由 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>
-
- 02 11月, 2009 1 次提交
-
-
由 Gottfried Haider 提交于
Reboot does not work out of the box on my "Early 2009" Mac mini (3,1). Detect this machine via DMI as we do for recent MacBooks. Signed-off-by: NGottfried Haider <gottfried.haider@gmail.com> Cc: Ozan Çağlayan <ozan@pardus.org.tr> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 12 10月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
-
- 02 9月, 2009 1 次提交
-
-
由 Shane Wang 提交于
Move tboot.h from asm to linux to fix the build errors of intel_txt patch on non-X86 platforms. Remove the tboot code from generic code init/main.c and kernel/cpu.c. Signed-off-by: NShane Wang <shane.wang@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 11 8月, 2009 1 次提交
-
-
由 Shunichi Fuji 提交于
Reboot does not work on my MacBook Pro 13 inch (MacBookPro5,5) too. It seems all unibody MacBook and MacBookPro require PCI reboot handling, i guess. Following model/machine ID list shows unibody MacBook/Pro have the 5 series of model number: http://www.everymac.com/systems/by_capability/macs-by-machine-model-machine-id.htmlSigned-off-by: NShunichi Fuji <palglowr@gmail.com> Cc: Ozan Çağlayan <ozan@pardus.org.tr> LKML-Reference: <30046e3b0908101134p6487ddbftd8776e4ddef204be@mail.gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 8月, 2009 1 次提交
-
-
由 Ozan Çağlayan 提交于
MacBookPro5,1 is not able to reboot unless reboot=pci is set. This patch forces it through a DMI quirk specific to this device. Signed-off-by: NOzan Çağlayan <ozan@pardus.org.tr> LKML-Reference: <1249403971-6543-1-git-send-email-ozan@pardus.org.tr> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 8月, 2009 1 次提交
-
-
由 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>
-
- 22 7月, 2009 1 次提交
-
-
由 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>
-
- 21 7月, 2009 1 次提交
-
-
由 Denis Turischev 提交于
The CompuLab SBC-fitPC2 board needs to reboot via BIOS. Signed-off-by: NDenis Turischev <denis@compulab.co.il> Signed-off-by: NMike Rapoport <mike@compulab.co.il> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 07 6月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
The Dell Optiplex 360 hangs on reboot, just like the Optiplex 330, so the same quirk is needed. Signed-off-by: NJean Delvare <jdelvare@suse.de> Cc: Steve Conklin <steve.conklin@canonical.com> Cc: Leann Ogasawara <leann.ogasawara@canonical.com> Cc: <stable@kernel.org> LKML-Reference: <200906051202.38311.jdelvare@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 22 5月, 2009 1 次提交
-
-
由 Zhang Rui 提交于
x86: DMI match for the Sony VGN-Z540N as it needs BIOS reboot, see: http://bugzilla.kernel.org/show_bug.cgi?id=12901 [ Impact: fix hung reboot on certain systems ] Signed-off-by: NZhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> LKML-Reference: <1242963350.32574.53.camel@rzhang-dt> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 4月, 2009 1 次提交
-
-
由 Alan Cox 提交于
Closes http://bugzilla.kernel.org/show_bug.cgi?12901Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> LKML-Reference: <20090326204524.4454.8776.stgit@localhost.localdomain> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 05 3月, 2009 1 次提交
-
-
由 Leann Ogasawara 提交于
Dell XPS710 will hang on reboot. This is resolved by adding a quirk to set bios reboot. Signed-off-by: NLeann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by: NTim Gardner <tim.gardner@canonical.com> Cc: "manoj.iyer" <manoj.iyer@canonical.com> Cc: <stable@kernel.org> LKML-Reference: <1236196380.3231.89.camel@emiko> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 18 2月, 2009 2 次提交
-
-
由 Ingo Molnar 提交于
Impact: cleanup Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ingo Molnar 提交于
Impact: cleanup Remove genapic.h and remove all references to it. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 29 1月, 2009 2 次提交
-
-
由 Ingo Molnar 提交于
Move mach_ipi.h definitions into genapic.h. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ingo Molnar 提交于
Our send_IPI_*() methods and definitions are a twisted mess: the same symbol is defined to different things depending on .config details, in a non-transparent way. - spread out the quirks into separately named per apic driver methods - prefix the standard PC methods with default_ - get rid of wrapper macro obfuscation - clean up various details Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 1月, 2009 1 次提交
-
-
由 Jaswinder Singh Rajput 提交于
Impact: cleanup Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 1月, 2009 1 次提交
-
-
由 Mike Travis 提交于
Impact: Reduce future system panics due to cpumask operations using NR_CPUS Insure that code does not look at bits >= nr_cpu_ids as when cpumasks are allocated based on nr_cpu_ids, these extra bits will not be defined. Also some other minor updates: * change in to use cpu accessor function set_cpu_present() instead of directly accessing cpu_present_map w/cpu_clear() [arch/x86/kernel/reboot.c] * use cpumask_of() instead of &cpumask_of_cpu() [arch/x86/kernel/reboot.c] * optimize some cpu_mask_to_apicid_and functions. Signed-off-by: NMike Travis <travis@sgi.com> Acked-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 31 12月, 2008 1 次提交
-
-
由 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>
-
- 30 12月, 2008 1 次提交
-
-
由 Jaswinder Singh Rajput 提交于
Impact: cleanup Now that arch/x86/pci/pci.h is used in a number of other places as well, move the lowlevel x86 pci definitions into the architecture include files. (not to be confused with the existing arch/x86/include/asm/pci.h file, which provides public details about x86 PCI) Tested on: X86_32_UP, X86_32_SMP and X86_64_SMP Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 27 12月, 2008 1 次提交
-
-
由 Jaswinder Singh 提交于
Impact: cleanup, avoid sparse warning Include "../pci/pci.h" for port_cf9_safe Fixes this sparse warning: arch/x86/kernel/reboot.c:43:6: warning: symbol 'port_cf9_safe' was not declared. Should it be static? Signed-off-by: NJaswinder Singh <jaswinder@infradead.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 24 11月, 2008 1 次提交
-
-
由 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>
-
- 23 11月, 2008 1 次提交
-
-
由 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>
-
- 19 11月, 2008 1 次提交
-
-
由 Steve Conklin 提交于
Dell Optiplex 330 appears to hang on reboot. This is resolved by adding a quirk to set bios reboot. Signed-off-by: NLeann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by: NSteve Conklin <steve.conklin@canonical.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 13 11月, 2008 3 次提交
-
-
由 Eduardo Habkost 提交于
Impact: make nmi_shootdown_cpus() callable from preemptible context We need to know on which CPU we are running on, and we don't want to be preempted while doing this. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Eduardo Habkost 提交于
Impact: widen nmi_shootdown_cpus() availability The X86_LOCAL_APIC #ifdef was for kdump. For !SMP, the function simply does nothing. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Eduardo Habkost 提交于
Impact: make nmi_shootdown_cpus() available to the rest of the x86 platform Now nmi_shootdown_cpus() is ready to be used by non-kdump code also. Move it to reboot.c. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 12 11月, 2008 1 次提交
-
-
由 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>
-
- 11 11月, 2008 1 次提交
-
-
由 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>
-
- 06 11月, 2008 1 次提交
-
-
由 Eduardo Habkost 提交于
This reverts commit c7ffa6c2. the assumptio of this change was that this would not break any existing machine. Andrey Borzenkov reported troubles with the ACPI reboot method: the system would hang on reboot, necessiating a power cycle. Probably more systems are affected as well. Also, there are patches queued up for v2.6.29 to disable virtualization on emergency_restart() - which was the original motivation of this change. Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru> Bisected-by: NAndrey Borzenkov <arvidjaar@mail.ru> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NAvi Kivity <avi@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 25 8月, 2008 1 次提交
-
-
由 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>
-
- 26 7月, 2008 1 次提交
-
-
由 Mike Travis 提交于
* Replace previous instances of the cpumask_of_cpu_ptr* macros with a the new (lvalue capable) generic cpumask_of_cpu(). Signed-off-by: NMike Travis <travis@sgi.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jack Steiner <steiner@sgi.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 19 7月, 2008 1 次提交
-
-
由 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>
-
- 17 7月, 2008 1 次提交
-
-
由 Ingo Molnar 提交于
as reported in: "reboot=bios is mandatory on Dell T5400 server." http://bugzilla.kernel.org/show_bug.cgi?id=11108 add a DMI reboot quirk. Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: <stable@kernel.org>
-