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
