Xen users - Feb 2008 - The real 0.6.5 release of Windows PV drivers

The last release was actually 0.6.4, and contained a bug which meant
that under Xen 3.2.0 the PCI IDE device wasn''t detected and disabled
(the PCI ID presented by Qemu had changed). This could result in bad
things happening to your windows filesystem (it did for me just now when
I didn''t get this fix quite right :).

This new release should fix that problem.

http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip

James

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

James Harper schrieb:
> The last release was actually 0.6.4, and contained a bug which meant
> that under Xen 3.2.0 the PCI IDE device wasn''t detected and
disabled
> (the PCI ID presented by Qemu had changed). This could result in bad
> things happening to your windows filesystem (it did for me just now when
> I didn''t get this fix quite right :).
While I encountered dangerous sounding messages at boot time, I could always
fix this by starting the Recovery Console from CD running chkdsk.

> This new release should fix that problem.
> 
> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054



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

On Sunday 03 February 2008 07:09:44 am James Harper
wrote:
> This new release should fix that problem.
>
> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
What''s the recommended update procedure? Every time I go into Device
Manager
and update one of your devices, my hvm''s network disappears for 5-10
min.
Would it be easier to just copy over the files in c:\windows\system32 and 
system32\drivers?

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

jim burns schrieb:
> On Sunday 03 February 2008 07:09:44 am James Harper wrote:
>> This new release should fix that problem.
>>
>> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
> 
> What''s the recommended update procedure? Every time I go into
Device Manager
> and update one of your devices, my hvm''s network disappears for
5-10 min.
> Would it be easier to just copy over the files in c:\windows\system32 and 
> system32\drivers?
I don''t know if this is the recommended update procedure, but I did the
same
as mentioned in the INSTALL.txt and get selections with version labelled 0.6.3
and 0.6.4.
Interestingly, after a second try this doesn''t shows 0.6.5, only 0.6.3
and 0.6.4.

Using (probably?) 0.6.5 my qemu disks doesn''t disappear (as in 0.6.4).
Only the "SCSI Device"
disappears when using /gplpv.
Network is working well.
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054



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

On Sunday 03 February 2008 07:09:44 am James Harper
wrote:
> This new release should fix that problem.
>
> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
Ok, installed 0.6.5. You''re getting closer. Booting with /gplpv
doesn''t result
in a BSOD anymore. The disk drives correctly report the Xen PV drivers in 
charge, and only one network adapter, also controlled by Xen PV. Doing my 
crude uncached large file copy benches, an intra domu copy took 10 secs, and 
a different file copied from domu to dom0 took 31.

Booting w/o /gplpv, the disk driver is indeed QEMU. However, I''m still
getting
two network adapters, the original Realtek, and the new Xen PV. The former 
has to be disabled  since they use the same mac address. Doing my crude 
uncached large file copy benches with the same 2 files, intra domu took 7 
secs, and domu to dom0 resulted in the BSOD shown below (the same one I got 
with my previous attempt at a file copy domu -> dom0 under 0.6.3). This same 
domu to dom0 copy prior to installing any version of your drivers took 23 
secs. So 7 secs vs. 10, and 23 vs. 31 - still slower w/ /gplpv.

*** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)

(ps - Further testing has resulted in a couple of BSODs on domu to dom0 xfers 
having booted *with* /gplpv, so it may be more related to xennet than xenvbd:

"A process or thread crucial to system operation has unexpectedly exited or
been terminated.
[...]
*** STOP: 0x000000F4 (0x00000003,0x81F60840,0x81F609B4,0x805D11F8)")

Furthermore, when booting w/o /gplpv my cd works fine, at least with the cd 
the vm booted up with. Booting w/ /gplpv, clicking on CD Drive (D:) in My 
Computer yields the error:

"Windows cannot read from this disk. The disk might be corrupted, or it
could
be using a format that is not compatible with Windows."

And just to round things out, once after booting w/ /gplpv and shutting down 
from within the hvm, my dom0 rebooted! And I have occaisionally gotten the 
error message "Error: Device 0 (vif) could not be connected. Hotplug
scripts
not working." upon trying to re xm create the domain.

(pps - Great - now on my last hvm reboot chkdsk went crazy. It looks like I 
have to reinstall all my user programs.)

Repeating my config:
Intel, everything 32bit PAE
xen.gz 3.1.0-rc7
kernel 2.6.21
xen 3.1.2
Windows XP Pro 2002 SP2

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

> 
> On Sunday 03 February 2008 07:09:44 am James Harper wrote:
> > This new release should fix that problem.
> >
> > http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
> 
> Ok, installed 0.6.5. You''re getting closer. Booting with /gplpv
doesn''t
> result
> in a BSOD anymore. The disk drives correctly report the Xen PV drivers
in
> charge, and only one network adapter, also controlled by Xen PV. Doing
my
> crude uncached large file copy benches, an intra domu copy took 10
secs,
> and
> a different file copied from domu to dom0 took 31.
I''m not sure that any benchmarks under the qemu disks is going to mean
anything, as Dom0 is doing caching for them, unless this has changed in
0.3.2. Can you confirm that CPU usage is way down under the pV drivers?
> Booting w/o /gplpv, the disk driver is indeed QEMU. However, I''m
still
> getting
> two network adapters, the original Realtek, and the new Xen PV. The
former
> has to be disabled  since they use the same mac address.
Yes. I''ll discuss that with Andy (he''s the guy who wrote the
network
drivers). While we were doing heavy development, it made sense to always
enable the pv network drivers as /gplpv would disable the qemu disk
drivers. Now that things are a bit more stable, maybe we should not
enable the pv network drivers without /gplpv.

Alternatively, using a type of ''netfront'' instead of
''ioemu'' in the xen
config will not create the rtl devices.
> Doing my crude
> uncached large file copy benches with the same 2 files, intra domu
took 7
> secs, and domu to dom0 resulted in the BSOD shown below (the same one
I
> got
> with my previous attempt at a file copy domu -> dom0 under 0.6.3).
This
> same
> domu to dom0 copy prior to installing any version of your drivers took
23
> secs. So 7 secs vs. 10, and 23 vs. 31 - still slower w/ /gplpv.
> 
> *** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)
> 
That''s that ''assert'' statement again. If it happens
again, please let me
know the driver it is being reported in.
> (ps - Further testing has resulted in a couple of BSODs on domu to
dom0
> xfers
> having booted *with* /gplpv, so it may be more related to xennet than
> xenvbd:
> 
> "A process or thread crucial to system operation has unexpectedly
exited
> or
> been terminated.
> [...]
> *** STOP: 0x000000F4 (0x00000003,0x81F60840,0x81F609B4,0x805D11F8)")
Does anything useful get logged in the event log about that? Is it
possible that your windows domU got so roasted by the previous pv driver
versions that it has other problems too?
> Furthermore, when booting w/o /gplpv my cd works fine, at least with
the
> cd
> the vm booted up with. Booting w/ /gplpv, clicking on CD Drive (D:) in
My
> Computer yields the error:
> 
> "Windows cannot read from this disk. The disk might be corrupted, or
it
> could
> be using a format that is not compatible with Windows."
Can you send me the config file, or at least the line for the block
devices?
> And just to round things out, once after booting w/ /gplpv and
shutting
> down
> from within the hvm, my dom0 rebooted! And I have occaisionally gotten
the
> error message "Error: Device 0 (vif) could not be connected. Hotplug
> scripts
> not working." upon trying to re xm create the domain.
> 
> (pps - Great - now on my last hvm reboot chkdsk went crazy. It looks
like
> I
> have to reinstall all my user programs.)
> 
> Repeating my config:
> Intel, everything 32bit PAE
> xen.gz 3.1.0-rc7
> kernel 2.6.21
> xen 3.1.2
> Windows XP Pro 2002 SP2
Thanks.

James


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

FYI, I''m using "netfront" in the config file and gave a
different MAC
address for it. That solved all my problems. I''m happy with the fact
that
xennet works even without /gplpv

Emre

On Feb 3, 2008 11:31 PM, James Harper <james.harper@bendigoit.com.au>
wrote:
> >
> > On Sunday 03 February 2008 07:09:44 am James Harper wrote:
> > > This new release should fix that problem.
> > >
> > > http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
> >
> > Ok, installed 0.6.5. You''re getting closer. Booting with
/gplpv
> doesn''t
> > result
> > in a BSOD anymore. The disk drives correctly report the Xen PV drivers
> in
> > charge, and only one network adapter, also controlled by Xen PV. Doing
> my
> > crude uncached large file copy benches, an intra domu copy took 10
> secs,
> > and
> > a different file copied from domu to dom0 took 31.
>
> I''m not sure that any benchmarks under the qemu disks is going to
mean
> anything, as Dom0 is doing caching for them, unless this has changed in
> 0.3.2. Can you confirm that CPU usage is way down under the pV drivers?
>
> > Booting w/o /gplpv, the disk driver is indeed QEMU. However,
I''m still
> > getting
> > two network adapters, the original Realtek, and the new Xen PV. The
> former
> > has to be disabled  since they use the same mac address.
>
> Yes. I''ll discuss that with Andy (he''s the guy who wrote
the network
> drivers). While we were doing heavy development, it made sense to always
> enable the pv network drivers as /gplpv would disable the qemu disk
> drivers. Now that things are a bit more stable, maybe we should not
> enable the pv network drivers without /gplpv.
>
> Alternatively, using a type of ''netfront'' instead of
''ioemu'' in the xen
> config will not create the rtl devices.
>
> > Doing my crude
> > uncached large file copy benches with the same 2 files, intra domu
> took 7
> > secs, and domu to dom0 resulted in the BSOD shown below (the same one
> I
> > got
> > with my previous attempt at a file copy domu -> dom0 under 0.6.3).
> This
> > same
> > domu to dom0 copy prior to installing any version of your drivers took
> 23
> > secs. So 7 secs vs. 10, and 23 vs. 31 - still slower w/ /gplpv.
> >
> > *** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)
> >
>
> That''s that ''assert'' statement again. If it
happens again, please let me
> know the driver it is being reported in.
>
> > (ps - Further testing has resulted in a couple of BSODs on domu to
> dom0
> > xfers
> > having booted *with* /gplpv, so it may be more related to xennet than
> > xenvbd:
> >
> > "A process or thread crucial to system operation has unexpectedly
> exited
> > or
> > been terminated.
> > [...]
> > *** STOP: 0x000000F4
(0x00000003,0x81F60840,0x81F609B4,0x805D11F8)")
>
> Does anything useful get logged in the event log about that? Is it
> possible that your windows domU got so roasted by the previous pv driver
> versions that it has other problems too?
>
> > Furthermore, when booting w/o /gplpv my cd works fine, at least with
> the
> > cd
> > the vm booted up with. Booting w/ /gplpv, clicking on CD Drive (D:) in
> My
> > Computer yields the error:
> >
> > "Windows cannot read from this disk. The disk might be corrupted,
or
> it
> > could
> > be using a format that is not compatible with Windows."
>
> Can you send me the config file, or at least the line for the block
> devices?
>
> > And just to round things out, once after booting w/ /gplpv and
> shutting
> > down
> > from within the hvm, my dom0 rebooted! And I have occaisionally gotten
> the
> > error message "Error: Device 0 (vif) could not be connected.
Hotplug
> > scripts
> > not working." upon trying to re xm create the domain.
> >
> > (pps - Great - now on my last hvm reboot chkdsk went crazy. It looks
> like
> > I
> > have to reinstall all my user programs.)
> >
> > Repeating my config:
> > Intel, everything 32bit PAE
> > xen.gz 3.1.0-rc7
> > kernel 2.6.21
> > xen 3.1.2
> > Windows XP Pro 2002 SP2
>
> Thanks.
>
> James
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>


-- 
Emre Erenoglu
erenoglu@gmail.com


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

On Sunday 03 February 2008 05:41:16 pm Emre Erenoglu
wrote:
> FYI, I''m using "netfront" in the config file and gave a
different MAC
> address for it. That solved all my problems. I''m happy with the
fact that
> xennet works even without /gplpv
James mentioned something similar. Could you send me your vif= line? Thanx.

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

Jim,

Something like:

"
vif = [ "type=netfront, mac=AA:BB:CC:DD:EE:FF, bridge=xen-br0" ]
"

is what you want. This solution will most likely disable network booting
though, as the BIOS will no longer be able to see the network interface.

James
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of jim burns
> Sent: Monday, 4 February 2008 14:44
> To: xen-users@lists.xensource.com; Emre Erenoglu
> Subject: Re: [Xen-users] The real 0.6.5 release of Windows PV drivers
> 
> On Sunday 03 February 2008 05:41:16 pm Emre Erenoglu wrote:
> > FYI, I''m using "netfront" in the config file and
gave a different
MAC
> > address for it. That solved all my problems. I''m happy with
the fact
> that
> > xennet works even without /gplpv
> 
> James mentioned something similar. Could you send me your vif= line?
> Thanx.
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sunday 03 February 2008 05:31:08 pm James Harper
wrote:
> I''m not sure that any benchmarks under the qemu disks is going to
mean
> anything, as Dom0 is doing caching for them, unless this has changed in
> 0.3.2. Can you confirm that CPU usage is way down under the pV drivers?
I wouldn''t say *way* down. I mostly use my hvm for multimedia that wine
or
mplayer/xine can''t handle, and that''s a real cpu hog on an hvm
guest,
especially video.
> Does anything useful get logged in the event log about that? Is it
> possible that your windows domU got so roasted by the previous pv driver
> versions that it has other problems too?
What log file in particular? (c:\windows\...) I''ve just recovered from
a bad
chkdsk relocation of my home directory, plus some anti-virus & anti-trojan 
checker files, but that happened after I installed 0.6.5. (Which reminds me, 
you never answered whether it''s better to do an upgrade with Device
Manager,
or straight copies to c:\windows\system32\drivers?)
> Can you send me the config file, or at least the line for the block
devices?
disk=[ ''file:/var/lib/xen/images/winxp,ioemu:hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]

tap:aio: (actually tap: for hvm guests) stopped working after the upgrade from 
fc7 to fc8.

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

> On Sunday 03 February 2008 05:31:08 pm James Harper wrote:
> > I''m not sure that any benchmarks under the qemu disks is
going to
mean
> > anything, as Dom0 is doing caching for them, unless this has changed
in
> > 0.3.2. Can you confirm that CPU usage is way down under the pV
drivers?
> 
> I wouldn''t say *way* down. I mostly use my hvm for multimedia that
wine or
> mplayer/xine can''t handle, and that''s a real cpu hog on
an hvm guest,
> especially video.
Hmmm... I wonder how much acceleration we could do for a vfb driver...
> > Does anything useful get logged in the event log about that? Is it
> > possible that your windows domU got so roasted by the previous pv
driver
> > versions that it has other problems too?
> 
> What log file in particular? (c:\windows\...) I''ve just recovered
from
a
> bad
> chkdsk relocation of my home directory, plus some anti-virus &
anti-trojan
> checker files, but that happened after I installed 0.6.5.
Windows event log (eventvwr.msc)
> (Which reminds
> me,
> you never answered whether it''s better to do an upgrade with
Device
> Manager,
> or straight copies to c:\windows\system32\drivers?)
I''ve never done it by just copying files so I couldn''t say for
sure. It
should work, but I''m not sure windows can set itself up to do a
''last
known good configuration'' boot if you do it that way.
> > Can you send me the config file, or at least the line for the block
> devices?
> 
> disk=[ ''file:/var/lib/xen/images/winxp,ioemu:hda,w'',
> ''phy:/dev/cdrom,hdc:cdrom,r'' ]
I''ve never tried it with a physical cdrom, so maybe there''s
something
funny there. I also wouldn''t normally use ''ioemu:'',
but I can''t think
that it would matter.

James

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

On Sunday 03 February 2008 11:07:16 pm James Harper
wrote:
> > What log file in particular? (c:\windows\...)
> Windows event log (eventvwr.msc)
Other than the same info that was in the BSOD, there was a few references to 
things like: "The device, \Device\Scsi\XenVbd1, did not respond within the 
timeout period.''.

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

> On Sunday 03 February 2008 11:07:16 pm James Harper wrote:
> > > What log file in particular? (c:\windows\...)
> > Windows event log (eventvwr.msc)
> 
> Other than the same info that was in the BSOD, there was a few
references
> to
> things like: "The device, \Device\Scsi\XenVbd1, did not respond within
the
> timeout period.''.
Is that the cdrom?

When windows doesn''t get an answer in a reasonable time, it starts
issuing bus resets. That code path is not very well tested... and there
are at lease two reports of performance problems with physical cdrom
devices (eg /dev/hdc). Possibly the bus reset problem is causing other
problems like crashes under load?

If you haven''t already, can you try with the cdrom removed from your
configuration?

Apologies if we''re going over existing ground here...

James

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

On Monday 04 February 2008 12:16:19 am James Harper
wrote:
> > Other than the same info that was in the BSOD, there was a few
references
>> to things like: "The device, \Device\Scsi\XenVbd1, did not respond
within
>> the timeout period.''.
> Is that the cdrom?
You would know better than I, since it is a XenVbd device, but the
''1'' would
lead me to guess it is the cdrom.
> When windows doesn''t get an answer in a reasonable time, it starts
> issuing bus resets. That code path is not very well tested... and there
> are at lease two reports of performance problems with physical cdrom
> devices (eg /dev/hdc). Possibly the bus reset problem is causing other
> problems like crashes under load?
To be complete, there are two log msgs in a row, same time stamp, titled 
XenVbd. The second one is ''A pending interrupt was detected on device 
\Device\Scsi\XenVbd1 during a timeout operation.  A large number of these 
warnings may indicate that the system is not correctly  receiving or 
processing interrupts from the device.'' Since they occur at quite
different
times than the log msgs that repeat the BSOD info, they probably correspond 
to my attempts to access the cd while booted w/ /gplpv.
> If you haven''t already, can you try with the cdrom removed from
your
> configuration?
Done. I still get the same BSOD (assert error) when I try a domu to dom0 large 
file xfer while using xennet (w/ or w/o /gplpv). Also, using netfront changes 
nothing (except that the original Realtek  adapter is no longer there).:

*** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)

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

Hello James,

first of all I want to thank you for your great work!
I am using Gentoo Linux on a AMD X2 in 64bit with Xen 3.2 and I 
installed your 0.6.5 Version of the PV drivers in Windows XP 
Professional SP2. It looks like that there still is a problem with 
disabling the PCI IDE, because after the reboot, I find the 
lvm-partition 2 times in my windows system :-p
C: and D: are identical! one is IDE the other the SCSI device.
And I maybe have found the reason why. You mentioned that the 0.6.4 
version of your driver had a bug with xen 3.2 and that you''ve fixed it 
in version 0.6.5. But your 0.6.5.zip package still contains the 0.6.4 
drivers (that''s what the inf-files tell me). Is it possible, that you 
accidently packaged the 0.6.4 drivers as 0.6.5.zip?

Greetz Age_M

James Harper wrote:
> The last release was actually 0.6.4, and contained a bug which meant
> that under Xen 3.2.0 the PCI IDE device wasn''t detected and
disabled
> (the PCI ID presented by Qemu had changed). This could result in bad
> things happening to your windows filesystem (it did for me just now when
> I didn''t get this fix quite right :).
>
> This new release should fix that problem.
>
> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
>
> James
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>   


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

Hi,

this was also my first thought after trying 0.6.5.
As I wasn''t really sure which versions has been installed, I did
a fresh guest installation with 0.6.5:

  -----------------------------------------------------------------------------
  Hypervisor    : Xen 3.2.0 / 64bit (XenSource sources)
  -----------------------------------------------------------------------------
  DomO          : Xensource 2.6.18.8 / 64bit
  -----------------------------------------------------------------------------
  DomU settings : 1 VCPU, PAE, APIC
                  upto 1GB RAM, Shadow memory undefined
                  VBD Physical Block device (partition or lv)
                  VIF netfront
                  clocksource: Hostbased time
  -----------------------------------------------------------------------------
  Guest OS      : Windows XP Professional 64bit
                  latest available XenPV Driver (winnet/amd64)
		 as of there is no winxp/amd64 and winxp refuses to install
  -----------------------------------------------------------------------------

