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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

> 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