On Thu, Jul 22, 2021 at 3:52 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > 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... > Thank you for checking! In the meanwhile, the last test job completed and passed as well. Let me know if you'd like more test runs or if there's anything else I can help with. Veronika > Robin. >
