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 927] Application list not updated when new applications
are installed ([EMAIL PROTECTED])
2. [Bug 1178] iron out XVideo support in Xglamo
([EMAIL PROTECTED])
3. [Bug 65] Visual indication for SMS overflow
([EMAIL PROTECTED])
4. [Bug 65] Visual indication for SMS overflow
([EMAIL PROTECTED])
5. [Bug 65] Visual indication for SMS overflow
([EMAIL PROTECTED])
6. [Bug 1043] Call use cases ([EMAIL PROTECTED])
7. [Bug 876] finished usb host patch
([EMAIL PROTECTED])
8. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
9. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
10. [Bug 1131] SIM does not register with network
([EMAIL PROTECTED])
11. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
12. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
13. Your Bugzilla buglist needs attention. ([EMAIL PROTECTED])
14. [Bug 1180] helloworld doesn't build out-of-the-box on ubuntu
([EMAIL PROTECTED])
15. [Bug 788] Starting or stopping gsmd completely locks up the
Neo ([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=927
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 12:08 -------
Fixed upstream in libtaku, updated and tested to work in r3893.
------- 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=1178
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 17:20 -------
Created an attachment (id=506)
-->
(http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=506&action=view)
make XVideo extension work again
This makes XVideo work for me again. Cleaned up the YUV frame handling control
part of the glamo chip.
Now here is what xvinfo shows:
[EMAIL PROTECTED]:~$ DISPLAY=:0 xvinfo
X-Video Extension version 2.2
screen #0
Adaptor #0: "GLAMO Video Overlay"
number of ports: 1
port base: 56
operations supported: PutImage
supported visuals:
depth 16, visualID 0x21
no port attributes defined
maximum XvImage size: 640 x 480
Number of image formats: 2
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
So basically I can play mpeg films using mplayer on the device. Clipping
rectangle and Stop/RePutImage are not handled yet.
These are what I a will be working on for now.
------- 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=65
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 17:23 -------
This all works now as much as is possible - When phone memory runs low, it
closes the phone's SMS store and waits until memory becomes available again (and
then reopens).
Indicator is a flashing GTK_SAVE icon in the panel and a notification pops up
saying what kind of memory has run low - the notification can be dismissed, the
panel applet will flash until the problem is resolved (if the notification is
still visible, it will also disappear on resolution).
Will attach a .bb with the panel applet.
Now waiting on gsmd interface to query current sms memory status and signal to
know when memory becomes free again (or I can poll a query if that's necessary)
------- 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=65
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 17:24 -------
Created an attachment (id=507)
-->
(http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=507&action=view)
bitbake recipe for openmoko-panel-memory
------- 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=65
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 17:32 -------
Screenshot: http://scap.linuxtogo.org/files/9d5138d9fb5f11064ca1458c6c5e741d.png
------- 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=1043
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 21:32 -------
I have received the not that this is a kind of real bug report and I should
reopen it. Well, it really looks like a kind of spam, advertising some Google
web service. If it is a real bug report, it is incomplete till the level when
it is not clear that is wrong.
------- 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=876
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2008-01-21 23:16 -------
GPB9 ? At least that's what the schematics of GTA01Bv4 and GTA02v4 say.
Also, arch/arm/mach-s3c2410/usb-modeswitch.c doesn't seem to be used,
so I've remove it from the patch.
It's now in the 2.6.24 tree in SVN, revision 3909.
------- 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
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 00:04 -------
Shouldn't just resetting flow control when switching away from / powering down
the modem solve the problem at hand ?
I don't think we absolutely have to preserve flow control state, since gsmd
can very well take care of setting it up upon restart. If someone sets flow
control by accident, well, that's called tragic pilot error :-)
If I had to choose between the two patches, I'd prefer Fabien's, because it's
less intrusive. However, I'd be even happier with a patch that just clears
the darn flow control bit (in the platform-specific code).
Any takers ?
Getting rid of the potential endless loop is a different issue, and certainly
a worthwhile endeavour. (I'd suggest to find a suitable time source, then
loop until a configurable amount of time has passed, and then setting a flag
that disables further looping, until the UART becomes operational again).
I.e.,
static int stuck = 0;
do ok = ready();
while (!stuck && !ok && !timeout())
if (!ok) {
stuck = 1;
return;
}
stuck = 0;
------- 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
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 00:12 -------
(in reply to comment #34)
If it's just to avoid an infinite loop, there's no need to find a timesource;
just loop a maximum number of times, with a suitable udelay() within the loop.
See for instance s3c24xx_serial_rx_enable() on drivers/serial/s3c2410.c, which
does exactly that.
------- 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=1131
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 00:15 -------
Sorry, no luck.
I flashed the phone with the image you linked, but it's still not asking the PIN
number for the Vodafone SIM. It says "Registering ..." in the top of the display
for some minutes now, but doesn't ask when using the Vodafone SIM card.
Besides that, I don't have icons anymore, just Xs.
T-Mobile is still fine, though no icons as well.
Shall I do a trace again?
------- 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
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 01:04 -------
re #35: very nice idea, thanks ! Keep the patches coming ! :-)
------- 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
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 03:25 -------
> If I had to choose between the two patches, I'd prefer Fabien's, because it's
less intrusive.
Yes, but see comment #20 -- that approach still leaves a vulnerability where a
lockup can be triggered by something as simple as someone messing with startup
scripts or boot-time ordering issues.
> However, I'd be even happier with a patch that just clears the darn flow
control bit (in the platform-specific code).
I tried. The way the tty stuff is handled at the highest levels in the kernel
means that we just can't find all the possible places where flow control might
be set. The fact that the current ttys structures say that it isn't set is only
good for as long as the tty is held open; it reverts as soon as the tty is
closed. And then, of course, another process can open it and change the flow
control at any time. Overall, it meant mucking about in code several levels
higher in the tty subsystem, and I decided that was not the place to try to fix
this.
> Getting rid of the potential endless loop is a different issue, and certainly
a worthwhile endeavour.
Agreed. But that doesn't solve the problem, really. It just replaces the
kernel lockup with total lack of any console output on the serial device; might
as well just disable the console (a la Fabien's fix) if you're going to do that.
I remain firmly convinced that the correct solution is one that:
a) ensures that no combination of setting flow control and diddling with the
GTA01 serial port mux should *ever* result in the crash of the kernel -- this is
even more important now that efforts are underway to streamline the boot time.
b) ensures that in any combination of setting flow control and diddling with the
GTA01 serial port mux, the minimum of kernel messages are lost to the serial
port. This also is important as work continues on boot time issues, but also as
effort continues to simply debug 2.6.24.
Perhaps the problem is the way the patch is written? Does anyone have any
concrete suggestions on how to rewrite it such that it's more palatable?
Someone had concerns about the use of the "unused[]" elements in the
datastructure to record state (although there is precedent for this elsewhere in
the driver). Would it make it better if elements were added to the structure,
or if the data were recorded elsewhere? I guess I'm still not really clear on
the objections to the solution.
------- 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 ---
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugzilla.openmoko.org/cgi-bin/bugzilla/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at them, and
decide on an initial action.
Generally, this means one of three things:
(1) You decide this bug is really quick to deal with (like, it's INVALID),
and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to someone
else. (Hint: if you don't know who to reassign it to, make sure that
the Component field seems reasonable, and then use the "Reassign bug to
owner of selected component" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
Just use the "Accept bug" command.
To get a list of all NEW bugs, you can use this URL (bookmark it if you like!):
http://bugzilla.openmoko.org/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL
PROTECTED]
Or, you can use the general query page, at
http://bugzilla.openmoko.org/cgi-bin/bugzilla/query.cgi.
Appended below are the individual URLs to get to all of your NEW bugs that
haven't been touched for a week or more.
You will get this message once a day until you've dealt with these bugs!
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=934
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=935
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1012
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1081
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1107
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1127
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1133
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1136
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1158
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1161
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1162
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1165
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1177
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1180
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
Component|MokoMakefile |OE bitbake recipes / build
| |system
------- 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
------- Additional Comments From [EMAIL PROTECTED] 2008-01-22 09:06 -------
Let's take this to openmoko-kernel. Two quick remarks to #37:
a) Agreed, hanging the kernel is cruel and unusual punishment for merely
turning on flow control.
b) I don't think kernel messages should be printed at any price. In
particular, interrupting communication with GSM arbitrarily when the
kernel feels like mumbling something will not help towards making
gsmd more reliable :) I could see an exception for messages indicating
a clearly fatal condition.
------- 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
