Yes, the
XenProject blog was what I was thinking of. It would be good to have your perspective on working with the drivers. I’m sure myself, Lars or Russ can help with correcting English.
Paul
From:
Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: 30 March 2015 10:59
To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [win-pv-devel] xenvif xennet don't update or load correctly and another error saw in qemu log
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.
|
