[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] 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.

Thanks for any reply and sorry for my bad english.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.