BCM943241 (B4) within Aava Inari 8 baytrail-based tablet fails to connect to wireless networks upon having scanned these successfully with this repeating: kernel: brcmfmac: brcmf_cfg80211_escan: Connecting: status (3) kernel: brcmfmac: brcmf_cfg80211_scan: scan error (-11) brcmfmac messages upon bootup: [ 6.753368] brcmfmac: F1 signature read @0x18000000=0x16c54324 [ 6.756695] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 4324 rev 5 pmurev 17 [ 6.757795] usbcore: registered new interface driver brcmfmac [ 7.002706] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Nov 15 2013 19:14:45 version 6.10.199.2 (r437079) FWID 01-1e5283bf [ 8.664258] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists [ 8.664265] brcmfmac: brcmf_add_if: ignore IF event [ 10.774432] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [ 20.951472] brcmfmac: brcmf_escan_timeout: timer expired [ 44.085789] brcmfmac: brcmf_escan_timeout: timer expired [ 77.120678] brcmfmac: brcmf_escan_timeout: timer expired The kernel is a 64-bit one, mostly 3.18-rc4 with the patch referenced in bug 69011, comment 61 applied; firmware and nvram files taken from ODM's android. Looks like there were similar problems on T100TA: https://lists.debian.org/debian-kernel/2014/08/msg00294.html What should I do/provide to help diagnose this issue and sort it out? TIA :)
CCing Intel and Broadcom folks who might know innards of Baytrail and brcmfmac.
The systems typically come with sdhci-acpi driver used for the SDIO host controller, which does runtime-pm. However, the brcmfmac driver does not support runtime-pm so when host controller goes into runtime suspend the firmware can not communicate with the host and brcmfmac is idle as it waits for firmware response. So please confirm it works with runtime-pm disabled for the host controller through sysfs. To locate the host controller, I think you need to go to /sys/bus/platform/drivers/sdhci-acpi. It can be bound to multiple devices so you have to find the correct one or disable runtime-pm for both.
Confirmed: --- bus/platform/drivers/sdhci-acpi/80860F14:00/power/control = on bus/platform/drivers/sdhci-acpi/80860F14:01/power/control = on bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control = on --- /etc/sysfs.conf gets me working wlan0; looks like INT33BB:00 is responsible for wifi on this particular platform. This is a valid workaround, thank you; is the bug still valid as a feature request to implement runtime PM support?
Not sure whether bugzilla is to track feature requests. We could add runtime-pm in brcmfmac, but that does not solve this issue. It would require an API that brcmfmac could use to inform the mmc host-controller not to go into runtime-suspend or at least allow the device to wake it up. I did not look into runtime-pm yet but from a quick glance I guess we should use pm_runtime_forbid()/pm_runtime_allow() on mmc_host->parent, which should be the sdhci-acpi device if I am not mistaken.
It's definitely up to you, Arend :-) Always glad to test of course.
Could this patch be related? https://github.com/AdamWill/baytrail-m/blob/master/kernel/sdhci-pm.patch
Actually this was enough: --- bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control = on ---
Hello, I'm writing to the old article. Sorry, but I have a problem with kernel 3.18-rc4. Following this post: https://www.tolgabagci.com/en/install-ubuntu/ on my old desktop computer (sorry for the link) I installed an Ubuntu/Linux with the virtual machine on Windows. I am running Ubuntu 14.10 (kernel: 3.18-rc4) on my virtual machine, but I have not been able to install the WiFi with the Realtek RTL8188 chipset I bought recently. What can I do about it?
(In reply to rowlandduke from comment #11) > I am running Ubuntu 14.10 (kernel: 3.18-rc4) on my virtual machine, but I That's a severely-out-of-date distribution and kernel. You're not going to get any support from anyone for that. > have not been able to install the WiFi with the Realtek RTL8188 chipset I > bought recently. What can I do about it? This is not the right place for this question. The current report is about Broadcom WiFi, not Realtek. This is also not the right place because a bug tracker is not the right place to ask for support.