Re: QWSLock errors
Radek Polak pson...@seznam.cz writes:
On Thursday, November 08, 2012 09:12:40 AM Neil Jerram wrote:
With current QtMoko git I'm seeing a lot of QWSLock errors in my log,
[...]
To me it looked that the semaphore was closed by the other process or thread.
The logging and some other stuff was added there in Qt 4.8.
I believe I've understood and fixed this - please see the attached
patch. I've been running with this change for a week and a bit now,
with no apparent bad consequences, so I guess it's OK to go into the
main repository.
Regards,
Neil
From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.homelinux.net
Date: Thu, 8 Nov 2012 08:18:32 +
Subject: [PATCH] Fix QWSLock invalid argument logs
There was no known actual problem associated with these logs, but they
were spamming the log, so I thought it worth trying to understand and
fix them.
The confusion is that there are two different ways of creating QWSLock
objects. QWSLock() creates an object that creates a new set of
semaphores, whereas QWSLock(id) creates an object that aliases the
existing set of semaphores with ID id. What seems to happen is that
each application creates a semaphore set scoped to that
application (QWSDisplay::Data::clientLock in qapplication_qws.cpp),
then this semaphore set is passed by complex means to
places (QWSClientPrivate and QWSMemorySurface) that use the semaphores
for a short period and then delete their QWSLock objects.
The problem was that the QWSLock destructor always destroyed the
semaphore set, even when that QWSLock hadn't create the semaphores
itself, hence making the semaphores invalid for other QWSLock objects
still referencing the same set.
Clearly a QWSLock object shouldn't destroy the semaphore set if it
didn't create it itself, and that is confirmed by the fact that one of
the implementations inside QWSLock already implements this logic, with
the 'owned' flag. The fix is to implement this for the #ifndef
QT_POSIX_IPC case - which is what is used in QtMoko - just as is
already implemented for the #ifdef QT_POSIX_IPC case.
---
src/gui/embedded/qwindowsystem_qws.cpp |3 +++
src/gui/embedded/qwslock.cpp| 17 +
src/gui/embedded/qwslock_p.h|2 +-
src/gui/kernel/qapplication_qws.cpp |2 ++
src/gui/painting/qwindowsurface_qws.cpp |2 ++
5 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/src/gui/embedded/qwindowsystem_qws.cpp b/src/gui/embedded/qwindowsystem_qws.cpp
index a1c613d..1ed8b6d 100644
--- a/src/gui/embedded/qwindowsystem_qws.cpp
+++ b/src/gui/embedded/qwindowsystem_qws.cpp
@@ -680,6 +680,7 @@ QWSClientPrivate::QWSClientPrivate()
QWSClientPrivate::~QWSClientPrivate()
{
#ifndef QT_NO_QWS_MULTIPROCESS
+//qDebug(QWSClientPrivate::~QWSClientPrivate());
delete clientLock;
#endif
}
@@ -689,7 +690,9 @@ void QWSClientPrivate::setLockId(int id)
#ifdef QT_NO_QWS_MULTIPROCESS
Q_UNUSED(id);
#else
+//qDebug(QWSClientPrivate::setLockId(%d), id);
clientLock = new QWSLock(id);
+//qDebug(= %p, clientLock);
#endif
}
diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp
index 9914a24..1055785 100644
--- a/src/gui/embedded/qwslock.cpp
+++ b/src/gui/embedded/qwslock.cpp
@@ -83,9 +83,13 @@ QWSLock::QWSLock(int id) : semId(id)
QWSSignalHandler::instance()-addWSLock(this);
#endif
+owned = false;
+
#ifndef QT_POSIX_IPC
if (semId == -1) {
semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666);
+owned = true;
+ //qDebug(QWSLock::QWSLock(): %p, %d, this, (int)semId);
if (semId == -1) {
perror(QWSLock::QWSLock);
qFatal(Unable to create semaphore);
@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id)
}
#else
sems[0] = sems[1] = sems[2] = SEM_FAILED;
-owned = false;
if (semId == -1) {
// ### generate really unique IDs
@@ -134,9 +137,12 @@ QWSLock::~QWSLock()
if (semId != -1) {
#ifndef QT_POSIX_IPC
-qt_semun semval;
-semval.val = 0;
-semctl(semId, 0, IPC_RMID, semval);
+ if (owned) {
+ qt_semun semval;
+ semval.val = 0;
+ semctl(semId, 0, IPC_RMID, semval);
+ }
+ //qDebug(QWSLock::~QWSLock(): %p, %d, this, (int)semId);
semId = -1;
#else
// emulate the SEM_UNDO behavior for the BackingStore lock
@@ -170,8 +176,10 @@ bool QWSLock::up(unsigned short semNum)
if (semNum == BackingStore)
sops.sem_flg |= SEM_UNDO;
+//qDebug(QWSLock::up(): %p, semop(%d, %d), this, (int)semId, (int)semNum);
EINTR_LOOP(ret, semop(semId, sops, 1));
#else
+//qDebug(QWSLock::up(): %p, sem_post(%d), this, (int)(sems[semNum]));
ret = sem_post(sems[semNum]);
#endif
if (ret == -1) {
@@ -195,6 +203,7 @@ bool QWSLock::down(unsigned short semNum, int)
if (semNum == BackingStore)
sops.sem_flg |= SEM_UNDO;
+//qDebug(QWSLock::down(): %p, semop(%d, %d),
QtMoko backup/restore
I wonder if anyone is already thinking about or working on backup and restore for QtMoko when upgrading - i.e. to maintain all your settings and data across an upgrade? My thoughts so far on this: - Most non-system data lives in a separate partition, /media/card, and doesn't need handling because an upgrade won't touch that partition. - For the same reason, /media/card is a good place for backing up anything that does need handling. - Stuff that does need backup and restore is under /home/root: settings, email/SMS messages, spectemu ROMs, web browser stuff, and so on. Unfortunately this is a mixture of genuine user data and application-generated runtime state, and I think it would be better to let the new distribution regenerate the latter. So possibly that means that we can't just save and restore the whole of /home/root. But maybe the algorithm can be save and restore the whole of /home/root except for a manageably small number of exceptions. - Maybe also backup and restore /etc/ssh/*key*, to avoid having to delete the old key on SSH clients? - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. Thoughts? Does anyone already have such scripts? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
On Saturday, November 17, 2012 02:46:05 PM Neil Jerram wrote: I wonder if anyone is already thinking about or working on backup and restore for QtMoko when upgrading - i.e. to maintain all your settings and data across an upgrade? Yes i did :) My thoughts so far on this: - Most non-system data lives in a separate partition, /media/card, and doesn't need handling because an upgrade won't touch that partition. - For the same reason, /media/card is a good place for backing up anything that does need handling. Yes, i aggree, /media/card is good location for backups. - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. I would personally very like export of my contacts in vcf format to /media/card/Documents. It shouldnt be hard since qtmoko can send contacts via email attachement. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QWSLock errors
On Saturday, November 17, 2012 01:38:42 PM Neil Jerram wrote: Radek Polak pson...@seznam.cz writes: On Thursday, November 08, 2012 09:12:40 AM Neil Jerram wrote: With current QtMoko git I'm seeing a lot of QWSLock errors in my log, [...] To me it looked that the semaphore was closed by the other process or thread. The logging and some other stuff was added there in Qt 4.8. I believe I've understood and fixed this - please see the attached patch. I've been running with this change for a week and a bit now, with no apparent bad consequences, so I guess it's OK to go into the main repository. Hi Neil, it's commited now. I havent tested it yet, will do it later.. Thanks a lot! Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Hi Neil - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. Thoughts? Does anyone already have such scripts? backup2l? The best documentation is here:- http://symbiosis.bytemark.co.uk/squeeze/docs/symbiosis.html#ch-backup-reference nb symbiosis is a debian based easy hosting system that includes backup2l; since backup2l is basically a shell script it doesn't care what sort of linux it's running on. There are debian paclages. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
dmatthews.org m...@dmatthews.org writes: Hi Neil - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. Thoughts? Does anyone already have such scripts? backup2l? The best documentation is here:- http://symbiosis.bytemark.co.uk/squeeze/docs/symbiosis.html#ch-backup-reference nb symbiosis is a debian based easy hosting system that includes backup2l; since backup2l is basically a shell script it doesn't care what sort of linux it's running on. There are debian paclages. backup2l looks pretty nice; thanks for the suggestion. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko v49
Hi, QtMoko v49 for GTA04 is now available [1]. There have been really many changes this time so be careful :) Complete changelog is here: * using gstreamer as media engine instead of cruxus * using pulseaudio for sounds * using pasuspender to pause media during calls and state switching * fixed DTMF tones on gta04 (Neil Jerram) * fixed USSD message box size (Stefan Rupp) * A3 earpiece state uses HiFi priority (Neil Jerram) * modem is now in 3g mode since modem usb disconnect fix is in kernel * modem dissapearing from usb in now logged to /modem_reenumerate.log * lot of work on debian package (Gilles Filippini) * fixed pkg-config handling (Gilles Filippini) * ogg metadata plugin (Neil Jerram) * fixed empty email content with windows charset (Neil Jerram) * fixed some email content displaying (Neil Jerram) * fixes in QtMaze accelerometer (Neil Jerram) * improvements in svg layouts (adrien) * arora and qx use new accelerometer library (Neil Jerram) * arora provides web access e.g. for web links in email (Neil Jerram) * mokofaen - space for 10 and more satellites (Neil Jerram) * qmplayer scans for webm and mkv now too * ssh access in allowed only on usb now (Paul Ferster, lindi) * updated build instructions - cross building is now done in chroot * using now glib even loop * parallel make option in configure for -build-qt option * pc build * kernel changes: * external gps antenna should work now (Christoph Mair) * avoid errors by stoping omap DMA channels before unlinking (Neil Brown) * CONFIG_TIDSPBRIDGE=m so that we can use dsp * jffs2 as module so that we can mount hw validation in nand * fixed modem disapearing from usb (Dr. H. Nikolaus Schaller) The most important thing is that ringtones and sound in calls should now thanks to gstreamer and pulseaudio work. It basically works now like this: All sound goes to pulseaudio. When there is a call the state switching and sw- voice routing is done via pasuspender. Pasuspender pauses all other audio streams and closes soundcard so that alsactl can do state switching and gsm- voice-routing can route voice. Please note that pulseaudio is in the image completely unconfigured. It is launched by /opt/qtmoko/pulse.sh scripts. I have noticed occasional clicking - this happens when pulseaudio ends and is restarted. I havent discovered yet why it's ending - maybe allow-exit = no option in /etc/pulse/daemon.conf will help... You can also try media player - it can now play videos. Other changes are quite self explaining. As for future - in master we have now nearly working QtMoko on top of Qt 4.8.3. There is just one bug that has to be fixed and it looks that QtMoko now also runs decently on debian wheezy/armhf so this could be our target for v50. We will also have support for html5 video when we switch to qt 4.8 - i have tested youtube and dailymotion and they work (although with glitches)... Another thing that would be nice to get fixed is the tarball size. It went from 98MB to 160MB due to gstreamer dependecies. I wonder how this could be solved. I dont think we need all the plugins that make it so big, but debian has all in one big package... If you are wondering about Freerunner - i am going to skip this release, there's not much useful for Freeruner now. I will do release for Freerunner with Qt 4.8 later. Thanks everybody who helped with this release - special thanks to Neil Jerram and Gilles! Enjoy the release Radek [1] http://sourceforge.net/projects/qtmoko/files/GTA04/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v49
hi, does it still require the first FAT partition or does it comply to the new scheme? thanks Hi, QtMoko v49 for GTA04 is now available [1]. There have been really many changes this time so be careful :) Complete changelog is here: * using gstreamer as media engine instead of cruxus * using pulseaudio for sounds * using pasuspender to pause media during calls and state switching * fixed DTMF tones on gta04 (Neil Jerram) * fixed USSD message box size (Stefan Rupp) * A3 earpiece state uses HiFi priority (Neil Jerram) * modem is now in 3g mode since modem usb disconnect fix is in kernel * modem dissapearing from usb in now logged to /modem_reenumerate.log * lot of work on debian package (Gilles Filippini) * fixed pkg-config handling (Gilles Filippini) * ogg metadata plugin (Neil Jerram) * fixed empty email content with windows charset (Neil Jerram) * fixed some email content displaying (Neil Jerram) * fixes in QtMaze accelerometer (Neil Jerram) * improvements in svg layouts (adrien) * arora and qx use new accelerometer library (Neil Jerram) * arora provides web access e.g. for web links in email (Neil Jerram) * mokofaen - space for 10 and more satellites (Neil Jerram) * qmplayer scans for webm and mkv now too * ssh access in allowed only on usb now (Paul Ferster, lindi) * updated build instructions - cross building is now done in chroot * using now glib even loop * parallel make option in configure for -build-qt option * pc build * kernel changes: * external gps antenna should work now (Christoph Mair) * avoid errors by stoping omap DMA channels before unlinking (Neil Brown) * CONFIG_TIDSPBRIDGE=m so that we can use dsp * jffs2 as module so that we can mount hw validation in nand * fixed modem disapearing from usb (Dr. H. Nikolaus Schaller) The most important thing is that ringtones and sound in calls should now thanks to gstreamer and pulseaudio work. It basically works now like this: All sound goes to pulseaudio. When there is a call the state switching and sw- voice routing is done via pasuspender. Pasuspender pauses all other audio streams and closes soundcard so that alsactl can do state switching and gsm- voice-routing can route voice. Please note that pulseaudio is in the image completely unconfigured. It is launched by /opt/qtmoko/pulse.sh scripts. I have noticed occasional clicking - this happens when pulseaudio ends and is restarted. I havent discovered yet why it's ending - maybe allow-exit = no option in /etc/pulse/daemon.conf will help... You can also try media player - it can now play videos. Other changes are quite self explaining. As for future - in master we have now nearly working QtMoko on top of Qt 4.8.3. There is just one bug that has to be fixed and it looks that QtMoko now also runs decently on debian wheezy/armhf so this could be our target for v50. We will also have support for html5 video when we switch to qt 4.8 - i have tested youtube and dailymotion and they work (although with glitches)... Another thing that would be nice to get fixed is the tarball size. It went from 98MB to 160MB due to gstreamer dependecies. I wonder how this could be solved. I dont think we need all the plugins that make it so big, but debian has all in one big package... If you are wondering about Freerunner - i am going to skip this release, there's not much useful for Freeruner now. I will do release for Freerunner with Qt 4.8 later. Thanks everybody who helped with this release - special thanks to Neil Jerram and Gilles! Enjoy the release Radek [1] http://sourceforge.net/projects/qtmoko/files/GTA04/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Schon vor dem Come-Back von Modern Talking wusste ich: Dieter Bohlen ist der Preis der Freiheit. Heinz Rudolf Kunze ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel panic on Freerunner QtMoko boot
On 11/16/12, Harry Prevor habsti...@gmail.com wrote: Thanks ahead of time for responses. Well, I've decided to transcribe the entire picture for these five reasons: 1. I was somewhat bored; 2. The phone is useless without an operating system anyways; 3. I figure that posting information in text form may bring that one UNIX old-timer that reads all their mail in Pine one step closer to helping me; 4. I'd like to bump up my thread but posting something along the lines of BUMP! would be a bit too cliché; 5. I am absolutely desperate for any help or tips whatsoever anyone can provide, even if they are wrong. The transcribed text follows: [3.99] mmc0: queuing unknown CIS tuple 0x1b (8 bytes) [4.01] s3c-sdi s3c2440-sdi: running at 25000kHz (requested: 25000kHz). [4.02] s3c-sdi s3c2440-sdi: running at 25000kHz (requested: 25000kHz). [4.03] mmc0: queuing unknown CIS tuple 0x80 (1 bytes) [4.04] mmc0: queuing unknown CIS tuple 0x81 (1 bytes) [4.05] mmc0: queuing unknown CIS tuple 0x82 (1 bytes) [4.06] mmc0: new SDIO card at address 0001 [4.26] No device for DAI s3c24xx-i2s [4.27] No device for DAI Bluetooth [4.29] asoc: WM8753 HiFi - s3c24xx-i2s mapping ok [4.30] asoc: WM8753 Voice - Bluetooth mapping ok [4.71] input: neo1973gta02 Headset Jack as /devices/platform/soc-audio/sound/card0/input5 [4.74] ALSA device list: [4.75] #0: neo1973gta02 (WM8753) [4.76] TCP westwood registered [4.77] NET: Registered protocol family 17 [4.78] Bridge firewalling registered [4.86] BMI Get Target Info: Exit (ver: 0x2059 type: 0x1) [4.93] regulator_init_complete: incomplete constraints, leaving memldo on [4.96] regulator_init_complete: incomplete constraints, leaving hcldo on [4.98] AR6000 Reg Code = 0x4060 [5.11] pcf50633-rtc pcf50633-rtc.0: setting system clock to 2000-01-01 05:38:23 UTC (946705103) [5.12] UBIFS error (pid 1): ubifs_get_sb: cannot open ubi0:om-gta02-rootfs, error -19 [5.13] VFS: Cannot open root device ubi0:om-gta02-rootfs or unknown-block(0,0) [5.14] Please append a correct root= boot option; here are the available partitions: [5.15] 1f002048 mtdblock0 (driver?) [5.16] 1f01 256 mtdblock1 (driver?) [5.15] 1f02 256 mtdblock2 (driver?) [5.15] 1f038192 mtdblock3 (driver?) [5.15] 1f04 640 mtdblock4 (driver?) [5.15] 1f05 256 mtdblock5 (driver?) [5.15] 1f06 252544 mtdblock6 (driver?) [5.22] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [5.23] Backtrace: [5.24] [c002b66c] (dump_backtrace+0x0/0x10c) from [c032b994] (dump_stack+0x18/0x1c) [5.25] r7:8001 r6:c0024a08 r5:c7ca r4:c0423a30 [5.27] [c032b97c] (dump_stack+0x0/0x1c) from [x032b9e4] (panic+0x4c/0xc8) [5.28] [c032b998] (panic+0x0/0xc8) from [c0008f20] (mount_block_root+0x1f8/0x2bc) [5.29] r3:c7c72ccc r2: r1:c7c19f78 r0:c03aa02c [5.30] [c0008d28] (mount_block_root+0x0/0x2bc) from [c00090e4] (prepare_namespace+0x94/0x1d0) [5.31] [c0009050] (prepare_namespace+0x0/0x1d0) from [c00084dc] (kernel_init+0x10c/0x148) [5.32] r5:c0023d74 r4:c0423080 [5.33] [c00083d0] (kernel_init+0x0/0x148) from [c00403a0] (do_exit+0x0/0x654) [5.34] r5: r4: Looking forward to any responses. -- Harry Prevor ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel panic on Freerunner QtMoko boot
I'm afraid I can't help much, but... Harry Prevor habsti...@gmail.com writes: [5.12] UBIFS error (pid 1): ubifs_get_sb: cannot open ubi0:om-gta02-rootfs, error -19 This is obviously the key problem. Is ubi0:om-gta02-rootfs a valid specification of the device/partition where the rootfs is? Googling the error message leads to http://lists.openmoko.org/pipermail/community/2011-April/064811.html, which (in my interpretation): - suggests that ubifs may not yet be completely reliable - points to another thread that might have clues for you. Of course, in order to have a working phone, I guess you could install on SD instead. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