I installed guest from iso, switched one vif from netfront to ioemu to get the
winpv drivers downloaded, rebootet with netfront and installed as stated in
INSTALL.txt (this time, i followed the rules step by step ;)
May it was my fault, but i left the newly appeared NIC''s unconfigured
(say,
windows uses dhcp).
After the first reboot (without /gplpv), the qemu-dm became zombie, probably
caused by now not responding / stalled bridge (ps shows two "ip show
..."
commands - i think these are spawned by qemu-dm or some handler around)
I don''t know if this could have to do with windows dhcp requests, well
I don''t
think so, but indeed there are very restrictive firewall rules and dhcp will
never go through.
By now the whole dom0 left unusable, former configured bridge routing is working
as well as the other domU''s are up and running.
... one shouldn''t test at production environment ;)

cheers,

Stephan




Age_M schrieb:
> Hello James,
> 
> first of all I want to thank you for your great work!
> I am using Gentoo Linux on a AMD X2 in 64bit with Xen 3.2 and I 
> installed your 0.6.5 Version of the PV drivers in Windows XP 
> Professional SP2. It looks like that there still is a problem with 
> disabling the PCI IDE, because after the reboot, I find the 
> lvm-partition 2 times in my windows system :-p
> C: and D: are identical! one is IDE the other the SCSI device.
> And I maybe have found the reason why. You mentioned that the 0.6.4 
> version of your driver had a bug with xen 3.2 and that you''ve
fixed it
> in version 0.6.5. But your 0.6.5.zip package still contains the 0.6.4 
> drivers (that''s what the inf-files tell me). Is it possible, that
you
> accidently packaged the 0.6.4 drivers as 0.6.5.zip?
> 
> Greetz Age_M
> 
> James Harper wrote:
>> The last release was actually 0.6.4, and contained a bug which meant
>> that under Xen 3.2.0 the PCI IDE device wasn''t detected and
disabled
>> (the PCI ID presented by Qemu had changed). This could result in bad
>> things happening to your windows filesystem (it did for me just now
when
>> I didn''t get this fix quite right :).
>>
>> This new release should fix that problem.
>>
>> http://www.meadowcourt.org/WindowsXenPV-0.6.5.zip
>>
>> James
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>>   
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054



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

