search for: 281,10

I am using function restrictedparts, but got error: restrictedparts(281,10) Error in integer(len) : vector size specified is too large Calls: restrictedparts -> integer In addition: Warning message: In restrictedparts(281, 10) : NAs introduced by coercion Error in integer(len) : vector size specified is too large Calls: restrictedparts -> integer is there a sim...

...ksums.mli | 3 +++ builder/index_parser.ml | 22 +++++++++++++++------- builder/index_parser.mli | 2 +- 5 files changed, 25 insertions(+), 11 deletions(-) diff --git a/builder/builder.ml b/builder/builder.ml index e4f40ef..6f2b4bd 100644 --- a/builder/builder.ml +++ b/builder/builder.ml @@ -281,10 +281,10 @@ let main () = let () = match entry with (* New-style: Using a checksum. *) - | { Index_parser.checksum_sha512 = Some csum } -> - Checksums.verify_checksum (Checksums.SHA512 csum) template + | { Index_parser.checksums = Some csums } -> + Checksums.ver...

...- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 5bfae1f972c74..0061deca290a4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -281,8 +281,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) pm_runtime_get_noresume(dev->dev); } else { ret = pm_runtime_get_sync(dev->dev); - if (ret < 0 && ret != -EACCES) + if (ret < 0 && ret != -EACCES) { + pm_runtime_put_autosuspen...

Josh Coalson wrote: > --- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > > > Hi all, > > > > I added -Wmissing-prototypes -Wstrict-prototypes to the CFLAGS and > > found that there were a number warnings generated. > > > > The patch below fixes those warnings and adds the two -W flags to > > configure.in. > > I checked most

...*err) { uint32_t n; - uint64_t real_size_copy; - - pthread_mutex_lock (&lock); - real_size_copy = real_size; - pthread_mutex_unlock (&lock); + uint64_t real_size_copy = get_real_size (); if (offset < real_size_copy) { if (offset + count <= real_size_copy) @@ -292,14 +281,10 @@ truncate_extents (struct nbdkit_next_ops *next_ops, void *nxdata, uint32_t flags, struct nbdkit_extents *extents, int *err) { uint32_t n; - uint64_t real_size_copy; + uint64_t real_size_copy = get_real_size (); CLEANUP_EXTENTS_FREE struct nbdkit_extents *extents2 =...

...6 +42,7 @@ type cmdline = { output_format : string option; output_name : string option; print_source : bool; + print_target : bool; root_choice : Types.root_choice; } diff --git a/v2v/types.ml b/v2v/types.ml index b89bd2fe2..c1f36fdb1 100644 --- a/v2v/types.ml +++ b/v2v/types.ml @@ -281,11 +281,10 @@ type overlay = { } let string_of_overlay ov = - sprintf "\ -ov_overlay_file = %s -ov_sd = %s -ov_virtual_size = %Ld -ov_source = %s + sprintf " overlay file: %s + overlay device name: %s +overlay virtual disk size: %Ld + overlay source qemu URI: %s &...

RHV was connecting to the VMware source in order to find out the virtual disk size of the source disk(s), duplicating logic that virt-v2v already provides. This makes that information available using a new ‘virt-v2v --print-target option’. Note in order to get all the information, this has to actually perform the conversion step, so it takes 30 seconds or so before we reach the point where the

The spec is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Add type-safe wrappers to prevent access with incorrect width. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

The spec is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Add type-safe wrappers to prevent access with incorrect width. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

This series is mainly for testing live migration between 2 vdpa_sim_blk devices. The first patch is preparation and moves the buffer allocation into devices, the second patch adds the `shared_buffer_mutex` parameter to vdpa_sim_blk to use the same ramdisk for all devices. Tested with QEMU v8.0.0-rc2 in this way: modprobe vhost_vdpa modprobe vdpa_sim_blk shared_backend=true vdpa dev add mgmtdev

This adds --print-target. In addition, v2 provides a machine-readable version (in JSON format). All of the record -> JSON boilerplate in this patch could be eliminated if we moved the baseline to OCaml 4.02. Rich.

...alue) * frame->n_registers, frame->registers); - if (frame->script) { - swfdec_script_unref (frame->script); - frame->script = NULL; - } if (frame->constant_pool) { swfdec_constant_pool_free (frame->constant_pool); frame->constant_pool = NULL; @@ -285,6 +281,10 @@ swfdec_as_frame_dispose (GObject *object swfdec_as_frame_pop_block (frame); g_array_free (frame->blocks, TRUE); g_slist_free (frame->scope_chain); + if (frame->script) { + swfdec_script_unref (frame->script); + frame->script = NULL; + } G_OBJECT_CLASS (s...

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

Hi, this series adds a basic support for Simple Streams v1.0 metadata files. This makes it possible to create a repository .conf files with [cirros] uri=http://download.cirros-cloud.net format=simplestreams to read the latest version of each CirrOS image. TODO items: - a bit more testing: listing and creating images works, so the current metadata is correct - handle revisions, so newer

I do have a question about whether patch 2 is right, or whether I've exposed a bigger problem in the truncate (and possibly other) filter, but the rest seem fairly straightforward. Eric Blake (4): server: Check for pthread lock failures truncate: Factor out reading real_size under mutex plugins: Check for mutex failures filters: Check for mutex failures filters/cache/cache.c

Resending this patch from my personal Linux server. Exchange server and outlook at Microsoft seems to badly munge my patch. :( From: Hank Janssen <hjanssen at sailtheuniverse.com> Subject: [PATCH 1/1] hv: Added new hv_utils driver with shutdown as first functionality Addition of new driver for Hyper-V called hv_utils. This driver is intended to support things like KVP, Timesync, Heartbeat

Resending this patch from my personal Linux server. Exchange server and outlook at Microsoft seems to badly munge my patch. :( From: Hank Janssen <hjanssen at sailtheuniverse.com> Subject: [PATCH 1/1] hv: Added new hv_utils driver with shutdown as first functionality Addition of new driver for Hyper-V called hv_utils. This driver is intended to support things like KVP, Timesync, Heartbeat

...if (!test_range_bit(&root->fs_info->pinned_extents, bytenr, bytenr + blocksize - 1, EXTENT_DIRTY, 0)) @@ -167,7 +172,7 @@ struct dir_iterate_data { struct btrfs_root *root; struct btrfs_inode_item *inode; u64 objectid; - u32 parent; + u64 parent; int errcode; }; @@ -281,10 +286,9 @@ fail: } /* - * record a single file extent. do all required works: - * 1. insert a btrfs_file_extent_item into fs tree. - * 2. compute checksum and insert btrfs_csum_item into fs tree. - * 3. insert extent item and extent backref into extent tree. + * Record a file extent. Do all th...

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel