No pin-dialog appears after boot, so no gsm is working in 2008.8

[Rorschach]

First: This is no duplicate of the 3G-problem. My sim-card is no 3G card. It is a normal sim card from ortel mobile and is working quite fine e.g. with FSO 2.

But with 2008.8 there's no pin-dialog appearing. In more than 30 boots I got one single time the pin-dialog to appear and after giving in my pin gsm was working just fine. I could call and recieve calls.

But as said it appeared just once in over 30 boots. In the other cases it just didn't show up, so I couldn't give in my pin and so gsm is not working at all.

Please tell me what more information you need to solve this problem.

[spielc]

Just for completeness: I remarked the same issue but i own a sim card from the austrian provider bob. To be be honest i haven't tried it as often as you did, i rebooted about 5 times and i never got a pin-dialog, so i reflashed a 2007.2-image and kernel and voila everything worked perfectly again. So the sim-card itself shouldn't be the problem. I haven't tried fso-stack so i can't tell if it would work with fso too

[apm]

Same (almost) problem here.
The pin-dailog showed up on first boot and seemed to accept my PIN. However GSM was not enabled.
The pin-dialog has never shown up since. (5-6 boots)

[schneck]

I confirm this error using GSM-Provider "E-Plus" in Germany - the pin dialog never showed up.

[apm]

Tried manually using the serial port with cu
It just hangs after "Connected"

[Peetrus]

Replying to apm:

Same (almost) problem here.
The pin-dailog showed up on first boot and seemed to accept my PIN. However GSM was not enabled.
The pin-dialog has never shown up since. (5-6 boots)

I've got the exact same problem

[Peetrus]

Sorry, I seem to have changed severity

[jomat]

Replying to schneck:

I confirm this error using GSM-Provider "E-Plus" in Germany - the pin dialog never showed up.

Same with O2 in germany.

[thomasb]

It seems to work with my T-Mobile SIM (although it takes a minute or so after X is up until the PIN dialog appears), but it doesn't seem to work with my Vodafone SIM. I'm attaching some log data.

[h.koenig]

I have the same problem (no pin dialog, no gsm) using an irish prepaid card from vodafone which worked fine so far with all other OM kernels/stacks.

from #1763 I learned that gsm relates to "qpe". now I see the following in "ps uaxwwww" output after reboot in ssh session:

root 1551 0.0 0.4 2568 520 ? S 08:33 0:00 /usr/bin/app-restarter The qpe process vanished. This is bad.?This is not meant to happen and is likely a sign of?a bug in Qtopia. Please try to reproduce it and?report the issue to ​http://docs.openmoko.org.??To be able to use your phone as a phone again you?will have to restart Qtopia.? qpe
root 1552 0.0 0.5 2924 728 ? S 08:33 0:00 logger
root 1553 4.4 5.8 16228 7196 ? S 08:33 0:15 enlightenment -profile illume
root 1554 7.5 15.1 85264 18740 ? Sl 08:33 0:26 qpe

note that qpe is still running, but in hangs in select():

root@om-gta02:~# strace -p 1554 -tt
Process 1554 attached - interrupt to quit