> By now the whole dom0 left unusable, former configured bridge routing
is
> working
> as well as the other domU''s are up and running.
> ... one shouldn''t test at production environment ;)
No, one shouldn''t :)

I test in a semi-production environment (there''s a secondary mail
server
running on the same Dom0).

Curiously, I''m testing an SMP problem reported by Jim Burns, and when
the SMP DomU crashed last night during the backup, it also crashed
another non-SMP Windows DomU on the same server. I think we''ve got some
ASSERT statements in the error path for xennet instead of handling
errors gracefully.

Early in development, I was able to hang the whole physical machine too,
but that hasn''t happened in a while.

One thing I have noticed though is that when I first install the network
drivers in a windows DomU, Dom0 terminates all tcp connections, although
they can be re-established immediately. It might be something like that
the bridge thinks it has detected a loop.

James

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

> Hello!
> I''m using latest Windows GPL PV drivers on Win 2003 r2 (sp2) and
while
> HD driver works o.k.
> network driver gives STOP error at boot-up or at net use.
> Is it possible to re-enable old driver?
There is a bug in the grant table code that affects xennet when vcpus > 1.
Can you change to vcpus = 1 for now?

Btw, this bug is pretty nasty and can kill your filesystem.

James
> 
> 
> System info: (maybe useful)
> Linux 84-255-235-83 2.6.18-5-xen-amd64 #1 SMP Sat Dec 22 22:22:11 UTC
> 2007 x86_64 GNU/Linux
> 
> Xen (and utils) 3.1.3-1-amd64 from packages.debianbase.de on Debian
> etch.
> 
> HW is white MacBook 1.5GB RAM
> Cpu: Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz
> 
> Windows error: STOP : 0x0000008E (0x80000003, 0x80878A8F, 0x8089A14C,
> 0x00000000)
> 
> Windows xen config:
> name = "w2k3r2s"
> builder = "hvm"
> memory = "512"
> disk = [ ''phy:/dev/vg1/winsnap,ioemu:hda,w'' ]
> #,''file:/home/w2k3r2_cd2.iso,hdc:cdrom,r'' ]
> vif = [ ''type=ioemu, mac=00:16:3e:0c:7e:18,
bridge=xenbr0'' ]
> device_model = "/usr/lib64/xen/bin/qemu-dm"
> kernel = "/usr/lib64/xen/boot/hvmloader"
> vnc=1
> #vncunused=1
> vnclisten=''0.0.0.0''
> apic=1
> acpi=1
> pae=1
> boot=''c''
> vcpus=2
> usb=1
> usbdevice=''tablet''
> on_reboot = ''restart''
> on_crash = ''restart''
> on_powerof = ''destroy''
> 
> 
> On 6.2.2008, at 0:06, James Harper wrote:
> 
> >> By now the whole dom0 left unusable, former configured bridge
routing
> > is
> >> working
> >> as well as the other domU''s are up and running.
> >> ... one shouldn''t test at production environment ;)
> >
> > No, one shouldn''t :)
> >
> > I test in a semi-production environment (there''s a secondary
mail
> > server
> > running on the same Dom0).
> >
> > Curiously, I''m testing an SMP problem reported by Jim Burns,
and when
> > the SMP DomU crashed last night during the backup, it also crashed
> > another non-SMP Windows DomU on the same server. I think
we''ve got
> > some
> > ASSERT statements in the error path for xennet instead of handling
> > errors gracefully.
> >
> > Early in development, I was able to hang the whole physical machine
> > too,
> > but that hasn''t happened in a while.
> >
> > One thing I have noticed though is that when I first install the
> > network
> > drivers in a windows DomU, Dom0 terminates all tcp connections,
> > although
> > they can be re-established immediately. It might be something like
> > that
> > the bridge thinks it has detected a loop.
> >
> > James
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users

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

