DomU freezes in the middle of booting

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

DomU freezes in the middle of booting

Konstantin Astafjev
Hello,

Stuck with starting DomU. :(

I've compiled bzImage with Xen frontend drivers, modules, installed them,
added some extra parameters about console

--------------------------------------------------
kernel = "/etc/xen/DomU-kernels/kernel-3.2.12-domU"
memory = 1024
name   = "vm0"
disk   = ['phy:/dev/vg01/vm0,xvda,w']
root   = '/dev/xvda ro'
extra = 'xencons=tty'
vif = ['vifname=veth1, bridge=xenbr0']
vcpus=2
--------------------------------------------------

then started DomU with:
# xl create /etc/xen/vm0 -c

and console output freezes somewhere after:
--------------------------------------------------
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: [hidden email]
TCP cubic registered
blkfront: xvda: flush diskcache: enabled
 xvda: unknown partition table
--------------------------------------------------

What am i doing wrong? ;)

P.S.: Also before that I got some not critical errors. I guess it
related to RTC or HPET somehow. Is it a big problem for DomU system?

--------------------------------------------------
PCI: System does not support PCI
PCI: System does not support PCI
Switching to clocksource xen
CE: xen increased min_delta_ns to 150000 nsec
CE: xen increased min_delta_ns to 225000 nsec
CE: xen increased min_delta_ns to 337500 nsec
CE: xen increased min_delta_ns to 506250 nsec
CE: xen increased min_delta_ns to 759375 nsec
CE: xen increased min_delta_ns to 1139062 nsec
CE: xen increased min_delta_ns to 1708593 nsec
CE: xen increased min_delta_ns to 2562889 nsec
CE: xen increased min_delta_ns to 3844333 nsec
CE: xen increased min_delta_ns to 5766499 nsec
CE: xen increased min_delta_ns to 8649748 nsec
CE: xen increased min_delta_ns to 10000000 nsec
CE: Reprogramming failure. Giving up
CE: Reprogramming failure. Giving up
hrtimer: interrupt took 5163 ns
CE: xen increased min_delta_ns to 150000 nsec
CE: xen increased min_delta_ns to 225000 nsec
CE: xen increased min_delta_ns to 337500 nsec
CE: xen increased min_delta_ns to 506250 nsec
CE: xen increased min_delta_ns to 759375 nsec
CE: xen increased min_delta_ns to 1139062 nsec
CE: xen increased min_delta_ns to 1708593 nsec
CE: xen increased min_delta_ns to 2562889 nsec
CE: xen increased min_delta_ns to 3844333 nsec
CE: xen increased min_delta_ns to 5766499 nsec
CE: xen increased min_delta_ns to 8649748 nsec
CE: xen increased min_delta_ns to 10000000 nsec
CE: Reprogramming failure. Giving up
CE: Reprogramming failure. Giving up
CE: Reprogramming failure. Giving up
pnp: PnP ACPI: disabled
--------------------------------------------------

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Matthew Thode (prometheanfire)
On Thu, 12 Apr 2012 10:53:16 +0300
Konstantin <[hidden email]> wrote:

> /dev/vg01/vm0
from the host, can you verify that /dev/vg01/vm0 has a valid partition
table?

--
Matthew Thode (prometheanfire)

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
Hello Matthew,

Thank you for your letter.

Thursday, April 12, 2012, 11:18:41, Matthew Thode wrote:
> On Thu, 12 Apr 2012 10:53:16 +0300
> Konstantin <[hidden email]> wrote:

>> /dev/vg01/vm0
> from the host, can you verify that /dev/vg01/vm0 has a valid partition
> table?

Sure. I've already done it. Actually sometimes (very rare) output jumps
somewhere farther like:

--------------------------------------------------------------------
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: [hidden email]
TCP cubic registered
blkfront: xvda: flush diskcache: enabled
 xvda: unknown partition table
