[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] The real 0.6.5 release of Windows PV drivers
> > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |