wl1273 interuptions

The problems started when we upgraded from the 2.6.32 compat wireless drivers to the 3.0 compat wireless drivers and we needed to use new firmware (wl127x-fw-5-sr.bin: 6.3.10.2.115). Disabling ELP shows a new error: "wlcore: ERROR HW watchdog interrupt received! starting recovery.", which make me think there is a bug in the firmware.

Is this a known problem?

Is 6.3.10.2.115 the latest version?

Any help is much appreciated, I already put a lot of time into this.

Hi,

No This is not latest version, get the script to get the latest driver.

https://github.com/TI-ECS/build-utilites

we have wiki for the same http://processors.wiki.ti.com/index.php/Open_Source_Wireless_Connectivity_WiLink8_Build_scripts

instructions hold good for wl6 as well.

But the issue to me seems be with IRQ line only. As mmc seems to configured as firmware download happens,

But seems like you have verified the irq line already, and we have not any of the above problem with driver and firmware version you have mentioned.

Any way try the latest driver and lets see from there.

Thanks

Vijay

Thanks for your response, Vijay!

I have tried with firmware Rev 6.3.10.0.136, which seems to be the latest one. The ELP problem disappears, but makes place for a new problem:

wlcore: ERROR HW watchdog interrupt received! starting recovery.

Which makes me think this is somehow firmware related.

I have double checked the IRQ GPIO, according to the schematics it is 147. This is the source that sets it up:

https://github.com/semc7x30/msm7x30-3.4.x-nAa/blob/cm-10.1/arch/arm/mach-msm/board-semc_mogami-wifi.c#L41

Also, the same setup worked with compat wireless of 2.6.32.60.

Any pointers/help/advice is greatly appreciated.

Hi Marcel,

Can you try to re-build the wl12xx driver by following this page?

The latest driver should be ol_R5.SP5.01, firmware file is wl127x-fw-4-sr.bin, firmware version is 6.3.10.0.136.

Hello Victor, 

Thank you for your help. We have managed to get the new driver to build and work.

We are facing an issue with deep sleep though when wifi is on. Basically the device hardly ever sleeps due to wake locks originating from the wl12xx driver.

More specifically, this is what dmesg has to say:

<6>[ 247.334838] PM: suspend exit 2013-05-16 11:19:45.050075757 UTC
<6>[ 247.346130] suspend: exit suspend, ret = 0 (2013-05-16 11:19:45.061328978 UTC)
<6>[ 247.346313] active wake lock mmc1_detect
<6>[ 247.346405] active wake lock wl1271_wake
<6>[ 247.346893] active wake lock rx_wake, time left 95
<6>[ 250.300445] PM: suspend entry 2013-05-16 11:19:48.015048597 UTC
<7>[ 250.301391] Freezing user space processes ...

Any ideas how to deal with this situation?

I have tried with the compat driver built with the script and using the latest firmware, but unfortunately the problem doesn't go away

ERROR HW watchdog interrupt received! starting recovery.

Hello Victor,

I'm continuing the work of the people who already posted here. After all these months, we still have the same problem. Using ol_R5.SP5.01 & 6.3.10.0.136, wifi is working but we get this error at random times every few minutes: 

<3>[ 2158.491637] wl12xx: ERROR watchdog interrupt received! starting recovery.

<6>[ 2158.493346] wl12xx: Reading FW panic log

<6>[ 2158.495727] wl12xx: Hardware recovery in progress. FW ver: Rev 6.3.10.0.136

<6>[ 2158.497527] wl12xx: pc: 0x4bc

<6>[ 2158.498321] wl12xx: removing interface xx:xx:xx:xx:xx:xx

<6>[ 2158.508636] wl12xx: removing interface xx:xx:xx:xx:xx:xx

<6>[ 2158.514037] ieee80211 phy0: Hardware restart was requested

<6>[ 2158.516997] wl12xx: state: 0

<6>[ 2159.251647] wl12xx: firmware booted (Rev 6.3.10.0.136)

<6>[ 2159.257506] wl12xx: state: 2

<6>[ 2159.258147] wl12xx: adding p2p mgmt vif

