Re: [Xen-users] gplpv: re-enabling the nic adapter removes it

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> 
> I should have mentioned the dom0 kernel version at the beginning. Must
> have forgotten.
> It is 3.8.8-1.el6xen.x86_64 not self compiled but taken from CRC's repo.
> 

My test machine is Debian 3.8.5 which should be close enough although it's 
possible there is a patch that changes the state transition in a subtle way.

> > Currently there is no timeout implemented, xennet just waits forever fort
> > the backend to progress to the next state. I can put a timeout in there 
> > which
> > will give you a more sensible error (eg windows will complain that device
> > couldn't start or something) instead of hanging, but won't solve the
> > underlying problem.
> 
> Yea, right now the problem is not irritating but makes me just curious
> since some most people encounter it. Not certainly the end of world
> but would help if the driver doesn't crash.
> 
> >
> > You only included the xennet stuff in your logs so I can't see if xenpci is
> > doing the right thing, I can't imagine it will tell me anything different 
> > though.
> > Can you  also send me the end of the kernel logs as there should be some
> > messages logged as the backend changes state.
> 
> Sure. Snippet of the logs is below. But I am afraid if kernel tells
> anything but few telltale signs of what's happening other than telling
> a vif is disabled.
> 
>  br0: port 3(vif159.0) entered disabled state
> device vif159.0 left promiscuous mode
> br0: port 3(vif159.0) entered disabled state
> frontend_changed: backend/vif/159/0: prepare for reconnect
> 

I'd expect an error would be logged if the reconnect failed but I can't be sure.

Can you try disabling both adapters so the driver unloads then enable them both 
again (even if it gets stuck when the first one loads)?

James


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users