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 #1841: white screen of death (WSOD) after resume
(Openmoko Public Trac)
2. Re: Openmoko Bug #1841: white screen of death (WSOD) after
resume (Openmoko Public Trac)
3. Re: Openmoko Bug #1728: SMS parser bug? (Openmoko Public Trac)
4. Re: Openmoko Bug #1766: [GSM Signal] no signal, can't make
phone call but can receive calls (Openmoko Public Trac)
5. Re: Openmoko Bug #1841: white screen of death (WSOD) after
resume (Openmoko Public Trac)
6. Openmoko Bug #1842: Verbosity & informational improvements to
dfu-util (Openmoko Public Trac)
7. Re: Openmoko Bug #1828: Assassin doesn't close packagekitd
anymore and so blocks opkg (Openmoko Public Trac)
8. Openmoko Bug #1843: u-boot's DFU upload garbles data at block
boundary (Openmoko Public Trac)
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
-----------------------+----------------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Keywords: wsod,resume
Blockedby: | Reproducible: always
Blocking: |
-----------------------+----------------------------------------------------
Because there's no bug-report describing exactly this problem I'm opening
a new one:
After suspending and resuming the screen is all white. The phone ist still
working, you can ssh to it and everything. Just the screen stays white.
The screen will stay white forever, no matter how long you wait it changes
nothing. The correct screen never comes back again. You have to shutdown
by pressing the startbutton for a time or reboot (via ssh) to use your
phone again.
This happens with every OS I tested!
This is imo a high critical bug and is preventing the daily usage of the
Neo Freerunner because of decreased battery-lifetime without being able to
resume. This bug is widly known on the mailinglist and irc for several
weeks but it seems no progress has been made into fixing it.
While other bugs like the 3G-Sim bug make the phone unusable for a certain
group of users this bug makes it unusable for everyone as daily phone.
Tested OSs by me:
* 2008.8
* FSO2
* Qtopia
* Debian
How to reproduce:
* suspend Neo Freerunner for more than 10-20min, try to resume after that
Interesting behavior:
* The screen still reacts on some things. e.g. under debian it gets
darkened after a few seconds of inactivity by the screenlocker and it gets
brigth (white) again when you touch it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
----------------------------+-----------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Resolution:
Keywords: wsod,resume | Blockedby:
Reproducible: always | Blocking:
----------------------------+-----------------------------------------------
Comment(by [EMAIL PROTECTED]):
Let's begin by determining what kernel you have running, as this is
probably more likely to be a kernel issue than a userspace issue if it
happens on all those different rootfs' -- can you provide information
regarding the kernel version and package version for each of the
environments you've tested? The output from "uname -a" will be somewhat
helpful; even better would be the full filename of the kernel image when
it was downloaded to be flashed (i.e.
"uImage-2.6.24+git1+cb3cc53a76c7f1f7c827d048db7a849e77071515-r1.01-om-
gta02.bin")
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1728: SMS parser bug?
--------------------+-------------------------------------------------------
Reporter: odlg | Owner: zecke
Type: defect | Status: accepted
Priority: high | Milestone:
Component: Qtopia | Version: Om2008.8
Severity: major | Resolution:
Keywords: | Blockedby:
Blocking: |
--------------------+-------------------------------------------------------
Comment(by wjbaird):
I've encountered the same problem - using a mostly stock OM2008.8 install
on a freerunner. a sample PDU is
{{{0791446742949940040BD0C7F7FBCC2E0300008080919075106935D2723BED2697E53A10BD3CA787400010B55E0605EB67502C078AC1743059B80D6A8162311D4C166E8350D7B77C9D02}}}
what I see is very similar to the already attached screenshot.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1728#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1766: [GSM Signal] no signal, can't make phone call but can receive calls
-----------------------------------+----------------------------------------
Reporter: dexteruk | Owner: zecke
Type: defect | Status: assigned
Priority: high | Milestone:
Component: Qtopia | Version: Om2008.8
Severity: normal | Resolution:
Keywords: GSM Antenna Signal | Blockedby:
Reproducible: | Blocking:
-----------------------------------+----------------------------------------
Comment(by catholicon):
I still have this issue on OM2008.8 with zecke's testing feeds. Today
there were lots of kernel module updates but this one still didn't work
out.
I don't get the signal bars even after suspend and then resume-on-call.
Ticket number 1801 (duplicate of this) has a copy of AtChat logs.
As an aside, how do I add myself to CC of this ticket?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1766#comment:34>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
----------------------------+-----------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Resolution:
Keywords: wsod,resume | Blockedby:
Reproducible: always | Blocking:
----------------------------+-----------------------------------------------
Comment(by zecke):
Small question. How is this different from #1621?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1842: Verbosity & informational improvements to dfu-util
----------------------------+-----------------------------------------------
Reporter: wiml | Owner: openmoko-devel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: host utilities | Version:
Severity: normal | Keywords: patch
Blockedby: | Reproducible: always
Blocking: |
----------------------------+-----------------------------------------------
I was trying to figure out what dfu-util is doing wrong on my system. I
made a handful of changes which I've included in this patch:
- include underlying libusb error in dfu-util failure messages
- make a second -v turn on verbose USB logging
- document -v in the man page
- extra details in error messages in a couple places
- fix a couple of typos
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1842>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1828: Assassin doesn't close packagekitd anymore and so blocks opkg
--------------------------+-------------------------------------------------
Reporter: Rorschach | Owner: tick
Type: defect | Status: closed
Priority: normal | Milestone: Om2008.8
Component: Installer | Version: GTA02v5
Severity: major | Resolution: wontfix
Keywords: | Blockedby:
Reproducible: | Blocking:
--------------------------+-------------------------------------------------
Changes (by tick):
* status: new => closed
* resolution: => wontfix
Comment:
Hi Rorschach,
Thanks for reporting and writing patch for this.
I had thought about this, and decided not kill packagekitd few months ago.
So it's a feature.
packagekitd will terminate itself automatically after 5 mins without
requests.
GUI users will not know the existence of packagekitd, it's transparent.
For power users, I think they will know how to deal with packagekitd. (Use
it or kill it) :-P
Cheers,
Tick
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1828#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1843: u-boot's DFU upload garbles data at block boundary
---------------------+------------------------------------------------------
Reporter: wiml | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: GTA02v6
Severity: major | Keywords:
Blockedby: | Reproducible:
Blocking: |
---------------------+------------------------------------------------------
I was trying to verify my downloaded kernel by re-uploading it again to
compare. The uploaded version differed in an interesting way: at offset
0x01f000, exactly 0x20000 bytes were missing (so that the uploaded file
contained at 0x01f000 the data that was at 0x03f000 in the original file).
This does not seem to be a dfu-util bug, but a u-boot bug.
Looking at the u-boot source code, I think the problem is in
handle_upload() in usbdfu.c, where it handles the wraparound at the end of
the NAND block. There are three bugs here:
- when it copies a new blockful of data, it copies it into the same
buffer that urb->buffer was already pointing to, thus overwriting the
beginning of the last buffer before it is sent back to the requestor
- it then calls memcpy() to copy the beginning of the newly-read block to
after the end of the buffer that urb->buffer is pointing to. If
ds->nand->erasesize is the same as the _buf[] array, then this will write
past the end of the _buf[] array and smash some other item in RAM.
- if a requested buffer exactly reaches the end of the block that's been
buffered in ds->buf, then handle_upload() will read a new NAND block into
the buffer even though it is not needed. (The test for (len > remain)
should probably go before the test for ds->ptr, not after?)
I would submit a patch, but I don't have a build environment set up for
uboot (or any jtag hardware for recovery from bad flashing, for that
matter) --- this is just from reading the uboot-dfu.patch file in svn.
I also wonder if this is related to ticket #676, although the comments in
that bug indicate corruption starting at 0x3001, not 0x1f000, so it may be
unrelated.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1843>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
