[Bug 1003] GSM modem is not powered down when Linux is shut down

[bugzilla-daemon at bugzilla.openmoko.org]

http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1003

mwester at dls.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |788



------- Additional Comments From mwester at dls.net  2007-11-19 23:06 -------
> But there are some problems:
> 1. There is a bug in kernel, and that may make the system hang while
> pulling pin.
This bug is #788, and has been fixed for a very long time.  If you choose not to
apply the patch provided in bug #788, then it is simple to arrange the stty
statements to avoid triggering the bug.  Therefore this argument is NOT a reason
to reject the original solution to this bug report.

> 2. "echo -e "AT at POFF\r" >$GSM_DEV"  is not a reliable way to send
> command to modem. 
> In our experiments, it is not as stable as we expected.
Ok.  Please elaborate.  What exactly failed, and how?  Once again, this point
(especially when it is thrown out here without any details to support it) is not
a reason to reject the original solution to this bug report.  It is, at best, a
reason to fix whatever is "not a reliable way" about it, whatever that might be.

> 3. It will reset the GSM modem before turning it off (not good
> in flying mode case.)
Please elaborate.  Why is this not good in flying mode case?  As soon as the
modem initializes, it reads the AT at POFF command and powers off -- there are no
other commands issued or queued to cause it to transmit.  Please point us to
some documentation that would indicate what this GSM modem does on power-up (and
if it does, in fact, transmit on power-up, then it can be argued that the modem
itself is flawed in design).  In any case, this also is not a reason to reject
the original solution, although it might be a reason to have an out-of-band
flag, perhaps managed by the kernel, that would ensure that no user action could
cause the modem to transmit in the event that the phone crashes and shuts down
while in "flying mode".

> In my experiments it shows that K34modem has the following advantages:
> 1. It can reliably and stably turn off the modem *IFF* GSMD works well. 
Yes.  Absolutely correct.  But the keyword here is: IFF.  The fact is that GSMD
DOES NOT work well.  Yes, it should be fixed.  Yes, it should be fixed soon. 
But the fact of the matter is that right now countless neo's are ending up with
flat batteries and are rendered unbootable (see the other bugs about how the Neo
will not boot even if plugged in to USB if the battery has been flattened). 
This is an extremely frustrating situation for users.  This argument is a valid
argument, IFF someone can make GSMD work reliably and well.  Until then, the fix
as originally documented in this bug report remains the best alternative to
resolving the issue reported by this bug report.

> 2. It avoid to touch the kernel bug that hangs the whole system.
Apply the patch that OpenMoko has been ignoring in #788.  That bug is thoroughly
understood, and a workaround has been developed, and is being used by numerous
Neo users today.  This is not difficult - apply a patch, and this issue goes away.

