>
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home