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 #1024: gsm modem oscillating between
registrated / not-registrated (Openmoko Public Trac)
2. Re: Openmoko Bug #2277: Wireless does not work with the
2.6.29 kernel (Openmoko Public Trac)
--- Begin Message ---
#1024: gsm modem oscillating between registrated / not-registrated
------------------------------------+---------------------------------------
Reporter: mic...@… | Owner: sean_chiang
Type: defect | Status: in_testing
Priority: high | Milestone:
Component: GSM Modem | Version: unspecified
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------------------+---------------------------------------
Comment(by PaulFertser):
Dieter Spaar finally found a way to fix recamping.
It's a hardware mod, basically increasing capacitance of C1009 (either
by soldering another one in parallel or desoldering C1009 and putting
a shiny new 22uF 0805 low-ESR cap on its place).
Great thanks to everybody who worked hard to make this happen and who
verified the solution!
Details can be found at
http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ,
results of suspend time (143hrs) at
http://totalueberwachung.de/blog/2009/06/03/freerunner-deep-sleep-standby-
time .
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1024#comment:56>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2277: Wireless does not work with the 2.6.29 kernel
---------------------+------------------------------------------------------
Reporter: arhuaco | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone: stable-kernel-2009.1
Component: unknown | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: sometimes
---------------------+------------------------------------------------------
Comment(by budfive):
I have a possible fix for the ifconfig down/up bug described above
(https://docs.openmoko.org/trac/ticket/2277#comment:14).
The driver does most of its initialization in ar6000_init(), which is
called
when the module is loaded. Most of this initialization is undone by
ar6000_close(), called at "ifconfig down". Noteably, ar6000_open() does
NOT
reinitialize the driver. Since this is the function called by "ifconfig
up",
the driver is hosed by "ifconfig down; ifconfig up".
A potential fix is to castrate ar6000_close() so that the driver can still
work even if ar6000_open() doesn't do much. The cleanup still needs to
happen when the module is removed. I'm about to attach a patch that does
this. With this patch, the driver works and the automatic network scripts
work.
One obvious potential downside with this is that since we're no longer
cleaning up at "ifconfig down", an inactive driver can still use power
needlessly. I did some tests, and while I do see this extra power usage,
it
looks like it's inconsequential:
{{{
*** ar6000_close castrated
| phone off doing nothing | 101mA |
| insmod ar6000.ko | 103mA |
| ifconfig eth0 up | 103mA |
| ifconfig eth0 down | 103mA |
| connect (ifconfig up, iwconfig, udhcpc, etc) | 105mA |
| ifconfig eth0 down | 105mA |
| rmmod | 100mA |
*** ar6000_close unmodified
| ifconfig eth0 up | 103mA |
| ifconfig eth0 down | 102mA |
| rmmod | 101mA |
| unbind | 96mA |
}}}
All readings were made by using the built-in coloumb counter, and each
number is good to about +- 2mA. It looks like the missing cleanup code in
the modified version costs us about 3mA or 3% of the total power usage. If
this is the case, I would argue we have a fix. It also looks like we
really
should unbind (echo "s3c2440-sdi" >
/sys/bus/platform/drivers/s3c2440-sdi/unbind) the driver when not in use,
since that's where the most of the power-savings lie. Do these numbers
seem
reasonable?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2277#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
