Modem crashes

[namagi]

Hi.

I was wondering if you could perhaps help with modem crashes (watchdog bites or smsm resets) on 3.4 kernel. Device in question is Photon Q 4G LTE/XT897/Asanti, unfortunately no longer officially supported but still the best slider qwerty out there.

We are using device tree appended to zImage from 3.4 kernel based on razrm/vanquish source.
Excluding modem, device and all components seem to be fully operational on the 3.4 kernel version.

The issue (issues?) are constant watchog bites from modem software or modem going into SMSM_RESET state where reset is first detected by SMD driver.
There are times when modem can work normally even for hours but those times appear to be related to suspend/idle. E.g., preventing the screen to turn off makes crashes much more rare and the only consistency I have been able to notice is that the crash primarily occurs when screen turns off. Also, toggling the screen on/off will certainly cause modem to crash. This behaviour can be observed in vast majority of cases. Unfortunately, modem will eventually crash even with the screen on, especially if the device was being used so I am not sure how much the above mentioned "consistency" is relevant. There is a lot more going on than just screen state change but perhaps there is some dependency or link between panel and modem, seeing that modem is notified of those state transitions...
SMSM state for modem so far has always been to "08108043", i.e.

<6>[ 7341.981320,0] atmxt_set_ic_state: IC state ACTIVE -> SLEEP
<6>[ 7342.313565,1] CPU1 is up
<6>[ 7342.404729,0] SMSM Int Modem->Apps
<6>[ 7342.404760,0] smsm_irq_handler: irq=70
<7>[ 7342.404760,0] <SM 00001929 08108043>
<3>[ 7342.404760,0] 
<3>[ 7342.404760,0] SMSM: Modem SMSM state changed to SMSM_RESET.

while the Apps state can vary.
When the modem crashes by watchdog bite, ramdumps (ramdump_smem.bin, ramdump_modem_fw.bin, ramdump_modem_sw.bin, /data/misc/ril/bp-dumps/modem.log) are a bunch of 0x0's while on smsm reset the only one containing non-null data is ramdump_smem.bin
For reference, crashing modem on 3.0 kernel (by an smsm reset) yields null data only for ramdump_modem_fw.bin, smem ramdump is filled with 2mb of data and modem sw ramdump with 65mb of data.

As you can see, I have no idea what is going on and any help would be greatly appreciated.

Here are some longer kernel log snippets:
smsm reset: http://pastebin.com/TKt8HhQ1
wdog bite: http://pastebin.com/jmwYkBZf ,
strings from smem ramdump: http://pastebin.com/wrPfrd50
It might be worth noting that modem.log, content of which is also included in smem dump, contains "SFR Init: wdog or kernel error suspected.", while under default circumstances log_modem_sfr() from modem-8960.c records "modem subsystem failure reason: (unknown, smem_get_entry failed).
The "modem subsystem failure reason: (unknown, init string found)." that can be seen in the above logs is an attempt of mine to allocate SMEM_SSR_REASON_MSS0 smem item.

• modem crash log almost always points to wl1m.c, line 6266, task IST418
  • rarely task times out (always rxtx, but it has the shortest timespan)

All of firmware (TZ, SBLs, Modem...) and proprietary blobs are from official JB released version.
machine = 'msm8960dt'
extended baseband = 'msm8960-svlte-B1.B2D.B5.C0.C1D.C10D.L25D'
baseband version: ASANTI_C_BP_1139.000.18.12P
HW_REV : 0x82b0
MBM_VERSION : 0x0000109b

I honestly don't know how to shorten this, not knowing makes it hard to filter out irrelevant data.
Basically, I would like to know if

• Have you encountered such an issue when migrating to 3.4 kernel?
• Do you have some idea what might have changed in kernel that could be causing such behavior?

Thank you in advance for an eventual reply.

[namagi]

Pretty please?
Something is missing or misconfigured. No clue even where to look anymore.