On 12 August 2015 at 16:07, Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > On 12 August 2015 at 10:58, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >> On 07/26/2015 05:40 PM, Rafał Miłecki wrote: >>> >>> On 20 July 2015 at 19:14, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >>>> >>>> On 07/19/2015 05:05 PM, Rafał Miłecki wrote: >>>>> >>>>> >>>>> On 10 July 2015 at 20:31, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> >>>>>> This series comprises of following changes: >>>>>> - support NVRAM loading for bcm47xx platform. >>>>>> - revise announced interface combinations and validate against it. >>>>>> - new debugfs entry for msgbuf protocol layer used with PCIe devices. >>>>>> - couple of PCIe fixes. >>>>>> - rework dealing with interface instances. >>>>> >>>>> >>>>> >>>>> I'm not sure which patch has caused this (I applied all of them except >>>>> for the 1st one) but now brcmfmac fails totally: >>>>>> >>>>>> >>>>>> Unable to handle kernel NULL pointer dereference at virtual address >>>>>> 00000014 >>>>> >>>>> >>>>> >>>>> I'm afraid I won't be able to spend any more time of this soon, so can >>>>> you try to reproduce this problem, please? >> >> >> You did a warm reboot of the device, right? There seems to be an issue >> because on OpenWrt the brcmfmac is not unloaded upon warm reboot, which >> makes the device unaccessible. Because on OpenWrt the firmware request is >> synchronous (OpenWrt patch on top of upstream brcmfmac) it results in probe >> failing on invalid access making the issue OpenWrt specific. Hante created a >> fix for the warm reboot issue. > > I'm not sure about this, it was too long time ago. I'm coming back > home on next Tuesday, so I should be able to work on this again soon. I tested warm reboots today and indeed they are broken in OpenWrt. However warm reboot attempt result in next-boot hang with: brcmfmac: brcmf_fw_request_nvram_done: Found platform NVRAM (19204 B) being the last message. This warm reboot issue is something different from the regression introduced by this patches which results in: Unable to handle kernel NULL pointer dereference at virtual address 00000014 I'm focusing on V2 now. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
