Mailinglist Archive: opensuse-bugs (2746 mails)

< Previous Next >
[Bug 825510] "shutdown -r now" fails @ Xen 4.3.0 Dom0 -- systems halts, but does not restart

https://bugzilla.novell.com/show_bug.cgi?id=825510

https://bugzilla.novell.com/show_bug.cgi?id=825510#c7


--- Comment #7 from A R <ar16@xxxxxxxxxxxx> 2013-06-28 10:56:52 UTC ---
To simplify the analysis, it would be desirable if you tried this
with disabled secondary CPUs ("nosmp" on the Xen command line).

I've found different advice on how best to achieve this.

Reading,

http://osdir.com/ml/xen-users/2007-11/msg00697.html

> Is it possible to disable the SMP function on the dom0 and assign
each single domU to have direct access on the multicore processor like Intel
Quadcore?

"Yes, Edit /etc/xend/xend-config.sxp and use (dom0-cpus x) to
assign a single cpu to dom0"

and

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308#22

> it’s also recommended that the dom0 is restricted to one
> CPU only, for example by booting with the kernel parameter nosmp."

Ian Campbell ==>
"Ignoring whether or not this is good advice (I expect it very much
depends on your workload)
this can be better achieved by adding dom0_max_vcpus=1 to your
hypervisor command line or
by hot-unplugging vCPUS once the system has booted ..."

mod'ing in my grub

- ... dom0_max_vcpus=4 ...
+ ... dom0_max_vcpus=1 ...

iiuc, appears to do the trick; after reboot, just one CPU appears active

cat /proc/interrupts | head -n 5
CPU0
1: 4 Phys-fasteoi i8042
6: 3 Phys-fasteoi floppy
7: 0 Phys-fasteoi parport0
8: 0 Phys-fasteoi rtc0

Is this sufficient for your request?

So with it not crashing, but just hanging, issuing the 'd' debug key from the
serial console ought to still work, and should give us insight into what's
going on.

Atm, when booting to Xen, I'm *unable* to get the server to recognize any
commands issued from my serial terminal (no cmd keys, not even seeing a login
prompt, etc). This *used* to work pre-systemd.

Something's possibly off in my serial config. I'm trying to get *that*
straightened out @

http://lists.opensuse.org/opensuse-virtual/2013-06/msg00015.html

That said - did you try the various "reboot=" hypervisor command line options,
and _none_ of them worked?

I hadn't tried any of them; tbh, not even aware of them.

Reading

http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

The options appear to be:

reboot
= b[ios] | t[riple] | k[bd] | n[o] [, [w]arm | [c]old]
Default: 0
Specify the host reboot method.

warm instructs Xen to not set the cold reboot flag.
cold instructs Xen to set the cold reboot flag.
bios instructs Xen to reboot the host by jumping to BIOS. This is only
available on 32-bit x86 platforms.
triple instructs Xen to reboot the host by causing a triple fault.
kbd instructs Xen to reboot the host via the keyboard controller.
acpi instructs Xen to reboot the host using RESET_REG in the ACPI FADT.

with no further explanation(s).

Reading

http://lists.xen.org/archives/html/xen-devel/2011-09/msg00942.html

suggests that @ 'Default', a *sequence* of the reboot options is attempted

"Summing up, both Linux 3.1 and Xen 4.1 both do the following sequence by
default:

ACPI, KBD, ACPI, KBD, TRIPLE, KBD, TRIPLE, KBD, ..."

setting, instead, individual reboot= grub options, testing `shutdown -r now` in
each case

reboot=cold
reboot=warm
reboot=triple
reboot=kbd
reboot=acpi
(reboot=bios, not applicable. this is x86_64.)

exec of `shutdown -r now` hangs, as reported above, @

(XEN) [2013-06-28 16:32:06] Domain 0 shutdown: rebooting machine.

--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
< Previous Next >
References