Xen users - Jun 2008 - Unable to remove GPLPV drivers without breaking win2k3 domU

I have a Win2K3 domU (and thankfully an image backup of the LVM volume 
that holds its system disk) I previously installed GPLPV v0.8.9 drivers, 
the domU boots OK with or without the /GPLPV switch in boot.ini, however 
with the /GPLPV switch it tries and fails to use the Xen network driver, 
and so the machine is network-less, so for the past few months I''ve
left
it using pure HVM instead of PV drivers.

Now I''d like to try the 0.9.11-pre4 drivers

attempt 1 - installed new drivers over the top of the old ones, got 
bluescreen at next boot.

attempt 2 - restored disk and used the un-install.bat from the old 
version, still bluescreen at next boot.

attempt 3 - manually uninstalled all xen devices from within device 
manager, deleted all relevant .inf/.pnf/.sys files, it still 
bluescreens, I think it''s a STOP 0x0000007B

Any more suggestions on how to remove the old drivers and keep it 
bootable, ready to try the newer version?


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, 2008-06-30 at 15:16 +0100, Andy Burns wrote:
> I have a Win2K3 domU (and thankfully an image backup of the LVM volume 
> that holds its system disk) I previously installed GPLPV v0.8.9 drivers, 
> the domU boots OK with or without the /GPLPV switch in boot.ini, however 
> with the /GPLPV switch it tries and fails to use the Xen network driver, 
> and so the machine is network-less, so for the past few months
I''ve left
> it using pure HVM instead of PV drivers.
> 
> Now I''d like to try the 0.9.11-pre4 drivers
> 
> attempt 1 - installed new drivers over the top of the old ones, got 
> bluescreen at next boot.
> 
> attempt 2 - restored disk and used the un-install.bat from the old 
> version, still bluescreen at next boot.
> 
> attempt 3 - manually uninstalled all xen devices from within device 
> manager, deleted all relevant .inf/.pnf/.sys files, it still 
> bluescreens, I think it''s a STOP 0x0000007B
> 
> Any more suggestions on how to remove the old drivers and keep it 
> bootable, ready to try the newer version?

I''m in the same boat. I have an older version installed on several
systems, 0.8.8, that''s I''d really like to update to see if it
fixes some
problems I''m having. I''m also unable to remove them without
blowing up
the system. I created a thread on Friday afternoon. No responses yet.
Please let me know if you make any progress.

Thanks,
James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30/06/2008 15:33, James Pifer wrote:
> I''m in the same boat. 
Sorry I missed your message, otherwise I wouldn''t have started a new
thread.
> I have an older version installed on several
> systems, 0.8.8, that''s I''d really like to update to see
if it fixes some
> problems I''m having. I''m also unable to remove them
without blowing up
> the system. 
I just booted my domU from an .iso of the Win2K3 CD and pressed "R" to
start the recovery console and disabled all the Xen drivers and services.

Unfortunately just doing that was enough to blue screen it on the next 
HVM boot.

I''ve also noticed that booting into PV mode is enough to trigger
Windows
into wanting a re-activation due to seeing "significant" hardware
changes.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30/06/2008 16:37, Andy Burns wrote:
> I just booted my domU from an .iso of the Win2K3 CD and pressed
"R" to
> start the recovery console and disabled all the Xen drivers and services.
> 
> Unfortunately just doing that was enough to blue screen it on the next 
> HVM boot.
I think I''m getting somewhere, after the previous attempt at disabling 
all GPLPV drivers and services, I re-enabled *just* the XenHide device, 
and it booted.

I cleaned out registry entries (a bit of care required as some Xen 
entries come from QEMU not from GPLPV) also some registry permissions 
needed changing to allow deletion.

Then I changed the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI_HAL\PNP0C08\0\Control\ActiveService
back to its default value of "ACPI"

Then deleted the .inf/.pnf/.sys files which related to gplpv

Rebooted and no blue screen :-)

Then I installed the 9.11-pre4 version, seemed to get a lot of pop-up 
warnings, and eventually the xen devices showed up with yellow bangs (at 
the same as the qemu devices)

I''m just about to reboot with /GPLPV flag and hopefully the yellow
bangs
will disappear ...


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30/06/2008 19:04, Andy Burns wrote:
> Then I installed the 9.11-pre4 version, seemed to get a lot of pop-up 
> warnings, and eventually the xen devices showed up with yellow bangs (at 
> the same as the qemu devices)
No dice!

