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 #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
2. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
3. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
4. Openmoko Bug #2137: stable-tracking lacks touchscreen jitter
reduction patch (Openmoko Public Trac)
5. Re: Openmoko Bug #1194: Touchscreen Jitter (Openmoko Public Trac)
6. Re: Openmoko Bug #2137: stable-tracking lacks touchscreen
jitter reduction patch (Openmoko Public Trac)
7. Re: Openmoko Bug #1194: Touchscreen Jitter (Openmoko Public Trac)
8. Re: Openmoko Bug #2088: [Testing] The settings app cannot be
started (Openmoko Public Trac)
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
Hm on the main project page
http://lse.sourceforge.net/kdump/
the last patch they have for Fedora is FC4, the link to the kernel side
git stuff is broken, the download dir
http://www.xmission.com/~ebiederm/files/kexec/
stops at support for 2.6.10-rc2...
I guess it means it got in and Fedora look after it, but it's fair to say
it looks a bit dead.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
stable-tracking branch has kexec support and it's enabled by default in
./arch/arm/configs/gta02-moredrivers-defconfig so I built the userland
package and tried
{{{
sudo kexec -l /boot/uImage2.bin --append="`cat /proc/cmdline`"
sudo kexec -e
}}}
but just got WSOD (first time I have ever seen WSOD btw!). lsusb does not
show the phone as usb device so the phone did not just boot without
display working. No leds are blinking or lit.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
Wow nice try... WSOD is probably just because of reset action on LCM or
Glamo and then nothing came and configured it, so it's not really related
to WSOD that is spoken about lately.
I guess it crashed early in new kernel or on leaving old one or whatever,
not much room to debug it without a debug board I would think.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2137: stable-tracking lacks touchscreen jitter reduction patch
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
I'm using self-compiled stable-tracking kernel and it seems the
touchscreen is again annoying to use. Most probably something similar to
http://git.openmoko.org/?p=kernel.git;a=commit;h=abe8f448547d1bd69ac2963e07e2657f27b79691
has not been ported to the stable-tracking kernel. It seems not to apply
as such to the current stable-tracking, but the mentioned patch really
helped a lot with the current stable kernel regarding touchscreen
usability.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2137>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1194: Touchscreen Jitter
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: openmoko-kernel
Type: defect | Status: in_testing
Priority: high | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------------------+---------------------------------------
Comment(by TimoJyrinki):
Tick's patch really helped a lot with the usability of the touchscreen.
Much less erronous "clicks"/selections.
However, I just created a ticket #2137 about the fact the functionality is
not there anymore with the stable-tracking kernel. The code has changed,
and something similar to tick's patch should be done there, too.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1194#comment:17>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2137: stable-tracking lacks touchscreen jitter reduction patch
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
Tick updated his patch and it is in stable-tracking for 7 hours... do a
git pull :-) If it's still broken post more detail.
http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=792484a3d2d24fff438a1844930431ad8c7d5611
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2137#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1194: Touchscreen Jitter
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: openmoko-kernel
Type: defect | Status: in_testing
Priority: high | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Resolution:
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------------------+---------------------------------------
Comment(by andy):
Tick updated his patch for stable-tracking and it is on there since
thismorning.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1194#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2088: [Testing] The settings app cannot be started
-------------------------+--------------------------------------------------
Reporter: dolfje | Owner: marek
Type: defect | Status: closed
Priority: normal | Milestone:
Component: Settings | Version:
Severity: normal | Resolution: fixed
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
-------------------------+--------------------------------------------------
Comment(by yarikoptic):
PS Doh -- I would love to reopen it but apparently I don't have 'the
permission'... imho that is silly... should I just file a new one then???
Today I hit the same issue here: I was running 'latest' FDOM and decided
to try my luck again -- added all 'testing' opkg sources and did opkg
upgrade... came to the point you know -- running exposure.py does nothing
-- exists after 1-2 seconds
the issue was that python-etk installed was
1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03
so it is epoch 1:
is that the one from old 'stable'?
in any case, testing has now
0.3.0+svnr36882-r0.01
But "opkg install", while 1:0.... is installed, fails to install even if I
say -force-downgrade. So I just did manually
wget http://downloads.openmoko.org/repository/testing/armv4t/python-
etk_0.3.0+svnr36882-r0.
01_armv4t.opk
opkg purge -force-depends python-etk
opkg install python-etk_0.3.0\+svnr36882-r0.01_armv4t.opk
now it starts fine...
I wonder if you should have used also epoch 1: for the correct upgrade
from old stable?
can't compare for sure since documented feature of opkg causes segfault:
/usr/lib/python2.5/site-packages/etk#opkg compare_versions 1 '<=' 2
Segmentation fault
or
> opkg compare_versions
1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03 '<='
0.3.0+svnr36882-r0.01 && echo yes
Segmentation fault
at least on debian it would be indeed the case:
{{{
>dpkg --compare-versions
'1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03' lt
'0.3.0+svnr36882-r0.01' && echo yes || echo no
no
}}}
and if you add epoch -- you are safe:
{{{
>dpkg --compare-versions
'1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03' lt
'1:0.3.0+svnr36882-r0.01' && echo yes || echo no
yes
}}}
So, imho, correct resolution would be to include epoch "1:" or even "2:"
into the version of python-etk
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2088#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
