Hi everyone,
I *really* need a stand-alone testcase for the GCC __sync_* builtins
or specifically, the cmpxchg syscall. A threded one.
I’ve got ARAnyM VMs hanging at 100% CPU, no network response any more,
during builds of first qt4-x11, and now cwidget. (Although I don’t know
if the former uses those GCC primitives, if available, in their generic
atomics code, or the latter uses atomics at all, this is a first guess.)
Since the VMs hang so that I must kill them, no debugging is possible.
The last lines of the cwidget build log (although eatmydata and the
ext4 journal replay might have cut off more) were:
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -Wall -Werror -I.. -I../src -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include -MT test_threads.o -MD -MP -MF ".deps/test_threads.Tpo" -c -o test_threads.o test_threads.cc; \
then mv -f ".deps/test_threads.Tpo" ".deps/test_threads.Po"; else rm -f ".deps/test_threads.Tpo"; exit 1; fi
/bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include -Wl,-z,relro -o test main.o test_eassert.o test_ssprintf.o test_threads.o ../src/cwidget/libcwidget.la -lcppunit -lncursesw -lpthread -lsigc-2.0
libtool: link: g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include -Wl,-z -Wl,relro -o .libs/test main.o test_eassert.o test_ssprintf.o test_threads.o ../src/cwidget/.libs/libcwidget.so /usr/lib/libcppunit.so -lncursesw -lpthread /usr/lib/m68k-linux-gnu/libsigc-2.0.so
make[3]: Leaving directory `/tmp/buildd/cwidget-0.5.16/tests'
/usr/bin/make check-TESTS
make[3]: Entering directory `/tmp/buildd/cwidget-0.5.16/tests'
Furthermore, as already mentioned, when I tried to test whether my
backport of the GCC atomics worked, I made a small test programme
to see whether it linked, but it *also* froze the VM (and I’m of the
opinion that it at most should have made the process inside eat up
almost-all CPU and be still killable/accessible). Parallel programming
is not mine, so I don’t know whether I did anything wrong (it wasn’t
really meant to be executed but to freeze the entire OS *and* virtual
hardware isn’t what I’d expect even in an endless loop).
Host: Kubuntu 8.04 (hardy) i386, Linux 2.6.24-32-server (2.6.24-32.104),
mpfr4 3.1.0-5~wtf804+1, aranym 0.9.13-3.1~wtf804+2
Guest: Debian sid m68k, Linux 3.2.0-3-atari (3.2.21-3)
Right now I suspect a bug on any layer, including the emulation.
It may or may not happen on my “other” host system:
Debian sid amd64 Xen domU, Linux 2.6.32-5-xen-amd64 (2.6.32-41),
mpfr4 3.1.0-5, aranym 0.9.13-3.1
If really needed, I can check that (and crash that VM, too) once the
guest I have on it is done compiling 3.2.23-1, i.e. in about 4-5 days.
Thanks in advance,
//mirabilos
<Natureshadow> Dann mach ich git annex copy --to shore und fertig ist das
<Natureshadow> das ist ja viel cooler als ownCloud ...
<mirabilos> sag ich doch
<Natureshadow> ja wieso stimmt das denn immer was du sagst ...
To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4....8400.18420@herc.mirbsd.org
Create a new topic
Follow the discussion
32 replies
Make a reply
Make your own search
Technology > Forums > Linux > Distribution > Debian > Ports > Motorola 68k (m68k) > ARAnyM VMs with Debian hanging at 100% CPU usage 
May 23rd, 2013 - 5:09 AM ET
Join now
Login
Replies