On 21/07/2008 01:53, James Harper wrote:
This is a bit of a long shot, but Windows tends to remember the driver
it had attached to various devices, so if you had device #832 running
with 0.9.11-pre5 and that device wasn't present when you upgraded to
-pre9, windows might still use the old driver.
strange, under "driver details ..." it knew it was using the xen*.sys
files, but it didn't show any driver provider/date/version info, so a
driver update did the trick.
Once you block-attach the device, can you right click and see what
version of the driver it has loaded? Even if it says -pre9, please try
upgrading the driver anyway.
That disk was eventually added via the domU config, I'll try another
with block-attach later, as it did seem to work better in pre5.
p.s.
I tried to uninstall of the "wrong" disk in device manager and got this
event, should the driver either support removal, or deny the request in
a different way?
log #271 from PlugPlayManager
Driver is preventing the device from stopping. The name of the device
driver is listed as the vetoing service name below.
Vetoed device: XEN\VBD\4&32FE5319&1&832
Vetoing device: Xen\vbd\4&32fe5319&1&832
Vetoing service name: Driver\XenVbd
Veto type 6: PNP_VetoDevice
When Windows attempts to install, upgrade, remove, or reconfigure a
device, it queries the driver responsible for that device to confirm
that the operation can be performed. If any of these drivers denies
permission (query-removal veto), then the computer must be restarted in
order to complete the operation.
User Action
Restart your computer.
p.p.s
I notice I get a "safely remove hardware" icon on the taksbar for the
Xen Net driver, barely a niggle, but perhaps it shouldn't do that.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home