[Xen-devel] Re: No shutdown of domU: xenbus_dev_shutdown: device/console/0: Initialising != Connected, skipping

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

OK ... so when a pv domU shutdown, in xenbus_dev_shutdown, what does the call 
dev->state return for a console ?
and why does it only seems to cause a problem for domains with multiple vcpu's 
assigned ?

--
Sander


Wednesday, November 17, 2010, 1:06:04 PM, you wrote:

> Consoles do not have a connection handshake. If there is a state field in
> xenstore, it is only unused detritus written by the toolstack
> (xend/libxl/whatever).

>  -- Keir

> On 17/11/2010 11:58, "Sander Eikelenboom" <linux@xxxxxxxxxxxxxx> wrote:

>> Hmm .. i haven't received any response, is there anyone who could point me to
>> the functions involved in communicating the state of the console from
>> "initializing" to "connected" ?
>> That way i could at some additional printk's to find out why the state of 
>> domU
>> consoles stays "1" instead of "4" in xenstore.
>> 
>> --
>> Sander
>> 
>> Friday, November 12, 2010, 6:30:10 PM, you wrote:
>> 
>>> I'm encountering the following problem:
>> 
>>> When trying to shutdown a PV domU with more than 1 vpcu, the shutdown fails.
>>> The domain keeps running with 100% cpu, and it's still possible to get the
>>> console of this domU with xm console.
>>> When only 1 vcpu is assigned the domain does shutdown.
>> 
>>> Last lines of the PV domU console:
>> 
>>> Debian GNU/Linux 5.0 tv hvc0
>> 
>>> INIT: Switching to runlevel: 0
>>> INIT: Sending processes the TERM signal
>>> Stopping web server: apache2 ... waiting .
>>> Stopping MythTV server: mythbackend No /usr/bin/mythbackend found running;
>>> none killed.
>>> .
>>> Stopping MTA: exim4_listener.
>>> Stopping rsync daemon: rsync.
>>> Stopping MySQL database server: mysqld.
>>> Saving the system clock.
>>> Cannot access the Hardware Clock via any known method.
>>> Use the --debug option to see the details of our search for an access 
>>> method.
>>> Stopping enhanced syslogd: rsyslogd.
>>> Asking all remaining processes to terminate...done.
>>> All processes ended within 2 seconds....done.
>>> Deconfiguring network interfaces...done.
>>> Cleaning up ifupdown....
>>> Deactivating swap...done.
>>> Unmounting local filesystems...done.
>>> Will now halt.
>>> [ 4336.046876] md: stopping all md devices.
>>> [ 4337.047171] xenbus_dev_shutdown:  trying shutdown of device/console/0:
>>> Initialising
>>> [ 4337.047194] xenbus_dev_shutdown: device/console/0: Initialising !=
>>> Connected, skipping
>>> [ 4337.047200] xenbus_dev_shutdown: result of shutdown of device/console/0:
>>> Initialising
>>> [ 4337.047205] xenbus_dev_shutdown:  trying shutdown of device/vif/0:
>>> Connected
>>> [ 4337.110869] xenbus_dev_shutdown: result of shutdown of device/vif/0:
>>> Closed
>>> [ 4337.110883] xenbus_dev_shutdown:  trying shutdown of device/vbd/51714:
>>> Connected
>>> [ 4337.161975] xenbus_dev_shutdown: result of shutdown of device/vbd/51714:
>>> Closed
>>> [ 4337.161989] xenbus_dev_shutdown:  trying shutdown of device/vbd/51713:
>>> Connected
>>> [ 4337.217136] xenbus_dev_shutdown: result of shutdown of device/vbd/51713:
>>> Closed
>>> [ 4337.217167] System halted.
>> 
>> 
>>> But when using xenstore-ls .. i see that for every domain (but 1 and 
>>> multiple
>>> vcpu's):
>>>     - All devices have state=4
>>>     - Except all backend = "/local/domain/0/backend/console/*/0" entries,
>>> those have state=1
>>>     - Although xenstore is saying the state is initializing .. xm console
>>> works perfectly for all domains.
>>>     - Perhaps this also explains the high event/0 load in dom0, related to
>>> tty and xenconsoled ?
>> 
>>> DomU kernels vary from debian 2.6.26-xen kernels, to 2.6.37-rc1 mainline.
>>> Xen-unstable-tip and xen-next-2.6.32 dom0
>> 
>> 
>>> --
>>> Sander
>> 
>> 





-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


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