* Re: [PATCH 6/6] usb: musb: Drop pointless PM runtime code for dsps glue
From: Johan Hovold @ 2016-11-14 15:59 UTC (permalink / raw)
To: Tony Lindgren
Cc: Bin Liu, Boris Brezillon, Greg Kroah-Hartman, Andreas Kemnade,
Felipe Balbi, George Cherian, Kishon Vijay Abraham I,
Ivaylo Dimitrov, Johan Hovold, Ladislav Michl, Laurent Pinchart,
Sergei Shtylyov, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161111184302.2438-7-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Fri, Nov 11, 2016 at 10:43:02AM -0800, Tony Lindgren wrote:
> This already gets done automatically by PM runtime and we have
> a separate autosuspend timeout in musb_core.c.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> @@ -816,8 +801,6 @@ static int dsps_remove(struct platform_device *pdev)
> platform_device_unregister(glue->musb);
>
> /* disable usbss clocks */
Perhaps also drop this comment which no longer applies.
> - pm_runtime_dont_use_autosuspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
Reviewed-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] powerpc/mm: Batch tlb flush when invalidating pte entries
From: Aneesh Kumar K.V @ 2016-11-14 15:58 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
This will improve the task exit case, by batching tlb invalidates.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/book3s/64/radix.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index aec6e8ee6e27..e8b4f39e9fab 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -147,10 +147,16 @@ static inline unsigned long radix__pte_update(struct mm_struct *mm,
* new value of pte
*/
new_pte = (old_pte | set) & ~clr;
- psize = radix_get_mmu_psize(pg_sz);
- radix__flush_tlb_page_psize(mm, addr, psize);
-
- __radix_pte_update(ptep, 0, new_pte);
+ /*
+ * If we are trying to clear the pte, we can skip
+ * the below sequence and batch the tlb flush. The
+ * tlb flush batching is done by mmu gather code
+ */
+ if (new_pte) {
+ psize = radix_get_mmu_psize(pg_sz);
+ radix__flush_tlb_page_psize(mm, addr, psize);
+ __radix_pte_update(ptep, 0, new_pte);
+ }
} else
old_pte = __radix_pte_update(ptep, clr, set);
asm volatile("ptesync" : : : "memory");
--
2.10.2
^ permalink raw reply related
* [PATCH V7 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-14 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG2=9p_SKF4TAbbqF6L4u=y9-_m73vZJ3tOAbRKHCT0MOsLwGQ@mail.gmail.com>
On Fri, 21 Oct 2016 20:13:13 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 18 Oct 2016 16:08:58 +0800
> > Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> >
> >> Currently Function traces can be only exported to ring buffer, this
> >> patch added trace_export concept which can process traces and export
> >> them to a registered destination as an addition to the current only
> >> one output of Ftrace - i.e. ring buffer.
> >>
> >> In this way, if we want Function traces to be sent to other destination
> >> rather than ring buffer only, we just need to register a new trace_export
> >> and implement its own .write() function for writing traces to storage.
> >>
> >> With this patch, only Function trace (trace type is TRACE_FN)
> >> is supported.
> >
> > This is getting better, but I still have some nits.
> >
>
> Thanks.
>
> >>
> >> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> >> ---
> >> include/linux/trace.h | 28 +++++++++++
> >> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
> >> 2 files changed, 159 insertions(+), 1 deletion(-)
> >> create mode 100644 include/linux/trace.h
> >>
> >> diff --git a/include/linux/trace.h b/include/linux/trace.h
> >> new file mode 100644
> >> index 0000000..eb1c5b8
> >> --- /dev/null
> >> +++ b/include/linux/trace.h
> >> @@ -0,0 +1,28 @@
> >> +#ifndef _LINUX_TRACE_H
> >> +#define _LINUX_TRACE_H
> >> +
> >> +#ifdef CONFIG_TRACING
> >> +/*
> >> + * The trace export - an export of Ftrace output. The trace_export
> >> + * can process traces and export them to a registered destination as
> >> + * an addition to the current only output of Ftrace - i.e. ring buffer.
> >> + *
> >> + * If you want traces to be sent to some other place rather than ring
> >> + * buffer only, just need to register a new trace_export and implement
> >> + * its own .write() function for writing traces to the storage.
> >> + *
> >> + * next - pointer to the next trace_export
> >> + * write - copy traces which have been delt with ->commit() to
> >> + * the destination
> >> + */
> >> +struct trace_export {
> >> + struct trace_export __rcu *next;
> >> + void (*write)(const char *, unsigned int);
> >
> > Why const char*? Why not const void *? This will never be a string.
> >
>
> Will revise this.
>
> >
> >> +};
> >> +
> >> +int register_ftrace_export(struct trace_export *export);
> >> +int unregister_ftrace_export(struct trace_export *export);
> >> +
> >> +#endif /* CONFIG_TRACING */
> >> +
> >> +#endif /* _LINUX_TRACE_H */
> >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> >> index 8696ce6..db94ec1 100644
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -40,6 +40,7 @@
> >> #include <linux/poll.h>
> >> #include <linux/nmi.h>
> >> #include <linux/fs.h>
> >> +#include <linux/trace.h>
> >> #include <linux/sched/rt.h>
> >>
> >> #include "trace.h"
> >> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
> >> ftrace_trace_userstack(buffer, flags, pc);
> >> }
> >>
> >> +static void
> >> +trace_process_export(struct trace_export *export,
> >> + struct ring_buffer_event *event)
> >> +{
> >> + struct trace_entry *entry;
> >> + unsigned int size = 0;
> >> +
> >> + entry = ring_buffer_event_data(event);
> >> +
> >> + size = ring_buffer_event_length(event);
> >> +
> >> + if (export->write)
> >> + export->write((char *)entry, size);
> >
> > Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
> >
> > And if there is, this can be racy. As in
> >
> >
> > CPU 0: CPU 1:
> > ------ ------
> > if (export->write)
> >
> > export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
Then why have a
if (export->write)
Is there every going to be a case where export will not have a write
function?
-- Steve
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
>
> Thanks for the review,
> Chunyan
>
> >
> > export->write(entry, size);
> >
> > BOOM!
> >
> >
> > -- Steve
^ permalink raw reply
* Re: [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Joerg Roedel @ 2016-11-14 15:59 UTC (permalink / raw)
To: Robin Murphy
Cc: catalin.marinas-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>
> v4: Add the missed static qualifier (thanks Catalin)
>
> drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
> include/linux/dma-iommu.h | 4 ++++
> 2 files changed, 25 insertions(+), 3 deletions(-)
Applied both, thanks Robin.
^ permalink raw reply
* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Joerg Roedel @ 2016-11-14 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> v4: Add the missed static qualifier (thanks Catalin)
>
> drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
> include/linux/dma-iommu.h | 4 ++++
> 2 files changed, 25 insertions(+), 3 deletions(-)
Applied both, thanks Robin.
^ permalink raw reply
* Re: [PATCH V7 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-14 15:59 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Mathieu Poirier, Alexander Shishkin, mingo, Mike Leach,
Tor Jeremiassen, philippe.langlais, Nicolas GUION, Felipe Balbi,
Lyra Zhang, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAG2=9p_SKF4TAbbqF6L4u=y9-_m73vZJ3tOAbRKHCT0MOsLwGQ@mail.gmail.com>
On Fri, 21 Oct 2016 20:13:13 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 18 Oct 2016 16:08:58 +0800
> > Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> >
> >> Currently Function traces can be only exported to ring buffer, this
> >> patch added trace_export concept which can process traces and export
> >> them to a registered destination as an addition to the current only
> >> one output of Ftrace - i.e. ring buffer.
> >>
> >> In this way, if we want Function traces to be sent to other destination
> >> rather than ring buffer only, we just need to register a new trace_export
> >> and implement its own .write() function for writing traces to storage.
> >>
> >> With this patch, only Function trace (trace type is TRACE_FN)
> >> is supported.
> >
> > This is getting better, but I still have some nits.
> >
>
> Thanks.
>
> >>
> >> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> >> ---
> >> include/linux/trace.h | 28 +++++++++++
> >> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
> >> 2 files changed, 159 insertions(+), 1 deletion(-)
> >> create mode 100644 include/linux/trace.h
> >>
> >> diff --git a/include/linux/trace.h b/include/linux/trace.h
> >> new file mode 100644
> >> index 0000000..eb1c5b8
> >> --- /dev/null
> >> +++ b/include/linux/trace.h
> >> @@ -0,0 +1,28 @@
> >> +#ifndef _LINUX_TRACE_H
> >> +#define _LINUX_TRACE_H
> >> +
> >> +#ifdef CONFIG_TRACING
> >> +/*
> >> + * The trace export - an export of Ftrace output. The trace_export
> >> + * can process traces and export them to a registered destination as
> >> + * an addition to the current only output of Ftrace - i.e. ring buffer.
> >> + *
> >> + * If you want traces to be sent to some other place rather than ring
> >> + * buffer only, just need to register a new trace_export and implement
> >> + * its own .write() function for writing traces to the storage.
> >> + *
> >> + * next - pointer to the next trace_export
> >> + * write - copy traces which have been delt with ->commit() to
> >> + * the destination
> >> + */
> >> +struct trace_export {
> >> + struct trace_export __rcu *next;
> >> + void (*write)(const char *, unsigned int);
> >
> > Why const char*? Why not const void *? This will never be a string.
> >
>
> Will revise this.
>
> >
> >> +};
> >> +
> >> +int register_ftrace_export(struct trace_export *export);
> >> +int unregister_ftrace_export(struct trace_export *export);
> >> +
> >> +#endif /* CONFIG_TRACING */
> >> +
> >> +#endif /* _LINUX_TRACE_H */
> >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> >> index 8696ce6..db94ec1 100644
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -40,6 +40,7 @@
> >> #include <linux/poll.h>
> >> #include <linux/nmi.h>
> >> #include <linux/fs.h>
> >> +#include <linux/trace.h>
> >> #include <linux/sched/rt.h>
> >>
> >> #include "trace.h"
> >> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
> >> ftrace_trace_userstack(buffer, flags, pc);
> >> }
> >>
> >> +static void
> >> +trace_process_export(struct trace_export *export,
> >> + struct ring_buffer_event *event)
> >> +{
> >> + struct trace_entry *entry;
> >> + unsigned int size = 0;
> >> +
> >> + entry = ring_buffer_event_data(event);
> >> +
> >> + size = ring_buffer_event_length(event);
> >> +
> >> + if (export->write)
> >> + export->write((char *)entry, size);
> >
> > Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
> >
> > And if there is, this can be racy. As in
> >
> >
> > CPU 0: CPU 1:
> > ------ ------
> > if (export->write)
> >
> > export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
Then why have a
if (export->write)
Is there every going to be a case where export will not have a write
function?
-- Steve
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
>
> Thanks for the review,
> Chunyan
>
> >
> > export->write(entry, size);
> >
> > BOOM!
> >
> >
> > -- Steve
^ permalink raw reply
* GIT Problem/ISSUE
From: Robert Fellendorf @ 2016-11-14 15:59 UTC (permalink / raw)
To: git
Dear Git Team,
I'm having some trouble with my git software. I just would like to
'pull' a project out of a repository.
At the beginning git worked just fine but since a few days ago I'm
constantly getting the error:
Couldn't resolve host 'gitlab.lrz.de'
git did not exit cleanly (exit code 128) (391 ms @ 14.11.2016 16:53:37)
To my architecture: I'm having a Windows 10 Pro Version with the Intel
U6600 processor.
I have Kaspersky running (But, indeed, I also tried it to shut this
software down while testing git - additionally I killed all tasks which
could considered to be a firewall)
Furthermore, I tried to use the ssh protocoll which did'nt worked out,
as well.
I added a ssh key changed the environment variable. Didn't worked as well.
I have a direct link to the internet (in particular I'm not accessing
the internet via a proxy)
A reinstallation of the software did't helped neither.
For your help I would like to thank you already in advance.
Kind Regards
Robert Fellendorf
^ permalink raw reply
* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Luis R. Rodriguez @ 2016-11-14 16:00 UTC (permalink / raw)
To: Lukas Wunner
Cc: Rafael J. Wysocki, Linux PM list, Greg Kroah-Hartman, Alan Stern,
Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
Marek Szyprowski, Kevin Hilman, Ulf Hansson, Grant Likely,
Laurent Pinchart, Lars-Peter Clausen, Andrzej Hajda
In-Reply-To: <20161114154805.GC10141@wunner.de>
On Mon, Nov 14, 2016 at 7:48 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Nov 14, 2016 at 02:48:32PM +0100, Luis R. Rodriguez wrote:
>> On Sun, Nov 13, 2016 at 06:34:13PM +0100, Lukas Wunner wrote:
>> > On Mon, Nov 07, 2016 at 10:39:54PM +0100, Luis R. Rodriguez wrote:
>> > > On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
>> > > > One of the actions carried out by device_link_add() is to reorder
>> > > > the lists used for device shutdown and system suspend/resume to
>> > > > put the consumer device along with all of its children and all of
>> > > > its consumers (and so on, recursively) to the ends of those lists
>> > > > in order to ensure the right ordering between all of the supplier
>> > > > and consumer devices.
>> > >
>> > > There's no explanation as to why this order is ensured to be
>> > > correct, I think its important to document this. From our discussions
>> > > at Plumbers it seems the order is ensured due to the fact that order
>> > > was already implicitly provided through platform firmware (ACPI
>> > > enumeration is one), adjusting order on the dpm list is just shuffling
>> > > order between consumer / provider, but nothing else.
>> >
>> > ACPI specifies a hierarchy and the order on the dpm_list and
>> > devices_kset is such that children are behind their parent.
>> >
>> > A device link specifies a dependency that exists in addition
>> > to the hierarchy, hence consumers need to be moved behind
>> > their supplier. And not only the consumers themselves but
>> > also recursively their children and consumers. Essentially
>> > the entire subtree is moved to the back. That happens in
>> > device_reorder_to_tail() in patch 2.
>>
>> Ah neat, I failed to notice this full subtree tree move, its
>> rather important.
>>
>> > If another device is enumerated which acts as a supplier to
>> > an existing other supplier, that other supplier and all its
>> > dependents are moved behind the newly enumerated device,
>> > and so on.
>> >
>> > That is probably correct so long as no loops are introduced
>> > in the dependency graph.
>>
>> "Probably" is what concerns me, there is no formality about
>> the correctness of this.
>
> It's a typo, I meant to say "provably correct". Sorry.
>
> Quite a difference in meaning. :-)
No sorry my own mistake -- you had written provably but I thought you
had a typo, clearly you meant as you typed :)
If the trees are independent then yes, I can see this working.
>> > That is checked by device_is_dependent(),
>> > which is called from device_link_add(), and the addition of the
>> > link is aborted if a loop is detected.
>>
>> And that is sufficient ?
>
> The device links turn the device tree into a directed acyclic graph.
> For the dpm_list and devices_kset, that graph is flattened into a
> one-dimensional form such that all ancestors and suppliers of a
> device appear in front of that device in the lists. I'm not a
> graph theorist and can't provide a formal proof. I think Rafael
> is a Dr., maybe he can do it. :-)
If you traverse the DAG you can get a linear one-dimensional
representation of the dependencies -- I'm no expert on this either,
however I'm buying what you described above then, provided we do
indeed avoid cycles.
> I merely looked at this from a
> practical point of view, i.e. I tried to come up with corner cases
> where dependencies are added that would result in incorrect ordering,
> and concluded that I couldn't find any.
Fair enough, likewise. I think the takeaway from this discussion is a
test driver trying to break this might be good to have, but also
documenting how this works in practice and how we avoid the cycles is
important. This was not very clear from the patches.
Luis
^ permalink raw reply
* [Qemu-devel] [Bug 1641637] [NEW] incorrect illegal SSE3 instructions reporting on x86_64
From: Jie @ 2016-11-14 15:45 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
Hi all, we found 28 differently encoded illegal SSE3 instructions
reporting on the most recent x86_64 user mode linux qemu (version
2.7.0). We believe these reporting should be incorrect because the same
code can be executed on a real machine. The instructions are the
following:
pabsb %mm0, %mm1
pabsb %xmm0, %xmm1
pabsd %mm0, %mm1
pabsd %xmm0, %xmm1
pabsw %mm0, %mm1
pabsw %xmm0, %xmm1
phaddd %mm0, %mm1
phaddd %xmm0, %xmm1
phaddsw %mm0, %mm1
phaddsw %xmm0, %xmm1
phaddw %mm0, %mm1
phaddw %xmm0, %xmm1
phsubd %mm0, %mm1
phsubd %xmm0, %xmm1
phsubsw %mm0, %mm1
phsubsw %xmm0, %xmm1
phsubw %mm0, %mm1
phsubw %xmm0, %xmm1
pmaddubsw %mm0, %mm1
pmaddubsw %xmm0, %xmm1
pmulhrsw %mm0, %mm1
pmulhrsw %xmm0, %xmm1
psignb %mm0, %mm1
psignb %xmm0, %xmm1
psignd %mm0, %mm1
psignd %xmm0, %xmm1
psignw %mm0, %mm1
psignw %xmm0, %xmm1
The following is the proof of code
/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsb %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 1.c **********/
/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsb %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 2.c **********/
/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 3.c **********/
/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 4.c **********/
/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 5.c **********/
/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 6.c **********/
/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 7.c **********/
/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 8.c **********/
/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 9.c **********/
/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 10.c **********/
/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 11.c **********/
/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 12.c **********/
/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 13.c **********/
/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 14.c **********/
/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 15.c **********/
/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 16.c **********/
/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 17.c **********/
/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 18.c **********/
/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char i2[0x10];
unsigned char i3[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));;
asm("pmaddubsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 19.c **********/
/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char i2[0x10];
unsigned char i3[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));;
asm("pmaddubsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 20.c **********/
/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pmulhrsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 21.c **********/
/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pmulhrsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 22.c **********/
/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignb %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 23.c **********/
/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignb %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 24.c **********/
/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 25.c **********/
/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 26.c **********/
/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 27.c **********/
/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 28.c **********/
For any of the above code, when compiled into x86-64 binary code with
gcc, qemu reports the illegal instructions bug. However, these can be
correctly executed on a real machine. For example,
$ gcc 28.c -o 28
$ qemu-x86_64 ./28
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction
$ ./28
00000000000000000000000000000000
Some information about the system:
$ qemu-x86_64 --version
qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
$ uname -a
Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks!
** Affects: qemu
Importance: Undecided
Status: New
** Information type changed from Private Security to Public
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1641637
Title:
incorrect illegal SSE3 instructions reporting on x86_64
Status in QEMU:
New
Bug description:
Hi all, we found 28 differently encoded illegal SSE3 instructions
reporting on the most recent x86_64 user mode linux qemu (version
2.7.0). We believe these reporting should be incorrect because the
same code can be executed on a real machine. The instructions are the
following:
pabsb %mm0, %mm1
pabsb %xmm0, %xmm1
pabsd %mm0, %mm1
pabsd %xmm0, %xmm1
pabsw %mm0, %mm1
pabsw %xmm0, %xmm1
phaddd %mm0, %mm1
phaddd %xmm0, %xmm1
phaddsw %mm0, %mm1
phaddsw %xmm0, %xmm1
phaddw %mm0, %mm1
phaddw %xmm0, %xmm1
phsubd %mm0, %mm1
phsubd %xmm0, %xmm1
phsubsw %mm0, %mm1
phsubsw %xmm0, %xmm1
phsubw %mm0, %mm1
phsubw %xmm0, %xmm1
pmaddubsw %mm0, %mm1
pmaddubsw %xmm0, %xmm1
pmulhrsw %mm0, %mm1
pmulhrsw %xmm0, %xmm1
psignb %mm0, %mm1
psignb %xmm0, %xmm1
psignd %mm0, %mm1
psignd %xmm0, %xmm1
psignw %mm0, %mm1
psignw %xmm0, %xmm1
The following is the proof of code
/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsb %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 1.c **********/
/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsb %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 2.c **********/
/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 3.c **********/
/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 4.c **********/
/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pabsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 5.c **********/
/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pabsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 6.c **********/
/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 7.c **********/
/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 8.c **********/
/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 9.c **********/
/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 10.c **********/
/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phaddw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 11.c **********/
/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phaddw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 12.c **********/
/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 13.c **********/
/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 14.c **********/
/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 15.c **********/
/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 16.c **********/
/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("phsubw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 17.c **********/
/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("phsubw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 18.c **********/
/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char i2[0x10];
unsigned char i3[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));;
asm("pmaddubsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 19.c **********/
/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char i2[0x10];
unsigned char i3[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));;
asm("pmaddubsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 20.c **********/
/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("pmulhrsw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 21.c **********/
/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("pmulhrsw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 22.c **********/
/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignb %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 23.c **********/
/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignb %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 24.c **********/
/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignd %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 25.c **********/
/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignd %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 26.c **********/
/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
asm("psignw %mm0, %mm1");
asm("mov %0, %%rdx\n"
"movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 27.c **********/
/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char i1[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
asm("mov %0, %%rdx\n"
"movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
asm("psignw %xmm0, %xmm1");
asm("mov %0, %%rdx\n"
"movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
/********** End of bug 28.c **********/
For any of the above code, when compiled into x86-64 binary code with
gcc, qemu reports the illegal instructions bug. However, these can be
correctly executed on a real machine. For example,
$ gcc 28.c -o 28
$ qemu-x86_64 ./28
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction
$ ./28
00000000000000000000000000000000
Some information about the system:
$ qemu-x86_64 --version
qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
$ uname -a
Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1641637/+subscriptions
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Phil Turmel @ 2016-11-14 16:01 UTC (permalink / raw)
To: Bruce Merry; +Cc: Wols Lists, linux-raid
In-Reply-To: <CAHy4j_6q2mmQ_y-xkh1Zx6CrP1vByQMadCXLJwibeeO85T3JgQ@mail.gmail.com>
Hi Bruce,
On 11/14/2016 01:50 AM, Bruce Merry wrote:
> Okay, I'll give that script a go to increase my kernel timeout. If I
> understand correctly, it's not the end of the world if the drive
> doesn't support SCTERC, provided I have a long kernel timeout (and
> when things go wrong it might take much longer to recover, but I can
> live with that). Is that correct?
Yes.
>> 2) Trim. Well-behaved drive firmware guarantees zeros for trimmed
>> sectors, but many drives return random data instead. Zing, mismatches.
>> It's often unhelpful with encrypted volumes, as even well-behaved
>> firmware can't deliver zeroed sectors *inside* the encryption.
>
> Weee, sounds like fun. I hope it's that. Is there any way to tell
> which blocks mismatch, so that I can tell which files are in trouble
> (assuming I can figure out how to map through LVM, LUKS and
> debuge2fs).
The check operation doesn't log the sector addresses, unfortunately. At
least I don't see any such operation in the code that increments
mismatch count. Not even a tracepoint. Hmmm.
In the meantime, run a "repair" scrub instead of a "check" scrub to
affirmatively force no mismatches. (Writes first member of mirrors to
the others.)
Phil
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Sekhar Nori @ 2016-11-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
Some kernel configuration options required for systemd
support are missing in davinci_all_defconfig. Add them.
This is based on recommendations in:
http://cgit.freedesktop.org/systemd/systemd/tree/README
Options which kernel enables by default (and will thus be removed
upon next savedefconfig update) are not included.
Tested on OMAP-L138 LCDK board with fully up to date armv5
archlinux filesystem.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/configs/davinci_all_defconfig | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978ff177f..bdc62e69807a 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -7,13 +7,13 @@ CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
+CONFIG_CHECKPOINT_RESTORE=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
@@ -34,6 +34,7 @@ CONFIG_DAVINCI_MUX_WARNINGS=y
CONFIG_DAVINCI_RESET_CLOCKS=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
+CONFIG_SECCOMP=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
@@ -52,7 +53,6 @@ CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_NETFILTER=y
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
@@ -189,11 +189,13 @@ CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
+CONFIG_TMPFS_XATTR=y
CONFIG_JFFS2_FS=m
CONFIG_UBIFS_FS=m
CONFIG_CRAMFS=y
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 1/2] mfd: rn5t618: Add Ricoh RC5T619 PMIC support
From: Rob Herring @ 2016-11-14 16:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161105161925.14910-2-phh-8tEavu1zA38@public.gmane.org>
On Sat, Nov 05, 2016 at 05:19:24PM +0100, Pierre-Hugues Husson wrote:
> The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
> the differences are:
>
> + DCDC4/DCDC5
> + LDO7-10
> + Slightly different output voltage/currents
> + 32kHz Output
> + RTC
> + USB Charger detection
>
> Signed-off-by: Pierre-Hugues Husson <phh-8tEavu1zA38@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/rn5t618.txt | 16 ++++++++++------
> drivers/mfd/Kconfig | 3 ++-
> drivers/mfd/rn5t618.c | 1 +
> include/linux/mfd/rn5t618.h | 9 +++++++++
> 4 files changed, 22 insertions(+), 7 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [PATCH 1/2] mfd: rn5t618: Add Ricoh RC5T619 PMIC support
From: Rob Herring @ 2016-11-14 16:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones, mark.rutland, lgirdwood, broonie, devicetree,
linux-kernel
In-Reply-To: <20161105161925.14910-2-phh@phh.me>
On Sat, Nov 05, 2016 at 05:19:24PM +0100, Pierre-Hugues Husson wrote:
> The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
> the differences are:
>
> + DCDC4/DCDC5
> + LDO7-10
> + Slightly different output voltage/currents
> + 32kHz Output
> + RTC
> + USB Charger detection
>
> Signed-off-by: Pierre-Hugues Husson <phh@phh.me>
> ---
> Documentation/devicetree/bindings/mfd/rn5t618.txt | 16 ++++++++++------
> drivers/mfd/Kconfig | 3 ++-
> drivers/mfd/rn5t618.c | 1 +
> include/linux/mfd/rn5t618.h | 9 +++++++++
> 4 files changed, 22 insertions(+), 7 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* RE: [PATCH v2] upload-pack: Optionally allow fetching any sha1
From: David Turner @ 2016-11-14 16:02 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <xmqqpom0yxyo.fsf@gitster.mtv.corp.google.com>
Sorry about that -- the first version of this patch noted:
"""This one is on top of yesterday's patch, "remote-curl: don't hang when
a server dies before any output".
That's because I want my test to show that allowanysha1inhead allows a
fetch to succeed where allowreachablesha1inhead would fail. Prior to
the previous patch, the first fetch's failure would instead be a hang.""""
But I didn't carry over this message to v2.
> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Saturday, November 12, 2016 8:23 PM
> To: David Turner
> Cc: git@vger.kernel.org; spearce@spearce.org
> Subject: Re: [PATCH v2] upload-pack: Optionally allow fetching any sha1
>
> David Turner <dturner@twosigma.com> writes:
>
> > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
> > index 43665ab..8d3db40 100755
>
> It seems that I haven't heard of 43665ab.
>
> > --- a/t/t5551-http-fetch-smart.sh
> > +++ b/t/t5551-http-fetch-smart.sh
> > @@ -306,6 +306,28 @@ test_expect_success 'test allowreachablesha1inwant
> with unreachable' '
> > test_must_fail git -C test_reachable.git fetch origin "$(git rev-
> parse HEAD)"
> > '
>
> Specifically, the above seems to be missing in my tree.
>
> Perhaps you noticed the lack of test for allowReachableSHA1InWant and
> added one, but forgot to send it out, while building this patch on top?
>
> > +uploadpack.allowAnySHA1InWant::
> > + Allow `upload-pack` to accept a fetch request that asks for any
> > + object at all.
> > + Defaults to `false`.
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Bruce Merry @ 2016-11-14 16:03 UTC (permalink / raw)
To: Wols Lists; +Cc: linux-raid
In-Reply-To: <5829DF1F.7030109@youngman.org.uk>
On 14 November 2016 at 17:58, Wols Lists <antlists@youngman.org.uk> wrote:
> On 14/11/16 15:52, Bruce Merry wrote:
>> On 13 November 2016 at 23:06, Wols Lists <antlists@youngman.org.uk> wrote:
>>> > Sounds like that drive could need replacing. I'd get a new drive and do
>>> > that as soon as possible - use the --replace option of mdadm - don't
>>> > fail the old drive and add the new.
>> Would you mind explaining why I should use --replace instead of taking
>> out the suspect drive? I guess I lose redundancy for any writes that
>> occur while the rebuild is happening, but I'd plan to do this with the
>> filesystem unmounted so there wouldn't be any writes.
>
> Because a replace will copy from the old drive to the new, recovering
> any failures from the rest of the array. A fail-and-add will have to
> rebuild the entire new array from what's left of the old, stressing the
> old array much more.
Okay, I can see how for RAID5 that might be a bad thing.
In my case however, it sounds like --replace will copy everything from
the failing drive, whereas I'd rather it copied everything from the
good drive. Same stress on the array, less chance of copying dodgy
data.
Bruce
--
Dr Bruce Merry
bmerry <@> gmail <.> com
http://www.brucemerry.org.za/
http://blog.brucemerry.org.za/
^ permalink raw reply
* Re: [PATCH] usb: dwc2: add amcc,dwc-otg device tree definition
From: Rob Herring @ 2016-11-14 16:04 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, John Youn, Mark Rutland,
Greg Kroah-Hartman
In-Reply-To: <20161106005608.26386-1-chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sun, Nov 06, 2016 at 01:56:08AM +0100, Christian Lamparter wrote:
> This patch adds support for the "amcc,usb-otg" device
> which is found in the PowerPC Canyonlands' dts.
>
> The device definition was added by:
> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'.
> AMCC produced a standalone driver that was sent to the
> linuxppc-dev at the time. However, it was never integrated.
>
> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> For anyone interested: the driver was sent to the ML multiple times back
> in 2012 [0], [1].
>
> [0] <https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-May/097847.html>
> [1] <https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-May/097938.html>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
I would say this needs to be more specific, but given it has been there
for 6 years:
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/usb/dwc2/platform.c | 33 ++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Alexandre Belloni @ 2016-11-14 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla@arm.com>
On 14/11/2016 at 15:44:08 +0000, Sudeep Holla wrote :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Alexandre Belloni @ 2016-11-14 16:04 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On 14/11/2016 at 15:44:08 +0000, Sudeep Holla wrote :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [PATCH 4/6] perf config: Add support for writing configs to a config file
From: Arnaldo Carvalho de Melo @ 2016-11-14 16:04 UTC (permalink / raw)
To: Taeung Song
Cc: linux-kernel, Jiri Olsa, Namhyung Kim, Ingo Molnar,
Peter Zijlstra, Wang Nan, Nambong Ha, Wookje Kwon
In-Reply-To: <1478241862-31230-5-git-send-email-treeze.taeung@gmail.com>
Em Fri, Nov 04, 2016 at 03:44:20PM +0900, Taeung Song escreveu:
> Add setting feature that can add config variables with their values
> to a config file (i.e. user or system config file) or modify
> config key-value pairs in a config file.
> For the syntax examples,
>
> perf config [<file-option>] [section.name[=value] ...]
>
> e.g. You can set the ui.show-headers to false with
>
> # perf config ui.show-headers=false
>
> If you want to add or modify several config items, you can do like
>
> # perf config annotate.show_nr_jumps=false kmem.default=slab
This works, but has some problems, see below:
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> ---
> tools/perf/builtin-config.c | 66 ++++++++++++++++++++++++++++++++++++++++-----
> tools/perf/util/config.c | 6 +++++
> tools/perf/util/config.h | 2 ++
> 3 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
> index fe253f3..5313702 100644
> --- a/tools/perf/builtin-config.c
> +++ b/tools/perf/builtin-config.c
> @@ -17,7 +17,7 @@
> static bool use_system_config, use_user_config;
>
> static const char * const config_usage[] = {
> - "perf config [<file-option>] [options] [section.name ...]",
> + "perf config [<file-option>] [options] [section.name[=value] ...]",
> NULL
> };
>
> @@ -33,6 +33,37 @@ static struct option config_options[] = {
> OPT_END()
> };
>
> +static int set_config(struct perf_config_set *set, const char *file_name,
> + const char *var, const char *value)
> +{
> + struct perf_config_section *section = NULL;
> + struct perf_config_item *item = NULL;
> + const char *first_line = "# this file is auto-generated.";
> + FILE *fp = fopen(file_name, "w");
> +
> + if (!fp)
> + return -1;
> + if (set == NULL)
> + return -1;
So, here fp is left open? I'm fixing this...
> + perf_config_set__collect(set, var, value);
> + fprintf(fp, "%s\n", first_line);
> +
> + /* overwrite configvariables */
missing space?
> + perf_config_items__for_each_entry(&set->sections, section) {
> + fprintf(fp, "[%s]\n", section->name);
> +
> + perf_config_items__for_each_entry(§ion->items, item) {
> + if (item->value)
> + fprintf(fp, "\t%s = %s\n",
> + item->name, item->value);
> + }
> + }
> + fclose(fp);
> +
> + return 0;
> +}
> +
> static int show_spec_config(struct perf_config_set *set, const char *var)
> {
> struct perf_config_section *section;
> @@ -82,7 +113,7 @@ static int show_config(struct perf_config_set *set)
> return 0;
> }
>
> -static int parse_config_arg(char *arg, char **var)
> +static int parse_config_arg(char *arg, char **var, char **value)
> {
> const char *last_dot = strchr(arg, '.');
>
> @@ -99,7 +130,21 @@ static int parse_config_arg(char *arg, char **var)
> return -1;
> }
>
> - *var = arg;
> + *value = strchr(arg, '=');
> + if (*value == NULL)
> + *var = arg;
> + else if (!strcmp(*value, "=")) {
> + pr_err("The config variable does not contain a value: %s\n", arg);
> + return -1;
> + } else {
> + *value = *value + 1; /* excluding a first character '=' */
> + *var = strsep(&arg, "=");
> + if (*var[0] == '\0') {
> + pr_err("invalid config variable: %s\n", arg);
> + return -1;
> + }
> + }
> +
> return 0;
> }
>
> @@ -153,7 +198,8 @@ int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
> default:
> if (argc) {
> for (i = 0; argv[i]; i++) {
> - char *var, *arg = strdup(argv[i]);
> + char *var, *value;
> + char *arg = strdup(argv[i]);
>
> if (!arg) {
> pr_err("%s: strdup failed\n", __func__);
> @@ -161,13 +207,21 @@ int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
> break;
> }
>
> - if (parse_config_arg(arg, &var) < 0) {
> + if (parse_config_arg(arg, &var, &value) < 0) {
> free(arg);
> ret = -1;
> break;
> }
>
> - ret = show_spec_config(set, var);
> + if (value == NULL)
> + ret = show_spec_config(set, var);
> + else {
> + const char *config_filename = config_exclusive_filename;
> +
> + if (!config_exclusive_filename)
> + config_filename = user_config;
> + ret = set_config(set, config_filename, var, value);
> + }
> free(arg);
> }
> } else
> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
> index 18dae74..c8fb65d 100644
> --- a/tools/perf/util/config.c
> +++ b/tools/perf/util/config.c
> @@ -602,6 +602,12 @@ static int collect_config(const char *var, const char *value,
> return -1;
> }
>
> +int perf_config_set__collect(struct perf_config_set *set,
> + const char *var, const char *value)
> +{
> + return collect_config(var, value, set);
> +}
> +
> static int perf_config_set__init(struct perf_config_set *set)
> {
> int ret = -1;
> diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
> index 6f813d4..0fcdb8c 100644
> --- a/tools/perf/util/config.h
> +++ b/tools/perf/util/config.h
> @@ -33,6 +33,8 @@ const char *perf_etc_perfconfig(void);
>
> struct perf_config_set *perf_config_set__new(void);
> void perf_config_set__delete(struct perf_config_set *set);
> +int perf_config_set__collect(struct perf_config_set *set,
> + const char *var, const char *value);
> void perf_config__init(void);
> void perf_config__exit(void);
> void perf_config__refresh(void);
> --
> 2.7.4
^ permalink raw reply
* Re: dm-cache issue
From: Alexander Pashaliyski @ 2016-11-14 16:05 UTC (permalink / raw)
To: Zdenek Kabelac, dm-devel
In-Reply-To: <884adfe3-ac18-5e37-f4b4-478e5031f35f@redhat.com>
On 11/14/2016 05:34 PM, Zdenek Kabelac wrote:
> Dne 14.11.2016 v 16:02 Alexander Pashaliyski napsal(a):
>> Hi guys,
>>
>>
>> I am in a process of evaluating dm-cache for our backup system.
>>
>> Currently I have an issue when restart the backup server. The server is
>> booting for hours, because of IO load. It seems is triggered a flush
>> from SSD
>> disk (that is used for a cache device) to the raid controllers (they
>> are with
>> slow SATA disks).
>> I have 10 cached logical volumes in *writethrough mode*, each with 2T
>> of data
>> over 2 raid controllers. I use a single SSD disk for the cache.
>> The backup system is with lvm2-2.02.164-1 & kernel 4.4.30.
>>
>>
>> Do you have any ideas why such flush is triggered? In writethrough
>> cache mode
>> we shouldn't have dirty blocks in the cache.
>>
>
> Hi
>
> Have you ensured there was proper shutdown ?
> Cache needs to be properly deactivated - if it's just turned off,
> all metadata are marked dirty.
>
>
> Regards
>
> Zdenek
>
Hi Zdenek,
Thank you for your answer.
Yes, I am sure. I have modified the lvm2 init script to de-activate all
logical volumes and then volume groups, but the issue still persist.
Regards,
Alex
^ permalink raw reply
* Re: [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Heiko Stuebner @ 2016-11-14 16:05 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Mark Yao, Yakir Yang, Douglas Anderson, David Wu, Jianqun Xu,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zhangqing,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Will Deacon, Ziyuan Xu, Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-4-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang:
> From: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add the core display-subsystem node and the two display controllers
> available on the rk3399.
>
> Signed-off-by: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
> ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1290,6 +1290,64 @@
> status = "disabled";
> };
>
> + vopl: vop@ff8f0000 {
> + compatible = "rockchip,rk3399-vop-lit";
> + reg = <0x0 0xff8f0000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
we're usig 4 irq elements nowadays to accomodate the pmus for separate
clusters, see
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd
Same for the edp node.
Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't
able to get any display output yet.
To make the vop at least compile I needed to forward-port
https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b
https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67
[full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ]
but I'm not sure if I did that correctly yet and am also still seeing
nothing on the display and get iommu errors when starting X11
Heiko
> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopl_mmu>;
> + status = "disabled";
> +
> + vopl_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopl_mmu: iommu@ff8f3f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff8f3f00 0x0 0x100>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopl_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + vopb: vop@ff900000 {
> + compatible = "rockchip,rk3399-vop-big";
> + reg = <0x0 0xff900000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopb_mmu>;
> + status = "disabled";
> +
> + vopb_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopb_mmu: iommu@ff903f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff903f00 0x0 0x100>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopb_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + display_subsystem: display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&vopl_out>, <&vopb_out>;
> + status = "disabled";
> + };
> +
> pinctrl: pinctrl {
> compatible = "rockchip,rk3399-pinctrl";
> rockchip,grf = <&grf>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Heiko Stuebner @ 2016-11-14 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-4-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang:
> From: Mark Yao <mark.yao@rock-chips.com>
>
> Add the core display-subsystem node and the two display controllers
> available on the rk3399.
>
> Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
> ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1290,6 +1290,64 @@
> status = "disabled";
> };
>
> + vopl: vop at ff8f0000 {
> + compatible = "rockchip,rk3399-vop-lit";
> + reg = <0x0 0xff8f0000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
we're usig 4 irq elements nowadays to accomodate the pmus for separate
clusters, see
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd
Same for the edp node.
Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't
able to get any display output yet.
To make the vop at least compile I needed to forward-port
https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b
https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67
[full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ]
but I'm not sure if I did that correctly yet and am also still seeing
nothing on the display and get iommu errors when starting X11
Heiko
> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopl_mmu>;
> + status = "disabled";
> +
> + vopl_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopl_mmu: iommu at ff8f3f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff8f3f00 0x0 0x100>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopl_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + vopb: vop at ff900000 {
> + compatible = "rockchip,rk3399-vop-big";
> + reg = <0x0 0xff900000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopb_mmu>;
> + status = "disabled";
> +
> + vopb_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopb_mmu: iommu at ff903f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff903f00 0x0 0x100>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopb_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + display_subsystem: display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&vopl_out>, <&vopb_out>;
> + status = "disabled";
> + };
> +
> pinctrl: pinctrl {
> compatible = "rockchip,rk3399-pinctrl";
> rockchip,grf = <&grf>;
^ permalink raw reply
* Re: [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Robert Yang @ 2016-11-14 16:05 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANniN3J9vLsXu=K3StVyXERoTiAHGb_Ppn_APv+0kYUPUA@mail.gmail.com>
On 11/14/2016 11:38 PM, Christopher Larson wrote:
>
> On Mon, Nov 14, 2016 at 8:37 AM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>
> On 11/14/2016 11:03 PM, Christopher Larson wrote:
>
>
> On Mon, Nov 14, 2016 at 7:34 AM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>
> <mailto:liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.com>>>
> wrote:
>
> The old code:
> network_enabled = not d.getVar('BB_NO_NETWORK', True)
>
> It is True only when BB_NO_NETWORK is not set (None),
> but BB_NO_NETWORK = "0" should also be True while "1" means no network,
> "0" means need network in a normal case.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>
> <mailto:liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.com>>>
> ---
> meta/classes/sanity.bbclass | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 7e383f9..c5e3809 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -363,15 +363,19 @@ def check_connectivity(d):
> test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or
> "").split()
> retval = ""
>
> + bbn = d.getVar('BB_NO_NETWORK', True)
> + if bbn not in (None, '0', '1'):
> + return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"'
> % bbn
>
>
> Does this mirror the same logic used in bitbake? What’s the behavior if it’s
> set, but to the empty string?
>
>
> bitbake only checks whether it equals "1" or not. Without this patch, an empty
> string is the same as not set since it doesn't equal to "1". But if it is
> set to "0", bitbake uses it as enable network, sanity.bbclass uses it
> as disable netowrk, which are conflicted. We can add checking for empty string,
> but do we have to ? Limit it to "0" or "1" makes things clear.
>
>
> IMO if we’re going to change the semantics, we should do it in bitbake and then
> mirror that in the metadata. Sanity checking should mirror the actual variable
> behavior where it’s used.
Sounds reasonable, but I'm not sure how to do it, ways I can think out:
1) Handle "0" as enable network as bitbake does in sanity.bbclass
2) If we want to limit its values, maybe we need check it in bitbake rather
than in sanity.bbclass, there are also other values have the similar
problems, I did a rough grep, such as BB_FETCH_PREMIRRORONLY:
fetch2/__init__.py: premirroronly =
(self.d.getVar("BB_FETCH_PREMIRRORONLY", True) == "1")
fetch2/git.py: if d.getVar("BB_FETCH_PREMIRRORONLY", True) is not None:
The __init__.py only checks whether it is "1" or not, but git.py checks if it
is None, there would be confusions when it is "" or "0".
// Robert
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Heiko Stuebner @ 2016-11-14 16:05 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai, tfiga, Mark Yao, Yakir Yang, Douglas Anderson,
David Wu, Jianqun Xu, devicetree, Brian Norris, linux-kernel,
zhangqing, linux-rockchip, Rob Herring, Will Deacon, Ziyuan Xu,
Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-4-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang:
> From: Mark Yao <mark.yao@rock-chips.com>
>
> Add the core display-subsystem node and the two display controllers
> available on the rk3399.
>
> Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
> ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1290,6 +1290,64 @@
> status = "disabled";
> };
>
> + vopl: vop@ff8f0000 {
> + compatible = "rockchip,rk3399-vop-lit";
> + reg = <0x0 0xff8f0000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
we're usig 4 irq elements nowadays to accomodate the pmus for separate
clusters, see
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd
Same for the edp node.
Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't
able to get any display output yet.
To make the vop at least compile I needed to forward-port
https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b
https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67
[full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ]
but I'm not sure if I did that correctly yet and am also still seeing
nothing on the display and get iommu errors when starting X11
Heiko
> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopl_mmu>;
> + status = "disabled";
> +
> + vopl_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopl_mmu: iommu@ff8f3f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff8f3f00 0x0 0x100>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopl_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + vopb: vop@ff900000 {
> + compatible = "rockchip,rk3399-vop-big";
> + reg = <0x0 0xff900000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopb_mmu>;
> + status = "disabled";
> +
> + vopb_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopb_mmu: iommu@ff903f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff903f00 0x0 0x100>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopb_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + display_subsystem: display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&vopl_out>, <&vopb_out>;
> + status = "disabled";
> + };
> +
> pinctrl: pinctrl {
> compatible = "rockchip,rk3399-pinctrl";
> rockchip,grf = <&grf>;
^ permalink raw reply
* Re: [PATCH] libsepol: fix checkpolicy dontaudit compiler bug
From: Stephen Smalley @ 2016-11-14 16:07 UTC (permalink / raw)
To: selinux
In-Reply-To: <1479139145-32596-1-git-send-email-sds@tycho.nsa.gov>
On 11/14/2016 10:59 AM, Stephen Smalley wrote:
> The combining logic for dontaudit rules was wrong, causing
> a dontaudit A B:C *; rule to be clobbered by a dontaudit A B:C p;
> rule.
>
> Reported-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Sorry, that's not correct either. NAKing my own patch.
> ---
> libsepol/src/expand.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
> index 004a029..cdfb792 100644
> --- a/libsepol/src/expand.c
> +++ b/libsepol/src/expand.c
> @@ -1850,10 +1850,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> */
> avdatump->data &= cur->data;
> } else if (specified & AVRULE_DONTAUDIT) {
> - if (avdatump->data)
> - avdatump->data &= ~cur->data;
> - else
> - avdatump->data = ~cur->data;
> + avdatump->data &= ~cur->data;
> } else if (specified & AVRULE_XPERMS) {
> xperms = avdatump->xperms;
> if (!xperms) {
>
^ 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.