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

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

  • To: Micky <mickylmartin@xxxxxxxxx>
  • From: James Harper <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Mon, 20 May 2013 01:43:42 +0000
  • Accept-language: en-AU, en-US
  • Cc: "xen-users@xxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 20 May 2013 01:45:12 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>
  • Thread-topic: [Xen-users] gplpv: re-enabling the nic adapter removes it

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


Xen-users mailing list



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