Re: [Qemu-devel] OSX build issues

2011-03-19 Thread Blue Swirl
On Tue, Mar 15, 2011 at 11:03 PM, Blue Swirl blauwir...@gmail.com wrote:
 On Mon, Mar 14, 2011 at 11:21 PM, François Revol re...@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.



Re: [Qemu-devel] OSX build issues

2011-03-17 Thread François Revol
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.




Re: [Qemu-devel] OSX build issues

2011-03-17 Thread Tristan Gingold

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.




Re: [Qemu-devel] OSX build issues

2011-03-17 Thread Juha.Riihimaki

On 17.03.11 13:09 , ext Tristan Gingold ging...@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




Re: [Qemu-devel] OSX build issues

2011-03-15 Thread Alexander Graf

On 14.03.2011, at 22:21, François Revol 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 ?
 
 * cpus.c:
 qemu_kvm_eat_signals refers to sigbus_reraise which is defined conditionally 
 on CONFIG_LINUX...
 And OSX doesn't have sigtimedwait...
 Any maintainer around who can fix it ?

Andreas is your man :).


Alex




Re: [Qemu-devel] OSX build issues

2011-03-15 Thread Stefan Hajnoczi
On Tue, Mar 15, 2011 at 6:41 AM, Alexander Graf ag...@suse.de wrote:

 On 14.03.2011, at 22:21, François Revol 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 ?

 * cpus.c:
 qemu_kvm_eat_signals refers to sigbus_reraise which is defined conditionally 
 on CONFIG_LINUX...
 And OSX doesn't have sigtimedwait...
 Any maintainer around who can fix it ?

 Andreas is your man :).

Daniel and Christian recently added a buildbot setup that periodically
builds qemu.git and checks that builds are successful.  OSX is
currently not covered but maybe you'd like to help here.

Here is the buildbot, if you're curious what it looks like:
http://buildbot.b1-systems.de/qemu/one_box_per_builder

If you have an OSX box available to run periodic builds you can help
by contributing it as a buildslave.  Check out this wiki page for
more info on contributing buildslaves:
http://wiki.qemu.org/ContinuousIntegration

Stefan



Re: [Qemu-devel] OSX build issues

2011-03-15 Thread Blue Swirl
On Mon, Mar 14, 2011 at 11:21 PM, François Revol re...@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.
From 8bc9b2c313bea3536ba258a16f211a8585c494f3 Mon Sep 17 00:00:00 2001
Message-Id: 8bc9b2c313bea3536ba258a16f211a8585c494f3.1300222948.git.blauwir...@gmail.com
From: Blue Swirl blauwir...@gmail.com
Date: Tue, 15 Mar 2011 20:48:52 +
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 re...@free.fr
Signed-off-by: Blue Swirl blauwir...@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) * 100);
-if (ts-tv_nsec = 10) {
-ts-tv_nsec -= 10;
-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



Re: [Qemu-devel] OSX build issues

2011-03-15 Thread François Revol

Le 15 mars 2011 à 22:03, Blue Swirl a écrit :

 On Mon, Mar 14, 2011 at 11:21 PM, François Revol re...@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.


[Qemu-devel] OSX build issues

2011-03-14 Thread François Revol
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 ?

* cpus.c:
qemu_kvm_eat_signals refers to sigbus_reraise which is defined conditionally on 
CONFIG_LINUX...
And OSX doesn't have sigtimedwait...
Any maintainer around who can fix it ?


François.