REISERFS (device xvda): found reiserfs format "3.6" with standard journal
REISERFS (device xvda): using ordered data mode
reiserfs: using flush barriers
REISERFS (device xvda): journal params: device xvda, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30,            max trans age 30
REISERFS (device xvda): checking transaction log (xvda)
REISERFS (device xvda): Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly on device 202:0.
Freeing unused kernel memory: 508k freed
INIT: version 2.88 booting

   OpenRC 0.9.8.4 is starting up Gentoo Linux (x86_64) [XENU]

 * Mounting /proc ...
 [ ok ]
.........................skipped........................
 * Initializing random number generator ...
 [ ok ]
INIT: Entering runlevel: 3
 * Mounting network filesystems ...
 [ ok ]
 * Doing udev cleanups
 * Starting local
 [ ok ]
--------------------------------------------------------------------

So I guess that my problem somewhere else.

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
Hello,

With the help of Nikita, I've figured out how to get rid of
"xvda: unknown partition table"

I have to use /dev/xvda1 not the /dev/xvda

-------------------------------------
disk   = ['phy:/dev/vg01/vm0,xvda,w']
root   = '/dev/xvda ro'
-------------------------------------

changed to:

-------------------------------------
disk   = ['phy:/dev/vg01/vm0,xvda1,w']
root   = '/dev/xvda1 ro'
-------------------------------------

Anyway booting freezes. Once I've saw:

-------------------------------------
TCP cubic registered
XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1)
XENBUS: Timeout connecting to device: device/vif/0 (local state 1, remote state 1)
VFS: Cannot open root device "xvda1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid: 1, comm: swapper/0 Not tainted 3.2.12-gentoo #2
Call Trace:
 [<ffffffff81318ebd>] ? panic+0x92/0x199
 [<ffffffff81319004>] ? printk+0x40/0x4c
 [<ffffffff814f4e2e>] ? mount_block_root+0x238/0x24f
 [<ffffffff814f4fc0>] ? prepare_namespace+0x12c/0x156
 [<ffffffff814f4b3e>] ? kernel_init+0x10a/0x113
 [<ffffffff8131d074>] ? kernel_thread_helper+0x4/0x10
 [<ffffffff8131bd33>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131b43c>] ? retint_restore_args+0x5/0x6
 [<ffffffff8131d070>] ? gs_change+0x13/0x13
-------------------------------------

So I guess may be it's related to some DomU kernel configuration
problem? I've attached it to this letter.

test # cat .config | grep XEN
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
# CONFIG_XEN_BACKEND is not set
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y

--
Konstantin

.config-3.2.12-domU.zip (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Pandu Poluan


On Apr 12, 2012 4:57 PM, "Konstantin" <[hidden email]> wrote:
>
> Hello,
>
> With the help of Nikita, I've figured out how to get rid of
> "xvda: unknown partition table"
>
> I have to use /dev/xvda1 not the /dev/xvda
>
> -------------------------------------
> disk   = ['phy:/dev/vg01/vm0,xvda,w']
> root   = '/dev/xvda ro'
> -------------------------------------
>
> changed to:
>
> -------------------------------------
> disk   = ['phy:/dev/vg01/vm0,xvda1,w']
> root   = '/dev/xvda1 ro'
> -------------------------------------
>
> Anyway booting freezes. Once I've saw:
>
> -------------------------------------
> TCP cubic registered
> XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
> XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1)
> XENBUS: Timeout connecting to device: device/vif/0 (local state 1, remote state 1)
> VFS: Cannot open root device "xvda1" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> Pid: 1, comm: swapper/0 Not tainted 3.2.12-gentoo #2
> Call Trace:
>  [<ffffffff81318ebd>] ? panic+0x92/0x199
>  [<ffffffff81319004>] ? printk+0x40/0x4c
>  [<ffffffff814f4e2e>] ? mount_block_root+0x238/0x24f
>  [<ffffffff814f4fc0>] ? prepare_namespace+0x12c/0x156
>  [<ffffffff814f4b3e>] ? kernel_init+0x10a/0x113
>  [<ffffffff8131d074>] ? kernel_thread_helper+0x4/0x10
>  [<ffffffff8131bd33>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff8131b43c>] ? retint_restore_args+0x5/0x6
>  [<ffffffff8131d070>] ? gs_change+0x13/0x13
> -------------------------------------
>
> So I guess may be it's related to some DomU kernel configuration
> problem? I've attached it to this letter.
>
> test # cat .config | grep XEN
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_XEN_BALLOON=y
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=y
> # CONFIG_XEN_BACKEND is not set
> CONFIG_XENFS=y
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_SWIOTLB_XEN=y
>
> --
> Konstantin