<6>[ 2159.308654] wl12xx: Association completed.

This makes wifi pretty much unusable because the connection is interrupted all the time. I hope you can give any idea about the issue...

Hi Michael,

We need more info from you in order to debug this issue.

What platform, wl12xx device, and SW package are you using? What steps did you do to get these messages? And what are you trying to accomplish?

We have WL1271L chip on 9 sony ericsson phones which are based on qualcomm msm7x30 platform.

We have ported 3.4 kernel from scratch on this device because the last official from sony was 2.6.32. In 2.6.32 we used compat-wireless of 2.6.38 and wifi was working without the above error I mentioned. Since moving to 3.+ kernels, we tried using a variety of compat-wireless packages and ended up on ol_R5.SP5.01 which we were told that was the latest officially supported, but we still get the error.

This message can be reproduced very easily: After enabling wifi, we get the error after a few minutes of wifi usage, in both wifi client & hotspot modes.

Our wifi imlementation is here: https://github.com/LegacyXperia/msm7x30-3.4.x-nAa/blob/cm-10.1/arch/arm/mach-msm/board-semc_mogami-wifi.c

also here: https://github.com/LegacyXperia/msm7x30-3.4.x-nAa/blob/cm-10.1/arch/arm/mach-msm/board-semc_mogami.c lines 3974 to 4029

I'm ready to provide more info if it's needed.

An additional problem is that calibrator doesn't work:

Error log is this:

<6>[ 1949.070281] wl12xx: loaded
<6>[ 1949.074371] wl12xx: power up
<6>[ 1949.717498] wl12xx: firmware booted in PLT mode (Rev 6.3.10.0.136)
<3>[ 1949.719879] wl12xx: ERROR command execute failure 2
<4>[ 1949.720458] ------------[ cut here ]------------
<4>[ 1949.721221] WARNING: at /home/mike/android/cm10.1/hardware/ti/wlan/mac80211/compat_wl12xx/drivers/net/wireless/wl12xx/main.c:1432 wl12xx_queue_recovery_work+0x2c/0x9c [wl12xx]()
<7>[ 1949.722747] Modules linked in: wl12xx_sdio(O) wl12xx(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: wl12xx_sdio]
<7>[ 1949.722961] [<c00131fc>] (unwind_backtrace+0x0/0xe0) from [<c0083398>] (warn_slowpath_common+0x4c/0x64)
<7>[ 1949.723052] [<c0083398>] (warn_slowpath_common+0x4c/0x64) from [<c00833c8>] (warn_slowpath_null+0x18/0x1c)
<7>[ 1949.723205] [<c00833c8>] (warn_slowpath_null+0x18/0x1c) from [<bf08c4b0>] (wl12xx_queue_recovery_work+0x2c/0x9c [wl12xx])
<7>[ 1949.723480] [<bf08c4b0>] (wl12xx_queue_recovery_work+0x2c/0x9c [wl12xx]) from [<bf08f744>] (wl1271_cmd_send+0x4c0/0x4f0 [wl12xx])
<7>[ 1949.723785] [<bf08f744>] (wl1271_cmd_send+0x4c0/0x4f0 [wl12xx]) from [<bf0904cc>] (wl1271_cmd_test+0x50/0x74 [wl12xx])
<7>[ 1949.724182] [<bf0904cc>] (wl1271_cmd_test+0x50/0x74 [wl12xx]) from [<bf0a1e4c>] (wl1271_tm_cmd+0xf4/0x4a4 [wl12xx])
<7>[ 1949.724792] [<bf0a1e4c>] (wl1271_tm_cmd+0xf4/0x4a4 [wl12xx]) from [<bf043124>] (ieee80211_testmode_cmd+0x28/0x34 [mac80211])
<7>[ 1949.725280] [<bf043124>] (ieee80211_testmode_cmd+0x28/0x34 [mac80211]) from [<bf00ae20>] (nl80211_testmode_do+0x50/0x64 [cfg80211])
<7>[ 1949.726165] [<bf00ae20>] (nl80211_testmode_do+0x50/0x64 [cfg80211]) from [<c04b4ca4>] (genl_rcv_msg+0x1b4/0x1f4)
<7>[ 1949.726257] [<c04b4ca4>] (genl_rcv_msg+0x1b4/0x1f4) from [<c04b4304>] (netlink_rcv_skb+0x50/0xac)
<7>[ 1949.726348] [<c04b4304>] (netlink_rcv_skb+0x50/0xac) from [<c04b4ae4>] (genl_rcv+0x18/0x24)
<7>[ 1949.726409] [<c04b4ae4>] (genl_rcv+0x18/0x24) from [<c04b3d80>] (netlink_unicast+0x144/0x1d8)
<7>[ 1949.726501] [<c04b3d80>] (netlink_unicast+0x144/0x1d8) from [<c04b4134>] (netlink_sendmsg+0x28c/0x31c)
<7>[ 1949.726593] [<c04b4134>] (netlink_sendmsg+0x28c/0x31c) from [<c047b864>] (sock_sendmsg+0xb4/0xdc)
<7>[ 1949.726654] [<c047b864>] (sock_sendmsg+0xb4/0xdc) from [<c047baec>] (___sys_sendmsg+0x1c0/0x25c)
<7>[ 1949.726745] [<c047baec>] (___sys_sendmsg+0x1c0/0x25c) from [<c047d264>] (__sys_sendmsg+0x3c/0x60)
<7>[ 1949.726837] [<c047d264>] (__sys_sendmsg+0x3c/0x60) from [<c000d8c0>] (ret_fast_syscall+0x0/0x30)
<4>[ 1949.726898] ---[ end trace f1d85953b4ee7143 ]---
<4>[ 1949.727539] wl12xx: WARNING TEST command failed
<4>[ 1949.728393] wl12xx: WARNING testmode cmd test failed: -5
<6>[ 1949.731872] wl12xx: power down