08:44:07.482158 select(53, [3 7 8 9 10 11 12 19 21 26 36 37 38 39 40 41 42 44 50 52], [], [], NULL) = 1 (in [7])
08:44:23.433705 ioctl(7, FIONREAD, [64]) = 0
08:44:23.436966 read(7, "\241 z\3,\0\240\0\232\0\0\0\241\0\0\0\0\0\0\0,\0\240\0"..., 64) = 64
08:44:23.448045 write(7, "\31\0\v\0;\0\0\0\0\0\30\0! \0\0;\0\0\0\232\0\0\0\241\0"..., 88) = 88
08:44:23.466111 ioctl(7, FIONREAD, [0]) = 0
08:44:23.471940 timer_delete(0x1) = 0
08:44:23.482227 timer_delete(0x1) = 0
08:44:23.488343 select(53, [3 7 8 9 10 11 12 19 21 26 36 37 38 39 40 41 42 44 50 52], [], [], NULL) = 1 (in [7])
08:44:39.433712 ioctl(7, FIONREAD, [64]) = 0
08:44:39.436979 read(7, "\241 |\3\16\0\240\0\232\0\0\0\241\0\0\0\0\0\0\0\16\0\240"..., 64) = 64
08:44:39.448049 write(7, "\31\0\v\0;\0\0\0\0\0\30\0! \0\0;\0\0\0\232\0\0\0\241\0"..., 88) = 88
08:44:39.466719 ioctl(7, FIONREAD, [0]) = 0
08:44:39.473851 timer_delete(0x1) = 0
08:44:39.482178 timer_delete(0x1) = 0
08:44:39.488577 select(53, [3 7 8 9 10 11 12 19 21 26 36 37 38 39 40 41 42 44 50 52], [], [], NULL) = 1 (in [7])

fd 7 is a socket (how can I find out what's connected to this socket?)

root@om-gta02:~# ls -l /proc/1554/fd/7
lrwx------ 1 root root 64 Aug 9 08:43 /proc/1554/fd/7 -> socket:[3469]

if I kill qpe I get that restart dialog (no surprise;).

when I start qpe in an ssh without setting DISPLAY, I get the keyboard window on my notebook on the very top of the screen and a 2nd black window at the bottom which only shows "bacK" at the right. I can toggle the keyboard layers to numeric, but I don't see any input and pressing RETURN doesn't seem to matter.

when I start qpe with "DISPLAY=:0 qpe" I _do_not_ get the keyboard on the FR !! I only see very short display distortions in the lower part of the screen (likely the keyboard showing up and disappearing immediately ?!)

can this be "just" a problem with X11 rendering of the keyboard/pin dialog ?

[h.koenig]

Replying to thepizzaking:

how do I get that log data on my FR ?

[apm]

can this be "just" a problem with X11 rendering of the keyboard/pin dialog ?

I don't think so. It does come up once in a while. Try restarting the X-server. That usually makes it appear.
However, it won't take my PIN and killing qpe (which holds the modem tty) and trying to talk to the modem manually doesn't work either.

[zecke]

Reboot, ssh into the device, get me the output of logread and attach that to this bug... make sure to wait long enough to have Qtopia started.

[thepizzaking]

Same troubles here, with Savvytel in Australia (Uses the Vodafone Australia network), I'll attach the log file.

[thepizzaking]

Fail log Savvytel Australia (Vodafone network)

[Peetrus]

logread

[apm]

apm logread output.

[apm]

I've attached the logread output.
What I did was a shutdown, inserted my SIM, booted and the PIN-dialog didn't come up.
Then I restarted the X-server and that made the PIN-dialog come up. Then I entered the PIN and tried using the dialer - but got the error-message that GSM was not available.

PIN and IMSI commented out, but it is the correct PIN and it seem to correctly indentify that it is "TDC MOBIL" which is my network.

[thenubus]

Hi,

well for me a pin dialog shows up, but it only shows letters and no numbers. An there is no way to correct the input (no backspace or delete key)

Using german medion-mobile prepaid (e-plus)

[mickeyl]

Please check whether the PIN dialog just opens in the background, i.e. use illume to check the task list.

For the keyboard problem, slide your finger up or down on the keyboard to change the layout.

[Rorschach]

Replying to mickeyl:

Please check whether the PIN dialog just opens in the background, i.e. use illume to check the task list.

I would like to do use if you would tell me the name of the process of the pin dialog. I checked ps aux mutliple times no but could never see anything with a name which looks like it would belong to a pin-dialog.

[h.koenig]

Replying to mickeyl:

Please check whether the PIN dialog just opens in the background, i.e. use illume to check the task list.

I only see "Home" in the task list, no pin menu or other tasks around..

[spielc]

Replying to mickeyl:

Please check whether the PIN dialog just opens in the background, i.e. use illume to check the task list.

Well when i still had ASU (as i said before i switched back to 2007.2 as i was at least able to use my openmoko as my primary phone with this distribution) installed i didn't see anything that was related to PIN-entry, i didn't check the output of ps via terminal (btw. PLEASE include some kind of terminal-application into the standard-distribution, in my eyes linux without some kind of access to the commandline is unusable) or ssh tho

[thomasb]

Sorry, forget the log that I posted, the error messages look more like good old #666. I thought that I had this SIM card working once in my Freerunner, but I must have mixed something up.

The error messages in the other logs look different, though, so I guess this bug remains valid.

[thepizzaking]

I couldn't manage to get the PIN input dialog up at all (not even by restarting the XServer), but I removed the SD Card and then the PIN came up about 30 seconds after booting, though, after I entered my PIN I couldn't receive or make any calls.

[Rorschach]

No, removing the SD-Card changes nothing for me. I tested again FSO2 and 2007 and with both images I can give in my pin and use GSM but with 2008.8 I can't.

So as already pointed out this bug is not related to the 3G bug. Any help on figuring this bug out would be nice.

I'm still waiting for any information about what the binary which asks for the pin is called and which process starts the dialog.

[zecke]

Okay. This is getting way too chaotic and not manageable at all. I have no other option than to close the bug, as we at least have two different issues.

@Peetrus and others: You run gsmd and qpe. This is not going to work. Deinstall gsmd or qtopia... If you want you can file a bug report for the distro team to put rconflicts in qpe and gsmd, so you can not install both at the same time.

saytel.log: Good log. The QAtChat is confused due a wakeup command (ATE0) and intereptes this response (OK) as the response of another command. So AT+CPIN? does respond with OK and the +CPIN is discarded. This is related to the various "GSM no signal/antenna" registration. I fixed that bug yesterday and I hope to have testing packages available soon. Also please file another bug report for that.

[apm]

What?!? gsmd?
No I don't. I'm perfectly aware that it's not supposed to work on 2008.8 and I've done nothing to install it and I can't find it anywhere on the system.

[Sander Hepp]

running stock 2008.8, so no gsmd (that I'm aware of).
9 out of 10 boots no PIN dialogue appears.
SIM works fine in 2007.2 and Qtopia.

[apm]

Looking at the output from logread it seems the problem is not the PIN-dialog. It correctly passed on the PIN to the modem, but afterwards, when I use the dialer it never tries to send an ATD command. It just decides that there's no GSM.
This can't be an Assassin problem, changing to qtopia which holds the TTY

[leo.studer]

I am having the same issue with Belgian provider BASE, see the attached logread output

[spielc]

I haven't installed gsmd neither, it was PLAIN ASU (and i would assume that you wouldn't ship gsmd with ASU when you already KNOW that qpe and gsmd interfere with each other...). So there has to be another reason for this problem..

[olberger]

See also #1798 where the same ticket was duplicated apparently.

[apm]

More info:
Now I couldn't use GSM, I decided to take the phone for a car trip testing GSP (without reboot). ... and lo an behold, after driving around for 15 minutes, suddenly the GSM works.
So maybe the symptoms of no PIN-dialog and no GSM after correct PIN entry (when the dialog makes one of its rare appearances) is just a problem of the system being slow to become operable.
Or is it a behaviour problem? Are the people seeing this symptom just the once who right after boot jumps directly to PIN entry and the dialer - getting the "No GSM" error message?

[zecke]

Okay. This is getting way too chaotic and not manageable at all. I have no other option than to close the bug, as we at least have two different issues.

@Peetrus and others: You run gsmd and qpe. This is not going to work. Deinstall gsmd or qtopia... If you want you can file a bug report for the distro team to put rconflicts in qpe and gsmd, so you can not install both at the same time.

saytel.log: Good log. The QAtChat is confused due a wakeup command (ATE0) and intereptes this response (OK) as the response of another command. So AT+CPIN? does respond with OK and the +CPIN is discarded. This is related to the various "GSM no signal/antenna" registration. I fixed that bug yesterday and I hope to have testing packages available soon. Also please file another bug report for that.

In case this was not seen...

[apm]

Replying to zecke:

Okay. This is getting way too chaotic and not manageable at all. I have no other option than to close the bug, as we at least have two different issues.

@Peetrus and others: You run gsmd and qpe. This is not going to work. Deinstall gsmd or qtopia...

This has got to be a joke, right?
I mean... here we are, trying to help you debug a real problem and you just plainly states that you don't care because we're running unsupported software (gsmd), WHICH WE ARE NOT!

[schneck]

Concerning gsmd etc.: I was talking about a _fresh_ install. Yesterday, I tried once again, and made the same observation as apm: Waiting about 1 hour made the pin-dialog appear. After a reboot, it didn't work at all. Running qtopia works: it requests the pin instantly after booting, every time.

[apm]

Oh... I just discovered: Incoming calls work, but using the dialer to call out still says: "No phone call is possible. Reason GSM phone is not registred, No network".

I'm reopening this, and please take it serious this time. WE DO NOT RUN gsmd

Symptoms are:

• PIN dialog does not appear after boot!
• It can appear later - for me it sometimes work to restart X
• When it appears it seems to take the PIN correctly
• But afterwards, there's no outgoing GSM calls. (for me incoming calls work though)
• However... GSM has been seens to start working after waiting >30 minutes.

[leo.studer]

Replying to zecke:

Okay. This is getting way too chaotic and not manageable at all. I have no other option than to close the bug, as we at least have two different issues.

@Peetrus and others: You run gsmd and qpe. This is not going to work. Deinstall gsmd or qtopia... If you want you can file a bug report for the distro team to put rconflicts in qpe and gsmd, so you can not install both at the same time.

saytel.log: Good log. The QAtChat is confused due a wakeup command (ATE0) and intereptes this response (OK) as the response of another command. So AT+CPIN? does respond with OK and the +CPIN is discarded. This is related to the various "GSM no signal/antenna" registration. I fixed that bug yesterday and I hope to have testing packages available soon. Also please file another bug report for that.

In case this was not seen...

This is no way to deal with a bug report, what the hell with gsmd ? do all the log information attached to this bug reffers to gsmd ? I don't think so !

So instead of keeping on closing this pretty active bug please be more constructive.

[apm]

With the recent discovery that I can receive calls, but not make calls, once I've managed to get the PIN-dialog, I would suspect, that this is related to #1801

[Rorschach]

Problem has finally been identified and workaround is available. Just follow this thread on the ML: ​http://lists.openmoko.org/pipermail/community/2008-August/026096.html

Pin-Dialog is now appearing with !every! boot.

[zecke]

Come on. Instead of actually fixing any bug and moving packages to .testing I'm busy with helping people to use a bugtracker... (seen globally on all incoming bugs)

Replying to apm:

Oh... I just discovered: Incoming calls work, but using the dialer to call out still says: "No phone call is possible. Reason GSM phone is not registred, No network".

Yes, we at least have four reports for that. I have witnessed this as well.. I have done a fix, but I'm not able to put a potential fix for that into .testing as I'm completely busy with assisting people to use a bugtracker....

I'm reopening this, and please take it serious this time. WE DO NOT RUN gsmd

At least one user did and I was referring to the log message. See, I acknowledge there is an issue. There is no doubt that there is an issue. But there is no way I can "solve" what this bug report has been turned in. I can not set it to "in_testing" as there is no way QA can verify that all the mentioned issues have been fixed. So the best thing I can do is to close this bug, and open one bug for one issue mentioned, or rely on people doing that. Reopening the bug does not change anything but keeps me away from putting bugfixes into .testing.

Symptoms are:

• PIN dialog does not appear after boot!
• It can appear later - for me it sometimes work to restart X
• When it appears it seems to take the PIN correctly
• But afterwards, there's no outgoing GSM calls. (for me incoming calls work though)

This is all related to the QAtChat (see my 1st vs 2nd) and highly dependent on timing. So by restarting, or killing qpe, or changing configs can change it. See the last five commits in ​http://git.openmoko.org/?p=qtopia.git;a=summary

• However... GSM has been seens to start working after waiting >30 minutes.

Random luck. I think the scanning of external media is just wasting power but is not blocking anything inside Qtopia.

Please keep that bug closed, that does not mean there is no issue, but we engineers have to have a good signal noise ratio to do our work and sadly we really head to a bad direction with this bugtracker.

Like in the two closing attempts. Your options are:

• File a bug for 1st (no one did that)
• File a bug for 2nd (the initial reporter did)

[apm]

This shouldn't be in a bug tracker, but I must say I've never experienced so disappointing a behaviour when I've spent time providing debug data.

Just for the record, I'm not here to keep this ticket open, I'm here to help provide data until I can see the problem has been diagnosed and bottom line is that you closed the bug report with a wrong and arrogant diagnose.

Replying to zecke:

Come on. Instead of actually fixing any bug and moving packages to .testing I'm busy with
helping people to use a bugtracker... (seen globally on all incoming bugs)

This is insane. You're not learning me anything. I do this every day, just from your point of view, and I never tell a reporter to get lost with a claim that he's running unsupported software, when he is not.

Replying to apm:

Oh... I just discovered: Incoming calls work, but using the dialer to call out still says: "No phone call is possible. Reason GSM phone is not registred, No network".

Yes, we at least have four reports for that. I have witnessed this as well.. I have done a fix, but I'm not able to put a potential fix for that into .testing as I'm completely busy with assisting people to use a bugtracker....

Well - then that was what you should have written as diganose.

I'm reopening this, and please take it serious this time. WE DO NOT RUN gsmd

At least one user did and I was referring to the log message.

Yes, but a lot of us wasn't.

See, I acknowledge there is an issue. There is no doubt that there is an issue. But there is no way I can "solve" what this bug report has been turned in. I can not set it to "in_testing" as there is no way QA can verify that all the mentioned issues have been fixed. So the best thing I can do is to close this bug, and open one bug for one issue mentioned, or rely on people doing that. Reopening the bug does not change anything but keeps me away from putting bugfixes into .testing.

But you don't close a bug report by telling people the reason for their trouble is something they know and can prove is false.

Symptoms are:

• PIN dialog does not appear after boot!
• It can appear later - for me it sometimes work to restart X
• When it appears it seems to take the PIN correctly
• But afterwards, there's no outgoing GSM calls. (for me incoming calls work though)

This is all related to the QAtChat (see my 1st vs 2nd) and highly dependent on timing. So by restarting, or killing qpe, or changing configs can change it. See the last five commits in ​http://git.openmoko.org/?p=qtopia.git;a=summary

Thanks.

• However... GSM has been seens to start working after waiting >30 minutes.

Random luck. I think the scanning of external media is just wasting power but is not blocking anything inside Qtopia.

Hmm.. it seems pretty consistant though, that once it has started to work it work.

Please keep that bug closed, that does not mean there is no issue, but we engineers have to have a good signal noise ratio to do our work and sadly we really head to a bad direction with this bugtracker.

Sure I'll keep it close. Now I know that this problem is diagnosed. ... see the difference?
Your S/N ration can be kept down by not giving people bogus explanations. Write that you suspect this is a duplicate. Convince people that you're on top of it. Don't tell people falsehood - it only gives the impression that you don't know what your're talking about which will achieve the exact opposite of what you want.

Like in the two closing attempts. Your options are:

• File a bug for 1st (no one did that)
• File a bug for 2nd (the initial reporter did)

No reason - now I know you're on top of it.