[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian on qemu-system-sparc64



Hi Adrian,

On Tue, Jan 26, 2016 at 12:13 AM, Adrian Davey <adrian@beth2.org> wrote:
>> Another item to note is that running
>> `top` in debian/unstable sparc64 has a load of ~1.09 of an idle system
>> (1.6 us, 2.9 sy, 0.0 ni, 95.5 id)
>> while
>> `top` in debian/7.9 sparc has a load of ~0.00 of an idle system (0.3
>> us, 1.6 sy, 0.0 ni, 98.7 id)
>>
>> I am tempted to try the 4.3 kernel on the debian 7.9 VM to see what
>> happens...
>
>
> Ok after a little fun with forcing dpkg architectures and depends in
> addition to a little bit of debian backports for initramfs-tools and udev +
> some guidance from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+752742, I have the 4.3
> kernel running on debian/7.9~ sparc.
>
> Same problem with bochs-drm as expected,

Btw, is bochs-drm supposed to work on a big endian machines at all?
Are there success stories from ppc, mips or arm folks?

> but `top` remains the same for load
> stats as the previous kernel.
>
> I wonder what is causing 64bit userland to spin so much on noops, or
> whatever it is doing.

64bit sparc userland should actually be faster under qemu (given that
qemu is compiled for x86_64).
It's also visible in your top output: with the 64 bit userland the
system is more idle.

The load average can be caused by waiting for I/O, or by a waiting
device driver.
What happens if you boot QEMU with "-nographic" option?

Basically there are just a few devices which are used: IDE (virtio),
serial, network, VGA and PS/2.

With -nographic the last two can be excluded. To exclude IDE and
virtio  it's possible to boot with a ramdisk.
If the presence of VGA makes no difference,  you can boot without
network and serial (or boot with serial console without the network
and VGA).

Then there are some optional modules, like RTC. And the last
possibility is that LA is caused by a buggy driver for a device which
is not present at all.

What modules are loaded?

Btw, when not testing an install image, I find booting qemu with
-kernel and -initrd options more handy. That's how I used to add the
virtio drivers to the initrd:
http://tyom.blogspot.de/2013/03/debiansparc64-wheezy-under-qemu-how-to.html

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu


Reply to: