|
Il 30/03/2015 10:56, Paul Durrant ha
scritto:
Thanks for the notes.
Perhaps worth a blog entry?
Paul
Which
blog you mean?
If
you mean the Xen blog is perhaps useful to inform all on the state
of winpv drivers with all the notes about them for anyone want to help in testing and/or development.
But in that case I think other and all possibible informations
should be added, my notes is short for now and probably my english
is bad.
Il 24/03/2015 16:07, Paul Durrant ha
scritto:
Sounds
like your VM is missing something pretty vital then
unfortunately.
Paul
I probably found a solution, I did some tests
successfull.
Here a readme with some notes about new winpv drivers
based on my tests:
http://fantu.info/xen/Notes_new_xen_winpv_drivers.7z
Probably can be useful for other users that wants tests
new winpv drivers, I think that anyone can improve it
and in future probably can be also added to wiki.
About regression reported some days ago seems solved
with latest build and I not found other
critical/important bugs for now, thanks.
Il 24/03/2015 15:41, Paul Durrant
ha scritto:
No,
that looks ok. You should not need to do anything
magic to re-enable the emulated IDE; the driver
should already be there. Can you boot up in safe
mode?
Paul
I tried also safe mode but was still unable to start.
Il 24/03/2015
12:00, Paul Durrant ha scritto:
Thanks
for the logs. The processor-group-awareness patch
did introduce a couple of problems in to XENVIF. I
just posted a couple of patches that should
hopefully fix these. I’ll apply them later if
no-one shouts so there should be a new build by
the end of the day.
Paul
Thanks.
Meanwhile I tried to do a batch for remove pv
drivers things that remain after uninstall all from
control panel.
Instead remove the registry keys about services I
removed them with sc command that also delete registry
keys and the files about but after reboot I had always
blue screen with 7B without nothing in logs, no
minidump and also with xen_platform_pci=0
I did the following commands:
net stop xenlite
sc delete xenlite
DEL /q "%SystemRoot%\system32\liteagent.exe"
sc delete xeniface
DEL /q "%SystemRoot%\system32\drivers\xeniface.sys"
sc delete xendisk
DEL /q "%SystemRoot%\system32\drivers\xendisk.sys"
sc delete xennet
DEL /q "%SystemRoot%\system32\drivers\xennet.sys"
sc delete xenvbd
DEL /q "%SystemRoot%\system32\drivers\xenvbd.sys"
sc delete XENVIF
DEL /q "%SystemRoot%\system32\drivers\xenvif.sys"
sc delete XENFILT
DEL /q "%SystemRoot%\system32\drivers\xenfilt.sys"
sc delete XENBUS
DEL /q "%SystemRoot%\system32\drivers\xenbus.sys"
I did something wrong or missed?
Is needed to add/change registry key about disk
controller standard to have emulated qemu controller
working?
I remember something similar with xp changing disk
controller but I not found exact reg key to add in
windows 7 about with a fast search.
Thanks for any reply.
Il
20/03/2015 11:22, Paul Durrant ha scritto:
Sorry
for the delay, I missed this…
It’s
fairly easy… The service keys are named the same
as the driver, so go look in
HKLM/CurrentControlSet/Services and find all the
things starting with XEN and then either get rid
of them or set the StartType value to 4
(disabled).
Paul
Thanks for reply, I'll try to do a bat script for
remove all files and registry keys of pv drivers
and I'll post it for help also other people having
problems about.
Today after updating pv drivers to latest build I
had blue screen after reboot windows, seems about
xenvif.
In attachments qemu log and crash minidump.
Thanks for any reply and sorry for my bad english.
Il 16/03/2015
18:40, Paul Durrant ha scritto:
Hi,
Windows driver removal is a black art
and is broken in different ways on different
versions of Windows. As you correctly observe,
using the pnputil tool does not actually
remove the drivers, and hence you’ll see
DllInitialize() and DriverEntry() functions
called *but*
there should be no AddDevice() called i.e. the
drivers are unbound from the devices but the
modules are still present.
If you also want to stop the driver
modules from loading then you need to remove
the service keys from the registry, which you
should be able to safely do after the reboot.
If you just remove the binaries from system32
then you may well end up in a situation where
the registry is telling the system to load a
driver but, when it looks, the binary has
gone.
Paul
Can you tell me which ones registry keys I must
delete with the manually remove of remaining pv
drivers in system32 without cause problems
please?
Il 11/03/2015
16:47, Paul Durrant ha scritto:
Have
a look in
C:\Windows\System32\DriverStore\FileRepository.
If you still have packages for old drivers
in here then Windows can find them and
re-install them even if you think you’ve
uninstalled. The correct way to remove
packages is using ‘pnputil –d’ but it’s a
bit clunky.
Paul
I removed all pv drivers visible in windows
control panel, after I removed with "pnputil
-f -d" all remaining drivers found with
"pnputil /e" and rebooted.
Now still load latest xenbus (visible from
qemu log) and network is not available even if
.../FileRepository folder don't have other
xen's drivers.
I tried a search and I found there are still
all pv drivers files in C:\windows\system32
and C:\windows\system32\drivers
I removed also these files and rebooted and
now didn't load pv drivers, emulated network
is working and seems ok.
Previous week tests instead gave me windows
blue screen "registry error" 1 minute after
windows boot.
Is there another way to clean uninstall all
drivers without risk of problems?
Thanks for any reply and sorry for my bad
english.
Il 11/03/2015
16:22, Paul Durrant ha scritto:
Have
you tried uninstalling all versions of
XENVIF and XENNET and then re-installing
the latest? Windows should always prefer
the newest driver by date but maybe
something has gone wrong and for some
reason is favouring a really old version
you have lying around in DriverStore.
Yes, I already uninstalled all old drivers
build of all component 3 tests ago, rebooted
windows and after installed the new build
but seems olders xenvif and xennet still
remained even if not visible in control
center and always on new xenvif and xennet
install give me "ready to use" instead of
"device updated" message at end.
The only other way I know to delete the
drivers is search the files in
c:/windows/... but I tried time ago with
other things gave me always blue screen on
next boot, so I not tried with pv.
The
RangeSetPop error is not anything to worry
about. It is expected. It simply means the
grant table has run out of space and needs
to be expanded, which is why you see the
error immediately followed by a map and
populate of the next grant table page.
Paul
As
I reported time ago there was strange
thing when update network components: give
"ready to use" instead of "device updated"
message at end of driver component
install.
Today I saw in qemu log of one W7 pro 64
bit domU this:
xen_platform_log xen platform:
XENVIF|DriverEntry: XENVIF 8.0.0 (0)
(24.09.2014)
xen_platform_log xen platform:
XENNET|DriverEntry: XENNET 8.0.0 (0)
(24.09.2014)
Is probably the first build I installed in
this domU and that I already uninstall
from control center time ago.
other components instead seems loaded
correctly the latest build installed:
xen_platform_log xen platform:
XEN|DllInitialize: XEN 8.0.0 (41)
(05.03.2015)
xen_platform_log xen platform:
XENFILT|DriverEntry: XENFILT 8.0.0 (41)
(05.03.2015)
xen_platform_log xen platform:
XENDISK|DriverEntry:XENDISK 8.0.0 (18)
(03.03.2015)
xen_platform_log xen platform:
XENIFACE|DriverEntry: 8.0.0.13 (2/3/2015)
----------
I saw also these errors in qemu log:
...
xen_platform_log
xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[1] @
00000000.f8002000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000200 - 000003ff]
xen_platform_log
xen platform: XENBUS|RangeSetPop:
fail1 (c000009a)
xen_platform_log xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[2] @
00000000.f8003000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000400 - 000005ff]
xen_platform_log xen platform:
XENBUS|RangeSetPop: fail1 (c000009a)
xen_platform_log xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[3] @
00000000.f8004000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000600 - 000007ff]
xen_platform_log xen platform:
XENBUS|RangeSetPop: fail1 (c000009a)
xen_platform_log xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[4] @
00000000.f8005000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000800 - 000009ff]
xen_platform_log xen platform:
XENBUS|RangeSetPop: fail1 (c000009a)
xen_platform_log xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[5] @
00000000.f8006000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000a00 - 00000bff]
xen_platform_log xen platform:
XENBUS|RangeSetPop: fail1 (c000009a)
xen_platform_log xen platform: GNTTAB: MAP
XENMAPSPACE_grant_table[6] @
00000000.f8007000
xen_platform_log xen platform:
XENBUS|GnttabExpand: added references
[00000c00 - 00000dff]
...
Can someone tell me something about?
Can they be related to some failed memory
balloning error in dom0's kern.log and
syslog?
Full qemu log in attachment is needed.
If you need more informations and/or tests
tell me and I'll post them.
Thanks for any reply and sorry for my bad
english.
|
