On Thu, 2006-12-14 at 08:24 +0000, Keir Fraser wrote:
> On 13/12/06 8:11 pm, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> wrote:
>
> > I've noticed today that some xenbus state changes are reported twice, as
> > in the follow example from dmesg:
> >
> > state is 4 (Connected), /local/domain/8/device/vif/4/state,
> > /local/domain/8/device/vif/4/stateDele
> > state is 4 (Connected), /local/domain/8/device/vif/4/state,
> > /local/domain/8/device/vif/4/stateDele
> >
> > I'm not sure whether this is legal or a bug.
>
> It's certainly legal, but a bit surprising and annoying. Only the 'state'
> node is watched, so presumably it is getting written to twice?
I'm not yet sure about the root of this problem. But from what I've
gathered so far, it seems (I'll try confirming this today) that the two
fires are actually happening. But one of them is for InitWait, and the
other one is for Closing. But when the first one is read, Closing state
has already been written in the store, overwriting the old value. (It is
not the situation that is shown in the log, tough. I'm analyzing it more
on the guest side now). Result is that guest reads Closing twice, when
it should be reading InitWait and Closing. Do you think this is a
reasonable hypothesis ?
Moreover, if multiple triggers are indeed valid, we should maybe take
extra care about double fires in drivers. For example, this situation I'
m describing crashes xennet on domU, because when receiving the second
Closing, it tries to unregister_netdev() again, in an invalid state.
Thanks
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home