* [Buildroot] [PATCH] patchelf: bump version to 0.9
From: Baruch Siach @ 2016-11-09 9:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109094346.5839-1-jezz@sysmic.org>
Hi J?r?me,
On Wed, Nov 09, 2016 at 10:43:46AM +0100, J?r?me Pouiller wrote:
> -PATCHELF_VERSION = 0.8
> -PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.8
> +PATCHELF_VERSION = 0.9
> +PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.9
Unrelated to this patch, but SITE should be
http://releases.nixos.org/patchelf/patchelf-$(PATCHELF_VERSION). And while at
it we can also move to .tar.bz2 file to save some space.
> PATCHELF_LICENSE = GPLv3+
> PATCHELF_LICENSE_FILES = COPYING
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC
From: Jaewon Kim @ 2016-11-09 9:47 UTC (permalink / raw)
To: Brian Starkey; +Cc: linux-mm, linux-kernel
In-Reply-To: <20161109092726.GA6009@e106950-lin.cambridge.arm.com>
On 2016년 11월 09일 18:27, Brian Starkey wrote:
> Hi Jaewon,
>
> On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote:
>> Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MA)
>> added MEMREMAP_WC for DMA_MEMORY_MAP. If, however, CPU cache can be used on
>> DMA_MEMORY_MAP, I think MEMREMAP_WC can be changed to MEMREMAP_WB. On my local
>> ARM device, memset in dma_alloc_from_coherent sometimes takes much longer with
>> MEMREMAP_WC compared to MEMREMAP_WB.
>>
>> Test results on AArch64 by allocating 4MB with putting trace_printk right
>> before and after memset.
>> MEMREMAP_WC : 11.0ms, 5.7ms, 4.2ms, 4.9ms, 5.4ms, 4.3ms, 3.5ms
>> MEMREMAP_WB : 0.7ms, 0.6ms, 0.6ms, 0.6ms, 0.6ms, 0.5ms, 0.4 ms
>>
>
> This doesn't look like a good idea to me. The point of coherent memory
> is to have it non-cached, however WB will make writes hit the cache.
>
> Writing to the cache is of course faster than writing to RAM, but
> that's not what we want to do here.
>
> -Brian
>
Hi Brian
Thank you for your comment.
If allocated memory will be used by TZ side, however, I think cacheable
also can be used to be fast on memset in dma_alloc_from_coherent.
How do you think to add another flag to distinguish this case?
>> Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
>> ---
>> drivers/base/dma-coherent.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>> index 640a7e6..0512a1d 100644
>> --- a/drivers/base/dma-coherent.c
>> +++ b/drivers/base/dma-coherent.c
>> @@ -33,7 +33,7 @@ static bool dma_init_coherent_memory(
>> goto out;
>>
>> if (flags & DMA_MEMORY_MAP)
>> - mem_base = memremap(phys_addr, size, MEMREMAP_WC);
>> + mem_base = memremap(phys_addr, size, MEMREMAP_WB);
>> else
>> mem_base = ioremap(phys_addr, size);
>> if (!mem_base)
>> --
>> 1.9.1
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC
From: Jaewon Kim @ 2016-11-09 9:47 UTC (permalink / raw)
To: Brian Starkey; +Cc: linux-mm, linux-kernel
In-Reply-To: <20161109092726.GA6009@e106950-lin.cambridge.arm.com>
On 2016e?? 11i?? 09i? 1/4 18:27, Brian Starkey wrote:
> Hi Jaewon,
>
> On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote:
>> Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MA)
>> added MEMREMAP_WC for DMA_MEMORY_MAP. If, however, CPU cache can be used on
>> DMA_MEMORY_MAP, I think MEMREMAP_WC can be changed to MEMREMAP_WB. On my local
>> ARM device, memset in dma_alloc_from_coherent sometimes takes much longer with
>> MEMREMAP_WC compared to MEMREMAP_WB.
>>
>> Test results on AArch64 by allocating 4MB with putting trace_printk right
>> before and after memset.
>> MEMREMAP_WC : 11.0ms, 5.7ms, 4.2ms, 4.9ms, 5.4ms, 4.3ms, 3.5ms
>> MEMREMAP_WB : 0.7ms, 0.6ms, 0.6ms, 0.6ms, 0.6ms, 0.5ms, 0.4 ms
>>
>
> This doesn't look like a good idea to me. The point of coherent memory
> is to have it non-cached, however WB will make writes hit the cache.
>
> Writing to the cache is of course faster than writing to RAM, but
> that's not what we want to do here.
>
> -Brian
>
Hi Brian
Thank you for your comment.
If allocated memory will be used by TZ side, however, I think cacheable
also can be used to be fast on memset in dma_alloc_from_coherent.
How do you think to add another flag to distinguish this case?
>> Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
>> ---
>> drivers/base/dma-coherent.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>> index 640a7e6..0512a1d 100644
>> --- a/drivers/base/dma-coherent.c
>> +++ b/drivers/base/dma-coherent.c
>> @@ -33,7 +33,7 @@ static bool dma_init_coherent_memory(
>> goto out;
>>
>> if (flags & DMA_MEMORY_MAP)
>> - mem_base = memremap(phys_addr, size, MEMREMAP_WC);
>> + mem_base = memremap(phys_addr, size, MEMREMAP_WB);
>> else
>> mem_base = ioremap(phys_addr, size);
>> if (!mem_base)
>> --
>> 1.9.1
>>
>
>
>
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v10 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl
From: Borislav Petkov @ 2016-11-09 9:47 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-2-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:50AM -0800, Kyle Huey wrote:
<--- Add commit message here.
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> ---
> arch/x86/kernel/process_64.c | 3 ++-
> arch/x86/um/syscalls_64.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
...
> void arch_switch_to(struct task_struct *to)
> {
> if ((to->thread.arch.fs == 0) || (to->mm == NULL))
> return;
>
> base-commit: e3a00f68e426df24a5fb98956a1bd1b23943aa1e
This looks like some tracking thing. It gets ignored by tools though...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v10 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl
From: Borislav Petkov @ 2016-11-09 9:47 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-2-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:50AM -0800, Kyle Huey wrote:
<--- Add commit message here.
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> ---
> arch/x86/kernel/process_64.c | 3 ++-
> arch/x86/um/syscalls_64.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
...
> void arch_switch_to(struct task_struct *to)
> {
> if ((to->thread.arch.fs == 0) || (to->mm == NULL))
> return;
>
> base-commit: e3a00f68e426df24a5fb98956a1bd1b23943aa1e
This looks like some tracking thing. It gets ignored by tools though...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: Virtio blk latency
From: Stefan Hajnoczi @ 2016-11-09 9:46 UTC (permalink / raw)
To: Esparza Borquez, David; +Cc: kvm@vger.kernel.org
In-Reply-To: <016D2F5F9DA7314594DE889A46F80F3CE29715@FMSMSX108.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
On Mon, Nov 07, 2016 at 04:43:13PM +0000, Esparza Borquez, David wrote:
> We are measuring virtio blk latency in linux containers following the method presented by you in
> http://www.linux-kvm.org/page/Virtio/Block/Latency and we have some questions:
That page is old but the general approach still makes sense. Some of
the details (e.g. trace event names) have changed.
I also recommend comparing against blktrace and benchmark I/O statistics
to sanity-check your tracing results. That way you can be sure that the
numbers you're getting make sense.
> 1. Does a single paio_submit call is followed by a pair of virtio_queue_notify/vitio_notify ?
> or a single paio_submit call could be followed by several virtio_queue_notify/vitio_notify traces.
It should be:
1 x virtio_queue_notify()
N x paio_submit() (N >= 1, there could be multiple requests to submit)
N x virtio_notify()
Note that the N virtio_notify() calls could happen at any time, even
after the *next* virtio_queue_notify(). This is because virtio-blk
requests can be done in parallel and their lifetimes can overlap.
Note that paio_submit() is used with the defailt -drive aio=threads
option. If you use -drive aio=native then laio_submit() can be used
instead.
> 2. Sometimes Host kvm.ko (kvm_pio:pio_write) traces appear to have less latency than QEMU paio/virtio traces and in theory they should be grater... do you think this is due to the clock we are using in the host/guest? we've tried several combinations of clocks but so far no luck or at least none has been consistent.
Which tracing backend did you enable in QEMU ./configure? I'd expect
kvm:kvm_pio and QEMU trace events to use coherent clock sources.
> 3. Because we have not observed results for QEMU paio latency when tracking posix_aio_process_queue( ) , we opted for measuring 'paio' latency but with the event 'paio_submit'. Do you think that could be ok to measure qemu paio latency?
posix_aio_process_queue does not exist in modern QEMU.
Latency is the time between 2 events. You have only mentioned
paio_submit so I don't know what other event you are using to calculate
the latency.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 32/36] pathspec: allow querying for attributes
From: Duy Nguyen @ 2016-11-09 9:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, Git Mailing List, Brandon Williams
In-Reply-To: <xmqqzilp63yh.fsf@gitster.mtv.corp.google.com>
On Fri, Oct 28, 2016 at 1:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The reason why I am bringing this up in this discussion thread on
> this patch is because I wonder if we would benefit by a similar
> "let's not do too involved things and be cheap by erring on the safe
> and lazy side" strategy in the call to ce_path_match() call made in
> this function to avoid making calls to the attr subsystem.
>
> In other words, would it help the system by either simplifying the
> processing done or reducing the cycle spent in preload_thread() if
> we could tell ce_path_match() "A pathspec we are checking may
> require not just the pattern to match but also attributes given to
> the path to satisfy the criteria, but for the purpose of preloading,
> pretend that the attribute satisfies the match criteria" (or
> "pretend that it does not match"), thereby not having to make any
> call into the attribute subsystem at all from this codepath?
>
> The strategy this round takes to make it unnecessary to punt
> preloading (i.e. dropping "pathspec: disable preload-index when
> attribute pathspec magic is in use" patch the old series had) is to
> make the attribute subsystem thread-safe. But that thread-safety in
> the initial round is based on a single Big Attribute Lock, so it may
> turn out that the end result performs better for this codepath if we
> did not to make any call into the attribute subsystem.
It does sound good and I want to say "yes please do this", but is it
making pathspec api a bit more complex (to express "assume all
attr-related criteria match")? I guess we can have an api to simply
filter out attr-related magic (basically set attr_match_nr back to
zero) then pass a safe (but more relaxing) pathspec to the threaded
code. That would not add big maintenance burden.
> I am probably being two step ahead of ourselves by saying the above,
> which is just something to keep in mind as a possible solution if
> performance in this preload codepath becomes an issue when the
> pathspec has attributes match specified.
--
Duy
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Ananyev, Konstantin @ 2016-11-09 9:46 UTC (permalink / raw)
To: Topel, Bjorn, dev@dpdk.org
Cc: Xu, Qian Q, Yao, Lei A, Wu, Jingjing, thomas.monjalon@6wind.com,
Topel, Bjorn
In-Reply-To: <20161109082341.19825-1-bjorn.topel@intel.com>
Hi,
>
> Commit 1bbcc5d21129 ("i40evf: report error for unsupported CRC
> stripping config") broke l3fwd, since it was forcing that CRC was
> kept. Now, if i40evf is running, CRC stripping will be enabled.
>
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> examples/l3fwd/main.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index 7223e773107e..b60278794135 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -906,6 +906,14 @@ main(int argc, char **argv)
> n_tx_queue = MAX_TX_QUEUE_PER_PORT;
> printf("Creating queues: nb_rxq=%d nb_txq=%u... ",
> nb_rx_queue, (unsigned)n_tx_queue );
> + rte_eth_dev_info_get(portid, &dev_info);
> + if (dev_info.driver_name &&
> + strcmp(dev_info.driver_name, "net_i40e_vf") == 0) {
> + /* i40evf require that CRC stripping is enabled. */
> + port_conf.rxmode.hw_strip_crc = 1;
> + } else {
> + port_conf.rxmode.hw_strip_crc = 0;
> + }
That's a common problem across Intel VF devices.
Bothe igb and ixgbe overcomes that problem just by forcing ' rxmode.hw_strip_crc = 1;'
at PMD itself:
static int
ixgbevf_dev_configure(struct rte_eth_dev *dev)
{
...
/*
* VF has no ability to enable/disable HW CRC
* Keep the persistent behavior the same as Host PF
*/
#ifndef RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC
if (!conf->rxmode.hw_strip_crc) {
PMD_INIT_LOG(NOTICE, "VF can't disable HW CRC Strip");
conf->rxmode.hw_strip_crc = 1;
}
#else
if (conf->rxmode.hw_strip_crc) {
PMD_INIT_LOG(NOTICE, "VF can't enable HW CRC Strip");
conf->rxmode.hw_strip_crc = 0;
}
#endif
Wonder, can't i40e VF do the same?
BTW, all other examples would experience same problem too, right?
Konstantin
> ret = rte_eth_dev_configure(portid, nb_rx_queue,
> (uint16_t)n_tx_queue, &port_conf);
> if (ret < 0)
> @@ -946,7 +954,6 @@ main(int argc, char **argv)
> printf("txq=%u,%d,%d ", lcore_id, queueid, socketid);
> fflush(stdout);
>
> - rte_eth_dev_info_get(portid, &dev_info);
> txconf = &dev_info.default_txconf;
> if (port_conf.rxmode.jumbo_frame)
> txconf->txq_flags = 0;
> --
> 2.9.3
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4
From: Zhiyi Sun @ 2016-11-09 9:45 UTC (permalink / raw)
To: Daniel Borkmann
Cc: bblanco, Tariq Toukan, Yishai Hadas, netdev, linux-rdma,
linux-kernel, alexei.starovoitov
In-Reply-To: <5822E6DB.40204@iogearbox.net>
On Wed, Nov 09, 2016 at 10:05:31AM +0100, Daniel Borkmann wrote:
> On 11/09/2016 08:35 AM, Zhiyi Sun wrote:
> > There are rx_ring_num queues. Each queue will load xdp prog. So
> > bpf_prog_add() should add rx_ring_num to ref_cnt.
> >
> > Signed-off-by: Zhiyi Sun <zhiyisun@gmail.com>
>
> Your analysis looks incorrect to me. Please elaborate in more detail why
> you think current code is buggy ...
>
Yes, you are correct. My patch is incorrect. It is not a bug.
> Call path is dev_change_xdp_fd(), which does bpf_prog_get_type() on the
> fd. This already takes a ref and only drops it in case of error. Thus
> in mlx4_xdp_set(), you only need priv->rx_ring_num - 1 refs for the rest
> of the rings, so that dropping refs from old_prog makes sure we release
> it again. Looks correct to me (maybe a comment would have helped there).
>
I thought mlx4's code is incorrect because in mlx5's driver, function
mlx5e_xdp_set() calls a pair of bpf_prog_add/put, the number of add and
put to the refs are same. I didn't notice that one "add" has been called in its
calller. So, it seems that mlx5's code is incorrect, right?
> > drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > index 12c99a2..d25e150 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > @@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> > */
> > if (priv->xdp_ring_num == xdp_ring_num) {
> > if (prog) {
> > - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> > + prog = bpf_prog_add(prog, priv->rx_ring_num);
> > if (IS_ERR(prog))
> > return PTR_ERR(prog);
> > }
> > @@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> > }
> >
> > if (prog) {
> > - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> > + prog = bpf_prog_add(prog, priv->rx_ring_num);
> > if (IS_ERR(prog))
> > return PTR_ERR(prog);
> > }
> >
>
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4
From: Zhiyi Sun @ 2016-11-09 9:45 UTC (permalink / raw)
To: Daniel Borkmann
Cc: bblanco-uqk4Ao+rVK5Wk0Htik3J/w, Tariq Toukan, Yishai Hadas,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <5822E6DB.40204-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
On Wed, Nov 09, 2016 at 10:05:31AM +0100, Daniel Borkmann wrote:
> On 11/09/2016 08:35 AM, Zhiyi Sun wrote:
> > There are rx_ring_num queues. Each queue will load xdp prog. So
> > bpf_prog_add() should add rx_ring_num to ref_cnt.
> >
> > Signed-off-by: Zhiyi Sun <zhiyisun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Your analysis looks incorrect to me. Please elaborate in more detail why
> you think current code is buggy ...
>
Yes, you are correct. My patch is incorrect. It is not a bug.
> Call path is dev_change_xdp_fd(), which does bpf_prog_get_type() on the
> fd. This already takes a ref and only drops it in case of error. Thus
> in mlx4_xdp_set(), you only need priv->rx_ring_num - 1 refs for the rest
> of the rings, so that dropping refs from old_prog makes sure we release
> it again. Looks correct to me (maybe a comment would have helped there).
>
I thought mlx4's code is incorrect because in mlx5's driver, function
mlx5e_xdp_set() calls a pair of bpf_prog_add/put, the number of add and
put to the refs are same. I didn't notice that one "add" has been called in its
calller. So, it seems that mlx5's code is incorrect, right?
> > drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > index 12c99a2..d25e150 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > @@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> > */
> > if (priv->xdp_ring_num == xdp_ring_num) {
> > if (prog) {
> > - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> > + prog = bpf_prog_add(prog, priv->rx_ring_num);
> > if (IS_ERR(prog))
> > return PTR_ERR(prog);
> > }
> > @@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> > }
> >
> > if (prog) {
> > - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> > + prog = bpf_prog_add(prog, priv->rx_ring_num);
> > if (IS_ERR(prog))
> > return PTR_ERR(prog);
> > }
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC ABI V5 07/10] IB/core: Support getting IOCTL header/SGEs from kernel space
From: Matan Barak @ 2016-11-09 9:45 UTC (permalink / raw)
To: Jason Gunthorpe, Matan Barak
Cc: Leon Romanovsky, Christoph Hellwig, linux-rdma, Doug Ledford,
Sean Hefty, Christoph Lameter, Liran Liss, Haggai Eran,
Majd Dibbiny, Tal Alon
In-Reply-To: <20161108004351.GA32444-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 08/11/2016 02:43, Jason Gunthorpe wrote:
> On Sun, Oct 30, 2016 at 10:48:39AM +0200, Matan Barak wrote:
>> On Fri, Oct 28, 2016 at 5:46 PM, Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>>> On Fri, Oct 28, 2016 at 08:37:25AM -0700, Christoph Hellwig wrote:
>>>> On Fri, Oct 28, 2016 at 06:33:06PM +0300, Leon Romanovsky wrote:
>>>>> Just to summarize, to be sure that I understood you correctly.
>>>>>
>>>>> | write | -> | conversion logic | ---
>>>>> | ioctl | ---------------------------
>>>>>
>>>>> Am I right?
>>>>
>>>> Yes, as long as the write and ioctl boxes do the copy_{from,to}_user.
>
>> If we accept the limitations here (i.e - all commands attributes
>> come either from kernel or from user, but you can't mix them -
>> that's mean the write comparability layer either needs to copy all
>> attributes or use a direct mapping for all of them), I could just
>> either break ib_uverbs_cmd_verbs to a a few functions or just pass a
>> callback of boxing the descriptors copy.
>
> From what I saw in the series, this looks easy enough to fix..
>
> Just lightly refactor things so that the write() compat layer can call
> into the ioctl processor with an already prepared tlv list in kernel
> memory and form such a list on the stack when doing the compat stuff.
>
Yeah, it's just an easy refactor of ib_uverbs_cmd_verbs and there's
multiple ways of doing that :)
> The bigger problem is the tlv list pointers themselves, they have to
> point to user memory so the compat layer can only do so much of a
> transformation.
>
> I guess another flag in the copy_from_user wrapper would do the trick
> if we need it.
>
Currently we assume the payload itself is in user-space only so direct
mapping is mandatory.
If we ever need to do something other than (bunch of consecutive write
ABI struct fields) -> (attribute in the ioctl world), we'll have to box
these copy macros/functions with copy_from_attr and copy_to_attr calls.
> Jason
Matan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 答复: [PATCH] add one parameter wro_enable to enable relaxed ordering for IXGBE
From: maowenan @ 2016-11-09 9:43 UTC (permalink / raw)
To: Jeff Kirsher, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Dingtianhong, weiyongjun (A)
In-Reply-To: <1477726941.2309.9.camel@intel.com>
I have verified that the performance will be enhanced certainly when I enabled Relax Ordering on SPARC, but think it is not very flexible to disable or enable Relax Ordering feature using CONFIG_SPARC currently,
So I want to use module parameter to set RO instead of "#ifndef CONFIG_SPARC", no need to rebuild the whole kernel.
-----邮件原件-----
发件人: Jeff Kirsher [mailto:jeffrey.t.kirsher@intel.com]
发送时间: 2016年10月29日 15:42
收件人: maowenan; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: [PATCH] add one parameter wro_enable to enable relaxed ordering for IXGBE
On Sat, 2016-10-29 at 15:08 +0800, Mao Wenan wrote:
> This patch provides a way to enable relaxed ordering, where it helps
> with performance in some architecture.
> The default value of wro_enable is 0, if you want to enable relaxed
> ordering, please set wro_enable=1.
>
> Mao Wenan (1):
> add one parameter wro_enable for IXGBE
>
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 29
> ++++++++++++++-----
> ------
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 28
> +++++++++++++----
> -------
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++++
> 4 files changed, 41 insertions(+), 26 deletions(-)
Why have a title patch for only one patch? Better yet, the one patch does not have a patch description. Get rid of the title patch and add the above information into the patches description.
In addition, module parameters are not kindly looked upon, one reason is that it cannot be standardized and enforced.
I am also confused because you are stating that on some architectures, yet this code is only compiled in when SPARC is defined and that there are times when you want relaxed ordering enabled and other times disabled?
Your gonna have to provide more data on why, because the code as is was resolving serious performance issues on SPARC when relaxed ordering was enabled.
^ permalink raw reply
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Greg KH @ 2016-11-09 9:44 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Kernel Build Reports Mailman List,
Olof's autobuilder, stable, Eric W. Biederman
In-Reply-To: <CAOesGMgee=Cdm5+aW6_F2LwL+1Bg2szmTY6__gqAM539kif93w@mail.gmail.com>
On Tue, Nov 08, 2016 at 02:17:41PM -0800, Olof Johansson wrote:
> On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >> Here are the build results from automated periodic testing.
> >>
> >> The tree being built was stable-rc, found at:
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >>
> >> Topmost commit:
> >>
> >> f821e08 Linux 4.4.31-rc1
> >>
> >> Build logs (stderr only) can be found at the following link (experimental):
> >>
> >> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> >
> > These seem to be largely caused by building with gcc-6. It's probably
> > a good idea to keep supporting that configuration though and
> > backport the fixes. Here are the upstream commit IDs I've found.
>
> That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
>
> It's not entirely reasonable to expect older releases to build with
> new toolchains without warnings, and I'm not sure if it makes sense to
> bring back those fixes to -stable (unless they fix real bugs, of
> course).
My test-builder system is using gcc-6, and I do keep track of warnings
as it is a good indication that an applied patch is wrong (found a bug
in an i2c patch just yesterday because of it.)
I'm currently seeing only 3 warnings on x86 for 4.4-stable and gcc-6,
and just found the fix for one of them, so I'll gladly take warning
fixes that resolve issues to make it easier for the real problems to
jump out at us.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/5] wic: check that filesystem is specified for a rootfs partition
From: Ed Bartosh @ 2016-11-09 9:44 UTC (permalink / raw)
To: Maciej Borzecki; +Cc: Maciej Borzecki, openembedded-core
In-Reply-To: <9d17d4a574a0a2b809f832b33a0af41fb7682ea4.1478619682.git.maciej.borzecki@rndity.com>
On Tue, Nov 08, 2016 at 04:56:09PM +0100, Maciej Borzecki wrote:
> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
> ---
> scripts/lib/wic/partition.py | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 8adc698240c8e3bd9f4118663a5d7a167e0bb4a4..24e657592738dc7c5cdff78e3740d7c373021e9d 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -184,6 +184,10 @@ class Partition():
> if os.path.isfile(rootfs):
> os.remove(rootfs)
>
> + if not self.fstype:
> + msger.error("File system for partition %s not specified in kickstart, " \
> + "use --fstype option" % (self.mountpoint))
> +
Would it make sense to make --fstype mandatory in ksparser?
> for prefix in ("ext", "btrfs", "vfat", "squashfs"):
> if self.fstype.startswith(prefix):
> method = getattr(self, "prepare_rootfs_" + prefix)
> --
> 2.5.0
>
--
--
Regards,
Ed
^ permalink raw reply
* [Buildroot] [PATCH] patchelf: bump version to 0.9
From: Jérôme Pouiller @ 2016-11-09 9:43 UTC (permalink / raw)
To: buildroot
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/patchelf/patchelf.hash | 2 +-
package/patchelf/patchelf.mk | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/patchelf/patchelf.hash b/package/patchelf/patchelf.hash
index 0da413e..14154a3 100644
--- a/package/patchelf/patchelf.hash
+++ b/package/patchelf/patchelf.hash
@@ -1,2 +1,2 @@
# Locally calculated
-sha256 14af06a2da688d577d64ff8dac065bb8903bbffbe01d30c62df7af9bf4ce72fe patchelf-0.8.tar.gz
+sha256 f2aa40a6148cb3b0ca807a1bf836b081793e55ec9e5540a5356d800132be7e0a patchelf-0.9.tar.gz
diff --git a/package/patchelf/patchelf.mk b/package/patchelf/patchelf.mk
index 043224d..5222e57 100644
--- a/package/patchelf/patchelf.mk
+++ b/package/patchelf/patchelf.mk
@@ -4,8 +4,8 @@
#
################################################################################
-PATCHELF_VERSION = 0.8
-PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.8
+PATCHELF_VERSION = 0.9
+PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.9
PATCHELF_LICENSE = GPLv3+
PATCHELF_LICENSE_FILES = COPYING
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] fstests: btrfs: Check false ENOSPC bug caused by incorrect metadata reserve
From: Eryu Guan @ 2016-11-09 9:43 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs, fstests
In-Reply-To: <d9a9d224-2f21-5b77-a3e9-de271cd4e755@cn.fujitsu.com>
On Wed, Nov 09, 2016 at 08:24:38AM +0800, Qu Wenruo wrote:
>
>
> At 11/08/2016 06:58 PM, Eryu Guan wrote:
> > On Tue, Nov 08, 2016 at 05:15:15PM +0800, Qu Wenruo wrote:
> > > Due to the fact that btrfs uses different max extent size for
> > > compressed and non-compressed write, it calculates metadata reservation
> > > incorrectly.
> > >
> > > This can leads to false ENOSPC alert for compressed write.
> > >
> > > This test case will check it by using small fs and large nodesize, and
> > > do parallel compressed write to trigger it.
> > >
> > > The fix is not merged and may change in the future, but the function is
> > > good enough:
> > > btrfs: improve inode's outstanding_extents computation
> > > btrfs: fix false enospc for compression
> > >
> > > Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> > > ---
[snip]
> > > +
> > > +# Use small filesystem with maximum nodesize.
> > > +# Since the false ENOSPC happens due to incorrect metadata reservation,
> > > +# larger nodesize and small fs will make it much easier to reproduce
> > > +_scratch_mkfs -b 512M -n 64k >> $seqres.full 2>&1
> >
> > How about override MKFS_OPTIONS and call _scratch_mkfs_sized? e.g.
> >
> > export MKFS_OPTIONS="-n 64k"
> > _scratch_mkfs_sized $((512 * 1024 * 1024))
>
> Overriding MKFS_OPTIONS makes us unable to parse more mkfs options, for
> example to test some incompatible features.
>
> So I'd just parse this mkfs options as extra options.
We should use helpers and not open-code when helpers are available. So
we should really use _scratch_mkfs_sized here.
And "-n 64k" is only to make bug easier to reproduce, but I don't think
it's necessary. In my testings, 50%-75% runs hit the ENOSPC failure on
my x86_64 test vm, even I removed the "-n 64k" mkfs option from the
test.
So I'd say remove "-n 64k" and test whatever mkfs options user
specified.
> >
> > > +_scratch_mount "-o compress"
And compress mount option is not necessary to me either. btrfs compress
is a commonly tested configuration, there's no need to force the
compress option in the test. So we can test other configurations too.
Thanks,
Eryu
^ permalink raw reply
* [Intel-wired-lan] 答复: [PATCH] add one parameter wro_enable to enable relaxed ordering for IXGBE
From: maowenan @ 2016-11-09 9:43 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <1477726941.2309.9.camel@intel.com>
I have verified that the performance will be enhanced certainly when I enabled Relax Ordering on SPARC, but think it is not very flexible to disable or enable Relax Ordering feature using CONFIG_SPARC currently,
So I want to use module parameter to set RO instead of "#ifndef CONFIG_SPARC", no need to rebuild the whole kernel.
-----????-----
???: Jeff Kirsher [mailto:jeffrey.t.kirsher at intel.com]
????: 2016?10?29? 15:42
???: maowenan; intel-wired-lan at lists.osuosl.org; netdev at vger.kernel.org; linux-kernel at vger.kernel.org
??: Re: [PATCH] add one parameter wro_enable to enable relaxed ordering for IXGBE
On Sat, 2016-10-29 at 15:08 +0800, Mao Wenan wrote:
> This patch provides a way to enable relaxed ordering, where it helps
> with performance in some architecture.
> The default value of wro_enable is 0, if you want to enable relaxed
> ordering, please set wro_enable=1.
>
> Mao Wenan (1):
> ? add one parameter wro_enable for IXGBE
>
> ?drivers/net/ethernet/intel/ixgbe/ixgbe.h??????? |? 1 +
> ?drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c? | 29
> ++++++++++++++-----
> ------
> ?drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 28
> +++++++++++++----
> -------
> ?drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?? |? 9 ++++++++
> ?4 files changed, 41 insertions(+), 26 deletions(-)
Why have a title patch for only one patch? ?Better yet, the one patch does not have a patch description. ?Get rid of the title patch and add the above information into the patches description.
In addition, module parameters are not kindly looked upon, one reason is that it cannot be standardized and enforced.
I am also confused because you are stating that on some architectures, yet this code is only compiled in when SPARC is defined and that there are times when you want relaxed ordering enabled and other times disabled?
?Your gonna have to provide more data on why, because the code as is was resolving serious performance issues on SPARC when relaxed ordering was enabled.
^ permalink raw reply
* [PATCH] sparc32: Fix inverted invalid_frame_pointer checks on sigreturns
From: Andreas Larsson @ 2016-11-09 9:43 UTC (permalink / raw)
To: David Miller, sparclinux; +Cc: Sam Ravnborg, linux-kernel, software
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
---
arch/sparc/kernel/signal_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/signal_32.c b/arch/sparc/kernel/signal_32.c
index c3c12ef..9c0c8fd 100644
--- a/arch/sparc/kernel/signal_32.c
+++ b/arch/sparc/kernel/signal_32.c
@@ -89,7 +89,7 @@ asmlinkage void do_sigreturn(struct pt_regs *regs)
sf = (struct signal_frame __user *) regs->u_regs[UREG_FP];
/* 1. Make sure we are not getting garbage from the user */
- if (!invalid_frame_pointer(sf, sizeof(*sf)))
+ if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv_and_exit;
if (get_user(ufp, &sf->info.si_regs.u_regs[UREG_FP]))
@@ -150,7 +150,7 @@ asmlinkage void do_rt_sigreturn(struct pt_regs *regs)
synchronize_user_stack();
sf = (struct rt_signal_frame __user *) regs->u_regs[UREG_FP];
- if (!invalid_frame_pointer(sf, sizeof(*sf)))
+ if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv;
if (get_user(ufp, &sf->regs.u_regs[UREG_FP]))
--
2.8.0
^ permalink raw reply related
* Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Jani Nikula @ 2016-11-09 9:42 UTC (permalink / raw)
To: Martin Steigerwald, intel-gfx
Cc: Intel Gfx Mailing List, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <2133270.BvWHEGSr0T@merkaba>
On Wed, 09 Nov 2016, Martin Steigerwald <martin@lichtvoll.de> wrote:
> Also no graphics glitches with external DisplayPort connected display.
Thanks for confirming this. The fix should make it to -rc5.
> *However*, I got a soft freeze and a hard freeze (well after about a
> minute I gave up and rebooted by pressing power button long enough to
> forcefully switch off the laptop) when playing PlaneShift using
> drm-intel-fixes branch.
>
> Unfortunately I have no further time to debug any of this week, but it
> seems not all fixes are there are ready for next stable kernel.
Current drm-intel-fixes is just six commits on top of -rc4, and it's
very hard for me to believe any of those would cause the symptoms you
see. I presume the problem, whatever it is, is already in -rc4.
That, of course, is not a happy thing per se, but please don't block the
current batch of fixes by making unsubstantiated claims. Please do file
a bug about that issue over at [1] so we don't hijack this thread.
Thanks,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Jani Nikula @ 2016-11-09 9:42 UTC (permalink / raw)
To: Martin Steigerwald, intel-gfx
Cc: Intel Gfx Mailing List, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <2133270.BvWHEGSr0T@merkaba>
On Wed, 09 Nov 2016, Martin Steigerwald <martin@lichtvoll.de> wrote:
> Also no graphics glitches with external DisplayPort connected display.
Thanks for confirming this. The fix should make it to -rc5.
> *However*, I got a soft freeze and a hard freeze (well after about a
> minute I gave up and rebooted by pressing power button long enough to
> forcefully switch off the laptop) when playing PlaneShift using
> drm-intel-fixes branch.
>
> Unfortunately I have no further time to debug any of this week, but it
> seems not all fixes are there are ready for next stable kernel.
Current drm-intel-fixes is just six commits on top of -rc4, and it's
very hard for me to believe any of those would cause the symptoms you
see. I presume the problem, whatever it is, is already in -rc4.
That, of course, is not a happy thing per se, but please don't block the
current batch of fixes by making unsubstantiated claims. Please do file
a bug about that issue over at [1] so we don't hijack this thread.
Thanks,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2] spi: atmel: use managed resource for gpio chip select
From: Alexandre Belloni @ 2016-11-09 9:34 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Mark Brown, linux, Boris BREZILLON, linux-spi, geert,
Ludovic Desroches, linux-arm-kernel, linux-kernel,
Cyrille Pitchen, Wenyou Yang
In-Reply-To: <8756e0f4-de7b-5d89-2561-ace18d157d91@atmel.com>
On 09/11/2016 at 10:16:18 +0100, Nicolas Ferre wrote :
> Le 08/11/2016 à 18:49, Alexandre Belloni a écrit :
> > On 08/11/2016 at 18:48:52 +0100, Nicolas Ferre wrote :
> >> Use the managed gpio CS pin request so that we avoid having trouble
> >> in the cleanup code.
> >> In fact, if module was configured with DT, cleanup code released
> >> invalid pin. Since resource wasn't freed, module cannot be reinserted.
> >>
> >> This require to extract the gpio request call from the "setup" function
> >> and call it in the appropriate probe function.
> >>
> >> Reported-by: Alexander Morozov <linux@meltdown.ru>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >
> > I think that's fine but I still have that item on my todo list
> > (discussion in july 2014 with Mark):
> >
> > ---
> >>> Mark: maybe it would make sense to do devm_gpio_request_one() in
> >>> of_spi_register_master(), after of_get_named_gpio.
> >
> >> You need to transition all the drivers doing things manually but yes.
> >> As I keep saying all the GPIO handling needs to be completely
> >> refactored.
> > ---
>
> Would make sense indeed as we are currently doing the same node scanning
> twice...
>
> But this patch actually fixes an issue with module unloading/re-loading
> and freeing of a wrong gpio. So I do think that we shouldn't hold its
> adoption while thinking about this enhancement...
>
Yes, this patch is still useful as-is and fixes a bug.
> Regards,
>
> >> ---
> >> v2: fix devm_gpio_request location: the setup code for device was not proper
> >> location. Move it to the probe function and add needed DT routines to
> >> handle all CS gpio specified.
> >>
> >> drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
> >> 1 file changed, 39 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> >> index 32683a13dd60..a60925614480 100644
> >> --- a/drivers/spi/spi-atmel.c
> >> +++ b/drivers/spi/spi-atmel.c
> >> @@ -24,6 +24,7 @@
> >>
> >> #include <linux/io.h>
> >> #include <linux/gpio.h>
> >> +#include <linux/of_gpio.h>
> >> #include <linux/pinctrl/consumer.h>
> >> #include <linux/pm_runtime.h>
> >>
> >> @@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
> >> u32 csr;
> >> unsigned int bits = spi->bits_per_word;
> >> unsigned int npcs_pin;
> >> - int ret;
> >>
> >> as = spi_master_get_devdata(spi->master);
> >>
> >> @@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
> >> if (!asd)
> >> return -ENOMEM;
> >>
> >> - if (as->use_cs_gpios) {
> >> - ret = gpio_request(npcs_pin, dev_name(&spi->dev));
> >> - if (ret) {
> >> - kfree(asd);
> >> - return ret;
> >> - }
> >> -
> >> + if (as->use_cs_gpios)
> >> gpio_direction_output(npcs_pin,
> >> !(spi->mode & SPI_CS_HIGH));
> >> - }
> >>
> >> asd->npcs_pin = npcs_pin;
> >> spi->controller_state = asd;
> >> @@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
> >> static void atmel_spi_cleanup(struct spi_device *spi)
> >> {
> >> struct atmel_spi_device *asd = spi->controller_state;
> >> - unsigned gpio = (unsigned long) spi->controller_data;
> >>
> >> if (!asd)
> >> return;
> >>
> >> spi->controller_state = NULL;
> >> - gpio_free(gpio);
> >> kfree(asd);
> >> }
> >>
> >> @@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
> >> }
> >>
> >> /*-------------------------------------------------------------------------*/
> >> +static int atmel_spi_gpio_cs(struct platform_device *pdev)
> >> +{
> >> + struct spi_master *master = platform_get_drvdata(pdev);
> >> + struct atmel_spi *as = spi_master_get_devdata(master);
> >> + struct device_node *np = master->dev.of_node;
> >> + int i;
> >> + int ret = 0;
> >> + int nb = 0;
> >> +
> >> + if (!as->use_cs_gpios)
> >> + return 0;
> >> +
> >> + if (!np)
> >> + return 0;
> >> +
> >> + nb = of_gpio_named_count(np, "cs-gpios");
> >> + for (i = 0; i < nb; i++) {
> >> + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> >> + "cs-gpios", i);
> >> +
> >> + if (cs_gpio == -EPROBE_DEFER)
> >> + return cs_gpio;
> >> +
> >> + if (gpio_is_valid(cs_gpio)) {
> >> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> >> + dev_name(&pdev->dev));
> >> + if (ret)
> >> + return ret;
> >> + }
> >> + }
> >> +
> >> + return 0;
> >> +}
> >>
> >> static int atmel_spi_probe(struct platform_device *pdev)
> >> {
> >> @@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
> >> master->num_chipselect = 4;
> >> }
> >>
> >> + ret = atmel_spi_gpio_cs(pdev);
> >> + if (ret)
> >> + goto out_unmap_regs;
> >> +
> >> as->use_dma = false;
> >> as->use_pdc = false;
> >> if (as->caps.has_dma_support) {
> >> --
> >> 2.9.0
> >>
> >
>
>
> --
> Nicolas Ferre
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Razvan Cojocaru @ 2016-11-09 9:42 UTC (permalink / raw)
To: xen-devel
Cc: kevin.tian, tamas, suravee.suthikulpanit, Razvan Cojocaru,
andrew.cooper3, julien.grall, jbeulich, sstabellini, jun.nakajima,
boris.ostrovsky
Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
which is now fired in a one-shot manner when enabled via the new
VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
The patch also fixes the behaviour of the xc_hvm_inject_trap()
hypercall, which would lead to non-architectural interrupts
overwriting pending (specifically reinjected) architectural ones.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
---
xen/arch/x86/hvm/hvm.c | 20 ++++++++++++++++----
xen/arch/x86/hvm/monitor.c | 15 +++++++++++++++
xen/arch/x86/hvm/svm/svm.c | 16 ++++++++++++++++
xen/arch/x86/hvm/vmx/vmx.c | 21 +++++++++++++++++++++
xen/arch/x86/vm_event.c | 6 ++++++
xen/common/vm_event.c | 3 +++
xen/include/asm-arm/vm_event.h | 6 ++++++
xen/include/asm-x86/hvm/hvm.h | 7 +++++++
xen/include/asm-x86/hvm/monitor.h | 2 ++
xen/include/asm-x86/vm_event.h | 1 +
xen/include/public/vm_event.h | 15 +++++++++++++++
xen/include/xen/vm_event.h | 2 ++
12 files changed, 110 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 704fd64..06c426c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
}
}
- /* Inject pending hw/sw trap */
- if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
- {
+ /* Inject pending hw/sw trap if there are no other pending interrupts. */
+ if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
- v->arch.hvm_vcpu.inject_trap.vector = -1;
+
+ v->arch.hvm_vcpu.inject_trap.vector = -1;
+
+ if ( unlikely(v->arch.vm_event) &&
+ v->arch.vm_event->monitor_next_interrupt )
+ {
+ struct hvm_trap info;
+
+ if ( hvm_get_pending_event(v, &info) )
+ {
+ hvm_monitor_interrupt(info.vector, info.type, info.error_code,
+ info.cr2);
+ v->arch.vm_event->monitor_next_interrupt = false;
+ }
}
}
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 401a8c6..00b2c3b 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -150,6 +150,21 @@ int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
return monitor_traps(curr, 1, &req);
}
+void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
+ unsigned int err, uint64_t cr2)
+{
+ struct vcpu *curr = current;
+ vm_event_request_t req = {
+ .reason = VM_EVENT_REASON_INTERRUPT,
+ .u.interrupt.vector = vector,
+ .u.interrupt.type = type,
+ .u.interrupt.error_code = err,
+ .u.interrupt.cr2 = cr2,
+ };
+
+ monitor_traps(curr, 1, &req);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 16427f6..bba0399 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2220,6 +2220,21 @@ static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
svm_asid_g_invlpg(v, vaddr);
}
+static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+ if ( vmcb->eventinj.fields.v )
+ return false;
+
+ info->vector = vmcb->eventinj.fields.vector;
+ info->type = vmcb->eventinj.fields.type;
+ info->error_code = vmcb->eventinj.fields.errorcode;
+ info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
+
+ return true;
+}
+
static struct hvm_function_table __initdata svm_function_table = {
.name = "SVM",
.cpu_up_prepare = svm_cpu_up_prepare,
@@ -2272,6 +2287,7 @@ static struct hvm_function_table __initdata svm_function_table = {
.tsc_scaling = {
.max_ratio = ~TSC_RATIO_RSVD_BITS,
},
+ .get_pending_event = svm_get_pending_event,
};
void svm_vmexit_handler(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..6f64033 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2134,6 +2134,26 @@ static int vmx_set_mode(struct vcpu *v, int mode)
return 0;
}
+static bool vmx_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ unsigned long intr_info, error_code;
+
+ vmx_vmcs_enter(v);
+ __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+ __vmread(VM_ENTRY_EXCEPTION_ERROR_CODE, &error_code);
+ vmx_vmcs_exit(v);
+
+ if ( !(intr_info & INTR_INFO_VALID_MASK) )
+ return false;
+
+ info->vector = MASK_EXTR(intr_info, INTR_INFO_VECTOR_MASK);
+ info->type = MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK);
+ info->error_code = error_code;
+ info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
+
+ return true;
+}
+
static struct hvm_function_table __initdata vmx_function_table = {
.name = "VMX",
.cpu_up_prepare = vmx_cpu_up_prepare,
@@ -2203,6 +2223,7 @@ static struct hvm_function_table __initdata vmx_function_table = {
.max_ratio = VMX_TSC_MULTIPLIER_MAX,
.setup = vmx_setup_tsc_scaling,
},
+ .get_pending_event = vmx_get_pending_event,
};
/* Handle VT-d posted-interrupt when VCPU is blocked. */
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 1e88d67..a153ec5 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -134,6 +134,12 @@ void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
v->arch.user_regs.eip = rsp->data.regs.x86.rip;
}
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+ ASSERT(v->arch.vm_event);
+ v->arch.vm_event->monitor_next_interrupt = true;
+}
+
void vm_event_fill_regs(vm_event_request_t *req)
{
const struct cpu_user_regs *regs = guest_cpu_user_regs();
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 907ab40..c947706 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -433,6 +433,9 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved)
if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
vm_event_set_registers(v, &rsp);
+ if ( rsp.flags & VM_EVENT_FLAG_GET_NEXT_INTERRUPT )
+ vm_event_monitor_next_interrupt(v);
+
if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
vm_event_vcpu_unpause(v);
}
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 66f2474..ab9c8cb 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
/* Not supported on ARM. */
}
+static inline
+void vm_event_monitor_next_interrupt(struct vcpu *v)
+{
+ /* Not supported on ARM. */
+}
+
#endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 7e7462e..e6d91ea 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -237,6 +237,8 @@ struct hvm_function_table {
/* Architecture function to setup TSC scaling ratio */
void (*setup)(struct vcpu *v);
} tsc_scaling;
+
+ bool (*get_pending_event)(struct vcpu *v, struct hvm_trap *info);
};
extern struct hvm_function_table hvm_funcs;
@@ -428,6 +430,11 @@ static inline int hvm_event_pending(struct vcpu *v)
return hvm_funcs.event_pending(v);
}
+static inline bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
+{
+ return hvm_funcs.get_pending_event(v, info);
+}
+
/* These bits in CR4 are owned by the host. */
#define HVM_CR4_HOST_MASK (mmu_cr4_features & \
(X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE))
diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hvm/monitor.h
index 82b85ec..85ca678 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -42,6 +42,8 @@ int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
unsigned long trap_type, unsigned long insn_length);
int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
unsigned int subleaf);
+void hvm_monitor_interrupt(unsigned int vector, unsigned int type,
+ unsigned int err, uint64_t cr2);
#endif /* __ASM_X86_HVM_MONITOR_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index ca73f99..b5cd872 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -32,6 +32,7 @@ struct arch_vm_event {
struct vm_event_emul_insn_data insn;
} emul;
struct monitor_write_data write_data;
+ bool monitor_next_interrupt;
};
int vm_event_init_domain(struct domain *d);
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index c28be5a..5c8c31e 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -105,6 +105,11 @@
* if any of those flags are set, only those will be honored).
*/
#define VM_EVENT_FLAG_SET_EMUL_INSN_DATA (1 << 9)
+/*
+ * Have a one-shot VM_EVENT_REASON_INTERRUPT event sent for the first
+ * interrupt occuring after resuming the VCPU.
+ */
+#define VM_EVENT_FLAG_GET_NEXT_INTERRUPT (1 << 10)
/*
* Reasons for the vm event request
@@ -139,6 +144,8 @@
* These kinds of events will be filtered out in future versions.
*/
#define VM_EVENT_REASON_PRIVILEGED_CALL 11
+/* Result of toolstack-requested (non-architectural) trap injection. */
+#define VM_EVENT_REASON_INTERRUPT 12
/* Supported values for the vm_event_write_ctrlreg index. */
#define VM_EVENT_X86_CR0 0
@@ -259,6 +266,13 @@ struct vm_event_cpuid {
uint32_t _pad;
};
+struct vm_event_interrupt {
+ uint32_t vector;
+ uint32_t type;
+ uint32_t error_code;
+ uint64_t cr2;
+};
+
#define MEM_PAGING_DROP_PAGE (1 << 0)
#define MEM_PAGING_EVICT_FAIL (1 << 1)
@@ -302,6 +316,7 @@ typedef struct vm_event_st {
struct vm_event_debug software_breakpoint;
struct vm_event_debug debug_exception;
struct vm_event_cpuid cpuid;
+ struct vm_event_interrupt interrupt;
} u;
union {
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 4f088c8..2fb3951 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -78,6 +78,8 @@ void vm_event_vcpu_unpause(struct vcpu *v);
void vm_event_fill_regs(vm_event_request_t *req);
void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
+void vm_event_monitor_next_interrupt(struct vcpu *v);
+
#endif /* __VM_EVENT_H__ */
/*
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH] gpu: ipu-di: silence videomode logspam
From: Philipp Zabel @ 2016-11-09 9:41 UTC (permalink / raw)
To: Lucas Stach; +Cc: kernel, dri-devel, patchwork-lst
In-Reply-To: <20161108155755.18379-1-l.stach@pengutronix.de>
Am Dienstag, den 08.11.2016, 16:57 +0100 schrieb Lucas Stach:
> Adapting the videomode to the hardware constraints is something that
> can and must happen during normal operation and isn't something that
> the user can avoid. So printing a warning each time it happens isn't
> helpful.
>
> Demote this message to the debug level.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Greg Kroah-Hartman @ 2016-11-09 9:41 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Luis R. Rodriguez, Geert Uytterhoeven, Lukas Wunner,
Rafael J. Wysocki, Linux PM list, Alan Stern,
Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
Marek Szyprowski, Kevin Hilman, Ulf Hansson, Laurent Pinchart,
Lars-Peter Clausen, Grant Likely, Mauro Carvalho Chehab,
Dmitry Torokhov
In-Reply-To: <32dbffe7-5c68-88f9-4631-7b9cd6bf445e@samsung.com>
On Wed, Nov 09, 2016 at 10:36:54AM +0100, Andrzej Hajda wrote:
> On 09.11.2016 07:45, Greg Kroah-Hartman wrote:
> > On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote:
> >>>> Furthermore -- how does this framework compare to Andrzej's resource tracking
> >>>> solution? I confess I have not had a chance yet to review yet but in light of
> >>>> this question it would be good to know if Andrzej's framework also requires
> >>>> deferred probe as similar concerns would exist there as well.
> >>> I have no idea what "framework" you are talking about here, do you have
> >>> a pointer to patches?
> >> I'm surprised given Andrzej did both Cc you on his patches [2] *and* chimed
> >> in on Rafael's patches to indicate that we likely can integrate PM concerns
> >> into his own "framework" [3]. There was no resolution to this discussion, however
> >> its not IMHO sufficient to brush off Andrzej's points in particular because
> >> Andrzej *is* indicating that his framework:
> > Dude, those patches were from 2014! I can't remember patches people
> > sent to me a month ago...
> >
> >> - Eliminates deferred probe and resulting late_initcall(), consumer registers
> >> callbacks informing when given resources (clock, regulator, etc) becomes
> >> available
> >> - Properly handle resource disappearance (driver unbind, hotplug)
> >> - Track resources which are not vital to the device, but can influence behavior
> >> - Offers simplified resource allocation
> >> - Can be easily expanded to help with power management
> >>
> >> Granted I have not reviewed this yet but it at least was on my radar, and
> >> I do believe its worth reviewing this further given the generally expressed
> >> interest to see if we can have a common framework to address both ordering
> >> problems, suspend and probe. At a quick glance the "ghost provider" idea
> >> seems like a rather crazy idea but hey, there may be some goods in there.
> > >From what I remember, and I could be totally wrong, these patches were
> > way too complex and required that every subsystem change their
> > interfaces. That's not going to work out well, but read the email
> > threads for the details...
>
> I haven't seen your comment on my patches, except few general questions
> regarding one of earlier version of the framework.
> So maybe you are talking about different framework.
>
> Regarding complexity, if the subsystem have simple way of
> '(un)publishing' resources it just adds single calls to restrack core:
> restrack_up, restrack_down in proper places.
> Additionally it adds quite simple stuff to encapsulate resource
> description and allocation routines into generic *_restrack_desc
> structure, see for example patch adding restrack to phy framework[1].
Ok, again, I have no idea what my response was to a 2 year-old patchset,
again, I can't remember my response to a patchset that was sent just a
month ago...
update it, and repost and we can all go from there if you think it is a
viable solution.
thanks,
greg k-h
^ permalink raw reply
* Re: Seeking help in getting run-tox-ceph-detect-init to work.
From: Willem Jan Withagen @ 2016-11-09 9:41 UTC (permalink / raw)
To: kefu chai; +Cc: Ceph Development
In-Reply-To: <CAJE9aOOj-A-kkBzjyOei7JHRY=qRmT_fVF9L7M_wFyypMKvoBQ@mail.gmail.com>
On 9-11-2016 09:17, kefu chai wrote:
> On Wed, Nov 9, 2016 at 6:57 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> Hi,
>>
>> I'm looking for a developer with more Python experience....
>> Especially with getting things thru tox.
>>
>> I was able to add FreeBSD support to ceph-detect-init in #11829. But
>> then that is tested in run-tox-detect-init. Which now fails in a Linux
>> Jenkins run:
>> https://jenkins.ceph.com/job/ceph-pull-requests/13621/consoleFull#124607955c19247c4-fcb7-4c61-9a5d-7e2b9731c678
>>
>> But that heavily depends on mock and variations on
>> platform.linux_distribution(), which is over my head.
>>
>> Like:
>> def test_get(self):
>> g = ceph_detect_init.get
>> with mock.patch('platform.linux_distribution',
>> lambda **kwargs: (('unknown', '', ''))):
>> self.assertRaises(exc.UnsupportedPlatform, g)
>>
>> Which hits the assert because linux_distribution() returns
>> (' ', ' ', ' ')
>> and the system info needs to be extracted from other functions.
>>
>> The brutal way would be to override this test, but the question then is
>> with what? Because there is no one function that returns the required
>> values. So the code would be a copy from what is in the _init_.py code.
>>
>> And that feels like a butcher testing his own meat.
>
> yes, you need to mock some methods get called in
> platform_information(), please see the updated patch at:
> https://github.com/tchaikov/ceph/commit/fced2823c311bee2be0d226759809fc10170a6ff
>
> in which, i also added a test for unsupported system.
Cool,
I sort of understand the code, and indeed you are copying the working
code from the module.
But this what it delivers.
--WjW
=================================== FAILURES
===================================
13: _________________________ TestCephDetectInit.test_get
__________________________
13: NOTE: Incompatible Exception Representation, displaying natively:
13:
13: _StringException: Traceback (most recent call last):
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/tests/test_all.py", line
155, in test_get
13: self.assertRaises(exc.UnsupportedPlatform, g)
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 485, in assertRaises
13: self.assertThat(our_callable, matcher)
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
13: raise mismatch_error
13: testtools.matchers._impl.MismatchError: <function get at
0x8089b1500> returned <module 'ceph_detect_init.freebsd' from
'/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/ceph_detect_init/freebsd/__init__.pyc'>
13:
13:
13: _________________ TestCephDetectInit.test_platform_information
_________________
13: NOTE: Incompatible Exception Representation, displaying natively:
13:
13: _StringException: Traceback (most recent call last):
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/tests/test_all.py", line
234, in test_platform_information
13: ceph_detect_init.platform_information())
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
13: self.assertThat(observed, matcher, message)
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
13: raise mismatch_error
13: testtools.matchers._impl.MismatchError: ('debian', '6.0', 'squeeze')
!= ('freebsd', '12.0-CURRENT', 'r306554M:')
13:
13:
13: _________________________ TestCephDetectInit.test_run
__________________________
13: NOTE: Incompatible Exception Representation, displaying natively:
13:
13: _StringException: Traceback (most recent call last):
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/tests/test_all.py", line
262, in test_run
13: self.assertRaises(exc.UnsupportedPlatform, main.run, argv)
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 485, in assertRaises
13: self.assertThat(our_callable, matcher)
13: File
"/usr/srcs/Ceph/work/ceph/src/ceph-detect-init/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
13: raise mismatch_error
13: testtools.matchers._impl.MismatchError: <function run at
0x8089b17d0> returned 0
13:
--WjW
^ 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.