On Friday 08 February 2008 05:35:03 pm James Harper
wrote:
> There is a bug in the grant table code that affects xennet when vcpus >
1.
> Can you change to vcpus = 1 for now?
>
> Btw, this bug is pretty nasty and can kill your filesystem.
What''s stopping you from releasing 0.7.0? Code cleanup?

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

> On Friday 08 February 2008 05:35:03 pm James Harper wrote:
> > There is a bug in the grant table code that affects xennet when
vcpus >
> 1.
> > Can you change to vcpus = 1 for now?
> >
> > Btw, this bug is pretty nasty and can kill your filesystem.
> 
> What''s stopping you from releasing 0.7.0? Code cleanup?
XenHide. It isn''t quite foolproof enough, and the verifier hates it.
I''m
trying to work out something that is a bit better, but Windows doesn''t
make it easy.

And work has been a but busier just lately.

James

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

Hi James/Andy,

Just to let you know, I can consistently crash the network drivers in Win2k3
by doing a large file (50Gb) transfer across the network.  This problem also
occurs at other times but a large file transfer is a guaranteed way to get a
BSOD.  The following information is from the BSOD that I get.....

DRIVER_IRQL_NOT_LESS_OR_EQL

***  STOP: 0x000000D1 (0x00000055,0xD0000002,0x00000000,0xF85D5216)

