[Gta04-owner] Kernel 3.12 modem suspend behavior

[Lukas Maerdian]

Hi,

Am 12.12.2014 um 22:02 schrieb Sebastian Krzyszkowiak:
> On Fri, Dec 12, 2014 at 6:11 PM, Lukas Maerdian <luk at slyon.de> wrote:
>> Am 12.12.2014 um 16:41 schrieb Rico Rommel:
>>> Am Freitag, 12. Dezember 2014, 16:17:54 schrieb Lukas Maerdian:
>>>> Hello everybody,
>>>>
>>>> since quite some time I'm trying to debug the Replicant modem suspend
>>>> behavior, but I cannot find any solution...
>>>>
>>>> My problem is that the modem transitions into a strange state after a
>>>> suspend/resume cycle, where it just returns the CME error 0 (phone
>>>> failure) to every single AT command I send. If I kill/restart the Radio
>>>> Interface Layer ("killall rild"), the modem seems to be working fine
>>>> again, so I guess a "AT+CFUN=0; AT+CFUN=1" correctly resets the modem.
>>>
>>> I don't know if it's related to this or a bug in my phonesoftware, but on
>>> resume my phone switches automatically to airplane mode. So I have to set
>>> operating mode everytime the phone resumes.
>>> I use kernel 3.12 and can't remember, if this problem also existed with kernel
>>> 3.7.
>>
>> Hi Rico,
>>
>> indeed this seems to be the case! I'm on 3.12 as well and directly after
>> resume everything is fine (CFUN: 1) but about 1 sec after the resume I
>> receive a "+CREG: 0" URC and if I issue "AT+CFUN?" afterwards I receive
>> a "+CFUN: 4", i.e. airplane mode.
>>
>> So, after this I can simply switch airplane mode off (AT+CFUN=1) and the
>> device will be back online! Well... the 3G connection still needs to be
>> re-configured, but this is another issue.
>>
>> Thanks a bunch, this was the missing piece I was looking for!
>>
>> I assume the modem is still operational during suspend, i.e. is able to
>> receive calls/SMS and interrupt the CPU, can you confirm this?
>>
>> Best,
>>   Lukas
> 
> Gee, I tried to debug it a few times, but always thought it was some
> FSO issue - so no wonder that I failed. Never even thought that it
> could be on lower layer!
> 
> That explains a lot. Now let's find out why it happens at all :)

Hmm... It seems like the bug is not inside drivers/net/usb/hso.c, but
rather somewhere deep inside the tty subsystem. There weren't a lot of
commits between 3.7-neil-plus and 3.12-replicant4 in hso.c:

c20b7de fix problem with wrong status code sent by GTM601 during RING
indication
53f10d0 reverted hso driver to mainline so that we can put our latest
patch on top
d608319 Merge commit 'd8dfad3876e4386666b759da3c833d62fb8b2267' into
neil-3.1x-plus
e75dc67 hso: Fix stack corruption on some architectures
35e57e1 hso: Earlier catch of error condition
b3789b8 Merge branches 'bq27000', 'pwm', 'omap', 'power', 'displays',
'codecs', 'hso', 'mmc', 'serial', 'sensors', 'touc
f5c7e15 fix problem with wrong status code sent by GTM601 during RING
indication
c514c7b HSO: allow power-save
aa27a09 TTY: add tty_port_tty_hangup helper
6aad04f TTY: add tty_port_tty_wakeup helper
21eaab6 Merge tag 'tty-3.9-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
38673c8 drivers: net: usb: Remove unnecessary alloc/OOM messages
2e124b4 TTY: switch tty_flip_buffer_push
05c7cd3 TTY: switch tty_insert_flip_string
191c5f1 TTY: call tty_port_destroy in the rest of drivers

The commit "191c5f1 TTY: call tty_port_destroy in the rest of drivers"
looked suspect to me, as I assume that something in the tty subsystem
closes/destroys/suspends the serial port and thus the modem switches to
airplane mode. But after testing this commit doesn't seem to make any
change.

There were some more changes in hso.c from 3.12 to 3.18 and I wonder if
they might have fixed the issue already? Could somebody, using kernel
3.18, check the modem state after suspend? I.e. issue an "AT+CFUN?" and
check if it returns "1" or "4" after suspend?

Thanks,
  Lukas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20141218/6564c6f8/attachment.asc>