search for: 1105,7

Right now, we'd always be setting a NULL username. --- src/drives.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/drives.c b/src/drives.c index a13dd03..0e62ca8 100644 --- a/src/drives.c +++ b/src/drives.c @@ -1105,7 +1105,7 @@ guestfs___drive_source_qemu_param (guestfs_h *g, const struct drive_source *src) CLEANUP_FREE char *username = NULL, *port = NULL; if (src->username) - username = safe_asprintf (g, "%s@", username); + username = safe_asprintf (g, "%s@", src-...

...-EACCES)) + return 0; + + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY); + + pm_runtime_put_autosuspend(dev); + return ret; +} + static int nouveau_connector_set_property(struct drm_connector *connector, struct drm_property *property, uint64_t value) @@ -1088,7 +1105,7 @@ nouveau_connector_funcs = { .reset = nouveau_conn_reset, .detect = nouveau_connector_detect, .force = nouveau_connector_force, - .fill_modes = drm_helper_probe_single_connector_modes, + .fill_modes = nouveau_connector_probe_single_connector_modes, .set_property = nouveau_connector_set_...

...t;vdev, skb_headlen(skb)); + hdr->hdr.gso_size = cpu_to_virtio16(vi->vdev, + skb_shinfo(skb)->gso_size); if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4) hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4; else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6) @@ -1105,7 +1112,7 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs) if (!vi->has_cvq || !virtio_has_feature(vi->vdev, VIRTIO_NET_F_MQ)) return 0; - s.virtqueue_pairs = queue_pairs; + s.virtqueue_pairs = cpu_to_virtio16(vi->vdev, queue_pairs); sg_init_one(&sg,...

...t;vdev, skb_headlen(skb)); + hdr->hdr.gso_size = cpu_to_virtio16(vi->vdev, + skb_shinfo(skb)->gso_size); if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4) hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4; else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6) @@ -1105,7 +1112,7 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs) if (!vi->has_cvq || !virtio_has_feature(vi->vdev, VIRTIO_NET_F_MQ)) return 0; - s.virtqueue_pairs = queue_pairs; + s.virtqueue_pairs = cpu_to_virtio16(vi->vdev, queue_pairs); sg_init_one(&sg,...

...igblockall(NULL); + vforked++; + + pid = vfork(); + + if (!pid) { + forkchild(jp, n, FORK_FG); + sigclearmask(); + shellexec(argv, path, idx); + /* NOTREACHED */ + } + + vforked = 0; + sigclearmask(); + forkparent(jp, n, FORK_FG, pid); + + return jp; +} + /* * Wait for job to finish. * @@ -1105,7 +1152,7 @@ static int dowait(int block, struct job *jp) STATIC int waitproc(int block, int *status) { - sigset_t mask, oldmask; + sigset_t oldmask; int flags = block == DOWAIT_BLOCK ? 0 : WNOHANG; int err; @@ -1119,8 +1166,7 @@ waitproc(int block, int *status) if (err || (err = -!bloc...

This fixes quite a number of runtime PM bugs I found that have been causing some pretty nasty issues such as: - Deadlocking on boot - Connector probing potentially not working while the GPU is in runtime suspend - i2c char dev not working while the GPU is in runtime suspend - aux char dev not working while the GPU is in runtime suspend There's definitely more parts of nouveau that need

...reinstall = mxsfb_irq_preinstall, .irq_uninstall = mxsfb_irq_preinstall, diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 7c2fcaba42d6..8cb174f95448 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -1105,7 +1105,7 @@ nouveau_driver_fops = { static struct drm_driver driver_stub = { .driver_features = - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER + DRIVER_GEM | DRIVER_MODESET | DRIVER_RENDER #if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) | DRIVER_KMS_LEGACY_CONTEXT #endif di...

...reinstall = mxsfb_irq_preinstall, .irq_uninstall = mxsfb_irq_preinstall, diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 7c2fcaba42d6..8cb174f95448 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -1105,7 +1105,7 @@ nouveau_driver_fops = { static struct drm_driver driver_stub = { .driver_features = - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER + DRIVER_GEM | DRIVER_MODESET | DRIVER_RENDER #if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) | DRIVER_KMS_LEGACY_CONTEXT #endif di...

...reinstall = mxsfb_irq_preinstall, .irq_uninstall = mxsfb_irq_preinstall, diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 7c2fcaba42d6..8cb174f95448 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -1105,7 +1105,7 @@ nouveau_driver_fops = { static struct drm_driver driver_stub = { .driver_features = - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER + DRIVER_GEM | DRIVER_MODESET | DRIVER_RENDER #if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) | DRIVER_KMS_LEGACY_CONTEXT #endif di...

Hi, this patch serie adds a new GUID type in the generator, which would do the same as String, but also validating (just in the C output) the passed GUID string. This allows to reject invalid GUIDs before passing them to low-level tools. Pino Toscano (4): utils: add a function to validate a GUID string generator: add a GUID parameter type generator: generate code for parameter validation

...reinstall = mxsfb_irq_preinstall, .irq_uninstall = mxsfb_irq_preinstall, diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 7c2fcaba42d6..8cb174f95448 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -1105,7 +1105,7 @@ nouveau_driver_fops = { static struct drm_driver driver_stub = { .driver_features = - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER + DRIVER_GEM | DRIVER_MODESET | DRIVER_RENDER #if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) | DRIVER_KMS_LEGACY_CONTEXT #endif di...

...turn; } This seem to be rational. From Samba POV there is posible that samba don't control directory which is root for share. But in other hand samba has share_info.tdb.... so a little diff will help us: --- samba-3.2.5.orig/source/smbd/reply.c +++ samba-3.2.5/source/smbd/reply.c @@ -1105,7 +1105,8 @@ * Not sure here is the right place to catch this * condition. Might be moved to somewhere else later -- vl */ - reply_nterror(req, NT_STATUS_ACCESS_DENIED); + //reply_nterror(req, NT_STATUS_ACCESS_DENIED); +...

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

As Michael mentioned, set affinity and select queue will not work very well when CPU IDs are not consecutive, this can happen with hot unplug. Fix this bug by traversal the online CPUs, and create a per cpu variable to find the mapping from CPU to the preferable virtual-queue. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

Hi, These patches contain support for some features that are already in Syslinux 4 but weren't working properly on the elflink branch. It's another step closer to feature parity with Syslinux 4. Having to jump through the comboot API for localboot support is less than ideal and I'll eventually fix that, probably when we move a big chunk of code from asm to C. Also, there's a