Re: [win-pv-devel] New windows pv drivers question

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> Sent: 25 September 2014 12:29
> To: Paul Durrant
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx; Ben Chalmers
> Subject: Re: New windows pv drivers question
> 
> Il 25/09/2014 12:00, Fabio Fantoni ha scritto:
> > Il 24/09/2014 16:03, Paul Durrant ha scritto:
> >>> -----Original Message-----
> >>> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> >>> Sent: 24 September 2014 14:52
> >>> To: Paul Durrant
> >>> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> >>> Subject: Re: New windows pv drivers question
> >>>
> >>> Il 24/09/2014 15:19, Paul Durrant ha scritto:
> >>>>> -----Original Message-----
> >>>>> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> >>>>> Sent: 24 September 2014 14:07
> >>>>> To: Paul Durrant
> >>>>> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> >>>>> Subject: Re: New windows pv drivers question
> >>>>>
> >>>>> Il 24/09/2014 11:15, Paul Durrant ha scritto:
> >>>>>>> -----Original Message-----
> >>>>>> [snip]
> >>>>>>>>>> Traceback (most recent call last):
> >>>>>>>>>>       File
> >>>>>>>>>> "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line
> >>> 365,
> >>>>>>>>>> in <module
> >>>>>>>>>>         build_sln(driver, release, 'x64', debug[sys.argv[1]],
> >>>>>>>>>> vs)
> >>>>>>>>>>       File
> >>>>>>>>>> "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line
> >>> 138,
> >>>>>>>>>> in build_s
> >>>>>>>>>> ln
> >>>>>>>>>>         msbuild(platform, configuration, 'Build', name +
> >>>>>>>>>> '.sln', '', vs)
> >>>>>>>>>>       File
> >>>>>>>>>> "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line
> >>> 122,
> >>>>>>>>>> in msbuild
> >>>>>>>>>>
> >>>>>>>>>>         status = shell([bin], dir)
> >>>>>>>>>>       File
> >>>>>>>>>> "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line
> >>> 100,
> >>>>>>>>>> in shell
> >>>>>>>>>>         print(line.rstrip())
> >>>>>>>>>>       File "C:\Python34\lib\encodings\cp850.py", line 19, in
> >>>>>>>>>> encode
> >>>>>>>>>>         return
> >>>>> codecs.charmap_encode(input,self.errors,encoding_map)[0]
> >>>>>>>>>> UnicodeEncodeError: 'charmap' codec can't encode character
> >>> '\u2026'
> >>>>> in
> >>>>>>>>>> position
> >>>>>>>>>> 28: character maps to <undefined>
> >>>>>>>>> I did something wrong or there is a bug or unexpected case?
> >>>>>>>>> Thanks for any reply.
> >>>>>>>> Not seen anything like that before. I can only assume it's to
> >>>>>>>> do with
> >>>>>>> language support. It seems like msbuild is emitting characters
> >>>>>>> that the
> >>>>> shell is
> >>>>>>> not handling correctly. I suspect you'll be ok if you use an
> >>>>>>> English
> >>> character
> >>>>>>> set but I'll try to figure out what the script is/isn't doing.
> >>>>>>>>       Paul
> >>>>>>>>
> >>>>>>> I installed english language pack and solves the problem.
> >>>>>> Ok. So we know what the problem was. We need to figure out a
> >>>>>> solution
> >>> to
> >>>>> that.
> >>>>>
> >>>>> Thanks, for now I built with english windows.
> >>>>>
> >>>>>>> After gave me other error about no sufficent permission on one
> >>>>>>> exe of
> >>>>>>> WDK, I tried to execute as administrator and did max permissions
> to
> >>>>>>> everyone on the file but not, I solved also that adding nosdv.
> >>>>>> I've seen problems running sdv where some of the processes it
> >>>>>> kicks off
> >>>>> seem to conflict on one of the log files, so it bails with a lack
> >>>>> of write
> >>>>> permission. Is that the sort of thing you saw?
> >>>>>
> >>>>> Probably, you need that I retry and post the exactly output of error?
> >>>>>
> >>>>>>> After I had near the end another error where I not found a
> >>> workaround:
> >>>>>>>> Done Building Project
> >>>>>>>> "C:\Users\Emilio\Desktop\pvdrivers\xenbus\vs2013\xenbus.sl
> >>>>>>>> n" (Build target(s)).
> >>>>>>>>
> >>>>>>>> Build succeeded.
> >>>>>>>>        0 Warning(s)
> >>>>>>>>        0 Error(s)
> >>>>>>>>
> >>>>>>>> Time Elapsed 00:00:02.37
> >>>>>>>>
> >>>>>>>> C:\Users\Emilio\Desktop\pvdrivers\xenbus\vs2013>if errorlevel 1
> >>> goto
> >>>>>>> error
> >>>>>>>> C:\Users\Emilio\Desktop\pvdrivers\xenbus\vs2013>exit 0
> >>>>>>>> vs2013\Windows7Release\Win32
> >>>>>>>> ['"C:\\Program Files (x86)\\Windows
> >>>>>>>> Kits\\8.1\\Debuggers\\x86\\symstore.exe"', '
> >>>>>>>> add', '/s', 'C:\\Symbols', '/r', '/f', '*.pdb', '/t', 'xenbus',
> >>>>>>>> '/v',
> >>>>>>>> '8.0.0.12'
> >>>>>>>> ]
> >>>>>>>> Finding ID...  0000000015
> >>>>>>>>
> >>>>>>>> SYMSTORE: Number of files stored = 3
> >>>>>>>> SYMSTORE: Number of errors = 0
> >>>>>>>> SYMSTORE: Number of files ignored = 0
> >>>>>>>> vs2013\Windows7Release\x64
> >>>>>>>> ['"C:\\Program Files (x86)\\Windows
> >>>>>>>> Kits\\8.1\\Debuggers\\x86\\symstore.exe"', '
> >>>>>>>> add', '/s', 'C:\\Symbols', '/r', '/f', '*.pdb', '/t', 'xenbus',
> >>>>>>>> '/v',
> >>>>>>>> '8.0.0.12'
> >>>>>>>> ]
> >>>>>>>> Finding ID...  0000000016
> >>>>>>>>
> >>>>>>>> SYMSTORE: Number of files stored = 3
> >>>>>>>> SYMSTORE: Number of errors = 0
> >>>>>>>> SYMSTORE: Number of files ignored = 0
> >>>>>>>> Traceback (most recent call last):
> >>>>>>>>      File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py",
> >>>>>>>> line 375,
> >>>>>>>> in <module
> >>>>>>>>        archive(driver + '\source.tgz', manifest().splitlines(),
> >>>>>>>> tgz=True)
> >>>>>>>>      File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py",
> >>>>>>>> line 289,
> >>>>>>>> in manifes
> >>>>>>>> t
> >>>>>>>>        sub = subprocess.Popen(cmd, stdout=subprocess.PIPE)
> >>>>>>>>      File "C:\Python34\lib\subprocess.py", line 858, in __init__
> >>>>>>>>        restore_signals, start_new_session)
> >>>>>>>>      File "C:\Python34\lib\subprocess.py", line 1111, in
> >>>>>>>> _execute_child
> >>>>>>>>        startupinfo)
> >>>>>>>> FileNotFoundError: [WinError 2] The system cannot find the file
> >>> specified
> >>>>>> That looks like git is not on your path. The build script adds an
> >>>>>> archive of
> >>> the
> >>>>> source to the output. I should probably just remove that from the
> >>>>> script.
> >>>>>>> I saw that in repository folder\xenbus\(x64|x86) seems there are
> >>>>>>> the
> >>>>>>> drivers ready, is correct and can be tried?
> >>>>>>>
> >>>>>> Yes. They should be good to go.
> >>>>> Installed all 5 drivers in windows 7 pro 64 bit sp1.
> >>>>> On boot now take very long time (much more time that with other
> >>> windows
> >>>>> pv or without any) until arrive at login screen, network card is not
> >>>>> visible (show unable to boot both emulated and pv network card).
> >>>>> Testsigning is enabled and the other pv drivers was removed and
> >>> rebooted
> >>>>> before install this new.
> >>>>> On same dom0 and domU with other pv drivers (of James Harper) I
> had
> >>> only
> >>>>> these 2 problems:
> >>>>> - occasional network disappaer after some hours or days (probable
> >>> xennet
> >>>>> crash)
> >>>>> - 2-3 time of "hang" after restore with qxl vga and vdagent enable
> >>>>>
> >>>>> This is the domU's cfg:
> >>>>>> name='W7-02'
> >>>>>> builder="hvm"
> >>>>>> memory=2048
> >>>>>> vcpus=2
> >>>>>> vif=['bridge=xenbr0,mac=00:16:3e:42:a2:5f']
> >>>>>> disk=['/mnt/vm/disks/W7-
> 02.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> >>>>>> boot='dc'
> >>>>>> device_model_version="qemu-xen"
> >>>>>> viridian=1
> >>>>>> vnc=0
> >>>>>> keymap="it"
> >>>>>> on_crash="destroy"
> >>>>>> vga="qxl"
> >>>>>> spice=1
> >>>>>> spicehost='0.0.0.0'
> >>>>>> spiceport=6003
> >>>>>> spicedisable_ticketing=1
> >>>>>> spicevdagent=1
> >>>>>> spice_clipboard_sharing=0
> >>>>>> spiceusbredirection=4
> >>>>>> soundhw="hda"
> >>>>>> localtime=1
> >>>>>> usbversion=2
> >>>>> I tried also disabling qxl, vdagent, audio and usb:
> >>>>>> name='W7-02'
> >>>>>> builder="hvm"
> >>>>>> memory=2048
> >>>>>> vcpus=2
> >>>>>> vif=['bridge=xenbr0,mac=00:16:3e:42:a2:5f']
> >>>>>> disk=['/mnt/vm/disks/W7-
> 02.disk1.xm,raw,hda,rw',',raw,hdb,ro,cdrom']
> >>>>>> boot='dc'
> >>>>>> device_model_version="qemu-xen"
> >>>>>> viridian=1
> >>>>>> vnc=0
> >>>>>> keymap="it"
> >>>>>> on_crash="destroy"
> >>>>>> vga="stdvga"
> >>>>>> spice=1
> >>>>>> spicehost='0.0.0.0'
> >>>>>> spiceport=6003
> >>>>>> spicedisable_ticketing=1
> >>>>>> spicevdagent=0
> >>>>>> spice_clipboard_sharing=0
> >>>>>> #spiceusbredirection=4
> >>>>>> #soundhw="hda"
> >>>>>> localtime=1
> >>>>>> #usbversion=2
> >>>>> But I had same problems.
> >>>>> Dom0 is wheezy with xen-unstable of some days ago plus some libxl
> >>>>> patch
> >>>>> (https://github.com/Fantu/Xen/tree/rebase/m2r-staging) and qemu
> >>> 2.1.1
> >>>>> Now I'll try also with W8.
> >>>>>
> >>>>> If you need more details and/or tests tell me and I'll post them.
> >>>>>
> >>>> If you could enable xen_platform_log in QEMU then the QEMU log
> should
> >>> tell us what's going on. If you don't know how to do that then the
> >>> way I do it
> >>> is to create a file called 'events' under /tmp populated with the
> >>> single line:
> >>>> xen_platform_log
> >>>>
> >>>> and then I add:
> >>>>
> >>>> device_model_args=[ "-trace", "events=/tmp/events"]
> >>>>
> >>>> to my config. QEMU by default is built to send traces to stderr, so
> >>>> you
> >>> should see the log entries appear in /var/log/xen/qemu-dm-<vm
> >>> name>.log.
> >>>> Did you try installing the drivers in a fresh VM? It's possible
> >>>> that there is still
> >>> some remnant of the GPLPV drivers around - uninstalling drivers on
> >>> Windows
> >>> is tricky.
> >>> Thanks for reply.
> >>> Tried with trace (log in attachment), with a fast look a saw a strange
> >>> mac different from the one setted in cfg.
> >>> I tried removing fixed mac in xl cfg but the network card problem
> >>> persist.
> >>> The old pv should be completly removed, I used also the bat for remove
> >>> the registry keys and file, not only the unstall from control panel.
> >>> I'll try also a clean install ASAP.
> >> Your PV storage looks fine, but the problem with your network is here:
> >>
> >> xen_platform_log xen platform:
> XENVIF|__FrontendWaitForStateChange:
> >> fail3
> >> xen_platform_log xen platform:
> XENVIF|__FrontendWaitForStateChange:
> >> fail2
> >> xen_platform_log xen platform:
> XENVIF|__FrontendWaitForStateChange:
> >> fail1 (c0000001)
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail10
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail9
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail8
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail7
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail6
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail5
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail4
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail3
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail2
> >> xen_platform_log xen platform: XENVIF|__FrontendConnect: fail1
> >> (c0000001)
> >> xen_platform_log xen platform: XENVIF|__PdoD3ToD0: fail1 (c0000001)
> >> xen_platform_log xen platform: XENVIF|PdoD3ToD0: fail2
> >> xen_platform_log xen platform: XENVIF|PdoD3ToD0: fail1 (c0000001)
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail7
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail6
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail5
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail4
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail3
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail2
> >> xen_platform_log xen platform: XENVIF|PdoStartDevice: fail1 (c0000001)
> >>
> >> What this means is that your frontend waited for a very very long
> >> time for your backend to go connected, and it failed to do so. It
> >> then  give up and you get the above cascade of error logging. I
> >> suspect the problem is a lack of the following netback fix:
> >>
> >> commit 279f438e36c0a70b23b86d2090aeec50155034a9
> >> Author: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Date:   Tue Sep 17 17:46:08 2013 +0100
> >>
> >>      xen-netback: Don't destroy the netdev until the vif is shut down
> >>
> >>      Without this patch, if a frontend cycles through states Closing
> >>      and Closed (which Windows frontends need to do) then the netdev
> >>      will be destroyed and requires re-invocation of hotplug scripts
> >>      to restore state before the frontend can move to Connected. Thus
> >>      when udev is not in use the backend gets stuck in InitWait.
> >>
> >>      With this patch, the netdev is left alone whilst the backend is
> >>      still online and is only de-registered and freed just prior to
> >>      destroying the vif (which is also nicely symmetrical with the
> >>      netdev allocation and registration being done during probe) so
> >>      no re-invocation of hotplug scripts is required.
> >>
> >>      Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> >>      Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
> >>      Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> >>      Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>      Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> >>      Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> >
> > I found it applied upstream:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-
> next.git/commit/?id=279f438e36c0a70b23b86d2090aeec50155034a9
> >
> > But not in 3.2-stable branch, I tried to apply it on latest Wheezy
> > (debian 7) kernel source but there are too many difference and I was
> > unable to apply it manually.
> > Can someone give me advices please?
> >
> > Use kernel from wheezy-backports (3.14+59~bpo70+1) can be a good thing
> > and very reliable? I plain to use new versions also in production ASAP
> > (if I can solve theoccasional network crash on windows I have with
> > gplpv and hope to solve with these drivers), with the agent lite of
> > these drivers should finally solves also the post-restore problem of
> > time(and users unable to login) with the windows domUs in a domain.
> > Now I'll do a fast test with kernel for backports to solves if solves
> > the problem.
> >
> > Thanks for any reply and sorry for my bad english.
> 
> I tried the kernel from backports and solves the network and very long
> boot time problem.
> The xen agent lite problem still persist instead, on my latest test on
> windows 7 show xenlite service running but xl shutdown and update time
> on restore are still not working :(
> I not saw an agent error in windows events log but I saw this error:
> the BIOS ACPI not contains a IRQ for the device in PCI slot 6 function 0
> With hwinfo I saw that is realtek emulated network card, is it correctly
> since pv driver is in use?
> 

Can you send the qemu log again? If you are still seeing the realtek device in 
the guest it suggests your PV frontend is still not installed correctly.

I think there's a compatibility problem. What happens if you simply 
xenstore_write "halt" into control/shutdown. (xl appears to write "poweroff" 
instead).

  Paul

> Thanks for any reply.
> 
> >
> >>
> >>> Another thing: I tried also xl shutdown and not works, xeniface is
> >>> installed (with dpinst) and liteagent is present windows folder after
> >>> it, I must do other thing to have it working?
> >> No, it should be working. Xeniface seems have started ok, so I don't
> >> know why that's not working.
> >>
> >>    Paul
> >


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