similar to: [PATCH][LINUX] use machine_emergency_restart() from the

This patch uses the standard generic header for the definition of machine_emergency_restart() and reverses the call path for XenoLinux. Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com> --- diff -r 7680b29c03a6 drivers/xen/core/reboot.c --- a/drivers/xen/core/reboot.c Sat Aug 05 11:33:24 2006 -0400 +++ b/drivers/xen/core/reboot.c Mon Aug 07 09:50:33 2006 -0400 @@ -9,6 +9,7 @@ #include

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Attached and below are a patch that unifies the shutdown code paths in Xen, including those from EARLY_FAIL. This will facilitate the use of Intel(R) TXT for measured launch by ensuring that all shutdowns will call the necessary hook to tear down the measured environment. It also centralizes any future shutdown-related changes. The patch also postpones clearing the online status APs in

There is a race case where the user does ''poweroff'' and at the same time the system admin does ''xl shutdown''. Depending on the race, the system_state will be SYSTEM_RUNNING or SYSTEM_POWER_OFF. If SYSTEM_RUNNING we just end up making a duplicate call to ''poweroff'' (while it is running). That will fail or execute (And if executed then it will

# HG changeset patch # User Hollis Blanchard <hollisb@us.ibm.com> # Date 1154990956 18000 # Node ID 058f2e27476d686538de2671f57c1ded5c693b47 # Parent 4196687234c530a11d26a199f1479bc07e08248f [XEN] Remove redundant redeclaration of ''machine_restart''. Fixes compile warning with gcc 3.4.2. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r 4196687234c5 -r

Fairly straightforward code motion in system.h into the sub-arch layer. Affected functionality include control register accessors, which are virtualizable but with great overhead due to the #GP cost; wbinvd, and most importantly, halt and interrupt control, which is non-virtualizable. Since read_cr4_safe can never fault on a VMI kernel (P5+ processor is required for VMI), we can omit the fault

Fairly straightforward code motion in system.h into the sub-arch layer. Affected functionality include control register accessors, which are virtualizable but with great overhead due to the #GP cost; wbinvd, and most importantly, halt and interrupt control, which is non-virtualizable. Since read_cr4_safe can never fault on a VMI kernel (P5+ processor is required for VMI), we can omit the fault

flight 17860 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17860/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 4 kernel-build fail REGR. vs. 17854 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1)

Add a thread watching the xenbus shutdown control path and notifies a wait queue. Add HYPERVISOR_shutdown convenient inline for minios shutdown. Add proper shutdown to the minios test application. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> diff -r fdf241ea6ff4 extras/mini-os/include/kernel.h --- a/extras/mini-os/include/kernel.h Wed Nov 28 21:29:18 2012 +0100 +++

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

Xen is crashing for me since version 4.1.3 during boot on a AMD machine. This happens since patch "x86-64: detect processors subject to AMD erratum #121 and refuse to boot." Instead of the actual panic-message from the patch the following stacktrace appears (i typed it down from screen, so it might contain typos) find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt

Subject: Obtain VESA capabilities and attributes of VESA mode Also, move some more common code to dom0_init_screen_info(). This was tested on 2.6.22.1, and only made apply to 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-08-07/arch/i386/kernel/setup-xen.c =================================================================== ---

Hi, I use ext3 over RAID1+0 LUN. When I disconnect my fiber cable to the RAID (in order to force a migration to a failover node) I expect to see I/O errors and then a failure to write/read to the filesystem, but in addition I get an Assertion failure. The end result is of course an unusable system which needs to be rebooted. (I reboot the system via machine_restart which works okay but I guess

Hey! Trying the root disk image http://xm-test.xensource.com/ramdisks/initrd-1.1-i386.img suggested in Documentation/lguest/lguest.txt, I get the follow trace when rebooting the guest. Kernel is 2.6.23-rc2-ge1cf20c1. @%@%> reboot The system is going down NOW !! Sending SIGTERM to all processes. Sending SIGKILL to all processes. Requesting system reboot. [ 7.541027] Restarting system. [

Hey! Trying the root disk image http://xm-test.xensource.com/ramdisks/initrd-1.1-i386.img suggested in Documentation/lguest/lguest.txt, I get the follow trace when rebooting the guest. Kernel is 2.6.23-rc2-ge1cf20c1. @%@%> reboot The system is going down NOW !! Sending SIGTERM to all processes. Sending SIGKILL to all processes. Requesting system reboot. [ 7.541027] Restarting system. [

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

Hi all, I'm running OCFS2 on two system with OpenSUSE 10.2 connected on fibre channel with a shared storage (HP MSA1500 + HP PROLIANT MSA20). The cluster has two node (web-ha1 and web-ha2), sometimes (1 or 2 times on a month) the OCFS2 stop to work on both system. On the first node I'm getting no error in log files and after a forced shoutdown of the first node on the second I can see

Avi, Hope this series is okay now. Thanks for the testing