Hi,
I just got an ECS LIVA and I haven't been able to get the wireless
working. First I got the error that the brcmfmac43241b4-sdio.txt file
was missing. I got the file from the ECS's beta drivers [1], but it's
still not working.
brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init
done for chip 4324 rev 5 pmurev 17
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 17 2013
07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634
brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
brcmfmac: brcmf_add_if: ignore IF event
WPA association/authentication failed for interface 'wlan0'
I also tried a nvram file that is stored in EFI variables, but it
didn't work either.
Some things seem to work some times, but not the whole association.
This is a 3.17.2 kernel.
Any ideas?
[1] http://www.ecs.com.tw/LIVA/support.html
--
Felipe Contreras
On 11/08/14 21:39, Felipe Contreras wrote:
> Hi,
>
> I just got an ECS LIVA and I haven't been able to get the wireless
> working. First I got the error that the brcmfmac43241b4-sdio.txt file
> was missing. I got the file from the ECS's beta drivers [1], but it's
> still not working.
>
> brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init
> done for chip 4324 rev 5 pmurev 17
> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 17 2013
> 07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634
> brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
> brcmfmac: brcmf_add_if: ignore IF event
>
> WPA association/authentication failed for interface 'wlan0'
>
> I also tried a nvram file that is stored in EFI variables, but it
> didn't work either.
>
> Some things seem to work some times, but not the whole association.
>
> This is a 3.17.2 kernel.
>
> Any ideas?
Hi Felipe,
The ideas may come to us with a bit more trace information. The logging
above is the usual stuff so no problem indication there.
I looked at the nvram file from [1]. At the end there are some entries
about OOB wakeup, ie. starting with 'sd_'. You may remove those, but
giving the logging it would not be the first thing to do.
Could you share the nvram obtained from EFI? Also please create a kernel
log with debug=0xd416.
Regards,
Arend
> [1] http://www.ecs.com.tw/LIVA/support.html
>
On 11/11/14 19:49, Felipe Contreras wrote:
> On Tue, Nov 11, 2014 at 12:35 PM, Arend van Spriel<[email protected]> wrote:
>> On 11-11-14 19:32, Felipe Contreras wrote:
>>> On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel<[email protected]> wrote:
>>>> On 10-11-14 21:48, Felipe Contreras wrote:
>>>
>>>>> /etc/modprobe.d/brcmfmac.conf
>>>>> options brcmfmac debug=0xd416
>>>>>
>>>>> I see nothing extra in the debug log... Am I doing something wrong?
>>>>
>>>> Not sure. You can verify and set the log level through sysfs, ie.:
>>>>
>>>> $ cat /sys/module/brcmfmac/parameters/debug
>>>
>>> 54294
>>>
>>> I guess ArchLinux's kernel is missing some configuration option needed
>>> for the debugging.
>>
>> Can you boot the kernel with 'debug ignore_loglevel' on the kernel
>> command line.
>
> Yes. I see more systemd messages, nothing extra from brcmfmac.
Ok. Probably brcmfmac was not built with CONFIG_BRCMDBG. Can you
checkout kernel config.
Regards,
Arend
On 10-11-14 21:48, Felipe Contreras wrote:
> Hi,
>
> On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
>
>> The ideas may come to us with a bit more trace information. The logging
>> above is the usual stuff so no problem indication there.
>>
>> I looked at the nvram file from [1]. At the end there are some entries about
>> OOB wakeup, ie. starting with 'sd_'. You may remove those, but giving the
>> logging it would not be the first thing to do.
>
> I removed the sd_ lines, it didn't help.
>
>> Could you share the nvram obtained from EFI? Also please create a kernel log
>> with debug=0xd416.
>
> Sure, the nvram file is here:
>
> http://pastie.org/9710358
>
> I tried adding this file:
>
> /etc/modprobe.d/brcmfmac.conf
> options brcmfmac debug=0xd416
>
> I see nothing extra in the debug log... Am I doing something wrong?
Not sure. You can verify and set the log level through sysfs, ie.:
$ cat /sys/module/brcmfmac/parameters/debug
To set it:
$ echo 0xd416 > /sys/module/brcmfmac/parameters/debug
Regards,
Arend
On 11-11-14 19:32, Felipe Contreras wrote:
> On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel <[email protected]> wrote:
>> On 10-11-14 21:48, Felipe Contreras wrote:
>
>>> /etc/modprobe.d/brcmfmac.conf
>>> options brcmfmac debug=0xd416
>>>
>>> I see nothing extra in the debug log... Am I doing something wrong?
>>
>> Not sure. You can verify and set the log level through sysfs, ie.:
>>
>> $ cat /sys/module/brcmfmac/parameters/debug
>
> 54294
>
> I guess ArchLinux's kernel is missing some configuration option needed
> for the debugging.
Can you boot the kernel with 'debug ignore_loglevel' on the kernel
command line.
Regards,
Arend
On Wed, Nov 12, 2014 at 4:40 AM, Arend van Spriel <[email protected]> wrote:
> On 11-11-14 23:32, Felipe Contreras wrote:
>> On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
>>
>>> Could you share the nvram obtained from EFI? Also please create a kernel log
>>> with debug=0xd416.
>>
>> There you go:
>> http://people.freedesktop.org/~felipec/dmesg-brcm.txt
>>
>
> It is using the sdhci-acpi driver for the sdio host controller. If I am
> not mistaken that one does runtime-pm. This has caused issues with our
> device. This is what happens:
>
> 1. driver sends control message and waits for firmware response.
> 2. runtime pm kicks in and suspends host controller.
> 3. host controller suspend disable sdio clock.
> 4. host controller does not detect firmware interrupt for response.
> 5. control message times out.
>
> You can disable it through sysfs, but the patch below may do it.
I tried this patch, and although it seems to make a difference, it
still doesn't work.
http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt
--
Felipe Contreras
On Thu, Nov 13, 2014 at 4:47 AM, Arend van Spriel <[email protected]> wrote:
> On 12-11-14 16:23, Felipe Contreras wrote:
>> On Wed, Nov 12, 2014 at 4:40 AM, Arend van Spriel <[email protected]> wrote:
>> I tried this patch, and although it seems to make a difference, it
>> still doesn't work.
>>
>> http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt
>
> Hi Felipe,
>
> All the messages to the firmware seem ok. If connection would succeed I
> normally see a LINK event followed by SET_SSID event. In your log I only
> see the SET_SSID event with failed status, hence the connect is
> unsuccessful. Do you have any control over the AP? Could you try without
> WPA security to quickly confirm connection works? May help in root
> causing the issue.
I tried disabled WPA security, it's still not working.
--
Felipe Contreras
On 12-11-14 16:23, Felipe Contreras wrote:
> On Wed, Nov 12, 2014 at 4:40 AM, Arend van Spriel <[email protected]> wrote:
>> On 11-11-14 23:32, Felipe Contreras wrote:
>>> On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
>>>
>>>> Could you share the nvram obtained from EFI? Also please create a kernel log
>>>> with debug=0xd416.
>>>
>>> There you go:
>>> http://people.freedesktop.org/~felipec/dmesg-brcm.txt
>>>
>>
>> It is using the sdhci-acpi driver for the sdio host controller. If I am
>> not mistaken that one does runtime-pm. This has caused issues with our
>> device. This is what happens:
>>
>> 1. driver sends control message and waits for firmware response.
>> 2. runtime pm kicks in and suspends host controller.
>> 3. host controller suspend disable sdio clock.
>> 4. host controller does not detect firmware interrupt for response.
>> 5. control message times out.
>>
>> You can disable it through sysfs, but the patch below may do it.
>
> I tried this patch, and although it seems to make a difference, it
> still doesn't work.
>
> http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt
Hi Felipe,
All the messages to the firmware seem ok. If connection would succeed I
normally see a LINK event followed by SET_SSID event. In your log I only
see the SET_SSID event with failed status, hence the connect is
unsuccessful. Do you have any control over the AP? Could you try without
WPA security to quickly confirm connection works? May help in root
causing the issue.
Regards,
Arend
On 11/14/14 18:03, Felipe Contreras wrote:
> On Thu, Nov 13, 2014 at 4:47 AM, Arend van Spriel<[email protected]> wrote:
>> On 12-11-14 16:23, Felipe Contreras wrote:
>>> On Wed, Nov 12, 2014 at 4:40 AM, Arend van Spriel<[email protected]> wrote:
>
>>> I tried this patch, and although it seems to make a difference, it
>>> still doesn't work.
>>>
>>> http://people.freedesktop.org/~felipec/dmesg-brcm-2.txt
>>
>> Hi Felipe,
>>
>> All the messages to the firmware seem ok. If connection would succeed I
>> normally see a LINK event followed by SET_SSID event. In your log I only
>> see the SET_SSID event with failed status, hence the connect is
>> unsuccessful. Do you have any control over the AP? Could you try without
>> WPA security to quickly confirm connection works? May help in root
>> causing the issue.
>
> I tried disabled WPA security, it's still not working.
Thanks, Felipe
Could you check the runtime-pm for mmc1 controller. You need to find
sdhci-acpi driver in sysfs. I think it is under
/sys/bus/platform/drivers. One of the bound devices is mmc1 (although
probably will have different nameing there) and there is subfolder power
with file named control. Can you cat that file and do 'echo on >
control' if it says auto.
Regards,
Arend
On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
> Could you share the nvram obtained from EFI? Also please create a kernel log
> with debug=0xd416.
There you go:
http://people.freedesktop.org/~felipec/dmesg-brcm.txt
--
Felipe Contreras
On Tue, Nov 11, 2014 at 12:35 PM, Arend van Spriel <[email protected]> wrote:
> On 11-11-14 19:32, Felipe Contreras wrote:
>> On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel <[email protected]> wrote:
>>> On 10-11-14 21:48, Felipe Contreras wrote:
>>
>>>> /etc/modprobe.d/brcmfmac.conf
>>>> options brcmfmac debug=0xd416
>>>>
>>>> I see nothing extra in the debug log... Am I doing something wrong?
>>>
>>> Not sure. You can verify and set the log level through sysfs, ie.:
>>>
>>> $ cat /sys/module/brcmfmac/parameters/debug
>>
>> 54294
>>
>> I guess ArchLinux's kernel is missing some configuration option needed
>> for the debugging.
>
> Can you boot the kernel with 'debug ignore_loglevel' on the kernel
> command line.
Yes. I see more systemd messages, nothing extra from brcmfmac.
--
Felipe Contreras
On Tue, Nov 11, 2014 at 1:10 PM, Arend van Spriel <[email protected]> wrote:
> On 11/11/14 19:49, Felipe Contreras wrote:
>>
>> On Tue, Nov 11, 2014 at 12:35 PM, Arend van Spriel<[email protected]>
>> wrote:
>>>
>>> On 11-11-14 19:32, Felipe Contreras wrote:
>>>>
>>>> On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel<[email protected]>
>>>> wrote:
>>>>>
>>>>> On 10-11-14 21:48, Felipe Contreras wrote:
>>>>
>>>>
>>>>>> /etc/modprobe.d/brcmfmac.conf
>>>>>> options brcmfmac debug=0xd416
>>>>>>
>>>>>> I see nothing extra in the debug log... Am I doing something wrong?
>>>>>
>>>>>
>>>>> Not sure. You can verify and set the log level through sysfs, ie.:
>>>>>
>>>>> $ cat /sys/module/brcmfmac/parameters/debug
>>>>
>>>>
>>>> 54294
>>>>
>>>> I guess ArchLinux's kernel is missing some configuration option needed
>>>> for the debugging.
>>>
>>>
>>> Can you boot the kernel with 'debug ignore_loglevel' on the kernel
>>> command line.
>>
>>
>> Yes. I see more systemd messages, nothing extra from brcmfmac.
>
>
> Ok. Probably brcmfmac was not built with CONFIG_BRCMDBG. Can you checkout
> kernel config.
That's right; it's not set. I will enable it and rebuild.
--
Felipe Contreras
On 11-11-14 23:32, Felipe Contreras wrote:
> On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
>
>> Could you share the nvram obtained from EFI? Also please create a kernel log
>> with debug=0xd416.
>
> There you go:
> http://people.freedesktop.org/~felipec/dmesg-brcm.txt
>
It is using the sdhci-acpi driver for the sdio host controller. If I am
not mistaken that one does runtime-pm. This has caused issues with our
device. This is what happens:
1. driver sends control message and waits for firmware response.
2. runtime pm kicks in and suspends host controller.
3. host controller suspend disable sdio clock.
4. host controller does not detect firmware interrupt for response.
5. control message times out.
You can disable it through sysfs, but the patch below may do it.
Regards,
Arend
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wire
index f754ffc..d231e65 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -27,6 +27,7 @@
#include <linux/mmc/sdio_func.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
+#include <linux/pm_runtime.h>
#include <linux/platform_device.h>
#include <linux/platform_data/brcmfmac-sdio.h>
#include <linux/suspend.h>
@@ -976,6 +977,12 @@ static int brcmf_sdiod_probe(struct brcmf_sdio_dev
*sdiodev
SG_MAX_SINGLE_ALLOC);
sdiodev->max_segment_size = host->max_seg_size;
+ /*
+ * Several issues with the driver seem to occur when the SDIO host
+ * is using runtime-pm. Prevent host from doing runtime-pm here.
+ */
+ __pm_runtime_use_autosuspend(&host->class_dev, false);
+
/* allocate scatter-gather table. sg support
* will be disabled upon allocation failure.
*/
Hi,
On Sun, Nov 9, 2014 at 4:46 AM, Arend van Spriel <[email protected]> wrote:
> The ideas may come to us with a bit more trace information. The logging
> above is the usual stuff so no problem indication there.
>
> I looked at the nvram file from [1]. At the end there are some entries about
> OOB wakeup, ie. starting with 'sd_'. You may remove those, but giving the
> logging it would not be the first thing to do.
I removed the sd_ lines, it didn't help.
> Could you share the nvram obtained from EFI? Also please create a kernel log
> with debug=0xd416.
Sure, the nvram file is here:
http://pastie.org/9710358
I tried adding this file:
/etc/modprobe.d/brcmfmac.conf
options brcmfmac debug=0xd416
I see nothing extra in the debug log... Am I doing something wrong?
--
Felipe Contreras
On Tue, Nov 11, 2014 at 5:08 AM, Arend van Spriel <[email protected]> wrote:
> On 10-11-14 21:48, Felipe Contreras wrote:
>> /etc/modprobe.d/brcmfmac.conf
>> options brcmfmac debug=0xd416
>>
>> I see nothing extra in the debug log... Am I doing something wrong?
>
> Not sure. You can verify and set the log level through sysfs, ie.:
>
> $ cat /sys/module/brcmfmac/parameters/debug
54294
I guess ArchLinux's kernel is missing some configuration option needed
for the debugging.
--
Felipe Contreras