All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH 53/55] scsi-generic: bump SCSIRequest reference count until aio completion runs
From: Kevin Wolf @ 2011-10-31 13:30 UTC (permalink / raw)
  To: anthony; +Cc: kwolf, qemu-devel
In-Reply-To: <1320067830-12093-1-git-send-email-kwolf@redhat.com>

From: Paolo Bonzini <pbonzini@redhat.com>

Same as before, but for scsi-generic.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 hw/scsi-generic.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/hw/scsi-generic.c b/hw/scsi-generic.c
index 2f95f2d..9594cc1 100644
--- a/hw/scsi-generic.c
+++ b/hw/scsi-generic.c
@@ -113,6 +113,9 @@ static void scsi_command_complete(void *opaque, int ret)
             r, r->req.tag, status);
 
     scsi_req_complete(&r->req, status);
+    if (!r->req.io_canceled) {
+        scsi_req_unref(&r->req);
+    }
 }
 
 /* Cancel a pending data transfer.  */
@@ -123,6 +126,11 @@ static void scsi_cancel_io(SCSIRequest *req)
     DPRINTF("Cancel tag=0x%x\n", req->tag);
     if (r->req.aiocb) {
         bdrv_aio_cancel(r->req.aiocb);
+
+        /* This reference was left in by scsi_*_data.  We take ownership of
+         * it independent of whether bdrv_aio_cancel completes the request
+         * or not.  */
+        scsi_req_unref(&r->req);
     }
     r->req.aiocb = NULL;
 }
@@ -183,6 +191,9 @@ static void scsi_read_complete(void * opaque, int ret)
         bdrv_set_buffer_alignment(s->conf.bs, s->blocksize);
 
         scsi_req_data(&r->req, len);
+        if (!r->req.io_canceled) {
+            scsi_req_unref(&r->req);
+        }
     }
 }
 
@@ -194,6 +205,9 @@ static void scsi_read_data(SCSIRequest *req)
     int ret;
 
     DPRINTF("scsi_read_data 0x%x\n", req->tag);
+
+    /* The request is used as the AIO opaque value, so add a ref.  */
+    scsi_req_ref(&r->req);
     if (r->len == -1) {
         scsi_command_complete(r, 0);
         return;
@@ -242,6 +256,8 @@ static void scsi_write_data(SCSIRequest *req)
         return;
     }
 
+    /* The request is used as the AIO opaque value, so add a ref.  */
+    scsi_req_ref(&r->req);
     ret = execute_command(s->conf.bs, r, SG_DXFER_TO_DEV, scsi_write_complete);
     if (ret < 0) {
         scsi_command_complete(r, ret);
@@ -285,6 +301,8 @@ static int32_t scsi_send_command(SCSIRequest *req, uint8_t *cmd)
             g_free(r->buf);
         r->buflen = 0;
         r->buf = NULL;
+        /* The request is used as the AIO opaque value, so add a ref.  */
+        scsi_req_ref(&r->req);
         ret = execute_command(s->conf.bs, r, SG_DXFER_NONE, scsi_command_complete);
         if (ret < 0) {
             scsi_command_complete(r, ret);
-- 
1.7.6.4

^ permalink raw reply related

* [Qemu-devel] [PATCH 54/55] scsi: push request restart to SCSIDevice
From: Kevin Wolf @ 2011-10-31 13:30 UTC (permalink / raw)
  To: anthony; +Cc: kwolf, qemu-devel
In-Reply-To: <1320067830-12093-1-git-send-email-kwolf@redhat.com>

From: Paolo Bonzini <pbonzini@redhat.com>

The request restart mechanism is generic and could be reused for
scsi-generic.  In the meanwhile, pushing it to SCSIDevice avoids
that scsi_dma_restart_bh looks at SCSIGenericReqs when working on
a scsi-block device.

The code is the same that is already in hw/scsi-disk.c, with
the type flags replaced by req->cmd.mode and a more generic way to
requeue SCSI_XFER_NONE commands.

I also added a missing call to qemu_del_vm_change_state_handler.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 hw/scsi-bus.c  |   56 +++++++++++++++++++++++++++++++++++++++++
 hw/scsi-disk.c |   76 +++++--------------------------------------------------
 hw/scsi.h      |    5 +++
 3 files changed, 68 insertions(+), 69 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index dfce5fb..e6ebbd5 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -8,6 +8,7 @@
 
 static char *scsibus_get_fw_dev_path(DeviceState *dev);
 static int scsi_req_parse(SCSICommand *cmd, SCSIDevice *dev, uint8_t *buf);
+static void scsi_req_dequeue(SCSIRequest *req);
 static int scsi_build_sense(uint8_t *in_buf, int in_len,
                             uint8_t *buf, int len, bool fixed);
 
@@ -33,6 +34,53 @@ void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info)
     bus->qbus.allow_hotplug = 1;
 }
 
+static void scsi_dma_restart_bh(void *opaque)
+{
+    SCSIDevice *s = opaque;
+    SCSIRequest *req, *next;
+
+    qemu_bh_delete(s->bh);
+    s->bh = NULL;
+
+    QTAILQ_FOREACH_SAFE(req, &s->requests, next, next) {
+        scsi_req_ref(req);
+        if (req->retry) {
+            req->retry = false;
+            switch (req->cmd.mode) {
+            case SCSI_XFER_FROM_DEV:
+            case SCSI_XFER_TO_DEV:
+                scsi_req_continue(req);
+                break;
+            case SCSI_XFER_NONE:
+                scsi_req_dequeue(req);
+                scsi_req_enqueue(req);
+                break;
+            }
+        }
+        scsi_req_unref(req);
+    }
+}
+
+void scsi_req_retry(SCSIRequest *req)
+{
+    /* No need to save a reference, because scsi_dma_restart_bh just
+     * looks at the request list.  */
+    req->retry = true;
+}
+
+static void scsi_dma_restart_cb(void *opaque, int running, RunState state)
+{
+    SCSIDevice *s = opaque;
+
+    if (!running) {
+        return;
+    }
+    if (!s->bh) {
+        s->bh = qemu_bh_new(scsi_dma_restart_bh, s);
+        qemu_bh_schedule(s->bh);
+    }
+}
+
 static int scsi_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     SCSIDevice *dev = DO_UPCAST(SCSIDevice, qdev, qdev);
@@ -83,6 +131,10 @@ static int scsi_qdev_init(DeviceState *qdev, DeviceInfo *base)
     dev->info = info;
     QTAILQ_INIT(&dev->requests);
     rc = dev->info->init(dev);
+    if (rc == 0) {
+        dev->vmsentry = qemu_add_vm_change_state_handler(scsi_dma_restart_cb,
+                                                         dev);
+    }
 
 err:
     return rc;
