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

[Robin Murphy]

Hi Aristeu,

On 2022-03-04 19:39, Aristeu Rozanski wrote:
> Hi Robin,
> 
> (Old thread, so reference to it: https://lists.infradead.org/pipermail/linux-arm-kernel/2021-June/668228.html)
> (Also, please keep me on Cc since I'm not subscribed to linux-arm)
> (And again because I failed to fix the email address after using the
> archives mailbox, apologies for that)
> 
> On Tue, Jun 29, 2021 at 06:27:57PM +0100, Robin Murphy wrote:
>> Ah, from that I can only assume that this must be stress-ng's --sysfs
>> test reading things at random, so not only would it have to be on a
>> machine whose firmware presents the right thing in the right way but the
>> random test conditions would also have to line up to poke it the "right"
>> (wrong) way too.
>>
>> As a temporary workaround for the CI flakes, might it be possible to
>> configure stress-ng to stay away from just these ACPI "data" files?
> 
> I started looking at this issue and managed to reproduce the issue
> instantly with
> 
> 	dd if=/sys/firmware/acpi/tables/data/BERT of=/dev/null bs=7
> 
> I've attempted a few ways of fixing it based on the comments on this
> thread but wasn't successful so far (my knowledge is pretty limited in
> this area too, so not a big surprise). How can I be of assistance to debug/test
> patches for this issue?

Gosh, there's a fair bit of additional history between then and now, 
scattered across several other threads... From memory, we ended up 
merging some form of Lorenzo's patch, but that turned out to break some 
other machine with a *differently* dodgy memory map, and got reverted 
again. I have a feeling that things wound up at that point leaning 
towards a consensus that the pseudo-generic machinery that was actually 
only used for dumping BERT records could probably be ripped out and 
replaced with a simple dedicated iomem-safe thing for dumping BERT 
records, but I'm not sure if any further progress happened on that front.

Cheers,
Robin.