On Thu, 6 Jun 2019 at 16:32, Marc Zyngier <[email protected]> wrote: > > Hi Jonathan, > > On 05/06/2019 23:14, Jonathan Richardson wrote: > > Hi, > > > > As of the 5.0 kernel we're seeing the crash dump kernel crash when the > > gicv3-its driver calls gic_reserve_range(): > > [...] > > > On crash dump boot, gic calls the same function, > > efi_mem_reserve_persistent, finds the entry that was on initial boot > > (0xc3836000), converts it to a va, and then crashes when it's used on this > > line: > > atomic_fetch_add_unless(&rsv->count > > > > In the previous revision of this file, kmalloc was called and this worked > > fine. > > > > [ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode > > [ 0.000000] GICv3: Distributor has no Range Selector support > > [ 0.000000] GICv3: no VLPI support, no direct LPI support > > [ 0.000000] GICv3: CPU0: found redistributor 1 region > > 0:0x0000000063e20000 > > [ 0.000000] ITS [mem 0x63c20000-0x63c2ffff] > > [ 0.000000] ITS@0x0000000063c20000: allocated 32768 Devices @fd480000 > > (flat, esz 8, psz 64K, shr 0) > > [ 0.000000] ITS: using cache flushing for cmd queue > > [ 0.000000] iter: prsv = 0xc3836000 > > [ 0.000000] rsv = 0x43836000 > > [ 0.000000] Unable to handle kernel paging request at virtual address > > ffff80a343836004 > > [ 0.000000] Mem abort info: > > [ 0.000000] ESR = 0x96000004 > > [ 0.000000] Exception class = DABT (current EL), IL = 32 bits > > > > int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > > { > > <clip> > > for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) { > > printk("iter: prsv = 0x%x\n", prsv); > > rsv = __va(prsv); > > printk("rsv = 0x%x\n", rsv); > > index = atomic_fetch_add_unless(&rsv->count, 1, rsv->size); > > if (index < rsv->size) { > > rsv->entry[index].base = addr; > > rsv->entry[index].size = size; > > <clip> > > > > It looks like the change has broken crash dump kernel, but I'm not > > sure what it should be doing instead. Has anyone used gicv3-its with > > crash dump kernel after this change? > > I've definitely used kexec/kdump since, both in VMs and bare-metal. > Other than __va() going horribly wrong, I have no idea. > > Ard, do you have any suggestion? >
Not sure. It would be helpful to have the entire log, though. including the normal kernel boot. I can take a look tomorrow.
