On Thu, 21 Feb 2019 at 09:59, Arend Van Spriel <[email protected]> wrote: > On 2/21/2019 9:01 AM, Rafał Miłecki wrote: > > On Wed, 20 Feb 2019 at 11:31, Rafał Miłecki <[email protected]> wrote: > >> From: Rafał Miłecki <[email protected]> > >> > >> While experimenting with firmware loading I ended up in a state of > >> firmware reporting shared RAM address 0x04000001. It was causing: > >> [ 94.448015] Unable to handle kernel paging request at virtual address > >> cd680001 > >> due to reading out of the mapped memory. > >> > >> This patch adds some basic validation to avoid kernel crashes due to the > >> unexpected firmware behavior. > > > > For a reference for the further hackers. That has been caused by a > > BCMA_CORE_SYS_MEM core on my BCM4366/4 not being up. > > Thanks, Rafał > > Does that happen all the time or in some specific scenario. Anyway, it > seems like we need to add a check in brcmf_chip_sysmem_ramsize() and > bringup the core if needed. Although, I am curious in what the state the > other cores are at that time. Might need a chip-wide reset.
It happens after brcmf_pcie_reset_device() which is probably a 100% expected case ;) Normally brcmfmac does not call brcmf_pcie_reset_device() between brcmf_chip_sysmem_ramsize() and the brcmf_pcie_download_fw_nvram() so it was only my hacking that caused that issue for me. -- Rafał
