Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. [Bug 1011] When running qemu there are many USB DataOverrun
messages ([EMAIL PROTECTED])
2. [Bug 544] Link to java-pkg-devel mailing list is broken
([EMAIL PROTECTED])
3. [Bug 1003] GSM modem is not powered down when Linux is shut
down ([EMAIL PROTECTED])
4. [Bug 1003] GSM modem is not powered down when Linux is shut
down ([EMAIL PROTECTED])
5. [Bug 1014] gsmd doesn't work in x86 platform
([EMAIL PROTECTED])
6. [Bug 1015] New: quemu-neo1973 in r3444 fails to compile
([EMAIL PROTECTED])
7. [Bug 1015] quemu-neo1973 in r3444 fails to compile
([EMAIL PROTECTED])
8. [Bug 1015] quemu-neo1973 in r3444 fails to compile
([EMAIL PROTECTED])
9. [Bug 1003] GSM modem is not powered down when Linux is shut
down ([EMAIL PROTECTED])
10. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
11. [Bug 1015] quemu-neo1973 in r3444 fails to compile
([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1011
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 12:07 -------
Rebuilt qemu this morning. It doesn't spam my terminal any more.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=544
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 12:47 -------
The lists should work now. Please verify.
Also I found the newly created lists have the wrong url. A 404 page is returned
when we are trying to access "more information about this list". It is an ill
configuration of mailman. This fault is also corrected. Please report if any
wrong url are found. Thanks.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1003
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 20:17 -------
K36atpoff is a good example to turn off the GSM modem.
But there are some problems:
1. There is a bug in kernel, and that may make the system hang while pulling
pin.
2. "echo -e "[EMAIL PROTECTED]" >$GSM_DEV" is not a reliable way to send
command to modem.
In our experiments, it is not as stable as we expected.
3. It will reset the GSM modem before turning it off (not good in flying mode
case.)
In K34modem there are still some problems:
1. GSMD has to be work when running K34modem
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.
2. It avoid to touch the kernel bug that hangs the whole system.
3. It will automatically failed and do nothing in "flying mode" (if implement in
the future)
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.
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.
2. As for the those conditions that system device failure (or GSMD terribly
failed ), in these cases system should reboot but not shutdown.
In my opinion
* GSMD has be stable enough to work normally to the end. (This is another
issue. )
Using GSMD to turn the modem off is not 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.
* 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.
* Even more it pulls nothing and this property is good at flying mode. (If we
can select entering flying when turning on the phone.)
Therefore, I think K35modem can solve the problem "GSM modem is not powered down
when Linux is shut down".
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1003
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 20:19 -------
Sorry for the typo K34modem
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1014
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 21:29 -------
It works for me. Are you getting an error from glibc about double free() and:
"Aborted." ? What are the symptoms?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1015
Summary: quemu-neo1973 in r3444 fails to compile
Product: OpenMoko
Version: current svn head
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: qemu-neo1973
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [email protected]
hi,
r3444 of trunk/src/host/qemu-neo1973 fails to build (make). Here is a patch to
make it compile and work (tested with openmoko/download.sh and
openmoko/flash.sh):
[EMAIL PROTECTED]:~/openmoko-trunk/src/host/qemu-neo1973$ svn diff
Index: hw/usb.h
===================================================================
--- hw/usb.h (revision 3444)
+++ hw/usb.h (working copy)
@@ -112,6 +112,8 @@
typedef struct USBDevice USBDevice;
typedef struct USBPacket USBPacket;
+#include "qemu-common.h"
+
/* definition of a USB device */
struct USBDevice {
void *opaque;
Index: usb-linux-gadget.c
===================================================================
--- usb-linux-gadget.c (revision 3444)
+++ usb-linux-gadget.c (working copy)
@@ -815,6 +815,7 @@
#else
# include "hw/usb.h"
+# include "linux-user/errno_defs.h"
int usb_gadget_init(void)
{
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1015
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1015
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 22:07 -------
Thanks for the report, I forgot to add the qemu-common.h include for the case
when Gadget fs is disabled because I only tested with it enabled. I added this
include in r3445, but it seems the errno_defs.h line wasn't necessary. Please
test and reopen if you still see the issue.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1003
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |788
------- Additional Comments From [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]" >$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 [EMAIL PROTECTED] 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.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=788
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |1003
nThis| |
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1015
------- Additional Comments From [EMAIL PROTECTED] 2007-11-19 23:35 -------
Your fix in r3445 works.
Thanks.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
