On 2021-07-22 13:38, Veronika Kabatova wrote:
On Fri, Jul 16, 2021 at 6:26 PM Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> 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@xxxxxxx> 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.