Hi Michael,

Can you please provide the log with these issues? And did you follow the build script to build the driver?

Victor, what logs do you need, aren't the above parts enough?

I built the drivers with the script and also pulled all the changes that were tagged with ol_R5.SP5.01 from TI-Openlink github and applied them to my source. I'm working on android, specifically cyanogenmod, based on android 4.2 if that matters.

About the wifi interruption problem, I have already tried many things and many different sources/versions of the driver/firmwares since April but the interruption error always exists.

Hi Michael,

I need the log since boot to see if everything is being initialized correctly, and, plus, I need to know what steps you did so that you get these messages.

On the other hand, we really cannot guarantee that our chip will be 100% compatible with third party host. That's why we provide driver source for anyone who want to use this device so anyone can modify.

Hi Michael,

did you check /proc/interrupts/ and see if you are seeing interrupts being generated?

Probe the line see if you have proper configuration (is it configured to INPUT?).

It seems host is not getting response from the chip? 

Thanks

Vijay

Schematics: ALS_INT/BT_HOST_WAKE/WLAN_IRQ = GPIO 147
board-semc_mogami-wifi.c: #define MOGAMI_WIFI_IRQ_GPIO 147

There are no interrupts for line 147 but after investigating the source, the gpio is calculated with MSM_GPIO_TO_INT(147):

#define NR_MSM_IRQS 128
#define MSM_GPIO_TO_INT(n) (NR_MSM_IRQS + (n))

So 128+147=275

So by running:

cat /proc/interrupts

...

275: 3299 msmgpio wl12xx

...

I can see there are interrupts generated.

The line is configured to input too:

gpio_direction_input(MOGAMI_WIFI_IRQ_GPIO);

I will get a complete log from boot until the interrupt error these days.

Also enable debug logs in the MMC and see if there is read request happening once you receive interrupt?

MMC_DEBUG is your option..

I would suggest scope the IRQ line, you will have better control.

Thanks

Vijay

Michael, maybe we have been searching in the wrong place.

Could you please check the kernel sleep modes as defined in the kernel config and maybe compare them with the 2.6.32 kernel? Maybe the 3.x kernel uses a processor sleep mode that disables interrupts in a deep sleep. This would explain why there are mostly interrupts, but sometimes not.