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 13:49
> To: Paul Durrant
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx; Ben Chalmers
> Subject: Re: New windows pv drivers question
> 
> Il 25/09/2014 13:38, Paul Durrant ha scritto:
> >> -----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.
> 
> Log in attachment.
> The windows device management still show realtek even if is not used
> (show error 12 - resources conflict on it), xen pv network device
> instead now is showed ok and is working.
> 

Hmm. That looks like a bug has crept in. In the log I can see:

xen_platform_log xen platform: XENFILT|PdoCreate: FFFFFA80016F85D0 
(PCI\VEN_10EC&DEV_8139&SUBSYS_11001AF4&REV_20\30)

(which is the realtek device). The unplug then happens later but the device has 
already been exposed to the Windows PnP subsystem - the unplug needs to come 
earlier. I suspect this may have broken things...

commit cba6dad2df306885dfc65908f14ce6e2d8a86211
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Fri Sep 5 17:58:51 2014 +0100

    Update active device's instance id at point of PDO filter creation

    It's tidier to have xenfilt simply return its own versions of device and
    instance id when it intercepts IRP_MN_QUERY_ID. The override of the instance
    id can be done and logged once when the PDO filter device object is created.
    This patch does that, and also replaces the rather vacuuous Name field in
    the filter device object extensions with DeviceID and InstanceID fields.

    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

I'll have a look and see what needs fixing.

> >
> > I think there's a compatibility problem. What happens if you simply
> xenstore_write "halt" into control/shutdown. (xl appears to write
> "poweroff" instead).
> 
> Here I not understand if is something I must try and post the result or
> you already found the exacly problem.
> 

I was suggesting a workaround for you. I know what the problem is; I'll submit 
a patch shortly.

  Paul

> Thanks for any reply.

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