***       xennet.sys - Address F85D5216 base at F85CF000, DateStamp 47a5acf4

This is a pure 32 bit environment running on a vanilla Centos 5.1 install
with a single vcpu for the DomU.

Let me know if I can help anyway with finding the source of the problem.

Thanks for all your efforts.

Wayne

-- 
View this message in context:
http://www.nabble.com/The-real-0.6.5-release-of-Windows-PV-drivers-tp15252855p15495379.html
Sent from the Xen - User mailing list archive at Nabble.com.


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

Are you running SMP or UP in DomU?

Andy checked in a bunch of changes to xennet which may or may not fix
any problems you are having.

I''m a bit short of time lately unfortunately, and am struggling to get
a
nice solution to xenhide, so a binary release will be a few days away at
an absolute minimum.

James
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of Wayne Love
> Sent: Monday, 18 February 2008 09:06
> To: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] The real 0.6.5 release of Windows PV drivers
> 
> 
> Hi James/Andy,
> 
> Just to let you know, I can consistently crash the network drivers in
> Win2k3
> by doing a large file (50Gb) transfer across the network.  This
problem
> also
> occurs at other times but a large file transfer is a guaranteed way to
get
> a
> BSOD.  The following information is from the BSOD that I get.....
> 
> DRIVER_IRQL_NOT_LESS_OR_EQL
> 
> ***  STOP: 0x000000D1 (0x00000055,0xD0000002,0x00000000,0xF85D5216)
> 
> ***       xennet.sys - Address F85D5216 base at F85CF000, DateStamp
> 47a5acf4
> 
> This is a pure 32 bit environment running on a vanilla Centos 5.1
install
> with a single vcpu for the DomU.
> 
> Let me know if I can help anyway with finding the source of the
problem.
> 
> Thanks for all your efforts.
> 
> Wayne
> 
> --
> View this message in context: http://www.nabble.com/The-real-0.6.5-
> release-of-Windows-PV-drivers-tp15252855p15495379.html
> Sent from the Xen - User mailing list archive at Nabble.com.
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>Are you running SMP or UP in DomU?
SMP (2 processors) running 3 domains (including Dom0).

