Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument
"Dmitry V. Levin" writes:
> diff --git a/arch/powerpc/include/asm/syscall.h
> b/arch/powerpc/include/asm/syscall.h
> index ab9f3f0a8637..d88b34179118 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -100,9 +100,15 @@ static inline void syscall_set_arguments(struct
> task_struct *task,
> regs->orig_gpr3 = args[0];
> }
>
> -static inline int syscall_get_arch(void)
> +static inline int syscall_get_arch(struct task_struct *task)
> {
> - int arch = is_32bit_task() ? AUDIT_ARCH_PPC : AUDIT_ARCH_PPC64;
> + int arch;
> +
> + if (IS_ENABLED(CONFIG_PPC64) && !test_tsk_thread_flag(task, TIF_32BIT))
> + arch = AUDIT_ARCH_PPC64;
> + else
> + arch = AUDIT_ARCH_PPC;
> +
> #ifdef __LITTLE_ENDIAN__
> arch |= __AUDIT_ARCH_LE;
> #endif
LGTM.
Acked-by: Michael Ellerman (powerpc)
cheers
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
'branches' perf event mapping differs on ARC and ARM
Hi, While playing with perf tool on ARMv7 and ARCv2 processors and profiling the same application I got interesting results. Even if we got pretty similar total execution time and instructions number the number of branches on ARC is about three times more then on ARM. I dug into architecture specific perf sources and found that we map different HW counters into generic 'branches' event on ARC and ARM. - We use "ijmp" event on ARC which counts all jump and branch instructions (regardless of real execution flow - even if no real jump happens) - We use "pc_write_retired" event on ARM which counts only taken branches (Instruction architecturally executed, condition check pass - software change of the PC) So I was wondering do you know which approach is correct? I guess counting all jump and branch instructions is correct because we use 'branches' event value to calculate relative value of 'branch-misses' using following formula: 8 branch-misses-ration = 'branch-misses' / 'branches' * 100.0 8 And using only taken branches here is incorrect IMHO. So I guess we should map 'br_immed_retired' instead of "pc_write_retired" into generic 'branches' event on ARM. -- Eugeniy Paltsev ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: 'branches' perf event mapping differs on ARC and ARM
On 27/11/2018 14:36, Eugeniy Paltsev wrote: Hi, While playing with perf tool on ARMv7 and ARCv2 processors and profiling the same application I got interesting results. Even if we got pretty similar total execution time and instructions number the number of branches on ARC is about three times more then on ARM. I dug into architecture specific perf sources and found that we map different HW counters into generic 'branches' event on ARC and ARM. - We use "ijmp" event on ARC which counts all jump and branch instructions (regardless of real execution flow - even if no real jump happens) - We use "pc_write_retired" event on ARM which counts only taken branches (Instruction architecturally executed, condition check pass - software change of the PC) So I was wondering do you know which approach is correct? I guess counting all jump and branch instructions is correct because we use 'branches' event value to calculate relative value of 'branch-misses' using following formula: 8 branch-misses-ration = 'branch-misses' / 'branches' * 100.0 8 And using only taken branches here is incorrect IMHO. So I guess we should map 'br_immed_retired' instead of "pc_write_retired" into generic 'branches' event on ARM. But register branches (including procedure returns) are also branches, so only counting immediate branches would be just as, if not more, misleading. Robin. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: failing ARC builds in kernelCI
Hi Kevin, On Tue, 2018-11-27 at 07:23 -0800, Kevin Hilman wrote: > Hi Alexey, > > You may have noticed that some defconfigs are failing to build > upstream for ARC. For example, on mainline, both allnoconfig and > tinyconfig fail to build[1]. Actually I haven't seen that! 1. I used to check https://kernelci.org/soc/ but there's still no mention of ARC so I thought builds for ARC are not enabled still. 2. I haven't seen any email notifications as well if they exist at all. That said it would be good if warning emails are sent to our mailing-list linux-snps-arc@lists.infradead.org (see in Cc as well) so somebody reacts on them. > Do you guys have any plans to fix these, or should we disable them? > We currently build these for all the other arches., Sure, let me take a look right now. > > Kevin > > [1] > https://kernelci.org/build/mainline/branch/master/kernel/v4.20-rc4-7-gef78e5ec9214/ -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: failing ARC builds in kernelCI
BTW judging by the error [1] "arc-linux-ld: error: vmlinux.o: unable to merge ISA extension attributes code-density." I may assume we again bump into situation of building ARCompact kernel with ARCv2 toolchain. Also what hints to that problem is our default defconfig is "nsim_700_defconfig" which obviously ARCompact, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Makefile#n9 Thus I think the simplest option would be to switch to say "nsim_hs_defconfig" for default one, but that requires Vineet's ack. -Alexey [1] https://kernelci.org/build/id/5bfd5cbe59b51413138b6da0/logs/ On Tue, 2018-11-27 at 15:38 +, Alexey Brodkin wrote: > Hi Kevin, > > On Tue, 2018-11-27 at 07:23 -0800, Kevin Hilman wrote: > > Hi Alexey, > > > > You may have noticed that some defconfigs are failing to build > > upstream for ARC. For example, on mainline, both allnoconfig and > > tinyconfig fail to build[1]. > > Actually I haven't seen that! > 1. I used to check > https://urldefense.proofpoint.com/v2/url?u=https-3A__kernelci.org_soc_&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=KXGPL3Q7lsPxI1vH-M5m_JDTQ5czcfO7hTNdGXJsqfU&e= > but there's still no mention > of ARC so I thought builds for ARC are not enabled still. > 2. I haven't seen any email notifications as well if they exist at all. > > That said it would be good if warning emails are sent to our mailing-list > linux-snps-arc@lists.infradead.org (see in Cc as well) so somebody reacts on > them. > > > > Do you guys have any plans to fix these, or should we disable them? > > We currently build these for all the other arches., > > Sure, let me take a look right now. > > > Kevin > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__kernelci.org_build_mainline_branch_master_kernel_v4.20-2Drc4-2D7-2Dgef78e5ec9214_&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=mAOgc823jx9R9N4t6nQ4AW9E8kdexU-Y3V5-t50CwJo&e= > > -Alexey > ___ > linux-snps-arc mailing list > linux-snps-arc@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=CjFcD6LV0UctpHpPG5sETrRyEMzZdu4HNEfoozl-y2c&e= ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: 'branches' perf event mapping differs on ARC and ARM
On 11/27/18 6:36 AM, Eugeniy Paltsev wrote: > Hi, > > While playing with perf tool on ARMv7 and ARCv2 processors and profiling the > same application I got interesting results. Even if we got pretty > similar total > execution time and instructions number the number of branches on ARC is about > three times more then on ARM. > > I dug into architecture > specific perf sources and found that we map different > HW counters into generic 'branches' event on ARC and ARM. > - We use "ijmp" event on ARC which > counts all jump and branch instructions (regardless > of real execution flow - even if no real jump happens) That doesn't seem correct IMO. A NOT taken conditional branch doesn't change control flow, so semantically doesn't qualify as a branch. On ARC, the generic branches event should be mapped to "actually taken branches" condition i.e. ijmptak > - We use "pc_write_retired" event on ARM > which counts only taken branches (Instruction > architecturally executed, condition check pass - software change of the PC) That seems correct. > I guess counting all jump and branch instructions is correct because we use > 'branches' event value to calculate relative value of 'branch-misses' using > > following formula: > 8 > branch-misses-ration = 'branch-misses' / 'branches' * 100.0 > > 8 > And using only taken branches here is incorrect IMHO. Why ? branch-misses is a CPU specific micro-arch state where the a changed control flow was NOT predicted. If an implementation mispredicts NOT taken branches, those should actually get counted and be fed to hardware folks to improve the micro-arch. > So I guess we should > map 'br_immed_retired' instead of > "pc_write_retired" into generic 'branches' > event on ARM. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
This series was originally part of the series ("serial: Finish kgdb on
qcom_geni; fix many lockdep splats w/ kgdb") but it made sense to
split it up.
It's believed that dropping into kgdb should be more robust once these
patches are applied.
Changes in v6:
- Moved smp_call_function_single_async() error check to patch 3.
Changes in v5:
- Add a comment about get_irq_regs().
- get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
- for_each_cpu() => for_each_online_cpu()
- Error check smp_call_function_single_async()
Changes in v4:
- Removed smp_mb() calls.
- Also clear out .debuggerinfo.
- Also clear out .debuggerinfo and .task for the master.
- Remove clearing out in kdb_stub for offline CPUs; it's now redundant.
Changes in v3:
- No separate init call.
- Don't round up the CPU that is doing the rounding up.
- Add "#ifdef CONFIG_SMP" to match the rest of the file.
- Updated desc saying we don't solve the "failed to roundup" case.
- Document the ignored parameter.
- Don't round up a CPU that failed rounding up before new for v3.
- Don't back trace on a cpu that didn't round up new for v3.
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).
Douglas Anderson (4):
kgdb: Remove irq flags from roundup
kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
kgdb: Don't round up a CPU that failed rounding up before
kdb: Don't back trace on a cpu that didn't round up
arch/arc/kernel/kgdb.c | 10 +
arch/arm/kernel/kgdb.c | 12 --
arch/arm64/kernel/kgdb.c| 12 --
arch/hexagon/kernel/kgdb.c | 32
arch/mips/kernel/kgdb.c | 9 +
arch/powerpc/kernel/kgdb.c | 6 +--
arch/sh/kernel/kgdb.c | 12 --
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 +
include/linux/kgdb.h| 22 +++
kernel/debug/debug_core.c | 65 -
kernel/debug/debug_core.h | 1 +
kernel/debug/kdb/kdb_bt.c | 11 +-
kernel/debug/kdb/kdb_debugger.c | 7
14 files changed, 98 insertions(+), 112 deletions(-)
--
2.20.0.rc0.387.gc7a69e6b6c-goog
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v6 1/4] kgdb: Remove irq flags from roundup
The function kgdb_roundup_cpus() was passed a parameter that was
documented as:
> the flags that will be used when restoring the interrupts. There is
> local_irq_save() call before kgdb_roundup_cpus().
Nobody used those flags. Anyone who wanted to temporarily turn on
interrupts just did local_irq_enable() and local_irq_disable() without
looking at them. So we can definitely remove the flags.
Signed-off-by: Douglas Anderson
Acked-by: Will Deacon
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
arch/arc/kernel/kgdb.c | 2 +-
arch/arm/kernel/kgdb.c | 2 +-
arch/arm64/kernel/kgdb.c | 2 +-
arch/hexagon/kernel/kgdb.c | 9 ++---
arch/mips/kernel/kgdb.c| 2 +-
arch/powerpc/kernel/kgdb.c | 2 +-
arch/sh/kernel/kgdb.c | 2 +-
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 ++---
include/linux/kgdb.h | 9 ++---
kernel/debug/debug_core.c | 2 +-
11 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..0932851028e0 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -197,7 +197,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), NULL);
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..f21077b077be 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -175,7 +175,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..12c339ff6e75 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -289,7 +289,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..012e0e230ac2 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -119,17 +119,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long
pc)
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them be in a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
* the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
*
* On non-SMP systems, this is not called.
*/
@@ -139,7 +134,7 @@ static void hexagon_kgdb_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..2b05effc17b4 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -219,7 +219,7 @@ static void kgdb_call_nmi_hook(void *ignored)
set_fs(old_fs);
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 59c578f865aa..b0e804844be0 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -124,7 +124,7 @@ static int kgdb_call_nmi_hook(struct pt_regs *regs)
}
#ifdef CONFIG_SMP
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
smp_send_debugger_break();
}
diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
index 4f04c6638a4d..cc57630f6bf2 100644
--- a/arch/sh/kernel/kgdb.c
+++ b/arch/sh/kernel/kgdb.c
@@ -319,7 +319,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+voi
[PATCH v6 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
When I had lockdep turned on and dropped into kgdb I got a nice splat
on my system. Specifically it hit:
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
Specifically it looked like this:
sysrq: SysRq : DEBUG
[ cut here ]
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875
lockdep_hardirqs_on+0xf0/0x160
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
pstate: 604003c9 (nZCv DAIF +PAN -UAO)
pc : lockdep_hardirqs_on+0xf0/0x160
...
Call trace:
lockdep_hardirqs_on+0xf0/0x160
trace_hardirqs_on+0x188/0x1ac
kgdb_roundup_cpus+0x14/0x3c
kgdb_cpu_enter+0x53c/0x5cc
kgdb_handle_exception+0x180/0x1d4
kgdb_compiled_brk_fn+0x30/0x3c
brk_handler+0x134/0x178
do_debug_exception+0xfc/0x178
el1_dbg+0x18/0x78
kgdb_breakpoint+0x34/0x58
sysrq_handle_dbg+0x54/0x5c
__handle_sysrq+0x114/0x21c
handle_sysrq+0x30/0x3c
qcom_geni_serial_isr+0x2dc/0x30c
...
...
irq event stamp: ...45
hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4
hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34
softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
---[ end trace adf21f830c46e638 ]---
Looking closely at it, it seems like a really bad idea to be calling
local_irq_enable() in kgdb_roundup_cpus(). If nothing else that seems
like it could violate spinlock semantics and cause a deadlock.
Instead, let's use a private csd alongside
smp_call_function_single_async() to round up the other CPUs. Using
smp_call_function_single_async() doesn't require interrupts to be
enabled so we can remove the offending bit of code.
In order to avoid duplicating this across all the architectures that
use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
to debug_core.c.
Looking at all the people who previously had copies of this code,
there were a few variants. I've attempted to keep the variants
working like they used to. Specifically:
* For arch/arc we passed NULL to kgdb_nmicallback() instead of
get_irq_regs().
* For arch/mips there was a bit of extra code around
kgdb_nmicallback()
NOTE: In this patch we will still get into trouble if we try to round
up a CPU that failed to round up before. We'll try to round it up
again and potentially hang when we try to grab the csd lock. That's
not new behavior but we'll still try to do better in a future patch.
Suggested-by: Daniel Thompson
Signed-off-by: Douglas Anderson
---
Changes in v6:
- Moved smp_call_function_single_async() error check to patch 3.
Changes in v5:
- Add a comment about get_irq_regs().
- get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
- for_each_cpu() => for_each_online_cpu()
- Error check smp_call_function_single_async()
Changes in v4: None
Changes in v3:
- No separate init call.
- Don't round up the CPU that is doing the rounding up.
- Add "#ifdef CONFIG_SMP" to match the rest of the file.
- Updated desc saying we don't solve the "failed to roundup" case.
- Document the ignored parameter.
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).
arch/arc/kernel/kgdb.c | 10 ++
arch/arm/kernel/kgdb.c | 12 ---
arch/arm64/kernel/kgdb.c | 12 ---
arch/hexagon/kernel/kgdb.c | 27 -
arch/mips/kernel/kgdb.c| 9 +
arch/powerpc/kernel/kgdb.c | 4 ++--
arch/sh/kernel/kgdb.c | 12 ---
include/linux/kgdb.h | 15 --
kernel/debug/debug_core.c | 41 ++
9 files changed, 59 insertions(+), 83 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 0932851028e0..68d9fe4b5aa7 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -192,18 +192,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long
ip)
instruction_pointer(regs) = ip;
}
-static void kgdb_call_nmi_hook(void *ignored)
+void kgdb_call_nmi_hook(void *ignored)
{
+ /* Default implementation passes get_irq_regs() but we don't */
kgdb_nmicallback(raw_smp_processor_id(), NULL);
}
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
#ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index f21077b077be..d9a69e941463 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -170,18 +170,6 @@ static struct undef_hook kgdb_compiled_brkpt_hook = {
.fn = kgdb_compiled_brk_fn
};
-static void kgdb_call_nmi_hook(void *ignored)
-{
- kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
-}
-
-void kgdb_roundup_cpus(void)
-{
- local_irq_enabl
Re: [PATCH v5 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
Hi, On Mon, Nov 26, 2018 at 9:39 PM kbuild test robot wrote: > > Hi Douglas, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on kgdb/kgdb-next] > [also build test ERROR on v4.20-rc4 next-20181126] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Douglas-Anderson/kgdb-Fix-kgdb_roundup_cpus/20181127-115425 > base: https://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git > kgdb-next > config: sparc64-allyesconfig (attached as .config) > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=sparc64 > > Note: the > linux-review/Douglas-Anderson/kgdb-Fix-kgdb_roundup_cpus/20181127-115425 HEAD > b8d0502e65f2d7a2187baa69870146a6fbf18c9f builds fine. > It only hurts bisectibility. > > All errors (new ones prefixed by >>): > >kernel/debug/debug_core.c: In function 'kgdb_roundup_cpus': > >> kernel/debug/debug_core.c:261:18: error: 'struct debuggerinfo_struct' has > >> no member named 'rounding_up' >kgdb_info[cpu].rounding_up = false; > ^ Oops, I squashed this into the wrong patch. It should have been in patch #3. Sorry about that. I'll send out a quick v6. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] u-boot-tools: Improve build preparation
Even though we're not going to build here real U-Boot binary
it is still required to "configure" U-Boot to get get to the
tools building.
We used to use "sandbox_defconfig" for that purpose but
since U-Boot v2018.11 it started to cause problems [1] due to [2].
So to have less dependencies let's create super minimalistic
configuration which is good enough to allow us to run "make tools".
[1] http://errors.yoctoproject.org/Errors/Details/202185/
[2]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a4958a71017fb142542f977c843c5fce769fc6ea
Signed-off-by: Alexey Brodkin
Cc: Richard Purdie
Cc: Otavio Salvador
Cc: Martin Jansa
Cc: Andrea Galbusera
Cc: Ross Burton
Cc: Tom Rini
Cc: Marek Vasut
---
meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
index 127c4c15d1..d1cfea05f5 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
@@ -18,14 +18,11 @@ EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC}
${BUILD_CFLAGS} ${BUILD_LDFLAGS}" H
EXTRA_OEMAKE_class-nativesdk = 'CROSS_COMPILE="${HOST_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
do_compile () {
- oe_runmake sandbox_defconfig
-
- # Disable CONFIG_CMD_LICENSE, license.h is not used by tools and
- # generating it requires bin2header tool, which for target build
- # is built with target tools and thus cannot be executed on host.
- sed -i "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/"
.config
-
- oe_runmake cross_tools NO_SDL=1
+ # Create the simplest configuration which is just enough
+ # to get to the building of tools.
+ echo "CONFIG_SYS_TEXT_BASE=0" > .config
+ oe_runmake olddefconfig
+ oe_runmake cross_tools
}
do_install () {
--
2.16.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
On Mon, Nov 26, 2018 at 07:51:31PM -0800, Douglas Anderson wrote:
> When I had lockdep turned on and dropped into kgdb I got a nice splat
> on my system. Specifically it hit:
> DEBUG_LOCKS_WARN_ON(current->hardirq_context)
>
> Specifically it looked like this:
> sysrq: SysRq : DEBUG
> [ cut here ]
> DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875
> lockdep_hardirqs_on+0xf0/0x160
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
> pstate: 604003c9 (nZCv DAIF +PAN -UAO)
> pc : lockdep_hardirqs_on+0xf0/0x160
> ...
> Call trace:
>lockdep_hardirqs_on+0xf0/0x160
>trace_hardirqs_on+0x188/0x1ac
>kgdb_roundup_cpus+0x14/0x3c
>kgdb_cpu_enter+0x53c/0x5cc
>kgdb_handle_exception+0x180/0x1d4
>kgdb_compiled_brk_fn+0x30/0x3c
>brk_handler+0x134/0x178
>do_debug_exception+0xfc/0x178
>el1_dbg+0x18/0x78
>kgdb_breakpoint+0x34/0x58
>sysrq_handle_dbg+0x54/0x5c
>__handle_sysrq+0x114/0x21c
>handle_sysrq+0x30/0x3c
>qcom_geni_serial_isr+0x2dc/0x30c
> ...
> ...
> irq event stamp: ...45
> hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4
> hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
> softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34
> softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
> ---[ end trace adf21f830c46e638 ]---
>
> Looking closely at it, it seems like a really bad idea to be calling
> local_irq_enable() in kgdb_roundup_cpus(). If nothing else that seems
> like it could violate spinlock semantics and cause a deadlock.
>
> Instead, let's use a private csd alongside
> smp_call_function_single_async() to round up the other CPUs. Using
> smp_call_function_single_async() doesn't require interrupts to be
> enabled so we can remove the offending bit of code.
>
> In order to avoid duplicating this across all the architectures that
> use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
> to debug_core.c.
>
> Looking at all the people who previously had copies of this code,
> there were a few variants. I've attempted to keep the variants
> working like they used to. Specifically:
> * For arch/arc we passed NULL to kgdb_nmicallback() instead of
> get_irq_regs().
> * For arch/mips there was a bit of extra code around
> kgdb_nmicallback()
>
> NOTE: In this patch we will still get into trouble if we try to round
> up a CPU that failed to round up before. We'll try to round it up
> again and potentially hang when we try to grab the csd lock. That's
> not new behavior but we'll still try to do better in a future patch.
>
> Suggested-by: Daniel Thompson
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v5:
> - Add a comment about get_irq_regs().
> - get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
> - for_each_cpu() => for_each_online_cpu()
> - Error check smp_call_function_single_async()
For the arm64 bit:
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 12c339ff6e75..da880247c734 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -284,18 +284,6 @@ static struct step_hook kgdb_step_hook = {
> .fn = kgdb_step_brk_fn
> };
>
> -static void kgdb_call_nmi_hook(void *ignored)
> -{
> - kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> -}
> -
> -void kgdb_roundup_cpus(void)
> -{
> - local_irq_enable();
> - smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> - local_irq_disable();
> -}
> -
Acked-by: Will Deacon
Will
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH] u-boot-tools: Improve build preparation
On Tue, Nov 27, 2018 at 5:13 PM Alexey Brodkin wrote: > Even though we're not going to build here real U-Boot binary > it is still required to "configure" U-Boot to get get to the > tools building. > > We used to use "sandbox_defconfig" for that purpose but > since U-Boot v2018.11 it started to cause problems [1] due to [2]. > > So to have less dependencies let's create super minimalistic > configuration which is good enough to allow us to run "make tools". > > [1] http://errors.yoctoproject.org/Errors/Details/202185/ > [2] > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a4958a71017fb142542f977c843c5fce769fc6ea > > Signed-off-by: Alexey Brodkin To allow extended use, we need to enable CONFIG_FIT_SIGNATURE otherwise we won't have the support. See: # MXSImage needs LibSSL ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),) HOSTLOADLIBES_mkimage += \ $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl -lcrypto") If you do that, we can likely rely on this and avoid some extra tools packages (for example on meta-freescale). -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH] u-boot-tools: Improve build preparation
On Tue, Nov 27, 2018 at 5:30 PM Otavio Salvador wrote: > > On Tue, Nov 27, 2018 at 5:13 PM Alexey Brodkin > wrote: > > Even though we're not going to build here real U-Boot binary > > it is still required to "configure" U-Boot to get get to the > > tools building. > > > > We used to use "sandbox_defconfig" for that purpose but > > since U-Boot v2018.11 it started to cause problems [1] due to [2]. > > > > So to have less dependencies let's create super minimalistic > > configuration which is good enough to allow us to run "make tools". > > > > [1] http://errors.yoctoproject.org/Errors/Details/202185/ > > [2] > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a4958a71017fb142542f977c843c5fce769fc6ea > > > > Signed-off-by: Alexey Brodkin > > To allow extended use, we need to enable CONFIG_FIT_SIGNATURE > otherwise we won't have the support. > > See: > > # MXSImage needs LibSSL > ifneq > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),) > HOSTLOADLIBES_mkimage += \ > $(shell pkg-config --libs libssl libcrypto 2> /dev/null || > echo "-lssl -lcrypto") > > If you do that, we can likely rely on this and avoid some extra tools > packages (for example on meta-freescale). Looking at this, I am wondering if folowing wouldn't be a generic solution capable of upstreaming: diff --git a/configs/nativetools_defconfig b/configs/nativetools_defconfig new file mode 100644 index 00..be69bdf43a --- /dev/null +++ b/configs/nativetools_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_TEXT_BASE=0 +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y diff --git a/tools/Makefile b/tools/Makefile index 3c0521f655..e916d0cebb 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -124,7 +124,7 @@ fit_info-objs := $(dumpimage-mkimage-objs) fit_info.o fit_check_sign-objs := $(dumpimage-mkimage-objs) fit_check_sign.o file2include-objs := file2include.o -ifneq ($(CONFIG_MX23)$(CONFIG_MX28),) +ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_FIT_SIGNATURE),) # Add CONFIG_MXS into host CFLAGS, so we can check whether or not register # the mxsimage support within tools/mxsimage.c . HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH] u-boot-tools: Improve build preparation
Hello all, On Tue, Nov 27, 2018 at 5:52 PM Otavio Salvador wrote: ... > Looking at this, I am wondering if folowing wouldn't be a generic > solution capable of upstreaming: I posted the proposed patch to U-Boot mailing list as RFC so we can see what their feedback is about this approach. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH] u-boot-tools: Improve build preparation
Hi Otavio, On Tue, 2018-11-27 at 17:52 -0200, Otavio Salvador wrote: > On Tue, Nov 27, 2018 at 5:30 PM Otavio Salvador > wrote: > > On Tue, Nov 27, 2018 at 5:13 PM Alexey Brodkin > > wrote: > > > Even though we're not going to build here real U-Boot binary > > > it is still required to "configure" U-Boot to get get to the > > > tools building. > > > > > > We used to use "sandbox_defconfig" for that purpose but > > > since U-Boot v2018.11 it started to cause problems [1] due to [2]. > > > > > > So to have less dependencies let's create super minimalistic > > > configuration which is good enough to allow us to run "make tools". > > > > > > [1] > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__errors.yoctoproject.org_Errors_Details_202185_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=6GBkAGgxs4IOh0rJ4joj36Xukb_msE_tdIIJQXh8Gbg&s=vuvAMfkM9WIKHek7mwuwSjWKKpUcKJ-zCcKypEfxCuw&e= > > > [2] > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.denx.de_-3Fp-3Du-2Dboot.git-3Ba-3Dcommitdiff-3Bh-3Da4958a71017fb142542f977c843c5fce769fc6ea&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=6GBkAGgxs4IOh0rJ4joj36Xukb_msE_tdIIJQXh8Gbg&s=GN4U6Of_hi-W_5CEu3RvRUIVEjgaNwnK8CarkwIly4Y&e= > > > > > > Signed-off-by: Alexey Brodkin > > > > To allow extended use, we need to enable CONFIG_FIT_SIGNATURE > > otherwise we won't have the support. > > > > See: > > > > # MXSImage needs LibSSL > > ifneq > > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),) > > HOSTLOADLIBES_mkimage += \ > > $(shell pkg-config --libs libssl libcrypto 2> /dev/null || > > echo "-lssl -lcrypto") > > > > If you do that, we can likely rely on this and avoid some extra tools > > packages (for example on meta-freescale). > > Looking at this, I am wondering if folowing wouldn't be a generic > solution capable of upstreaming: > > diff --git a/configs/nativetools_defconfig b/configs/nativetools_defconfig > new file mode 100644 > index 00..be69bdf43a > --- /dev/null > +++ b/configs/nativetools_defconfig > @@ -0,0 +1,3 @@ > +CONFIG_SYS_TEXT_BASE=0 > +CONFIG_FIT=y > +CONFIG_FIT_SIGNATURE=y > diff --git a/tools/Makefile b/tools/Makefile > index 3c0521f655..e916d0cebb 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -124,7 +124,7 @@ fit_info-objs := $(dumpimage-mkimage-objs) fit_info.o > fit_check_sign-objs := $(dumpimage-mkimage-objs) fit_check_sign.o > file2include-objs := file2include.o > > -ifneq ($(CONFIG_MX23)$(CONFIG_MX28),) > +ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_FIT_SIGNATURE),) > # Add CONFIG_MXS into host CFLAGS, so we can check whether or not register > # the mxsimage support within tools/mxsimage.c . > HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS So do you think there's a room for improvement in my patch for OE? Or before we get a missing part for tools/Makefile there's nothing more to be done in OE? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: failing ARC builds in kernelCI
Alexey Brodkin writes: > Hi Kevin, > > On Tue, 2018-11-27 at 07:23 -0800, Kevin Hilman wrote: >> Hi Alexey, >> >> You may have noticed that some defconfigs are failing to build >> upstream for ARC. For example, on mainline, both allnoconfig and >> tinyconfig fail to build[1]. > > Actually I haven't seen that! > 1. I used to check https://kernelci.org/soc/ but there's still no mention > of ARC so I thought builds for ARC are not enabled still. Yeah, the /soc/ page is currently for boot results, not build results > 2. I haven't seen any email notifications as well if they exist at all. The list where all the general build/boot reports go is here[1], and here's an example[2] showing the warnings/errors. > That said it would be good if warning emails are sent to our mailing-list > linux-snps-arc@lists.infradead.org (see in Cc as well) so somebody reacts on > them. Unfortunately, we don't have a way of sending arch-specific mails at the moment. > >> Do you guys have any plans to fix these, or should we disable them? >> We currently build these for all the other arches., > > Sure, let me take a look right now. Thanks, Kevin >> >> Kevin >> >> [1] >> https://kernelci.org/build/mainline/branch/master/kernel/v4.20-rc4-7-gef78e5ec9214/ > > -Alexey [1] https://lists.linaro.org/mailman/listinfo/kernel-build-reports [2] https://lists.linaro.org/pipermail/kernel-build-reports/2018-November/039387.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: change defconfig defaults to ARCv2
Change the default defconfig (used with 'make defconfig') to the ARCv2 nsim_hs_defconfig, and also switch the default Kconfig ISA selection to ARCv2. This allows several default defconfigs (e.g. make defconfig, make allnoconfig, make tinyconfig) to all work with ARCv2 by default. Signed-off-by: Kevin Hilman --- Applies on v4.20-rc4 arch/arc/Kconfig | 2 +- arch/arc/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index c9e2a1323536..a65ca0955d8b 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -109,7 +109,7 @@ endmenu choice prompt "ARC Instruction Set" - default ISA_ARCOMPACT + default ISA_ARCV2 config ISA_ARCOMPACT bool "ARCompact ISA" diff --git a/arch/arc/Makefile b/arch/arc/Makefile index c64c505d966c..df00578c279d 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -6,7 +6,7 @@ # published by the Free Software Foundation. # -KBUILD_DEFCONFIG := nsim_700_defconfig +KBUILD_DEFCONFIG := nsim_hs_defconfig cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 -- 2.11.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: change defconfig defaults to ARCv2
On 11/27/18 2:21 PM, Kevin Hilman wrote: > Change the default defconfig (used with 'make defconfig') to the ARCv2 > nsim_hs_defconfig, and also switch the default Kconfig ISA selection to > ARCv2. > > This allows several default defconfigs (e.g. make defconfig, make > allnoconfig, make tinyconfig) to all work with ARCv2 by default. > > Signed-off-by: Kevin Hilman Applied to for-curr Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: failing ARC builds in kernelCI
Alexey Brodkin writes: > BTW judging by the error [1] "arc-linux-ld: error: vmlinux.o: unable to merge > ISA extension attributes code-density." > I may assume we again bump into situation of building ARCompact kernel with > ARCv2 toolchain. > > Also what hints to that problem is our default defconfig is > "nsim_700_defconfig" which > obviously ARCompact, see > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Makefile#n9 > > Thus I think the simplest option would be to switch to say > "nsim_hs_defconfig" for > default one, but that requires Vineet's ack. I tried that, but that's not the only thing required. Because the Kconfig default the ISA is ISA_ARCOMPACT, allnoconfig uses that, no matter what the default in the Makefile is. And, since tinyconfig is based on allnoconfig, it has the same problem. I submitted a patch[1] that gets this working for me, and with that, 'make defconfig', 'make allnoconfig' and 'make tinyconfig' all work with ARCv2 by default. Kevin [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-November/004863.html > > -Alexey > > [1] https://kernelci.org/build/id/5bfd5cbe59b51413138b6da0/logs/ > > On Tue, 2018-11-27 at 15:38 +, Alexey Brodkin wrote: >> Hi Kevin, >> >> On Tue, 2018-11-27 at 07:23 -0800, Kevin Hilman wrote: >> > Hi Alexey, >> > >> > You may have noticed that some defconfigs are failing to build >> > upstream for ARC. For example, on mainline, both allnoconfig and >> > tinyconfig fail to build[1]. >> >> Actually I haven't seen that! >> 1. I used to check >> https://urldefense.proofpoint.com/v2/url?u=https-3A__kernelci.org_soc_&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=KXGPL3Q7lsPxI1vH-M5m_JDTQ5czcfO7hTNdGXJsqfU&e= >> but there's still no mention >> of ARC so I thought builds for ARC are not enabled still. >> 2. I haven't seen any email notifications as well if they exist at all. >> >> That said it would be good if warning emails are sent to our mailing-list >> linux-snps-arc@lists.infradead.org (see in Cc as well) so somebody reacts on >> them. >> >> >> > Do you guys have any plans to fix these, or should we disable them? >> > We currently build these for all the other arches., >> >> Sure, let me take a look right now. >> >> > Kevin >> > >> > [1] >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__kernelci.org_build_mainline_branch_master_kernel_v4.20-2Drc4-2D7-2Dgef78e5ec9214_&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=mAOgc823jx9R9N4t6nQ4AW9E8kdexU-Y3V5-t50CwJo&e= >> >> -Alexey >> ___ >> linux-snps-arc mailing list >> linux-snps-arc@lists.infradead.org >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=Yt-UgnQ5sp-_dEc2MtGZg0QqdnhXBo5Xwvw1tb_a6gA&s=CjFcD6LV0UctpHpPG5sETrRyEMzZdu4HNEfoozl-y2c&e= ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
