Re: ❌ FAIL: Test report for kernel 5.13.0-rc7 (arm-next, 8ab9b1a9)

[Robin Murphy <robin.murphy@arm.com>]

On 2021-07-22 13:38, Veronika Kabatova wrote:
> On Fri, Jul 16, 2021 at 6:26 PM Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>>
>> On Fri, Jul 16, 2021 at 06:16:01PM +0200, Ard Biesheuvel wrote:
>>> On Mon, 5 Jul 2021 at 18:17, Lorenzo Pieralisi
>>> <lorenzo.pieralisi@arm.com> wrote:
>>>>
>>>> On Wed, Jun 30, 2021 at 08:18:22PM +0200, Ard Biesheuvel wrote:
>>>>
>>>> [...]
>>>>
>>>>>> In current code, even if the BERT were mapped with acpi_os_map_iomem()
>>>>>> this would change nothing since it's acpi_os_ioremap() that runs the
>>>>>> rule (backed up by EFI memory map region info).
>>>>>>
>>>>>
>>>>> Indeed. So the fact that acpi_os_map_memory() is backed by
>>>>> acpi_os_ioremap() is something we should fix. So they should both
>>>>> consult the EFI memory map, but have different fallback defaults if
>>>>> the region is not annotated correctly.
>>>>
>>>> Put together patch below even though I am not really satisfied, a tad
>>>> intrusive and duplicate code in generic/arch backends, compile tested
>>>> only; overall this IO vs memory mapping distinction is a bit too fuzzy
>>>> for my taste - there is legacy unfortunately to consider though.
>>>>
>>>
>>> I'd say that this does not look unreasonable at all. Is there any way
>>> we could get this tested on actual hw?
>>
>> Sure, I was meant to follow-up and was caught up in something else,
>> sorry.
>>
>> I will clean up the log, push it out in a branch on Monday, CKI
>> should pick it up. I will also think about other possible testing
>> options.
>>
> 
> Hi,
> 
> thanks for the patience with the testing, the stress-ng test couldn't
> deal with a new glibc version and had to be fixed and this week
> has just been crazy.
> 
> I managed to do 2 runs of the updated tree with the stress-ng test
> and it didn't hit the problem. Given how unreliably it reproduces it
> doesn't mean all that much. I still have one more run pending and
> can submit more if needed.
> 
> However, we ran into a panic with this tree on a completely
> different machine:
> 
> https://gitlab.com/-/snippets/2152899/raw/main/snippetfile1.txt

All the warnings from arch_setup_dma_ops() there are (unfortunately) 
pretty much legitimate for that platform, and should be gone again since 
rc2 with commit c1132702c71f.

> The machine also hit a hardware error during LTP:
> 
> https://gitlab.com/-/snippets/2152899/raw/main/snippetfile2.txt

Hmm, if "access mode: secure" in that fault report implies that the 
firmnware itself has done something dodgy to raise an SError, I'm not 
sure there's much we can do about that...

Robin.