Xen devel - Aug 2005 - [PATCH] xenlinux i386: don''t force a reboot on panics

This is supposed to be configurable (eg on the command line), not
hard-coded (also, x86_64 didn''t try to do similar things).

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Index: xen-2005-08-19/arch/xen/i386/kernel/setup.c
==================================================================---
xen-2005-08-19.orig/arch/xen/i386/kernel/setup.c	2005-08-19
13:53:09.517661792 +0200
+++ xen-2005-08-19/arch/xen/i386/kernel/setup.c	2005-08-19
14:14:31.550763136 +0200
@@ -69,11 +69,6 @@
 /* Allows setting of maximum possible memory size  */
 static unsigned long xen_override_max_pfn;
 
-static int xen_panic_event(struct notifier_block *, unsigned long,
void *);
-static struct notifier_block xen_panic_block = {
-	xen_panic_event, NULL, 0 /* try to go last */
-};
-
 int disable_pse __devinitdata = 0;
 
 /*
@@ -1530,14 +1525,6 @@
 	physdev_op_t op;
 	unsigned long max_low_pfn;
 
-	/* Force a quick death if the kernel panics. */
-	extern int panic_timeout;
-	if (panic_timeout == 0)
-		panic_timeout = 1;
-
-	/* Register a call for panic conditions. */
-	notifier_chain_register(&panic_notifier_list,
&xen_panic_block);
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable,
VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable,
 			     VMASST_TYPE_writable_pagetables);
@@ -1765,14 +1752,6 @@
 	}
 }
 
-static int
-xen_panic_event(struct notifier_block *this, unsigned long event, void
*ptr)
-{
-	HYPERVISOR_crash();    
-	/* we''re never actually going to get here... */
-	return NOTIFY_DONE;
-}
-
 #include "setup_arch_post.h"
 /*
  * Local Variables:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Aug 2005, at 09:16, Jan Beulich wrote:
> This is supposed to be configurable (eg on the command line), not
> hard-coded (also, x86_64 didn''t try to do similar things).
What is? panic_timeout?

Seems sensible on a VMM to inform control software as quickly as 
possible that you''ve crashed, rather than spinning in a loop trying to 
blink a keyboard led that doesn''t exist.

Even the concept of a timeout before restart makes little sense -- the 
console output has been sent to an external daemon so it shouldn''t get 
lost like it would if it was printed to vga console and you did a real 
physical reboot.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 22.08.05 11:05:43
>>>
>
>On 22 Aug 2005, at 09:16, Jan Beulich wrote:
>
>> This is supposed to be configurable (eg on the command line), not
>> hard-coded (also, x86_64 didn''t try to do similar things).
>
>What is? panic_timeout?
>
>Seems sensible on a VMM to inform control software as quickly as 
>possible that you''ve crashed, rather than spinning in a loop trying
to
>blink a keyboard led that doesn''t exist.
I agree to that part.
>Even the concept of a timeout before restart makes little sense -- the
>console output has been sent to an external daemon so it shouldn''t
get
>lost like it would if it was printed to vga console and you did a real
>physical reboot.
But not completely here: If I don''t have a serial console attached (in
fact I never even tried to), then the information *IS* lost. Hence this
should still be configurable, but you may clearly chose a default mode
that in fact does reboot immediately.

Further, as indicated, x86_64 behavior is different from i386''s, which
already points to pre-exisiting consistency issues.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Aug 2005, at 10:17, Jan Beulich wrote:
> But not completely here: If I don''t have a serial console attached
(in
> fact I never even tried to), then the information *IS* lost. Hence this
> should still be configurable, but you may clearly chose a default mode
> that in fact does reboot immediately.
I guess what you want in dom0 is different from domU.... we should have 
more native-like behaviour in dom0. But what we do now is sane for 
domU.
> Further, as indicated, x86_64 behavior is different from i386''s,
which
> already points to pre-exisiting consistency issues.
Our x86_64 port is merging towards i386, not vice versa for the most 
part.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel