Re: ❌ FAIL (MISSED 2 of 87): Test report for for-kernelci (6.9.0-rc4, arm-next, 6a71d290)

[Jeremy Linton <jeremy.linton@arm.com>]

Hi,


I'm fairly certain I had a conversation about whether that patch should 
be upstream and there wasn't a big desire to carry it upstream for 
$REASONS. But google/etc can't seem to find the conversation so maybe it 
didn't happen in public.

So, I will post it there is a willingness to carry it.

Thanks,


On 4/23/24 10:23, Jeremy Linton wrote:
> Hi,
> 
> On 4/23/24 09:42, Donald Zickus wrote:
>> (adding Jeremy Linton as the author of the out of tree patch)
>>
>> Hi Jeremy,
>>
>>
>> On Tuesday, April 23, 2024 at 7:49:26 AM UTC-4 Suzuki K Poulose wrote:
>>
>> On 23/04/2024 12:17, James Clark wrote:
>>>
>>>
>>> On 23/04/2024 12:14, James Clark wrote:
>>>>
>>>>
>>>> On 22/04/2024 18:08, Will Deacon wrote:
>>>>> [+Suzuki, Mike and James]
>>>>>
>>>>> On Fri, Apr 19, 2024 at 08:30:09PM -0000, cki-project@redhat.com 
>>>>> wrote:
>>>>>> Hi, we tested your kernel and here are the results:
>>>>>>
>>>>>> Overall result: FAILED
>>>>>> Merge: OK
>>>>>> Compile: OK
>>>>>> Test: FAILED
>>>>>>
>>>>>>
>>>>>> Kernel information:
>>>>>> Commit message: Merge branch 'for-next/core' into for-kernelci
>>>>>>
>>>>>> You can find all the details about the test run at
>>>>>> https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:1260423326
>>>>>>
>>>>>> One or more kernel tests failed:
>>>>>> Unrecognized or new issues:
>>>>>> Boot test
>>>>>> aarch64
>>>>>> Logs: https://datawarehouse.cki-project.org/kcidb/tests/
>> redhat:1260423326-aarch64-kernel_upt_4
>>>>>> Non-passing ran subtests:
>>>>>> ❌ FAIL distribution/kpkginstall/journalctl-check
>>>>>
>>>>> I'm not sure if it's the root cause, but the logs here have a tonne of
>>>>> coresight ETM splats (I included one at the end of the mail).
>>>>>
>>>>> https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/
>> trusted-artifacts/1260423326/test_aarch64/6670265232/
>> artifacts/run.done.01/job.01/recipes/15985953/tasks/5/
>> results/1713555252/logs/journalctl.log
>>>>>
>>>>> Jonathan has recently done a bunch of work fixing up the ->parent
>>>>> pointers for PMU devices, but I don't see anything going near the
>>>>> coresight drivers so this is probably unrelated.
>>>>>
>>>>> Will
>>>>>
>>>>> --->8
>>>>>
>>>>> Apr 19 15:33:38 hpe-apollo-cn99xx-03.khw.eng.rdu2.dc.redhat.com 
>>>>> kernel:
>> CSCFG registered etm103
>>>>> Apr 19 15:33:38 hpe-apollo-cn99xx-03.khw.eng.rdu2.dc.redhat.com 
>>>>> kernel:
>> coresight etm103: CPU103: etm v4.1 initialized
>>>>> Apr 19 15:33:38 hpe-apollo-cn99xx-03.khw.eng.rdu2.dc.redhat.com 
>>>>> kernel:
>> sysfs: cannot create duplicate filename '/devices/system/container/
>> ACPI0004:00/ARMHC9FE:00/funnel0/connections/in:0'
>>>>
>>>> Hi Will,
>>>>
>>>> It looks like multiple ETMs are described as being connected to the 
>>>> same
>>>> port on a funnel. Those connections to build the filename string all
>>>> come from the firmware. I don't think there are any changes since 
>>>> 6.8 in
>>>> Coresight that would affect device registration.
>>>>
>>>> I did try to find some previous runs on that machine and I found this
>>>> message
>>>> (https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/
>> trusted-artifacts/1260423326/test_aarch64/6670265232/
>> artifacts/run.done.01/job.01/recipes/15985953/tasks/5/
>> results/1713555252/logs/journalctl.log):
>>>>
>>>> "ETM4 disabled due to firmware bug"
>>>>
>>>> Although I couldn't find where that string comes from. It seems to me
>>>> like there has been a firmware change on that machine recently, or this
>>>> is the first time it's been booted with Coresight enabled.
>>>>
>>>> Also possible is that we removed the kernel part that disabled it 
>>>> due to
>>>> whatever that flag is, but I don't think that's happened. Maybe Suzuki
>>>> knows about that message and could comment?
>>>>
>>>> Thanks
>>>>
>>>> James
>>>
>>> Ok I found the string, it's from an out of tree patch:
>>>
>>> https://src.fedoraproject.org/rpms/kernel/c/2db8df88f66eacaa9bec1995431388
>> fb3a044566.patch
>>
>>
>> Is your patch [1] still relevant in light of the current splat?
> 
> Yes. because the firmware doesn't appear to be updated on the test machine.
> 
> The downstream patch is quirking/disabling coresight on the machine in 
> question because the table is just fundamentally broken. So, yes the 
> module could be blacklisted if the test harness could do that on a 
> machine by machine basis, or for that matter a corrected table could 
> also be injected.
> 
> 
> 
> 
>>
>> Cheers,
>> Don
>>
>> [1]
>> - 
>> https://gitlab.com/cki-project/kernel-ark/-/commit/ea9bdc9a2dd2fe5aa2de58dcbfa14f64bdd4d716
>>
>>
>>>
>>>
>>
>>
>> Could they not black list the coresight* modules on the system ?
>>
>> Suzuki
>>
>>
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel