diff mbox

OSX build issues

Message ID AANLkTik4HC1LGkd8f+abS4WBFL==hax+oY-miwqgFZUC@mail.gmail.com
State New
Headers show

Commit Message

Blue Swirl March 15, 2011, 9:03 p.m. UTC
On Mon, Mar 14, 2011 at 11:21 PM, François Revol <revol@free.fr> wrote:
> The OSX build has been broken for some time now...
>
> * qemu-thread-posix.c:
> both qemu_mutex_timedlock and qemu_cond_timedwait make use of clock_gettime() and CLOCK_REALTIME, which OSX doesn't have.
> It seems like both functions are nowhere found. Can they be removed then ?

This patch should fix the problem.

Comments

François Revol March 15, 2011, 9:26 p.m. UTC | #1
Le 15 mars 2011 à 22:03, Blue Swirl a écrit :

> On Mon, Mar 14, 2011 at 11:21 PM, François Revol <revol@free.fr> wrote:
>> The OSX build has been broken for some time now...
>> 
>> * qemu-thread-posix.c:
>> both qemu_mutex_timedlock and qemu_cond_timedwait make use of clock_gettime() and CLOCK_REALTIME, which OSX doesn't have.
>> It seems like both functions are nowhere found. Can they be removed then ?
> 
> This patch should fix the problem.
> <0001-qemu-thread-delete-unused-functions.patch>

It should fix the build issue.
But QEMU is unreliable on OSX even when it gets built.
I tried to bisect but lost some time trying to find a revision that actually builds. I thought I updated more this month...

55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
Then there are some thread-related changes which I suspect have side effects.
The guest starts but stales for a while several times, at least with Haiku.
And the screen (SDL, couldn't try with vnc since the OSX client violates the RFB specs and QEMU doesn't like it) stays white for some time, then is only updated a few times.
Then the IDE driver fails to get DMA working, disables the DMA and eventually goes a bit further.

François.
François Revol March 17, 2011, 10:28 a.m. UTC | #2
Hi,

Le 16 mars 2011 à 08:57, Tristan Gingold a écrit :

>> It should fix the build issue.
>> But QEMU is unreliable on OSX even when it gets built.
>> I tried to bisect but lost some time trying to find a revision that actually builds. I thought I updated more this month...
>> 
>> 55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
> 
> J'utilise ce hack pour eviter ce probleme.

Indeed this hack works (quite a hack for someone working on ada :p)...

> diff --git a/cpus.c b/cpus.c
> index 5d14468..e976452 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -548,6 +548,7 @@ static void qemu_tcg_init_cpu_signals(void)
> #ifndef CONFIG_IOTHREAD
> int qemu_init_main_loop(void)
> {
> +#if 0
>     int ret;
> 
>     ret = qemu_signal_init();
> @@ -558,6 +559,7 @@ int qemu_init_main_loop(void)
>     qemu_init_sigbus();
> 
>     return qemu_event_init();
> +#endif
> }
> 
> void qemu_main_loop_start(void)

(Added a return 0 for the sake of it).

From the content of the functions called it's either one of the added fds which cause problem on select() (but why ?), or likely some signal masks which interfere with some internal thread in the process.

I sampled the process and took some screenshots without and with the #if 0 hack:
http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png
Things work but oddly what is supposed to be an internal dispatcher thread ends up executing qemu code. The main thread includes lots of calls from arbitrary addresses indicating it receives some signals.

http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png
Things stale, and there are 2 more threads that wait, and the main thread seems quite stuck in select().

François.
Tristan Gingold March 17, 2011, 11:09 a.m. UTC | #3
On Mar 17, 2011, at 11:28 AM, François Revol wrote:

> Hi,
> 
> Le 16 mars 2011 à 08:57, Tristan Gingold a écrit :
> 
>>> It should fix the build issue.
>>> But QEMU is unreliable on OSX even when it gets built.
>>> I tried to bisect but lost some time trying to find a revision that actually builds. I thought I updated more this month...
>>> 
>>> 55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
>> 
>> J'utilise ce hack pour eviter ce probleme.
> 
> Indeed this hack works (quite a hack for someone working on ada :p)...

That's why I send it to you via a private mail ;-)

Note that I also get failures on Linux iirc.

> From the content of the functions called it's either one of the added fds which cause problem on select() (but why ?), or likely some signal masks which interfere with some internal thread in the process.
> 
> I sampled the process and took some screenshots without and with the #if 0 hack:
> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png
> Things work but oddly what is supposed to be an internal dispatcher thread ends up executing qemu code. The main thread includes lots of calls from arbitrary addresses indicating it receives some signals.
> 
> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png
> Things stale, and there are 2 more threads that wait, and the main thread seems quite stuck in select().

Yes, I have to investigate that...

Tristan.
Juha.Riihimaki@nokia.com March 17, 2011, 11:30 a.m. UTC | #4
On 17.03.11 13:09 , "ext Tristan Gingold" <gingold@adacore.com> wrote:

>On Mar 17, 2011, at 11:28 AM, François Revol wrote:
>
>>From the content of the functions called it's either one of the added
>>fds which cause problem on select() (but why ?), or likely some signal
>>masks which interfere with some internal thread in the process.
>> 
>> I sampled the process and took some screenshots without and with the
>>#if 0 hack:
>> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png
>> Things work but oddly what is supposed to be an internal dispatcher
>>thread ends up executing qemu code. The main thread includes lots of
>>calls from arbitrary addresses indicating it receives some signals.
>> 
>> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png
>> Things stale, and there are 2 more threads that wait, and the main
>>thread seems quite stuck in select().
>
>Yes, I have to investigate that...

From what I've found out so far is that the sigwait_compat() function in
compatfd.c will block all signals with sigprocmask() call and then wait
for a single signal in sigwaitinfo() (forgot what it is). Sounds a bit odd
to me but perhaps there's a reason for that? I tried changing the
sigprocmask() call so that it only blocks the same signals that it will
later wait for and things start rolling again.


Regards,
Juha
Blue Swirl March 19, 2011, 8:39 a.m. UTC | #5
On Tue, Mar 15, 2011 at 11:03 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Mon, Mar 14, 2011 at 11:21 PM, François Revol <revol@free.fr> wrote:
>> The OSX build has been broken for some time now...
>>
>> * qemu-thread-posix.c:
>> both qemu_mutex_timedlock and qemu_cond_timedwait make use of clock_gettime() and CLOCK_REALTIME, which OSX doesn't have.
>> It seems like both functions are nowhere found. Can they be removed then ?
>
> This patch should fix the problem.

I applied the patch.
diff mbox

Patch

From 8bc9b2c313bea3536ba258a16f211a8585c494f3 Mon Sep 17 00:00:00 2001
Message-Id: <8bc9b2c313bea3536ba258a16f211a8585c494f3.1300222948.git.blauwirbel@gmail.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Tue, 15 Mar 2011 20:48:52 +0000
Subject: [PATCH] qemu-thread: delete unused functions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

qemu_mutex_timedlock() and qemu_cond_timedwait() are no longer used.

Remove them and their helper timespec_add_ms().

Reported-by: François Revol <revol@free.fr>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
 qemu-thread-posix.c |   38 --------------------------------------
 qemu-thread.h       |    2 --
 2 files changed, 0 insertions(+), 40 deletions(-)

diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index 87c1a9f..2bd02ef 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -61,30 +61,6 @@  int qemu_mutex_trylock(QemuMutex *mutex)
     return pthread_mutex_trylock(&mutex->lock);
 }
 
-static void timespec_add_ms(struct timespec *ts, uint64_t msecs)
-{
-    ts->tv_sec = ts->tv_sec + (long)(msecs / 1000);
-    ts->tv_nsec = (ts->tv_nsec + ((long)msecs % 1000) * 1000000);
-    if (ts->tv_nsec >= 1000000000) {
-        ts->tv_nsec -= 1000000000;
-        ts->tv_sec++;
-    }
-}
-
-int qemu_mutex_timedlock(QemuMutex *mutex, uint64_t msecs)
-{
-    int err;
-    struct timespec ts;
-
-    clock_gettime(CLOCK_REALTIME, &ts);
-    timespec_add_ms(&ts, msecs);
-
-    err = pthread_mutex_timedlock(&mutex->lock, &ts);
-    if (err && err != ETIMEDOUT)
-        error_exit(err, __func__);
-    return err;
-}
-
 void qemu_mutex_unlock(QemuMutex *mutex)
 {
     int err;
@@ -139,20 +115,6 @@  void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex)
         error_exit(err, __func__);
 }
 
-int qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex, uint64_t msecs)
-{
-    struct timespec ts;
-    int err;
-
-    clock_gettime(CLOCK_REALTIME, &ts);
-    timespec_add_ms(&ts, msecs);
-
-    err = pthread_cond_timedwait(&cond->cond, &mutex->lock, &ts);
-    if (err && err != ETIMEDOUT)
-        error_exit(err, __func__);
-    return err;
-}
-
 void qemu_thread_create(QemuThread *thread,
                        void *(*start_routine)(void*),
                        void *arg)
diff --git a/qemu-thread.h b/qemu-thread.h
index acdb6b2..edc7ab6 100644
--- a/qemu-thread.h
+++ b/qemu-thread.h
@@ -15,7 +15,6 @@  void qemu_mutex_init(QemuMutex *mutex);
 void qemu_mutex_destroy(QemuMutex *mutex);
 void qemu_mutex_lock(QemuMutex *mutex);
 int qemu_mutex_trylock(QemuMutex *mutex);
-int qemu_mutex_timedlock(QemuMutex *mutex, uint64_t msecs);
 void qemu_mutex_unlock(QemuMutex *mutex);
 
 void qemu_cond_init(QemuCond *cond);
@@ -29,7 +28,6 @@  void qemu_cond_destroy(QemuCond *cond);
 void qemu_cond_signal(QemuCond *cond);
 void qemu_cond_broadcast(QemuCond *cond);
 void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex);
-int qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex, uint64_t msecs);
 
 void qemu_thread_create(QemuThread *thread,
                        void *(*start_routine)(void*),
-- 
1.7.2.3