@@ -92,6 +144,9 @@ static int scsi_qdev_exit(DeviceState *qdev)
 {
     SCSIDevice *dev = DO_UPCAST(SCSIDevice, qdev, qdev);
 
+    if (dev->vmsentry) {
+        qemu_del_vm_change_state_handler(dev->vmsentry);
+    }
     if (dev->info->destroy) {
         dev->info->destroy(dev);
     }
@@ -586,6 +641,7 @@ int32_t scsi_req_enqueue(SCSIRequest *req)
 static void scsi_req_dequeue(SCSIRequest *req)
 {
     trace_scsi_req_dequeue(req->dev->id, req->lun, req->tag);
+    req->retry = false;
     if (req->enqueued) {
         QTAILQ_REMOVE(&req->dev->requests, req, next);
         req->enqueued = false;
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index bb07737..352d41f 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -42,12 +42,6 @@ do { fprintf(stderr, "scsi-disk: " fmt , ## __VA_ARGS__); } while (0)
 #define SCSI_DMA_BUF_SIZE    131072
 #define SCSI_MAX_INQUIRY_LEN 256
 
-#define SCSI_REQ_STATUS_RETRY           0x01
-#define SCSI_REQ_STATUS_RETRY_TYPE_MASK 0x06
-#define SCSI_REQ_STATUS_RETRY_READ      0x00
-#define SCSI_REQ_STATUS_RETRY_WRITE     0x02
-#define SCSI_REQ_STATUS_RETRY_FLUSH     0x04
-
 typedef struct SCSIDiskState SCSIDiskState;
 
 typedef struct SCSIDiskReq {
@@ -58,7 +52,6 @@ typedef struct SCSIDiskReq {
     uint32_t buflen;
     struct iovec iov;
     QEMUIOVector qiov;
-    uint32_t status;
     BlockAcctCookie acct;
 } SCSIDiskReq;
 
@@ -75,8 +68,7 @@ struct SCSIDiskState
     bool tray_locked;
 };
 
-static int scsi_handle_rw_error(SCSIDiskReq *r, int error, int type);
-static int32_t scsi_send_command(SCSIRequest *req, uint8_t *buf);
+static int scsi_handle_rw_error(SCSIDiskReq *r, int error);
 
 static void scsi_free_request(SCSIRequest *req)
 {
@@ -102,7 +94,6 @@ static void scsi_cancel_io(SCSIRequest *req)
     SCSIDiskReq *r = DO_UPCAST(SCSIDiskReq, req, req);
 
     DPRINTF("Cancel tag=0x%x\n", req->tag);
-    r->status &= ~(SCSI_REQ_STATUS_RETRY | SCSI_REQ_STATUS_RETRY_TYPE_MASK);
     if (r->req.aiocb) {
         bdrv_aio_cancel(r->req.aiocb);
 
@@ -139,7 +130,7 @@ static void scsi_read_complete(void * opaque, int ret)
     }
 
     if (ret) {
-        if (scsi_handle_rw_error(r, -ret, SCSI_REQ_STATUS_RETRY_READ)) {
+        if (scsi_handle_rw_error(r, -ret)) {
             goto done;
         }
     }
@@ -168,7 +159,7 @@ static void scsi_flush_complete(void * opaque, int ret)
     }
 
     if (ret < 0) {
-        if (scsi_handle_rw_error(r, -ret, SCSI_REQ_STATUS_RETRY_FLUSH)) {
+        if (scsi_handle_rw_error(r, -ret)) {
             goto done;
         }
     }
@@ -233,9 +224,9 @@ static void scsi_read_data(SCSIRequest *req)
  * scsi_handle_rw_error always manages its reference counts, independent
  * of the return value.
  */
-static int scsi_handle_rw_error(SCSIDiskReq *r, int error, int type)
+static int scsi_handle_rw_error(SCSIDiskReq *r, int error)
 {
-    int is_read = (type == SCSI_REQ_STATUS_RETRY_READ);
+    int is_read = (r->req.cmd.xfer == SCSI_XFER_FROM_DEV);
     SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
     BlockErrorAction action = bdrv_get_on_error(s->qdev.conf.bs, is_read);
 
@@ -247,17 +238,10 @@ static int scsi_handle_rw_error(SCSIDiskReq *r, int error, int type)
     if ((error == ENOSPC && action == BLOCK_ERR_STOP_ENOSPC)
             || action == BLOCK_ERR_STOP_ANY) {
 
-        type &= SCSI_REQ_STATUS_RETRY_TYPE_MASK;
-        r->status |= SCSI_REQ_STATUS_RETRY | type;
-
         bdrv_mon_event(s->qdev.conf.bs, BDRV_ACTION_STOP, is_read);
         vm_stop(RUN_STATE_IO_ERROR);
         bdrv_iostatus_set_err(s->qdev.conf.bs, error);
-
-        /* No need to save a reference, because scsi_dma_restart_bh just
-         * looks at the request list.  If a request is canceled, the
-         * retry request is just dropped.
-         */
+        scsi_req_retry(&r->req);
     } else {
         switch (error) {
         case ENOMEDIUM:
@@ -290,7 +274,7 @@ static void scsi_write_complete(void * opaque, int ret)
     }
 
     if (ret) {
-        if (scsi_handle_rw_error(r, -ret, SCSI_REQ_STATUS_RETRY_WRITE)) {
+        if (scsi_handle_rw_error(r, -ret)) {
             goto done;
         }
     }
@@ -347,51 +331,6 @@ static void scsi_write_data(SCSIRequest *req)
     }
 }
 
-static void scsi_dma_restart_bh(void *opaque)
-{
-    SCSIDiskState *s = opaque;
-    SCSIRequest *req;
-    SCSIDiskReq *r;
-
-    qemu_bh_delete(s->bh);
-    s->bh = NULL;
-
-    QTAILQ_FOREACH(req, &s->qdev.requests, next) {
-        r = DO_UPCAST(SCSIDiskReq, req, req);
-        if (r->status & SCSI_REQ_STATUS_RETRY) {
-            int status = r->status;
-
-            r->status &=
-                ~(SCSI_REQ_STATUS_RETRY | SCSI_REQ_STATUS_RETRY_TYPE_MASK);
-
-            switch (status & SCSI_REQ_STATUS_RETRY_TYPE_MASK) {
-            case SCSI_REQ_STATUS_RETRY_READ:
-                scsi_read_data(&r->req);
-                break;
-            case SCSI_REQ_STATUS_RETRY_WRITE:
-                scsi_write_data(&r->req);
-                break;
-            case SCSI_REQ_STATUS_RETRY_FLUSH:
-                scsi_send_command(&r->req, r->req.cmd.buf);
-                break;
-            }
-        }
-    }
-}
-
-static void scsi_dma_restart_cb(void *opaque, int running, RunState state)
-{
-    SCSIDiskState *s = opaque;
-
-    if (!running) {
-        return;
-    }
-    if (!s->bh) {
-        s->bh = qemu_bh_new(scsi_dma_restart_bh, s);
-        qemu_bh_schedule(s->bh);
-    }
-}
-
 /* Return a pointer to the data buffer.  */
 static uint8_t *scsi_get_buf(SCSIRequest *req)
 {
@@ -1591,7 +1530,6 @@ static int scsi_initfn(SCSIDevice *dev)
     }
     bdrv_set_buffer_alignment(s->qdev.conf.bs, s->qdev.blocksize);
 
-    qemu_add_vm_change_state_handler(scsi_dma_restart_cb, s);
     bdrv_iostatus_enable(s->qdev.conf.bs);
     add_boot_device_path(s->qdev.conf.bootindex, &dev->qdev, ",0");
     return 0;
diff --git a/hw/scsi.h b/hw/scsi.h
index fcc3455..ff8fdd0 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -3,6 +3,7 @@
 
 #include "qdev.h"
 #include "block.h"
+#include "sysemu.h"
 
 #define MAX_SCSI_DEVS	255
 
@@ -52,6 +53,7 @@ struct SCSIRequest {
     uint32_t sense_len;
     bool enqueued;
     bool io_canceled;
+    bool retry;
     void *hba_private;
     QTAILQ_ENTRY(SCSIRequest) next;
 };
@@ -59,6 +61,8 @@ struct SCSIRequest {
 struct SCSIDevice
 {
     DeviceState qdev;
+    VMChangeStateEntry *vmsentry;
+    QEMUBH *bh;
     uint32_t id;
     BlockConf conf;
     SCSIDeviceInfo *info;
@@ -194,6 +198,7 @@ uint8_t *scsi_req_get_buf(SCSIRequest *req);
 int scsi_req_get_sense(SCSIRequest *req, uint8_t *buf, int len);
 void scsi_req_abort(SCSIRequest *req, int status);
 void scsi_req_cancel(SCSIRequest *req);
+void scsi_req_retry(SCSIRequest *req);
 void scsi_device_purge_requests(SCSIDevice *sdev, SCSISense sense);
 int scsi_device_get_sense(SCSIDevice *dev, uint8_t *buf, int len, bool fixed);
 SCSIDevice *scsi_device_find(SCSIBus *bus, int channel, int target, int lun);
-- 
1.7.6.4

^ permalink raw reply related

* [Qemu-devel] [PATCH 55/55] scsi-disk: add scsi-block for device passthrough
From: Kevin Wolf @ 2011-10-31 13:30 UTC (permalink / raw)
  To: anthony; +Cc: kwolf, qemu-devel
In-Reply-To: <1320067830-12093-1-git-send-email-kwolf@redhat.com>

From: Paolo Bonzini <pbonzini@redhat.com>

scsi-block is a new device that supports device passthrough of Linux
block devices (i.e. /dev/sda, not /dev/sg0).  It uses SG_IO for commands
other than I/O commands, and regular AIO read/writes for I/O commands.
Besides being simpler to configure (no mapping required to scsi-generic
device names), this removes the need for a large bounce buffer and,
in the future, will get scatter/gather support for free from scsi-disk.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 hw/scsi-disk.c |  118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 352d41f..1c04872 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -39,6 +39,10 @@ do { fprintf(stderr, "scsi-disk: " fmt , ## __VA_ARGS__); } while (0)
 #include "blockdev.h"
 #include "block_int.h"
 
+#ifdef __linux
+#include <scsi/sg.h>
+#endif
+
 #define SCSI_DMA_BUF_SIZE    131072
 #define SCSI_MAX_INQUIRY_LEN 256
 
@@ -1588,6 +1592,105 @@ static SCSIRequest *scsi_new_request(SCSIDevice *d, uint32_t tag, uint32_t lun,
     return req;
 }
 
+#ifdef __linux__
+static int get_device_type(SCSIDiskState *s)
+{
+    BlockDriverState *bdrv = s->qdev.conf.bs;
+    uint8_t cmd[16];
+    uint8_t buf[36];
+    uint8_t sensebuf[8];
+    sg_io_hdr_t io_header;
+    int ret;
+
+    memset(cmd, 0, sizeof(cmd));
+    memset(buf, 0, sizeof(buf));
+    cmd[0] = INQUIRY;
+    cmd[4] = sizeof(buf);
+
+    memset(&io_header, 0, sizeof(io_header));
+    io_header.interface_id = 'S';
+    io_header.dxfer_direction = SG_DXFER_FROM_DEV;
+    io_header.dxfer_len = sizeof(buf);
+    io_header.dxferp = buf;
+    io_header.cmdp = cmd;
+    io_header.cmd_len = sizeof(cmd);
+    io_header.mx_sb_len = sizeof(sensebuf);
+    io_header.sbp = sensebuf;
+    io_header.timeout = 6000; /* XXX */
+
+    ret = bdrv_ioctl(bdrv, SG_IO, &io_header);
+    if (ret < 0 || io_header.driver_status || io_header.host_status) {
+        return -1;
+    }
+    s->qdev.type = buf[0];
+    s->removable = (buf[1] & 0x80) != 0;
+    return 0;
+}
+
+static int scsi_block_initfn(SCSIDevice *dev)
+{
+    SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, dev);
+    int sg_version;
+    int rc;
+
+    if (!s->qdev.conf.bs) {
+        error_report("scsi-block: drive property not set");
+        return -1;
+    }
+
+    /* check we are using a driver managing SG_IO (version 3 and after) */
+    if (bdrv_ioctl(s->qdev.conf.bs, SG_GET_VERSION_NUM, &sg_version) < 0 ||
+        sg_version < 30000) {
+        error_report("scsi-block: scsi generic interface too old");
+        return -1;
+    }
+
+    /* get device type from INQUIRY data */
+    rc = get_device_type(s);
+    if (rc < 0) {
+        error_report("scsi-block: INQUIRY failed");
+        return -1;
+    }
+
+    /* Make a guess for the block size, we'll fix it when the guest sends.
+     * READ CAPACITY.  If they don't, they likely would assume these sizes
+     * anyway. (TODO: check in /sys).
+     */
+    if (s->qdev.type == TYPE_ROM || s->qdev.type == TYPE_WORM) {
+        s->qdev.blocksize = 2048;
+    } else {
+        s->qdev.blocksize = 512;
+    }
+    return scsi_initfn(&s->qdev);
+}
+
+static SCSIRequest *scsi_block_new_request(SCSIDevice *d, uint32_t tag,
+                                           uint32_t lun, uint8_t *buf,
+                                           void *hba_private)
+{
+    SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, d);
+
+    switch (buf[0]) {
+    case READ_6:
+    case READ_10:
+    case READ_12:
+    case READ_16:
+    case WRITE_6:
+    case WRITE_10:
+    case WRITE_12:
+    case WRITE_16:
+    case WRITE_VERIFY_10:
+    case WRITE_VERIFY_12:
+    case WRITE_VERIFY_16:
+        return scsi_req_alloc(&scsi_disk_reqops, &s->qdev, tag, lun,
+                              hba_private);
+    }
+
+    return scsi_req_alloc(&scsi_generic_req_ops, &s->qdev, tag, lun,
+                          hba_private);
+}
+#endif
+
 #define DEFINE_SCSI_DISK_PROPERTIES()                           \
     DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),          \
     DEFINE_PROP_STRING("ver",  SCSIDiskState, version),         \
@@ -1623,6 +1726,21 @@ static SCSIDeviceInfo scsi_disk_info[] = {
             DEFINE_SCSI_DISK_PROPERTIES(),
             DEFINE_PROP_END_OF_LIST(),
         },
+#ifdef __linux__
+    },{
+        .qdev.name    = "scsi-block",
+        .qdev.fw_name = "disk",
+        .qdev.desc    = "SCSI block device passthrough",
+        .qdev.size    = sizeof(SCSIDiskState),
+        .qdev.reset   = scsi_disk_reset,
+        .init         = scsi_block_initfn,
+        .destroy      = scsi_destroy,
+        .alloc_req    = scsi_block_new_request,
+        .qdev.props   = (Property[]) {
+            DEFINE_SCSI_DISK_PROPERTIES(),
+            DEFINE_PROP_END_OF_LIST(),
+        },
+#endif
     },{
         .qdev.name    = "scsi-disk", /* legacy -device scsi-disk */
         .qdev.fw_name = "disk",
-- 
1.7.6.4

^ permalink raw reply related

* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Łukasz Sacha @ 2011-10-31 13:29 UTC (permalink / raw)
  To: Patrice Kadionik; +Cc: xenomai
In-Reply-To: <4EAEA0AB.4010102@domain.hid>

Yes you were right! That helped - thank you.
--
Łukasz Dragilla Sacha



On Mon, Oct 31, 2011 at 14:20, Patrice Kadionik
<kadionik@domain.hid> wrote:
> Le 31/10/2011 14:13, Gilles Chanteperdrix a écrit :
>
> Hi,
>
> You have perhaps followed this tutorial for mini2440 (I've worked on this
> board in july ;-) ):
> http://code.google.com/p/friendlyarm/wiki/Linux_Tutorial
>
> Please try to unset  CC and CROSS_COMPILE.
>
> Pat.
>
>
>> On 10/31/2011 01:52 PM, Łukasz Sacha wrote:
>>>
>>> This is the line configure generated to test whether compiler works:
>>> arm-none-linux-gnueabi-gcc –march=armv4t –mtune=arm920t -o conftest
>>> -march=armv4t -march=armv4t conftest.c
>>> (notice tripple  -march=armv4t)
>>>
>>> when I execute it it gives me:
>>> arm-none-linux-gnueabi-gcc: –march=armv4t: No such file or directory
>>> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
>>> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
>>> arm-none-linux-gnueabi-gcc: no input files
>>>
>>> However with a single  -march=armv4t it doesn't work either.
>>> luke@domain.hid$
>>> arm-none-linux-gnueabi-gcc -march=armv4t –mtune=arm920t -o conftest
>>> conftest.c
>>> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
>>> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
>>> arm-none-linux-gnueabi-gcc: no input files
>>>
>>> .. which is strange, because arm-none-linux-gnueabi-gcc --help tells
>>> me all the options are ok:
>>> "Options starting with -g, -f, -m, -O, -W, or --param are automatically
>>>  passed on to the various sub-processes invoked by
>>> arm-none-linux-gnueabi-gcc."
>>>
>>> Seems -mtune is not recognized by some subprocess, but which and why?
>>>
>>> cheers :)
>>
>> Strange toolchain. I use codesourcery toolchain and never observed such
>> behaviour. You should make sure the toolchain you use works before
>> trying and compiling xenomai.
>>
>
>
> --
> Patrice Kadionik. F6KQH / F4CUQ
> -----------
>
> +----------------------------------------------------------------------+
> +"Tout doit etre aussi simple que possible, pas seulement plus simple" +
> +----------------------------------------------------------------------+
> + Patrice Kadionik             http://www.enseirb-matmeca.fr/~kadionik +
> + IMS Laboratory               http://www.ims-bordeaux.fr/             +
> + ENSEIRB-MATMECA              http://www.enseirb-matmeca.fr           +
> + PO BOX 99                    fax   : +33 5.56.37.20.23               +
> + 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
> + FRANCE                                                               +
> +----------------------------------------------------------------------+
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>


^ permalink raw reply

* Re: [PATCH 5/7] ath6kl: Invoke wow suspend/resume calls during PM operations
From: Kalle Valo @ 2011-10-31 13:29 UTC (permalink / raw)
  To: Raja Mani; +Cc: linux-wireless
In-Reply-To: <4EAE705C.3090704@qca.qualcomm.com>

On 10/31/2011 11:54 AM, Raja Mani wrote:
> On Friday 28 October 2011 06:51 PM, Kalle Valo wrote:
>> On 10/25/2011 01:37 PM, rmani@qca.qualcomm.com wrote:
>>
>>> +	if (wow&&  ath6kl_cfg80211_ready(ar)&&
>>> +	    test_bit(CONNECTED,&ar->flag)&&
>>> +	    ath6kl_hif_keep_pwr_caps(ar)) {
>>> +
>>> +		/* Flush all non control pkts in Tx path */
>>> +		ath6kl_tx_data_cleanup(ar);
>>> +
>>> +		ret = ath6kl_pm_wow_suspend(ar, wow);
>>> +		if (ret)
>>> +			return ret;
>>> +	}
>>
>> Forgot to mention: don't you also need to check for MMC_PM_WAKE_SDIO_IRQ
>> and also set it with sdio_set_host_pm_flags()?
> 
> I tested it in x86 machine. Wow suspend/resume works even without 
> setting MMC_PM_WAKE_SDIO_IRQ. Should i really handle it ?

Yes, you should. Otherwise firmware is not able to wake up the host.

Also you should both check that wake sdio irq supported by the sdio
controller. Otherwise we might enable WoW even in cases when sdio
controller doesn't support it and which would result in broken wow
functionality.

Kalle

^ permalink raw reply

* Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]
From: Christian Brunner @ 2011-10-31 13:29 UTC (permalink / raw)
  To: Josef Bacik, Sage Weil, linux-btrfs
In-Reply-To: <CAO47_-98Sgpo124_F6w13Oi994wUt12PstWyB5N7+QdiYJECEQ@mail.gmail.com>

2011/10/31 Christian Brunner <chb@muc.de>:
> 2011/10/31 Christian Brunner <chb@muc.de>:
>> 2011/10/31 Christian Brunner <chb@muc.de>:
>>>
>>> The patch didn't hurt, but I've to tell you that I'm still seeing t=
he
>>> same old problems. Load is going up again:
>>>
>>> =A0PID USER =A0 =A0 =A0PR =A0NI =A0VIRT =A0RES =A0SHR S %CPU %MEM =A0=
 =A0TIME+ =A0COMMAND
>>> =A05502 root =A0 =A0 =A020 =A0 0 =A0 =A0 0 =A0 =A00 =A0 =A00 S 52.5=
 0.0 106:29.97 btrfs-endio-wri
>>> =A01976 root =A0 =A0 =A020 =A0 0 =A0601m 211m 1464 S 28.3 0.9 115:1=
0.62 ceph-osd
>>>
>>> And I have hit our warning again:
>>>
>>> [223560.970713] ------------[ cut here ]------------
>>> [223560.976043] WARNING: at fs/btrfs/inode.c:2118
>>> btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
>>> [223560.985411] Hardware name: ProLiant DL180 G6
>>> [223560.990491] Modules linked in: btrfs zlib_deflate libcrc32c sun=
rpc
>>> bonding ipv6 sg serio_raw pcspkr ghes hed iTCO_wdt iTCO_vendor_supp=
ort
>>> i7core_edac edac_core ixgbe dca mdio iomemory_vsl(P) hpsa squashfs
>>> [last unloaded: scsi_wait_scan]
>>> [223561.014748] Pid: 2079, comm: ceph-osd Tainted: P
>>> 3.0.6-1.fits.9.el6.x86_64 #1
>>> [223561.023874] Call Trace:
>>> [223561.026738] =A0[<ffffffff8106344f>] warn_slowpath_common+0x7f/0=
xc0
>>> [223561.033564] =A0[<ffffffff810634aa>] warn_slowpath_null+0x1a/0x2=
0
>>> [223561.040272] =A0[<ffffffffa0282120>] btrfs_orphan_commit_root+0x=
b0/0xc0 [btrfs]
>>> [223561.048278] =A0[<ffffffffa027ce55>] commit_fs_roots+0xc5/0x1b0 =
[btrfs]
>>> [223561.055534] =A0[<ffffffff8154c231>] ? mutex_lock+0x31/0x60
>>> [223561.061666] =A0[<ffffffffa027ddbe>]
>>> btrfs_commit_transaction+0x3ce/0x820 [btrfs]
>>> [223561.069876] =A0[<ffffffffa027d1b8>] ? wait_current_trans+0x28/0=
x110 [btrfs]
>>> [223561.077582] =A0[<ffffffffa027e325>] ? join_transaction+0x25/0x2=
50 [btrfs]
>>> [223561.085065] =A0[<ffffffff81086410>] ? wake_up_bit+0x40/0x40
>>> [223561.091251] =A0[<ffffffffa025a329>] btrfs_sync_fs+0x59/0xd0 [bt=
rfs]
>>> [223561.098187] =A0[<ffffffffa02abc65>] btrfs_ioctl+0x495/0xd50 [bt=
rfs]
>>> [223561.105120] =A0[<ffffffff8125ed20>] ? inode_has_perm+0x30/0x40
>>> [223561.111575] =A0[<ffffffff81261a2c>] ? file_has_perm+0xdc/0xf0
>>> [223561.117924] =A0[<ffffffff8117086a>] do_vfs_ioctl+0x9a/0x5a0
>>> [223561.124072] =A0[<ffffffff81170e11>] sys_ioctl+0xa1/0xb0
>>> [223561.129842] =A0[<ffffffff81555702>] system_call_fastpath+0x16/0=
x1b
>>> [223561.136699] ---[ end trace 176e8be8996f25f6 ]---
>>
>> [ Not sending this to the lists, as the attachment is large ].
>>
>> I've spent a little time to do some tracing with ftrace. Its output
>> seems to be right (at least as far as I can tell). I hope that its
>> output can give you an insight on whats going on.
>>
>> The interesting PIDs in the trace are:
>>
>> =A05502 root =A0 =A0 =A020 =A0 0 =A0 =A0 0 =A0 =A00 =A0 =A00 S 33.6 =
0.0 118:28.37 btrfs-endio-wri
>> =A05518 root =A0 =A0 =A020 =A0 0 =A0 =A0 0 =A0 =A00 =A0 =A00 S 29.3 =
0.0 41:23.58 btrfs-endio-wri
>> =A08059 root =A0 =A0 =A020 =A0 0 =A0400m =A048m 2756 S =A08.0 =A00.2=
 =A0 8:31.56 ceph-osd
>> =A07993 root =A0 =A0 =A020 =A0 0 =A0401m =A041m 2808 S 13.6 =A00.2 =A0=
 7:58.38 ceph-osd
>>
>
> [ adding linux-btrfs again ]
>
> I've been digging into this a bit further:
>
> Attached is another ftrace report that I've filtered for "btrfs_*"
> calls and limited to CPU0 (this is where PID 5502 was running).
>
> From what I can see there is a lot of time consumed in
> btrfs_reserve_extent(). I this normal?

Sorry for spamming, but in the meantime I'm almost certain that the
problem is inside find_free_extent (called from btrfs_reserve_extent).

When I'm running ftrace for a sample period of 10s my system is
wasting a total of 4,2 seconds inside find_free_extent(). Each call to
find_free_extent() is taking an average of 4 milliseconds to complete.
On a recently rebooted system this is only 1-2 us!

I'm not sure if the problem is occurring suddenly or slowly over time.
(At the moment I suspect that its occurring suddenly, but I still have
to investigate this).

Thanks,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 08/14] Revert "KVM: PPC: Add support for explicit HIOR
From: Avi Kivity @ 2011-10-31 13:30 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti
In-Reply-To: <1320047596-20577-9-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> This reverts commit 11d7596e18a712dc3bc29d45662ec111fd65946b. It exceeded
> the padding on the SREGS struct, rendering the ABI backwards-incompatible.

Can't find the commit hash.  Please use hashes from the Linus tree when
possible.

This needs to be backported?  To which trees?

-- 
error compiling committee.c: too many arguments to function


^ permalink raw reply

* Re: [PATCH 08/14] Revert "KVM: PPC: Add support for explicit HIOR setting"
From: Avi Kivity @ 2011-10-31 13:30 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti
In-Reply-To: <1320047596-20577-9-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> This reverts commit 11d7596e18a712dc3bc29d45662ec111fd65946b. It exceeded
> the padding on the SREGS struct, rendering the ABI backwards-incompatible.

Can't find the commit hash.  Please use hashes from the Linus tree when
possible.

This needs to be backported?  To which trees?

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply

* [U-Boot] [PATCH] Powerpc/DIU: Fixed the 800x600 and 1024x768 resolution bug
From: Tabi Timur-B04825 @ 2011-10-31 13:31 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1320041994-28675-1-git-send-email-Chang-Ming.Huang@freescale.com>

On Mon, Oct 31, 2011 at 1:19 AM,  <Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> When the resolution is set to 800x600 and 1024x768,
> but, the driver will use 1280x1024 resolution to set the DIU register
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>

Acked-by: Timur Tabi <timur@freescale.com>

Thanks, Jerry.  I'm amazed that I didn't notice this mistake earlier.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: [meta-efl][meta-oe 11/12] systemd-serialgetty: use better default SERIAL_CONSOLE
From: Martin Jansa @ 2011-10-31 13:25 UTC (permalink / raw)
  To: openembedded-devel
In-Reply-To: <j8lunf$7vb$6@dough.gmane.org>

On Mon, Oct 31, 2011 at 11:53 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Op 29-10-11 12:29, Martin Jansa schreef:
>> * having /dev/ttySO fails with: | ln: failed to create symbolic link
>> `/OE/shr-core/tmp/work/nokia900-oe-linux-gnueabi/systemd-serialgetty-1.0-r0/image/etc/systemd/system/getty.target.wants/serial-getty@/dev/ttyS0.service':
>>
>>
> No such file or directory
>>
>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> ---
>> .../recipes-core/systemd/systemd-serialgetty.bb    |    2 +- 1 files
>> changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta-oe/recipes-core/systemd/systemd-serialgetty.bb
>> b/meta-oe/recipes-core/systemd/systemd-serialgetty.bb index
>> 86d833e..9294869 100644 ---
>> a/meta-oe/recipes-core/systemd/systemd-serialgetty.bb +++
>> b/meta-oe/recipes-core/systemd/systemd-serialgetty.bb @@ -2,7 +2,7 @@
>> DESCRIPTION = "Systemd serial config" LICENSE = "GPLv2+" LIC_FILES_CHKSUM
>> = "file://${WORKDIR}/LICENSE;md5=751419260aa954499f7abaabaa882bbe"
>>
>> -SERIAL_CONSOLE ?= "115200 /dev/ttyS0" +SERIAL_CONSOLE ?= "115200 ttyS0"
>>
>> SRC_URI = "file://LICENSE \ file://serial-getty@.service"
>
> Missing PR bump

Nobody without SERIAL_CONSOLE already overwritten could build it
before to have old binary package in feed (because it fails) and those
with SERIAL_CONSOLE overwritten won't be influenced by change of
default value and binary package won't change for them too. That's why
PR bump was missing..

But to make you happy added in branch :).

Cheers,

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iD8DBQFOrn4vMkyGM64RGpERAkzGAJ42j+LXz7GZQfUCtdrk2hgzBjuhDwCdHs6q
> UjxgP+htyH+rTcU7/oPfikw=
> =jTYz
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



^ permalink raw reply

* 1.0 Hard Freeze Logistics
From: Anthony Liguori @ 2011-10-31 13:28 UTC (permalink / raw)
  To: qemu-devel, kvm-devel

Hi,

Here are the logistics for the upcoming 1.0 hard freeze.  All dates are 
reflected in the wiki[1].

If you're a contributor and you've sent a series before the soft freeze 
deadline, you've already done everything you need to do so sit back and enjoy 
gorge yourself on Halloween candy.

If you're a submaintainer, the deadline for PULL requests for 1.0 hard freeze 
will be EOD tomorrow (May 1st).

I encourage all submaintainers to spend today and tomorrow reviewing any 
outstanding patches on the mailing list.  I will do the same.

Once everything is processed, I'll update VERSION, and tag v1.0-rc0.  I will not 
upload a -rc0 tarball since this is basically a git snapshot.  Unlike previous 
releases, we will do this stable development in HEAD.

Our first release candidate will be tagged and released on November 7th (next 
Tuesday).  I'll do the release that Monday evening so that the -rc1 build is 
available for out Test Day[2].

To make the Test Day more successful, please sign up to test a specific area on 
the Test[3] wiki page.

We have a fairly long -rc cycle for this release so I expect submaintainers will 
continue to maintain patches in their tree.  I also think it would be good to 
set up a -next staging tree but we can discuss that more in another thread.

[1] http://wiki.qemu.org/Planning/1.0
[2] http://mid.gmane.org/4EA94D53.3000707@redhat.com
[3] http://wiki.qemu.org/Planning/1.0/Testing

Regards,

Anthony Liguori


^ permalink raw reply

* [Qemu-devel] 1.0 Hard Freeze Logistics
From: Anthony Liguori @ 2011-10-31 13:28 UTC (permalink / raw)
  To: qemu-devel, kvm-devel

Hi,

Here are the logistics for the upcoming 1.0 hard freeze.  All dates are 
reflected in the wiki[1].

If you're a contributor and you've sent a series before the soft freeze 
deadline, you've already done everything you need to do so sit back and enjoy 
gorge yourself on Halloween candy.

If you're a submaintainer, the deadline for PULL requests for 1.0 hard freeze 
will be EOD tomorrow (May 1st).

I encourage all submaintainers to spend today and tomorrow reviewing any 
outstanding patches on the mailing list.  I will do the same.

Once everything is processed, I'll update VERSION, and tag v1.0-rc0.  I will not 
upload a -rc0 tarball since this is basically a git snapshot.  Unlike previous 
releases, we will do this stable development in HEAD.

Our first release candidate will be tagged and released on November 7th (next 
Tuesday).  I'll do the release that Monday evening so that the -rc1 build is 
available for out Test Day[2].

To make the Test Day more successful, please sign up to test a specific area on 
the Test[3] wiki page.

We have a fairly long -rc cycle for this release so I expect submaintainers will 
continue to maintain patches in their tree.  I also think it would be good to 
set up a -next staging tree but we can discuss that more in another thread.

[1] http://wiki.qemu.org/Planning/1.0
[2] http://mid.gmane.org/4EA94D53.3000707@redhat.com
[3] http://wiki.qemu.org/Planning/1.0/Testing

Regards,

Anthony Liguori

^ permalink raw reply

* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Gilles Chanteperdrix @ 2011-10-31 13:33 UTC (permalink / raw)
  To: Łukasz Sacha; +Cc: xenomai
In-Reply-To: <CAAeYjMnGFw8GZEkb_qUoa_wxoCzmNLa=+E_bfZESuQ9TPS8_nw@domain.hid>

On 10/31/2011 02:23 PM, Łukasz Sacha wrote:
> I used the toolchain from codesourcery
> (http://www.codesourcery.com/sgpp/lite/arm/portal/package3696/public/arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2).
> The one downloaded from the ubuntu repos behaves the same way.

Something is broken in you environment, like an environment variable set
or a wrapper script intercepting the arm-none-linux-gnueabi-gcc command.
Because codesourey toolchains work, there is no doubt about that. 2008q3
is a bit old, but it works, no matter the number of -march=armv4t on the
command line.

-- 
                                                                Gilles.



^ permalink raw reply

* Re: Lock in the ironlake_panel_vdd_work()
From: Daniel Vetter @ 2011-10-31 13:34 UTC (permalink / raw)
  To: Konstantin Belousov; +Cc: intel-gfx
In-Reply-To: <20111031130133.GJ50300@deviant.kiev.zoral.com.ua>

On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> I have a question about ironlake_panel_vdd_work(). Should it use
> the device struct_mutex, or need it to be the mode_config.mutex
> instead ?

Yeah. This was actually flagged in review by Chris and me, but seems to
have been lost in the merge. Keith?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

^ permalink raw reply

* Re: [patch 07/66] btrfs: clear_extent_bit error push-up
From: Jeff Mahoney @ 2011-10-31 13:34 UTC (permalink / raw)
  To: Chris Mason, Ilya Dryomov, Jeff Mahoney, David Sterba,
	Linux Btrfs
In-Reply-To: <20111031130050.GC4468@shiny>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2011 09:00 AM, Chris Mason wrote:
> On Mon, Oct 31, 2011 at 02:30:42PM +0200, Ilya Dryomov wrote:
>> On Wed, Oct 26, 2011 at 12:13:46PM -0400, Jeff Mahoney wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 10/26/2011 12:09 PM, David Sterba wrote:
>>>> On Wed, Oct 26, 2011 at 11:18:42AM -0400, Jeff Mahoney
>>>> wrote:
>>>>>>> extent_io_tree *tree, u64 start, u64 end, -
>>>>>>> gfp_t mask); +		       gfp_t mask) __must_check;
>>>>>> ^^^^^^^^^^^^ shouldn't this be placed at the beginning of
>>>>>> the prototype?
>>>>> 
>>>>> I don't see why that would need to be the case. It needs to
>>>>> be at the beginning of the prototype if it's the actual
>>>>> function definition but not when it's a prototype.
>>>> 
>>>> I'm not aware of a general recommendation, but the
>>>> __must_check is related to return value and makes sense to
>>>> place it there. There is no other instance of __must_check
>>>> placed at the end of declaratin/definition so I'm applying
>>>> the "be consistent with surrounding code" rule.
>>> 
>>> Putting it at the beginning means indenting the entire
>>> prototype, which I'm not a fan of.
>>> 
>>> - -Jeff
>> 
>> I think it would be much better to put it at the beginning.  For
>> one it's conventional and the rest of the kernel puts it at the
>> beginning. The other, and much more important, thing is that it
>> greatly confuses C indexing tools like cscope.  Now you could
>> argue that those tools' regexes should be tweaked but since it's
>> just a matter of taste why don't put it at the beginning ?
> 
> The rest of the kernel seems to use the beginning.  I don't really
> have a preference, but it's good to use the same standard as the
> rest of the kernel.
> 
> (Sorry Jeff)

Ok. I'll adjust. Thanks for weighing in.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOrqP5AAoJEB57S2MheeWynmgP/33qFEMZcq6AiXp+1JYBwWNu
W725iBRAI1t5cnp7Pgj5Xv+2iccP14lG8dhECBR3g0+xcFI06XetE88jqd3NKPx7
vsKSAt7Txi33NkaihfUPTL07e8HiPgJ9S4MycJ5pZyLCAfmSCbd6NlenZOrsopft
7HVVZKOjDNCSPOjPFGO3NGdaOapfdEkHlImRabpxJQTCNqdrJGCN0+2to30PKQ1Z
Ss2o1tmLdFt+RVSQP9jJ9+zdLnlxqjGMXpI0C103SP+T7GmUJD4XkamPfpMfXNKv
tCHHepRHsqMTERjVXdyu46+Xu0jHfADYIeea/2fXi2XMy88IIsWT/UC3eyeXHaJP
VmykOMnKzcw45r3v1AnAjZ2yqIEwWeGtwz1yXW8vKCALmHrrc+XyI5cRK59jSltf
I/+ghDBw8SycN7e/b+82HCc68VJFoa1vBN4nvvOLrkDiraLwcMgvQvUpdS5vuvSP
aqwhqMtu7qjdw+DxN7oGHEbFzdpIuiHSfAHvW7W4a/SnuRJXqzLMFgqNQ4gyjLAl
6yv/YZ+FqDC2qupZ5Nu6mZXubWI5oEF9p+E0xCTF4NHbbG1rUnnsVTU/xEmZQhcf
2VTZ8+R7g2i61WYxRj9kRZpDAi3zbhMojtN78C2y9pejHDA07FyyTp2vXnbcX7/e
EnsiEPPvcxsUbPH8/osE
=aG23
-----END PGP SIGNATURE-----

^ permalink raw reply

* Re: [Qemu-devel] [PATCH v9 1/4] block: add the block queue support
From: Stefan Hajnoczi @ 2011-10-31 13:35 UTC (permalink / raw)
  To: Zhi Yong Wu; +Cc: kwolf, qemu-devel, stefanha
In-Reply-To: <1319796143-9061-2-git-send-email-wuzhy@linux.vnet.ibm.com>

On Fri, Oct 28, 2011 at 11:02 AM, Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> wrote:
> +static void bdrv_io_limits_skip_set(void *opaque,
> +                                    BlockAPIType co_type,
> +                                    bool cb_skip,
> +                                    bool limit_skip) {
> +    RwCo *rwco;
> +    BlockDriverAIOCBCoroutine *aioco;
> +
> +    if (co_type == BDRV_API_SYNC) {
> +        rwco = opaque;
> +        rwco->limit_skip = limit_skip;
> +    } else if (co_type == BDRV_API_ASYNC) {
> +        aioco = opaque;
> +        aioco->cb_skip = cb_skip;
> +        aioco->limit_skip = limit_skip;
> +    } else {
> +        abort();
> +    }
> +}

The main question I have about this series is why have different cases
for sync, aio, and coroutines?  Perhaps I'm missing something but this
should all be much simpler.

All read/write requests are processed in a coroutine
(bdrv_co_do_readv()/bdrv_co_do_writev()).  That is the place to
perform I/O throttling.  Throttling should not be aware of sync, aio,
vs coroutines.

Since all requests have coroutines you could use CoQueue and the
actual queue waiting code in bdrv_co_do_readv()/bdrv_co_do_writev()
becomes:

if (bdrv_exceeds_io_limit(bs, sector_num, qiov, is_write)) {
    qemu_co_queue_wait(&bs->throttled_reqs);

    /* Wait until this request is allowed to start */
    while (bdrv_exceeds_io_limit(bs, sector_num, qiov, is_write)) {
        /* Re-inserting at the head of the CoQueue is equivalent to
         * the queue->flushing/queue->limit_exceeded behavior in your
         * patch.
         */
        qemu_co_queue_wait_insert_head(&bs->throttled_reqs);
    }
}

I think block/blk-queue.h isn't needed if you use the existing CoQueue
structure.

This is the main point I want to raise, just a few minor comments
below which may not be relevant if you can drop BlockQueue.

> +static int qemu_block_queue_handler(BlockQueueAIOCB *request)
> +{
> +    int ret;
> +
> +    BlockDriverState *bs = request->common.bs;
> +    assert(bs);
> +
> +    if (bs->io_limits_enabled) {

I'm not sure why the BlockQueue needs to reach into BlockDriverState.
Now BlockDriverState and BlockQueue know about and depend on each
other.  It's usually nicer to keep the relationship unidirectional, if
possible.

> +        ret = request->handler(request->common.bs, request->sector_num,
> +                               request->nb_sectors, request->qiov,
> +                               request, request->co_type);
> +    } else {
> +        if (request->co_type == BDRV_API_CO) {
> +            qemu_coroutine_enter(request->co, request->cocb);
> +        } else {
> +            printf("%s, req: %p\n", __func__, (void *)request);

Debug output should be removed.

> +            bdrv_io_limits_issue_request(request, request->co_type);
> +        }
> +
> +        ret = BDRV_BLKQ_DEQ_PASS;
> +    }
> +
> +    return ret;
> +}
> +
> +void qemu_block_queue_submit(BlockQueue *queue, BlockDriverCompletionFunc *cb)
> +{
> +    BlockQueueAIOCB *request;
> +    queue->flushing = true;
> +
> +    /*QTAILQ_FOREACH_SAFE(request, &queue->requests, entry, next) {*/

Commented out code should be removed.

> +    while (!QTAILQ_EMPTY(&queue->requests)) {
> +        int ret = 0;
> +
> +        request = QTAILQ_FIRST(&queue->requests);
> +        QTAILQ_REMOVE(&queue->requests, request, entry);
> +        queue->limit_exceeded = false;
> +        ret = qemu_block_queue_handler(request);
> +        if (ret == -EIO) {
> +            cb(request, -EIO);
> +            break;
> +        } else if (ret == BDRV_BLKQ_ENQ_AGAIN) {
> +            QTAILQ_INSERT_HEAD(&queue->requests, request, entry);
> +            break;
> +        } else if (ret == BDRV_BLKQ_DEQ_PASS) {
> +            cb(request, 0);
> +        }

What if ret is not -EIO, BDRV_BLKQ_ENQ_AGAIN, or BDRV_BLKQ_DEQ_PASS?
I think the -EIO case should be the default that calls cb(request,
ret).

> +    }
> +
> +    printf("%s, leave\n", __func__);

Debug code should be removed.

Stefan

^ permalink raw reply

* RE: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Ajay Pillai @ 2011-10-31 13:35 UTC (permalink / raw)
  To: Anderson Lizardo, Ganir, Chen
  Cc: Luiz Augusto von Dentz, Mat Martineau, Claudio Takahasi,
	linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
	ingas@codeaurora.org
In-Reply-To: <CAJdJm_M0cK5YzpHeWhjLdm+Tekej3nGue_Dc44nT-Ba6Fo7S+A@mail.gmail.com>

Hi Anderson,
Hello Chen,

> What about writing the value? Should we allow the user to set the value with either Write request/Write Command/Write signed or do we >really want to keep that internal (like read/read blob) ?

>Again, If I were to implement it, I would stick with the core spec requirements, and checking Characteristic Properties and the link >encryption status for deciding which operation to use. But if you really think it is useful to allow D-Bus clients "break" spec >requirements some times, you can provide this control. This particular detail is not my main concern :).


Can we detail out the "write" API design once again, please? There has been too much discussion and hence I am not sure, which way it is going.

There are two main aspects to write"

1) The write mechanism - 
	a) Do we do a setproperty() or do we add a new API writeValue()?
	b) Is the method blocking or non-blocking?
	c) If non-blocking,what is the mechanism like? 
My understanding - if the write is called while the connection is not active, then the value is going to be buffered in BlueZ while BlueZ tries to get the connection up. When the connection comes up, after the write operation is complete, BlueZ will emit a signal indicating that it is written.

2) The choice of write operation - Does it lie within BlueZ or is it given to DBUS Apps. I guess Anderson is okay with giving some control to the DBUS App.
	a) write without response, write with response, signed write without response - 
I believe the DBUS App must be allowed to indicate its preference among these to BlueZ. BlueZ must be able to meet this preference in most of the cases, but in cases where it cannot, BlueZ must throw an error. It would in most cases be a wrong request from App (using signed write on a long characteristic, for instance) 
	b) Write long characteristics value 
This, I believe, is a value add to Apps, if done autonomously within BlueZ.
	c) reliable write of one characteristic
Not covered in this discussion so far. But worth having a separate API like writeReliable(offset, value, {"prepare","execute"})?
	d) reliable write used for atomic write of multiple characteristics
Not covered in this discussion so far. Same API as above. But an "execute" operation on any char object will do complete the reliable write operation.

Regarding reliable writes, we will need to figure out a state machine within BlueZ that blocks out other operations on a remote server during a prepare-execute cycle and also an exit criteria from that "block-other-operations" state to cater to Aps that disappear after doing a "prepare".


Thank you
ajay


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

^ permalink raw reply

* Re: [PATCH 09/14] KVM: PPC: Add generic single register ioctls
From: Avi Kivity @ 2011-10-31 13:36 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti, Jan Kiszka
In-Reply-To: <1320047596-20577-10-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> Right now we transfer a static struct every time we want to get or set
> registers. Unfortunately, over time we realize that there are more of
> these than we thought of before and the extensibility and flexibility of
> transferring a full struct every time is limited.
>
> So this is a new approach to the problem. With these new ioctls, we can
> get and set a single register that is identified by an ID. This allows for
> very precise and limited transmittal of data. When we later realize that
> it's a better idea to shove over multiple registers at once, we can reuse
> most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
> interface.
>
> The only downpoint I see to this one is that it needs to pad to 1024 bits
> (hardware is already on 512 bit registers, so I wanted to leave some room)
> which is slightly too much for transmitting only 64 bits. But if that's all
> the tradeoff we have to do for getting an extensible interface, I'd say go
> for it nevertheless.

Do we want this for x86 too?  How often do we want just one register?

>  
> +4.64 KVM_SET_ONE_REG
> +
> +Capability: KVM_CAP_ONE_REG
> +Architectures: all
> +Type: vcpu ioctl
> +Parameters: struct kvm_one_reg (in)
> +Returns: 0 on success, negative value on failure
> +
> +struct kvm_one_reg {
> +       __u64 id;

would be better to have a register set (in x86 terms,
gpr/x86/sse/cr/xcr/msr/special) and an ID within the set.  __u64 is
excessive, I hope.

> +       union {
> +               __u8 reg8;
> +               __u16 reg16;
> +               __u32 reg32;
> +               __u64 reg64;
> +               __u8 reg128[16];
> +               __u8 reg256[32];
> +               __u8 reg512[64];
> +               __u8 reg1024[128];
> +       } u;
> +};
> +
> +Using this ioctl, a single vcpu register can be set to a specific value
> +defined by user space with the passed in struct kvm_one_reg. There can
> +be architecture agnostic and architecture specific registers. Each have
> +their own range of operation and their own constants and width. To keep
> +track of the implemented registers, find a list below:
> +
> +  Arch  |       Register        | Width (bits)
> +        |                       |
> +
>

One possible issue is that certain register have mutually exclusive
values, so you may need to issue multiple calls to get the right
sequence.  You probably don't have that on ppc.

-- 
error compiling committee.c: too many arguments to function


^ permalink raw reply

* Re: [PATCH 09/14] KVM: PPC: Add generic single register ioctls
From: Avi Kivity @ 2011-10-31 13:36 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti, Jan Kiszka
In-Reply-To: <1320047596-20577-10-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> Right now we transfer a static struct every time we want to get or set
> registers. Unfortunately, over time we realize that there are more of
> these than we thought of before and the extensibility and flexibility of
> transferring a full struct every time is limited.
>
> So this is a new approach to the problem. With these new ioctls, we can
> get and set a single register that is identified by an ID. This allows for
> very precise and limited transmittal of data. When we later realize that
> it's a better idea to shove over multiple registers at once, we can reuse
> most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
> interface.
>
> The only downpoint I see to this one is that it needs to pad to 1024 bits
> (hardware is already on 512 bit registers, so I wanted to leave some room)
> which is slightly too much for transmitting only 64 bits. But if that's all
> the tradeoff we have to do for getting an extensible interface, I'd say go
> for it nevertheless.

Do we want this for x86 too?  How often do we want just one register?

>  
> +4.64 KVM_SET_ONE_REG
> +
> +Capability: KVM_CAP_ONE_REG
> +Architectures: all
> +Type: vcpu ioctl
> +Parameters: struct kvm_one_reg (in)
> +Returns: 0 on success, negative value on failure
> +
> +struct kvm_one_reg {
> +       __u64 id;

would be better to have a register set (in x86 terms,
gpr/x86/sse/cr/xcr/msr/special) and an ID within the set.  __u64 is
excessive, I hope.

> +       union {
> +               __u8 reg8;
> +               __u16 reg16;
> +               __u32 reg32;
> +               __u64 reg64;
> +               __u8 reg128[16];
> +               __u8 reg256[32];
> +               __u8 reg512[64];
> +               __u8 reg1024[128];
> +       } u;
> +};
> +
> +Using this ioctl, a single vcpu register can be set to a specific value
> +defined by user space with the passed in struct kvm_one_reg. There can
> +be architecture agnostic and architecture specific registers. Each have
> +their own range of operation and their own constants and width. To keep
> +track of the implemented registers, find a list below:
> +
> +  Arch  |       Register        | Width (bits)
> +        |                       |
> +
>

One possible issue is that certain register have mutually exclusive
values, so you may need to issue multiple calls to get the right
sequence.  You probably don't have that on ppc.

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply

* Re: [Qemu-devel] Performance of USB2.0
From: Til Obes @ 2011-10-31 13:37 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <4EAE98A4.6000700@redhat.com>

Hi.

Am 31.10.2011 13:46, schrieb Hans de Goede:
> If you're using libvirt to start qemu, then it will also pass
> -usb to qemu, so you will have both a usb-1 (uhci) and a usb-2
> (ehci) controller inside your vm, since your hostdev xml code does
> not specify a bus the hostdev will likely get connected to the first
> usb bus which is the one attached to the uhci controller, although
> your lsusb output suggests otherwise (to my surprise).
 >
 > So assuming that I'm reading your lsusb output correct, the device
 > does seem to be connected to the virtual ehci controller rather then
 > to the virtual uhci controller, which more or less rules that out
 > as the cause.


The kernel output says:
router:~# dmesg|grep usb
[    0.418314] usbcore: registered new interface driver usbfs
[    0.418401] usbcore: registered new interface driver hub
[    0.419256] usbcore: registered new device driver usb
[    0.488137] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.488144] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[    0.488150] usb usb1: Product: EHCI Host Controller
[    0.488155] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 ehci_hcd
[    0.488160] usb usb1: SerialNumber: 0000:00:07.0
[    0.488437] usb usb1: configuration #1 chosen from 1 choice
[    1.155604] usb 1-1: new high speed USB device using ehci_hcd and 
address 2
[    1.665760] usb 1-1: New USB device found, idVendor=9710, idProduct=7830
[    1.665781] usb 1-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[    1.665784] usb 1-1: Product: USB-MAC Controller
[    1.665786] usb 1-1: Manufacturer: Moschip Semiconductor
[    1.665787] usb 1-1: SerialNumber: 3b0c00d1
[    1.665886] usb 1-1: configuration #1 chosen from 1 choice
[    1.877906] usb 1-1: applying rev.C fixup
[    1.890249] usb 1-1: applying rev.C fixup
[    1.905011] eth2: register 'MOSCHIP usb-ethernet driver' at 
usb-0000:00:07.0-1, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:0c:00:d1
[    1.905028] usbcore: registered new interface driver MOSCHIP 
usb-ethernet driver

So it should work with my configuration...


> This means that the likely cause is just that usb emulation / pass
> through causes quite a bit of overhead, which is not unexpected since
> both the usb protocol and the ehci controller interface are both quite
> hard to emulate.

But 6Mbit from 480MBit is quite low, at least 100MBit should be 
realistic or? How can i debug this?

> It is likely better to just use the usb nic directly from the host,
> and then pass it through the virtio-net using bridging.

Well the cable modem is only talking to the first mac address it gets.
In my setup eth1 is the bridged nic to the cable box and it isnt
working. Any suggestions how to solve this?

Regards Til

^ permalink raw reply

* Re: [PATCH] cache align vm_stat
From: Dimitri Sivanich @ 2011-10-31 13:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Lameter, linux-kernel, linux-mm, David Rientjes,
	Andi Kleen, Mel Gorman
In-Reply-To: <20111028155456.20f3d611.akpm@linux-foundation.org>

On Fri, Oct 28, 2011 at 03:54:56PM -0700, Andrew Morton wrote:
> On Wed, 26 Oct 2011 21:31:46 -0500 (CDT)
> Christoph Lameter <cl@gentwo.org> wrote:
> 
> > On Mon, 24 Oct 2011, Dimitri Sivanich wrote:
> > 
> > > Avoid false sharing of the vm_stat array.
> 
> Did we have some nice machine-description and measurement results which
> can be included in the changelog?  Such things should always be
> included with a performace patch!
> 
Tests run on a 640 cpu UV system.

With 120 threads doing parallel writes, each to different tmpfs mounts:
No patch:		~300 MB/sec
With vm_stat alignment:	~430 MB/sec

^ permalink raw reply

* Re: [PATCH] cache align vm_stat
From: Dimitri Sivanich @ 2011-10-31 13:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Lameter, linux-kernel, linux-mm, David Rientjes,
	Andi Kleen, Mel Gorman
In-Reply-To: <20111028155456.20f3d611.akpm@linux-foundation.org>

On Fri, Oct 28, 2011 at 03:54:56PM -0700, Andrew Morton wrote:
> On Wed, 26 Oct 2011 21:31:46 -0500 (CDT)
> Christoph Lameter <cl@gentwo.org> wrote:
> 
> > On Mon, 24 Oct 2011, Dimitri Sivanich wrote:
> > 
> > > Avoid false sharing of the vm_stat array.
> 
> Did we have some nice machine-description and measurement results which
> can be included in the changelog?  Such things should always be
> included with a performace patch!
> 
Tests run on a 640 cpu UV system.

With 120 threads doing parallel writes, each to different tmpfs mounts:
No patch:		~300 MB/sec
With vm_stat alignment:	~430 MB/sec

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH 13/14] KVM: PPC: E500: Support hugetlbfs
From: Avi Kivity @ 2011-10-31 13:38 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti
In-Reply-To: <1320047596-20577-14-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> With hugetlbfs support emerging on e500, we should also support KVM
> backing its guest memory by it.
>
> This patch adds support for hugetlbfs into the e500 shadow mmu code.
>
>
> @@ -673,12 +674,31 @@ static inline void kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
>  				pfn &= ~(tsize_pages - 1);
>  				break;
>  			}
> +		} else if (vma && hva >= vma->vm_start &&
> +                           (vma->vm_flags & VM_HUGETLB)) {
> +			unsigned long psize = vma_kernel_pagesize(vma);
>

Leading spaces spotted.

-- 
error compiling committee.c: too many arguments to function


^ permalink raw reply

* Re: [PATCH 13/14] KVM: PPC: E500: Support hugetlbfs
From: Avi Kivity @ 2011-10-31 13:38 UTC (permalink / raw)
  To: Alexander Graf; +Cc: kvm-ppc, kvm list, Marcelo Tosatti
In-Reply-To: <1320047596-20577-14-git-send-email-agraf@suse.de>

On 10/31/2011 09:53 AM, Alexander Graf wrote:
> With hugetlbfs support emerging on e500, we should also support KVM
> backing its guest memory by it.
>
> This patch adds support for hugetlbfs into the e500 shadow mmu code.
>
>
> @@ -673,12 +674,31 @@ static inline void kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
>  				pfn &= ~(tsize_pages - 1);
>  				break;
>  			}
> +		} else if (vma && hva >= vma->vm_start &&
> +                           (vma->vm_flags & VM_HUGETLB)) {
> +			unsigned long psize = vma_kernel_pagesize(vma);
>

Leading spaces spotted.

-- 
error compiling committee.c: too many arguments to function

^ permalink raw reply

* Re: NFS4ERR_STALE_CLIENTID loop
From: Chuck Lever @ 2011-10-31 13:39 UTC (permalink / raw)
  To: David Flynn; +Cc: Myklebust, Trond, J. Bruce Fields, linux-nfs
In-Reply-To: <20111031132115.GJ2011@rd.bbc.co.uk>


On Oct 31, 2011, at 9:21 AM, David Flynn wrote:

> * Chuck Lever (chuck.lever@oracle.com) wrote:
>> David, what would help immensely is if you can find a reliable way of
>> reproducing this.  So far we have been unable to find a reproducer.
> 
> While i've managed to have problems with individual machines, that seem
> to fail at some random point of their own choosing, the most reliable
> way to produce problem for us to have a number of nodes updating various
> RRD files frequently.
> 
> Given that i haven't found a reliable and short method for reproducing
> it either, if we were to re-run the known case and capture all network
> traffic, would you be able to extract the relevant detail to generate a
> simulation?

A reproducer would be better for us [*], but I understand the arbitrary nature of the problem.  A network trace would be an excellent start.

Now, it would be interesting if in fact the problem occurs only when multiple clients interact with a server.  In that case, capture a full network trace with snoop on your server.  We'll worry about pruning the size of the trace once you have a clean capture.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

* - A reproducer allows us to perform internal-only tests at will, and it also can confirm we've got the problem properly fixed.



^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.