[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] set_phys_to_machine not exported?
>>> On 04.01.12 at 04:44, James Harper <james.harper@xxxxxxxxxxxxxxxx> wrote: >> Okay I have it compiling and loading now (that xenbus init macro obviously >> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi > device - >> it just hangs for a while then says hotplug didn't work. >> >> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre >> I'm running now? >> > > Loading and detecting properly now (see email about the choice of shell in > the vscsi script), and appears to be restoring with the following patch: > > --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c 2012-01-04 > 10:51:36.090985303 +1100 > +++ emulate.c 2012-01-04 13:28:23.288336520 +1100 > @@ -401,8 +401,8 @@ > NO_EMULATE(INQUIRY); /*0x12*/ > /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/ > NO_EMULATE(MODE_SELECT); /*0x15*/ /* st */ > - /*NO_EMULATE(RESERVE); *//*0x16*/ > - /*NO_EMULATE(RELEASE); *//*0x17*/ > + NO_EMULATE(RESERVE); /*0x16*/ > + NO_EMULATE(RELEASE); /*0x17*/ These don't appear to be generated anywhere in the Linux tree, even though several drivers implement their handing. Am I then to understand that it's Windows which is actually making use of them? If so, is there a way to know what other commands Linux doesn't use may still need enabling in the emulation table for Windows' sake? Jan > /*NO_EMULATE(COPY); *//*0x18*/ > NO_EMULATE(ERASE); /*0x19*/ /* st */ > NO_EMULATE(MODE_SENSE); /*0x1a*/ /* st */ > > James > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |