[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] Driver 8.2 not working with Xen 4.9

Laurent,

 

  Ok, that’s a bit more interesting J

 

  The frontend area is in state 4 (connected) and will be waiting for the backend to go into the same state:

 

/local/domain/14/device/vif/0/backend-id = "0"

/local/domain/14/device/vif/0/state = "4"

/local/domain/14/device/vif/0/handle = "0"

/local/domain/14/device/vif/0/mac = "00:16:3e:00:03:98"

/local/domain/14/device/vif/0/request-rx-copy = "1"

/local/domain/14/device/vif/0/feature-sg = "1"

/local/domain/14/device/vif/0/feature-rx-notify = "1"

/local/domain/14/device/vif/0/feature-gso-tcpv4 = "1"

/local/domain/14/device/vif/0/feature-gso-tcpv6 = "1"

/local/domain/14/device/vif/0/feature-no-csum-offload = "0"

/local/domain/14/device/vif/0/feature-ipv6-csum-offload = "1"

/local/domain/14/device/vif/0/rx-ring-ref = "32"

/local/domain/14/device/vif/0/event-channel = "13"

/local/domain/14/device/vif/0/tx-ring-ref = "33"

/local/domain/14/device/vif/0/multi-queue-num-queues = "1"

 

  This all looks generally ok. The backend area shows:

 

/local/domain/0/backend/vif/14/0 = ""

/local/domain/0/backend/vif/14/0/frontend = "/local/domain/14/device/vif/0"

/local/domain/0/backend/vif/14/0/frontend-id = "14"

/local/domain/0/backend/vif/14/0/_online_ = "1"

/local/domain/0/backend/vif/14/0/state = "2"

/local/domain/0/backend/vif/14/0/script = "/etc/xen/scripts/vif-bridge-stemina"

/local/domain/0/backend/vif/14/0/mac = "00:16:3e:00:03:98"

/local/domain/0/backend/vif/14/0/bridge = "wan"

/local/domain/0/backend/vif/14/0/handle = "0"

/local/domain/0/backend/vif/14/0/type = "vif_ioemu"

/local/domain/0/backend/vif/14/0/feature-sg = "1"

/local/domain/0/backend/vif/14/0/feature-gso-tcpv4 = "1"

/local/domain/0/backend/vif/14/0/feature-rx-copy = "1"

/local/domain/0/backend/vif/14/0/feature-rx-flip = "0"

 

  It appears to be stuck in state 2. This may be due to netback requiring the hotplug script to do something, or perhaps a udev event to occur; I’m not sure. However, your problem is definitely in your backend and not the Windows frontend… it’s just waiting patiently.

  Have you perhaps updated to Xen 4.9 from a much older Xen? The libxl toolstack in older Xen used to rely on udev rules but newer versions of the toolstack execute hotplug scripts directly so I wonder whether you have a double invocation of a hotplug script (or even perhaps invocation of two different scripts) leading to the backend becoming confused. You may want to have a look at your active set of of udev rules and clean out any Xen related ones.

 

  Paul

 

From: Laurent Sauve [mailto:lsauve@xxxxxxxx]
Sent: 16 November 2017 14:55
To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Subject: Re: Driver 8.2 not working with Xen 4.9

 

This is xenstore-ls with –s and –f after I booted the VM with both xennet install. The VM is stuck waiting for something (see screenshot).

 

Laurent Sauve
Spécialiste Platforme et Ingénierie Infonuagique – Cloud Platform and Engineering Specialist

O: 514.732.7507  |  C: 514.732.6637

ebok_Icon.pngkedin_Icon.pngtter_Icon.png

Ce message est destiné à l’usage exclusif du (des) destinataire(s) et peut contenir des informations privilégiées et confidentielles.

L’utilisation, la divulgation et la distribution non autorisée est interdite.

Si ce courriel ne vous est pas destiné, merci de contacter l’expéditeur en répondant à ce message et détruisez toutes les copies du message d’origine.

 

This message is intended for the use of the intended recipient(s) and may contain confidential and privileged information.

Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact

the sender by reply e-mail and destroy all copies of the original message.

 

From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date: Thursday, November 16, 2017 at 09:29
To: Laurent Sauve <lsauve@xxxxxxxx>
Cc: "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: Driver 8.2 not working with Xen 4.9

 

Laurent,

 

  Was the xenstore output taken after XENNET was installed and the VM rebooted? Both the frontend and backend are in state 6 (closed) with no apparent attempt by XENVIF to connect to the backend. What state is the VM in? Has it hung?

 

  Paul

 

From: Laurent Sauve [mailto:lsauve@xxxxxxxx]
Sent: 16 November 2017 14:16
To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Driver 8.2 not working with Xen 4.9

 

Here are the xenstore-ls and xl dmesg command output.

 

Laurent Sauve

