| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] vbd devices stuck in Initialising/InitWait
Ewan Mellor wrote:
That sounds to me like the guest kernel is crashing or deadlocking. Do you
see anything on the guest console? Perhaps you could put #define DEBUG 1 at
the top of blkfront/block.h and xenbus/xenbus_probe.c for your guest kernel,
and try and figure out where it is getting stuck.
The domains aren't crashing since they will boot, provided the root
device isn't among the missing...
I've added DEBUG a bunch of printk's to talk_to_backend() and
xenbus_switch_state(). The outputs are here:
http://www.theshore.net/~caker/xen/InitWait/dmesg-working.txt
http://www.theshore.net/~caker/xen/InitWait/dmesg-not_working.txt
At the bottom of both of those files, I've pasted in just the debugging
messages in order.
There are two main differences:
When devices are missing, talk_to_backend() is making duplicate calls
for the same vbd to xenbus_switch_state(), and on the second call
xenbus_switch_state avoids writing to xenstore an identical value (which
it's supposed to). Why the duplicate calls?
Second difference: even though there were two calls to
xenbus_switch_state) to set the state to 3, later on xenbus_probe only
detects the state as 2.
talk_to_backend - about to call xenbus_switch_state
xenbus_switch_state() nodename=device/vbd/770 state=3 - entering
xenbus_switch_state() nodename=device/vbd/770 state=3 - finished
talk_to_backend - about to call xenbus_switch_state
xenbus_switch_state() nodename=device/vbd/770 state=3 - entering
xenbus_switch_state() nodename=device/vbd/770 state=3 - state == dev->state
but then:
xenbus_probe (otherend_changed:302) state is 2,
/local/domain/0/backend/vbd/151/770/state,
/local/domain/0/backend/vbd/151/770/state.
So, is this a deadlock or locking issue like you suspected?
Thanks,
-Chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home