When rebooting with /GPLPV it hung at the "grey" 2003 GUI boot screen,
I
tried it again with /GPLPV /SOS /NOGUIBOOT and then it did bluescreen, 
it also bluescreens without /GPLPV









_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, 2008-06-30 at 19:27 +0100, Andy Burns wrote:
> On 30/06/2008 19:04, Andy Burns wrote:
> 
> > Then I installed the 9.11-pre4 version, seemed to get a lot of pop-up 
> > warnings, and eventually the xen devices showed up with yellow bangs
(at
> > the same as the qemu devices)
> 
> No dice!
> 
> When rebooting with /GPLPV it hung at the "grey" 2003 GUI boot
screen, I
> tried it again with /GPLPV /SOS /NOGUIBOOT and then it did bluescreen, 
> it also bluescreens without /GPLPV
DANG! 

In my case I have 0.8.8 loaded, but I''m not even loading /gplpv. I
originally loaded it to get rid of the unknown PCI device, which it
did. 

I have not had time to work on mine today. 

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30/06/2008 19:52, James Pifer wrote:
> DANG! 
> 
> In my case I have 0.8.8 loaded, but I''m not even loading /gplpv. I
> originally loaded it to get rid of the unknown PCI device, which it
> did. 
OK, I tried again and got it working with 0.9.10 instead of 0.9.11-pre4 
(though the version might not be significant)

I was a bit more fussy about what registry settings I kept and removed 
this time, also I think I didn''t wait at the "grey progress
screen" for
long enough last time, it sticks there for what feels like two or three 
minutes.

So to summarise what I did ...

1) ensure domU will boot without /GPLPV

2) reboot into recovery console from windows CD (or ISO)

3) disable all xen services/drivers *except* xenhide

4) boot into windows, without /GPLPV

5) If any "hardware detected" dialogs are raised, cancel them, do not 
allow any xen drivers/services to be re-installed.

6) Start regedit

Alter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI_HAL\PNP0C08\0\Control\ActiveService
from
"XenHide" to "ACPI"

Search the whole registry for "xen" and set permissions/remove
keys/values

Don''t remove anything under HKLM/HARDWARE/ACPI

Do remove all the UpperFilter/LowerFilter values

Beware of false matches such as "xenroll"
"IVBSAXEntityResolver"

Check where currentcontrolset points to, so you know which 
controlset01/02 etc to ignore and which to process.

7) reboot without /GPLPV

8) If any "hardware detected" dialogs are raised, cancel them, do not 
allow any xen drivers/services to be re-installed.

9) Within C:\windows delete xen*.sys and cached DIFx copies in 
DRIVERSTORE folders

10 delete all oem*.?nf files which are related to gplpv

11) reboot without /GPLPV

at this point the machine should be "clean" of the old xen drivers, if
you''re using LVM you might like to snapshot it at this point.

I then installed the 0.9.10 drivers from the .exe and accepted all 
"unsigned driver" prompts, in device manager you should see the PV 
devices (with yellow bangs) as well as the QEMU devices

12) reboot *with* /GPLPV

Be patient at the grey screen ;-)

Hopefully your machine will boot and now the QEMU devices will have 
yellow bangs and the Xen PV devices will not!

I did a quick iometer test with 100% sequental 64Kb reads and got about 
37MB/s a PV linux domU on the same hardware gets about twice that, I''ll
do some more perf testing soon.

