The steps to install Debian Wheezy RC1 / SPARC64 under QEMU.
Since the installation process is not obvious for the current QEMU and Debian versions, I gathered this How-To. Feel free to send any feedback.
Get the latest QEMU from git (released versions up to 1.4.x won't work).
Download debian-wheezy-DI-rc1-sparc-DVD-1.iso.
Currently qemu-system-sparc64 does not emulate the hardware devices the Debian can boot from. This is not a show stopper at all! We just going to need some extra steps for setting the things up. Mount the image on your host machine. As root,
# mkdir -p /mnt/wheezy
# mount -o loop,ro /path-to/debian-wheezy-DI-rc1-sparc-DVD-1.iso /mnt/wheezy
(if you don't want to do it as root, use isoinfo, fuseiso, 7z or whatever utility your OS has for extracting the files from ISO images)
As user which will run qemu,
$ mkdir ~/debian-wheezy-DI-rc1-sparc
$ cp /mnt/wheezy/boot/sparc64 ~/debian-wheezy-DI-rc1-sparc
$ cp /mnt/wheezy/boot/initrd.gz ~/debian-wheezy-DI-rc1-sparc
Unfortunately Debian Wheezy RC1 doesn't have virtio modules in the installation initrd. This won't stop us, as there is a package with them on the install media:
$ cd ~/debian-wheezy-DI-rc1-sparc
$ ar -p /mnt/wheezy/pool/main/l/linux/virtio-modules-3.2.0-4-sparc64-di_3.2.35-2_sparc.udeb data.tar.xz |tar xfJ -
$ umount /mnt/wheezy
now we have the modules:
$ ls -l lib/modules/3.2.0-4-sparc64/kernel/drivers/virtio/
total 56
-rw-r--r--. 1 user user 13184 Dec 19 17:10 virtio_balloon.ko
-rw-r--r--. 1 user user 11208 Dec 19 17:10 virtio.ko
-rw-r--r--. 1 user user 14480 Dec 19 17:10 virtio_pci.ko
-rw-r--r--. 1 user user 11368 Dec 19 17:10 virtio_ring.ko
add them to initrd:
$ gunzip -c initrd.gz > initrd+virtio
$ find lib/ |cpio -o -H newc --append -O initrd+virtio
$ rm -r lib
$ gzip initrd+virtio
Done. Now we have initrd+virtio.gz which contains the original initial RAMdisk contents and the virtio modules.
$ mkdir ~/debian-wheezy
$ qemu-img create -f qcow2 ~/debian-wheezy/debian-wheezy.qcow2 4G
# Please note that you'll need another command line for running the installed system
$ sparc64-softmmu/qemu-system-sparc64 -L pc-bios -m 384 -nographic \
-monitor telnet::4440,server,nowait -kernel ~/debian-wheezy-DI-rc1-sparc/sparc64 \
-initrd ~/debian-wheezy-DI-rc1-sparc/initrd+virtio.gz \
-drive file=~/debian-wheezy/debian-wheezy.qcow2,if=virtio,index=0 \
-drive file=/path/to/debian-wheezy-DI-rc1-sparc-DVD-1.iso,if=virtio,readonly=on,index=1 \
-net nic,model=virtio -net user -append 'modprobe.blacklist=pata_cmd64x'
Some seconds after launching the installer will be asking you about the locale settings. Nothing tricky about them. Then it will be trying hard to find a CD-ROM drive...
After this point comes a blank screen. Be patient it may take some minutes. And then... it won't find the CD/DVD drive, as we didn't give it any. Actually it was on purpose. The "pata_cmd64x" driver crashes under QEMU because of some missing functionality. So it's not only important not to launch QEMU with a '-cdrom' option, but also blacklist the pata_cmd64x driver (I didn't find the way to completely disable DMA. In PIO modes cmd64x might even be working).
The proper answer here is 'No'. We don't need to load additional drivers. The next question is whether we want to select the driver manually:
The answer is 'Yes'. We do want to select it manually...
...sort of. The module needed for accessing the CD-ROM is 'none' (we haven't plugged a real CD-ROM). The next question is the Device Name:
The default '/dev/cdrom' won't work (did I mention that we haven't plugged a real CD-ROM?). Use the virtio device /dev/vdb instead.
The next few steps are not QEMU-specific. You will be asked ...
for the Hostname, ...
password for the root user, ...
and disk partitioning. Here it makes more sense to use the "Manual" method. The "Guided" method creates a /boot partition (from which QEMU can't boot using virtio anyway) and too much swap for a virtual machine. So, unless you are the SILO developer/tester, you don't need a special /boot partition.
The installer warns that it will re-label your empty disk image.
Ext4 under QEMU is significantly faster than Ext3 (see a quick test here).
That's an example how it can be partitioned without /boot, ...
...and here comes the warning that SILO can not boot from an ext4 partition. Just ignore it.
Answer yes to write partition information. After this point the installation starts. It takes some tens of minutes (at least on my machine), so be patient. You'll figure as you see the progress monitor.
Not QEMU-specific. Select standard system utilities.
After taking the 'Continue' option the system will panic with the message Reboot failed:
Requesting system reboot
[ 3205.593245] Restarting system.
BOOT[ 3205.597929] Kernel panic - not syncing: Reboot failed!
This is expected, because the OpenBIOS can not reset system. So just use the QEMU monitor. From another shell execute
$ telnet localhost 4440
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
QEMU 1.4.50 monitor - type 'help' for more information
(qemu)
And enter 'q' here to quit the QEMU process gracefully.
$ cd ~/debian-wheezy/
$ guestfish --ro -a debian-wheezy.qcow2 -m /dev/vda1 copy-out /boot/vmlinuz-3.2.0-4-sparc64 /boot/initrd.img-3.2.0-4-sparc64 .
# -- QEMU can't load compressed kernel, so uncompress it
$ gunzip -c vmlinuz-3.2.0-4-sparc64 > vmlinux-3.2.0-4-sparc64
Use the kernel and initrd extracted at the step 6.
$ sparc64-softmmu/qemu-system-sparc64 -L pc-bios -m 384 -nographic \
-monitor telnet::4440,server,nowait -kernel ~/debian-wheezy/vmlinux-3.2.0-4-sparc64 \
-initrd ~/debian-wheezy/initrd.img-3.2.0-4-sparc64 \
-drive file=~/debian-wheezy/debian-wheezy.qcow2,if=virtio,index=0 \
-net nic,model=virtio -net user -append 'modprobe.blacklist=pata_cmd64x root=/dev/vda1'
optionally you can add
-drive file=/path/to/debian-wheezy-DI-rc1-sparc-DVD-1.iso,if=virtio,readonly=on,index=1
to make the installer DVD available for your guest OS.
/ Happy hacking
Since the installation process is not obvious for the current QEMU and Debian versions, I gathered this How-To. Feel free to send any feedback.
0. Getting stuff
Get the latest QEMU from git (released versions up to 1.4.x won't work).
Download debian-wheezy-DI-rc1-sparc-DVD-1.iso.
1. Extracting the kernel and initrd
Currently qemu-system-sparc64 does not emulate the hardware devices the Debian can boot from. This is not a show stopper at all! We just going to need some extra steps for setting the things up. Mount the image on your host machine. As root,
# mkdir -p /mnt/wheezy
# mount -o loop,ro /path-to/debian-wheezy-DI-rc1-sparc-DVD-1.iso /mnt/wheezy
(if you don't want to do it as root, use isoinfo, fuseiso, 7z or whatever utility your OS has for extracting the files from ISO images)
As user which will run qemu,
$ mkdir ~/debian-wheezy-DI-rc1-sparc
$ cp /mnt/wheezy/boot/sparc64 ~/debian-wheezy-DI-rc1-sparc
$ cp /mnt/wheezy/boot/initrd.gz ~/debian-wheezy-DI-rc1-sparc
2. Adding the VirtIO modules to initrd
Unfortunately Debian Wheezy RC1 doesn't have virtio modules in the installation initrd. This won't stop us, as there is a package with them on the install media:
$ cd ~/debian-wheezy-DI-rc1-sparc
$ ar -p /mnt/wheezy/pool/main/l/linux/virtio-modules-3.2.0-4-sparc64-di_3.2.35-2_sparc.udeb data.tar.xz |tar xfJ -
$ umount /mnt/wheezy
now we have the modules:
$ ls -l lib/modules/3.2.0-4-sparc64/kernel/drivers/virtio/
total 56
-rw-r--r--. 1 user user 13184 Dec 19 17:10 virtio_balloon.ko
-rw-r--r--. 1 user user 11208 Dec 19 17:10 virtio.ko
-rw-r--r--. 1 user user 14480 Dec 19 17:10 virtio_pci.ko
-rw-r--r--. 1 user user 11368 Dec 19 17:10 virtio_ring.ko
add them to initrd:
$ gunzip -c initrd.gz > initrd+virtio
$ find lib/ |cpio -o -H newc --append -O initrd+virtio
$ rm -r lib
$ gzip initrd+virtio
Done. Now we have initrd+virtio.gz which contains the original initial RAMdisk contents and the virtio modules.
3. Creating image for the virtual guest disk
$ mkdir ~/debian-wheezy
$ qemu-img create -f qcow2 ~/debian-wheezy/debian-wheezy.qcow2 4G
4. Launching QEMU for the installation
# Please note that you'll need another command line for running the installed system
$ sparc64-softmmu/qemu-system-sparc64 -L pc-bios -m 384 -nographic \
-monitor telnet::4440,server,nowait -kernel ~/debian-wheezy-DI-rc1-sparc/sparc64 \
-initrd ~/debian-wheezy-DI-rc1-sparc/initrd+virtio.gz \
-drive file=~/debian-wheezy/debian-wheezy.qcow2,if=virtio,index=0 \
-drive file=/path/to/debian-wheezy-DI-rc1-sparc-DVD-1.iso,if=virtio,readonly=on,index=1 \
-net nic,model=virtio -net user -append 'modprobe.blacklist=pata_cmd64x'
5. Answering Installer's questions
Some seconds after launching the installer will be asking you about the locale settings. Nothing tricky about them. Then it will be trying hard to find a CD-ROM drive...
After this point comes a blank screen. Be patient it may take some minutes. And then... it won't find the CD/DVD drive, as we didn't give it any. Actually it was on purpose. The "pata_cmd64x" driver crashes under QEMU because of some missing functionality. So it's not only important not to launch QEMU with a '-cdrom' option, but also blacklist the pata_cmd64x driver (I didn't find the way to completely disable DMA. In PIO modes cmd64x might even be working).
The proper answer here is 'No'. We don't need to load additional drivers. The next question is whether we want to select the driver manually:
...sort of. The module needed for accessing the CD-ROM is 'none' (we haven't plugged a real CD-ROM). The next question is the Device Name:
The default '/dev/cdrom' won't work (did I mention that we haven't plugged a real CD-ROM?). Use the virtio device /dev/vdb instead.
The next few steps are not QEMU-specific. You will be asked ...
for the Hostname, ...
password for the root user, ...
and disk partitioning. Here it makes more sense to use the "Manual" method. The "Guided" method creates a /boot partition (from which QEMU can't boot using virtio anyway) and too much swap for a virtual machine. So, unless you are the SILO developer/tester, you don't need a special /boot partition.
The installer warns that it will re-label your empty disk image.
Ext4 under QEMU is significantly faster than Ext3 (see a quick test here).
That's an example how it can be partitioned without /boot, ...
...and here comes the warning that SILO can not boot from an ext4 partition. Just ignore it.
Answer yes to write partition information. After this point the installation starts. It takes some tens of minutes (at least on my machine), so be patient. You'll figure as you see the progress monitor.
Not QEMU-specific. Select standard system utilities.
After taking the 'Continue' option the system will panic with the message Reboot failed:
Requesting system reboot
[ 3205.593245] Restarting system.
BOOT[ 3205.597929] Kernel panic - not syncing: Reboot failed!
This is expected, because the OpenBIOS can not reset system. So just use the QEMU monitor. From another shell execute
$ telnet localhost 4440
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
QEMU 1.4.50 monitor - type 'help' for more information
(qemu)
And enter 'q' here to quit the QEMU process gracefully.
6. Getting the installed kernel and initrd
Use the guestfish to get the files from the qcow2 image:
$ cd ~/debian-wheezy/
$ guestfish --ro -a debian-wheezy.qcow2 -m /dev/vda1 copy-out /boot/vmlinuz-3.2.0-4-sparc64 /boot/initrd.img-3.2.0-4-sparc64 .
# -- QEMU can't load compressed kernel, so uncompress it
$ gunzip -c vmlinuz-3.2.0-4-sparc64 > vmlinux-3.2.0-4-sparc64
7. Booting from the installed Debian Wheezy / sparc64 image
Use the kernel and initrd extracted at the step 6.
$ sparc64-softmmu/qemu-system-sparc64 -L pc-bios -m 384 -nographic \
-monitor telnet::4440,server,nowait -kernel ~/debian-wheezy/vmlinux-3.2.0-4-sparc64 \
-initrd ~/debian-wheezy/initrd.img-3.2.0-4-sparc64 \
-drive file=~/debian-wheezy/debian-wheezy.qcow2,if=virtio,index=0 \
-net nic,model=virtio -net user -append 'modprobe.blacklist=pata_cmd64x root=/dev/vda1'
optionally you can add
-drive file=/path/to/debian-wheezy-DI-rc1-sparc-DVD-1.iso,if=virtio,readonly=on,index=1
to make the installer DVD available for your guest OS.
/ Happy hacking
46 comments:
> Unfortunately Debian Wheezy RC1 doesn't have virtio modules in the installation initrd.
> This won't stop us, as there is a package with them on the install media
Hmm, this should probably be reported as bug (if it hasn't been reported yet)...
Yeah, reported twice. #673320 and #704672.
Looks like this how-to helped to push it. Steve McIntyre promised that in rc2 it will be fixed.
Здравствуйте Артем !
А незнаете ли вы, есть ли возможность(хотя-бы теоритическая) запустить в qemu sparc - Solbourne OS/MP 4.1.
Привет Дмитрий! (что за официальность, кстати? Мы же вроде в прошлый раз были на "ты"?)
Искал Solbourne несколько лет назад, но не нашёл.
OS/MP 4.1 умеет запускаться на одном CPU? Если да - шанс есть. Носитель - CD или лента? Если CD, QEMU его надо подсовывать как жёсткий диск. Потому что размер сектора, скорее всего, 512 байт.
Если OS/MP слишком привязана к Solbourne, может потребоваться родная прошивка ПЗУ (у меня её нет) и немного колдунства с соединением компонентов QEMU (но там всё просто, если знать, что по какому адресу подключать).
А если OS/MP не может запускаться на одном проце - надо сначала найти, из-за какого бага, OBP под QEMU не опознаёт наличие более одного процессора.
У меня CD, на образе UFS(big endian), поэтому посмотреть что на диске у меня возможности нет.
По твоей инструкции о установке Solaris, я попытался загрузиться с образа но получил:
ok boot disk1:d -vs
Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@1,0:d File and args: -vs
The file just loaded does not appear to be executable.
Возможно все дело в фирмваре, у меня есть дампы солборновских железок, но мне это дампы кажутся странными, да и Sparc я полный 0
Я посчитал, что лишним оффициоз не будет, так как своим странным хобби возможно отвлекаю вас от важных дел.
Вообще-то, UFS под линуксом прочитать довольно легко. (Изменять труднее и опаснее). Под CentOS я просто делаю
mount -o loop,ro /path/to/img /mnt
иногда ещё надо указать ufstype=sun (dmesg про это скажет).
> The "pata_cmd64x" driver crashes under QEMU because of some missing functionality.
Probably, it would be better for QEMU to emulate some SCSI controller instead of this PATA one...
>Probably, it would be better for QEMU to emulate some SCSI controller instead of this PATA one...
PATA is used just to be close to the original Ultra-5 machine. QEMU can emulate multiple PCI SCSI controllers.
But virtio is faster than emulated SCSI devices anyway (especially since due to the current limitations in the upstream SPARC PCI controller they would only be able use PIO mode).
Hi, excellent blog article, however now, the final one is needed! How to run Solaris 10 on qemu/sparc64? Would be most welcome here! Thanks! :-)
thank you for the article,
i tried debian 7.8 (last sparc release) http://cdimage.debian.org/cdimage/archive/7.8.0/sparc/iso-dvd/debian-7.8.0-sparc-DVD-1.iso
because 7.7 and earlier versions are not available anymore
debian 7.8 does still not include the virtio modules in initrd
with qemu git (2015/07/02) build under ubuntu 15.04 x64
i followed your virtio installation step by step but the installation breaks with "installtion failed" while installing the "standard system utilities" and the resulting images is not bootable
any avices for using debian 7.8 with virtio?
installing without virtio directly booting from dvd works but is way to slow - test installation runned for hours and it would be nice to have a little bit faster system
Can you please check the logs after the "installtion failed" message? What is failing exactly? I haven't tried it recently but from your report it looks like it aborts after successful loading the virtio drivers. It may be a regression in a sparc kernel or QEMU sparc emulation (the later is less likely because there were no sparc - related changes recently).
i will get back to my computer in two weeks and will check the installation logs (console 4 or /var/log/syslog i think) while getting the error, using a freshly git qemu - and 3 shell-scripts for initrd virtio preperation, installtion-start and after-installation-extraction + some screenshots - anything else i can prepare?
back to my computer i tested the installation again but i've got problems to get to the log console - ctrl-alt-f1...f4 does nothing, esc-1..2 works sometimes, also qemu monitor sendkey does not work
tested on ubuntu itself and a putty (for the setup and another for qemu monitor) connection from windows
got the syslog :)
debian 7.8 sparc install fail syslog
http://pastebin.com/L156mQZ6
my install start script
http://pastebin.com/BUtTb3n1
the non-virtio installtion with
qemu-system-sparc64 -m 1024 -hda debian-7.8.0.qcow2 -nographic -cdrom debian-7.8.0-sparc-DVD-1.iso -boot d
works/runs without any problem
better compareable (diffable) syslogs of virtio and non-virtio installation
i replaced alle PIDs/ect. with !better_diffable!
non_virtio_install_syslog.txt
http://pastebin.com/QMgE86fT
virtio_install_fail_syslog.txt
http://pastebin.com/Dxb28NX1
it seems that the virtio installation (with working ethernet) tries
to uses different (broken?) security packages from the internet - is that the problem?
and another info:
the non-virtio installation show different options while installation
for example:
the "Participate in package survey" question does come not up when using virtio
the non-virtio installation gives me the complete list of installable software like Desktop Environment, SSH Server, etc. the virtio just "Basic System utilities"
Yes, for some reason it says:
"Unable to locate package popularity-contest"
which would start the survey. What is strange, the non-virtio install is failing to connect to security.debian.org , so it doesn't seem to install any updates.
One idea is to try a virtio install where qemu is not connected to the net, to check whether security updates break anything.
the virtio installation works if i disable network
but i still get only "Basic System Utilities" not the complete list and
no package popularity-contest question like in the non-virtio installation
so
virtio with net:
not the complete list of installabale software - only basic utilities
no package popularity-contest question
-->install fail some time after "basic system utilities" installation
virtio without net
not the complete list of installabale software - only basic utilities
no package popularity-contest question
-->install works and is bootable
non-virtio with net
complete list of installabale software
package popularity-contest question
-->install works and is bootable
anything else i can do?
and still the question why non-virtio fails to connect to security.debian.org?
Report a bug to qemu-devel@ and debian-sparc@lists.debian.org . :-)
I'll try installing the version 7.8 tonight. And I think I'll have to update this how-to because meanwhile QEMU can perfectly boot from the IDE drives, so using an IDE drive for /boot and a VirtIO drive for / might be easier than extracting the kernel/initrd from the VirtIO disk.
I think it doesn't connect to security.debian.org because of your command line. Try adding "-net user" to it.
Yes, I can reproduce the setup messing up when a virtio device is used instead of cdrom. It seems to be a regression in the Debian installer. What is also interesting, the late stage just ignores device explicitly given as a cdrom from which the base system is installed. Without modprobe.blacklist=pata_cmd64x, it keeps trying /dev/sr0.
Well, since there is a workaround - using the ide cdrom - and since sparc is not an official Debian port anymore it's quite unlikely that it's gonna be fixed. But who knows...
will you update or post a new blog about the debian 7.8 installation / and the known problems - could help the bug report to have an known sparc/qemu authoritiy behind :)
so the current workaround is
using virtio for the hda
using ide for cdrom
blacklist pata_cmd64x
like
qemu-system-sparc64 -m 1024 -nographic -drive file=~/image.qcow2,if=virtio,index=0 -cdrom~/debian-7.8.0-sparc-DVD-1.iso -net nic,model=virtio -net user -append 'modprobe.blacklist=pata_cmd64x'
or?
Not quite. Blacklisting partially solves problems in virtio-only install, but shall not be used with -cdrom option (with it the ide driver is blacklisted). So it's just
qemu-system-sparc64 -m 1024 -nographic -drive file=~/image.qcow2,if=virtio,index=0 -cdrom ~/debian-7.8.0-sparc-DVD-1.iso -net nic,model=virtio -net user
and kernel sparc64 + virtio-initrd
Haven't tried, but it should be not necessary when booting from an ide cdrom.
do i still need to disable network with -net user,restrict=y then?
No, disabling the network is not necessary. I did an install from an IDE cd to a VirtIO hdd with network. Chosen a German mirror when the installer asked for it, but I think it should not matter.
The install is a bit slower than a pure VirtIO install, but not 6 times slower as I was afraid (I wrote about VirtIO vs. IDE performance some time ago).
>No, disabling the network is not necessary.
>I did an install from an IDE
>cd to a VirtIO hdd with network.
that seems to work
>Chosen a German mirror when
>the installer asked for it
me too
>but not 6 times slower
>as I was afraid
i've installed the whole stuff serveral times an
would say at least 3-4 times slower
thx for the help
the installation works - thx
is there anything i can do to speedup qemus emulation (attach cores or stuff like that)?
its still very slow
3-4 times slower is strange: I did a quick benchmarking and in case of a DVD iso image the throughput seems to be only 20% less:
# dd if=/dev/sr0 of=/dev/null bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 2.0884 s, 50.2 MB/s
# dd if=/dev/vdb of=/dev/null bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.81383 s, 57.8 MB/s
And for some reason a virtio HDD access is 2 times faster than virtio DVD access.
As for speeding up, I'm afraid currently there is no way to do it. You can try using more aggressive gcc optimization options or even using icc for compilation (some tests shown 15% performance gain with it on my hardware), but yeah. QEMU is not that quick when emulating sparc64 CPU.
Maybe it gets better when the upstream switches to the multi-threaded TCG.
>the throughput seems to be only 20% less
the virtio-dvd (which fails in the end) is definitiely multiple times faster - i reinstalled the whole stuff serveral times
also the rest of the system is very slow
currently compiling CMake - for the last 2 hours i think - under the x86 host itself a thing of few minutes
cmake 3.2.2 tooked more then 10 hours to build - but it works :)
That's slow. Have you had an experience with building it on a real sun4u? Is actually cmake the goal, or are you going to use it for building something else?
Can you please try looking in "perf top" during the build to find out where does QEMU spend time the most? Maybe there are some easy ways to gain more performance.
>That's slow. Have you had an experience with building it on a real sun4u?
hardcore slow
no i don't have a sun4u available
have you got one with debian 7.8.0 for comparison available :)
>Is actually cmake the goal,
>or are you going to use it for building something else?
want to build something other - bigger :(
>Can you please try looking in "perf top"
>during the build to find out where does QEMU
>spend time the most? Maybe there are some
>easy ways to gain more performance.
im still unable to switch to another virtual terminal
tried
1. qemu monitor sendkey
2. ALT + left or right arrows on the keypad
3. stick" it to the "virtualized window" followed by the other keys e.g. CTRL+CTRL+CTRL+ALT+F1
anything else i can do to get to another login
I usually set port forwarding (either with qemu command line or via ssh from guest to host) and ssh from host to guest as many sessions as I need.
But when I was writing about "perf top", I meant the host, not the guest. That would show where QEMU spends its time while building your software.
And, btw, if you are tunneling with ssh (http://tyom.blogspot.de/2010/03/tunneling-qemu-guest-back-and-forth.html), it makes sense to use an faster cipher http://tyom.blogspot.de/2010/03/ssh-ciphers-on-emulated-sparcs.html .
im not using tunneling - but maybe i should
running "top perf" after boot gives:
53.16% [kernel] [k] touch_nmi_watchdog
39.27% [kernel] [k] touch_softlockup_watchdog
2.78% perf_3.2 [.] 0x42e5c
1.22% perf_3.2 [.] dso__find_symbol
now i need to setup ssh access and perf the cmake (or something smaller build)
Why do you need ssh to run perf top on the host? The idea is to profile QEMU process itself and not the guest OS. But to make it sure you are profiling something useful and not the OS idle loop, the guest has to run something useful (the build in your use case).
http://pastebin.com/D2fUpPrM
mit Host und SPARC
Pugixml(and test) builds for ages
if you want to have a look
i uploaded my debian image for the pugixml developer to help solving some big-endian/unaligned access problems
using the free file hoster depositfiles (seems to be the only one with ftp upload feature)
https://depositfiles.com/files/sj20aqwp0
press the "regular download" button, wait some seconds, solve the chapca, "download file in regular mode by browser"
there is pugi_sparc.txt in the 7z which describes how to start and what is installed in the image
i benchmarked the pugixml.cpp (https://github.com/zeux/pugixml/blob/master/src/pugixml.cpp) compile
qemu-system-sparc64: >180sek
x64 native : ~ 2sek
that explains my 10h cmake build perfectly :)
Have you looked how much RAM does gcc need for compiling the file? Could it be that the virtual Debian starts swapping/paging?
root@debian:~# free -mh
ram
total: 1.0G
used: ~140...150MB
free ~800...900MB
swap
total: 86M
usage: 0M (never in use)
while compiling
If you are not limited to Linux, there is a faster emulator - TME. I wrote about it a few years back. But afair it can only boot NetBSD.
Post a Comment