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. Re: Openmoko Bug #2084: CRC Fail on boot , long boot time
before init , wireless isnt detected (Openmoko Public Trac)
2. Re: Openmoko Bug #2084: CRC Fail on boot , long boot time
before init , wireless isnt detected (Openmoko Public Trac)
3. Re: Openmoko Bug #2084: CRC Fail on boot , long boot time
before init , wireless isnt detected (Openmoko Public Trac)
4. Re: Openmoko Bug #2019: Headphone Jack Event
(Openmoko Public Trac)
5. Re: Openmoko Bug #1983: eth0 doesn't exist / Oops during
bootup (Openmoko Public Trac)
6. Openmoko Bug #2091: batget polls lots too often
(Openmoko Public Trac)
7. Re: Openmoko Bug #2091: batget polls lots too often
(Openmoko Public Trac)
--- Begin Message ---
#2084: CRC Fail on boot , long boot time before init , wireless isnt detected
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: julian_chu
Type: defect | Status: new
Priority: highest | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------+---------------------------------------------------
Comment(by werner):
Hardware is a possibility, yes. There's at least one case where the
problem is (was) almost certainly in the hardware:
https://docs.openmoko.org/trac/ticket/1983
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2084#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2084: CRC Fail on boot , long boot time before init , wireless isnt detected
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: julian_chu
Type: defect | Status: new
Priority: highest | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------+---------------------------------------------------
Comment(by Zoup):
well , all strange things are just happening to me .
well , how can i test ?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2084#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2084: CRC Fail on boot , long boot time before init , wireless isnt detected
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: julian_chu
Type: defect | Status: new
Priority: highest | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------+---------------------------------------------------
Comment(by werner):
You seem to be unusually lucky indeed :-(
I'd suggest you install a specific u-boot, kernel, and rootfs, and try
booting with init=/bin/sh, then check with iwconfig.
If this still doesn't work, please post the URLs of the u-boot, kernel,
and rootfs you installed here (URLs to the long name, with date/revision,
so that I can still find the files the next day :-), and the dmesg output
of that run, and I'll try the same setup.
On the hardware side, you could try to remove all power sources, then
disconnect and reconnect the WLAN module. That would rule out the "module
wasn't properly connected and the contacts came apart during transport or
use" hypothesis.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2084#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2019: Headphone Jack Event
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: openmoko-devel
Type: defect | Status: closed
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution: wontfix
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
------------------------+---------------------------------------------------
Changes (by werner):
* status: new => closed
* haspatch: => 0
* resolution: => wontfix
Comment:
I see in #2084 that you've made your peace with the state of things.
So let's close it as "wontfix".
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2019#comment:30>
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: closed
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution: fixed
Keywords: wifi kernel | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
----------------------------+-----------------------------------------------
Changes (by werner):
* status: new => closed
* haspatch: => 0
* resolution: => fixed
Comment:
Seems that this one was successfully resolved through warranty
replacement,
so let's close it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1983#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2091: batget polls lots too often
---------------------+------------------------------------------------------
Reporter: Viddy | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone: FSO
Component: unknown | Version: FSO-MS2
Severity: normal | Keywords: batget,polling
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
---------------------+------------------------------------------------------
A strace of
/usr/lib/enlightenment/modules/battery/linux-gnueabi-arm/batget
while it is running produces the following output, repeated:
Command to get ouput:
ps ax|grep batget|grep -v grep|awk '{print $1}'|xargs -n1 strace -Ff -p
Output:
open("/sys/class/power_supply/bat/current_now", O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4001e000
read(6, "-43125\n", 4096) = 7
close(6) = 0
munmap(0x4001e000, 4096) = 0
open("/sys/class/power_supply/bat/status", O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4001e000
read(6, "Charging\n", 4096) = 9
close(6) = 0
munmap(0x4001e000, 4096) = 0
open("/sys/class/power_supply/bat/time_to_full_now", O_RDONLY|O_LARGEFILE)
= 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4001e000
read(6, "0\n", 4096) = 2
close(6) = 0
munmap(0x4001e000, 4096) = 0
open("/sys/class/power_supply/bat/charge_now", O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
gettimeofday({1225162448, 995725}, NULL) = 0
select(6, [4 5], [], [], {0, 254907}) = 0 (Timeout)
gettimeofday({1225162449, 257579}, NULL) = 0
gettimeofday({1225162449, 260369}, NULL) = 0
open("/sys/class/power_supply/bat/capacity", O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4001e000
read(6, "100\n", 4096) = 4
close(6) = 0
munmap(0x4001e000, 4096) = 0
Count of calls, and time taken:
[EMAIL PROTECTED]:~# strace -fF -p 1416 -c
Process 1416 attached - interrupt to quit
Process 1416 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.004264 102 42 mmap2
0.00 0.000000 0 41 read
0.00 0.000000 0 52 10 open
0.00 0.000000 0 41 close
0.00 0.000000 0 32 gettimeofday
0.00 0.000000 0 41 munmap
0.00 0.000000 0 11 select
0.00 0.000000 0 42 fstat64
------ ----------- ----------- --------- --------- ----------------
100.00 0.004264 302 10 total
I appreciate that the easiest way to check the battery status is to poll
the device every so often, and inotify is more challenging to use, but
a) polling multiple files n times per second isn't a good idea, and b)
there really isn't any point in polling the battery while the screen is
off
Suggestions:
use sleep()
if screen is off, sleep() longer
if screen comes back on, wake up process, get it to update battery, go
back to sleep for a few seconds/minutes
Given that battery indicator is a four bar or percentage indicator, a
calculation on how long to sleep for given current capacity and discharge
rate divided by a fudge factor should give the time to sleep for before
any meaningful change in the indicator would be seen by the user.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2091>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2091: batget polls lots too often
-------------------------------+--------------------------------------------
Reporter: Viddy | Owner: openmoko-devel
Type: task | Status: new
Priority: lowest | Milestone: FSO
Component: unknown | Version: FSO-MS2
Severity: trivial | Resolution:
Keywords: batget,polling | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
-------------------------------+--------------------------------------------
Changes (by raster):
* priority: normal => lowest
* type: defect => task
* severity: normal => trivial
Comment:
first. 1. the default config for e (upstream) is 32 "ticks" (8 ticks per
second) between polls. thats every 4 seconds. that is less waking up than
almost anything else around on the system. second - it's a config option
in the battery module config - increase the # of ticks between checks
there is a gui for it. 2. you cannot use d/inotify on sysfs - you can't
get change events. it doesn't work. if you could - i would have already. i
use it where appropriate and possible already. 3. - there have been lots
of bugs with emitting events on the uevent file for the battery when
plugging/unplugging power and battery so poll time is "often enough" so
that u'll catch a change (like plug in power and start charging) with a
poll rather than a uevent - i don't know if this is fixed these days as
the polling covers it up mostly. just to expand you can get events - but
the event reports "ac plugged in" but battery wont report its charging for
an arbitrary amount of time after so you have to poll to find this out. or
that was the case last time i looked and was working on this code. 4. if
the screen is blanked u likely want to be going to sleep soon anyway
(suspend) so until zero-clock rolls around and all userspace stuff that
polls needs to be aware of this - it's not work the effort as you have a
problem of not having suspended, rather than there being occasional
polling. if the system is not idle (eg playing music or making a call)
while blanked, then you are constantly awake and consuming cycles anyway
so it doesn't matter. the poll overhead is nigh zero except for kernel ->
device overhead. 5. the battery meter is not a 4 bar limit - that is
merely the theme that om wanted that reduces accuracy. reality is that the
battery reports full detail and the batget abstraction will always report
a value from 0 to 100 for battery then the gadget and ultimately theme are
responsible for displaying it however the like (by putting up a group of
chickens and the more chickens you have, the more power, or by color
(green, yellow, red) or a dial, or... the ui designer entirely decides
that. batget/code know nothing of their intentions and are just there to
feed the current state of the machine :). the battery itself and other
themes display full accuracy (eg e17(illume)'s default theme), so you
can't calculate when to poll as power drain may be variable and the
theme/ui abstracts the display. 6. do some actual power measurements. kill
batget then run it by hand:
/usr/lib/enlightenment/modules/battery/linux-*/batget X
where X is ticks. there are 8 ticks per second. the default is 32. try it
and actually do power drain measurements (run a idle system for lets say
10 minutes and calculate battery drain at the end of it). do it while
running batget @ 32 ticks and with batget off. if you can show measurable
differences (that are not entropy - so u'll have to run the test multiple
times) it'd be maaaaybe worth a bit more code and effort - but really, it
isn't. my bet is that you will not show any measurable difference.
remember - i really paid attention to this when writing the code. it goes
to effort to minimise what it opens when it polls and how often it does
and allows it to be configured. i know about all the details about power
consumption, wakeups, (i've checked with powertop before). batget HAS to
poll (has no choice) and even have a generic mechanism to indicate the
polling interval. :)
so here's your challenge. test with batget off. run for a period of time
(10 mins, 30) measure drain (from full), recharge to full then do it again
with batget at 32 ticks, then maybe try it at 128 or 256 or 512 ticks
(make it a power of 2 - it only allows power of 2). if you got a
measurable difference from no batget to 32 ticks. if u see a difference <
5-10% it's probably entropy so u'll need to run the test many times to get
an average.
if you can show real differences - report back here :) because there is
nothing much u can do code-wise to improve this beyond the battery issuing
interrupts via kernel to indicate a change in level, which the battery is
not capable of doing as it literally needs to be polled to get its charge
on the hardware level. so someone will do the polling - if not batget -
it'll be a kernel thread. you just shuffle the problem out of your sight -
but don't remove it or the overhead. what you do add is likely lack of
control and configuration :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2091#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