It's also worth noting that the refusal of OpenMoko to fix bug #788 is one of
the things that makes the Neo so unreliable and frustrating.  So while we
understand that "purity" and avoidance of "architectural layering violations"
and other good design principles are important, there is a need to apply
less-than-perfect solutions and patches to quickly solve a problem, especially
when the real solution will take many months and has dire consequences, such as
crashing the kernel (#788) or flattening the battery and rendering the device
unbootable (this bug report).

> 3. It will automatically failed and do nothing in
> "flying mode" (if implement in the future)

Ahhh! So "flying mode" is a red herring, because it is not yet implemented? 
This is a ridiculous argument against the original fix for this problem. 
When/if "flying mode" is actually implemented, then this fix can be revisited
and changed or removed as necessary.  Until then, this argument is not applicable.

> Here comes out a potential assumption, GSMD has to be alive
> when K34modem runs.
> Is this logical?  
> I think it ok, though not very ideal. 

No.  As stated above, GSMD is not reliable enough, and there are far too many
reasons for users to shut it down.  Not to mention that the dialer code shuts
down (and attempts to restart) gsmd as well.  There is simply no reasonable
reason to assume that gsmd is running when a user finds the need to power off
the device.  Quite the contrary - it is reasonable to assume that the user will
power off the device when it has gone wrong in some way.  At some point, we can
assume that the user will restart it -- but right now, it is more likely that if
the device ceases to function properly as a phone, the user will shut it down
and use an alternate cell phone.  And unless the patch as originally provided in
this bug report is used, in that use case the Neo will quietly sit in the user's
pocket, draining the battery until it is totally flat.  At which point, the
device will fail to reboot, even if connected to a USB cable.

> 1. We can write a new program to turn off the GSM firmware stably
> and reliably. 
>   But since we have GSMD and libgsmd-tools that can do the same thing,
> why not
> take good use of it?   And save the space of rootfs?
>   All we have to do is allow gsmd not been killed at this moment. 

For reasons repeatedly stated above, and on IRC discussions with openmoko, THIS
IS CURRENTLY ONLY A DREAM!  Gsmd is NOT reliable enough.  Some day, we hope -
but not today.  Please stop confusing future goodness with today's bug reports.

> 2. As for the those conditions that system device failure (or GSMD
> terribly failed ), in these cases system should reboot but not shutdown. 

Really?  Should that printed in multiple languages on the back of the Neo? 
That's just ridiculous - when the user is sufficiently frustrated with the
device, they will power it off.

But if OpenMoko *REALLY* believes that, then please remove the shutdown command,
the poweroff command, and the corresponding menu items in the neod daemon, and
replace them all with the appropriate "reboot" command.  Also ensure that u-boot
is altered to make sure that reboots are attempted at all times.

> In my opinion
> * GSMD has be stable enough to work normally to the end.
> (This is another issue. )
WHAT!!!!  "This is another issue."????  NO NO NO!  This is *EXACTLY* the issue -
gsmd fails, and fails all the time, and leaves phones sucking batteries dry! 
Yes, gsmd should work.  BUT IT DOES NOT, and it will not for a very long time. 
Once it is judged that gsmd is reliable, and once the dialer and other
applications stop restarting it all the time, and once the mux is implemented so
that gsmd doesn't need to be shut down in order to do data calls, THEN perhaps
we can say that gsmd is stable and will be running at shutdown.  This bug report
is for a problem in the "here and now" - this argument is referring to the "in
the future".  This is a dream, not an argument against using the patch/fix as
originally posted in this bug report.

> Using GSMD to turn the modem off is not a bad choice.
No.  It's not.  If gsmd stays running.  But it doesn't.  So therefore, relying
on gsmd to turn off the modem becomes a bad choice.

> Or if you can use "cu" or some other stable way to turn the GSM modem
> off, is also a good choice. 
Yes - except that cu can't twiddle the CRTSCTS mode that's required.  So maybe
"expect".  Or a python script.  Or a perl script.  Or a very small C program. 
There are so very many ways to do this.  If you can define what you find to be
"unstable" about "echo", an appropriate substitute for echo can be found, and
the fix as originally attached to this bug can be altered, and used.

> * K35modem take good usage of shutting down system will automatically
> pull down the pin without hang the whole system. So the kernel's bug
> (It's also another
> issue.) will not be a blocker to this case.

Sigh.  Here we go again on this unrelated issue.  Apply the patch to bug #788,
and the problems all go away.  Really.  It's that easy.  This is a ridiculous
argument, because it is OpenMoko that is refusing to address bug #788, so
arguing that you need a different solution for *this* bug, because you won't fix
another bug, is foolish.  Don't solve this bug wrongly just because you won't
fix another bug.

> * Even more it pulls nothing and this property is good at flying mode. 
> (If we can select entering flying when turning on the phone.)

More arguments about "future" stuff.  When someone implements "flying mode",
then someone can revisit this fix.  Until then, the community would very much
like to have the Neo NOT flatten its batteries.

> Therefore, I think K35modem can solve the problem "GSM modem is not
> powered down when Linux is shut down".  

No. Quite wrong.  What this argument is about is rationalization of a fix that
is preferred by some folks at OpenMoko, even though it does not really solve the
current problem.

It is quite clear that we need a fix right now to ensure that the GSM modem is
powered off when the phone shuts down.  It is also clear that gsmd is not stable
enough to do this reliably.  To make matters worse, other software shuts down
gsmd (dialer), and it is also common for users to shut down gsmd because there
is no other way to use features that gsmd does not yet do (data).  So gsmd is
clearly not ready yet.  It is also clear that the arguments expressed contain a
great deal of "noise": constant references to a kernel crash are red herrings,
as this crash has been solved, and can be avoided in several different ways. 
Other references to "flying mode" also are red herrings, as no such feature
currently exists.  Additionally, there is no documentation to support that
resetting the GSM modem and immediately powering it off results in any attempt
by the modem to transmit.  Finally, there are references to the use of "echo" as
being unreliable, without any substantiation of that -- no trace, no error
messages, no logs, not even any specific symptoms.  But even so, that too is a
red herring -- echo can be replaced by a number of alternate implementations
that can address whatever issues are posed by the use of "echo".

In summary, the original fix, remains the correct solution.  Bug #788 has been
marked as a dependency.  The echo issue can be rewritten or changed, pending
concrete description of that problem by the person who made the claims that
"echo" is unreliable.

gsmd is NOT the correct place or way, at present, to resolve this problem.





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.