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