* [PATCH v3 7/7] net/virtio_user: enable multiqueue with vhost kernel
From: Jianfeng Tan @ 2017-01-04 3:59 UTC (permalink / raw)
To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>
With vhost kernel, to enable multiqueue, we need backend device
in kernel support multiqueue feature. Specifically, with tap
as the backend, as linux/Documentation/networking/tuntap.txt shows,
we check if tap supports IFF_MULTI_QUEUE feature.
And for vhost kernel, each queue pair has a vhost fd, and with a tap
fd binding this vhost fd. All tap fds are set with the same tap
interface name.
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
drivers/net/virtio/virtio_user/vhost_kernel.c | 69 +++++++++++++++++++++---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 1 +
2 files changed, 64 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c b/drivers/net/virtio/virtio_user/vhost_kernel.c
index bdb4af2..023bdf8 100644
--- a/drivers/net/virtio/virtio_user/vhost_kernel.c
+++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
@@ -206,6 +206,29 @@ prepare_vhost_memory_kernel(void)
(1ULL << VIRTIO_NET_F_CSUM))
static int
+tap_supporte_mq(void)
+{
+ int tapfd;
+ unsigned int tap_features;
+
+ tapfd = open(PATH_NET_TUN, O_RDWR);
+ if (tapfd < 0) {
+ PMD_DRV_LOG(ERR, "fail to open %s: %s",
+ PATH_NET_TUN, strerror(errno));
+ return -1;
+ }
+
+ if (ioctl(tapfd, TUNGETFEATURES, &tap_features) == -1) {
+ PMD_DRV_LOG(ERR, "TUNGETFEATURES failed: %s", strerror(errno));
+ close(tapfd);
+ return -1;
+ }
+
+ close(tapfd);
+ return tap_features & IFF_MULTI_QUEUE;
+}
+
+static int
vhost_kernel_ioctl(struct virtio_user_dev *dev,
enum vhost_user_request req,
void *arg)
@@ -213,6 +236,8 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
int i, ret = -1;
uint64_t req_kernel;
struct vhost_memory_kernel *vm = NULL;
+ int vhostfd;
+ unsigned int queue_sel;
PMD_DRV_LOG(INFO, "%s", vhost_msg_strings[req]);
@@ -232,15 +257,37 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
/* VHOST kernel does not know about below flags */
*(uint64_t *)arg &= ~VHOST_KERNEL_GUEST_OFFLOADS_MASK;
*(uint64_t *)arg &= ~VHOST_KERNEL_HOST_OFFLOADS_MASK;
+
+ *(uint64_t *)arg &= ~(1ULL << VIRTIO_NET_F_MQ);
}
- for (i = 0; i < VHOST_KERNEL_MAX_QUEUES; ++i) {
- if (dev->vhostfds[i] < 0)
- continue;
+ switch (req_kernel) {
+ case VHOST_SET_VRING_NUM:
+ case VHOST_SET_VRING_ADDR:
+ case VHOST_SET_VRING_BASE:
+ case VHOST_GET_VRING_BASE:
+ case VHOST_SET_VRING_KICK:
+ case VHOST_SET_VRING_CALL:
+ queue_sel = *(unsigned int *)arg;
+ vhostfd = dev->vhostfds[queue_sel / 2];
+ *(unsigned int *)arg = queue_sel % 2;
+ PMD_DRV_LOG(DEBUG, "vhostfd=%d, index=%u",
+ vhostfd, *(unsigned int *)arg);
+ break;
+ default:
+ vhostfd = -1;
+ }
+ if (vhostfd == -1) {
+ for (i = 0; i < VHOST_KERNEL_MAX_QUEUES; ++i) {
+ if (dev->vhostfds[i] < 0)
+ continue;
- ret = ioctl(dev->vhostfds[i], req_kernel, arg);
- if (ret < 0)
- break;
+ ret = ioctl(dev->vhostfds[i], req_kernel, arg);
+ if (ret < 0)
+ break;
+ }
+ } else {
+ ret = ioctl(vhostfd, req_kernel, arg);
}
if (!ret && req_kernel == VHOST_GET_FEATURES) {
@@ -250,6 +297,12 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
*/
*((uint64_t *)arg) |= VHOST_KERNEL_GUEST_OFFLOADS_MASK;
*((uint64_t *)arg) |= VHOST_KERNEL_HOST_OFFLOADS_MASK;
+
+ /* vhost_kernel will not declare this feature, but it does
+ * support multi-queue.
+ */
+ if (tap_supporte_mq())
+ *(uint64_t *)arg |= (1ull << VIRTIO_NET_F_MQ);
}
if (vm)
@@ -329,6 +382,7 @@ vhost_kernel_enable_queue_pair(struct virtio_user_dev *dev,
TUN_F_TSO6 |
TUN_F_TSO_ECN |
TUN_F_UFO;
+ int req_mq = (dev->max_queue_pairs > 1);
vhostfd = dev->vhostfds[pair_idx];
@@ -382,6 +436,9 @@ vhost_kernel_enable_queue_pair(struct virtio_user_dev *dev,
goto error;
}
+ if (req_mq)
+ ifr.ifr_flags |= IFF_MULTI_QUEUE;
+
if (dev->ifname)
strncpy(ifr.ifr_name, dev->ifname, IFNAMSIZ);
else
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index c40b77e..2d9d989 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -93,6 +93,7 @@ virtio_user_kick_queue(struct virtio_user_dev *dev, uint32_t queue_sel)
state.num = vring->num;
dev->ops->send_request(dev, VHOST_USER_SET_VRING_NUM, &state);
+ state.index = queue_sel;
state.num = 0; /* no reservation */
dev->ops->send_request(dev, VHOST_USER_SET_VRING_BASE, &state);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/7] net/virtio_user: fix wrongly set features
From: Jianfeng Tan @ 2017-01-04 3:59 UTC (permalink / raw)
To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan, stable
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>
Before the commit 86d59b21468a ("net/virtio: support LRO"), features
in virtio PMD, is decided and properly set at device initialization
and will not be changed. But afterward, features could be changed in
virtio_dev_configure(), and will be re-negotiated if it's changed.
In virtio_user, device features is obtained at driver probe phase
only once, but we did not store it. So the added feature bits in
re-negotiation will fail.
To fix it, we store it down, and will be used to feature negotiation
either at device initialization phase or device configure phase.
Fixes: e9efa4d93821 ("net/virtio-user: add new virtual PCI driver")
CC: stable@dpdk.org
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 34 +++++++++++-------------
drivers/net/virtio/virtio_user/virtio_user_dev.h | 5 +++-
drivers/net/virtio/virtio_user_ethdev.c | 4 +--
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index e239e0e..0d7e17b 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -148,12 +148,13 @@ virtio_user_start_device(struct virtio_user_dev *dev)
/* Step 1: set features
* Make sure VHOST_USER_F_PROTOCOL_FEATURES is added if mq is enabled,
- * and VIRTIO_NET_F_MAC is stripped.
+ * VIRTIO_NET_F_MAC and VIRTIO_NET_F_CTRL_VQ is stripped.
*/
features = dev->features;
if (dev->max_queue_pairs > 1)
features |= VHOST_USER_MQ;
features &= ~(1ull << VIRTIO_NET_F_MAC);
+ features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
ret = vhost_user_sock(dev->vhostfd, VHOST_USER_SET_FEATURES, &features);
if (ret < 0)
goto error;
@@ -228,29 +229,26 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
}
if (vhost_user_sock(dev->vhostfd, VHOST_USER_GET_FEATURES,
- &dev->features) < 0) {
+ &dev->device_features) < 0) {
PMD_INIT_LOG(ERR, "get_features failed: %s", strerror(errno));
return -1;
}
if (dev->mac_specified)
- dev->features |= (1ull << VIRTIO_NET_F_MAC);
+ dev->device_features |= (1ull << VIRTIO_NET_F_MAC);
- if (!cq) {
- dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
- /* Also disable features depends on VIRTIO_NET_F_CTRL_VQ */
- dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_RX);
- dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
- dev->features &= ~(1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
- dev->features &= ~(1ull << VIRTIO_NET_F_MQ);
- dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
- } else {
- /* vhost user backend does not need to know ctrl-q, so
- * actually we need add this bit into features. However,
- * DPDK vhost-user does send features with this bit, so we
- * check it instead of OR it for now.
+ if (cq) {
+ /* device does not really need to know anything about CQ,
+ * so if necessary, we just claim to support CQ
*/
- if (!(dev->features & (1ull << VIRTIO_NET_F_CTRL_VQ)))
- PMD_INIT_LOG(INFO, "vhost does not support ctrl-q");
+ dev->device_features |= (1ull << VIRTIO_NET_F_CTRL_VQ);
+ } else {
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
+ /* Also disable features depends on VIRTIO_NET_F_CTRL_VQ */
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_RX);
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_MQ);
+ dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
}
if (dev->max_queue_pairs > 1) {
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index 33690b5..28fc788 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -46,7 +46,10 @@ struct virtio_user_dev {
uint32_t max_queue_pairs;
uint32_t queue_pairs;
uint32_t queue_size;
- uint64_t features;
+ uint64_t features; /* the negotiated features with driver,
+ * and will be sync with device
+ */
+ uint64_t device_features; /* supported features by device */
uint8_t status;
uint8_t mac_addr[ETHER_ADDR_LEN];
char path[PATH_MAX];
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 8cb983c..4a5a227 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -117,7 +117,7 @@ virtio_user_get_features(struct virtio_hw *hw)
{
struct virtio_user_dev *dev = virtio_user_get_dev(hw);
- return dev->features;
+ return dev->device_features;
}
static void
@@ -125,7 +125,7 @@ virtio_user_set_features(struct virtio_hw *hw, uint64_t features)
{
struct virtio_user_dev *dev = virtio_user_get_dev(hw);
- dev->features = features;
+ dev->features = features & dev->device_features;
}
static uint8_t
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/7] net/virtio_user: fix not properly reset device
From: Jianfeng Tan @ 2017-01-04 3:59 UTC (permalink / raw)
To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan, stable
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>
virtio_user is not properly reset when users call vtpci_reset(),
as it ignores VIRTIO_CONFIG_STATUS_RESET status in
virtio_user_set_status().
This might lead to initialization failure as it starts to re-init
the device before sending RESET messege to backend. Besides, previous
callfds and kickfds are not closed.
To fix it, we add support to disable virtqueues when it's set to
DRIVER OK status, and re-init fields in struct virtio_user_dev.
Fixes: e9efa4d93821 ("net/virtio-user: add new virtual PCI driver")
Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
CC: stable@dpdk.org
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 26 ++++++++++++++++--------
drivers/net/virtio/virtio_user_ethdev.c | 15 ++++++++------
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 0d7e17b..a38398b 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -182,7 +182,17 @@ virtio_user_start_device(struct virtio_user_dev *dev)
int virtio_user_stop_device(struct virtio_user_dev *dev)
{
- return vhost_user_sock(dev->vhostfd, VHOST_USER_RESET_OWNER, NULL);
+ uint32_t i;
+
+ for (i = 0; i < dev->max_queue_pairs * 2; ++i) {
+ close(dev->callfds[i]);
+ close(dev->kickfds[i]);
+ }
+
+ for (i = 0; i < dev->max_queue_pairs; ++i)
+ vhost_user_enable_queue_pair(dev->vhostfd, i, 0);
+
+ return 0;
}
static inline void
@@ -210,6 +220,8 @@ int
virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
int cq, int queue_size, const char *mac)
{
+ uint32_t i;
+
snprintf(dev->path, PATH_MAX, "%s", path);
dev->max_queue_pairs = queues;
dev->queue_pairs = 1; /* mq disabled by default */
@@ -218,6 +230,11 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
parse_mac(dev, mac);
dev->vhostfd = -1;
+ for (i = 0; i < VIRTIO_MAX_VIRTQUEUES * 2 + 1; ++i) {
+ dev->kickfds[i] = -1;
+ dev->callfds[i] = -1;
+ }
+
dev->vhostfd = vhost_user_setup(dev->path);
if (dev->vhostfd < 0) {
PMD_INIT_LOG(ERR, "backend set up fails");
@@ -264,13 +281,6 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
void
virtio_user_dev_uninit(struct virtio_user_dev *dev)
{
- uint32_t i;
-
- for (i = 0; i < dev->max_queue_pairs * 2; ++i) {
- close(dev->callfds[i]);
- close(dev->kickfds[i]);
- }
-
close(dev->vhostfd);
}
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 4a5a227..93f5b01 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -87,21 +87,24 @@ virtio_user_write_dev_config(struct virtio_hw *hw, size_t offset,
}
static void
-virtio_user_set_status(struct virtio_hw *hw, uint8_t status)
+virtio_user_reset(struct virtio_hw *hw)
{
struct virtio_user_dev *dev = virtio_user_get_dev(hw);
- if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
- virtio_user_start_device(dev);
- dev->status = status;
+ if (dev->status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
+ virtio_user_stop_device(dev);
}
static void
-virtio_user_reset(struct virtio_hw *hw)
+virtio_user_set_status(struct virtio_hw *hw, uint8_t status)
{
struct virtio_user_dev *dev = virtio_user_get_dev(hw);
- virtio_user_stop_device(dev);
+ if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
+ virtio_user_start_device(dev);
+ else if (status == VIRTIO_CONFIG_STATUS_RESET)
+ virtio_user_reset(hw);
+ dev->status = status;
}
static uint8_t
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] f2fs: fix small discards when se->valid_blocks is zero
From: Yunlong Song @ 2017-01-04 3:59 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: cm224.lee, yuchao0, chao, sylinux, bintian.wang, linux-fsdevel,
linux-f2fs-devel, linux-kernel
In-Reply-To: <20170104015510.GB16504@jaegeuk.local>
Hi Kim,
Although the blocks of that file will finally be discarded when it is not current segment any more and almost fully invalidate,
but the point is that the blocks of that file can only be discarded along with the whole segment now, which violates the meaning
of small discard. Look at the case I said in last mail, if the segment which owns the deleted file has no more changing after the file
deleting, and its validate blocks are perhaps over 95%, and it may not be easy to be selected as a gc victim. In this case, FTL can
not know the "file delete" on time, and the invalidate blocks of that file can not be discarded in FTL layer on time.
On 2017/1/4 9:55, Jaegeuk Kim wrote:
> Hi Yunlong,
>
> On 01/03, Yunlong Song wrote:
>> In the small discard case, when se->valid_blocks is zero, the add_discard_addrs
>> will directly return without __add_discard_entry. This will cause the file
>> delete have no small discard. The case is like this:
>>
>> 1. Allocate free 2M segment
>> 2. Write a file (size n blocks < 512) in that 2M segment, se->valid_blocks = n
>> 3. Delete that file, se->valid_blocks = 0, add_discard_addrs will return without
>> sending any discard of that file, and forever due to cur_map[i] ^ ckpt_map[i] =
>> 0 after that checkpoint
> During this checkpoint, that'll be discarded as a prefree segment, no?
> Note that, if this is a current segment, f2fs won't discard it until it is
> fully allocated.
>
> Thanks,
>
>> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
>> ---
>> fs/f2fs/segment.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 0738f48..8610f14 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -838,7 +838,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control *cpc)
>> return;
>>
>> if (!force) {
>> - if (!test_opt(sbi, DISCARD) || !se->valid_blocks ||
>> + if (!test_opt(sbi, DISCARD) ||
>> SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards)
>> return;
>> }
>> --
>> 1.8.5.2
> .
>
--
Thanks,
Yunlong Song
^ permalink raw reply
* Re: [PATCH] f2fs: fix small discards when se->valid_blocks is zero
From: Yunlong Song @ 2017-01-04 3:59 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: cm224.lee, yuchao0, chao, sylinux, bintian.wang, linux-fsdevel,
linux-f2fs-devel, linux-kernel
In-Reply-To: <20170104015510.GB16504@jaegeuk.local>
Hi Kim,
Although the blocks of that file will finally be discarded when it is not current segment any more and almost fully invalidate,
but the point is that the blocks of that file can only be discarded along with the whole segment now, which violates the meaning
of small discard. Look at the case I said in last mail, if the segment which owns the deleted file has no more changing after the file
deleting, and its validate blocks are perhaps over 95%, and it may not be easy to be selected as a gc victim. In this case, FTL can
not know the "file delete" on time, and the invalidate blocks of that file can not be discarded in FTL layer on time.
On 2017/1/4 9:55, Jaegeuk Kim wrote:
> Hi Yunlong,
>
> On 01/03, Yunlong Song wrote:
>> In the small discard case, when se->valid_blocks is zero, the add_discard_addrs
>> will directly return without __add_discard_entry. This will cause the file
>> delete have no small discard. The case is like this:
>>
>> 1. Allocate free 2M segment
>> 2. Write a file (size n blocks < 512) in that 2M segment, se->valid_blocks = n
>> 3. Delete that file, se->valid_blocks = 0, add_discard_addrs will return without
>> sending any discard of that file, and forever due to cur_map[i] ^ ckpt_map[i] =
>> 0 after that checkpoint
> During this checkpoint, that'll be discarded as a prefree segment, no?
> Note that, if this is a current segment, f2fs won't discard it until it is
> fully allocated.
>
> Thanks,
>
>> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
>> ---
>> fs/f2fs/segment.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 0738f48..8610f14 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -838,7 +838,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control *cpc)
>> return;
>>
>> if (!force) {
>> - if (!test_opt(sbi, DISCARD) || !se->valid_blocks ||
>> + if (!test_opt(sbi, DISCARD) ||
>> SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards)
>> return;
>> }
>> --
>> 1.8.5.2
> .
>
--
Thanks,
Yunlong Song
^ permalink raw reply
* Re: [PATCH] lib/librte_vhost: fix memory leak
From: Yuanhan Liu @ 2017-01-04 4:02 UTC (permalink / raw)
To: Yong Wang; +Cc: dev
In-Reply-To: <1483502275-18482-1-git-send-email-wang.yong19@zte.com.cn>
On Tue, Jan 03, 2017 at 10:57:55PM -0500, Yong Wang wrote:
> In function vhost_new_device(), current code dose not free 'dev'
> in "i == MAX_VHOST_DEVICE" condition statements. It will lead to a
> memory leak.
Nice catch!
Here are few minor stuff you might need pay attention to for future
contribution:
- a fix patch needs a fixline, like following
Fixes: 45ca9c6f7bc6 ("vhost: get rid of linked list for devices")
- the prefix for vhost lib is "vhost: ". And FYI, for PMD drivers, it's
'net/PMD_NAME', say 'net/virtio'.
For you convenience, I have fixed the two while applying. And thanks
for the fix.
Applied to dpdk-next-virtio.
--yliu
^ permalink raw reply
* Re: [PATCH] ASoC: intel: rt5640: add support for sound card found on HP Pavilion x2 10-p000
From: Vinod Koul @ 2017-01-04 4:02 UTC (permalink / raw)
To: Alexandrov Stanislav; +Cc: Alsa Devel, Pierre-Louis Bossart
In-Reply-To: <505f46a71aa53080da43f9c8abeb3b5d@nya.ai>
On Tue, Jan 03, 2017 at 11:40:04PM +0300, Alexandrov Stanislav wrote:
> Add support for rt5640 sound card found on HP Pavilion x2 10-p000
> tablet.
>
> Inside DSDT table there is record for this soundcard:
>
> Device (RTKC)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "10EC3276") // _HID: Hardware ID
> Name (_CID, "10EC3276") // _CID: Compatible ID
> Name (_DDN, "ALC3276") // _DDN: DOS Device Name
> Name (_SUB, "103C827C") // _SUB: Subsystem ID
> Name (_PR0, Package (0x01) // _PR0: Power Resources
> for D0
>
> original bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=187621
Hi,
Thanks for the patch, changes look okay, but they need to be split per
driver and you need to sign-off these changes.
See Documentation/process/submitting-patches.rst esp Section 11.
>
> ---
>
> diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
> index e29a6de..c5234b9 100644
> --- a/sound/soc/codecs/rt5640.c
> +++ b/sound/soc/codecs/rt5640.c
> @@ -2315,6 +2315,7 @@ static const struct acpi_device_id
> rt5640_acpi_match[] = {
> { "INT33CA", 0 },
> { "10EC5640", 0 },
> { "10EC5642", 0 },
> + { "10EC3276", 0 },
> { "INTCCFFD", 0 },
> { },
> };
> diff --git a/sound/soc/intel/atom/sst/sst_acpi.c
> b/sound/soc/intel/atom/sst/sst_acpi.c
> index f4d92bb..896ced2 100644
> --- a/sound/soc/intel/atom/sst/sst_acpi.c
> +++ b/sound/soc/intel/atom/sst/sst_acpi.c
> @@ -463,6 +463,8 @@ static struct sst_acpi_mach sst_acpi_chv[] = {
> /* some CHT-T platforms rely on RT5640, use Baytrail machine
> driver */
> {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin",
> "bytcr_rt5640", cht_quirk,
> &chv_platform_data },
> + {"10EC3276", "bytcr_rt5640", "intel/fw_sst_22a8.bin",
> "bytcr_rt5640", NULL,
> + &chv_platform_data },
>
> {},
> };
--
~Vinod
^ permalink raw reply
* [U-Boot] [PATCH RESEND v2 1/2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible
From: Vignesh R @ 2017-01-04 4:02 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAD6G_RQaOJzkskQnd-AXhYZV34iSpHRejOTZ4QwpN28dVDA=rA@mail.gmail.com>
On Tuesday 03 January 2017 07:40 PM, Jagan Teki wrote:
> On Tue, Jan 3, 2017 at 2:35 PM, R, Vignesh <vigneshr@ti.com> wrote:
>>
>>
>> On 12/21/2016 10:42 AM, Vignesh R wrote:
>>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>>> data interface writes until the last word of an indirect transfer
>>> otherwise indirect writes is known to fails sometimes. So, make sure
>>> that QSPI indirect writes are 32 bit sized except for the last write. If
>>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>>
>>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>>> for all boards that use Cadence QSPI driver.
>>>
>>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>> Reviewed-by: Marek Vasut <marex@denx.de>
>>
>> Gentle ping on the series...
>
> Please link to other one, I couldn't find it on patchwork.
>
Here are the two patches of the series:
https://patchwork.ozlabs.org/patch/707648/
https://patchwork.ozlabs.org/patch/707647/
--
Regards
Vignesh
^ permalink raw reply
* Re: [PATCH 2/2] md/r5cache: enable chunk_aligned_read with write back cache
From: NeilBrown @ 2017-01-04 4:02 UTC (permalink / raw)
To: linux-raid
Cc: shli, kernel-team, dan.j.williams, hch, liuzhengyuan, liuyun01,
Song Liu, Jes.Sorensen
In-Reply-To: <20161229011802.692478-2-songliubraving@fb.com>
[-- Attachment #1: Type: text/plain, Size: 6381 bytes --]
On Thu, Dec 29 2016, Song Liu wrote:
> Chunk aligned read significantly reduces CPU usage of raid456.
> However, it is not safe to fully bypass the write back cache.
> This patch enables chunk aligned read with write back cache.
>
> For chunk aligned read, we track stripes in write back cache at
> a bigger granularity, "big_stripe". Each chunk may contain more
> than one stripe (for example, a 256kB chunk contains 64 4kB-page,
> so this chunk contain 64 stripes). For chunk_aligned_read, these
> stripes are grouped into one big_stripe, so we only need one lookup
> for the whole chunk.
>
> For each big_stripe, struct big_stripe_info tracks how many stripes of
> this big_stripe are in the write back cache. These data are tracked
> in a radix tree (big_stripe_tree). big_stripe_index() is used to
> calculate keys for the radix tree.
>
> chunk_aligned_read() calls r5c_big_stripe_cached() to look up
> big_stripe of each chunk in the tree. If this big_stripe is in the
> tree, chunk_aligned_read() aborts. This look up is protected by
> rcu_read_lock().
>
> It is necessary to remember whether a stripe is counted in
> big_stripe_tree. Instead of adding new flag, we reuses existing flags:
> STRIPE_R5C_PARTIAL_STRIPE and STRIPE_R5C_FULL_STRIPE. If either of these
> two flags are set, the stripe is counted in big_stripe_tree. This
> requires moving set_bit(STRIPE_R5C_PARTIAL_STRIPE) to
> r5c_try_caching_write().
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> drivers/md/raid5-cache.c | 146 ++++++++++++++++++++++++++++++++++++++++++++---
> drivers/md/raid5.c | 19 +++---
> drivers/md/raid5.h | 1 +
> 3 files changed, 152 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 817b294..268dcd2 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -162,9 +162,60 @@ struct r5l_log {
>
> /* to submit async io_units, to fulfill ordering of flush */
> struct work_struct deferred_io_work;
> +
> + /* to for chunk_aligned_read in writeback mode, details below */
> + spinlock_t tree_lock;
> + struct radix_tree_root big_stripe_tree;
> + struct kmem_cache *bsi_kc; /* kmem_cache for big_stripe_info */
Why use a kmem_cache. The structure you are allocating is an atomic_t,
which is 4 or 8 bytes, so kmalloc can allocate it efficiently. You only
need a kmem_cache for objects that are not a nice even size.
> + mempool_t *big_stripe_info_pool;
And why a mempool? Mempool are used when the allocation mustn't fail and
you can wait for some other users of the memory to free it. That is not
at all the case here.
As you are using a radix tree, it would probably make sense to not store
a pointer, but to store an integer directly. Use radix_tree_replace to
update.
> };
>
> /*
> + * Enable chunk_aligned_read() with write back cache.
> + *
> + * Each chunk may contain more than one stripe (for example, a 256kB
> + * chunk contains 64 4kB-page, so this chunk contain 64 stripes). For
> + * chunk_aligned_read, these stripes are grouped into one "big_stripe".
> + * For each big_stripe, struct big_stripe_info tracks how many stripes of
> + * this big_stripe are in the write back cache. These data are tracked
> + * in a radix tree (big_stripe_tree). big_stripe_index() is used to
> + * calculate keys for the radix tree.
> + *
> + * chunk_aligned_read() calls r5c_big_stripe_cached() to look up
> + * big_stripe of each chunk in the tree. If this big_stripe is in the
> + * tree, chunk_aligned_read() aborts. This look up is protected by
> + * rcu_read_lock().
> + *
> + * It is necessary to remember whether a stripe is counted in
> + * big_stripe_tree. Instead of adding new flag, we reuses existing flags:
> + * STRIPE_R5C_PARTIAL_STRIPE and STRIPE_R5C_FULL_STRIPE. If either of these
> + * two flags are set, the stripe is counted in big_stripe_tree. This
> + * requires moving set_bit(STRIPE_R5C_PARTIAL_STRIPE) to
> + * r5c_try_caching_write().
> + */
> +struct big_stripe_info {
> + atomic_t count;
> +#ifdef CONFIG_DEBUG_VM
> + void *pad; /* suppress size check error in kmem_cache_sanity_check */
There is a probably a reason for this error .....
> +#endif
> +};
> +
> +/*
> + * calculate key for big_stripe_tree
> + *
> + * sect: align_bi->bi_iter.bi_sector or sh->sector
> + */
> +static inline sector_t big_stripe_index(struct r5conf *conf,
> + sector_t sect)
> +{
> + sector_t offset;
> +
> + offset = sector_div(sect, conf->chunk_sectors *
> + (conf->raid_disks - conf->max_degraded));
This code implies that 'sect' is a sector address in the array.
However you call this function as
> + bs_index = big_stripe_index(conf, sh->sector);
and sh->sector is a sector address in each underlying device.
So something is definitely wrong.
> + return sect;
> +}
> +
> +/*
> * an IO range starts from a meta data block and end at the next meta data
> * block. The io unit's the meta data block tracks data/parity followed it. io
> * unit is written to log disk with normal write, as we always flush log disk
> @@ -2293,6 +2344,8 @@ int r5c_try_caching_write(struct r5conf *conf,
> int i;
> struct r5dev *dev;
> int to_cache = 0;
> + struct big_stripe_info *bsinfo;
> + sector_t bs_index;
>
> BUG_ON(!r5c_is_writeback(log));
>
> @@ -2327,6 +2380,37 @@ int r5c_try_caching_write(struct r5conf *conf,
> }
> }
>
> + /* if the stripe is not counted in big_stripe_tree, add it now */
> + if (!test_bit(STRIPE_R5C_PARTIAL_STRIPE, &sh->state) &&
> + !test_bit(STRIPE_R5C_FULL_STRIPE, &sh->state)) {
> + bs_index = big_stripe_index(conf, sh->sector);
> + spin_lock(&log->tree_lock);
> + bsinfo = radix_tree_lookup(&log->big_stripe_tree, bs_index);
> + if (bsinfo)
> + atomic_inc(&bsinfo->count);
> + else {
> + bsinfo = mempool_alloc(log->big_stripe_info_pool, GFP_ATOMIC);
> + if (bsinfo) {
> + atomic_set(&bsinfo->count, 1);
> + radix_tree_insert(&log->big_stripe_tree, bs_index, bsinfo);
You've declared this radix_tree as
> + INIT_RADIX_TREE(&log->big_stripe_tree, GFP_ATOMIC);
so it can be using in spinlock context, but that is only reliable if you
first call radix_tree_preload() before taking the lock.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* adding 32 bit compatibility layer in custom kernel module
From: Pradeepa Kumar @ 2017-01-04 4:04 UTC (permalink / raw)
To: kernelnewbies
Hi experts
down votefavorite
<http://stackoverflow.com/questions/41455943/adding-32-bit-compatibility-layer-in-custom-kernel-module#>
in my 64 bit kernel, I have a custom kernel module providing new protocol
and providing socket system calls.
it works fine when 64 bit app runs.
i am seeing issues when 32 bit app runs (for exp recvmsg() call does not
work if msg has cmsghdrs as struct size of cmsghdr is different in 32 bit
and 64 bit).
This is because my custom kernel module does not have 32 bit compatibility
layer ( but linux kernel has this in compat.c etc).
-
is it simple to add compatibility layer to my custom kernel module
-
how do i do this (any links ?)
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170104/6f56f08e/attachment-0001.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-2.9 v3 0/5] Sheepdog cleanups
From: Jeff Cody @ 2017-01-04 4:07 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel, Hitoshi Mitake, Liu Yuan, qemu-block
In-Reply-To: <3f948687-3169-c304-3ef8-31347f08857f@redhat.com>
On Wed, Dec 21, 2016 at 03:07:07PM +0100, Paolo Bonzini wrote:
>
>
> On 29/11/2016 12:32, Paolo Bonzini wrote:
> > Cleaning up the code and removing duplication makes it simpler to
> > later adapt it for the multiqueue work.
> >
> > Tested against sheepdog 1.0. I also tested taking snapshots and reverting
> > to older snapshots, but the latter only worked with "dog vdi rollback".
> > Neither loadvm nor qemu-img worked for me.
> >
> > Paolo
> >
> > v1->v2: placate patchew
> > v2->v3: rebase
> >
> > Paolo Bonzini (5):
> > sheepdog: remove unused cancellation support
> > sheepdog: reorganize coroutine flow
> > sheepdog: do not use BlockAIOCB
> > sheepdog: simplify inflight_aio_head management
> > sheepdog: reorganize check for overlapping requests
> >
> > block/sheepdog.c | 289 ++++++++++++++++---------------------------------------
> > 1 file changed, 83 insertions(+), 206 deletions(-)
> >
>
> 2.8 is now out, so ping.
>
I don't have a functional sheepdog setup at the moment; have you tested
these patches, or should I set up a test rig for them? (I am guessing I
should do the latter; either way, I'll pull the patches in once I or someone
else has tested them).
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/4] QOM'ify work for ppc
From: David Gibson @ 2017-01-04 3:28 UTC (permalink / raw)
To: 赵小强; +Cc: peter.maydell, qemu-ppc, qemu-devel, agraf
In-Reply-To: <A1654386-0C53-4C64-BE97-A6804E1AA4F3@163.com>
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
On Tue, Jan 03, 2017 at 10:02:21PM +0800, 赵小强 wrote:
> Hi,david:
>
> To my understanding,what must be put in the realize function is
> code which depends on property values. What's the benefit of
> moving memory region initialization into realize function? I can
> not figure out, can you make some explanations?
If nothing else it's better in realize() for consistency with other
devices.
I'm not familiar enough with the details to be sure, but I also think
it's not safe in instance_init. Once memory regions are registered,
the device can potentially interact with other devices in the virtual
machine. realize() is sequenced to expect that, instance_init is not.
> Thanks for your review.
>
> Best wishes !
>
> > 在 2017年1月3日,06:28,David Gibson <david@gibson.dropbear.id.au> 写道:
> >
> >> On Sat, Dec 31, 2016 at 09:18:27AM +0800, xiaoqiang zhao wrote:
> >> This is some QOM'ify work relate with ppc.
> >> See each commit message for details.
> >>
> >> xiaoqiang zhao (4):
> >> hw/gpio: QOM'ify mpc8xxx.c
> >> hw/ppc: QOM'ify e500.c
> >> hw/ppc: QOM'ify ppce500_spin.c
> >> hw/ppc: QOM'ify spapr_vio.c
> >>
> >> hw/gpio/mpc8xxx.c | 20 +++++++++++---------
> >> hw/ppc/e500.c | 17 ++++-------------
> >> hw/ppc/ppce500_spin.c | 18 ++++++++----------
> >> hw/ppc/spapr_vio.c | 2 --
> >> 4 files changed, 23 insertions(+), 34 deletions(-)
> >
> > Patches 1-3 all have the same problem - they move memory region
> > initialization and similar to an instance_init function. This is not
> > how things are generally done in the qdev model. Instead that phase
> > of initialization should be done from a dc->realize() function.
> >
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [radeon-alex:amd-staging-drm-next 149/158] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1740:2: warning: ISO C90 forbids mixed declarations and code
From: kbuild test robot @ 2017-01-04 4:12 UTC (permalink / raw)
To: Andrew Wong; +Cc: Alex Deucher, kbuild-all, dri-devel
[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 5d8e75c019bf76889bd606a67afabf7d0b32d3fa
commit: 23ffa1200a5abc5b724fe87bb4a7291fce85bba2 [149/158] drm/amd/display: DAL3: HDR10 Infoframe encoding
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 23ffa1200a5abc5b724fe87bb4a7291fce85bba2
# save the attached .config to linux build tree
make.cross ARCH=alpha
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_hdr_static_info_packet':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1740:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
struct dc_hdr_static_metadata hdr_metadata =
^~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1760:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
uint32_t data;
^~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_avi_info_frame':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1495:38: warning: iteration 28 invokes undefined behavior [-Waggressive-loop-optimizations]
info_packet->sb[byte_index] = info_frame.avi_info_packet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
info_packet_hdmi.packet_raw_data.sb[byte_index];
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1493:2: note: within this loop
for (byte_index = 0; byte_index < sizeof(info_packet->sb); byte_index++)
^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_hdr_static_info_packet.isra.7':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1734:11: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
uint16_t i;
^
vim +1740 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
1728
1729 static void set_hdr_static_info_packet(
1730 struct core_surface *surface,
1731 struct core_stream *stream,
1732 struct hw_info_packet *info_packet)
1733 {
> 1734 uint16_t i;
1735 enum signal_type signal = stream->signal;
1736
1737 if (!surface)
1738 return;
1739
> 1740 struct dc_hdr_static_metadata hdr_metadata =
1741 surface->public.hdr_static_ctx;
1742
1743 if (dc_is_hdmi_signal(signal)) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47963 bytes --]
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: mount_pseudo(), sget() and MS_KERNMOUNT
From: Eric W. Biederman @ 2017-01-04 4:20 UTC (permalink / raw)
To: Luis Ressel; +Cc: Alexander Viro, linux-fsdevel, linux-kernel
In-Reply-To: <20161227112037.015dc5ac@gentp.lnet>
Luis Ressel <aranea@aixah.de> writes:
> Hello,
>
> With Linux 4.8, the sget() function in fs/super.c got a new permission
> check: It now returns -EPERM if
> (!(flags & MS_KERNMOUNT) && !ns_capable(user_ns, CAP_SYS_ADMIN)) .
>
> I presume the first half is intented to detect in-kernel mounts? If so,
> why doesn't mount_pseudo() (in fs/libfs.c) pass the MS_KERNMOUNT flag
> to sget()?
It looks like an oversight that has simply not mattered.
> This behaviour has caused a problem for me: During graphics driver
> initalization, drm_fs_inode_new() (in drivers/gpu/drm/drm_drv.c) calls
> simple_pin_fs(). The MS_KERNMOUNT flag is indeed passed down the
> call chain from there, but it is lost when mount_pseudo() is called, as
> that function doesn't take a 'flags' argument.
>
> Hence, the first part of the above permission check fails. (The second
> part also fails under some cicumstances due to a SELinux quirk, and
> therefore the initalization of my graphics driver doesn't succeed.)
I am concerned that perhaps there is some wrong context in here that is
causing SELinux to have problems.
Does this correct your symptoms?
Eric
diff --git a/fs/libfs.c b/fs/libfs.c
index e973cd51f126..28d6f35feed6 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -245,7 +245,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type *fs_type, char *name,
struct inode *root;
struct qstr d_name = QSTR_INIT(name, strlen(name));
- s = sget(fs_type, NULL, set_anon_super, MS_NOUSER, NULL);
+ s = sget_userns(fs_type, NULL, set_anon_super, MS_KERNMOUNT|MS_NOUSER,
+ &init_user_ns, NULL);
if (IS_ERR(s))
return ERR_CAST(s);
^ permalink raw reply related
* [PATCH perf/core 2/3] perf-probe: Fix to probe on gcc generated symbols for offline kernel
From: Masami Hiramatsu @ 2017-01-04 3:30 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu, linux-kernel, Jiri Olsa, Peter Zijlstra,
Ingo Molnar, Namhyung Kim
In-Reply-To: <148350046263.19001.16486219029429895749.stgit@devbox>
Fix perf-probe to show probe definition on gcc generated symbols
for offline kernel (including cross-arch kernel image).
Gcc sometimes optimizes functions and generate new symbols with
suffixes such as ".constprop.N" or ".isra.N" etc. Since those
symbol names are not recorded in DWARF, we have to find correct
generated symbols from offline ELF binary to probe on it (kallsyms
doesn't correct it).
For online kernel or uprobes we don't need it because those are
rebased on _text, or a section relative address.
E.g. Without this;
-----
$ perf probe -k build-arm/vmlinux -F __slab_alloc*
__slab_alloc.constprop.9
$ perf probe -k build-arm/vmlinux -D __slab_alloc
p:probe/__slab_alloc __slab_alloc+0
-----
If you put above definition on target machine, it should fail
because there is no __slab_alloc in kallsyms.
With this fix, perf probe shows correct probe definition on
__slab_alloc.constprop.9.
-----
$ perf probe -k build-arm/vmlinux -D __slab_alloc
p:probe/__slab_alloc __slab_alloc.constprop.9+0
-----
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
tools/perf/util/probe-event.c | 48 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 542e647..4a57c8a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,51 @@ static int find_perf_probe_point_from_dwarf(struct probe_trace_point *tp,
return ret ? : -ENOENT;
}
+/*
+ * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
+ * and generate new symbols with suffixes such as .constprop.N or .isra.N
+ * etc. Since those symbols are not recorded in DWARF, we have to find
+ * correct generated symbols from offline ELF binary.
+ * For online kernel or uprobes we don't need this because those are
+ * rebased on _text, or already a section relative address.
+ */
+static int
+post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
+ int ntevs, const char *pathname)
+{
+ struct symbol *sym;
+ struct map *map;
+ unsigned long stext = 0;
+ u64 addr;
+ int i;
+
+ /* Prepare a map for offline binary */
+ map = dso__new_map(pathname);
+ if (!map || get_text_start_address(pathname, &stext) < 0) {
+ pr_warning("Failed to get ELF symbols for %s\n", pathname);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ntevs; i++) {
+ addr = tevs[i].point.address + tevs[i].point.offset - stext;
+ sym = map__find_symbol(map, addr);
+ if (!sym)
+ continue;
+ if (!strcmp(sym->name, tevs[i].point.symbol))
+ continue;
+ /* If we have no realname, use symbol for it */
+ if (!tevs[i].point.realname)
+ tevs[i].point.realname = tevs[i].point.symbol;
+ else
+ free(tevs[i].point.symbol);
+ tevs[i].point.symbol = strdup(sym->name);
+ tevs[i].point.offset = addr - sym->start;
+ }
+ map__put(map);
+
+ return 0;
+}
+
static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,
int ntevs, const char *exec)
{
@@ -671,7 +716,8 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
/* Skip post process if the target is an offline kernel */
if (symbol_conf.ignore_vmlinux_buildid)
- return 0;
+ return post_process_offline_probe_trace_events(tevs, ntevs,
+ symbol_conf.vmlinux_name);
reloc_sym = kernel_get_ref_reloc_sym();
if (!reloc_sym) {
^ permalink raw reply related
* cron job: media_tree daily build: ERRORS
From: Hans Verkuil @ 2017-01-04 4:25 UTC (permalink / raw)
To: linux-media
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Jan 4 05:00:10 CET 2017
media-tree git hash: 40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash: 1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: 951c4878a93f4722146f8bc6515a47fba6470bb3
gcc version: i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware: x86_64
host os: 4.8.0-164
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2
The Media Infrastructure API from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/index.html
^ permalink raw reply
* [Qemu-devel] [Bug 1639225] Re: qcow2 - filesize 8.1Petabyte
From: Launchpad Bug Tracker @ 2017-01-04 4:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20161104124922.14508.87645.malonedeb@chaenomeles.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1639225
Title:
qcow2 - filesize 8.1Petabyte
Status in QEMU:
Expired
Bug description:
problem :
Filesystem Size Used Avail Use%
Mounted on
/dev/sdd1 120G 63G 57G 53%
/storage/kvmstorage4ssd
# pwd
/storage/kvmstorage4ssd/images
# qemu-img info vsys19_ssd1.qcow2
image: vsys19_ssd1.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 11G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
refcount bits: 16
corrupt: true
# ls -lah vsys19_*
-rw------- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2
# ls -la vsys19_*
-rw------- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2
# qemu-img check vsys19_ssd1.qcow2
qemu-img: Check failed: File too large
# xfs_repair /dev/sdd1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
# pwd
/storage/kvmstorage4ssd/images
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/storage/kvmstorage4ssd/images/vsys19_ssd1.qcow2'/>
<target dev='vdn' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/>
</disk>
guest OS:
# uname -a
Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
cat /etc/debian_version
stretch/sid
Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272
Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s
tarting block 1085897)
Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897
Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898
Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899
Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900
Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901
Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902
Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903
Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904
Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905
Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906
Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280
Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023)
Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288
Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149)
Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296
Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275)
Nov 4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304
Nov 4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401)
KVM host :
# cat /etc/debian_version
stretch/sid
Debian
# uname -a
Linux asus1 4.5.5-custom #1 SMP Sun May 22 21:14:57 CEST 2016 x86_64 GNU/Linux
# dpkg -l | grep -i qemu
ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1 all PXE boot firmware - ROM images for qemu
ii qemu 1:2.5+dfsg-5+b1 amd64 fast processor emulator
ii qemu-kvm 1:2.5+dfsg-5+b1 amd64 QEMU Full virtualization on x86 hardware
ii qemu-slof 20151103+dfsg-2 all Slimline Open Firmware -- QEMU PowerPC version
ii qemu-system 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries
ii qemu-system-arm 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (arm)
ii qemu-system-common 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-mips 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (mips)
ii qemu-system-misc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (miscelaneous)
ii qemu-system-ppc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (ppc)
ii qemu-system-sparc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (sparc)
ii qemu-system-x86 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (x86)
ii qemu-user 1:2.5+dfsg-5+b1 amd64 QEMU user mode emulation binaries
ii qemu-user-binfmt 1:2.5+dfsg-5+b1 amd64 QEMU user mode binfmt registration for qemu-user
ii qemu-utils 1:2.5+dfsg-5+b1 amd64 QEMU utilities
ii qemubuilder 0.80 amd64 pbuilder using QEMU as backend
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1639225/+subscriptions
^ permalink raw reply
* [xen-unstable test] 104015: tolerable FAIL - PUSHED
From: osstest service owner @ 2017-01-04 4:26 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 104015 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104015/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 104004
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104004
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104004
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 104004
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 104004
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 104004
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 104004
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 104004
test-amd64-amd64-xl-rtds 9 debian-install fail like 104004
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
baseline version:
xen ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5
Last test of basis 104004 2017-01-03 01:59:38 Z 1 days
Failing since 104008 2017-01-03 11:13:37 Z 0 days 2 attempts
Testing same since 104015 2017-01-03 19:45:46 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <george.dunlap@citrix.com>
Jan Beulich <jbeulich@suse.com>
Kevin Tian <kevin.tian@intel.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable
+ revision=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ branch=xen-unstable
+ revision=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xe34bc403c3c7dc0075111fa9cd29e2a385bc66ed = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.xen-unstable
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/xen
+ git push osstest@xenbits.xen.org:/home/xen/git/xen.git e34bc403c3c7dc0075111fa9cd29e2a385bc66ed:refs/heads/master
To osstest@xenbits.xen.org:/home/xen/git/xen.git
ee524f2..e34bc40 e34bc403c3c7dc0075111fa9cd29e2a385bc66ed -> master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [Qemu-devel] [Bug 1102027] Re: QED Time travel
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20130120115433.12489.5115.malonedeb@soybean.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1102027
Title:
QED Time travel
Status in QEMU:
Expired
Bug description:
This night after a reboot of a VM, it was back to 8 Oct. 2012, i've
lost all data between 8 Oct 2012 and now. I've check the QED file and
mount on another VM, all seems OK.
This QED has a raw backfile with the base OS (debian) shared with many
others QED. It has NO snapshot.
QEMU emulator version 1.1.2
Does anyone have a hint ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1102027/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 1317603] Re: qemu-system-ppc does not terminate on VM exit
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20140508172525.21754.50051.malonedeb@chaenomeles.canonical.com>
[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]
** Changed in: qemu (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1317603
Title:
qemu-system-ppc does not terminate on VM exit
Status in QEMU:
Won't Fix
Status in qemu package in Ubuntu:
Expired
Bug description:
When a VM is created for a p4080-e500mc ; the VM can not be rebooted
or terminated.
The qemu-system-ppc process must be killed.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1
ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9
Uname: Linux 3.13.9+ ppc
ApportVersion: 2.14.1-0ubuntu3
Architecture: powerpc
Date: Thu May 8 12:20:57 2014
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: qemu
UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317603/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 612297] Re: qemu-kvm fails to detect mouse while Windows 95 setup
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20100801164711.20463.98993.malonedeb@soybean.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/612297
Title:
qemu-kvm fails to detect mouse while Windows 95 setup
Status in QEMU:
Expired
Bug description:
CPU: AMD Phenom II X4 945
KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package)
Kernel: linux-2.6.26.8-rt16
arch: x86_64
Guest: Windows 95 B
I'm trying to install Windows 95 B on qemu-kvm with this options:
kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M
-rtc base=localtime -k de -soundhw sb16 -vga cirrus -net
user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda
/var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom
/var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb
I've also tried some other option, but always the same: no ps/2 mouse
detection. And usb mouse is not supported by Windows 95 B while setup
process. This is only possible later by installing the extension
usbsupp.exe after the system setup.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/612297/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 590552] Re: New default network card doesn't work with tap networking
From: Launchpad Bug Tracker @ 2017-01-04 4:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20100606230821.4593.45646.malonedeb@soybean.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/590552
Title:
New default network card doesn't work with tap networking
Status in QEMU:
Expired
Bug description:
Unfortunately, I can provide very little information.
Hope this will be useful anyway.
I've upgraded qemu using debian apt to lastest unstable (QEMU PC
emulator version 0.12.4 (Debian 0.12.4+dfsg-2), Copyright (c)
2003-2008 Fabrice Bellard): looks like at some point the default
network card for -net nic option was switched to intel gigabit instead
of the good old ne2k_pci.
I was using -net tap -net nic options and my network stopped working.
When not working,
- tcpdump on the host shows me taht all packets are sent and received fine from guest
- tcpdump on guest shows that packets from host are NOT received
obviously, both host tap interface and guest eth0 interfaces, routing
tables, dns, firewall, etc... are well configured.
Having banged my head for a while, I finally stopped the host and
started it again using -net nic,model=ne2k_pci option, then my network
magically started working again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/590552/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 1119686] Re: Incorrect handling of icebp
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20130208193040.11551.94134.malonedeb@chaenomeles.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1119686
Title:
Incorrect handling of icebp
Status in QEMU:
Expired
Bug description:
Wine conformance suite tests the behavior of various low-level Windows
API functions. One of the tests involves checking the interaction of
breakpoints and exceptions, and in particular the 'icebp' breakpoint.
This test works on a Windows XP machine running either on the metal or
in VMware ESX but fails when run in QEmu.
To reproduce the issue grab the attached 'exception.exe' file and run
it. If you get 'Test failed' lines like below then it means the
problem is still present:
exception.c:202: exception 0: 80000004 flags:0 addr:003F0000
exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001
exception.c:214: this is the last test seen before the exception
exception: unhandled exception 80000004 at 003F0000
exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9
exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004
exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001
Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian
Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian
Experimental).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 809912] Re: qemu-kvm -m bigger 4096 aborts with 'Bad ram offset'
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20110713143335.13610.27004.malonedeb@chaenomeles.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/809912
Title:
qemu-kvm -m bigger 4096 aborts with 'Bad ram offset'
Status in QEMU:
Expired
Bug description:
When I try to start a virtual machine (x86_64 guest on a x86_64 host
that has 32GB memory, using kvm_amd module, both host and guest
running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp
2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts
with a message "Bad ram offset 11811c000".
With e.g. "-m 3500" (or lower), the virtual machine runs fine.
I experience this both using qemu-kvm 0.14.1 and a recent version from git
commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021
Merge: d589310 75ef849
Author: Avi Kivity <avi@redhat.com>
Date: Mon Jul 4 13:36:06 2011 +0300
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/809912/+subscriptions
^ permalink raw reply
* [Qemu-devel] [Bug 441672] Re: Windos XP BSOD with HP Photosmart usb device attached
From: Launchpad Bug Tracker @ 2017-01-04 4:17 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20091003195706.32421.28307.malonedeb@gangotri.canonical.com>
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/441672
Title:
Windos XP BSOD with HP Photosmart usb device attached
Status in QEMU:
Expired
Bug description:
https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details
of the problem.
I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One
printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random
(fairly short :-) intervals.
My latest attempt was on a fedora rawhide system with pretty up to date software
(qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen.
A reply to that bugzilla recommended adding this upstream bug, so here
it is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/441672/+subscriptions
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.