[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Ahh the difference between console on the other devices seems to be "XENBUS: 
Device with no driver: device/console/0"
That makes it states "initializing" for ever ...
It then probably goes wrong with the "out:" path in xenbus_dev_shutdown() doing 
the put_device ?

I only fail to see why it seems to cause a problem with multiple vpcu's 
assigned and not with just one.

--
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.