On 12/8/23 7:12 PM, Gregory CLEMENT wrote:
> Now that we support having the kernel in XPHYS and not only in KSEG0,
> the case where ebase doesn't belong to KSEG0 is more likely to
> occur. However, in this scenariowe encounter a significant and
Scenario we? :-)
> intimidating stack dump without any explanation. To address this, we
> should eliminate the uninformative stack dump and replace it with a
> warning that provides a clear explanation of the issue.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@xxxxxxxxxxx>
> ---
> arch/mips/kernel/traps.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index 68f1dd54cde1c..ec0cebfd2ef7b 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -2420,10 +2420,13 @@ void __init trap_init(void)
> * EVA is special though as it allows segments to be rearranged
> * and to become uncached during cache error handling.
> */
> - if (!IS_ENABLED(CONFIG_EVA) && !WARN_ON(ebase_pa >= 0x20000000))
> + if (!IS_ENABLED(CONFIG_EVA) && ebase_pa < 0x20000000)
> ebase = CKSEG0ADDR(ebase_pa);
> else
> ebase = (unsigned long)phys_to_virt(ebase_pa);
> + if (ebase_pa >= 0x20000000)
> + pr_warn("ebase(%pa) should better be in KSeg0",
I think it's called KSEG0...
[...]
MBR, Sergey