Good luck.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, 2008-07-01 at 00:10 +0100, Andy Burns wrote:
> On 30/06/2008 19:52, James Pifer wrote:
> 
> > DANG! 
> > 
> > In my case I have 0.8.8 loaded, but I''m not even loading
/gplpv. I
> > originally loaded it to get rid of the unknown PCI device, which it
> > did. 
> 
> OK, I tried again and got it working with 0.9.10 instead of 0.9.11-pre4 
> (though the version might not be significant)
> 
> I was a bit more fussy about what registry settings I kept and removed 
> this time, also I think I didn''t wait at the "grey progress
screen" for
> long enough last time, it sticks there for what feels like two or three 
> minutes.
> 
> So to summarise what I did ...
> 
> 1) ensure domU will boot without /GPLPV
> 
> 2) reboot into recovery console from windows CD (or ISO)
> 
> 3) disable all xen services/drivers *except* xenhide
> 
> 4) boot into windows, without /GPLPV
> 
> 5) If any "hardware detected" dialogs are raised, cancel them, do
not
> allow any xen drivers/services to be re-installed.
> 
> 6) Start regedit
> 
> Alter
>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI_HAL\PNP0C08\0\Control\ActiveService
> from
> "XenHide" to "ACPI"
> 
> Search the whole registry for "xen" and set permissions/remove
keys/values
> 
> Don''t remove anything under HKLM/HARDWARE/ACPI
> 
> Do remove all the UpperFilter/LowerFilter values
> 
> Beware of false matches such as "xenroll"
"IVBSAXEntityResolver"
> 
> Check where currentcontrolset points to, so you know which 
> controlset01/02 etc to ignore and which to process.
> 
> 7) reboot without /GPLPV
> 
> 8) If any "hardware detected" dialogs are raised, cancel them, do
not
> allow any xen drivers/services to be re-installed.
> 
> 9) Within C:\windows delete xen*.sys and cached DIFx copies in 
> DRIVERSTORE folders
> 
> 10 delete all oem*.?nf files which are related to gplpv
> 
> 11) reboot without /GPLPV
> 
> at this point the machine should be "clean" of the old xen
drivers, if
> you''re using LVM you might like to snapshot it at this point.
> 
> I then installed the 0.9.10 drivers from the .exe and accepted all 
> "unsigned driver" prompts, in device manager you should see the
PV
> devices (with yellow bangs) as well as the QEMU devices
> 
> 12) reboot *with* /GPLPV
> 
> Be patient at the grey screen ;-)
> 
> Hopefully your machine will boot and now the QEMU devices will have 
> yellow bangs and the Xen PV devices will not!
> 
> I did a quick iometer test with 100% sequental 64Kb reads and got about 
> 37MB/s a PV linux domU on the same hardware gets about twice that,
I''ll
> do some more perf testing soon.
> 
> Good luck.
> 
I''ll give this another shot. Most of current machines are running in
sparse image files, not as LVMs, so before I do any of this I''m making
a
sparse copy first. 

I''m also trying to install a fresh copy of win2k3 for a couple reasons.
One is to install later xen pv drivers, but also to get multiple CPUs.
My current win2k3 image refuses to recognize more than one. I don''t
know
if that''s a xen problem or my image problem. Supposedly win2k3
automatically adjusts the hal.  

Frustrating though, I can''t even get win2k3 to install right now! 

Thanks for the detailed removal instructions!

James



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> 
> attempt 1 - installed new drivers over the top of the old ones, got
> bluescreen at next boot.
> 
> attempt 2 - restored disk and used the un-install.bat from the old
> version, still bluescreen at next boot.
> 
> attempt 3 - manually uninstalled all xen devices from within device
> manager, deleted all relevant .inf/.pnf/.sys files, it still
> bluescreens, I think it''s a STOP 0x0000007B
> 
> Any more suggestions on how to remove the old drivers and keep it
> bootable, ready to try the newer version?
> 
I have documented this on the wiki -
http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing

It''s probably the upper and lower filter entries in the registries that
are biting you - if xenhide.sys is an upper or lower filter anywhere (eg
on the pci bus) then that driver won''t load (because you deleted it),
and obviously if the pci bus doesn''t get loaded then nothing good is
going to happen.

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> On 30/06/2008 19:52, James Pifer wrote:
> 
> > DANG!
> >
> > In my case I have 0.8.8 loaded, but I''m not even loading
/gplpv. I
> > originally loaded it to get rid of the unknown PCI device, which it
> > did.
> 
> OK, I tried again and got it working with 0.9.10 instead of
0.9.11-pre4
> (though the version might not be significant)
> 
> I was a bit more fussy about what registry settings I kept and removed
> this time, also I think I didn''t wait at the "grey progress
screen"
for
> long enough last time, it sticks there for what feels like two or
three
> minutes.
> 
> So to summarise what I did ...
> 
> 1) ensure domU will boot without /GPLPV
> 
> 2) reboot into recovery console from windows CD (or ISO)
> 
> 3) disable all xen services/drivers *except* xenhide
> 
> 4) boot into windows, without /GPLPV
> 
> 5) If any "hardware detected" dialogs are raised, cancel them, do
not
> allow any xen drivers/services to be re-installed.
> 
> 6) Start regedit
> 
> Alter
>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI_HAL\PNP0C08\0\Cont
ro
> l\ActiveService
> from
> "XenHide" to "ACPI"
> 
> Search the whole registry for "xen" and set permissions/remove
keys/values
> 
> Don''t remove anything under HKLM/HARDWARE/ACPI
> 
> Do remove all the UpperFilter/LowerFilter values
> 
> Beware of false matches such as "xenroll"
"IVBSAXEntityResolver"
> 
> Check where currentcontrolset points to, so you know which
> controlset01/02 etc to ignore and which to process.
> 
> 7) reboot without /GPLPV
> 
> 8) If any "hardware detected" dialogs are raised, cancel them, do
not
> allow any xen drivers/services to be re-installed.
> 
> 9) Within C:\windows delete xen*.sys and cached DIFx copies in
> DRIVERSTORE folders
> 
> 10 delete all oem*.?nf files which are related to gplpv
> 
> 11) reboot without /GPLPV
> 
> at this point the machine should be "clean" of the old xen
drivers, if
> you''re using LVM you might like to snapshot it at this point.
> 
> I then installed the 0.9.10 drivers from the .exe and accepted all
> "unsigned driver" prompts, in device manager you should see the
PV
> devices (with yellow bangs) as well as the QEMU devices
> 
> 12) reboot *with* /GPLPV
> 
> Be patient at the grey screen ;-)
> 
> Hopefully your machine will boot and now the QEMU devices will have
> yellow bangs and the Xen PV devices will not!
> 
> I did a quick iometer test with 100% sequental 64Kb reads and got
about
> 37MB/s a PV linux domU on the same hardware gets about twice that,
I''ll
> do some more perf testing soon.
> 
> Good luck.
> 
I didn''t notice this when I just replied. Feel like updating the wiki?

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 01/07/2008 03:59, James Harper wrote:
> I didn''t notice this when I just replied. Feel like updating the
wiki?
Done.

Is the long delay at the "gray screen" to be expected? could any of
the
gplpv drivers output a message to warn about it? (I use /SOS and 
/NOGUIBOOT to watch what''s going on)

I have now upgraded to 0.9.11-pre4, my filesystems are not corrupted :-)

As expected the QEMU devices *are* hidden when the PV devices are 
active, but not vice-versa.

The instructions don''t mention the need to boot into non /GPLPV mode
for
the upgrade, I certainly had to.

I found the XenShutdownMon service would not stop (in response to the 
installer, or by me manually stopping it) so I had to set it to manual, 
then reboot, then do the upgrade, then set it back to auto before the 
reboot.

Disk performance seems improved, especially with larger transfer block 
sizes, I''m seeing up to 50MB/s on either reads or writes, but if I do 
mixed reads *and* writes the performance is really killed, ie. 5MB/s

Thanks for your efforts on these drivers.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> On 01/07/2008 03:59, James Harper wrote:
> 
> > I didn''t notice this when I just replied. Feel like updating
the
wiki?
> 
> Done.
Thanks for that.
> 
> Is the long delay at the "gray screen" to be expected? could any
of
the
> gplpv drivers output a message to warn about it? (I use /SOS and
> /NOGUIBOOT to watch what''s going on)
I think I did fix a delay (up to 30 or 60 seconds?) in the current hg
sources. I''ll probably do a release sometime in the next few days as I
have save/restore working, although it''s not well tested yet.
> I have now upgraded to 0.9.11-pre4, my filesystems are not corrupted
:-)