Thanks
Wayne


-- 
View this message in context:
http://www.nabble.com/The-real-0.6.5-release-of-Windows-PV-drivers-tp15252855p15537112.html
Sent from the Xen - User mailing list archive at Nabble.com.


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

> >Are you running SMP or UP in DomU?
> 
> SMP (2 processors) running 3 domains (including Dom0).
Can you reproduce the crashes with vcpus=1 in the windows domu?

James

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

> > >Are you running SMP or UP in DomU?
> > 
> > SMP (2 processors) running 3 domains (including Dom0).
> 
> Can you reproduce the crashes with vcpus=1 in the windows domu?
> 
Sorry should learn to read before I type.

The windows 2k3 domu is running with vcpus=1, I''ve not tried it >1
as do
want to push things to much in case I break something + have no real
need for >1 CPUs in my DomU machines.

The Dom0 is a SMP machine as outlined in my previous post.

Wayne

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

James,

I was finally able to use your drivers on my test machines, and release
0.6.5 finally boots no problem.

I''m doing some tests around different scenarios I''ll have in
my lab, and at
least 1 thing seems not to be fine.

The scenario is as follows:
1- a server (Win 2k3 r2/sp2 - 1 cpu - x86) creates a series of files on its
D: drive. These files are big (around 2gigs each), and are basically zip
archives.
2- when finished, the server shuts down
3- the D: drive on that server gets mounted in another domain (same windows
version) in read-only mode, and this new server unzips some of those files
on its C: drive

It seems that, if I install the pv drivers on the second server when the D:
is not present in its domain configuration, and then update the domain
configuration to include it, the system tries to mount it with the
"normal"
qemu drivers.
I tried mouting the drive as both ide or scsi, with no differences.
The system takes forever to boot, and it does not give you access to the
drive (it seems it''s not connected); in the device manager, I can see
that I
have 2 Xen vbd haddrives, and 2 scsi controllers.
I finally tried to disable the qemu provided scsi controller, leave only the
xen pv scsi active and reboot and everything started to work ok.

Maybe this is some problem with the device hider ?

Anyway, it''s a great improvement (download times have improved by ca.
50%,
and cpu seems to be gone down too) and makes Xen much more usable.

Regards,

                                                         M.



-- 
View this message in context:
http://www.nabble.com/The-real-0.6.5-release-of-Windows-PV-drivers-tp15252855p15538492.html
Sent from the Xen - User mailing list archive at Nabble.com.


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