search for: uncompetit

...in the nlme package (version 3.1-16) is: eval(parse(text = paste("~", deparse(form)))) however, if deparse(form) exceeds 'width.cutoff (which defaults to 60)', this results in inappropriately placed "~" signs: For example, in my application with the error, form is UnCompetitive(MethoxyresorufinConc, InhibitorConc, Vmax, Km, Ki) the result of the paste() operation in the last line of getCovariateFormula is: > paste("~",deparse(form)) [1] "~ UnCompetitive(MethoxyresorufinConc, InhibitorConc, Vmax, Km, " [2] "~ Ki)" extending width....

...;> reported in the field we might need to catch a kick to handle these. >> I wonder whether it's easier to just support modern device? >> >> Thanks > Well hardware vendors are I think interested in supporting legacy > guests. Limiting vdpa to modern only would make it uncompetitive. My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to work. So it can only work for modern device ... Thanks > > >

...;> reported in the field we might need to catch a kick to handle these. >> I wonder whether it's easier to just support modern device? >> >> Thanks > Well hardware vendors are I think interested in supporting legacy > guests. Limiting vdpa to modern only would make it uncompetitive. My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to work. So it can only work for modern device ... Thanks > > >

...d to catch a kick to handle these. >>>> I wonder whether it's easier to just support modern device? >>>> >>>> Thanks >>> Well hardware vendors are I think interested in supporting legacy >>> guests. Limiting vdpa to modern only would make it uncompetitive. >> >> My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to >> work. > Hmm I don't really see why. Assume host maps guest memory properly, > VM does not have an IOMMU, legacy guest can just work. Yes, guest may not set IOMMU_PLATFORM. > &g...

...d to catch a kick to handle these. >>>> I wonder whether it's easier to just support modern device? >>>> >>>> Thanks >>> Well hardware vendors are I think interested in supporting legacy >>> guests. Limiting vdpa to modern only would make it uncompetitive. >> >> My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to >> work. > Hmm I don't really see why. Assume host maps guest memory properly, > VM does not have an IOMMU, legacy guest can just work. Yes, guest may not set IOMMU_PLATFORM. > &g...

...nds to write 65,000 indexed records to a dBase type file under sp2 and the same job in sp1 is 7 seconds!! I can't believe that this is a 'normal' feature of Windows sp2 software when working with Samba. Is it possible that Microsoft has made changes that make Samba under Linux totaly uncompetitive. ps. the performance drop is still there using the 'copy' command from the command prompt. The file in question is 8.1 Meg, large but not unreasonable. ANY help would be appreciated. John@mbstemps.com

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

...e might need to catch a kick to handle these. > > > I wonder whether it's easier to just support modern device? > > > > > > Thanks > > Well hardware vendors are I think interested in supporting legacy > > guests. Limiting vdpa to modern only would make it uncompetitive. > > > My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to > work. Hmm I don't really see why. Assume host maps guest memory properly, VM does not have an IOMMU, legacy guest can just work. Care explaining what's wrong with this picture? > So i...

...> > > > I wonder whether it's easier to just support modern device? > > > > > > > > > > Thanks > > > > Well hardware vendors are I think interested in supporting legacy > > > > guests. Limiting vdpa to modern only would make it uncompetitive. > > > > > > My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to > > > work. > > Hmm I don't really see why. Assume host maps guest memory properly, > > VM does not have an IOMMU, legacy guest can just work. > > > Yes,...

...is > > reported in the field we might need to catch a kick to handle these. > > > I wonder whether it's easier to just support modern device? > > Thanks Well hardware vendors are I think interested in supporting legacy guests. Limiting vdpa to modern only would make it uncompetitive. > > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > --- > > drivers/vdpa/vdpa.c | 1 + > > include/linux/vdpa.h | 34 ++++++++++++++++++++++++++++++++++ > > 2 files changed, 35 insertions(+) > > > > diff --git...

Just on the off chance that Canadian Asterisk users might be interested in a place to discuss topics specific to the "great white north" (sources, services, telcos, etc.), I created the asterisk-canada mailing list: http://lists.syonex.com/mailman/listinfo/asterisk-canada or asterisk-canada-subscribe@lists.syonex.com Cheers! John