w00t!
> As expected the QEMU devices *are* hidden when the PV devices are
> active, but not vice-versa.
> 
> The instructions don''t mention the need to boot into non /GPLPV
mode
for
> the upgrade, I certainly had to.
With your upgrade from 0.8.x to 0.9.x you certainly need to take every
precaution. Upgrades from now on should be a bit less painless though.
> I found the XenShutdownMon service would not stop (in response to the
> installer, or by me manually stopping it) so I had to set it to
manual,
> then reboot, then do the upgrade, then set it back to auto before the
> reboot.
You can just go into task manager and kill the shutdownmon process. For
some reason stopping the service doesn''t stop the process...

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 01/07/2008 12:06, James Harper wrote:
> I think I did fix a delay (up to 30 or 60 seconds?) 
I''ll watch out for 0.9.11 proper, The delay I see was long enough to 
convince me it had hung.
> With your upgrade from 0.8.x to 0.9.x you certainly need to take every
> precaution. Upgrades from now on should be a bit less painless though.
I understand it was a bit knife&fork to upgrade from 0.8.x to 0.9.x
but I meant I had to switch to non /GPLPV mode for the 0.9.10 to 
0.9.11-pre4 upgrade.
> You can just go into task manager and kill the shutdownmon process. For
> some reason stopping the service doesn''t stop the process...
OK


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> 
> > With your upgrade from 0.8.x to 0.9.x you certainly need to take
every
> > precaution. Upgrades from now on should be a bit less painless
though.
> 
> I understand it was a bit knife&fork to upgrade from 0.8.x to 0.9.x
> but I meant I had to switch to non /GPLPV mode for the 0.9.10 to
> 0.9.11-pre4 upgrade.
> 
Because of the warning, or because it didn''t work?

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 01/07/2008 13:21, James Harper wrote:
> Because of the warning, or because it didn''t work?
The installer ran, but none of the .sys files were updated to 0.9.10.4 
versions, I hadn''t imported your code-signing certificate at that
stage,
I only did that when I tried again in non /GPLPV mode, that time the 
upgrade worked.




_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Hopefully your machine will boot and now the QEMU devices will have 
> yellow bangs and the Xen PV devices will not!
> 
> I did a quick iometer test with 100% sequental 64Kb reads and got about 
> 37MB/s a PV linux domU on the same hardware gets about twice that,
I''ll
> do some more perf testing soon.
> 
> Good luck.
> 
Andy, 

After doing all this, do you end up with anything in Device Manager
showing up with yellow bangs?

Both of these show up as yellow bangs for me now:
Intel(R) 82371SB PCI Bus Master IDE Controller
Realtek RTL8139 Family PCI Fast Ethernet NIC

I do have the Xen net Device Driver, so networking works. 

Thanks,
James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, 2008-07-01 at 11:36 -0400, James Pifer wrote:
> > Hopefully your machine will boot and now the QEMU devices will have 
> > yellow bangs and the Xen PV devices will not!
> > 
> > I did a quick iometer test with 100% sequental 64Kb reads and got
about
> > 37MB/s a PV linux domU on the same hardware gets about twice that,
I''ll
> > do some more perf testing soon.
> > 
> > Good luck.
> > 
> 
> Andy, 
> 
> After doing all this, do you end up with anything in Device Manager
> showing up with yellow bangs?
> 
> Both of these show up as yellow bangs for me now:
> Intel(R) 82371SB PCI Bus Master IDE Controller
> Realtek RTL8139 Family PCI Fast Ethernet NIC
> 
> I do have the Xen net Device Driver, so networking works. 
> 
Sorry, just re-read your message. I assume those are the QEMU devices
that you mentioned!

Thanks,
James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 01/07/2008 16:36, James Pifer wrote:
> After doing all this, do you end up with anything in Device Manager
> showing up with yellow bangs?
> 
> Both of these show up as yellow bangs for me now:
> Intel(R) 82371SB PCI Bus Master IDE Controller
> Realtek RTL8139 Family PCI Fast Ethernet NIC
I think if you''re on 0.9.10 it is intended that the QEMU devices will
be
  visible rather than hidden by xenhide, but will show the yellow bangs 
so the device isn''t accessed by both drivers.

I''ve now upgraded to 0.9.11-pre4 and the xenhide does hide the QEMU 
devices, so evrything looks "clean" in device manager, all hard 
drive/cdrom/nic ar handled by PV drivers and console/fb/kbd are just 
stub devices, but no yellow bangs or question marks.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> On 01/07/2008 13:21, James Harper wrote:
> 
> > Because of the warning, or because it didn''t work?
> 
> The installer ran, but none of the .sys files were updated to 0.9.10.4
> versions, I hadn''t imported your code-signing certificate at that
stage,
> I only did that when I tried again in non /GPLPV mode, that time the
> upgrade worked.
> 
Hmmm... Windows favours signed drivers over unsigned drivers, even if
the unsigned drivers are a later version. /GPLPV shouldn''t have changed
the outcome of that though.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users