Have you tried:

root   = '/dev/xvda1'

That is, without 'ro'?

Rgds,

Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Andrey Korolyov-4
In reply to this post by Konstantin Astafjev
Should be googled easily: you need to modify your inittab adding
entries for xen virtual console

hvc0:2345:respawn:/sbin/getty 38400 hvc0
xvc0:2345:respawn:/sbin/getty 38400 xvc0

On Thu, Apr 12, 2012 at 1:55 PM, Konstantin <[hidden email]> wrote:

> Hello,
>
> With the help of Nikita, I've figured out how to get rid of
> "xvda: unknown partition table"
>
> I have to use /dev/xvda1 not the /dev/xvda
>
> -------------------------------------
> disk   = ['phy:/dev/vg01/vm0,xvda,w']
> root   = '/dev/xvda ro'
> -------------------------------------
>
> changed to:
>
> -------------------------------------
> disk   = ['phy:/dev/vg01/vm0,xvda1,w']
> root   = '/dev/xvda1 ro'
> -------------------------------------
>
> Anyway booting freezes. Once I've saw:
>
> -------------------------------------
> TCP cubic registered
> XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
> XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1)
> XENBUS: Timeout connecting to device: device/vif/0 (local state 1, remote state 1)
> VFS: Cannot open root device "xvda1" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> Pid: 1, comm: swapper/0 Not tainted 3.2.12-gentoo #2
> Call Trace:
>  [<ffffffff81318ebd>] ? panic+0x92/0x199
>  [<ffffffff81319004>] ? printk+0x40/0x4c
>  [<ffffffff814f4e2e>] ? mount_block_root+0x238/0x24f
>  [<ffffffff814f4fc0>] ? prepare_namespace+0x12c/0x156
>  [<ffffffff814f4b3e>] ? kernel_init+0x10a/0x113
>  [<ffffffff8131d074>] ? kernel_thread_helper+0x4/0x10
>  [<ffffffff8131bd33>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff8131b43c>] ? retint_restore_args+0x5/0x6
>  [<ffffffff8131d070>] ? gs_change+0x13/0x13
> -------------------------------------
>
> So I guess may be it's related to some DomU kernel configuration
> problem? I've attached it to this letter.
>
> test # cat .config | grep XEN
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_XEN_BALLOON=y
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=y
> # CONFIG_XEN_BACKEND is not set
> CONFIG_XENFS=y
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_SWIOTLB_XEN=y
>
> --
> Konstantin

Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Andrey Korolyov-4
Sorry, I have missed because of savvy Gmail interface - the answer
belongs to disappearance of login prompt.

On Thu, Apr 12, 2012 at 2:09 PM, Andrey Korolyov <[hidden email]> wrote:

> Should be googled easily: you need to modify your inittab adding
> entries for xen virtual console
>
> hvc0:2345:respawn:/sbin/getty 38400 hvc0
> xvc0:2345:respawn:/sbin/getty 38400 xvc0
>
> On Thu, Apr 12, 2012 at 1:55 PM, Konstantin <[hidden email]> wrote:
>> Hello,
>>
>> With the help of Nikita, I've figured out how to get rid of
>> "xvda: unknown partition table"
>>
>> I have to use /dev/xvda1 not the /dev/xvda
>>
>> -------------------------------------
>> disk   = ['phy:/dev/vg01/vm0,xvda,w']
>> root   = '/dev/xvda ro'
>> -------------------------------------
>>
>> changed to:
>>
>> -------------------------------------
>> disk   = ['phy:/dev/vg01/vm0,xvda1,w']
>> root   = '/dev/xvda1 ro'
>> -------------------------------------
>>
>> Anyway booting freezes. Once I've saw:
>>
>> -------------------------------------
>> TCP cubic registered
>> XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
>> XENBUS: Timeout connecting to device: device/vbd/51713 (local state 3, remote state 1)
>> XENBUS: Timeout connecting to device: device/vif/0 (local state 1, remote state 1)
>> VFS: Cannot open root device "xvda1" or unknown-block(0,0)
>> Please append a correct "root=" boot option; here are the available partitions:
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>> Pid: 1, comm: swapper/0 Not tainted 3.2.12-gentoo #2
>> Call Trace:
>>  [<ffffffff81318ebd>] ? panic+0x92/0x199
>>  [<ffffffff81319004>] ? printk+0x40/0x4c
>>  [<ffffffff814f4e2e>] ? mount_block_root+0x238/0x24f
>>  [<ffffffff814f4fc0>] ? prepare_namespace+0x12c/0x156
>>  [<ffffffff814f4b3e>] ? kernel_init+0x10a/0x113
>>  [<ffffffff8131d074>] ? kernel_thread_helper+0x4/0x10
>>  [<ffffffff8131bd33>] ? int_ret_from_sys_call+0x7/0x1b
>>  [<ffffffff8131b43c>] ? retint_restore_args+0x5/0x6
>>  [<ffffffff8131d070>] ? gs_change+0x13/0x13
>> -------------------------------------
>>
>> So I guess may be it's related to some DomU kernel configuration
>> problem? I've attached it to this letter.
>>
>> test # cat .config | grep XEN
>> CONFIG_XEN=y
>> CONFIG_XEN_DOM0=y
>> CONFIG_XEN_PRIVILEGED_GUEST=y
>> CONFIG_XEN_PVHVM=y
>> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
>> CONFIG_XEN_SAVE_RESTORE=y
>> # CONFIG_XEN_DEBUG_FS is not set
>> CONFIG_PCI_XEN=y
>> CONFIG_XEN_PCIDEV_FRONTEND=y
>> CONFIG_XEN_BLKDEV_FRONTEND=y
>> CONFIG_NETXEN_NIC=m
>> CONFIG_XEN_NETDEV_FRONTEND=y
>> CONFIG_HVC_XEN=y
>> CONFIG_XEN_BALLOON=y
>> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
>> CONFIG_XEN_SCRUB_PAGES=y
>> CONFIG_XEN_DEV_EVTCHN=y
>> # CONFIG_XEN_BACKEND is not set
>> CONFIG_XENFS=y
>> CONFIG_XEN_COMPAT_XENFS=y
>> CONFIG_XEN_SYS_HYPERVISOR=y
>> CONFIG_XEN_XENBUS_FRONTEND=y
>> CONFIG_XEN_GNTDEV=m
>> CONFIG_XEN_GRANT_DEV_ALLOC=m
>> CONFIG_SWIOTLB_XEN=y
>>
>> --
>> Konstantin

Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
In reply to this post by Pandu Poluan
Hello Pandu,

Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
> Have you tried:
> root   = '/dev/xvda1'
> That is, without 'ro'?
> Rgds,

Thank you. Already tried without any difference.

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
In reply to this post by Andrey Korolyov-4
Hello Andrey,

Thank you for your letter.

Thursday, April 12, 2012, 13:17:52, Andrey Korolyov wrote:
> Sorry, I have missed because of savvy Gmail interface - the answer
> belongs to disappearance of login prompt.

> On Thu, Apr 12, 2012 at 2:09 PM, Andrey Korolyov <[hidden email]> wrote:
>> Should be googled easily: you need to modify your inittab adding
>> entries for xen virtual console
>>
>> hvc0:2345:respawn:/sbin/getty 38400 hvc0
>> xvc0:2345:respawn:/sbin/getty 38400 xvc0

Yeah, I remember that. AFAIK, it could be done by modifying inittab in
DomU or by inserting some extra parameters in virtual machine
configuration file like
extra = 'xencons=tty'

But right now I have an issue with XENBUS, I guess.

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Pandu Poluan
In reply to this post by Konstantin Astafjev


On Apr 12, 2012 6:23 PM, "Konstantin" <[hidden email]> wrote:
>
> Hello Pandu,
>
> Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
> > Have you tried:
> > root   = '/dev/xvda1'
> > That is, without 'ro'?
> > Rgds,
>
> Thank you. Already tried without any difference.
>

It's a DomU, right? Why do you have Dom0 option enabled?

Rgds,

Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
Hello Pandu,

Thursday, April 12, 2012, 15:29:42, Pandu Poluan wrote:
>> Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
>> > Have you tried:
>> > root   = '/dev/xvda1'
>> > That is, without 'ro'?
>> > Rgds,
>>
>> Thank you. Already tried without any difference.
>>
> It's a DomU, right? Why do you have Dom0 option enabled?

You mean this part of .config file:
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y

I just could not find how to disable this code in menuconfig. :)

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Konstantin Astafjev
Hello,

Thursday, April 12, 2012, 15:52:50, Konstantin wrote:

> Thursday, April 12, 2012, 15:29:42, Pandu Poluan wrote:
>>> Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
>>> > Have you tried:
>>> > root   = '/dev/xvda1'
>>> > That is, without 'ro'?
>>> > Rgds,
>>>
>>> Thank you. Already tried without any difference.
>>>
>> It's a DomU, right? Why do you have Dom0 option enabled?

> You mean this part of .config file:
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y

> I just could not find how to disable this code in menuconfig. :)

If I'm trying to turn it off, but then other frontend options
disappear.

Latest update: When I saw
---------------------
 * Starting local
 [ ok ]
---------------------

I've noticed that domU actually working. I've tried to change inittab
remotely via ssh to something like

# TERMINALS
x1:12345:respawn:/sbin/agetty 38400 console linux
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:2345:respawn:/sbin/agetty 38400 tty2 linux
#c3:2345:respawn:/sbin/agetty 38400 tty3 linux
#c4:2345:respawn:/sbin/agetty 38400 tty4 linux
#c5:2345:respawn:/sbin/agetty 38400 tty5 linux
#c6:2345:respawn:/sbin/agetty 38400 tty6 linux

Then reinitialized init by
localhost ~ # init q

and console in Dom0 become interactive again. So that freezing after
"Starting local" was the console problem anyway.

Right now only one left with that random start. DomU starts
successfully about one time per three unsuccessful.

I've noticed that it gets stuck when kernel outputs this text:

-------------------------------------------------------------
Switching to clocksource xen
pnp: PnP ACPI: disabled
CE: xen increased min_delta_ns to 150000 nsec
CE: xen increased min_delta_ns to 225000 nsec
CE: xen increased min_delta_ns to 337500 nsec
CE: xen increased min_delta_ns to 506250 nsec
CE: xen increased min_delta_ns to 759375 nsec
CE: xen increased min_delta_ns to 1139062 nsec
CE: xen increased min_delta_ns to 1708593 nsec
CE: xen increased min_delta_ns to 2562889 nsec
CE: xen increased min_delta_ns to 3844333 nsec
CE: xen increased min_delta_ns to 5766499 nsec
CE: xen increased min_delta_ns to 8649748 nsec
CE: xen increased min_delta_ns to 10000000 nsec
CE: Reprogramming failure. Giving up
CE: Reprogramming failure. Giving up
hrtimer: interrupt took 5171 ns
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
CE: xen increased min_delta_ns to 150000 nsec
CE: xen increased min_delta_ns to 225000 nsec
CE: xen increased min_delta_ns to 337500 nsec
CE: xen increased min_delta_ns to 506250 nsec
CE: xen increased min_delta_ns to 759375 nsec
CE: xen increased min_delta_ns to 1139062 nsec
CE: xen increased min_delta_ns to 1708593 nsec
CE: xen increased min_delta_ns to 2562889 nsec
CE: xen increased min_delta_ns to 3844333 nsec
CE: xen increased min_delta_ns to 5766499 nsec
CE: xen increased min_delta_ns to 8649748 nsec
CE: xen increased min_delta_ns to 10000000 nsec
CE: Reprogramming failure. Giving up
CE: Reprogramming failure. Giving up
platform rtc_cmos: registered platform RTC device (no PNP device found)
-------------------------------------------------------------

And when kernel not writing any "CE: " messages domU boots
successfully:

--------------------------------
PCI: System does not support PCI
PCI: System does not support PCI
Switching to clocksource xen
pnp: PnP ACPI: disabled
--------------------------------

Trying to figure out what to do next.

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting

Pandu Poluan


On Apr 12, 2012 8:51 PM, "Konstantin" <[hidden email]> wrote:
>
> Hello,
>
> Thursday, April 12, 2012, 15:52:50, Konstantin wrote:
> > Thursday, April 12, 2012, 15:29:42, Pandu Poluan wrote:
> >>> Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
> >>> > Have you tried:
> >>> > root   = '/dev/xvda1'
> >>> > That is, without 'ro'?
> >>> > Rgds,
> >>>
> >>> Thank you. Already tried without any difference.
> >>>
> >> It's a DomU, right? Why do you have Dom0 option enabled?
>
> > You mean this part of .config file:
> > CONFIG_XEN_DOM0=y
> > CONFIG_XEN_PRIVILEGED_GUEST=y
> > CONFIG_XEN_PVHVM=y
> > CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> > CONFIG_XEN_SAVE_RESTORE=y
>
> > I just could not find how to disable this code in menuconfig. :)
>
> If I'm trying to turn it off, but then other frontend options
> disappear.
>
> Latest update: When I saw
> ---------------------
>  * Starting local
>  [ ok ]
> ---------------------
>
> I've noticed that domU actually working. I've tried to change inittab
> remotely via ssh to something like
>
> # TERMINALS
> x1:12345:respawn:/sbin/agetty 38400 console linux
> #c1:12345:respawn:/sbin/agetty 38400 tty1 linux
> #c2:2345:respawn:/sbin/agetty 38400 tty2 linux
> #c3:2345:respawn:/sbin/agetty 38400 tty3 linux
> #c4:2345:respawn:/sbin/agetty 38400 tty4 linux
> #c5:2345:respawn:/sbin/agetty 38400 tty5 linux
> #c6:2345:respawn:/sbin/agetty 38400 tty6 linux
>
> Then reinitialized init by
> localhost ~ # init q
>
> and console in Dom0 become interactive again. So that freezing after
> "Starting local" was the console problem anyway.
>
> Right now only one left with that random start. DomU starts
> successfully about one time per three unsuccessful.
>
> I've noticed that it gets stuck when kernel outputs this text:
>
> -------------------------------------------------------------
> Switching to clocksource xen
> pnp: PnP ACPI: disabled
> CE: xen increased min_delta_ns to 150000 nsec
> CE: xen increased min_delta_ns to 225000 nsec
> CE: xen increased min_delta_ns to 337500 nsec
> CE: xen increased min_delta_ns to 506250 nsec
> CE: xen increased min_delta_ns to 759375 nsec
> CE: xen increased min_delta_ns to 1139062 nsec
> CE: xen increased min_delta_ns to 1708593 nsec
> CE: xen increased min_delta_ns to 2562889 nsec
> CE: xen increased min_delta_ns to 3844333 nsec
> CE: xen increased min_delta_ns to 5766499 nsec
> CE: xen increased min_delta_ns to 8649748 nsec
> CE: xen increased min_delta_ns to 10000000 nsec
> CE: Reprogramming failure. Giving up
> CE: Reprogramming failure. Giving up
> hrtimer: interrupt took 5171 ns
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> CE: xen increased min_delta_ns to 150000 nsec
> CE: xen increased min_delta_ns to 225000 nsec
> CE: xen increased min_delta_ns to 337500 nsec
> CE: xen increased min_delta_ns to 506250 nsec
> CE: xen increased min_delta_ns to 759375 nsec
> CE: xen increased min_delta_ns to 1139062 nsec
> CE: xen increased min_delta_ns to 1708593 nsec
> CE: xen increased min_delta_ns to 2562889 nsec
> CE: xen increased min_delta_ns to 3844333 nsec
> CE: xen increased min_delta_ns to 5766499 nsec
> CE: xen increased min_delta_ns to 8649748 nsec
> CE: xen increased min_delta_ns to 10000000 nsec
> CE: Reprogramming failure. Giving up
> CE: Reprogramming failure. Giving up
> platform rtc_cmos: registered platform RTC device (no PNP device found)
> -------------------------------------------------------------
>
> And when kernel not writing any "CE: " messages domU boots
> successfully:
>
> --------------------------------
> PCI: System does not support PCI
> PCI: System does not support PCI
> Switching to clocksource xen
> pnp: PnP ACPI: disabled
> --------------------------------
>
> Trying to figure out what to do next.
>
> --
> Konstantin
>
>

Try using "tickless". I forgot where exactly, but IIRC on the same page where you set the CPU type.

Rgds,

Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting [SOLVED]

Konstantin Astafjev
Hello Pandu,

Thursday, April 12, 2012, 17:30:08, Pandu Poluan wrote:

> On Apr 12, 2012 8:51 PM, "Konstantin" <[hidden email]> wrote:
>> Thursday, April 12, 2012, 15:52:50, Konstantin wrote:
>> > Thursday, April 12, 2012, 15:29:42, Pandu Poluan wrote:
>> >>> Thursday, April 12, 2012, 13:09:15, Pandu Poluan wrote:
>> >>> > Have you tried:
>> >>> > root   = '/dev/xvda1'
>> >>> > That is, without 'ro'?
>> >>> > Rgds,
>> >>>
>> >>> Thank you. Already tried without any difference.
>> >>>
>> >> It's a DomU, right? Why do you have Dom0 option enabled?
>>
>> > You mean this part of .config file:
>> > CONFIG_XEN_DOM0=y
>> > CONFIG_XEN_PRIVILEGED_GUEST=y
>> > CONFIG_XEN_PVHVM=y
>> > CONFIG_XEN_MAX_DOMAIN_MEMORY=128
>> > CONFIG_XEN_SAVE_RESTORE=y
>>
>> > I just could not find how to disable this code in menuconfig. :)
>>
>> If I'm trying to turn it off, but then other frontend options
>> disappear.
>>
>> Latest update: When I saw
>> ---------------------
>>  * Starting local
>>  [ ok ]
>> ---------------------
>>
>> I've noticed that domU actually working. I've tried to change inittab
>> remotely via ssh to something like
>>
>> # TERMINALS
>> x1:12345:respawn:/sbin/agetty 38400 console linux
>> #c1:12345:respawn:/sbin/agetty 38400 tty1 linux
>> #c2:2345:respawn:/sbin/agetty 38400 tty2 linux
>> #c3:2345:respawn:/sbin/agetty 38400 tty3 linux
>> #c4:2345:respawn:/sbin/agetty 38400 tty4 linux
>> #c5:2345:respawn:/sbin/agetty 38400 tty5 linux
>> #c6:2345:respawn:/sbin/agetty 38400 tty6 linux
>>
>> Then reinitialized init by
>> localhost ~ # init q
>>
>> and console in Dom0 become interactive again. So that freezing after
>> "Starting local" was the console problem anyway.
>>
>> Right now only one left with that random start. DomU starts
>> successfully about one time per three unsuccessful.
>>
>> I've noticed that it gets stuck when kernel outputs this text:
>>
>> -------------------------------------------------------------
>> Switching to clocksource xen
>> pnp: PnP ACPI: disabled
>> CE: xen increased min_delta_ns to 150000 nsec
>> CE: xen increased min_delta_ns to 225000 nsec
>> CE: xen increased min_delta_ns to 337500 nsec
>> CE: xen increased min_delta_ns to 506250 nsec
>> CE: xen increased min_delta_ns to 759375 nsec
>> CE: xen increased min_delta_ns to 1139062 nsec
>> CE: xen increased min_delta_ns to 1708593 nsec
>> CE: xen increased min_delta_ns to 2562889 nsec
>> CE: xen increased min_delta_ns to 3844333 nsec
>> CE: xen increased min_delta_ns to 5766499 nsec
>> CE: xen increased min_delta_ns to 8649748 nsec
>> CE: xen increased min_delta_ns to 10000000 nsec
>> CE: Reprogramming failure. Giving up
>> CE: Reprogramming failure. Giving up
>> hrtimer: interrupt took 5171 ns
>> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
>> TCP: Hash tables configured (established 131072 bind 65536)
>> TCP reno registered
>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>> CE: xen increased min_delta_ns to 150000 nsec
>> CE: xen increased min_delta_ns to 225000 nsec
>> CE: xen increased min_delta_ns to 337500 nsec
>> CE: xen increased min_delta_ns to 506250 nsec
>> CE: xen increased min_delta_ns to 759375 nsec
>> CE: xen increased min_delta_ns to 1139062 nsec
>> CE: xen increased min_delta_ns to 1708593 nsec
>> CE: xen increased min_delta_ns to 2562889 nsec
>> CE: xen increased min_delta_ns to 3844333 nsec
>> CE: xen increased min_delta_ns to 5766499 nsec
>> CE: xen increased min_delta_ns to 8649748 nsec
>> CE: xen increased min_delta_ns to 10000000 nsec
>> CE: Reprogramming failure. Giving up
>> CE: Reprogramming failure. Giving up
>> platform rtc_cmos: registered platform RTC device (no PNP device found)
>> -------------------------------------------------------------
>>
>> And when kernel not writing any "CE: " messages domU boots
>> successfully:
>>
>> --------------------------------
>> PCI: System does not support PCI
>> PCI: System does not support PCI
>> Switching to clocksource xen
>> pnp: PnP ACPI: disabled
>> --------------------------------
>>
>> Trying to figure out what to do next.

> Try using "tickless". I forgot where exactly, but IIRC on the same page where you set the CPU type.
> Rgds,

If you mean Tickless System (Dynamic Ticks) as NO_HZ=y so it already
enabled for me.

I figured out how to solve my problem with DomU. I've changed tsc_mode
to something different from 0 or 4 and it seems started to work for
me.

Here is short tsc_mode option description from sample VM config file:

#----------------------------------------------------------------------------
#   tsc_mode : TSC mode (0=default, 1=native TSC, 2=never emulate, 3=pvrdtscp)
#   emulate TSC provides synced TSC for all vcpus, but lose perfomrance.
#   native TSC leverages hardware's TSC(no perf loss), but vcpu's TSC may lose
#    sync due to hardware's unreliable/unsynced TSC between CPUs.
#   default intelligently uses native TSC on machines where it is safe, but
#    switches to emulated if necessary after save/restore/migration
#   pvrdtscp is for intelligent apps that use special Xen-only paravirtualized
#    cpuid instructions to obtain offset/scaling/migration info and maximize
#    performance within pools of machines that support the rdtscp instruction
tsc_mode=1

BTW, does anybody has NTP server on a virtual machine? ;)

--
Konstantin


Reply | Threaded
Open this post in threaded view
|

Re: DomU freezes in the middle of booting [SOLVED]

Pandu Poluan


On Apr 12, 2012 9:46 PM, "Konstantin" <[hidden email]> wrote:
>
> Hello Pandu,
>
>
> If you mean Tickless System (Dynamic Ticks) as NO_HZ=y so it already
> enabled for me.
>
> I figured out how to solve my problem with DomU. I've changed tsc_mode
> to something different from 0 or 4 and it seems started to work for
> me.
>
> Here is short tsc_mode option description from sample VM config file:
>
> #----------------------------------------------------------------------------
> #   tsc_mode : TSC mode (0=default, 1=native TSC, 2=never emulate, 3=pvrdtscp)
> #   emulate TSC provides synced TSC for all vcpus, but lose perfomrance.
> #   native TSC leverages hardware's TSC(no perf loss), but vcpu's TSC may lose
> #    sync due to hardware's unreliable/unsynced TSC between CPUs.
> #   default intelligently uses native TSC on machines where it is safe, but
> #    switches to emulated if necessary after save/restore/migration
> #   pvrdtscp is for intelligent apps that use special Xen-only paravirtualized
> #    cpuid instructions to obtain offset/scaling/migration info and maximize
> #    performance within pools of machines that support the rdtscp instruction
> tsc_mode=1
>

Ah, glad to hear that.

> BTW, does anybody has NTP server on a virtual machine? ;)
>

Actually, I do. With tickless, the clock drifts around unpredictably, so I resort to having one of my VMs sync to the NTP pool, while other VMs sync to that VM.

Rgds,