[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d9e80b8-17e2-b1d9-14fa-f1d8d7dfbd9a@microchip.com>
Date: Thu, 30 Jun 2022 16:37:50 +0000
From: <Conor.Dooley@...rochip.com>
To: <sudeep.holla@....com>
CC: <linux-kernel@...r.kernel.org>, <gregkh@...uxfoundation.org>,
<atishp@...shpatra.org>, <atishp@...osinc.com>,
<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
<wangqing@...o.com>, <robh+dt@...nel.org>, <rafael@...nel.org>,
<ionela.voinescu@....com>, <pierre.gondois@....com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-riscv@...ts.infradead.org>, <gshan@...hat.com>,
<Valentina.FernandezAlanis@...rochip.com>
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache
information from the cacheinfo
On 30/06/2022 11:39, Sudeep Holla wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Wed, Jun 29, 2022 at 11:25:41PM +0000, Conor.Dooley@...rochip.com wrote:
>> On 29/06/2022 21:32, Conor.Dooley@...rochip.com wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 29/06/2022 20:54, Sudeep Holla wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> On Wed, Jun 29, 2022 at 07:39:43PM +0000, Conor.Dooley@...rochip.com wrote:
>>>>> On 29/06/2022 19:42, Sudeep Holla wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>>
>>>>>> On Wed, Jun 29, 2022 at 06:18:25PM +0000, Conor.Dooley@...rochip.com wrote:
>>>>>>>
>>>>>>> No, no it doesn't. Not sure what I was thinking there.
>>>>>>> Prob tested that on the the last commit that bisect tested
>>>>>>> rather than the one it pointed out the problem was with.
>>>>>>>
>>>>>>> Either way, boot is broken in -next.
>>>>>>>
>>>>>>
>>>>>> Can you check if the below fixes the issue?
>>>>>
>>>>> Unfortunately, no joy.
>>>>> Applied to a HEAD of 3b23bb2573e6 ("arch_topology: Use the
>>>>> last level cache information from the cacheinfo").
>>>>
>>>> That's bad. Does the system boot with
>>>> Commit 2f7b757eb69d ("arch_topology: Add support to parse and detect cache
>>>> attributes") ?
>>>
>>> It does.
>>
>
> I can't think of any reason for that to happen unless detect_cache_attributes
> is failing from init_cpu_topology and we are ignoring that.
>
> Are all RISC-V platforms failing on -next or is it just this platform ?
I don't know. I only have SoCs with this core complex & one that does not
work with upstream. I can try my other board with this SoC - but I am on
leave at the moment w/ a computer or internet during the day so it may be
a few days before I can try it.
However, Niklas Cassel has tried to use the Canaan K210 on next-20220630
but had issues with RCU stalling:
https://lore.kernel.org/linux-riscv/Yr3PKR0Uj1bE5Y6O@x1-carbon/T/#m52016996fcf5fa0501066d73352ed8e806803e06
Not going to claim any relation, but that's minus 1 to the platforms that
can be used to test this on upstream RISC-V.
> We may have to try with some logs in detect_cache_attributes,
> last_level_cache_is_valid and last_level_cache_is_shared to check where it
> is going wrong.
>
> It must be crashing in smp_callin->update_siblings_masks->last_level_cache_is_shared
Yeah, I was playing around last night for a while but didn't figure out the
root cause. I'll try again tonight.
In the meantime, would you mind taking the patches out of -next?
FWIW I repro'd the failure on next-20220630.
Thanks,
Conor.
Powered by blists - more mailing lists