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. Openmoko Bug #1987: [Qt-Contact] conact name will have limit
letters when export from phone to SIM (Openmoko Public Trac)
2. Openmoko Bug #1989: addressbook not handling vCard 2.1 with
multiline records correctly on importing, often leading to crash
(wild memory leak) (Openmoko Public Trac)
3. Re: Openmoko Bug #1989: addressbook not handling vCard 2.1
with multiline records correctly on importing, often leading to
crash (wild memory leak) (Openmoko Public Trac)
4. Openmoko Bug #1986: AUX LED blicks too early at power on
(Openmoko Public Trac)
5. Openmoko Bug #1985: no auto-suspend after some time
(Openmoko Public Trac)
6. Re: Openmoko Bug #1989: addressbook not handling vCard 2.1
with multiline records correctly on importing, often leading to
crash (wild memory leak) (Openmoko Public Trac)
7. Re: Openmoko Bug #1983: eth0 doesn't exist / Oops during
bootup (Openmoko Public Trac)
--- Begin Message ---
#1987: [Qt-Contact] conact name will have limit letters when export from phone
to
SIM
------------------------+---------------------------------------------------
Reporter: wendy_hung | Owner: zecke
Type: defect | Status: new
Priority: high | Milestone: Om2008.9
Component: Qtopia | Version: Om2008.8
Severity: critical | Keywords:
Blockedby: | Reproducible: always
Blocking: |
------------------------+---------------------------------------------------
Summary:
conact name will have limit letters when export from phone to SIM
kernel:20080903-asu.stable-uImage.bin
root file system:20080910-asu.stable-rootfs.jffs2
Steps+current results:
1) create a contact name with more than 9 letters (with space is
ok)(contact 1)
2) check contact detail and press option to Export contact to SIM
3) check contact list you'll see the contact name was cut only left 9
letters (contact 2)
4) import contact 2 to phone, you'll see it reduce letter again
5) if phone to SIM will have the limit, SIM to phone with out. The limit
letter number is 9
6) please see attach photo (a bit ugly...sorry)
Expected:
no limit letters when export/import contacts
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1987>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1989: addressbook not handling vCard 2.1 with multiline records correctly on
importing, often leading to crash (wild memory leak)
---------------------+------------------------------------------------------
Reporter: kavol | Owner: zecke
Type: defect | Status: new
Priority: highest | Milestone: Om2008.9
Component: Qtopia | Version: Om2008.9-dev
Severity: blocker | Keywords:
Blockedby: | Reproducible: always
Blocking: |
---------------------+------------------------------------------------------
Hi.
I've exported my contacts from kaddressbook using vCard 2.1 format (cannot
use v 3.0, see ticket #1988) into a single file. I've copied the file onto
Freerunner and run "DISPLAY=:0 addressbook addressbook.vcf" from the
console.
The FreeRunner got stuck then.
Trying to find the cause:
- FreeRunner got stuck because oom killer killed some system processes
- oom killer kicked in because the addressbook greedily allocated memory
- the addressbook does this only on some vCard records
- the thing which these have in common is that there are multiline records
The other problem is, if "quoted printable" encoding is used and the line
ends in the middle of encoded character, the program does not crash, but
the character is decoded incorrectly.
I attach test case vCards for both problems.
I am using packages from testing:
Package: qtopia-phone-x11-addressbook
Version: 1:4.3.2+gitr3+906a00fdcb89fdcc8252f84a76625eb42c8fe302-r41
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1989>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1989: addressbook not handling vCard 2.1 with multiline records correctly on
importing, often leading to crash (wild memory leak)
------------------------+---------------------------------------------------
Reporter: kavol | Owner: zecke
Type: defect | Status: new
Priority: highest | Milestone: Om2008.9
Component: Qtopia | Version: Om2008.9-dev
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by kavol):
Priority:
highest
Severity:
blocker
huh? - I did not set these ...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1989#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1986: AUX LED blicks too early at power on
----------------------+-----------------------------------------------------
Reporter: h.koenig | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords:
Blockedby: | Reproducible:
Blocking: |
----------------------+-----------------------------------------------------
when booting the FR with 8-second-pwr-button the AUX LED flashes too
early, because this often triggers me to release the pwr button ("hey,
it's alive") which is just too early for startup -- the FR won't start and
I have to press pwr for another 8 seconds (and close my eyes;)
it would be nice if the LED only flashes _after_ the pwr up signal got
accepted and the FR really starts up...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1986>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1985: no auto-suspend after some time
----------------------+-----------------------------------------------------
Reporter: h.koenig | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords:
Blockedby: | Reproducible:
Blocking: |
----------------------+-----------------------------------------------------
Om 20008.8 + updates: since the last 1 or 2 updates (maybe up to a week
now ?!) I notice that auto-suspend doesn't work anymore for me.
I've set "blank screen" and "suspend after blank" both to 60 seconds but
after a while either only screen blank works, or even neither screen
blanker nor suspend work. (it's ok just after fresh boot).
right now when pressing the power button, only screen blanker gets
activated, no suspend -- but "apm -s" from ssh login still suspends,
so it's not the "device or resource busy" issue...
3 ideas what might trigger this problems:
a) it's triggered by my atd job which rus every 10 minutes to log battery
data. if that atd job resumes the suspended FR, then there will be no new
auto-blank or auto-suspennd anymore.
b) it's triggered by pressing the power button to suspend
c) the phone is kept alive because of lots of GSM communication I can see
in "logread" output:
logread | grep simyo
Sep 10 12:43:36 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:43:37 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:45:09 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:45:09 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:46:10 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:46:10 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:46:50 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:46:51 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:46:51 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:47:55 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:47:56 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:48:38 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:48:38 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:49:27 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:49:42 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:51:38 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:51:38 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:52:20 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:52:20 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:52:20 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:53:01 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:53:02 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:53:49 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:53:50 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:54:30 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:54:30 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:55:20 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
Sep 10 12:55:45 om-gta02 user.notice root: AtChat : F : "+COPS:
0,0,"simyo""
[EMAIL PROTECTED]:~# opkg list_installed kernel
kernel - 2:2.6.24+git75969+a1e97c611253511ffc2d8c45e3e6d6894fa03fa3-r1.01
-
which other information do you need ?
what can I trace to figure out
- why suspend doesn't work anymore (what happens when pressing power
button)
- what triggers that problem...
thanks for pointers!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1985>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1989: addressbook not handling vCard 2.1 with multiline records correctly on
importing, often leading to crash (wild memory leak)
------------------------+---------------------------------------------------
Reporter: kavol | Owner: zecke
Type: defect | Status: new
Priority: highest | Milestone:
Component: Qtopia | Version:
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Changes (by zecke):
* version: Om2008.9-dev =>
* milestone: Om2008.9 =>
Comment:
Remove milestone.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1989#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1983: eth0 doesn't exist / Oops during bootup
----------------------------+-----------------------------------------------
Reporter: Weiss | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: wifi kernel | Blockedby:
Reproducible: always | Blocking:
----------------------------+-----------------------------------------------
Comment(by werner):
I would consider the possibility of this being a hardware problem,
yes.
Perhaps first, we could have a look at whether there is something
else going wrong in the kernel that causes the driver to fail to
communicate and then ultimately leads to the Oops.
If you enter u-boot, you can increase the kernel's log buffer size
as follows:
GTA02v6 # setenv bootcmd setenv bootargs \${bootargs_base} \${mtdparts}
\${extra}\; nand read.e 0x32000000 kernel 0x200000\; bootm 0x32000000
GTA02v6 # setenv extra log_buf_len=2M
GTA02v6 # saveenv
This will increase the kernel log buffer size to 2MB, which should be
plenty. If you want to return it to its default size later, you would
GTA02v6 # setenv extra
GTA02v6 # saveenv
Then boot
GTA02v6 # boot
and retrieve all the information with
pc% ssh neo dmesg -s 2000000 >log
The -s option is important, because dmesg by default only retrieves
16kB.
In case nothing suspicious shows up:
If you don't mind disassembling the device, it may be worth checking
if the WLAN module is properly seated. It's glued to the top of the
main shield with some conductive adhesive tape, so it has some wiggle
room.
There is a small white connector close to the edge of the main PCB,
which connects the WLAN module. If you look at it from the side,
you should be able to see if the connector is fully inserted. If it
seems loose, you could gently press from the top of the WLAN PCB down
towards the connector.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1983#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
