On Mon, Nov 19, 2018 at 02:13:52PM -0200, Martin Pieuchot wrote:
> On 18/11/18(Sun) 14:29, Carlos Cardenas wrote:
> > Howdy.
> >
> > After an upgrade, my mcbin-ss panic'ed while performing pkg_add -u.
> >
> > Attached is the dmesg and ddb output(s).
>
> This seems to be a SPL issue. In the trace below uvm_pmr_remove_1strange()
> is called with `fpageq' lock, which is a IPL_VM mutex. So the bnx(4)
> interrupt shouldn't be triggered.
Yeah, I think I can tell you why. First of all, bnxt(4) does not use
MSI, even though that ARM64 platform supports it, because it's disabled
in bnxt(4). Thus we have to use legacy interrupts.
The device tree for the PCIe nodes specify an interrupt map:
pcie@f2600000 {
[...]
interrupt-map-mask = <0x00000000 0x00000000 0x00000000 0x00000000>;
interrupt-map = <0x00000000 0x00000000 0x00000000 0x00000000
0x00000008 0x00000000 0x00000016 0x00000004>;
interrupts = <0x00000000 0x00000016 0x00000004>;
[...]
};
The "interrupts" property is used to establish an interrupt handler on
the controller itself. In this case apparently we have a handler that
ACKs INTx interrupts and returns, because someone else will take care of
the actual interrupt handling (i.e. PCIe device driver).
sc->sc_ih = fdt_intr_establish(sc->sc_node, IPL_AUDIO | IPL_MPSAFE,
dwpcie_armada8k_intr, sc, sc->sc_dev.dv_xname);
The PCIe device driver like bnxt(4) maps the interrupt through the
interrupt-map which apparently has the same interrupt ids.
cookie = fdt_intr_establish_imap(sc->sc_node, reg,
sizeof(reg), level, func, arg, name);
That means bnxt(4) and dwpcie(4) share the same interrupt line, but one
has IPL_AUDIO and the other one IPL_NET. Since the highest IPL on a
pin counts, this line is now IPL_AUDIO (which is >IPL_VM). A bnxt(4)
interrupt is now allowed to interrupt IPL_VM.
I don't think there's a regression, I think it behaves as implemented.
The question that remains is: How should it behave if not like that?
Patrick