From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date: Thursday, November 16, 2017 at 05:10
To: Laurent Sauve <lsauve@xxxxxxxx>, "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: Driver 8.2 not working with Xen 4.9

 

Laurent,

 

  The log snippet below is expected behaviour when you install XENNET. The emulated Realtek device is present so XENVIF stashes the network settings corresponding to that, sets a registry key to request unplug of emulated NICs at next boot, sets another registry key so that the monitor service will request reboot (the dialog that you see popping up) and then fails the PDO start IRP (which is why you see the warning in device manager). The question is what happens *after* reboot.

  I’m assuming the file ‘qemu-dm-ThisIsTheVmName’ is the post-reboot log and from that we see:

 

XENNET|DriverEntry: XENNET 8.2.0 (6) (28.02.2017)

XENVIF|PdoSetFriendlyName: 0: Xen PV Network Device #0

XENVIF|SettingsRestore: TO Ethernet 5 (Xen PV Network Device #0)

XENVIF|SettingsCopyIpAddresses: Version6: ADDRESSES NOT FOUND

XENVIF|FrontendSetState: device/vif/0: ====> 'CLOSED' -> 'CONNECTED'

XENVIF|FrontendSetState: device/vif/0 in state 'PREPARED'

XENVIF|__MacSetPermanentAddress: attr/vif/0: 00:16:3E:00:03:98

XENVIF|__MacSetCurrentAddress: attr/vif/0: 00:16:3E:00:03:98

XENVIF|FrontendSetNumQueues: device/vif/0: 1

XENVIF|FrontendSetSplit: device/vif/0: FALSE

GNTTAB: MAX FRAMES = 256

XENBUS|RangeSetPop: fail1 (c000009a)

GNTTAB: MAP XENMAPSPACE_grant_table[0] @ 00000000.f2001000

XENBUS|GnttabExpand: added references [00000020 - 000001ff]

 

  This is XENVIF noticing the stashed settings and copying them into XENNET’s registry area. XENVIF is attempting to transition from the CLOSED state to the connected STATE but is seemingly getting stuck. I see no failure message here though, nor do I see any failure message from netback in kern.log. The fact that FrontendSetNumQueues() has only set a single queue, and FrontendSetSplit() says FALSE suggested that you have a very old netback and indeed when I then look at the top of kern.log I see “Linux version 3.1.0-r128-iweb”, which is pretty ancient. So, my suspicion is that there is some incompatibility in the xenstore protocol between the old netback and the newer XENVIF. I assume the VM is probably hung at this point waiting for netback to respond. Could you send me the ouput of xenstore-ls (in dom0) at this point? From that we can determine the current state of negotiation with netback and attempt to figure out why it might have wedged up.

 

  Paul

 

From: Laurent Sauve [mailto:lsauve@xxxxxxxx]
Sent: 15 November 2017 21:04
To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Driver 8.2 not working with Xen 4.9

 

I made a clean install and follow one of the post you made to explain order of installation for the drivers as follow:

 

1. xenbus

2. xenvif

3. xennet

4. reboot

5. xenvbd

6. reboot

7. xeniface

 

I can do 1-3, the at reboot its stuck. I again join the logs from the complete installation and the kern.log. So far, I can boot the VM when I got in device manager and disable the XEN PV Network Driver for the network card but I first need to go to safe mode for that.

 

 

When I try to enable the driver, I get this in the qemu log:

 

XENNET|DriverEntry: XENNET 8.2.0 (6) (28.02.2017)

XENVIF|PdoSetFriendlyName: 0: Xen PV Network Device #0

XENVIF|SettingsSave: FROM Ethernet (Realtek RTL8139C+ Fast Ethernet NIC)

XENVIF|SettingsCopyIpAddresses: Version6: ADDRESSES NOT FOUND

XENBUS|UnplugRequest: NICS (MAKE)

XEN|UnplugIncrementValue: NICS 1

XENVIF|PdoStartDevice: fail9

XENVIF|__DriverRequestReboot: ====>

XENVIF|__DriverRequestReboot: <====

XENVIF|PdoStartDevice: fail8

XENVIF|PdoStartDevice: fail7

XENVIF|PdoStartDevice: fail6

XENVIF|PdoStartDevice: fail5

XENVIF|PdoStartDevice: fail4

XENVIF|PdoStartDevice: fail3

XENVIF|PdoStartDevice: fail2

XENVIF|PdoStartDevice: fail1 (c0000001)

XENNET|DriverUnload: XENNET 8.2.0 (6) (28.02.2017)

 

And the screenshot of Screen Shot 2017-11-13 at 12.42.29 and Screen Shot 2017-11-15 at 10.02.06 and the reboot is then stuck again.

 

Hope this can help see what the trouble is.

 

Laurent Sauve

 

 

 

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel

 

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.

Rackspace

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