[Gta04-owner] Modem reenummerating (was: Re: Crowdfunding an Ubuntu smartphone)

[NeilBrown]

On Tue, 3 Sep 2013 14:26:54 +0200 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> Hi Radek,
> 
> Am 31.08.2013 um 12:32 schrieb Dr. H. Nikolaus Schaller:
> 
> > 
> > Am 30.08.2013 um 08:07 schrieb Radek Polak:
> > 
> >> On Thursday, August 29, 2013 01:00:54 PM Dr. H. Nikolaus Schaller wrote:
> >>> Am 29.08.2013 um 12:56 schrieb Radek Polak:
> >>>> On Thursday, August 29, 2013 11:50:26 AM Dr. H. Nikolaus Schaller wrote:
> >>>>> Am 29.08.2013 um 10:50 schrieb Radek Polak:
> >>>>> 
> >>>>> Looks like becoming a Heisenberg-Bug. The closer you look the less you
> >>>>> can grab it...
> >>>> 
> >>>> unfortunately yes...
> >>>> 
> >>>>>> I think that it has lost it after playing with AT_OPSYS. My GTA04 is
> >>>>>> brand new and i havent used AT_OPSYS command until yesterday.
> >>>>> 
> >>>>> Unfortunately I don't know what the factory setting is.
> >>>> 
> >>>> You can use AT_OPSYS? to find out on brand new GTA04 board if such board
> >>>> exists.
> >>> 
> >>> Hm. I don't think so :( All of them have been tested including some modem
> >>> commands... So unless we produce more, there is no really virgin GTA04
> >>> board :(
> >> 
> >> I think "some AT commands" dont matter unless you did AT_OPSYS.
> >> 
> >> Btw mine phone is now very stable. 315 calls and 0 reenumerates.
> > 
> > If I get it right, this is with OPSYS=0,2.
> > 
> > Hm. What I still don't get into a clear hypothesis is that it depends on
> > 2G vs. 3G AND suspend vs. no suspend.
> > 
> > If it would show up only when using suspend I would conjecture that
> > the EHCI/USB interface does not handle CPU suspends correctly. Maybe
> > irritating the modem which might not be prepared that the host is suspending
> > or getting into a bad state [1]
> > 
> > But the dependence on 2G vs. 3G does not fit into this picture.
> > 
> > BTW: in my setup I still have to try to find out why my GTA04 used for testing
> > only sees 2G (AT_ONCI?) - even if I issue OPSYS=3,2. Maybe I have played
> > with some other (persistent) settings of the modem. So at the moment I can't
> > try to reproduce 3G reenumerations.
> > 
> > -- hns
> 
> I have now a better setup to test this issue.
> 
> The major problem was that the antenna connection in the GTA04 was broken
> and therefore the signal strength wasn't good enough for 3G and the modem
> simply refused to switch to 3G mode even with OPSYS=3,2 because it did not
> even see a 3G base station.
> 
> But after replacing the antenna, I could now see reenumeration in ~10% of the
> incoming (and aborted) 3G calls.
> 
> To me it looks as if the first RING signal is not even being printed, but once I
> had a RING + some other unsolicted message. The caller is redirected to
> the mailbox quite immediately.
> 
> And, it is not only the modem reenumerating, but it also appears to be
> sort of resetting.
> 
> I conjecture that from the fact that parameters like AT+CRC=1 and AT+CLIP=1
> are reset when I reopen /dev/ttyHS_Application.
> 
> Hm. We may have some resonance of the 2.1 GHz UMTS signals with
> the ON_KEY transistor...
> 
> But I don't have the impression that the modem is switched off and on, because I
> don't have to wake it up again. I.e. the USB connection is reenumerated
> automatically. If we would have RF disturbances there would be some chance
> that the modem stays turned off after the transmission stops.
> 
> I have not enabled PIN checks on this SIM card for easier testing, so I can't see
> if the modem was really powered off, because then it would ask for the PIN
> again.
> 
> I use the latest 3.11 kernel and I don't think the kernel did go to suspend at all.
> 
>

Have you removed the 

+       pm_runtime_allow(&hso_dev->usb->dev);

line from drivers/net/usb/hso.c ??

I find that makes a big difference.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130904/43d919bd/attachment.bin>