Am 09.11.2016 um 07:34 schrieb Dennis Luehring:
im using cross-linux-from-scratch manual/script for building the non-x86_64
platforms
fyi
after using the crosscompilers from the gcc-5-crossports packages
(http://packages.ubuntu.com/source/xenial/gcc-5-cross-ports)
alpha-linux-gnu-gcc-5
Am 07.11.2016 um 18:21 schrieb Laszlo Ersek:
its not alpha related same error happens with ppc64,sparc64,mips64...
so i tried to reproduce the errors also on x86_64 in qemu
building a tiny linux kernel 4.8.6 (~1MB) and a simple init (~1MB) based on
http://mgalgs.github.io/2015/05/16/how-to-bu
Am 07.11.2016 um 16:56 schrieb Laszlo Ersek:
>so the second one couldn't be a problem with running out of memory - and
>its not alpha related same error happens with ppc64,sparc64,mips64...
The second one*is* related to running out of memory. Initrd
decompression takes unintuitive amounts of me
Am 07.11.2016 um 15:15 schrieb Laszlo Ersek:
On 11/07/16 08:35, Dennis Luehring wrote:
> Am 04.11.2016 um 20:40 schrieb Laszlo Ersek:
>> I guess it is "possible to design a system which can recover from
>> this", except noone seems to have bothered, since 2009. (Ditto f
Am 07.11.2016 um 15:12 schrieb Laszlo Ersek:
The second error message is incorrect in its own right (it's just
another symptom of running out of memory;
there a two cpios
big(~370MB) initrd.cpio + 1GB ram gives only this message: "Initramfs
unpacking failed: write error"
small(~14MB) initrd.cp
Am 04.11.2016 um 22:08 schrieb Richard Henderson:
No, it was less specific than that. Something like "unpacking failed: error".
>And, apparently, it used to be handled with a panic() call, but then that
>was deemed "policy", and downgraded to a KERN_EMERG message:
Ouch. A silly decision, but
Am 04.11.2016 um 20:40 schrieb Laszlo Ersek:
I guess it is "possible to design a system which can recover from this", except noone
seems to have bothered, since 2009. (Ditto for the proposed "panic-level=X" alternative.)
I've now briefly considered posting a trivial kernel patch for this, but h
qemu: 2.7.x (git head)
platform: Alpha (Clipper)
kernel: 4.7.0
gcc: 6.1
i don't know if its an qemu oder linux kernel problem
i've got an ~360MB big_initrd.cpio and it sometimes happen(seems so) that
there are files missing after the kernel loaded the initrd
this does not happen with the same pr
Am 15.10.2016 um 12:29 schrieb Alex Bennée:
>i can get a list of all supported CPUs by using the -cpu ? commandline
>
>but which CPU is selected if i don't give the -cpu parameter on normal
>qemu start of a softmmu?
IIRC it is dependant on the machine model you select
and which cpu is seletec
i can get a list of all supported CPUs by using the -cpu ? commandline
but which CPU is selected if i don't give the -cpu parameter on normal
qemu start of a softmmu?
fixed - thanks
Am 16.08.2016 um 09:33 schrieb Marc-André Lureau:
Hi
On Tue, Aug 16, 2016 at 10:35 AM Dennis Luehring wrote:
> working: "v2.7.0-rc0" 2d2e632ad00d11867c6c5625605b1fbc022dd62f
> non-working: "v2.7.0-rc1" 69d490079f82f5ffe31fff426aaa580d5fec5fb7
>
you should push that change - can't find it on http://git.qemu.org/qemu.git
Am 16.08.2016 um 10:33 schrieb Marc-André Lureau:
Since commit d7a04fd7d5008, tcp_chr_wait_connected() was introduced,
so vhost-user could wait until a backend started successfully. In
vhost-user case, the chr socket mus
Signed-off-by: Michael S. Tsirkin
:100644 100644 6eba615818b7ae96256017663acde90e0e674d30
a50b8fb3a39c8c5456c901dc420d1fb2aadd1b0d Mqemu-char.c
Am 12.08.2016 um 11:03 schrieb Stefan Hajnoczi:
On Fri, Aug 05, 2016 at 07:15:06AM +0200, Dennis Luehring wrote:
> my scenario works wi
my scenario works with before "v2.7.0-rc1"
git "v2.5.0" OK
git "v2.6.0" OK
git "v2.7.0-rc0" OK
git "v2.7.0-rc1" FAILS
[qemu-git]
build qemu from git at ~2016/08/04
git rev-parse HEAD
09704e6ded83fa0bec14baf32f800f6512156ca0
[scenario]
qemu/sparc64-softmmu/qemu-system-sparc64 --version
QEMU emu
qemu-system-alpha -m 1GB -nographic -monitor telnet::4440,server,nowait
-serial telnet::3000,server -kernel clfskernel-4.2.3 -append
'console=ttyS0' -initrd initramfs.cpio
using: git clone -b "v2.4.0.1" git://git.qemu-project.org/qemu.git and build
i see the normal
"QEMU waiting for connection
Am 30.09.2015 um 08:48 schrieb Richard Henderson:
On 09/30/2015 02:36 PM, Dennis Luehring wrote:
> ~/qemu/alpha-softmmu/qemu-system-alpha -m 1GB -monitor
telnet::4440,server,nowait\
> -kernel vmlinux.img-2.6.26-2-alpha-generic -initrd
> initrd.img-2.6.26-2-alpha-generic\
> -
Am 30.09.2015 um 04:40 schrieb Richard Henderson:
On 09/27/2015 05:02 PM, Dennis Luehring wrote:
> git master clone from 09/27/2015, 8:07
> git rev-parse HEAD
> 9e071429e649346c14b2dc76902f84f8352d2333
>
> if i try to start qemu-system-alpha with option -nographic while installing
git master clone from 09/27/2015, 8:07
git rev-parse HEAD
9e071429e649346c14b2dc76902f84f8352d2333
if i try to start qemu-system-alpha with option -nographic while
installing debian lenny 5.0.10 for alpha
i get this output and qemu hangs - without using -nographic debian is
fully installable
Am 15.09.2015 um 22:19 schrieb Richard Henderson:
Indeed. It would indeed be good to add a bunch of bare-metal tests.
Pre-compiled and checked in so that one doesn't have to have a suite of
cross-compilers in order to use them.
OTOH, I don't see myself (or anyone else) really having the time to
Am 10.09.2015 um 12:37 schrieb Dennis Luehring:
Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:
> On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring wrote:
>> >Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>> >>>
>>>>> >>> >stran
Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:
On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring wrote:
>Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>
>>> >strangly your branch doesn't changed anything for pure SPARC64 in my
>>> >tests -
>
Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>strangly your branch doesn't changed anything for pure SPARC64 in my tests -
>i've always completely removed the qemu folder and cleanly rebuild
>(all based on stable shell-scripts)
Can you please show "perf top" of the qemu-system-sparc64 proces
Am 08.09.2015 um 21:00 schrieb Richard Henderson:
Anyway, I've just fixed the sparc problem and re-pushed the tree to
git://github.com/rth7680/qemu.git tcg-search-2
for anyone who wants to do any more testing.
strangly your branch doesn't changed anything for pure SPARC64 in my
tests - i
i will try that - thx
Am 27.08.2015 um 17:29 schrieb Artyom Tarasenko:
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7
Am 26.08.2015 um 21:47 schrieb Richard Henderson:
Anyway, this sort of setup is exactly what I did for Alpha. The PALcode
(hypervisor-ish) layer used for qemu looks nothing like the PALcode layer used
for real hardware.
can post your qemu parameters for installing/starting your alpha
emulatio
Am 25.08.2015 um 20:09 schrieb Richard Henderson:
But you're right, it would be nice to put together a coherent set of
benchmarks. Ideally, a guest kernel plus minimal ramdisk with the tests
pre-loaded so that we can boot and run ./benchmark at the prompt. That's
the sort of thing we can easily
Am 25.08.2015 um 20:09 schrieb Richard Henderson:
On 08/25/2015 07:37 AM, Dennis Luehring wrote:
> Am 25.08.2015 um 16:25 schrieb Richard Henderson:
>> Er, no, it should. The primary vector by which I expect improvement is via
not
>> encoding dmmu.mmu_primary_context into the
Am 25.08.2015 um 16:25 schrieb Richard Henderson:
Er, no, it should. The primary vector by which I expect improvement is via not
encoding dmmu.mmu_primary_context into the TB flags. I.e. ASI_DMMU, which
sun4u certainly uses.
The fact that the patch_also_ fixes a sun4v problem is secondary.
Am 25.08.2015 um 08:44 schrieb Artyom Tarasenko:
>your patch gives the worst result in stream benchmark but nearly the best in
>pugixml compile times and prime.c runtime
>every tried patch or branch nearly halfs the speed of the stream benchmark
>comapred to qemu-git-master
This is very surprisi
Am 25.08.2015 um 06:19 schrieb Richard Henderson:
Artyom and Dennis, I'm hoping that this will help with some of your
translation performance problems. I don't currently have a sparc64
kernel set up for booting, but I did smoke test this with openbios,
and even there it reduced the number of TBs
Am 22.08.2015 um 20:53 schrieb Artyom Tarasenko:
Compared with #undef USE_TCG_OPTIMIZATIONS , they are similar, yes.
Compared with vanilla master I get a more noticeable improvement.
my test suffering less from the Aurelien Jarno described Sparc32->x86_64
"translation" if you're still using de
Am 22.08.2015 um 18:45 schrieb Artyom Tarasenko:
git master: 18m31s
tcg-indirect: 16m50s
#undef USE_TCG_OPTIMIZATIONS: 14m18s
my results are not totaly different to yours - ~20-30% slowdown compared
to #undef USE_TCG_OPTIMIZATIONS
Am 21.08.2015 um 17:47 schrieb Richard Henderson:
On 08/20/2015 11:05 PM, Dennis Luehring wrote:
>> > g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
-MP
>> >
>> > tcg-indirect: ~2:46.5
>> > qemu.org-git: ~2:51.2 (worst result)
>
Am 21.08.2015 um 07:49 schrieb Richard Henderson:
On 08/20/2015 09:32 PM, Dennis Luehring wrote:
> gcc prime.c -o prime.out -lm
>
> prime.out runtime
>
> tcg-indirect: ~9.3 sec (best result)
> qemu.org-git: ~11 sec
> without-optimization: ~9.9 sec (worst result)
I presume
Am 20.08.2015 um 19:19 schrieb Richard Henderson:
This isn't surprising, because at the moment tcg optimizations are almost
completely ineffective for sparc. The way the register windows are implemented
means that there are very few proper tcg temporaries to optimize.
I've just updated an old b
Am 19.08.2015 um 16:41 schrieb Artyom Tarasenko:
And if I completely disable optimizer (// #define
USE_TCG_OPTIMIZATIONS in tcg.c), it's still quite faster:
real14m17.668s
user14m10.241s
sys 0m6.060s
my tests also without USE_TCG_OPTIMIZATIONS
qemu 2.4.50, netbsd 6.1.5 SPARC64
wi
Am 18.08.2015 um 21:06 schrieb Karel Gardas:
Thanks a lot for doing this. It looks like g++ is memory-bound in this
case, isn't it? What does stream[1] benchmark tell on host and
emulated as 32/64bit sparc binary? Let's see if the ratio is kind of
similar to the time you get...
[1]:https://www.c
Am 06.08.2015 um 11:00 schrieb Karel Gardas:
Denis, if NetBSD is fast in qemu and if it provides sparc64 user-land,
perhaps also its GCC is sparc64 binary and if so, then it would be
good if you do your original benchmark of compiling pugixml.cpp and
write the numbers here for comparison? I would
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
and the gcc -ftime-report
g++ src/pugixml.cpp -g -Wall -Wextra -Werr
Am 18.08.2015 um 10:19 schrieb Aurelien Jarno:
How big is the source file and the output file? I find strange that I/O
impacts so much for a compilation which should be CPU bounded. Maybe try
to add the -pipe argument to g++.
NetBSD SPARC64, running from ramdisk, qemu 2.4.50
g++ src/pugixml.cp
Am 31.07.2015 um 17:43 schrieb Aurelien Jarno:
> >Anyway I have extracted this code into a C file (see attached file) that
> >can more easily compiled to 32 or 64 bit using -m32 or -m64. I observe
> >the same behavior than sysbench, even with qemu-user (which is not
> >surprising as the above cod
qemu-2.2.0/bin/qemu-system-sparc64 -hda
openbsd_sparc64.img -m 1024 -nographic -net nic,model=i82551 -net
user
On Thu, Aug 6, 2015 at 11:27 AM, Dennis Luehring wrote:
> Am 06.08.2015 um 11:21 schrieb Dennis Luehring:
>>
>> if NetBSD is fast in qemu and if it provides sparc64 user-l
Am 06.08.2015 um 11:21 schrieb Dennis Luehring:
if NetBSD is fast in qemu and if it provides sparc64 user-land,
>perhaps also its GCC is sparc64 binary and if so
according to the docs its pure SPARC64 kernel and userland (no exceptions)
, 2015 at 9:51 PM, Dennis Luehring wrote:
> Am 03.08.2015 um 17:59 schrieb Karel Gardas:
>>
>> On Mon, Aug 3, 2015 at 4:51 PM, Dennis Luehring wrote:
>> > ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0
>> > SPARC64 -
>> > i installed the
Am 03.08.2015 um 17:59 schrieb Karel Gardas:
On Mon, Aug 3, 2015 at 4:51 PM, Dennis Luehring wrote:
> ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0 SPARC64 -
> i installed the complete system (without X) in a few minutes
> Debian needs >1h
I had the same exp
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland.
ok - NetBSD 6.5.1 SPARC64 is blasting fast compare to Debian 7.8.0
SPARC64 - i installed the complete system (without X) in a few minutes
Debian
Am 30.07.2015 um 10:55 schrieb Aurelien Jarno:
Note that when you say SPARC64 here, it's actually only the kernel, you
are using a 32-bit userland. And that makes a difference. Here are my
tests here:
installing NetBSD 6.5.1 SPARC64 seems to perform much better (compared
to Debian 7.8.0 SPARC6
Am 30.07.2015 um 12:09 schrieb Aurelien Jarno:
I am using Debian SPARC64 from debian-ports. But it's not really
ready-to-use and often broken.
the current 6.5.1 NetBSD is available for SPARC and SPARC64 - with SPARC
using 32bit Kernel/Userland and
SPARC64 with 64bit Kernel/Userland
and accor
Am 30.07.2015 um 09:52 schrieb Aurelien Jarno:
On 2015-07-30 05:52, Dennis Luehring wrote:
> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
> >The point is that emulation has a cost, and it's quite difficult to
> >to lower it and thus improve the emulation speed.
>
> s
Am 29.07.2015 um 17:01 schrieb Aurelien Jarno:
The point is that emulation has a cost, and it's quite difficult to
to lower it and thus improve the emulation speed.
so its just not strange for you to see an 1/100...200 of the native x64
speed under qemu/SPARC64
i hoped that someone will jump u
YES
value: 0x1234
done
On Wed, Jul 29, 2015 at 3:55 PM, Dennis Luehring wrote:
> Am 29.07.2015 um 14:34 schrieb Karel Gardas:
>>
>> Once it boots, tell me how to find the asnwers to your
>> questions.
>
>
> compile with gcc test.cpp and run
>
> ---
Am 29.07.2015 um 14:34 schrieb Karel Gardas:
Once it boots, tell me how to find the asnwers to your
questions.
compile with gcc test.cpp and run
---
#include
#include
#include
#include
#include
int main()
{
uint16_t value = 0x1234;
{
volatile uint8_t* ptr = (uint8_t*)&
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
What was interesting was that nbench2 was comparable on aarch64
was aarch64 a little or big-endian system, with unaligned accesses possible?
Am 29.07.2015 um 11:17 schrieb Karel Gardas:
If
anybody is interested I can dig those old emails.
would be nice
UMA node0 CPU(s): 0-7
Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
On Tue, Jul 28, 2015 at 9:52 AM, Dennis Luehring wrote:
> (i've posted the question already on qemu-disc...@nongnu.org but was toled
> to better use this mailing list)
>
> i've prepared an Debian 7.8.0 ima
Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
>anything i can do to speedup the emulation?
Maybe try the fresh tcg optimizer improvements from Aurelien:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
it don't seems to target sparc (or isn't ready) many x86/x64 only etc.
(i've posted the question already on qemu-disc...@nongnu.org but was
toled to better use this mailing list)
i've prepared an Debian 7.8.0 image for SPARC64/qemu emulation for C/C++
development before-real-hardware big-endian/unaligned tests
i've benchmarked compiling of single pugixml.cpp
(htt
Am 18.07.2014 00:22, schrieb Mark Cave-Ayland:
On 17/07/14 07:43, Dennis Luehring wrote:
> Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
>> At the moment my work is focused on getting the basic system emulation
>> up and running, so I haven't spent much time looking at the
Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
At the moment my work is focused on getting the basic system emulation
up and running, so I haven't spent much time looking at the graphics
side at all.
I have noticed that the kernel falls back to the dummy console during
boot, so perhaps it is una
i've followed the avices on Artyom Tarasenko's blog to install debian
wheezy sparc on qemu
but qemu won't boot the graphical installation
with -nographic the debian default installation seems to work
is this a known bug?
these are my installation steps
fresh ubuntu 14.04 x64 (3.13.0-30-generi
Am 08.07.2014 00:15, schrieb Mark Cave-Ayland:
Sadly sun4u support isn't quite there yet; it's enough to boot Linux
(and with git master you can actually start booting the *BSD kernels and
Solaris) but there are still some issues with the device tree that need
to be resolved in order for this to
i want to virtualize my noisy sparc workstation
with the help of qemu and want to know if its possible to
get an system image to run or what other options available
for sparc virtualization
im developing a low-traffic network communication software
and sparc is one of my test platforms
is the sp
i want to virtualize (under a linux x86 host) my noisy sparc workstation
with the help of qemu and want to know if its possible to
get an system image to run or what other options available
for sparc virtualization
im developing a low-traffic network communication software
and sparc is one of my
63 matches
Mail list logo
