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 #2056: /etc/resolv.conf is empty on first
boot (Openmoko Public Trac)
2. Re: Openmoko Bug #2012: 2008 updated and FDOM failure to
register to vodafone Australia (Openmoko Public Trac)
3. Re: Openmoko Bug #1587: can not receive SMS often
(Openmoko Public Trac)
4. Re: Openmoko Bug #1858: [E-illume] installer menu appear
instead of softmenu after cancel to save contacts from call
history (Openmoko Public Trac)
5. Re: Openmoko Bug #2056: /etc/resolv.conf is empty on first
boot (Openmoko Public Trac)
6. Re: Openmoko Bug #1024: gsm modem oscillating between
registrated / not-registrated (Openmoko Public Trac)
7. Re: Openmoko Bug #1024: gsm modem oscillating between
registrated / not-registrated (Openmoko Public Trac)
--- Begin Message ---
#2056: /etc/resolv.conf is empty on first boot
------------------------+---------------------------------------------------
Reporter: rwhitby | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by newkirk):
Sorry, I didn't understand you were speaking to the case where NO valid
network connection exists, but route and DNS via usb0 were still active.
I ran some tests with USB unplugged (Raster's latest image with FSO feed,
though I expect 2007.x and 2008.x would be very similar) and I get these
times with 'opkg update' (with two 'dead' feeds where I've not removed
unused 'my-distribution.org' entries):
160 secs - usb0 up, dns pointing out usb0
40 secs - usb0 up, /etc/resolv.conf empty
5 secs - usb0 down with or without /etc/resolv.conf populated
So generally speaking, emptying resolv.conf leads to 25% the wait,
bringing usb0 down leads to 3%. (oh, and of that 5 secs about 4 is opkg
setting up before it tries to communicate - same for all scenarios - it
fails each connection attempt faster than it can print the status to the
screen with no route available)
The flipside is that if the default is to have nothing in /etc/resolv.conf
when only usb0 is up, then there will be a stream of complaints and bug
reports that USB networking is broken, etc. We can't require manual
insertion of DNS each time a user plugs into a host computer through which
they wish to route.
So the 'real' solution as I see it is to have resolv.conf populated
'correctly' for usb0, but bring usb0 down when no usb cable is present.
(though I don't see a simple way to achieve that automatically ATM, only
manually with a widget or icon) Without that, I don't see a way to "make
both sides happy"... :(
Another possibility, addressing the specific opkg/assassin case, is to add
a test to opkg_download() that tries to ping the default gateway, and dies
if it's unreachable. Which seems sensible to me regardless. ;)
j
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2056#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2012: 2008 updated and FDOM failure to register to vodafone Australia
-----------------------------+----------------------------------------------
Reporter: billk | Owner: zecke
Type: defect | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: GTA02v5
Severity: major | Resolution:
Keywords: GSM Register | Blockedby:
Reproducible: always | Blocking:
-----------------------------+----------------------------------------------
Comment(by BillK):
list_installed attached.
The failure to register and SMS failure seem related. After fighting this
registration thing since I first got the FR, with only 2007.2 being in any
way acceptable (Ive tried ASU/2008.8/2008.9/FDOM/FSO) - it seems that
there are timing issues involved (perhaps SIM/GSM provider triggered) that
are manifesting themselves in number of ways.
1. Failure to register - always happens if the kernel error is in the log
2. SMS seems to be problematic and often (not always) problems co-incide
with the same error
It *could* be two separate issues, or part of the same one so its better
to have all the information in ways the FR is misbehaving.
Oddly, actual calls seem ok.
BillK
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2012#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1587: can not receive SMS often
-----------------------------------------+----------------------------------
Reporter: regina_kim | Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: highest | Milestone: Om2008.10
Component: Qtopia | Version:
Severity: blocker | Resolution: fixed
Keywords: must have, keep watching | Blockedby:
Reproducible: | Blocking:
-----------------------------------------+----------------------------------
Changes (by regina_kim):
* status: assigned => closed
* resolution: => fixed
Comment:
test with 200809039(testing) does not happen. always can receive SMS
immediately.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1587#comment:22>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1858: [E-illume] installer menu appear instead of softmenu after cancel to save
contacts from call history
---------------------------+------------------------------------------------
Reporter: regina_kim | Owner:
Type: defect | Status: in_testing
Priority: normal | Milestone: Om2008.10
Component: E - Illume | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: sometimes | Blocking:
---------------------------+------------------------------------------------
Comment(by regina_kim):
ok.i will keep watching this until next upgrade than will close.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1858#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2056: /etc/resolv.conf is empty on first boot
------------------------+---------------------------------------------------
Reporter: rwhitby | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by marek):
Replying to [comment:5 newkirk]:
> So the 'real' solution as I see it is to have resolv.conf populated
'correctly' for usb0, but bring usb0 down when no usb cable is present.
(though I don't see a simple way to achieve that automatically ATM, only
manually with a widget or icon) Without that, I don't see a way to "make
both sides happy"... :(
What about using allow-hotplug in /etc/network/interfaces and let udev
bring the interface up once it is plugged.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2056#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1024: gsm modem oscillating between registrated / not-registrated
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: sean_chiang
Type: defect | Status: assigned
Priority: high | Milestone:
Component: gsmd | Version: unspecified
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by [EMAIL PROTECTED]):
Replying to [comment:46 erin_yueh]:
> patch is committed to qtopia image
>
http://git.openmoko.org/?p=qtopia.git;a=commitdiff;h=115a733771d257565c0ec03b485d3ba63c2cec61;hp=22c3c1f28631c1091a83fb72bf0a9c9f4b008246
> thanks a lot!
I took a quick look at the commit -- please apply the
"brc_qtopia_quickfix.patch" as well.
The problem is that I updated the Qt Extended (4.4.1) patch to include the
%SLEEP fix, but I overlooked updating the patch for Qtopia 4.3 on the
website. The code as committed only detects and logs when the oscillation
begins. The extra patch adds the logic to disable "deep sleep" if we
detect 3 "bounces" in succession.
Note that there are TODO items in the code; this needs to be revisited
once we understand more about the problem. Areas that could use
improvement would be adding logic to attempt to re-enable deep sleep at
various times -- right now, a restart is required to do this. If we can
identify some events that would be worth trying to re-enter deep sleep
without disruption to the user, that would be good. Also, we may need to
do this conditionally - I know that Moko7 firmware works well with this
parameter but there is a report that Moko8 will not wake from GSM activity
if the %SLEEP is issued. Perhaps Openmoko can help out by publishing a
change log for the firmware releases, or by testing these changes on the
various GSM firmwares for the community.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1024#comment:47>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1024: gsm modem oscillating between registrated / not-registrated
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: sean_chiang
Type: defect | Status: assigned
Priority: high | Milestone:
Component: gsmd | Version: unspecified
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by erin_yueh):
> Note that there are TODO items in the code; this needs to be revisited
once we understand more about the problem. Areas that could use
improvement would be adding logic to attempt to re-enable deep sleep at
various times -- right now, a restart is required to do this. If we can
identify some events that would be worth trying to re-enter deep sleep
without disruption to the user, that would be good. Also, we may need to
do this conditionally - I know that Moko7 firmware works well with this
parameter but there is a report that Moko8 will not wake from GSM activity
if the %SLEEP is issued. Perhaps Openmoko can help out by publishing a
change log for the firmware releases, or by testing these changes on the
various GSM firmwares for the community.
Thank you! I will apply this patch soon. But for me, i can hardly verify
this problem, coz i cannot reproduce it in Taiwan. I would ask Mickey's
help for the GSM network provider.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1024#comment:48>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
